从传统运维到云运维演进历程之软件定义存储中

Posted 2020-08-24

上篇文章主要讲了常见的几种数据保护方式，本文我们主要讲下Ceph有哪些常见的灾备设计方式。Ceph在灾备方面有三大神兵利器：故障域、RBD异地灾备、RGW异地灾备。

关卡五：Ceph灾备神兵利器-故障域

重要度：五颗星

转眼六篇文章过去了，还记得大明湖畔（本系列一）的运维小哥吗？勿忘初心，咱们还是回到最初的运维小哥，运维小哥经历了硬件选型、部署、调优、测试的一系列转型的关卡，终于就要到最后的上线了。但是往往在生产环境的要求都是无单点、高可用的架构设计，避免出现灾难故障影响业务正常运行。运维小哥最初的梦想搭建一个Ceph存储集群，对接云服务，底层存储实现高可用的数据访问架构。在正式上线之前，需要将集群架构部署好，并对存储集群进行服务器断电、机架断电等数据高可用测试，这时候就需要Ceph灾备神器【故障域】。现有24台服务器，用于搭建Ceph存储集群。

根据存储管理平台的需求和集群规模，需要实现：

将物理环境按高可用的拓扑架构规划好，并且完成存储集群部署。实现存储资源的统一管理，在降低存储管理难度的同时，提高管理效率；通过软件定义存储保证存储数据的高可用，从而经济地利用存储资源提高业务连续性；

根据现有物理资源规格及配置，在保证最大安全性及空间利用率的情况下合理规划存储资源池。将24台服务器分别规划在3个机架上，每个机架8台服务器，每个机架设置为一个故障域，创建一个3副本存储资源池，数据副本自动分布到不同故障域中，也是分布在不同机架上，保障数据安全。可以为机架、服务器、硬盘提供故障恢复能力。无论磁盘、服务器发生硬件故障，甚至整个机架发生故障，也不会造成停机或数据丢失。这与Ceph的自身设计Crush Map以及rule set有关，后面会具体讲述。

物理拓扑规划：每个机架相当于1个故障域，向每个机架分配相同数量、具有统一配置的主机。将24台服务器平均的分配到3个机架中，每个机架中8台服务器。

拓扑图

注：我这里说的1个机架相当于1个故障域并不代表只能这样做，要根据自己实际情况来规划故障域和Crush Map。

技术实现

Crush Map包含集群里所有存储设备的列表，和一些组织这些设备形成物理层级架构的Buckets，以及一套指定复制数据策略的规则。Buckets分不同的类型，高层级的Buckets可以聚合低层级的Buckets。比如一个典型的Bucket层级为OSD, Host, Rack, Row, Room, DC, Root。对于由这些buckets类型组成的一张Crush Map，其结构如下图所示，形成一棵树形结构。对于某种类型的Bucket，Crush算法可以将数据及其副本放置于该类型的不同的Bucket中，形成故障域。即使该故障域中有任何设备损坏，数据也是安全和可用的，从而来避免单点故障。

如果将Bucket跟集群物理架构映射得当的话，Crush Map可以很好的用来定位集群内的物理设备问题。比如，如果集群里有个OSD对应的硬盘坏了，可以从Crush Map中很容易的定位其物理位置，从而可以快速的进行更换。又比如，如果在Crush Map中看到一个host下面的所有OSDs全部down了，则可能的问题会出现在这个host电源断了或者是网络断了，而不会是在OSD自身身上。

Bucket除了有类型之外，还有权重。可以为最低层级的Bucket，比如OSD，定义一个权重。根据Bucket层级的树形结构，高层级的Bucket的权重则为其下面所有子树层级的权重之和。OSD上的权重代表了该OSD上存储数据的比重。如果为0，其上将不会存储任何数据。而如果一个OSD的权重为1，而另一个为2的话，第一个OSD上存储的数据量将只会有第二个OSD上数据量的一半。权重可以用来代表一个OSD对应的物理磁盘的真实容量。它还可以被用来减轻一个OSD上的负载。

具体的Crush Map操作查看官网：http://docs.ceph.com/docs/master/rados/operations/crush-map/?highlight=crushmap

 

总结

为保证存储数据的高可用，需要在前期做好集群部署规划。将同一个机架上服务器组成一个故障域，将数据副本分布存储在不同的故障域中，可以确保无论磁盘、服务器发生硬件故障，甚至整个机架出故障，也不会造成停机或数据丢失。

希望本关卡能够给予Ceph新手参考，请读者见仁见智，预知后事如何，请期待《 架构灾备设计》。

本文出自 “态度决定一切” 博客，请务必保留此出处http://sangh.blog.51cto.com/6892345/1884396