Openshift的高可用架构设计

第一部分：高可用设计

一、Openshift架构

Openshift架构如上图，其核心组件有：

●Multiple Masters

●External etcd

●Routers

●Registry

●Logging

●Metrics

在PoC环境中，我们安装Openshift的时候，可以用一个服务器或者虚拟机，搭建成All in One的模式。也可以配置成1个Master，1-2个node，如笔者的测试环境：

在生产环境中，我们就需要考虑Openshift的高可用。接下来，我们看看Openshift的各个组件如何实现高可用。

一、入口流量的负载均衡

在Openshift中，两个重要的流量入口组件是Master和Router。

在生产环境中，为了保证高可用，Master和Router都会配置多个。这就引入了一个问题：多个Master和Router对外如何提供统一的域名。

这时候，需要使用客户数据中心/公有云的负载均衡。当然，在数据中心内，我们也可以通过Haproxy搭建软负载，这和使用F5的设备无本质区别。

在考虑流量入口的负载均衡的同时，我们还需要考虑DNS的问题。当然，商业的F5通常有DNS的功能。

针对Master,多个Master会有一个VIP/域名。VIP和多个Master都需要被DNS解析。在负载均衡器上，将Master VIP的域名（如master.ocp.example.com）和多个Master的域名对应起来，同时设置负载均衡策略，如roundrobin等。

针对Router, DNS需要将应用对外的域名，解析成router所在的openshift节点的域名。如果有多个router，就需要个多个router配置VIP和它的域名。VIP被解析成多个router所在的Openshift节点的域名（同时配置负载均衡策略）。而DNS上进行配置，对应用对泛域名解析，将其解析成router的VIP。

二、etcd的高可用

在Openshift中，etcd做服务发现，其K-V数据库存放Openshift的信息。

为了保证etcd的高可用，在生产环境中，etcd应配置成奇数个（2n+1），并且每个etcd成员之间的网络延迟小于5ms。

在Openshift中，建议将etcd与Master节点部署到一起。也就是三个master上，每个master上一个etcd。

三、日志和监控数据的高可用

目前Openshift的日志使用EFK，具体概念不展开讲，请参照其他文档。

在EFK中，Elasticsearch需要高可用，和etcd一样，需要2n+1个节点，以保证高可用并规避脑裂。

在Openshift的监控数据中，Cassandra分布式数据库存放监控信息，因此需要做高可用。在多个Cassandra之间，做存储的复制。

四、集成镜像仓库INTEGRATED REGISTRY

在Openshift中，集成镜像仓库通常用于存放dev成功后的镜像，以完成整个CI/CD过程。他与数据中心外部镜像仓库是分开的，作用也不一样。

在生产环境中，INTEGRATED REGISTRY通常会被配置成多个。

同样，需要给多个REGISTRY配置VIP和域名。多个REGISTRY的VIP通过负载均衡器的roundrbin指向多个registery。

五、一个典型的Openshift高可用集群

根据以上的高可用原则，master至少应为三个，且为奇数个（上面有etcd）。

基础架构节点有三个，上面运行日志、监控、router、INTEGRATED REGISTRY。

Openshift的计算节点至少应有2个，以保证当一个节点出现故障的时候，不影响应用。

这样，当Openshift计算资源不够的时候，增加计算节点即可，不必对Master和基础架构节点进行变动。

六、多Openshift集群设计

Openshift在多数据中心上部署的时候，有两种模式：SEPARATE CLUSTERS和STRETCH CLUSTER。

前者就是比较典型的，在多个数据中心独立部署多个Openshft集群。

后者指的是一个Openshift集群跨数据中心部署。这种模式对环境要求较高，并不是推荐的做法。

在实际环境只能怪，CI/CD至少应包含dev、pro两个阶段。有的客户还包含SIT、UAT阶段。但整体上讲，是包含非生产环境、生产环境。

生产环境的架构设置，上面已经提到了即典型的3（Master）+3（Infrastructure）架构。

但在非生产环境，架构可以适当简练一些，如将Infrastructure和Master合并；或者配置一个Master、一个Infrastructure即可。当然，这需要结合用户的具体SLA要求，没有固定模式。

用户在通过Openshift构建CI/CD的时候，通常将dev和pro分开到两个Openshift集群上，甚至将两个集群部署到两个DC中。

这就牵扯到两个问题：

1.应用如何跨数据中心部署

2.镜像如何跨数据中心管理。

针对于第一点，openshift可以通过templates实现跨数据中心部署。

针对第二点，我们有两个方法实现跨数据中心镜像管理。

在dev阶段，其成功的输出物是bc成功的应用镜像，然后push到INTEGRATED REGISTRY中，然后这个镜像需要推送到生产环境，执行dc。推送的方法有两个：

1.通过手动从dev环境的INTEGRATED REGISTRY推送到生产环境的INTEGRATED REGISTRY中，然后执行dc，部署应用。这其实是调用docker pull， docker push的命令

这种方法比较简单，但有一些限制：

用户需要在系统上安装docker。

docker守护进程需要在系统上启动。

docker守护进程使用特权运行。

2.借助于一些复制工具，如Skopeo，实现镜像的拷贝（实现从一个集成镜像仓库到另外一个集成经常仓库的拷贝）。skopeo 的一个优点是它不需要任何守护进程的协助来完成任务，同时可以配置权限认证、签名等。

复制的时候，执行类似命令：

skopeo copy docker://internal.registry/myimage:latest /

docker://production.registry/myimage:v1.0

第二部分：灾备步骤

在考虑Openshift灾备的时候，我们应考虑两种灾难的发生：OPENSHIFT CONFIGURATIONS和STORAGE。

在拷贝灾备问题时候，应遵循如下流程：确认要备份的内容、定义备份流程、灾备演练。

Openshift的备份和恢复步骤如下：

（https://docs.openshift.com/container-platform/3.7/admin_guide/backup_restore.html）

本文只列出大致的步骤，项目步骤参考上面链接。

●Backup Master Configuration Folders 备份master节点的配置文件

○/etc/origin/master

●Backup etcd 备份etcd

○Using etcdctl tool

●Backup image registry certificates 备份镜像仓库证书

●Backup project configurations 备份项目配置

恢复：

●Rebuild etcd 重建etcd

●Restore remaining components 恢复其它组件