為了解決這個問題，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，這樣就可以重新在主站點上啟動應用。