Openshift的高可用架构设计

前言

本文仅为笔者的读书笔记,仅作为技术探讨和参考,不能作为Openshift生产部署的标准。本文仅代表笔者的个人观点。

第一部分:高可用设计

一、Openshift架构

Openshift架构如上图,其核心组件有:

●MultipleMasters

●Externaletcd

●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的功能。

针对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)

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

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

○/etc/origin/master

●Backup etcd 备份etcd

○Usingetcdctl tool

●Backupimage registry certificates 备份镜像仓库证书

●Backupproject configurations 备份项目配置

恢复:

●Rebuildetcd 重建etcd

●Restoreremaining components 恢复其它组件

大卫分享:

魏新宇

"大卫分享"运营者、红帽资深解决方案架构师

专注开源云计算、容器及自动化运维在金融行业的推广

拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、ITIL V3、Cobit5、C-STAR、AIX、HPUX等相关认证。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180214B0H9NH00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券