背景

公司有私有云需求，作为大型软件的测试环境，每个测试环境需要500+cpu和1.2TB+内存。目前已经采购了数千台的HP rack服务器。

需求

  • 压榨计算资源，有同样的资源创造越多的测试环境越好
  • 环境稳定，容灾好
  • 云上线后，OPEX一定要控制好

团队

一个资深云运维组，10人左右 一个研发组，10人左右

云设计

由于很多客户的云都是openstack。目前来说openstack也基本就是开源云的唯一选择。

  1. Pod的尺寸 为了防止单点和提高HA，大规模的云都是多套小的云部署组成。Redhat的咨询工程师建议是32台一个pod，3个controller和29个conpute nodes。我们也尝试了其他不同size的POD，最后看下来node越少越稳定，但是node越少，cloud虚拟化的意义就相对越小。权衡之后我们选择了32 nodes和64 nodes两种方案。在POD之上，再独立做一个多POD的云管理平台，用于管理tenancy，下沉运营运维数据和聚合资源。跨多POD或者说跨多云的管理平台市面上已经有很多，包括自己公司也有这个产品，但是几乎都偏向于tenancy管理，没有与自动化运维结合。Example，可以通过一个统一的平台在不用的POD里创建tenancy，但是没有关联tenancy相关的运维信息。当我给5个客户管理100个tenancies的时候，我需要一个功能 - 自动统计每个客户tenancies每个月总体的utilization，然后自动给客户联系人发utilization的report。目前市面的跨云管理平台比较generic，这种定制化的功能需要二次开发。

  2. Storage方案 很多公司都从物理机环境转到云，硬件都拿去复用来建造云。blade服务器，vnx和unity的储存都复用到云上。但实际上，vmx和unity都不适合于云上的应用部署，换句话说，传统的储存方案并不太合适大型cloud-native（或者说微服务）的app，尤其是在测试环境中需要频繁tear down和安装app。大型cloud-native动辄几百个instances（或container），volume一建就是5分钟内几百个，然后还要attach到instance上，这样的压力传统storage solution扛不住。Redhat的CEPH据说性能优秀，我们还在调研其他合适的储存方案。

  3. 容灾 一般来说，多POD云的容灾可以有两种途径

    1. 每个POD上留存一点buffer，当有一个POD宕掉的时候，把这个宕掉的POD里跑的东西自动调度到其他正常运行POD里的buffer处。
    2. 提高contention ratio，简单来说就是当一个POD挂了，就把上面跑的东西挤到其他正常运行的POD里。然后通过云运维平台去控制每个POD的实际容量。也就是说，在云的配置里，我设置的是云容量的最高上限，而云实际容量上限的控制是通过管理平台来控制的。 我通常会把cloud cpu的contention ratio设置得比较高- 8:1甚至16:1，RAM 最高到1.5 : 1，而在管理平台里，我会把contention ratio结合实际负载做动态调整，比如，cpu调到4:1， ram调到1.2:1
Buffer POD也可以是一种方案，但是不如POD里留存buffer灵活。

  1. pipeline Monitoring bootstrap -> auto intall -> configration -> integration test -> benchmark test -> Tunning ###TO-DO

  2. OPEX 人均运维设备CPU数，每日Churn，外包服务，7*24 ###TO-DO

后话

容器on baremental