EC-ONE 云平台高可靠的实现

EC-ONE平台是基于开源OpenStack深度定制的私有云管理软件。原生的OpenStack + KVM构建的私有云从架构设计、扩展性、模块的丰富程度都非常理想化，社区的主要贡献者都是以技术框架来考虑产品设计而并非应用如何落地。由于这些社区的特性决定了OpenStack平台将缺失部分云平台产品落地应有的一些常用功能，其中最常被系统管理员提到的是资源调度和高可靠功能。以主流的VMware产品为例，如vMotion、Storage vMotion、HA、DRS等功能深入人心。考虑到运维人员已经习惯了通过上述方式进行日常的运维管理，因此在EC-ONE产品功能设计之初，就决定在我们的OpenStack平台中实现类似的功能。

VMware Stroage vMotion VS EC-ONE Ceph

Storage vMotion是存储集群根据空间和存储IO延时来自动安置虚拟机磁盘文件，即基于磁盘空间和存储的性能进行磁盘均衡负载。EC-ONE平台采用了分布式存储解决了这个问题，分布式存储本身是一个集群化的存储资源池，所有虚拟机文件和挂载卷被均匀切割（默认4MB），通过多副本方式均匀分布在集群内，因此从根本上杜绝了集群中的某个存储节点因空间不足或存储IO成为超级热点，除此之外分布式存储还提供了传统存储无法提供的灵活性和扩展性。

社区HA 解决方案 VS EC-ONE HA解决方案

对于OpenStack平台运维人员来说，最迫切的需求之一是虚拟机层面的HA功能。当承载VM的物理设备发生故障时，VM可在集群内的其它节点上自动重启。对此需求OpenStack社区只提供了通过evacuate接口手动实现，故障主机上的虚拟机无法在其他机器上自动重启。社区解释是“应当由OpenStack上层组件实现HA，OpenStack核心模块仅提供基本的操作。”社区希望通过Heat实现在设备故障时，社区认为用户需要的是虚拟上Service的恢复而非虚拟机本身的HA。对于无状态应用，Heat通过删除原有虚拟机，然后重新创建也许适合的，但是如果是数据库之类的有状态应用Heat是无法保证数据一致性的。针对此问题，我们的理解是作为开源项目的OpenStack不提供HA情有可原，但作为要落地的产品实现HA是必不可缺的功能。因此我们在构建EC-ONE，实现了虚拟机HA功能，确保在主机故障时虚拟机可在其他节点自动重启。

DRS VS Hot Spot Monitor

DRS是VMware平台中设计最复杂的功能，也是vSphere产品的核心部分，DRS在生命周期内通过对虚拟机的关键指标的监控，根据策略确定是否将虚拟机迁移至合适的物理主机，在资源超分的情况下，DRS起了很好的作用。但是看似完美的方案在实际应用场景中是往往带来很多问题，如：

• 计划内的负载突然增高

管理员知道在未来一段时间将会虚拟机将会发生负载变化，但又不想触发虚拟机自动迁移导致业务的中断，在启用DRS功能后将无法得到有效控制。

• 虚拟机的复杂性

在资源池内虚拟机的配置和负载存在的巨大差异，如配置特别高的虚拟机和配置特别低的虚拟机，计算密集型和磁盘密集型等。这些复杂的集群在配置DRS策略时很难做出最优方案，自动迁移往往会增加系统运维管理的复杂度。

• 虚拟机关联性

在OpenStack使用SDN的场景下，相关联的虚拟机在相同的主机内将进行交 互将有效降低网络负载，DRS触发的自动迁移将导致相关联的虚拟机迁移至不同的主机上，造成了Neutron网络管理节点负载的增加。

介于此，EC-ONE设计的热点监控（Hot Spot Monitor）和迁移助手（Migration Assistant）功能，当主机负载超过阈值时，热点监控将提示管理员热点主机的负载，并列出集群内负载相对低、适合虚拟机迁移的目标主机群。管理员会根据运维经验和实际情况，选择迁移的目标主机。这样从很大程度上避免虚拟机频繁的自动迁移，尤其是在私有云环境中资源没有超分的情况下，虚拟机是否迁移应当有管理员根据实际情况而定，频繁的系统迁移只会带来系统的不稳定。

• 想了解更多技术干货，请持续关注休伦科技官方微信平台，或休伦官网www.hihuron.com