為了解決這個(gè)問(wèn)題，Openshift上的容災需要的解決方案應是：

• 容器顆粒度的

• Kubernetes命名空間可感知的

• 應用一致的

• 能夠備份數據和應用配置

• 能夠為數據中心提供同步和異步備份的不同方式

Portworx企業(yè)版數據平臺的PX-DR就是按照以上的原則設計的。

較遠網(wǎng)絡(luò )的OpenShift容災策略(兩個(gè)站點(diǎn)之間的往返延遲 >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集群配對

一旦完成兩個(gè)站點(diǎn)都在運行Portworx，在正確的集群域設定基礎上，它們就可以正常的來(lái)Sync了。我們可以通過(guò)Portworx命令 “` $ pxctl cluster domains show “` 來(lái)進(jìn)行驗證。驗證完成后，并且兩個(gè)集群域都是正常的情況下，就可以創(chuàng )建集群配對對象。這樣兩個(gè)站點(diǎn)就可以共享一個(gè)OpenShift應用YAML文件。這些YAML文件代表了應用的配置，對于在出問(wèn)題時(shí)保證低RTO有著(zhù)重要的作用。首先為目標命名空間產(chǎn)生集群配對，然后把YAML文件應用到主站點(diǎn)上。

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

可以通過(guò)下面的命令來(lái)驗證集群配對。

$ storkctl get clusterdomainsstatus

創(chuàng )建一個(gè)調度和遷移

取決于你的組織的RTO要求，你可以選擇應用的sync頻率。通過(guò)創(chuàng )建一個(gè)策略來(lái)定義調度，然后把調度和應用的遷移關(guān)聯(lián)起來(lái)。

首先，創(chuàng )建一個(gè)調度，下面的例子中在每一分鐘遷移應用配置。把它保存成一個(gè)Yaml文件，然后使用`oc create -f` 來(lái)創(chuàng )建策略。

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”

接下來(lái)，創(chuàng )建一個(gè)遷移：針對 “appns”命名空間、“dr-site”集群配對、和使用這個(gè)調度。注意文件最下方的“schedulePolicyName”。存成一個(gè)yaml文件，然后通過(guò)` oc create -f` 來(lái)應用它。

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集群已經(jīng)在兩個(gè)集群上都配置了數據，因此我們不再需要include卷，并且直到有系統錯誤發(fā)生前，我們也不想啟動(dòng)這個(gè)應用。如果我們使用異步PX-DR方式，我們需要把`includeVolumes` 改為true。

你可以通過(guò)運行下面的命令來(lái)驗證遷移是否已經(jīng)完成。

$ storkctl get migration

通過(guò)OpenShift DR站點(diǎn)來(lái)恢復

現在OpenShift集群都已經(jīng)sync完成，應用也sync完成。我們準備好來(lái)恢復應用了。當一個(gè)主站點(diǎn)的災難發(fā)生后，下面的步驟即可在DR站點(diǎn)上恢復，并且是零RPO。

首先，關(guān)閉主站點(diǎn)，等待域變成  (NotInSync)

$ storkctl deactivate clusterdomain ocs-primary
$ storkctl get clusterdomainsstatus

接下來(lái)，如果你有權限訪(fǎng)問(wèn)主站點(diǎn)，把復制集變成0。如果你沒(méi)有權限訪(fǎng)問(wèn)主站點(diǎn)，直接走到下一步，在容災站點(diǎn)上恢復應用。

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

通過(guò)向遷移調度增加 `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站點(diǎn)上，啟動(dòng)遷移，打開(kāi)DR站點(diǎn)上的Pods。

$ storkctl activate migration -n appns

你的“appns”命名空間里的應用現在已經(jīng)在OpenShift DR站點(diǎn)上重啟了，并且是0數據損失。

PX-DR包括一個(gè)API可以自動(dòng)化的實(shí)現上面的步驟，另外，當主站點(diǎn)又重新啟動(dòng)后，應用的配置和數據會(huì )重新被sync，這樣就可以重新在主站點(diǎn)上啟動(dòng)應用。