哈布爾的讀者們大家好！ 本文的主題將是災難復原工具在AERODISK Engine儲存系統中的實施。 最初，我們想在一篇文章中介紹這兩種工具：複製和 MetroCluster，但不幸的是，文章太長，因此我們將文章分為兩部分。 讓我們從簡單到複雜。 在本文中，我們將設定並測試同步複製 - 我們將刪除一個資料中心，並斷開資料中心之間的通訊通道，看看會發生什麼。
我們的客戶經常問我們有關複製的各種問題，因此在繼續設定和測試副本的實施之前，我們將告訴您一些關於儲存中的複製是什麼的資訊。
一點理論
儲存系統中的複製是同時確保多個儲存系統上的資料同一性的連續過程。 從技術上講，複製是透過兩種方式完成的。
同步複製 – 這是將資料從主儲存系統複製到備份系統，然後兩個儲存系統強制確認資料已被記錄和確認。 經過雙方（兩個儲存系統）確認後，資料才被視為已記錄並可使用。 這可確保參與副本的所有儲存系統上的資料身分得到保證。
這種方法的優點：
- 所有儲存系統上的資料始終相同
缺點：
- 解決方案成本高（快速通訊通道、昂貴的光纖、長波收發器等）
- 距離限制（幾十公里以內）
- 沒有針對邏輯資料損壞的保護措施（如果資料在主儲存系統上損壞（故意或意外），它會在備份系統上自動立即損壞，因為資料總是相同的（這就是悖論）
非同步複製 – 這也是將資料從主儲存系統複製到備份系統，但有一定的延遲，並且不需要另一側確認寫入。 資料記錄到主儲存系統後您可以立即使用，並且在備份儲存系統上資料將在一段時間後可用。 當然，這種情況下資料的身份根本無法得到保證。 備份儲存系統上的資料總是有點「過去」。
異步複製的優點：
- 低成本解決方案（任何通訊通道，光學可選）
- 無距離限制
- 在備份儲存系統上，如果主儲存系統上的資料損壞（至少在一段時間內），資料不會惡化；如果資料損壞，您可以隨時停止副本以防止備份儲存系統上的資料損壞
缺點：
- 不同資料中心的資料總是不相同的
因此，複製模式的選擇取決於業務目標。 如果備份資料中心包含與主資料中心完全相同的資料（即 RPO = 0 的業務要求）對您來說至關重要，那麼您將不得不支付現金並忍受同步的限制複製品。 而如果資料狀態的延遲是可以接受的或根本沒有錢，那麼你肯定需要使用非同步方法。
我們也單獨強調這樣一種模式（更準確地說，是一種拓樸），即城域群集。 在城域叢集模式下，使用同步複製，但與常規副本不同的是，城域叢集允許兩個儲存系統在活動模式下運作。 那些。 活動資料中心和備用資料中心之間沒有分離。 應用程式同時與兩個儲存系統一起工作，這兩個儲存系統物理上位於不同的資料中心。 這種拓樸中發生事故時的停機時間非常短（RTO，通常是幾分鐘）。 在本文中，我們不會考慮 Metrocluster 的實現，因為這是一個非常大且廣泛的主題，因此我們將在下一篇文章中專門討論它，作為本文的延續。
另外，很多時候，當我們談論使用儲存系統進行複製時，很多人都會有一個合理的問題：>「許多應用程式都有自己的複製工具，為什麼要在儲存系統上使用複製？ 是好還是壞？
這裡沒有明確的答案，所以這裡是贊成和反對的論點：
儲存複製的參數：
- 解決方案的簡單性。 使用工具，您可以複製整個資料集，無論負載類型和應用程式如何。 如果您使用應用程式的副本，則必須單獨配置每個應用程式。 如果它們的數量超過 2 個，那麼這將是極其耗費人力和成本的（應用程式複製通常需要為每個應用程式提供單獨的且非免費的許可證。更多資訊請參見下文）。
- 您可以複製任何內容 - 任何應用程式、任何資料 - 並且它將始終保持一致。 許多（大多數）應用程式不具備複製功能，來自儲存系統的副本是提供災難保護的唯一方法。
- 無需為應用程式複製功能支付過多費用。 一般來說，它並不便宜，就像儲存系統副本的許可證一樣。 但儲存複製的License需要支付一次費用，並且應用副本的License需要為每個應用程式單獨購買。 如果有很多這樣的應用程序，那麼它的成本就相當可觀，並且儲存複製的許可證成本就變成九牛一毛了。
反對儲存複製的爭論：
- 從應用程式本身的角度來看，透過應用程式進行副本具有更多功能，應用程式更了解其資料（顯然），因此有更多使用它們的選項。
- 如果使用第三方工具完成複製，某些應用程式的製造商不保證其資料的一致性。 *
* - 有爭議的論文。 例如，一家知名的DBMS製造商很長一段時間以來都官方宣稱，他們的DBMS只能使用他們的手段正常複製，其餘的複製（包括儲存系統）都是「不真實的」。 但生活顯示事實並非如此。 最有可能（但不確定）這根本不是向客戶出售更多許可證的最誠實的嘗試。
因此，在大多數情況下，從儲存系統進行複製會更好，因為這是一個更簡單且成本更低的選項，但是在需要特定應用程式功能的複雜情況下，並且有必要使用應用程式級複製。
理論講完了，現在開始實踐
我們將在實驗室中配置副本。 在實驗室條件下，我們模擬了兩個資料中心（實際上，兩個相鄰的機架似乎位於不同的建築物中）。 該展台由兩個Engine N2儲存系統組成，兩個系統透過光纜相互連接。 執行 Windows Server 2016 的實體伺服器使用 10Gb 乙太網路連接到兩個儲存系統。 展台很簡單，但這並沒有改變本質。
示意性地看起來像這樣：
從邏輯上講，複製的組織方式如下：
現在讓我們看看我們現在擁有的複製功能。
支援兩種模式：非同步和同步。 同步模式受到距離和通訊頻道的限制是合乎邏輯的。 特別是，同步模式需要使用光纖作為實體和 10 Gigabit 乙太網路（或更高）。
支援同步複製距離40公里，資料中心間光通道時延值最大2毫秒。 一般來說，它會在很大的延遲下工作，但在記錄過程中會出現嚴重的減速（這也是合乎邏輯的），因此如果您計劃在資料中心之間進行同步複製，您應該檢查光學質量和延遲。
對於非同步複製的要求並不是那麼嚴格。 更準確地說，他們根本不存在。 任何可用的乙太網路連接都可以。
目前，AERODISK ENGINE 儲存系統支援透過乙太網路協定（透過銅纜或光纖）進行區塊設備 (LUN) 複製。 對於需要透過光纖通道上的 SAN 結構進行複製的項目，我們目前正在添加適當的解決方案，但尚未準備就緒，因此在我們的案例中，僅使用乙太網路。
複製可以在任何 ENGINE 系列儲存系統（N1、N2、N4）之間進行，從初級系統到舊系統，反之亦然。
兩種複製模式的功能完全相同。 以下是有關可用內容的更多詳細資訊：
- 複製“一對一”或“一對一”，即具有主備兩個資料中心的經典版本
- 複製是“一對多”或“一對多”，即一個LUN可以同時複製到多個儲存系統
- 分別啟用、停用和「反向」複製，以啟用、停用或變更複製方向
- 複製可用於 RDG（Raid 分散式組）和 DDP（動態磁碟區）池。 但是，RDG 池的 LUN 只能複製到另一個 RDG。 與DDP相同。
還有很多小功能，但沒有特別列出它們；我們將在設定時提及它們。
設定複製
設定過程非常簡單，由三個階段組成。
- 網絡配置
- 存儲設置
- 設定規則（連接）和映射
設定複製的一個重要點是，前兩個階段應在遠端儲存系統上重複，第三階段僅在主儲存系統上重複。
設定網路資源
第一步是配置傳輸複製流量的網路連接埠。 為此，您需要啟用連接埠並在前端適配器部分設定其 IP 位址。
之後，我們需要建立一個池（在我們的範例中為 RDG）和一個用於複製的虛擬 IP (VIP)。 VIP 是一個浮動 IP 位址，與儲存控制器的兩個「實體」位址（我們剛剛配置的連接埠）綁定。 這將是主複製介面。 如果您需要處理標記流量，您也可以不使用 VIP，而是使用 VLAN 進行操作。
為副本建立 VIP 的流程與為 I/O（NFS、SMB、iSCSI）建立 VIP 沒有太大差異。 在這種情況下，我們建立一個常規 VIP（沒有 VLAN），但一定要表明它是用於複製的（沒有這個指針，我們將無法在下一步中將 VIP 添加到規則中）。
VIP 必須與其浮動的 IP 連接埠位於同一子網路中。
我們在遠端儲存系統上重複這些設置，當然使用不同的 IP。
來自不同儲存系統的VIP可以位於不同的子網路中，最主要的是它們之間有路由。 在我們的範例中，準確顯示了此範例（192.168.3.XX 和 192.168.2.XX）
這樣就完成了網路部分的準備工作。
設定儲存
為副本設定儲存與平常的不同之處僅在於我們透過特殊選單「複製映射」進行對應。 否則一切都與正常設定相同。 現在，按順序。
在先前建立的池R02中，需要建立LUN。 我們來創建它並將其命名為 LUN1。
我們還需要在相同大小的遠端儲存系統上建立相同的LUN。 我們創造。 為了避免混淆，我們將遠端 LUN 稱為 LUN1R
如果我們需要使用一個已經存在的 LUN，那麼在設定副本時，我們需要從主機卸載這個生產性 LUN，然後在遠端儲存系統上建立一個相同大小的空 LUN。
儲存設定已完成，讓我們繼續建立複製規則。
設定複製規則或複製連結
在儲存系統（目前將作為主儲存系統）上建立 LUN 後，我們將儲存系統 1 上的複製規則 LUN1 配置為儲存系統 1 上的 LUN2R。
在“遠端複製”選單中進行設置
讓我們建立一個規則。 為此，您需要指定副本的收件者。 在那裡我們還設定連接的名稱和複製類型（同步或非同步）。
在「遠端系統」欄位中，我們新增儲存系統2。 要新增，您需要使用管理 IP 儲存系統 (MGR) 以及我們將在其中執行複製的遠端 LUN 的名稱（在我們的範例中為 LUN1R）。 僅在新增連線階段才需要控制 IP；複製流量不會透過它們傳輸；先前配置的 VIP 將用於此目的。
在此階段，我們可以為「一對多」拓撲新增多個遠端系統：按一下「新增節點」按鈕，如下圖所示。
在我們的例子中，只有一個遠端系統，因此我們僅限於此。
規則已經準備好了。 請注意，它會自動添加到所有複製參與者上（在我們的例子中有兩個）。 您可以為任意數量的 LUN 和任意方向建立任意數量的此類規則。 例如，為了平衡負載，我們可以將儲存系統1的部分LUN複製到儲存系統2，而將另一部分LUN從儲存系統2複製到儲存系統1。
儲存系統1. 創建後，同步立即開始。
儲存系統2. 我們看到相同的規則，但同步已經結束。
儲存系統1上的LUN1處於Primary角色，即處於活動狀態。 儲存系統1上的LUN2R處於Secondary角色，即在儲存系統1發生故障時處於備用狀態。
現在我們可以將 LUN 連接到主機。
我們將透過 iSCSI 連接，儘管也可以透過 FC 完成。 在副本中透過 iSCSI LUN 設定映射實際上與通常的場景沒有什麼不同，因此我們在此不詳細考慮這一點。 如果有的話，這個過程在文章““。
唯一的區別是我們在“複製映射”選單中建立映射
我們設定映射並將 LUN 提供給主機。 主機看到了 LUN。
我們將其格式化為本機檔案系統。
就這樣，設定完成了。 接下來將進行測試。
測試
我們將測試三個主要場景。
- 定期角色切換次要 > 主要。 需要定期進行角色切換，例如，我們需要在主資料中心執行一些預防性操作，在此期間，為了使資料可用，我們將負載轉移到備份資料中心。
- 緊急角色切換輔助>主（資料中心故障）。 這是複製存在的主要場景，它可以幫助在資料中心完全故障時倖存下來，而無需使公司長時間停頓。
- 資料中心之間的通訊通道中斷。 在由於某種原因資料中心之間的通訊通道不可用的情況下檢查兩個儲存系統的正確行為（例如，挖土機在錯誤的位置挖掘並損壞了暗光學元件）。
首先，我們將開始將資料寫入 LUN（使用隨機資料寫入檔案）。 我們立即看到儲存系統之間的通訊通道正在被利用。 如果您打開負責複製的連接埠的負載監控，這很容易理解。
現在兩個儲存系統都有「有用」的數據，我們可以開始測試了。
以防萬一，讓我們看一下其中一個文件的哈希和並將其寫下來。
定期角色切換
切換角色的操作（更改複製方向）可以在任何儲存系統上完成，但您仍然需要同時存取這兩個系統，因為您需要在主儲存系統上停用映射，並在輔助儲存系統（將成為主儲存系統）上啟用它。 ）。
也許現在出現了一個合理的問題：為什麼不將其自動化？ 答案是：很簡單，複製是一種簡單的災難復原手段，完全基於手動操作。 為了自動化這些操作，有一個 Metrocluster 模式；它是完全自動化的，但其配置要複雜得多。 我們將在下一篇文章中介紹如何設定 Metrocluster。
在主儲存系統上，我們停用映射以確保記錄停止。
然後在「遠端複製」選單中的其中一個儲存系統（無論是主儲存系統還是備份儲存系統）上，選擇我們的連接 REPL1 並點擊「更改角色」。
幾秒鐘後，LUN1R（備份儲存系統）成為主儲存系統。
我們將LUN1R 與儲存系統2 進行對應。
此後，我們的 E: 驅動器會自動連接到主機，只是這次它是從 LUN1R「到達」的。
為了以防萬一，我們比較雜湊值。
同樣。 考試通過了。
故障轉移。 資料中心故障
此時，定期切換後的主儲存系統分別為儲存系統2和LUN1R。 為了模擬事故，我們將關閉兩個儲存控制器2上的電源。
無法再訪問它。
讓我們看看儲存系統 1（目前是備份系統）上發生了什麼。
我們看到主 LUN (LUN1R) 不可用。 日誌、資訊面板以及複製規則本身中均出現錯誤訊息。 因此，來自主機的資料目前不可用。
將 LUN1 的角色改為主 LUNXNUMX。
我正在映射到主機。
確保驅動器 E 出現在主機上。
我們檢查哈希值。
一切都好。 該儲存系統成功地在活躍的資料中心倒塌後倖存下來。 我們連接複製「反轉」以及從備份資料中心連接 LUN 所花費的時間約為 3 分鐘。 很明顯，在實際生產中，一切都要複雜得多，除了儲存系統的操作之外，您還需要在網路、主機和應用程式中執行更多操作。 而在人生這段時間會更長。
這裡我想寫的是，一切，測試已經成功完成，但我們不要急。 主儲存系統正在“躺著”，我們知道當它“倒下”時，它處於Primary角色。 如果它突然亮起會發生什麼事？ 會有兩個Primary角色，這等於資料損壞嗎？ 我們現在檢查一下。
讓我們突然打開底層儲存系統。
它會載入幾分鐘，然後在短暫同步後返回服務，但扮演輔助角色。
一切都好。 裂腦並沒有發生。 我們考慮過這一點，並且總是在跌倒後，儲存系統會上升到輔助角色，無論它「在生命期間」扮演什麼角色。 現在我們可以肯定地說資料中心故障測試是成功的。
資料中心之間的通訊通道故障
此測試的主要任務是確保儲存系統在兩個儲存系統之間暫時失去通訊通道然後再次出現時不會出現異常行為。
所以。 我們斷開儲存系統之間的電線（假設它們是由挖掘機挖掘的）。
在 Primary 上，我們看到與 secondary 沒有任何聯繫。
在次要節點上，我們看到與主要節點沒有任何關聯。
一切正常，我們繼續向主儲存系統寫入數據，即保證它們與備份的不同，即它們已經「分離」了。
幾分鐘後我們就「修復」了溝通管道。 一旦儲存系統相互看到，就會自動啟動資料同步。 這裡不需要管理員做任何事。
一段時間後，同步完成。
連線恢復，通訊通道遺失沒有造成任何緊急狀況，開機後自動同步。
發現
我們分析了這個理論──需要什麼，為什麼，優點在哪裡，缺點在哪裡。 然後我們在兩個儲存系統之間設定同步複製。
接下來，對正常切換、資料中心故障和通訊通道故障進行了基礎測試。 在所有情況下，儲存系統都運作良好。 對於手動場景，不會出現資料遺失，並且管理操作也保持在最低限度。
下次我們將使情況複雜化，並展示所有這些邏輯如何在主動-主動模式下的自動化城域叢集中工作，也就是說，當兩個儲存系統都是主儲存系統時，並且儲存系統故障時的行為是完全自動化的。
請寫下評論，我們很高興收到合理的批評和實用的建議。
直到下一次。
來源： www.habr.com