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)特点
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 样式的完整的系统。
参考链接
- https://www.mirantis.com/blog/a-dash-of-saltstack-using-salt-for-better-openstack-kubernetes-and-cloud/
- https://docs.mirantis.com/mcp/1.0/