災難恢複
明確災難恢複模式等進行數據分析平台是至關重要的磚。Beplay体育安卓版本對一些公司來說,這是至關重要的,你的團隊可以使用磚平台數據即使在罕見的情況下區域service-wide雲服務提供者中斷,是否引起的地區災難就像一個颶風或地Beplay体育安卓版本震或其他來源。
磚通常是一個生態係統整體數據的核心部分,包括許多服務,包括上遊數據攝入服務(批/流),原生雲存儲,如Amazon S3,下遊的工具和服務,如商業智能應用程序,和編製工具。你的一些用例可能特別敏感地區service-wide停機。
本文描述的概念和一個成功的災難恢複解決方案的最佳實踐的磚統一的分析平台。Beplay体育安卓版本每個組織都是不同的,所以如果你有當部署自己的解決方案的問題,請聯係您的磚的代表。
重要的
這篇文章提到了這個詞數據平麵,這是計算層磚平台。Beplay体育安卓版本在本文的上下文中,平麵是指經典數據平麵在AWS帳戶。相比之下,Serverless飛機數據支持Serverless SQL端點(公共預覽版)在磚AWS帳戶運行。欲了解更多,請看Serverless計算。
災難恢複的概述
災難恢複是一套策略、工具和程序,使重要的技術基礎設施和係統的恢複或延續自然或人為災難。大雲服務AWS服務許多客戶和內置的防範一個失敗。beplay体育app下载地址例如,區域是一組建築物連接到不同的電源保證單個功率損耗不會關閉。然而,雲地區的失敗可能發生,破壞的程度及其對組織的影響也各不相同。
在實施災難恢複計劃之前,重要的是要理解之間的差異災難恢複(博士),高可用性(公頃)。
高可用性是一個係統的彈性特征。高可用性保證最低級別的操作性能通常定義的一致的正常運行時間或正常運行時間的百分比。高可用性實現到位(在同一地區作為你的主係統)設計主係統的一個特征。例如,像AWS雲服務高可用性服務,如Amazon S3。高可用性不需要從磚客戶重要的明確的準備。
相比之下,一個災難恢複計劃需要決策和解決方案,為您的特定組織工作為關鍵係統處理一個更大的地區停電。本文討論了常見的災難恢複的術語,常見的解決方案,和一些最佳實踐與磚的災難恢複計劃。
術語
地區的術語
本文使用以下定義區域:
主要地區:用戶運行一個典型的日常互動的地理區域和自動數據分析工作負載。
二級區域:IT團隊的地理區域數據分析工作負載暫時停機期間的主要地區。
Geo-redundant存儲:AWSgeo-redundant存儲各地區堅持桶使用異步存儲複製過程。
重要的
對於災難恢複過程,磚建議不依靠geo-redundant存儲區域的重複數據,如根S3 bucket。一般來說,使用深克隆表和數據轉換為δ格式使用深克隆如果可能對其他數據格式。
部署狀態的術語
本文使用以下定義的部署狀態:
積極部署:用戶可以連接到一個積極部署磚工作區和運行的工作負載。工作計劃定期使用磚調度器或其他機製。數據流可以在此部署執行。一些文件可能引用作為一個活躍的部署熱部署。
被動的部署:過程不運行在一個被動的部署。IT團隊可以設置自動程序部署代碼,配置,和其他磚的被動對象的部署。部署變得活躍隻有如果當前活動的部署。一些文件可能指的是作為一個被動的部署寒冷的部署。
重要的
一個項目可以包含多個被動部署在不同地區提供額外的選項來解決地區斷電。
一般來說,一個團隊隻有一個積極部署,所謂的一個主被動災難恢複策略。有一個不太常見的災難恢複解決方案策略active - active中,有兩個同時積極部署。
災難恢複行業術語
有兩個重要的行業術語,你必須為你的團隊理解和定義:
恢複點目標:一個恢複點目標(RPO)最大的目標是在數據(事務)可能會失去從IT服務由於重大事件。你的磚部署不存儲你的主要客戶數據。存儲在單獨的係統,如Amazon S3或者其他數據源在你的控製之下的。磚控製飛機在部分或全部存儲一些對象,如就業和筆記本。磚,RPO是定義為對象,如工作的最大目標段和筆記本變化可能會丟失。另外,你對自己的客戶負責定義RPO Amazon S3或其他數據源中的數據在你的控製之下的。
恢複時間目標:恢複時間目標(RTO)是有針對性的持續時間和服務水平在一個業務流程必須災後恢複。
災難恢複和數據腐敗
一個災難恢複解決方案不減少數據丟失。破損的數據複製的主要地區的主要地區二級區域,這兩個地區的損壞。還有其他方法來緩解這種失敗,例如三角洲時間旅行。
典型的複蘇工作流
磚災難恢複場景通常在以下方式:
故障發生在一個關鍵服務使用在您的主要地區。這可能是一個影響磚的數據源服務或網絡部署。
你與雲提供商調查情況。
如果你認為你的公司不能等待要矯正的問題在主要地區,你可能會決定你需要故障轉移到次要的地區。
確認同樣的問題也不影響你的二級地區。
故障轉移到次要的地區。
在工作區中停止一切活動。用戶停止工作負載。用戶或管理員要求最近的變化如果可能的話進行備份。工作是關閉,如果他們還沒有失敗由於停機。
在二級地區啟動恢複過程。恢複過程更新路由和重命名的二級地區的連接和網絡流量。
測試後,申報二級地區運營。現在可以恢複生產工作負載。用戶可以登錄到現在積極部署。你可以再觸發器或延誤工作。
在磚上下文中詳細步驟,請參閱測試故障轉移。
在某種程度上,問題的主要地區是減輕和你確認這個事實。
恢複(失敗)你的主要地區。
停止所有工作在二級地區。
啟動恢複過程的主要地區。恢複過程處理路由和重命名的連接和網絡流量的主要地區。
複製數據所需的主要地區。降低複雜性,也許減少多少數據需要被複製。例如,如果有些工作是隻讀的運行時部署在二級,你可能不需要複製數據回到你的主要部署在主要地區。然而,你可能有一個生產工作,需要運行,可能需要數據複製回的主要地區。
測試部署的主要地區。
聲明你的主要地區作戰,積極部署。恢複生產工作負載。
對恢複您的主要地區的更多信息,見測試恢複(退回)。
重要的
在這些步驟中,一些數據可能發生的損失。您的組織必須定義數據丟失多少是可以接受的,你能做什麼來減輕這種損失。
第一步:了解您的業務需求
你的第一步是定義和理解您的業務需求。定義哪些數據服務是至關重要的,什麼是他們的預期RPO, RTO。
研究每個係統的實際公差,請記住,災難恢複故障轉移和退回可以是昂貴和有其他風險。其他風險可能包括數據丟失、數據複製如果你寫錯誤的存儲位置,和用戶登錄並修改錯誤的地方。
地圖上所有的磚集成點,影響您的業務:
你的災難恢複解決方案需要適應互動流程,自動化流程,或都有?
你使用哪個數據服務?一些可能是內部。
輸入數據到雲中如何?
誰使用這些數據?什麼流程下遊消費嗎?
有第三方集成需要意識到災難恢複變化?
確定工具或傳播策略能夠支持災難恢複計劃:
你們將使用什麼工具來修改網絡配置快?
你能預先確定您的配置,使其模塊化,以適應災難恢複解決方案在自然和可維護的方式?
通訊工具和渠道將通知內部團隊和第三方(集成,下遊消費者)災難恢複故障轉移和退回變化?和你將如何確認確認?
需要什麼工具或特殊支持嗎?
如果有哪些服務將被關閉,直到完全恢複?
步驟2:選擇一個過程,滿足您的業務需求
你的解決方案必須複製正確的數據在兩種控製平麵,數據平麵和數據來源。冗餘的工作區災難恢複必須映射到不同的控製飛機在不同地區。你必須保持數據同步定期使用基於腳本解決方案,一個同步工具或CI / CD工作流。不需要同步數據從內部數據平麵網絡本身,如磚運行時的工人。
如果你使用customer-managed VPC特性(無法獲得與所有訂閱和部署類型),你可以使用基於模板的這兩個地區的持續部署這些網絡工具等起程拓殖。
此外,您需要確保您的數據來源是根據需要複製的跨區域。
一般的最佳實踐
一般成功的災難恢複計劃的最佳實踐包括:
理解哪些流程關鍵業務,必須在災難恢複運行。
清楚地識別哪些服務,數據處理,數據流是什麼和在哪裏存儲
隔離和數據盡可能的服務。例如,創建一個特殊的雲存儲容器的數據災難恢複或移動磚對象需要在災難的一個單獨的空間。
是你的責任來維護完整性中小學部署其他對象之間不存儲在磚控製飛機。
警告
這是一個最佳實踐不將任何數據元素存儲在根Amazon S3 bucket用於根DBFS訪問工作區。根DBFS存儲客戶數據不支持生產。但是,你可以存儲其他對象(如圖書館、配置文件、init腳本,和類似的數據。開發一個自動化過程複製這些對象,或者記住流程更新二次部署為手動部署。
為數據來源,在可能的情況下,建議您使用本機AWS工具複製和冗餘複製數據到災難恢複的地區。
選擇一個恢複解決方案策略
典型的災難恢複解決方案包含兩個(或更多)工作區。你可以選擇有幾種策略。考慮潛在的破壞長度(小時甚至一天),努力確保工作區是全麵運行,並努力恢複(失敗)的主要地區。
主被動解決方案策略
一個被動的解決方案是最常見和最簡單的解決方案,和這種類型的解決方案是本文的重點。解決方案的一個主動-被動同步數據和對象變化從你積極部署你的被動部署。如果你喜歡,你可以有多個被動部署在不同的地區,但本文主要關注單一被動的部署方法。在事件中,災難恢複的被動部署在二級地區成為你積極部署。
有兩種主要的變異的策略:
統一(enterprise-wise)解決方案:一個主動和被動的部署,支持整個組織。
解決方案由部門或項目:每個部門或項目領域維護一個單獨的災難恢複解決方案。一些組織想解耦災難恢複細節部門之間和使用不同的主要和次要區域為每個團隊根據每個團隊的獨特需求。
還有其他的變種,如使用被動部署為隻讀的用例。如果你有工作負載是隻讀的,例如用戶查詢,他們可以在任何時候運行在一個被動的解決方案如果不修改數據或磚對象如筆記本或工作。
active - active解決方案策略
在一個active - active的解決方案,您運行所有數據進程並行在這兩個地區。運營團隊必須確保數據流程等工作僅標記為完成當它完成成功地在這兩個地區。對象不能更改在生產中,必須遵循嚴格的CI / CD從開發/分段生產推廣。
一個active - active的解決方案是最複雜的策略,因為這兩個地區的工作運行,有額外的財務成本。
正如主被動策略,可以實現這個解決方案或由部門統一組織。
你可能不需要一個等價的工作區中所有工作區輔助係統,根據您的工作流程。例如,也許開發或分期工作區可能不需要一個副本。用精心設計的開發過程,你可以重建這些工作區容易如果需要。
選擇你的工具
主要有兩種方法工具保持數據盡可能相似的工作區之間在你的主要和次要區域:
同步客戶端複製從主要到次要的:同步客戶端將生產數據和資產的主要地區二級地區。這通常運行在一個預定的基礎。
CI / CD為並行部署工具:對於生產代碼和資產,使用CI / CD的工具同時推動改變生產係統這兩個地區。例如,當把代碼和資產分期/從開發到生產,CI / CD係統使得它可以在這兩個地區在同一時間。的核心思想是將所有工件在磚infrastructure-as-code工作區。大多數工件可以重新部署到初級和二級工作區,雖然有些工件可能隻需要部署災後複蘇的事件。工具,請參閱自動化腳本、樣品和原型。
下圖對比這兩種方法。
根據您的需要,您可以結合的方法。例如,使用CI / CD筆記本源代碼,但使用同步配置池和訪問控製等。
下表描述了如何處理不同類型的數據,每個工具的選擇。
描述 |
如何處理與CI / CD工具嗎 |
如何處理與同步工具 |
|---|---|---|
源代碼:筆記本源包裝出口和源代碼庫 |
Co-deploy主要和次要的。 |
同步源代碼從主要到次要的。 |
用戶和組 |
在Git管理元數據配置。另外,使用相同的身份提供商(IdP)為工作區。Co-deploy用戶和組數據主要和次要的部署。 |
使用SCIM對這兩個地區或其他自動化。手動創建不使用推薦的,但是如果必須同時完成。如果使用手動設置,創建一個調度自動化流程比較兩國部署的用戶和組列表。 |
池配置 |
可以在Git模板。Co-deploy中小學。然而, |
池創建任何 |
工作配置 |
可以在Git模板。主要部署,部署工作定義。二次部署,部署工作,將並發設置為零。這禁用的工作部署和防止額外的運行。改變後並發值二次部署變得活躍。 |
如果工作在現有運行 |
訪問控製列表(acl) |
可以在Git模板。Co-deploy中小學部署筆記本,文件夾,和集群。然而,持有的數據工作,直到災難恢複活動。 |
的權限API 2.0可以為集群設置訪問控製、工作、池,筆記本,文件夾。同步客戶端需要為每一個對象映射到相應的對象id在二級工作區。磚建議創建一個地圖對象的id從初級到中級工作區而同步這些對象之前複製的訪問控製。 |
庫 |
包括源代碼和集群/工作模板。 |
從集中式存儲庫同步自定義庫、DBFS或雲存儲(可以安裝)。 |
如果你喜歡包含在源代碼。 |
對於簡單的同步,init腳本存儲在主工作區在公共文件夾或在一個小的文件夾,如果可能的話。 |
|
掛載點 |
包含在源代碼中如果隻有通過notebook-based或創造就業機會命令API。 |
使用工作。注意,存儲端點可能會改變,因為工作區將會在不同地區。這在很大程度上取決於你的數據災難恢複策略。 |
表元數據 |
包括源代碼如果隻有通過notebook-based或創造就業機會命令API。這適用於內部磚metastore metastore或外部配置。 |
比較metastores之間的元數據定義使用火花目錄API或顯示創建表通過筆記本或腳本。注意,表底層存儲可以提出,將不同metastore實例。 |
秘密 |
如果隻有通過創建包含在源代碼命令API。注意,一些機密內容可能需要中小學之間的變化。 |
秘密是兩個工作區中創建通過API。注意,一些機密內容可能需要中小學之間的變化。 |
集群配置 |
可以在Git模板。Co-deploy中小學部署,盡管次要的部署應該終止,直到災難恢複活動。 |
創建集群後同步到二級工作區使用API或CLI。這些可以明確如果你想終止,根據auto-termination設置。 |
筆記本,工作,和文件夾權限 |
可以在Git模板。Co-deploy中小學部署。 |
複製使用權限API 2.0。 |
選擇區域和多個二級工作區
你需要完全控製你的災難恢複觸發。你可以決定觸發這個在任何時間或任何理由。你必須負責災難恢複穩定才能重新啟動操作退回(正常生產)模式。通常這意味著您需要創建多個磚工作區來滿足您的生產和災難恢複的需求,並選擇你的二次故障轉移。
在AWS,您可以選擇中等地區的完全控製。確保你所有的可用資源和產品,如EC2。一些磚服務是可用的隻有在一些地區。如果你的磚E2版本的平台賬戶,你必須選擇在支持AWS E2版本的平台區域。Beplay体育安卓版本
第三步:準備工作區和做一次性複製
如果一個工作區已經在生產中,它是典型的運行一次性複製操作同步你的被動部署積極部署。這一次複製處理如下:
數據複製:複製使用雲複製解決方案或δ深克隆操作。
令牌生成:使用令牌生成自動複製和未來的工作負載。
工作區複製使用描述的方法:使用工作區複製第四步:準備數據源。
工作區驗證:測試確保工作區和流程可以執行成功,並提供預期的結果。
初始一次性複製操作之後,隨後的複製和同步行動更快,任何日誌記錄從你的工具也是一個日誌的改變,當它改變。
第四步:準備數據源
磚可以處理多種數據源使用批處理或數據流。
批處理數據來源
在批處理數據時,它通常駐留在一個數據源,很容易被複製或傳遞到另一個地區。
例如,數據可能會被上傳到雲存儲位置。在災難恢複模式下對你的二級地區,您必須確保文件將上傳到您的二級地區存儲。工作負載必須閱讀二級區域存儲和寫入二級區域存儲。
數據流
處理數據流是一個更大的挑戰。流數據可以從各種來源攝取、處理和發送到流媒體解決方案:
消息隊列,如卡夫卡
數據庫變化數據捕獲流
基於文件的連續處理
基於文件的安排處理,也稱為觸發一次
在所有這些情況下,您必須配置您的數據源處理災難恢複模式和使用你的二級地區二級部署。
流作家存儲檢查點與被處理的數據信息。該檢查點可以包含一個數據位置(通常是雲存儲),已被修改成一個新位置,以確保一個成功重啟的流。例如,源子文件夾下檢查點可能雲存儲文件的文件夾。
必須及時複製該檢查點。考慮同步檢查點間隔的任何新的雲複製解決方案。看到好流的例子。
作家的檢查點更新是一個函數,因此適用於數據流攝入或處理和存儲在另一個流源。
對於流媒體工作負載,確保配置在customer-managed存儲檢查點,這樣他們就可以被複製到二級地區工作負載恢複從去年的失敗。你也可以選擇在並行運行二次流過程的主要過程。
第五步:實現和測試您的解決方案
定期測試災難恢複設置,以確保其功能正常。沒有價值在維護一個災難恢複解決方案如果你不能使用它,當你需要它。一些公司之間切換地區每隔幾個月。定期切換區域測試假設和流程,確保他們滿足你的恢複的需求。這也確保您的組織的政策和程序熟悉緊急情況。
重要的
在現實條件下定期測試災難恢複解決方案。
如果你發現你失蹤一個對象或模板和仍然需要依靠信息存儲在主工作區,修改你的計劃來消除這些障礙,複製這個信息在二級係統,或在其他方式使其可用。
測試所需的組織變更流程和配置。災難恢複計劃影響您的部署管道,重要的是,你的團隊知道需要保持同步。建立災難恢複工作後,您必須確保您的基礎設施(手動或代碼),工作,筆記本,圖書館,和其他工作區對象在你的二級地區。
與您的團隊討論如何擴大標準工作流程和配置管道將更改部署到所有工作區。在所有工作區管理用戶身份。記得要配置工具,如工作自動化和監測新工作區。
計劃和測試修改配置工具:
攝入:了解你的數據來源是哪裏,那些得到他們的數據來源。在可能的情況下,參數化源和確保你有一個單獨的配置模板來處理你的二級和二級地區部署。準備一份計劃,故障轉移和測試所有的假設。
執行變更:如果你有一個調度器觸發工作或其他操作,您可能需要配置一個獨立的調度程序,適用於二級部署或其數據源。準備一份計劃,故障轉移和測試所有的假設。
交互式連接:考慮如何配置、驗證和網絡連接可能會影響區域中斷任何使用REST api, CLI工具,或其他服務,如JDBC / ODBC。準備一份計劃,故障轉移和測試所有的假設。
自動化的變化:自動化工具,準備一個計劃為故障轉移和測試所有的假設。
輸出:對於任何工具,生成輸出數據或日誌,準備一個計劃為故障轉移和測試所有的假設。
測試故障轉移
災難恢複可以由許多不同的場景。它可以由一個意想不到的休息。一些核心功能可能發生故障,包括雲計算網絡,雲存儲,或者另一個核心服務。您沒有訪問關閉係統優雅和必須努力恢複。然而,這個過程可以由關機或停機計劃,甚至通過周期性切換兩個地區之間的積極部署。
當你測試故障轉移時,連接到係統並運行一個關閉的過程。確保所有工作完成和集群被終止。
同步客戶端(或CI / CD工具)可以複製相關數據磚二級工作區對象和資源。激活你的二級工作區,過程可能包括下列部分或全部:
平台運行測試確認是最新的。Beplay体育安卓版本
在主節點上禁用池和集群地區,如果沒有在線服務返回,不開始處理新的數據的主要區域。
恢複過程:
檢查最新的同步數據的日期。看到災難恢複行業術語。這一步的細節變化基於如何同步數據和您的獨特的業務需求。
穩定你的數據源,並確保他們都是可用的。包括所有的外部數據源,如AWS RDS,以及三角洲湖,拚花,或其他文件。
找到你的流恢複點。設置過程從那裏重新開始,有一個準備過程識別和消除潛在的重複(三角洲湖湖使這更容易)。
完成數據流過程和通知用戶。
開始相關池(或增加
min_idle_instances相關數字)。啟動相關的集群(如果不是終止)。
改變工作和運行的並發運行的相關工作。這可能是一次性或定期運行運行。
任何外部工具,它使用一個URL或域名磚工作區,更新配置占新的控製飛機。例如,更新url REST api和JDBC / ODBC連接。磚的web應用程序的麵向客戶的URL更改控製平麵的變化,所以通知您組織的用戶的新URL。
測試恢複(退回)
退回可以做更容易控製和維護窗口。這個計劃可以包括下列部分或全部:
得到確認的主要地區是恢複。
禁用池和集群在二級地區所以它不會開始處理新的數據。
同步任何新的或修改資產在二級工作區主要部署。根據您的故障轉移腳本的設計,您可以運行相同的腳本,以同步對象從二級(災難恢複)地區主要的(生產)區域。
任何新的數據更新同步回主部署。您可以使用日誌和三角洲表的審計跟蹤保證不丟失數據。
在災難恢複地區關閉所有工作負載。
改變工作和用戶的URL的主要地區。
平台運行測試確認是最新的。Beplay体育安卓版本
開始相關池(或增加
min_idle_instances數量有關)。啟動相關的集群(如果不是終止)。
改變工作的並發運行,運行相關工作。這可能是一次性或定期運行運行。
再根據需要,設置二級地區未來的災難恢複。
自動化腳本、樣品和原型
自動化腳本考慮為您的災難恢複項目:
磚建議您使用磚起程拓殖的提供者幫助開發自己的同步過程。
另請參閱磚工作區遷移工具示例腳本自動化和原型。
的磚同步(DBSync)項目是一個對象同步工具,備份,恢複和同步數據磚工作區。