前言很久没有处理很大的集群，在接触一个新集群的时候，如果集群足够大，需要比较长的时间才能去理解这个集群的结构，而直接去看ceph osd tree的结果，当然是可以的，这里是把osd tree的结构进行了一个结构化输出，也可以理解为画出一个简单的结构图，比较适合给其它人讲解你对crush做了哪些改变，这个如果指着文字来讲估计很多人会听的云里雾里，如果有比较方便的方式出图就比较好了 为此写了一个小工

关于arm之前wdlab对外发布过一次约500个节点的arm的ceph集群，那个采用的是微集群的结构，使用的是双核的cortex-a9 ARM处理器，运行速度为1.3 GHz，内存为1 GB，直接焊接到驱动器的PCB上，选项包括2 GB内存和ECC保护 这个在国内也有类似的实现，深圳瑞驰商用Arm存储NxCells 这个采用的是微集群的架构，能够比较好的应对一些冷存场景，但是今天要说的不是这种架

前言自启动相关的文章很多，有分析的很详细的文章，这里就不做赘述，本篇讲述的是什么情况下用，怎么用的问题 使用场景一台机器的系统盘坏了，需要重装系统，相关的一些信息没有了，但是上面的数据盘还是在的，所以需要保留 某个磁盘需要换台机器进行启动，但是那台机器上没有相关的信息 处理过程自启动的相关处理先扫描下lvm 123vgscanpvscanlvscan 本篇的场景是lvm没有损坏的情况，如果lvm本

问题通过对我们的启动流程看了下，目前是穿到一个脚本里面的，然后这个脚本是用无限循环的方式去执行一些事情，这个地方不符合松耦合的设计，一个模块做一个事情，两个并不相关的功能不要嵌入另一个脚本，否则出现问题的时候，不好更改不好优化 解决方式首先分析ceph自身的启动方式 ceph的启动方式是通过去enable的一个service的方式这个enable会传入参数，osd的id和osd的fsid，这两个都

场景A机器能够联通内网机器，B机器能够联通A机器，但是访问不到内网机器，场景是希望通过A机器能够转发直接联通局域网内的其它机器 机器IP内网为172.0.0.x/24 A机器为172.0.0.10/24 A机器为192.168.1.10/24 B机器IP为192.168.1.20/24 进行设置在A机器上进行设置 1234567891011121314151

引言ceph自从到了L版本以后，L版本的启用，对性能本身有了极大的提高，一直对这个比较不放心的就是内存的占用，刚开始的时候记得大量dd就可以把内存搞崩掉，这个应该是内部的设计逻辑需要更多的内存的占用 最近在做ARM版本的服务器的测试，机器为36盘位的机器，内存需要自然多，但是36盘位的机器，按之前想法是4G预留，那得需要144G内存了，这个还没有算迁移的时候的内存消耗，而很多时候，我们并不需要速度

前言在做一个管理平台的时候，面向客户的最开始的第一步就是管理平台的登陆系统，而由于面向的是企业用户，内网用户，因此，往往有很多我们预想不到的情况出现，而这些都会去影响着管理平台的体验，或者会完全中断掉你的操作 这里在分析一些做的比较好的平台后，以及结合我们自身可能遇到的情况，对登陆系统进行一个新的设计，这个是通用的设计并不针对某款产品 范例zabbix的登陆系统是做的比较好的，我们先来看看，然后再

前言邮箱系统在提供了用户名和密码以后可以发送邮件，而在发送之前我们有个需求是需要验证下这个密码是不是正确的，本篇的内容就是用python默认的库来检测邮箱是不是可以登录的 验证这个采用的是python默认带的库smtplib，是一个发送邮件的库，脚本文件如下 123456789101112131415161718192021222324252627282930313233343536373839#

前言服务器的服务做HA有很多种方式，其中有一种就是是用CTDB，之前这个是独立的软件来做HA的，现在已经跟着SAMBA主线里面了，也就是跟着samba发行包一起发行 之前CTDB的模式是需要有一个共享文件系统，并且在这个共享文件系统里面所有的节点都去访问同一个文件，会有一个Master会获得这个文件的锁 在cephfs的使用场景中可以用cephfs的目录作为这个锁文件的路径，这个有个问题就是一旦有

需求描述在某些测试场景下面，需要满足能够拔盘以后在插入的时候能够自动上线磁盘，这个需求实际在生产中是不建议使用的，原因是插入的磁盘如果本身存在问题，那么拉起的操作可能会破坏了本身集群的稳定性，所以这个算是一个测试相关的功能，但是做这个功能的前提是我们不要去影响了正常的环境的逻辑 类似的功能的开发都是应该去在外面做触发的也就是能够很方便的开启和关闭功能，整个功能也是集成到原来的环境当中的，原来怎么用