這篇文章主要講解了“怎么通過Openshift實現(xiàn)K8S容災(zāi)”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么通過Openshift實現(xiàn)K8S容災(zāi)”吧！

創(chuàng)新互聯(lián)公司是一家集成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站頁面設(shè)計、網(wǎng)站優(yōu)化SEO優(yōu)化為一體的專業(yè)的建站公司，已為成都等多地近百家企業(yè)提供網(wǎng)站建設(shè)服務(wù)。追求良好的瀏覽體驗,以探求精品塑造與理念升華,設(shè)計最適合用戶的網(wǎng)站頁面。 合作只是第一步，服務(wù)才是根本,我們始終堅持講誠信，負責(zé)任的原則，為您進行細心、貼心、認(rèn)真的服務(wù),與眾多客戶在蓬勃發(fā)展的市場環(huán)境中,互促共生。如何通過Red Hat Openshift實現(xiàn)K8S容災(zāi)?越來越多的K8S應(yīng)用采用RedHat OpenShift進行部署，IT團隊需要部署容災(zāi)功能，來防范系統(tǒng)崩潰導(dǎo)致業(yè)務(wù)受損。一部分行業(yè)通常有較強的監(jiān)管要求，在出現(xiàn)大規(guī)模錯誤的時候必須有數(shù)據(jù)保護。例如HIPAA 監(jiān)管要求中的CFR 164.308(7)(ii)(B)，要求公司必須能夠在出現(xiàn)系統(tǒng)錯誤的時候“恢復(fù)所有數(shù)據(jù)”。這種情況下對于Openshift上的關(guān)鍵應(yīng)用來說，容災(zāi)是必須的。本文講解了用戶如何使用OpenShift和Portworx來實現(xiàn)零RPO的容災(zāi)。Portworx是Redhad容器目錄認(rèn)證的廠商，在OperaterHub上也有經(jīng)過認(rèn)證的Operator。能夠為Red Hat客戶提供完整的OpenShift體驗。在我們進入如何在OpenShift上達到零RPO容災(zāi)之前，讓我們首先來分析一下，傳統(tǒng)的容災(zāi)方案為什么不適用于K8S。傳統(tǒng)的備份和恢復(fù)方案是在虛擬機（VM）層面來實現(xiàn)的。如果一個單一應(yīng)用運行在單一虛擬機上，這種方案很合適。因為備份虛擬機和備份應(yīng)用一樣的。而運行在OpenShift上的容器化應(yīng)用，卻很不一樣。一個虛擬機通?？梢赃\行多個Pods，但不是所有的這些Pods都是為一個應(yīng)用服務(wù)的。同樣，一個應(yīng)用也可能跨越多個虛擬機。容器化應(yīng)用的通常架構(gòu)模式中應(yīng)用是分布在一組服務(wù)器集群上的。所以僅僅備份虛擬機就不合適了。要么過多備份了無用的內(nèi)容，要么沒有備份關(guān)鍵的應(yīng)用數(shù)據(jù)。例如我想備份應(yīng)用A，備份虛擬機的過程中，也會備份包括應(yīng)用B和應(yīng)用C的數(shù)據(jù)，這就會導(dǎo)致過多的備份。如果我備份了整個VM，而應(yīng)用A運行在其他VM上的部分就沒有被有效的備份，這就導(dǎo)致沒有備份關(guān)鍵的應(yīng)用數(shù)據(jù)。

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

• 容器顆粒度的

• Kubernetes命名空間可感知的

• 應(yīng)用一致的

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

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

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

容器顆粒度的Openshift容災(zāi)PX-DR是一個容器顆粒度的DR方案。它不是去備份VM或者物理機上的所有數(shù)據(jù)，而是備份運行在主機上的特定的Pod，或者備份一組Pod。在下面的圖中，我們看到一個3節(jié)點的OpenShift集群、一個三節(jié)點的Cassandra環(huán)，和三個單獨節(jié)點的PostgreSQL數(shù)據(jù)庫。通過PX-DR我們可以去備份我們想要備份的特定Pods。例如，我們想備份3節(jié)點的Cassandra環(huán)，或者想備份一個單獨的PostgreSQL數(shù)據(jù)庫。通過提供容器顆粒度的備份，我們避免了在備份所有VM過程中復(fù)雜的數(shù)據(jù)提取，轉(zhuǎn)化和加載（ETL）過程。通過僅僅備份單獨的應(yīng)用，我們可以大量節(jié)省存儲成本，以及保持很低的RTO。對整個Kubernetes命名空間的容災(zāi)具備容器顆粒度的備份代表我們也可以對整個命名空間進行備份。Kubernetes上的命名空間，通?？梢赃\行有關(guān)聯(lián)的一組應(yīng)用。例如，某企業(yè)的一個命名空間代表了該企業(yè)的一個分支機構(gòu)的所有應(yīng)用。通常在備份命名空間的時候，我們會備份整個命名空間，而不是僅備份命名空間里的某一個應(yīng)用。傳統(tǒng)的備份方案是無法對命名空間進行備份的，因為命名空間是跨VM邊界的。PX-DR，可以備份整個命名空間，不論與這個命名空間關(guān)聯(lián)的Pods在哪里。對 OpenShift備份過程中保持應(yīng)用的一致性PX-DR可以保持應(yīng)用的一致性。如上面的例子，3個Cassandr pods是一個分布式系統(tǒng)。通過對它們進行快照的過程中，如果需要支持應(yīng)用在無數(shù)據(jù)損失的情況下恢復(fù)，就需要在快照過程中保持所有的Pods被鎖定。對VM進行快照無法鎖定所有Pods。而進行系列快照也不能達到。Portworx提供了Kubernetes組快照規(guī)則引擎，允許Operators自動的執(zhí)行前置和后置快照命令。例如對Cassandra，我們必須運行nodetool flush命令來達到對多個Cassandra容器快照過程中保持應(yīng)用的一致性。

apiVersion: stork.libopenstorage.org/v1alpha1
kind: Rule
metadata:
name: cassandra-presnap-rule
spec:
– podSelector:
app: cassandra
actions:
– type: command
value: nodetool flush

為Openshift應(yīng)用備份數(shù)據(jù)和應(yīng)用配置我們已經(jīng)敘述了容器顆粒度備份、命名空間感知、應(yīng)用一致性備份的重要性。現(xiàn)在我們來看一下為什么OpenShift的DR要求能夠備份數(shù)據(jù)和應(yīng)用配置。在OpenShift上備份和恢復(fù)一個應(yīng)用需要兩件事情：數(shù)據(jù)、和應(yīng)用配置。如果我們僅僅備份數(shù)據(jù)，恢復(fù)應(yīng)用的時間會非常長，因為我們需要重建應(yīng)用配置，會增加RTO。如果我們僅僅備份應(yīng)用的配置 – 所有的Yaml文件（定義了應(yīng)用的部署、服務(wù)賬戶、PVCs等），但我們卻沒有應(yīng)用數(shù)據(jù)。因此我們需要同時備份應(yīng)用數(shù)據(jù)和應(yīng)用配置。PX-DR可以通過一個OpenShift命令備份應(yīng)用數(shù)據(jù)和應(yīng)用配置?；謴?fù)OpenShift應(yīng)用的時候使用 `oc -f apply myapp.yml` 命令，因為恢復(fù)應(yīng)用的過程與最初部署應(yīng)用過程是一樣的。

對Openshift的同步或異步DR針對我們的目標(biāo)和數(shù)據(jù)中心的不同架構(gòu)，我們可以選擇正確的OpenShift容災(zāi)策略。我們可以選擇同步或者異步的備份模式。在一些情況下，也可以同時選取同步和異步備份，因為同步和異步提供了不同層級的系統(tǒng)保護。 

例如，一個銀行有本地部署的數(shù)據(jù)中心，并且通過專線連接到了一個AWS數(shù)據(jù)中心，可能會需要為一個重要商業(yè)應(yīng)用選擇零RPO的DR策略，同時要求RTO<1分鐘。在這種情況下，我們傾向于推薦同步備份的PX-DR，由于兩個環(huán)境的延時極低，因此可以提供零數(shù)據(jù)損失的恢復(fù)。

另一個例子，如果一個制造業(yè)的公司在較遠的兩地有兩個數(shù)據(jù)中心，應(yīng)用要求較低的RTO，但按每小時的備份頻率對于RPO的目標(biāo)來說已經(jīng)足夠了，在這種情況下，異步備份的PX-DR，使用連續(xù)增量式的備份就已經(jīng)足夠。

下面是不同情況下OpenShift DR策略的選擇

較遠網(wǎng)絡(luò)的OpenShift容災(zāi)策略(兩個站點之間的往返延遲 >10毫秒的情況)

近距離網(wǎng)絡(luò)的OpenShift的容災(zāi)策略（兩個站點之間的往返延遲 < 10毫秒的情況）如何在OpenShift上通過PX-DR實現(xiàn)零RPO的DRPX-DR支持在OpenShift上的同步和異步容災(zāi)，下面我們來關(guān)注下零RPO的同步容災(zāi)。我們先看一下通過Portworx和OpenShift同步容災(zāi)的相關(guān)概念和配置，包括初始setup和模擬出一個系統(tǒng)錯誤。一個單獨的Portworx數(shù)據(jù)管理層橫跨多個站點，如上圖所示，同步PX-DR使用位于多個OpenShift集群下的、一個單獨的Portworx數(shù)據(jù)管理層。這會在每一個OpenShift站點上提供永遠可用的數(shù)據(jù)復(fù)制。一個單獨的數(shù)據(jù)管理層意味著：有兩個Portworx集群域，其中總有一個Portworx集群是可用的。

通過集群域，Portworx數(shù)據(jù)管理層來區(qū)分主站點和容災(zāi)站點。集群域在Portworx集群被安裝的時候就會配置完成。在每一個OpenShift集群上（主集群或DR集群）配置Portworx來包括同一個Key-value的存儲端點和集群名稱，但使用不同的集群域來區(qū)分主站點和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需要很低的延時。因為每一個寫入操作都會被同步的復(fù)制到容災(zāi)站點上，如果延時較高，應(yīng)用的性能就會受到很大影響。這也是為什么在這樣的架構(gòu)中，卷必須設(shè)定復(fù)制因子在2以上。到DR站點的往返延遲不能夠超過10毫秒，甚至有一些應(yīng)用要求的延時比10毫秒還要低。當(dāng)設(shè)計應(yīng)用時，同時需要思考DR的架構(gòu)和延時的要求。可以在兩個站點間使用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，在正確的集群域設(shè)定基礎(chǔ)上，它們就可以正常的來Sync了。我們可以通過Portworx命令 “` $ pxctl cluster domains show “` 來進行驗證。驗證完成后，并且兩個集群域都是正常的情況下，就可以創(chuàng)建集群配對對象。這樣兩個站點就可以共享一個OpenShift應(yīng)用YAML文件。這些YAML文件代表了應(yīng)用的配置，對于在出問題時保證低RTO有著重要的作用。首先為目標(biāo)命名空間產(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完成。我們準(zhǔn)備好來恢復(fù)應(yīng)用了。當(dā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)上面的步驟，另外，當(dāng)主站點又重新啟動后，應(yīng)用的配置和數(shù)據(jù)會重新被sync，這樣就可以重新在主站點上啟動應(yīng)用。

感謝各位的閱讀，以上就是“怎么通過Openshift實現(xiàn)K8S容災(zāi)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么通過Openshift實現(xiàn)K8S容災(zāi)這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！

文章題目：怎么通過Openshift實現(xiàn)K8S容災(zāi)-創(chuàng)新互聯(lián)
URL標(biāo)題：http://sd-ha.com/article18/goegp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、品牌網(wǎng)站制作、網(wǎng)站收錄、面包屑導(dǎo)航、小程序開發(fā)、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)