怎么通过Openshift实现K8S容灾

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

• 容器颗粒度的

• Kubernetes命名空间可感知的

• 应用一致的

• 能够备份数据和应用配置

• 能够为数据中心提供同步和异步备份的不同方式

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

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

$ 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，这样就可以重新在主站点上启动应用。