Kubernetes 容災(zāi)解決方案關(guān)鍵能力
我們面臨著不斷地需要實(shí)施和部署新的軟件應(yīng)用、發(fā)展新的商業(yè)模式、以及吸引新的客戶(hù)。通過(guò)Kubernetes，我們可以采用云原生方式來(lái)進(jìn)行軟件的開(kāi)發(fā)、部署和運(yùn)維。
基于Kubernetes開(kāi)發(fā)和運(yùn)行的應(yīng)用，對(duì)于我們實(shí)現(xiàn)我們的商業(yè)目標(biāo)，非常重要。但新技術(shù)的導(dǎo)入，也會(huì)要求我們考慮更多：新的開(kāi)發(fā)方法、新的團(tuán)隊(duì)、新的工程師、新的技術(shù)、新的合作伙伴、新的供應(yīng)商、新的挑戰(zhàn)。
對(duì)CIO們來(lái)說(shuō)，將關(guān)鍵應(yīng)用轉(zhuǎn)移到Kubernetes上的最大挑戰(zhàn)之一，就是容災(zāi)恢復(fù)能力。
在投入大量資金開(kāi)發(fā)了Kubernetes上的應(yīng)用后，我們最擔(dān)心的就是：一旦出現(xiàn)我們無(wú)法控制的意外事件，我們的應(yīng)用變得無(wú)法訪問(wèn)。如：云供應(yīng)商服務(wù)意外停止、數(shù)據(jù)中心電力中斷、云服務(wù)中斷、網(wǎng)絡(luò)連接中斷等。導(dǎo)致用戶(hù)無(wú)法訪問(wèn)應(yīng)用后，用戶(hù)滿(mǎn)意度大幅下降。
根據(jù)著名研究機(jī)構(gòu)Uptime Institute的報(bào)告，通常發(fā)生服務(wù)中斷，一般我們會(huì)歸因到第三方服務(wù)上，如托管服務(wù)供應(yīng)商或云服務(wù)供應(yīng)商。31%的服務(wù)中斷是由由我們無(wú)法控制的因素導(dǎo)致的，如：網(wǎng)絡(luò)錯(cuò)誤（30%），IT/軟件錯(cuò)誤（28%）。對(duì)于Kubernetes上的應(yīng)用，我們需要一個(gè)可靠的容災(zāi)恢復(fù)方案。
根據(jù)451 Research的報(bào)告，對(duì)于關(guān)鍵性應(yīng)用來(lái)說(shuō)，57%的應(yīng)用要求RPO<1小時(shí)，48%要求RTO<1小時(shí)。即使是非關(guān)鍵應(yīng)用，也有容災(zāi)恢復(fù)的需求。這對(duì)已經(jīng)滿(mǎn)負(fù)荷工作的IT團(tuán)隊(duì)來(lái)說(shuō)都是較大的壓力。
在這樣的情況下，企業(yè)的IT團(tuán)隊(duì)，需要為諸多企業(yè)級(jí)應(yīng)用交付強(qiáng)健的容災(zāi)恢復(fù)方案。
要點(diǎn)小結(jié)
Portworx解決了云原生Kubernetes應(yīng)用企業(yè)級(jí)容災(zāi)的三個(gè)關(guān)鍵難點(diǎn)。
基于Kubernetes底層原生開(kāi)發(fā)的PX-DR:
以Kubernetes原生方式進(jìn)行保護(hù)和恢復(fù)：容器顆粒度的保護(hù)、命名空間可感知。
可應(yīng)用感知的整體企業(yè)級(jí)解決方案、而不是多種方法的應(yīng)用復(fù)合。
操作簡(jiǎn)單，可實(shí)現(xiàn)零數(shù)據(jù)損失的跨云自動(dòng)化快速恢復(fù)。
Kubernetes容災(zāi)解決方案，不僅需要操作簡(jiǎn)單方便，而且需要對(duì)容器化應(yīng)用的技術(shù)細(xì)節(jié)進(jìn)行有效感知。因此，一個(gè)為Kubernetes原生構(gòu)建的、簡(jiǎn)單、易用、方便的容災(zāi)恢復(fù)方案變得更加重要。
Kubernetes應(yīng)用保護(hù)的主要難點(diǎn)
容器的基本結(jié)構(gòu)原理與虛擬機(jī)有著根本的不同
容器化應(yīng)用與虛擬機(jī)中的應(yīng)用有很大不同。為了有效的保護(hù)和恢復(fù)容器化應(yīng)用，我們需要在分布式系統(tǒng)中編排執(zhí)行一系列復(fù)雜的操作。這是因?yàn)閼?yīng)用是同時(shí)運(yùn)行在多個(gè)容器里的，并且這些容器存在于Kubernetes集群里的不同的節(jié)點(diǎn)之上。
相對(duì)于在過(guò)去15年里我們常見(jiàn)的基于虛擬機(jī)的單體應(yīng)用來(lái)說(shuō)，這是架構(gòu)上的很大不同。
傳統(tǒng)的備份和恢復(fù)方案對(duì)于虛擬機(jī)的應(yīng)用來(lái)說(shuō)已足夠。但是對(duì)于Kubernetes和容器來(lái)說(shuō)，就不再適合。使用傳統(tǒng)的基于VM的備份方案，不僅會(huì)讓你失去對(duì)系統(tǒng)安全的控制，甚至?xí)陉P(guān)鍵時(shí)候?qū)е聭?yīng)用不可用或者數(shù)據(jù)丟失，這是存在較大風(fēng)險(xiǎn)的。
容器應(yīng)用需要智能化的自動(dòng)恢復(fù)
在出現(xiàn)災(zāi)難事件后，恢復(fù)一個(gè)Kubernetes應(yīng)用，并不是僅在另一個(gè)區(qū)域重新啟動(dòng)一個(gè)新容器那么簡(jiǎn)單。簡(jiǎn)單的快照無(wú)法有效確保數(shù)據(jù)的一致性。
容器應(yīng)用的組件都是單獨(dú)部署和單獨(dú)擴(kuò)展的，每個(gè)容器都有自己的容器鏡像、部署配置、狀態(tài)規(guī)則、外部配置、運(yùn)維周期、依賴(lài)關(guān)系和數(shù)據(jù)。配置數(shù)據(jù)和應(yīng)用的商業(yè)邏輯通常是作為元數(shù)據(jù)進(jìn)行存儲(chǔ)，保存在Kubernetes集群上，并且需要被保護(hù)和恢復(fù)，以確保應(yīng)用能夠正常的工作。
今天的容器化應(yīng)用不再僅僅是一個(gè)只包括容器鏡像和數(shù)據(jù)的單體。處于微服務(wù)架構(gòu)下的應(yīng)用，包括前端服務(wù)和中間件層。中間件層包括大量的正在運(yùn)行商業(yè)邏輯的中間件，并且它們都連接到了持久數(shù)據(jù)服務(wù)上。這個(gè)完整的堆棧都需要被作為一個(gè)整體來(lái)進(jìn)行備份和恢復(fù)。
一些流行的數(shù)據(jù)服務(wù)，如Kafka、Cassandra、Elastic、MySQL、MongoDB，是由不同的社區(qū)來(lái)創(chuàng)建的，每一個(gè)的運(yùn)維管理和要求的技能都很不一樣。
分布式數(shù)據(jù)服務(wù)的廣泛采用，要求我們重新思考我們的數(shù)據(jù)保護(hù)機(jī)制，需要同時(shí)考慮數(shù)據(jù)、以及運(yùn)維中的元數(shù)據(jù)。
零數(shù)據(jù)損失情況下的跨云快速恢復(fù)
備份和數(shù)據(jù)保護(hù)是非常重要的。在零數(shù)據(jù)損失的情況下，及時(shí)的恢復(fù)應(yīng)用是容災(zāi)恢復(fù)最重要的目標(biāo)。
超過(guò)53%的組織認(rèn)為，對(duì)于關(guān)鍵應(yīng)用來(lái)說(shuō)，RTO（恢復(fù)時(shí)間目標(biāo)）應(yīng)該小于1個(gè)小時(shí)，但實(shí)際上，超過(guò)50%的應(yīng)用需要1~4小時(shí)來(lái)恢復(fù)。因此為了達(dá)到理想的可用性目標(biāo)，我們還有一定的差距。
對(duì)于商業(yè)組織來(lái)說(shuō)，擁有有效的應(yīng)用保護(hù)和恢復(fù)能力，正在變得越來(lái)越重要。超過(guò)65%的大型組織，已經(jīng)實(shí)施部署了混合云/多云的策略。而其中的31%，正在同時(shí)使用超過(guò)2個(gè)以上的公有云服務(wù)。企業(yè)不可能從每一個(gè)單獨(dú)的基礎(chǔ)設(shè)施服務(wù)商，或者云服務(wù)商那里分別采購(gòu)它們自行定制的解決方案。
Portworx為Kubernetes提供數(shù)據(jù)保護(hù)
Portworx是基于Kubernetes和容器的原生方式構(gòu)建的。我們創(chuàng)建了一系列的存儲(chǔ)和數(shù)據(jù)管理解決方案，專(zhuān)門(mén)來(lái)解決企業(yè)在現(xiàn)代化IT架構(gòu)中面臨的挑戰(zhàn)。
Portworx PX-DR產(chǎn)品的定位，是為了保護(hù)Kubernetes應(yīng)用，以達(dá)到零數(shù)據(jù)損失的快速恢復(fù)，并且賦能團(tuán)隊(duì)可以快速的掌握使用，不需要過(guò)多深入到每一個(gè)容器化應(yīng)用的技術(shù)細(xì)節(jié)。
為Kubernetes原生設(shè)計(jì)
容器化應(yīng)用通?？缍鄠€(gè)主機(jī)，運(yùn)行在多個(gè)容器里。通過(guò)Pods和命名空間來(lái)運(yùn)行。Portworx PX-DR按照原生Pods和命名空間構(gòu)建的方式來(lái)運(yùn)行，從而讓我們可以在容器顆粒度和命名空間層面上來(lái)對(duì)應(yīng)用進(jìn)行保護(hù)。
通過(guò)保護(hù)Pod和整個(gè)命名空間，不論應(yīng)用如何配置或者應(yīng)用如何在集群上跨主機(jī)來(lái)運(yùn)行，我們都可以容易的選擇應(yīng)用并進(jìn)行保護(hù)。
雖然應(yīng)用是復(fù)雜的，我們采用快照操作，就可以對(duì)應(yīng)用進(jìn)行保護(hù)。Portworx的數(shù)據(jù)保護(hù)解決方案，讓我們可以在另一個(gè)Kubernetes集群上快速的恢復(fù)和重啟應(yīng)用，不論集群是位于什么樣/什么位置的云服務(wù)之上。
通過(guò)保護(hù)應(yīng)用、應(yīng)用的配置、以及應(yīng)用的數(shù)據(jù)，Portworx提供了真正的Kubernetes原生容災(zāi)恢復(fù)解決方案。
應(yīng)用可感知
今天的容器化應(yīng)用變的越來(lái)越復(fù)雜：展現(xiàn)技術(shù)、消息流、分析、數(shù)據(jù)存儲(chǔ)，每種技術(shù)都由不同的社區(qū)來(lái)構(gòu)建，并且需要不同的運(yùn)維方法。
為了達(dá)到應(yīng)用的擴(kuò)展性和數(shù)據(jù)保護(hù)，我們要么嚴(yán)格限制我們所采用的技術(shù)的來(lái)源數(shù)量，這會(huì)降低我們的靈活性。或者我們采用有效的解決方案來(lái)原生化的處理各種復(fù)雜性問(wèn)題，從而更快的推動(dòng)數(shù)字化。
這意味著我們可以持續(xù)性的創(chuàng)新和部署新的應(yīng)用，而不需要對(duì)每一個(gè)技術(shù)都有深入的了解。Portworx會(huì)幫助我們完成底層的集成。我們只需要制定我們的應(yīng)用保護(hù)時(shí)間計(jì)劃，來(lái)滿(mǎn)足可用性需要。
跨多云/混合云環(huán)境下的一致性的、可靠的容災(zāi)恢復(fù)?
我們的應(yīng)用并不是處于單一控制的環(huán)境中。即便我們僅僅使用單一的云服務(wù)提供商，我們也會(huì)跨區(qū)域來(lái)部署應(yīng)用。當(dāng)我們使用混合云/多云環(huán)境時(shí)，復(fù)雜度就進(jìn)一步提升。
Portworx PX-DR是按Kubernetes原生的分布式方式構(gòu)建的。能夠交付零數(shù)據(jù)損失（零RPO）和快速恢復(fù)時(shí)間（低RTO）是保持系統(tǒng)穩(wěn)健的重要能力。
當(dāng)應(yīng)用被部署在彼此高速連接的云平臺(tái)上時(shí)，例如，由專(zhuān)線連接的不同區(qū)域的云服務(wù)，Portworx可以幫助我們達(dá)到零RPO和零RTO。這意味著不會(huì)有數(shù)據(jù)損失，并且在發(fā)生問(wèn)題時(shí)，可以即時(shí)恢復(fù)。
如果應(yīng)用部署采用傳統(tǒng)配置方式，如跨不同地理位置的數(shù)據(jù)中心的部署，通過(guò)Portworx，我們可以在幾秒至幾分鐘的時(shí)間內(nèi)恢復(fù)應(yīng)用，并且不會(huì)有數(shù)據(jù)損失。
大多數(shù)企業(yè)的數(shù)據(jù)保護(hù)目標(biāo)是1小時(shí)內(nèi)恢復(fù)應(yīng)用11，使用Portworx PX-DR數(shù)據(jù)保護(hù)，可以讓我們達(dá)到更加快速的恢復(fù)。
如果當(dāng)我們正在使用的某個(gè)云服務(wù)發(fā)生錯(cuò)誤后，而我們的應(yīng)用依然在運(yùn)行，我們的客戶(hù)滿(mǎn)意度會(huì)更高。
加拿大皇家銀行RBC的成功案例
加拿大皇家銀行RBC正在通過(guò)Red Hat OpenShift使用Kubernetes，但是無(wú)法達(dá)到可用性的要求。通過(guò)Portworx企業(yè)級(jí)數(shù)據(jù)管理平臺(tái)和PX-DR，RBC達(dá)到了零RPO、以及小于2分鐘的RPO指標(biāo)。這意味著RBC可以在2分鐘內(nèi)在另一個(gè)數(shù)據(jù)中心恢復(fù)應(yīng)用，而沒(méi)有數(shù)據(jù)損失。
結(jié)論
我們的商業(yè)環(huán)境在快速演進(jìn)，我們的競(jìng)爭(zhēng)對(duì)手在快速追趕。在互聯(lián)網(wǎng)時(shí)代，客戶(hù)的體驗(yàn)是成功的關(guān)鍵，我們無(wú)法允許讓客戶(hù)不快的事情的發(fā)生。
錯(cuò)誤時(shí)常會(huì)出現(xiàn)，服務(wù)中斷時(shí)常會(huì)發(fā)生，云服務(wù)時(shí)常會(huì)宕機(jī)。我們需要一個(gè)強(qiáng)健、靈活和快速的恢復(fù)解決方案，來(lái)保證我們的應(yīng)用能夠持續(xù)性的滿(mǎn)足客戶(hù)的需要。
我們?cè)贙ubernetes上部署的容器化應(yīng)用是我們的增長(zhǎng)引擎，但是容器化應(yīng)用與傳統(tǒng)應(yīng)用有很大的不同。需要有針對(duì)性的通過(guò)Kubernetes和容器的方式來(lái)對(duì)應(yīng)用進(jìn)行保護(hù)。而不是傳統(tǒng)的數(shù)據(jù)保護(hù)方式。
為了讓DevOps能夠充分的發(fā)揮效能，如果每一個(gè)技術(shù)都需要專(zhuān)業(yè)的工程師來(lái)應(yīng)對(duì)，會(huì)極大的增加我們的投入。我們的容災(zāi)恢復(fù)方案需要與這些技術(shù)事先集成，可感知應(yīng)用，這樣通用型的運(yùn)維工程師就可以很好的處理問(wèn)題。
混合云/多云架構(gòu)變得普遍，我們不能允許云服務(wù)提供商的任何錯(cuò)誤對(duì)我們的應(yīng)用造成影響。不論我們選擇什么樣的基礎(chǔ)架構(gòu)服務(wù)商，都應(yīng)確保我們應(yīng)用的可用性。
下一步
Portworx已服務(wù)全球2000強(qiáng)企業(yè)超過(guò)5年。我們理解您的目標(biāo)、您的難點(diǎn)。我們?cè)附哒\(chéng)幫助您。
這里是PX-DR的介紹視頻，歡迎觀看。
