如何通过Openshift实现K8S容灾?

如何通过Red Hat Openshift实现K8S容灾?
越来越多的K8S应用采用RedHat OpenShift进行部署,IT团队需要部署容灾功能,来防范系统崩溃导致业务受损。一部分行业通常有较强的监管要求,在出现大规模错误的时候必须有数据保护。例如HIPAA 监管要求中的CFR 164.308(7)(ii)(B),要求公司必须能够在出现系统错误的时候“恢复所有数据”。这种情况下对于Openshift上的关键应用来说,容灾是必须的。
本文讲解了用户如何使用OpenShift和Portworx来实现零RPO的容灾。Portworx是Redhad容器目录认证的厂商,在OperaterHub上也有经过认证的Operator。能够为Red Hat客户提供完整的OpenShift体验。在我们进入如何在OpenShift上达到零RPO容灾之前,让我们首先来分析一下,传统的容灾方案为什么不适用于K8S。
传统的备份和恢复方案是在虚拟机(VM)层面来实现的。如果一个单一应用运行在单一虚拟机上,这种方案很合适。因为备份虚拟机和备份应用一样的。而运行在OpenShift上的容器化应用,却很不一样。一个虚拟机通常可以运行多个Pods,但不是所有的这些Pods都是为一个应用服务的。同样,一个应用也可能跨越多个虚拟机。容器化应用的通常架构模式中应用是分布在一组服务器集群上的。所以仅仅备份虚拟机就不合适了。要么过多备份了无用的内容,要么没有备份关键的应用数据。例如我想备份应用A,备份虚拟机的过程中,也会备份包括应用B和应用C的数据,这就会导致过多的备份。如果我备份了整个VM,而应用A运行在其他VM上的部分就没有被有效的备份,这就导致没有备份关键的应用数据。

为了解决这个问题,Openshift上的容灾需要的解决方案应是:

  • 容器颗粒度的
  • Kubernetes命名空间可感知的
  • 应用一致的
  • 能够备份数据和应用配置
  • 能够为数据中心提供同步和异步备份的不同方式

Portworx企业版数据平台的PX-DR就是按照以上的原则设计的。

容器颗粒度的Openshift容灾
PX-DR是一个容器颗粒度的DR方案。它不是去备份VM或者物理机上的所有数据,而是备份运行在主机上的特定的Pod,或者备份一组Pod。在下面的图中,我们看到一个3节点的OpenShift集群、一个三节点的Cassandra环,和三个单独节点的PostgreSQL数据库。

通过PX-DR我们可以去备份我们想要备份的特定Pods。例如,我们想备份3节点的Cassandra环,或者想备份一个单独的PostgreSQL数据库。通过提供容器颗粒度的备份,我们避免了在备份所有VM过程中复杂的数据提取,转化和加载(ETL)过程。通过仅仅备份单独的应用,我们可以大量节省存储成本,以及保持很低的RTO。
对整个Kubernetes命名空间的容灾
具备容器颗粒度的备份代表我们也可以对整个命名空间进行备份。Kubernetes上的命名空间,通常可以运行有关联的一组应用。例如,某企业的一个命名空间代表了该企业的一个分支机构的所有应用。通常在备份命名空间的时候,我们会备份整个命名空间,而不是仅备份命名空间里的某一个应用。传统的备份方案是无法对命名空间进行备份的,因为命名空间是跨VM边界的。PX-DR,可以备份整个命名空间,不论与这个命名空间关联的Pods在哪里。
对 OpenShift备份过程中保持应用的一致性
PX-DR可以保持应用的一致性。如上面的例子,3个Cassandr pods是一个分布式系统。通过对它们进行快照的过程中,如果需要支持应用在无数据损失的情况下恢复,就需要在快照过程中保持所有的Pods被锁定。对VM进行快照无法锁定所有Pods。而进行系列快照也不能达到。Portworx提供了Kubernetes组快照规则引擎,允许Operators自动的执行前置和后置快照命令。例如对Cassandra,我们必须运行nodetool flush命令来达到对多个Cassandra容器快照过程中保持应用的一致性。
apiVersion: stork.libopenstorage.org/v1alpha1
kind: Rule
metadata:
name: cassandra-presnap-rule
spec:
– podSelector:
app: cassandra
actions:
– type: command
value: nodetool flush
为Openshift应用备份数据和应用配置
我们已经叙述了容器颗粒度备份、命名空间感知、应用一致性备份的重要性。现在我们来看一下为什么OpenShift的DR要求能够备份数据和应用配置。在OpenShift上备份和恢复一个应用需要两件事情:数据、和应用配置。如果我们仅仅备份数据,恢复应用的时间会非常长,因为我们需要重建应用配置,会增加RTO。如果我们仅仅备份应用的配置 – 所有的Yaml文件(定义了应用的部署、服务账户、PVCs等),但我们却没有应用数据。因此我们需要同时备份应用数据和应用配置。PX-DR可以通过一个OpenShift命令备份应用数据和应用配置。恢复OpenShift应用的时候使用 `oc -f apply myapp.yml` 命令,因为恢复应用的过程与最初部署应用过程是一样的。

对Openshift的同步或异步DR
针对我们的目标和数据中心的不同架构,我们可以选择正确的OpenShift容灾策略。我们可以选择同步或者异步的备份模式。在一些情况下,也可以同时选取同步和异步备份,因为同步和异步提供了不同层级的系统保护。 

例如,一个银行有本地部署的数据中心,并且通过专线连接到了一个AWS数据中心,可能会需要为一个重要商业应用选择零RPO的DR策略,同时要求RTO<1分钟。在这种情况下,我们倾向于推荐同步备份的PX-DR,由于两个环境的延时极低,因此可以提供零数据损失的恢复。

 

另一个例子,如果一个制造业的公司在较远的两地有两个数据中心,应用要求较低的RTO,但按每小时的备份频率对于RPO的目标来说已经足够了,在这种情况下,异步备份的PX-DR,使用连续增量式的备份就已经足够。

下面是不同情况下OpenShift DR策略的选择

较远网络的OpenShift容灾策略(两个站点之间的往返延迟 >10毫秒的情况)

近距离网络的OpenShift的容灾策略(两个站点之间的往返延迟 < 10毫秒的情况)

如何在OpenShift上通过PX-DR实现零RPO的DR
PX-DR支持在OpenShift上的同步和异步容灾,下面我们来关注下零RPO的同步容灾。我们先看一下通过Portworx和OpenShift同步容灾的相关概念和配置,包括初始setup和模拟出一个系统错误。一个单独的Portworx数据管理层横跨多个站点,如上图所示,同步PX-DR使用位于多个OpenShift集群下的、一个单独的Portworx数据管理层。这会在每一个OpenShift站点上提供永远可用的数据复制。一个单独的数据管理层意味着:有两个Portworx集群域,其中总有一个Portworx集群是可用的。

通过集群域,Portworx数据管理层来区分主站点和容灾站点。集群域在Portworx集群被安装的时候就会配置完成。在每一个OpenShift集群上(主集群或DR集群)配置Portworx来包括同一个Key-value的存储端点和集群名称,但使用不同的集群域来区分主站点和DR站点,看下面的例子。

Primary DR Site args: [“-k”, “etcd:http://etcd:2379”, “-c”, “px-cluster-synchronous”, “-s”, “type=gp2,size=250”, “-secret_type”, “k8s”, “-cluster_domain”, “primary” “-x”, “kubernetes”] “` args: [“-k”, “etcd:http://etcd:2379”, “-c”, “px-cluster-synchronous”, “-s”, “type=gp2,size=250”, “-secret_type”, “k8s”, “-cluster_domain”, “dr-site” “-x”, “kubernetes”]

 

低延时要求

同步PX-DR需要很低的延时。因为每一个写入操作都会被同步的复制到容灾站点上,如果延时较高,应用的性能就会受到很大影响。这也是为什么在这样的架构中,卷必须设定复制因子在2以上。到DR站点的往返延迟不能够超过10毫秒,甚至有一些应用要求的延时比10毫秒还要低。当设计应用时,同时需要思考DR的架构和延时的要求。可以在两个站点间使用Ping来测试延时。测试延时可以返回最小、最大和平均延时以及分布。

$ ping ip-10-0-131-167 PING (10.0.131.167) 56(84) bytes of data. 64 bytes from (10.0.131.167): icmp_seq=1 ttl=255 time=0.019 ms 64 bytes from (10.0.131.167): icmp_seq=2 ttl=255 time=0.028 ms 64 bytes from (10.0.131.167): icmp_seq=3 ttl=255 time=0.035 ms 64 bytes from (10.0.131.167): icmp_seq=4 ttl=255 time=0.029 ms 64 bytes from (10.0.131.167): icmp_seq=5 ttl=255 time=0.028 ms ^C — ip-10-0-131-167.us-west-2.compute.internal ping statistics — 5 packets transmitted, 5 received, 0% packet loss, time 4080ms rtt min/avg/max/mdev = 0.019/0.027/0.035/0.008 ms

Setup Openshift集群配对

一旦完成两个站点都在运行Portworx,在正确的集群域设定基础上,它们就可以正常的来Sync了。我们可以通过Portworx命令 “` $ pxctl cluster domains show “` 来进行验证。验证完成后,并且两个集群域都是正常的情况下,就可以创建集群配对对象。这样两个站点就可以共享一个OpenShift应用YAML文件。这些YAML文件代表了应用的配置,对于在出问题时保证低RTO有着重要的作用。首先为目标命名空间产生集群配对,然后把YAML文件应用到主站点上。

$ storkctl generate clusterpair -n appns dr-site > dr-site.yaml
$ oc create -f dr-site.yaml

可以通过下面的命令来验证集群配对。

$ storkctl get clusterdomainsstatus

创建一个调度和迁移

取决于你的组织的RTO要求,你可以选择应用的sync频率。通过创建一个策略来定义调度,然后把调度和应用的迁移关联起来。

首先,创建一个调度,下面的例子中在每一分钟迁移应用配置。把它保存成一个Yaml文件,然后使用`oc create -f` 来创建策略。

apiVersion: stork.libopenstorage.org/v1alpha1
kind: SchedulePolicy
metadata:
name: sched-policy
namespace: appns
policy:
interval:
intervalMinutes: 1
daily:
time: “10:14PM”
weekly:
day: “Thursday”
time: “10:13PM”
monthly:
date: 14
time: “8:05PM”

接下来,创建一个迁移:针对 “appns”命名空间、“dr-site”集群配对、和使用这个调度。注意文件最下方的“schedulePolicyName”。存成一个yaml文件,然后通过` oc create -f` 来应用它。

apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
name: migrationschedule
namespace: appns
spec:
template:
spec:
clusterPair: dr-site
includeResources: true
startApplications: false
includeVolumes: false
namespaces:
– demo
schedulePolicyName: sched-policy

注意以上仅仅设定includeResources是true,而设定其他的都是false,因为同步DR集群已经在两个集群上都配置了数据,因此我们不再需要include卷,并且直到有系统错误发生前,我们也不想启动这个应用。如果我们使用异步PX-DR方式,我们需要把`includeVolumes` 改为true。

你可以通过运行下面的命令来验证迁移是否已经完成。

$ storkctl get migration

通过OpenShift DR站点来恢复

现在OpenShift集群都已经sync完成,应用也sync完成。我们准备好来恢复应用了。当一个主站点的灾难发生后,下面的步骤即可在DR站点上恢复,并且是零RPO。

首先,关闭主站点,等待域变成  (NotInSync)

$ storkctl deactivate clusterdomain ocs-primary
$ storkctl get clusterdomainsstatus

接下来,如果你有权限访问主站点,把复制集变成0。如果你没有权限访问主站点,直接走到下一步,在容灾站点上恢复应用。

$ oc scale deploy -n demo –replicas=0 –all

通过向迁移调度增加 `suspend:true` ,并且更新spec,可以暂停迁移

apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
name: migrationschedule
namespace: appns
spec:
template:
spec:
clusterPair: dr-site
includeResources: true
startApplications: false
includeVolumes: false
namespaces:
– demo
schedulePolicyName: sched-policy
suspend: true

$oc apply -f migration-schedule.yaml

最后,在DR站点上,启动迁移,打开DR站点上的Pods。

$ storkctl activate migration -n appns

你的“appns”命名空间里的应用现在已经在OpenShift DR站点上重启了,并且是0数据损失。

PX-DR包括一个API可以自动化的实现上面的步骤,另外,当主站点又重新启动后,应用的配置和数据会重新被sync,这样就可以重新在主站点上启动应用。

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录