在业务系统上云的过程中, 业务部署的高可用和容灾是一个要考虑的关键因素. 如今很多系统都采用分布式的架构, 从架构层面避免单点故障. 分布式系统中, 任意一个节点故障, 其他节点可以快速接管业务, 避免整个业务系统宕机. 这就对 IaaS 层资源提出了要求, 即单节点故障, 不影响其他节点. 由于公有云是一个多租户的环境, 一台物理机上会运行多个虚拟机, 如果分布式系统的多个虚拟机落到了同一台物理机上, 当物理机发生故障时, 多个分布式节点同时故障, 就有可能造成整个系统宕机. 那么在公有云的 IaaS 层, 如何才能保证分布式系统部署的高可用呢? 使用腾讯云的分散置放群组可以解决这个问题.
本文从如下几个方面介绍置了分散置放群组:
什么是分散置放群组;
分散置放群组的应用场景;
分散置放群组的使用方法;
分散置放群组的使用限制;
总结
阅读本文大概需要 10 分钟.
1. 什么是分散置放群组
分散置放群组是云主机 (CVM) 实例在底层硬件上分布放置的策略, 在置放群组中创建的实例在启动时就具备容灾性和高可用性. 腾讯云云服务器提供实例置放策略, 可在创建时将实例以某种策略强制打散, 以降低底层硬件 / 软件故障给云服务器上业务带来的影响. 用户可以使用置放群组将业务涉及到的 CVM 实例分散部署在不同的物理服务器上, 以此保证业务的高可用性和底层容灾能力. 在置放群组内创建实例时, 腾讯云会根据用户事先设置的部署策略在指定地域下分散启动实例. 如果您没有为实例设定置放群组, 腾讯云则会尽可能在不同的物理机上启动实例, 保障服务可用性.
分散置放群组支持 3 个级别的打散策略:
a. host 物理机级别, 在一个置放群组里的 CVM 不会 落在同一个底层物理机上, 可能会落在同一个机架上的物理机上, 也可能落在不同机架的物理机上, 仅保障落在不同的物理机上;
图 1
b. 交换机级别, 在同一个置放群组下的 CVM 实例会落在不同的物理交换机下;
图 2
c. 机架级别, 在同一个放置群组下的 CVM 实例会落在不同的机架上.
图 3
不同级别的打散策略提供不同的分散放置策略. 打散策略约严格, 对底层资源的要求更高, 应该根据实际业务需求, 选择合适的打散策略, 不要过度设计(overdesign), 一味的追求打散, 避免分散置放群组给业务部署带来麻烦.
2. 分散置放群组的应用场景
分散置放群组使用适用于主从数据库, 高可用集群的搭建. 下面以常见的几个集群场景看看如何使用分散置放群组实现高可用部署.
2.1 数据库主从集群搭建
强烈建议用户使用腾讯云 CDB for MySQL. CDB for MySQL 底层基于 NvMe SSD 本地磁盘, 具备超高性能. 默认高可用, 主备节点跨机柜容灾.
以 MySQL 为例, 为了保障数据库的高可用, 需要搭建主从节点. 主从节点使用不同的云主机, 主节点出现故障时, 可以快速切换到备节点.
图 4
如上图所示, MySQL 的主备节点都在 AZ1, 在 AZ2 中也有一个从节点. 由于公有云是多租户共享资源池的模式, 默认情况下, AZ1 中的主节点 CVM, 和备节点 CVM 有可能落到同一台物理机上, 也有可能落到同一个机架上. 如果出现这种情况, 如果物理机出现故障, MySQL 的主备节点都将被影响, 导致数据库不可用, 或切换到远端的 AZ2 上. 切换到远端的 AZ2 上虽然可以保证可用性, 但是跨 AZ 的延迟明显高于同 AZ 的延迟. 因此我们在架构设计上要尽量的保障 AZ1 的主从节点落到不同的物理机机柜上. 如下图所示:
图 5
置放群组 1 选择跨机架容灾, 那么创建的两台 CVM 实例会分散到不同的机架上, 满足机架级别容灾需求.
在很多场景下, MySQL 会有一主多从的架构. 从库作为只读库, 开放给程序读写. 只读从库的容灾需求要比主备的容灾需求低一些, 可以使用 host 级别的置放群组满足. 如下图所示
host 级别的置放群组会确保主从节点分散到不同的物理机上, 保障实例的高可用.
这里可能有人会问, 为什么不能所有的主从都使用机架级的容灾呢?
理论上都可以全部使用机架级别容灾, 更安全可靠. 但是机架级的容灾对资源的要求更高. 以一主 5 从的架构来说, 如果全部使用机架级容灾, 需要资源分布到 6 个机架上. 每个机架上, 需要有满足某一个型号的 CVM 资源. 这一点在公有云上很难做资源保障. 如果没有满足需求的资源, 创建 CVM 会失败. 而满足跨物理机容灾的资源相对多一些. 所以建议使用机架级别的容灾满足最基础, 最核心的容灾需求.
图 6
同样的场景适用于 Redis,MongoDB 等数据库场景.
自建 MySQL 还涉及到 CVM 机型的选择, 磁盘类型的选择, 本文将不做深入讨论. 还是建议使用腾讯云 CDB for MySQL.
2.2 ZooKeeper
Zookeeper 作为一个分布式的服务框架, 主要用来解决分布式集群中应用系统的一致性问题, 它能提供基于类似于文件系统的目录节点树方式的数据存储. zookeeper 作为分布式协调系统, 往往是一个业务系统的核心, 很多组件都会依赖它, 那么保障它的可用性就非常重要了. ZooKeeper 的部署架构如下:
图 7
以 3 节点的 zookeeper 为例, 可以采用如下部署方式.
图 8
如果 zookeeper 中有很多节点, 其余节点可以采用 host 级别的置放组实现.
同样的部署方式也适用于 etcd,consul 的部署架构.
2.3 Hadoop 高可用集群
使用云主机自建 Hadoop 高可用集群, 会涉及到 Namenode 的高可用, 和 Zookeeper 的高可用. 高可用 Hadoop 集群的高可用架构如下:
图 9
Zookeeper 的高可用在 2.2 节中已经讨论过. 2 台 Namenode 节点的高可用建议使用机架级别的分散置放群组实现.
图 10
2.4 Kubernates 集群的 master 节点
在搭建 Kubernates 集群时, 为了实现高可用架构, 一般会采用三节点的 Master. 腾讯云的 TKE 服务支持跨可用区的 Master 节点, 做到跨可用区容灾. 如果采用自建 Kubernates 集群时, 并且有多个 Master 节点, 并且有 Master 可能会落到同一个可用区时, 可以使用分散置放群组的方式创建 Master 节点.
2.5 不适合使用分散放置群组的场景
分散放置群组虽然可以解决高可用的问题, 但是它本身也有一定的使用限制:
物理机每个置放群组每个地域最多可以有 50 个实例
交换机每个置放群组每个地域最多可以有 20 个实例
机架每个置放群组每个地域最多可以有 30 个实例
所以并不是所有的场景都适合使用分散置放群组.
例如: web 类的应用. Web 类的应用一般服务器数量会比较多, 这些服务器落到同一个物理机或机架的概率非常小. 并且 Web 类的服务器会放到负载均衡下面, 负载均衡本身会有故障剔除机制, 单台 webserver 或几台 Web server 并不会对应用产生特别大的影响. 所以这类应用不适合使用置放群组.
3. 分散置放群组的使用方法
3.1 通过腾讯云控制台使用分散置放群组
使用控制台创建云主机时, 在高级选项里可以使用分散放置群组
图 11
3.2 通过 API 操作分散置放群组
腾讯云的 API explorer 提供了可视化的 API 操作示例, 可以快速生成代码.
创建分散置放群组
图 12
创建 CVM 实例的时候, 指定分散置放群组:
图 13
4. 分散放置群组的使用限制
在使用分散置放群组之前, 请注意以下规则:
不能合并置放群组.
一次可在一个置放群组中启动一个实例.
实例不能跨多个置放群组.
对于已有实例, 目前不支持自助加入置放群组.
可选择分散置放层级: 物理机, 交换机, 机架三个层级.
不同置放层级的群组最多支持实例不同, 具体数值视官网页面为准.
使用容灾组策略后, 会严格遵守您指定的策略. 特别注意的是, 如底层硬件不足够使实例分散, 部分实例将创建失败.
专用宿主机上实例不支持分散置放群组.
详细参考官网文档
5. 总结
在进行高可用业务设计时, 对一些关键业务系统需要做到容灾, 腾讯云置放群组通过将 CVM 打散到不同的物理机, 交换机, 机架上, 从 IaaS 层保障业务的容灾需求.
来源: https://www.qcloud.com/developer/article/1446212