1.前言
Mirantis 公司在2014年9月14日宣布收购 TCPCloud，然后宣布在2017年第一季度会推出全新的私有云产品。从那时候开始，我就一直满怀期待。终于，今年4月19日，Mirantis 宣布推出全新的 MCP 1.0。本文根据公开的文档，试着对该产品做些分析和总结，并且展望一下其未来。因为只是看文档和视频，并没有进行实际部署和操作，因此，可能有一些错误。本文会持续进行更新。
2. MCP 1.0 概况
2.1 MCP 1.0 的组成
MCP 1.0 主要包括三大部分：
- DriveTrain：即部署和变更系统，用于整个平台的部署（Day 1）和部署后的变更（Day 2）。
- 云系统：包括支持物理机和虚机的 OpenStack，支持容器的 Kubernetes，分布式块和对象存储 Ceph，面向 OpenStack 集群的SDN OpenContrail，面向 Kubernetes 的 SDN Calico。
- StackLight：即日志、监控和告警系统，为云平台提供运维支持。
2.2 设计出发点
Mirantis 设计 MCP 1.0 的出发点包括但不限于：
- 基础架构的消费模式是由公有云定义的，它的主要特征包括 API 驱动（API driven）、持续交付（continuously delivered）和托管模式（managed）。因此，MCP 1.0 就由之前的以安装为中心的架构（installer-centric architecture）变为以运维为中心的架构（operations-centric architecture）。
- 面向各种工作负载的统一云平台，包括为迁移到云上的传统应用（cloud hosted）提供虚机和裸机；为已经为云做过优化的应用（cloud optimized）提供虚机；为云原生应用（cloud native）提供虚机和容器。
- 变更不再以6到12个月为周期，而是以周为周期进行小迭代（minor increments）而持续发生。
3. MCP 1.0 具体
下面具体分析 MCP 1.0 中的具体组件。
3.1 DriveTrain
3.1.1 概况
（1）理念：Infrasture-as-code 基础架构即代码，将基础架构代码化。
（2）目标：支持 Day 1 定制化安装和 Day 2 部署后配置，包括功能和架构变更。
（3）方法：采用 CI/CD 工具和流程，实现 DevOps 模式。
（4）支持：当前支持 OpenStack 集群和 Kubernets 集群，将来会增加更多集群支持。
（5）界面：DriveTrain 的界面集成在 DevOps 界面中。
3.1.2 组件
DriveTrain 是 DevOps 形式的云平台部署和配置系统。它主要包括以下生命周期管理工具：
- SaltStack + Reclass：SlatStack 类似Puppet 和 Chef，提供配置管理和 MCP 集群的部署和变更；Reclass 结合 SaltStack 使用。
- Gerrit：提供 Git 库和代码检视管理系统，保存源代码、SaltStack 程序（formulas）、Reclass 模型（models）。
- Jenkins：job 自动化工具。它检测提交到 Gerrit 的针对 MCP 集群配置的变化，然后通过执行一系列 jobs，将相应的 SaltStack 程序和Reclass 模型应用到 MCP 集群。
- MCP Registry：保存 MCP 集群所需的软件库，比如 Docker 镜像、Debian 包等。
3.1.3 部署
要部署DriveTrain，至少需要3个虚机。它的组件运行在由 Docker Swarm 管理的容器之中。
- 使用三节点 Docker Swarm 部署模式，每个 DriveTrain 组件运行在 Docker Swarm 容器中，确保提供高可用的服务。（mysql 如何运行在容器中，没有具体说明）
- 使用 GlusterFS 共享文件系统作为共享存储
- 使用 Keepalived 对各个 service 提供 HA VIP
- 使用 nginx 提供公网访问能力
3.1.4 CI/CD 流程
- 当运维人员要进行 MCP 部署或者变更时，他首先在 Gerrit 中提交 SaltStack 程序 或者 Reclass 模型的代码检视申请。
- 代码检视结束后，根据配置的不同（有没有staging环境），触发Jenkins 相应的变更 job。
- Jenkins job 从 Jenkins 中获取SaltStack 程序 或者 Reclass 模型的代码，以及从 MCP 库中获取二进制文件。
- SaltStack 将更改应用到 MCP 集群
3.1.5 简单分析
与Mirantis之前的 Fuel 做比较，
- Fuel 使用 Puppet 来做配置管理，现在改为使用 SlatStack，应该是吸收了 TCPCloud 的成果。在 Github 上有看到有大量的 TCPCloud 写的 Slat 程序，比如 https://github.com/tcpcloud。
- Fuel 主要是在 Day 1 部署，而 DriveTrain 则 Day 1 部署和 Day 2 变更并重。当然，现在的 Day 2 变更主要还只是做一些小的变更，比如安全补丁之类的。但是，长期看，两者都是必须的。
- 客户有了 DriveTrain 并接受了培训之后，就可以自动地进行变更了，这为 Mirantis 推行新的 build-operate-transfer 交付模式提供了产品基础。
3.2 MCP 集群
MCP 1.0 支持 OpenStack 集群和 Kubernetes 集群。
3.2.1 OpenStack 集群
一个部署实例：
MCP OpenStack 集群的特点：
- 采用 DriveTrain 进行部署和变更
- 使用 StackLight 作为 LMA（Logging, Metering, Alerting） 系统
- 每个组件使用多个分布在不同物理服务器上的虚机来实现高可用
- SDN 支持 OpenContrail 或者 Neutron OVS，前者是推荐配置
- 推荐采用 Ceph 做块和对象存储。
- 支持多种 OpenStack 服务，支持物理机和虚机：
-
3.2.2 Kubernetes 集群
MCP 1.0 支持单独部署一个 K8S 集群，也支持在 OpenStack 集群旁边部署一个 K8S 集群。一个部署示例如下：
特点：
- K8S 集群和 OpenStack 集群目前没有关联。
- 采用 Calico 作为SDN。使用 OpenContrail 处于 technical preview 状态，也就是测试可用，但生产别用。
- 采用 Ceph 提供卷。
- 采用 DriveTrain 进行集群部署和变更。
- 典型地，K8S 集群会部署在裸金属服务器上。MCP 采用基于 Ironic 的 MaaS 组件来准备物理环境。
3.2.3 简单分析
- MCP 中的 OpenStack 和 K8S 集群目前是独立的，两者之间没有关联
- OpenStack 和 K8S 集群使用同一的部署和配置工具 DriveTrain，以及 LMA 工具 StackLight。
- Mirantis 强调 100% 开源。
3.3 StackLight
MCP StackLight 是 Mirantis 的日志（收集、分析、可视化）、监控（包括设备，服务，和租户资源等）和告警系统。
3.3.1 功能汇总
3.3.2 总体架构
3.3.2 日志（logging）
（1）日志收集目标包括：
（2）特点
- 采用 Heka 作为日志收集器。它被安装在MCP集群的每个节点上，负责收集这些节点上的日志。
- 采用 ElasticSearch 作为日志存储
- 使用 Kabana 作可视化
3.3.3 监控 （Metering）
特点：
- 包括云物理环境监控和租户环境监控。
- 租户资源监控基于 Ceilometer。它将监控指标数据保存在 InfluxDB 中，将资源数据保存在 Elasticsearch 中。
- 采用 InfluxDB 时间序列数据库保存监控数据
- 采用 Grafana 作为可视化
3.3.4 告警（Altering）
特点：
- 采用 Sensu 和 Uchiwa，支持集群
- 支持通过标准协议将告警导向第三方系统
3.4 DevOps Portal
MCP 1.0 还提供了处于技术预览状态的 DevOps 界面。它是 MCP 管理员的主要入口。它的主要内容有：
- 通过各种图标和状态等展示云环境的各种信息
- 提供链接到其它工具的链接，包括 Grafana，Kibana 和 Rundeck等。
3.4.1 架构
3.4.2 Cloud Intelligence Service （CIS，云智能服务）
CIS 包括一系列用于收集系统信息的收集器（collectors），包括 OpenStack 集群和MaaS 等等。CIS 保存这些信息，跟踪它们的变化，并进行分类。CIS 会查询各种服务的API，并且连接到特定的数据库去加速数据收集。尽管 CIS 的搜索功能很强大，但是它不能修改任何资源。
Runbooks 每隔5分钟会运行这些收集器去收集各种信息，并保存到 ElasticSearch 中。
3.4.3 Cloud Health Service 服务（CHS，云状态服务）
CHS 也包括一组收集器，它们通过各种资源的通知来提供云的状态概要，包括网络、存储、计算节点等。这些结果会被展示在 DevOps 界面中。
Runbook 会执行 FCI，API 测试，并将数据保存在 LMA 中。DevOps 界面查询 LMA，创建云状态的各种图表。云管理员监控这些图表。
3.4.4 Runbook 后端和UI
Runbooks Auotmation 是一个自动化服务。用户可以在其UI中创建工作流任务，这些任务会被定时或者周期性执行。其它 OSS 组件会使用 Runbooks 服务来自动化执行这些任务，比如创建备份、监控数据查询、生成报表、云维护等等。Runbooks 是有 Rundeck 工具提供的，它使得用户可以方便地添加 Rundeck 任务，并将它们嵌入工作流。 Jenkins 和 SaltStack 主要用于部署和生命周期管理，Rundeck 则会帮助用户执行每天的运维和维护任务。
3.4.5 Capacity Management Serice （CMS， 容量管理服务）
CMS 服务利用LMA 和 CIS 产生的数据，提供多个界面来显示云中的资源使用情况。它的内容包括：
- 按照可用区（AZ）分组的计算节点的 CPU 和内存利用率
- 在用内存容量
- 在用存储容量
- 计算节点总数
它的部分界面会集成到Horizon 中：
3.5 多集群支持
3.5.1 DriveTrain 能支持多集群
一套包含 SlatStack 和 Reclass 的 DriveTrain 环境能支持多集群的配置：
- 一个 Service class 定义MCP 集群中的一个组件（component），比如 RabbitMQ，MySql 等。Service class 定义为 SlatStack 程序。
- 一个 System class 定义 MCP 集群中的一个节点（node），比如控制节点和计算节点，以及部署在节点上的 service。
- 一个 Cluster class 定义一个 MCP 集群，比如一个 demo OpenStack 集群，一个生产 K8S 集群等。一个 cluster class 组合多个 system classes。
通过 DriveTrain 的 CI/CD 流程，管理员就可以定义、部署、维护多个 MCP 云环境。
3.5.2 StackLight 能支持多集群
4. 总结和展望
4.1 总结
根据上面的信息，对 Mirantis MCP 1.0 做个简单的总结：
- 产品化思路非常直接：将合适用户工作负载的云环境（当前是OpenStack环境和K8S环境）通过好用的部署和变更工具（DriveTrain）和 LMA 系统（StackLight）提供给用户，使得这个产品既能解决业务需要，又好用。
- OpenStack 地位确定：由神化（无所不能）回到人间（支持物理机和虚机），在整个 Mirantis 私有云产品中的分量由之前的 100% 下降到当前的 60%，将来应该会进一步下降。
- OpenStack 功能得到聚焦：MCP 1.0 使用 Salt 而不是 OpenStack 自带的 Magnum 项目来编排 K8S 集群，显示出 Mirantis 有将 OpenStack 功能收缩到核心组件的趋势，这应该和 Mirantis 减少 OpenStack 研发人员同时TCPCloud 团队有非常强大的 SaltStack 能力有一定关系。
- K8S 地位清晰：即定位在 CAAS 平台。它既不能取代OpenStack，也不是 PAAS，而是在其该在的 CAAS 位置。
- 强调 Day 2 （部署后运维），推行 CI/CD 模式的自动化运维平台。
- 强调 LMA （日志-监控-告警），并强调事前分析告警。
4.2 展望
如本文标题，MCP 1.0 只是 Mirantis 新私有云产品的第一个版本，还处于 OpenStack 和 K8S 整合的第一步。不负责任地预测，将来 MCP 会：
（1）通过 OpenContrail 将 K8S 和 OpenStack 做进一步的整合，打通 物理机-虚机-容器 的网络。这方面之前 TCPCloud 已经有了很多的尝试，相信将来会进一步利用起来。
这是 TCPCloud 之前放的一篇文章：
这是 Mirantis 在今年波士顿OpenStack 峰会上的展示，它将大数据不同的组件作为不同的工作负载运行在不同的环境中，在使用 OpenContrail 作为统一的 SDN：
（2）进一步拓宽云产品栈，OpenStack 的分量会进一步下降，也许会到 30% 左右。
通过 DriveTrain 和 StackLight 支持更多的云产品，比如大数据、AI 等云技术栈。相信 Mirantis 也不会限于 OpenStack 和 K8S，而是会选择更多的开源云产品。我们也许会看到 Mirantis 参与到更多的开源云项目中。
（3）用户体验（UI）的进一步优化，包括 DriveTrain UI， StackLight UI，DevOps 界面等的增强，以及多个界面之间的整合。
（4）DriveTrain 功能的进一步丰富。当前它更多的只能支持 Day 1 部署，将来会在 Day 2 部署后变更方面做增强，使它真正成为 DevOps 样式的完整的系统。
参考链接