金融级IT架构与运维：云原生、分布式与安全
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

4.2　容器云的备份与双活

在实际项目生产环境中，容器云的备份、多集群管理、双活与灾备是很受大家关注的话题。在本节中，我们会依次进行介绍。

4.2.1　容器云的备份

在Kubernetes、OpenShift单集群部署时，我们会采用高可用的部署方式，如图4-32所示。因此，在单一容器云集群中，我们不用担心单点故障。

106-2

图4-32　OpenShift的高可用架构

那么，针对容器云集群，我们如何做备份？备份方式主要分为单集群全量备份和基于Namespaces增量备份两种。

  • 单集群全量备份：在集群级别备份所有重要文件和配置等，可以满足相同地址（服务器主机名和IP与之前集群相同）集群的恢复及回滚到历史时间点。它相当于重新部署一套完全一样的集群，必须在整个集群离线的条件下执行恢复操作。
  • 基于Namespace增量备份：在Namespaces级别备份所有资源对象，可以满足任意时间点在任意一个集群的恢复操作。这种备份恢复不涉及OpenShift平台底层基础架构，仅涉及平台上的应用和资源对象。

在实际的项目中，除了要考虑容器云自身的备份外，我们还需要考虑应用持久化数据的备份。接下来，我们对这三点进行说明。

1. 单集群全量备份

单集群全量备份的内容如表4-3所示。

表4-3　单集群全量备份资源表

107-1

2. 基于Namespace增量备份

基于Namespace增量备份，同样需要备份以下两类内容。

  • 集群中所有Namespaces中的资源对象。
  • 挂载持久化存储的应用数据的备份：平台中所有挂载PV的Pod的应用数据。

根据上述分类，需要使用不同的备份方式，如表4-4所示。

表4-4　基于Namespace备份资源表

107-2

对于基于Namespace增量备份，常见需要备份的资源对象列举如下（包含但不限于）：

  • namespace
  • deploymentconfig
  • deployment
  • buildconfig
  • imagestream
  • service
  • route
  • configmap
  • rolebindings
  • serviceaccounts
  • secrets
  • pvcs
  • templates
  • jobs
  • cronjobs
  • statefulsets
  • hpas

3. 应用数据备份

在上述两种备份方式中，我们都提到应用数据备份，这也是灾备中最难实现的地方。传统数据中心可以利用磁带库和管理软件实现数据备份，也可以依靠数据复制工具实现数据备份。根据作用层次的不同，我们可将数据备份主要分为以下三类。

  • 基于存储层面的数据备份：在存储层面实现数据备份，商业存储大部分都提供这项功能，主流产品有EMC Symmtrix、EMC Clarrion、IBM PPRC、HDS TrueCopy、HP CA等。
  • 基于主机层面的数据备份：在操作系统层面实现数据复制，主流产品有VVR（Veritas Volume Replicator，卷远程复制）、VSF（Veritas Storage Foundation，卷远程镜像）等。
  • 基于应用层面的数据备份：在应用层面实现数据备份，通常是依赖应用数据多副本或提供导出导入工具等实现。

当然，我们在具体选择数据备份的方式时，主要根据应用的性质决定。对于无状态的应用，直接在存储层面或主机层面实现数据复制和恢复，比如Jenkins、镜像仓库。对于有状态的应用，通常使用应用提供的工具，允许客户在Pod中的应用层面将文件或数据导出到备份存储上保存，如GitLab、etcd。

关于更多容器云备份的技术细节，请参考《OpenShift在企业中的实践：PaaS DevOps微服务（第2版）》的相关内容。由于篇幅有限，这里不再赘述。

4.2.2　容器云的多集群管理

随着容器云的普及，客户将越来越多的应用迁移到容器云上。如果容器云的集群数量不多，对集群进行单独管理是没问题的。但如果容器云的集群数量超过10个，那么多集群管理就势在必行了。

在容器云的项目实施过程中，很多国内厂商基于DIY的方式定制容器云的管理平台，实现对多个Kubernetes集群的纳管。这样做的好处是语言本地化支持做得好，并且由于针对不同的客户提供定制化UI，因此界面相对友好。但问题在于这种DIY的方式脱离了开源社区，当Kubernetes的版本升级后，我们大概率需要对定制化UI进行一些调整。因此，笔者建议通过社区开源方案来实现容器云的多集群管理。

关于多集群管理的方案，此前开源社区的联邦集群方案一直不太成熟。目前在开源社区多集群管理方案中，做得比较好的方案是RHACM（Red Hat Advanced Cluster Management for Kubernetes）方案。

针对Kubernetes/OpenShift集群，RHACM主要实现三大功能，分析如下。

  • 多Kubernetes/OpenShift集群的监控：RHACM上的multicluster-observability-operator可以监视托管集群的运行状况，也可以进行高级配置，如设置告警模式。
  • 安全合规：应用基于策略的监管方法，自动监控并确保安全防护与配置控制均符合行业合规要求或公司自定标准。目前RHACM已经和StackRox整合，可以通过StackRox的能力实现较好的合规。
  • 应用发布：RHACM原生支持GitOps，支持在多个集群上发布应用，并且监控应用的状态。此外，RHACM实现了与ArgoCD的兼容和整合。目前OpenShift已经支持ArgoCD。

1. RHACM多集群纳管

我们查看RHACM的界面，可以看到它纳管了10个分布在4个公有云上的Kubernetes集群，如图4-33所示。我们在RHACM上创建应用，界面如图4-34所示。

110-1

图4-33　RHACM的界面

110-2

图4-34　在RHACM上创建应用

应用发布后，可以查看Kubernetes集群和应用的拓扑，如图4-35所示。

111-1

图4-35　查看RHACM发布的应用

RHACM可以对多Kubernetes集群做合规配置检查，如图4-36所示。需要指出的是，新版本的RHACM已经和StackRox方案进行了整合，即由RHACM发起合规策略，StackRox执行策略。

111-2

图4-36　对多Kubernetes集群做合规配置检查

2. 多集群监控

接下来，我们查看多集群监控功能。通过RHACM可以实现对多个Kubernetes集群的性能监控，如图4-37所示。

112-1

图4-37　RHACM多集群监控

Grafana可以统一查看多个Kubernetes集群的资源利用率，如查看单独集群的资源利用情况。如果客户有多Kubernetes集群监控的需求，但又不想引入RHACM这样的开源工具的话，那可以考虑使用Prometheus+ Thanos实现Prometheus联邦，定制化DashBoard报表，对多集群资源情况进行统一纳管。

Thanos的架构通过位于每个Prometheus服务器旁边的Sidecar组件以及响应PromQL查询的中央Query组件，在所有服务器之间引入了一个中央查询层，构成了Thanos部署。组件间通信是通过成员列表Gossip协议实现的。Query可以水平扩展，因为它是无状态的，可以充当智能反向代理，将请求传递给Sidecar，聚合它们的响应并评估针对它们的PromQL查询，如图4-38所示。

113-1

图4-38　Thanos的架构示意图

Thanos通过使用对象存储作为后端来解决存储保留问题。只要Prometheus将数据写入磁盘，并将其加载到对象存储，Sidecar StoreAPI组件就会检测到它。同一个Store组件还可以作为Gossip协议的检索代理，让Query组件与它通信以获取数据，然后将统一的Grafana展现部署在顶层Prometheus的所在OpenShift集群中。

3. ArgoCD实现多集群应用发布

目前RHACM已经与ArgoCD进行了集成。由于通过ArgoCD实现多容器云的应用部署的步骤较多，我们只展示其部分效果。

OCP 4.7上的ArgoCD，是红帽提供的Operator，如图4-39所示。

113-2

图4-39　ArgoCD

使用同样的方法，添加多个集群，成功添加的效果如图4-40所示。

113-3

图4-40　ArgoCD添加多个集群

添加测试Demo代码，并在第一个集群部署代码：

[root@bastion ～]# argocd repo add https://github.com/mvazquezc/gitops-demo.git
repository 'https://github.com/mvazquezc/gitops-demo.git' added
[root@bastion ～]# argocd app create --project default --name pre-reversewords
    --repo https://github.com/mvazquezc/gitops-demo.git --path reversewords_app/base
    --dest-server  https://console-openshift-console.apps.ocp46.ats.com:6443
    --dest-namespace reverse-words --revision pre
application 'pre-reversewords' created

在第二个集群部署应用：

[root@bastion ～]# argocd app create --project default --name pro-reversewords
    --repo https://github.com/mvazquezc/gitops-demo.git --path reversewords_app/base
    --dest-server  https://console-openshift-console.apps.ocp.ats.com:6443
    --dest-namespace reverse-words --revision pro
application 'pro-reversewords' created

登录ArgoCD，可以看到部署成功的应用，如图4-41所示。

114-1

图4-41　登录ArgoCD查看部署成功的应用

通过浏览器分别访问两个应用的路由，如图4-42所示。

114-2

图4-42　通过浏览器访问应用

在ArgoCD中修改应用源码后，可以触发代码自动构建。

修改gitops-demo/reversewords_app/overlays/pro/deployment.yaml，将版本改为v0.0.4，如图4-43所示。

115-1

图4-43　修改应用源码

此时登录ArgoCD，看到repo代码变更被发现，然后代码会自动同步并重新部署应用，如图4-44所示。

115-2

图4-44　自动重新部署应用

通过浏览器访问应用，发现版本信息已经发生变化，如图4-45所示。

116-1

图4-45　版本信息发生变化

利用ArgoCD，我们可以在混合容器云中部署应用，如图4-46所示。

116-2

图4-46　利用ArgoCD在混合容器云上部署应用

部署完毕后，查看ArgoCD，如图4-47所示。图中方框内显示应用相关的资源，即在三个OCP集群分别部署应用，还部署了一个haproxy。

116-3

图4-47　查看ArgoCD在混合容器云上部署的应用

我们可以查看haproxy指向的服务器，通过查看configmap进行确认：

[root@bastion app]# oc describe cm haproxy

#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend  main
    bind *:8080
    use_backend sushi_Dev if { hdr_beg(host) -i dev.sushi-everywhere }
    default_backend             sushi_Prod

frontend stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 10s

#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend sushi_Prod
    balance roundrobin
    option httpchk GET / HTTP/1.1\r\nHost:\ sushi.proxy
    http-request set-header Host sushi.proxy
    mode http
        #server Demo-Power 10.3.66.1:80 check weight 100
        server Demo-Z 172.16.32.239:80 check weight 100
        server Demo-x86 172.16.32.88:80 check weight 100

backend sushi_Dev
    balance roundrobin
    option httpchk GET / HTTP/1.1\r\nHost:\ dev.sushi.proxy
    http-request set-header Host dev.sushi.proxy
    mode http
        server local-x86 172.16.32.223:80 check weight 1
Events:  <none>

访问开发环境的地址，显示环境为x86_64，如图4-48所示。

117-1

图4-48　访问开发环境的地址

访问生产环境的地址，可以看到是s390x，也就是Z环境，如图4-49所示。

118-1

图4-49　访问生产环境的地址

刷新生产环境页面，出现x86_64。因为haproxy是轮询转发的，访问结果如图4-50所示。

118-2

图4-50　刷新生产环境页面

ArgoCD修改源码触发应用自动部署的完整步骤可查看“大魏分享”公众号中文章《混合云中的OpenShift应用发布》的相关内容。

4.2.3　容器云的双活与灾备

在多中心多云环境下，我们可以将容器云部署为多活/灾备模式，通过全局负载均衡器实现应用的多中心多活与灾备。

需要指出的是，真正意义上的容器应用跨数据中心的双活，是将一个应用的不同副本部署到不同的数据中心，如图4-51所示的Database应用。

119-1

图4-51　真正意义上的应用双活

图4-51中的方案设计有几个重要的技术点。

  • 三个不同的区域将有三个OpenShift集群。每个集群都有一个有状态的工作负载实例，工作负载实例是一个数据库。这些实例将形成一个集群，并通过相互同步状态组成一个单一的概念实体。所有实例都将处于活动状态，并且使用Leader选举算法（例如paxos或raft）选出Leader。
  • 实例可以通过在OpenShift的SDN之间建立的网络隧道相互通信，使用Submariner技术实现。

由于篇幅有限，本方案的具体实现我们不展开讨论，对实现感兴趣的读者，可以查看“大魏分享”公众号中的文章《有状态应用在OpenShift上实现多活》。

从笔者的角度来看，上述方案必须在应用自身跨数据中心保证能多活时才能实现。此外Submariner的隧道打通方式会存在一定的网络开销，方案也较为复杂。而在容器云上的应用多活，更多是采用一个应用在多数据中心部署多份的方案，下面我们会介绍。

跨中心多活需要从全局负载均衡、集群配置、存储、应用数据缓存、数据库这五个层面进行相应配置工作，如图4-52所示。

120-1

图4-52　容器云的双活

1）全局负载均衡层：

  • 使用F5等负载均衡器，为多个数据中心的容器云提供统一的入口流量；
  • 每个集群的Route服务域名应保持相同；
  • 全局负载均衡层需要配置每个应用所对应的集群分发地址，并根据集群中所给的资源配比配置权重。

2）集群配置层：

  • 应用部署时，不同集群可以使用独立的镜像库，以提升镜像的获取速度；
  • 应用部署时，各集群中的服务信息应保持一致，服务名称、外部地址应相同；
  • 同一应用容器使用的PV/PVC应保持一致。

3）存储层：

  • 基于Ceph的分布式存储同步能力，可以使用客户提供的符合要求的镜像库和存储同步方案；
  • 原则上每个中心的PaaS平台使用本中心内的存储资源，只有当集群和异地存储的时间延迟和网络抖动满足应用的要求时，才会做跨中心的存储访问。

4）应用数据缓存层：

  • 如果使用Redis集群，则使用redis-migrate-tool或RedisShake做跨集群的异步复制，我们将在8.1.7节介绍两种实现的区别。如果对缓存的数据一致性要求很高，可以使用JBoss Data Grid（对应开源社区Infinispan）自动实现跨中心的双向数据同步。
  • 对于单纯的读缓存的数据，由应用系统进行初始化以及灾备切换后的初始化之后，从数据库中读取。
  • 对于会话性缓存数据，如果希望PaaS端发生多活切换后，客户端应用不重新构建会话数据，则需要单独搭建数据缓存的跨中心复制功能。
  • 每个数据中心的应用，只访问各自数据中心的缓存，不跨集群访问。

5）数据库层：

  • 建议将MySQL部署到物理机上；
  • 数据库采用MySQL主从复制的方式，可以一主多从；
  • 从数据中心写数据库需访问主库；
  • 两个数据中心可以实现MySQL的读写分离，即主中心的数据读写主库，从中心读从库、写主库。

接下来，我们看3个银行客户在容器云双活方面考量的实例。客户主要从7个技术点进行考量。

1）应用的双活实现（考虑OpenShift集群之间是否需要打通VPN）。

a）一个应用的不同副本部署到两个OCP集群？

b）一个应用在两个OCP集群各部署一套。

2）GLB的实现策略（考虑负载均衡器的能力）：

a）通过F5（或其他负载均衡器）的负载均衡策略实现（主从、轮询、性能）；

b）通过F5（或其他负载均衡器）的header过滤，不同地区请求转发到不同的OCP。

3）两数据中心应用的工作模式（考虑容器应用是否实现了无状态）：双写、读写分离、主从复制。

4）缓存的设计（考虑数据中心之间的带宽以及是否可以接受服务降级）：Redis集群的部署方式以及复制方式。

5）数据库的设计（考虑数据库是否本身支持双活）：数据中心的部署方式以及复制方式，如分布分表、分布式数据库、主从复制。

6）公有云（考虑公有云与私有云的业务分配与CI/CD打通）：公有云上的OCP与数据中心内部的双活设计、业务划分。

7）镜像仓库设计（考虑数据中心之间的网络带宽）：不同数据中心之间的镜像仓库复制设计。

根据以上7个技术问题，3个客户在容器云双活方面的设计如表4-5所示。

表4-5　3个银行客户容器云双活设计

122-1

多活容器云的异地灾备中的环境配置、应用部署过程与双活配置相同，但是会增加如下恢复环节：

  • 确认切换目标集群的对应的应用配置库；
  • 确认数据复制、恢复状态；
  • 应用初始化；
  • 应用状态确认；
  • 接通全局负载均衡的流量。
上一章目录下一章