Kubernetes 容災(zāi)解決方案關(guān)鍵能力
我們面臨著不斷地需要實施和部署新的軟件應(yīng)用院促、發(fā)展新的商業(yè)模式筏养、以及吸引新的客戶。通過Kubernetes常拓，我們可以采用云原生方式來進行軟件的開發(fā)渐溶、部署和運維。
基于Kubernetes開發(fā)和運行的應(yīng)用弄抬，對于我們實現(xiàn)我們的商業(yè)目標茎辐，非常重要。但新技術(shù)的導(dǎo)入掂恕，也會要求我們考慮更多：新的開發(fā)方法拖陆、新的團隊、新的工程師懊亡、新的技術(shù)依啰、新的合作伙伴、新的供應(yīng)商店枣、新的挑戰(zhàn)速警。
對CIO們來說叹誉，將關(guān)鍵應(yīng)用轉(zhuǎn)移到Kubernetes上的最大挑戰(zhàn)之一，就是容災(zāi)恢復(fù)能力闷旧。
在投入大量資金開發(fā)了Kubernetes上的應(yīng)用后长豁，我們最擔(dān)心的就是：一旦出現(xiàn)我們無法控制的意外事件，我們的應(yīng)用變得無法訪問鸠匀。如：云供應(yīng)商服務(wù)意外停止蕉斜、數(shù)據(jù)中心電力中斷、云服務(wù)中斷缀棍、網(wǎng)絡(luò)連接中斷等宅此。導(dǎo)致用戶無法訪問應(yīng)用后，用戶滿意度大幅下降爬范。
根據(jù)著名研究機構(gòu)Uptime Institute的報告父腕，通常發(fā)生服務(wù)中斷，一般我們會歸因到第三方服務(wù)上青瀑，如托管服務(wù)供應(yīng)商或云服務(wù)供應(yīng)商璧亮。31%的服務(wù)中斷是由由我們無法控制的因素導(dǎo)致的，如：網(wǎng)絡(luò)錯誤（30%）斥难，IT/軟件錯誤（28%）枝嘶。對于Kubernetes上的應(yīng)用，我們需要一個可靠的容災(zāi)恢復(fù)方案哑诊。
根據(jù)451 Research的報告群扶，對于關(guān)鍵性應(yīng)用來說，57%的應(yīng)用要求RPO<1小時镀裤，48%要求RTO<1小時竞阐。即使是非關(guān)鍵應(yīng)用，也有容災(zāi)恢復(fù)的需求暑劝。這對已經(jīng)滿負荷工作的IT團隊來說都是較大的壓力骆莹。
在這樣的情況下，企業(yè)的IT團隊担猛，需要為諸多企業(yè)級應(yīng)用交付強健的容災(zāi)恢復(fù)方案幕垦。
要點小結(jié)
Portworx解決了云原生Kubernetes應(yīng)用企業(yè)級容災(zāi)的三個關(guān)鍵難點。
基于Kubernetes底層原生開發(fā)的PX-DR:
以Kubernetes原生方式進行保護和恢復(fù)：容器顆粒度的保護毁习、命名空間可感知智嚷。
可應(yīng)用感知的整體企業(yè)級解決方案、而不是多種方法的應(yīng)用復(fù)合纺且。
操作簡單，可實現(xiàn)零數(shù)據(jù)損失的跨云自動化快速恢復(fù)稍浆。
Kubernetes容災(zāi)解決方案载碌，不僅需要操作簡單方便猜嘱，而且需要對容器化應(yīng)用的技術(shù)細節(jié)進行有效感知。因此嫁艇，一個為Kubernetes原生構(gòu)建的朗伶、簡單、易用步咪、方便的容災(zāi)恢復(fù)方案變得更加重要论皆。
Kubernetes應(yīng)用保護的主要難點
容器的基本結(jié)構(gòu)原理與虛擬機有著根本的不同
容器化應(yīng)用與虛擬機中的應(yīng)用有很大不同。為了有效的保護和恢復(fù)容器化應(yīng)用猾漫，我們需要在分布式系統(tǒng)中編排執(zhí)行一系列復(fù)雜的操作点晴。這是因為應(yīng)用是同時運行在多個容器里的，并且這些容器存在于Kubernetes集群里的不同的節(jié)點之上悯周。
相對于在過去15年里我們常見的基于虛擬機的單體應(yīng)用來說粒督，這是架構(gòu)上的很大不同。
傳統(tǒng)的備份和恢復(fù)方案對于虛擬機的應(yīng)用來說已足夠禽翼。但是對于Kubernetes和容器來說屠橄，就不再適合。使用傳統(tǒng)的基于VM的備份方案闰挡，不僅會讓你失去對系統(tǒng)安全的控制锐墙，甚至?xí)陉P(guān)鍵時候?qū)е聭?yīng)用不可用或者數(shù)據(jù)丟失，這是存在較大風(fēng)險的长酗。
容器應(yīng)用需要智能化的自動恢復(fù)
在出現(xiàn)災(zāi)難事件后溪北，恢復(fù)一個Kubernetes應(yīng)用，并不是僅在另一個區(qū)域重新啟動一個新容器那么簡單花枫。簡單的快照無法有效確保數(shù)據(jù)的一致性刻盐。
容器應(yīng)用的組件都是單獨部署和單獨擴展的，每個容器都有自己的容器鏡像劳翰、部署配置敦锌、狀態(tài)規(guī)則、外部配置佳簸、運維周期乙墙、依賴關(guān)系和數(shù)據(jù)。配置數(shù)據(jù)和應(yīng)用的商業(yè)邏輯通常是作為元數(shù)據(jù)進行存儲生均，保存在Kubernetes集群上听想，并且需要被保護和恢復(fù)，以確保應(yīng)用能夠正常的工作马胧。
今天的容器化應(yīng)用不再僅僅是一個只包括容器鏡像和數(shù)據(jù)的單體汉买。處于微服務(wù)架構(gòu)下的應(yīng)用，包括前端服務(wù)和中間件層佩脊。中間件層包括大量的正在運行商業(yè)邏輯的中間件蛙粘，并且它們都連接到了持久數(shù)據(jù)服務(wù)上垫卤。這個完整的堆棧都需要被作為一個整體來進行備份和恢復(fù)。
一些流行的數(shù)據(jù)服務(wù)出牧，如Kafka穴肘、Cassandra、Elastic舔痕、MySQL评抚、MongoDB，是由不同的社區(qū)來創(chuàng)建的伯复，每一個的運維管理和要求的技能都很不一樣慨代。
分布式數(shù)據(jù)服務(wù)的廣泛采用，要求我們重新思考我們的數(shù)據(jù)保護機制边翼，需要同時考慮數(shù)據(jù)鱼响、以及運維中的元數(shù)據(jù)。
零數(shù)據(jù)損失情況下的跨云快速恢復(fù)
備份和數(shù)據(jù)保護是非常重要的组底。在零數(shù)據(jù)損失的情況下丈积，及時的恢復(fù)應(yīng)用是容災(zāi)恢復(fù)最重要的目標。
超過53%的組織認為债鸡，對于關(guān)鍵應(yīng)用來說江滨，RTO（恢復(fù)時間目標）應(yīng)該小于1個小時，但實際上厌均，超過50%的應(yīng)用需要1~4小時來恢復(fù)唬滑。因此為了達到理想的可用性目標，我們還有一定的差距棺弊。
對于商業(yè)組織來說晶密，擁有有效的應(yīng)用保護和恢復(fù)能力，正在變得越來越重要模她。超過65%的大型組織稻艰，已經(jīng)實施部署了混合云/多云的策略。而其中的31%侈净，正在同時使用超過2個以上的公有云服務(wù)尊勿。企業(yè)不可能從每一個單獨的基礎(chǔ)設(shè)施服務(wù)商，或者云服務(wù)商那里分別采購它們自行定制的解決方案畜侦。
Portworx為Kubernetes提供數(shù)據(jù)保護
Portworx是基于Kubernetes和容器的原生方式構(gòu)建的元扔。我們創(chuàng)建了一系列的存儲和數(shù)據(jù)管理解決方案，專門來解決企業(yè)在現(xiàn)代化IT架構(gòu)中面臨的挑戰(zhàn)。
Portworx PX-DR產(chǎn)品的定位，是為了保護Kubernetes應(yīng)用坑匠，以達到零數(shù)據(jù)損失的快速恢復(fù)融欧，并且賦能團隊可以快速的掌握使用咏连，不需要過多深入到每一個容器化應(yīng)用的技術(shù)細節(jié)盯孙。
為Kubernetes原生設(shè)計
容器化應(yīng)用通陈成跨多個主機祟滴，運行在多個容器里。通過Pods和命名空間來運行歌溉。Portworx PX-DR按照原生Pods和命名空間構(gòu)建的方式來運行垄懂，從而讓我們可以在容器顆粒度和命名空間層面上來對應(yīng)用進行保護。
通過保護Pod和整個命名空間痛垛，不論應(yīng)用如何配置或者應(yīng)用如何在集群上跨主機來運行草慧，我們都可以容易的選擇應(yīng)用并進行保護。
雖然應(yīng)用是復(fù)雜的匙头，我們采用快照操作漫谷，就可以對應(yīng)用進行保護。Portworx的數(shù)據(jù)保護解決方案蹂析，讓我們可以在另一個Kubernetes集群上快速的恢復(fù)和重啟應(yīng)用舔示，不論集群是位于什么樣/什么位置的云服務(wù)之上。
通過保護應(yīng)用电抚、應(yīng)用的配置惕稻、以及應(yīng)用的數(shù)據(jù)，Portworx提供了真正的Kubernetes原生容災(zāi)恢復(fù)解決方案蝙叛。
應(yīng)用可感知
今天的容器化應(yīng)用變的越來越復(fù)雜：展現(xiàn)技術(shù)俺祠、消息流、分析借帘、數(shù)據(jù)存儲蜘渣，每種技術(shù)都由不同的社區(qū)來構(gòu)建，并且需要不同的運維方法肺然。
為了達到應(yīng)用的擴展性和數(shù)據(jù)保護蔫缸，我們要么嚴格限制我們所采用的技術(shù)的來源數(shù)量，這會降低我們的靈活性狰挡∥媪洌或者我們采用有效的解決方案來原生化的處理各種復(fù)雜性問題，從而更快的推動數(shù)字化加叁。
這意味著我們可以持續(xù)性的創(chuàng)新和部署新的應(yīng)用倦沧，而不需要對每一個技術(shù)都有深入的了解。Portworx會幫助我們完成底層的集成它匕。我們只需要制定我們的應(yīng)用保護時間計劃展融，來滿足可用性需要。
跨多云/混合云環(huán)境下的一致性的豫柬、可靠的容災(zāi)恢復(fù)?
我們的應(yīng)用并不是處于單一控制的環(huán)境中告希。即便我們僅僅使用單一的云服務(wù)提供商扑浸，我們也會跨區(qū)域來部署應(yīng)用。當我們使用混合云/多云環(huán)境時燕偶，復(fù)雜度就進一步提升喝噪。
Portworx PX-DR是按Kubernetes原生的分布式方式構(gòu)建的。能夠交付零數(shù)據(jù)損失（零RPO）和快速恢復(fù)時間（低RTO）是保持系統(tǒng)穩(wěn)健的重要能力指么。
當應(yīng)用被部署在彼此高速連接的云平臺上時酝惧，例如，由專線連接的不同區(qū)域的云服務(wù)伯诬，Portworx可以幫助我們達到零RPO和零RTO晚唇。這意味著不會有數(shù)據(jù)損失，并且在發(fā)生問題時盗似，可以即時恢復(fù)哩陕。
如果應(yīng)用部署采用傳統(tǒng)配置方式，如跨不同地理位置的數(shù)據(jù)中心的部署赫舒，通過Portworx悍及，我們可以在幾秒至幾分鐘的時間內(nèi)恢復(fù)應(yīng)用，并且不會有數(shù)據(jù)損失号阿。
大多數(shù)企業(yè)的數(shù)據(jù)保護目標是1小時內(nèi)恢復(fù)應(yīng)用11并鸵，使用Portworx PX-DR數(shù)據(jù)保護，可以讓我們達到更加快速的恢復(fù)扔涧。
如果當我們正在使用的某個云服務(wù)發(fā)生錯誤后园担，而我們的應(yīng)用依然在運行，我們的客戶滿意度會更高枯夜。
加拿大皇家銀行RBC的成功案例
加拿大皇家銀行RBC正在通過Red Hat OpenShift使用Kubernetes弯汰，但是無法達到可用性的要求。通過Portworx企業(yè)級數(shù)據(jù)管理平臺和PX-DR湖雹，RBC達到了零RPO咏闪、以及小于2分鐘的RPO指標。這意味著RBC可以在2分鐘內(nèi)在另一個數(shù)據(jù)中心恢復(fù)應(yīng)用摔吏，而沒有數(shù)據(jù)損失鸽嫂。
結(jié)論
我們的商業(yè)環(huán)境在快速演進，我們的競爭對手在快速追趕征讲。在互聯(lián)網(wǎng)時代据某，客戶的體驗是成功的關(guān)鍵，我們無法允許讓客戶不快的事情的發(fā)生诗箍。
錯誤時常會出現(xiàn)癣籽，服務(wù)中斷時常會發(fā)生，云服務(wù)時常會宕機。我們需要一個強健筷狼、靈活和快速的恢復(fù)解決方案瓶籽，來保證我們的應(yīng)用能夠持續(xù)性的滿足客戶的需要。
我們在Kubernetes上部署的容器化應(yīng)用是我們的增長引擎埂材，但是容器化應(yīng)用與傳統(tǒng)應(yīng)用有很大的不同塑顺。需要有針對性的通過Kubernetes和容器的方式來對應(yīng)用進行保護。而不是傳統(tǒng)的數(shù)據(jù)保護方式楞遏。
為了讓DevOps能夠充分的發(fā)揮效能茬暇，如果每一個技術(shù)都需要專業(yè)的工程師來應(yīng)對，會極大的增加我們的投入寡喝。我們的容災(zāi)恢復(fù)方案需要與這些技術(shù)事先集成，可感知應(yīng)用勒奇，這樣通用型的運維工程師就可以很好的處理問題预鬓。
混合云/多云架構(gòu)變得普遍，我們不能允許云服務(wù)提供商的任何錯誤對我們的應(yīng)用造成影響赊颠。不論我們選擇什么樣的基礎(chǔ)架構(gòu)服務(wù)商格二，都應(yīng)確保我們應(yīng)用的可用性。
下一步
Portworx已服務(wù)全球2000強企業(yè)超過5年竣蹦。我們理解您的目標顶猜、您的難點。我們愿竭誠幫助您痘括。
這里是PX-DR的介紹視頻长窄，歡迎觀看。
