怎么通過Openshift實現(xiàn)K8S容災(zāi)

為了解決這個問題，Openshift上的容災(zāi)需要的解決方案應(yīng)是：

• 容器顆粒度的

• Kubernetes命名空間可感知的

• 應(yīng)用一致的

• 能夠備份數(shù)據(jù)和應(yīng)用配置

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

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

較遠網(wǎng)絡(luò)的OpenShift容災(zāi)策略(兩個站點之間的往返延遲 >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，在正確的集群域設(shè)定基礎(chǔ)上，它們就可以正常的來Sync了。我們可以通過Portworx命令 “` $ pxctl cluster domains show “` 來進行驗證。驗證完成后，并且兩個集群域都是正常的情況下，就可以創(chuàng)建集群配對對象。這樣兩個站點就可以共享一個OpenShift應(yīng)用YAML文件。這些YAML文件代表了應(yīng)用的配置，對于在出問題時保證低RTO有著重要的作用。首先為目標命名空間產(chǎn)生集群配對，然后把YAML文件應(yīng)用到主站點上。

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

可以通過下面的命令來驗證集群配對。

$ storkctl get clusterdomainsstatus

創(chuàng)建一個調(diào)度和遷移

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

首先，創(chuàng)建一個調(diào)度，下面的例子中在每一分鐘遷移應(yīng)用配置。把它保存成一個Yaml文件，然后使用`oc create -f` 來創(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”

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

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

注意以上僅僅設(shè)定includeResources是true，而設(shè)定其他的都是false，因為同步DR集群已經(jīng)在兩個集群上都配置了數(shù)據(jù)，因此我們不再需要include卷，并且直到有系統(tǒng)錯誤發(fā)生前，我們也不想啟動這個應(yīng)用。如果我們使用異步PX-DR方式，我們需要把`includeVolumes` 改為true。

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

$ storkctl get migration

通過OpenShift DR站點來恢復(fù)

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

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

$ storkctl deactivate clusterdomain ocs-primary
$ storkctl get clusterdomainsstatus

接下來，如果你有權(quán)限訪問主站點，把復(fù)制集變成0。如果你沒有權(quán)限訪問主站點，直接走到下一步，在容災(zāi)站點上恢復(fù)應(yīng)用。

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

通過向遷移調(diào)度增加 `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”命名空間里的應(yīng)用現(xiàn)在已經(jīng)在OpenShift DR站點上重啟了，并且是0數(shù)據(jù)損失。

PX-DR包括一個API可以自動化的實現(xiàn)上面的步驟，另外，當主站點又重新啟動后，應(yīng)用的配置和數(shù)據(jù)會重新被sync，這樣就可以重新在主站點上啟動應(yīng)用。