哈布爾的讀者們大家好！ 在上一篇文章中，我們討論了AERODISK ENGINE儲存系統中一種簡單的災難復原手段—複製。 在這篇文章中，我們將深入探討一個更複雜、更有趣的主題——城域集群，也就是對兩個資料中心進行自動化災難保護的手段，讓資料中心能夠以雙活模式運作。 我們會告訴你、向你展示、打破它並修復它。
像往常一樣，理論第一
都市集群是分佈在城市或地區內多個站點的集群。 「集群」這個詞清楚地向我們暗示，複雜性是自動化的，即在發生故障時自動切換集群節點。
這是城域集群和常規複製之間的主要區別所在。 操作自動化。 也就是說，當發生某些事件（資料中心故障、通道中斷等）時，儲存系統將獨立執行必要的操作，以維持資料可用性。 使用常規副本時，這些操作完全或部分由管理員手動執行。
它有什麼作用？
客戶在使用某些城域群集實作時追求的主要目標是最大限度地減少 RTO（恢復時間目標）。 即盡量減少IT服務故障後的恢復時間。 如果您使用常規複製，恢復時間將始終比城域群集的恢復時間長。 為什麼？ 很簡單。 管理員必須在辦公桌前手動切換複製，而 Metrocluster 會自動執行此操作。
如果沒有專門的管理員值班，不睡覺、不吃飯、不抽煙、不生病，24小時監視儲存系統的狀態，那麼就沒有辦法保證管理員會在故障期間可進行手動切換。
因此，在沒有城域叢集或沒有99級管理員值班服務的不朽管理員的情況下，RTO將等於所有系統的切換時間與保證管理員開始工作的最大時間段之和與儲存系統和相關係統。
由此，我們得出一個明顯的結論：如果RTO的要求是分鐘而不是小時或天，那麼就應該使用城域集群，即當資料中心發生最嚴重的故障時，IT部門必須為業務提供時間在幾分鐘甚至幾秒鐘內恢復對IT 服務的存取。
它是如何工作的呢？
在較低級別，metrocluster 使用同步資料複製機制，我們在上一篇文章中對此進行了描述（請參閱）。 ）。 由於複製是同步的，因此它的要求是相應的，或者更確切地說：
- 光纖作為物理，10吉比特乙太網路（或更高）；
- 資料中心之間的距離不超過40公里；
- 資料中心之間（儲存系統之間）光通道延遲最高5毫秒（最佳2毫秒）。
所有這些要求本質上都是建議性的，也就是說，即使不滿足這些要求，城域叢集也會工作，但我們必須明白，不遵守這些要求的後果等於兩個儲存系統的運行速度減慢。都市集群。
那麼，同步副本用於在儲存系統之間傳輸數據，副本如何自動切換，最重要的是如何避免腦裂？ 為此，在更高層級上使用了一個附加實體 - 仲裁器。
仲裁員如何工作以及他的任務是什麼？
仲裁器是一個小型虛擬機器或硬體集群，必須在第三個站點（例如，在辦公室中）啟動，並透過 ICMP 和 SSH 提供對儲存系統的存取。 啟動後，仲裁器應設定IP，然後從儲存側指示其位址，以及參與城域叢集的遠端控制器的位址。 此後，裁判員就可以開始工作了。
仲裁器持續監控 Metrocluster 中的所有儲存系統，如果特定儲存系統不可用，則在確認叢集的另一個成員（「即時」儲存系統之一）不可用後，決定啟動切換複製規則的流程和測繪。
非常重要的一點。 仲裁器必須始終位於與儲存系統不同的地點，即既不在安裝儲存系統1的資料中心1中，也不在安裝儲存系統2的資料中心2中。
為什麼？ 因為這是仲裁員在倖存的儲存系統之一的幫助下，能夠明確且準確地確定安裝儲存系統的兩個站點中任何一個的崩潰的唯一方法。 放置仲裁器的任何其他方法都可能導致腦裂。
現在讓我們深入了解仲裁員的工作細節。
仲裁器運行多個服務，不斷輪詢所有儲存控制器。 如果輪詢結果與前一個不同（可用/不可用），則將其記錄在一個小型資料庫中，該資料庫也適用於仲裁器。
讓我們更詳細地看看仲裁員的工作邏輯。
步驟 1：確定不可用性。 儲存系統故障事件是指同一儲存系統的兩個控制器在 5 秒內沒有 ping 通。
步驟 2. 啟動切換過程。 仲裁器意識到其中一個儲存系統無法使用後，他會向「活動」儲存系統發送請求，以確保「死亡」儲存系統確實已死亡。
在從仲裁器接收到這樣的命令之後，第二（活動）儲存系統另外檢查失效的第一儲存系統的可用性，並且如果不存在，則向仲裁器發送其猜測的確認。 儲存系統確實不可用。
收到此類確認後，仲裁器啟動遠端流程，用於切換複製並提高在故障儲存系統上的活動（主）副本上的映射，並向第二儲存系統發送命令以將這些副本從輔助副本更改為主副本，並且提高映射。 那麼，第二個儲存系統會相應地執行這些過程，然後提供對遺失的 LUN 的存取。
為什麼需要額外的驗證？ 對於法定人數。 也就是說，奇數 (3) 個叢集成員中的大多數必須確認叢集節點之一的故障。 只有這樣，這個決定才絕對正確。 為了避免錯誤切換以及相應的裂腦，這是必要的。
時間步驟 2 大約需要 5 - 10 秒，因此，考慮到確定不可用所需的時間（5 秒），在事故發生後 10 - 15 秒內，故障存儲系統中的 LUN 將自動可用於正常工作。存儲系統。
顯然，為了避免失去與主機的連接，您還需要注意正確配置主機上的逾時。 建議的超時時間至少為 30 秒。 這樣可以防止發生災難時主機在負載切換時切斷與儲存系統的連接，並且可以確保不會出現I/O中斷。
等一下，事實證明，如果 Metrocluster 一切都那麼好，為什麼我們還需要定期複製呢？
事實上，一切都沒有那麼簡單。
讓我們考慮一下 Metrocluster 的優缺點
因此，我們意識到，與傳統複製相比，城域群聚的明顯優勢是：
- 全自動化，確保災難發生時復原時間最短；
- 就這樣 ：-）。
現在，請注意缺點：
- 解決方案成本。 儘管 Aerodisk 系統中的 Metrocluster 不需要額外的許可（與副本使用相同的許可），但該解決方案的成本仍然比使用同步複製更高。 您將需要實現同步副本的所有要求，以及與附加交換和附加站點相關的城域集群的要求（請參閱城域集群規劃）；
- 解決方案的複雜性。 Metrocluster 比常規副本複雜得多，需要更多的關注和精力來規劃、配置和記錄。
最終。 當您確實需要在幾秒鐘或幾分鐘內提供 RTO 時，Metrocluster 無疑是一個技術非常先進且良好的解決方案。 但如果沒有這樣的任務，而且幾小時內的 RTO 對業務來說是可以的，那麼砲打麻雀就沒有意義了。 通常的工農複製就足夠了，因為都市集群會導致 IT 基礎設施的額外成本和複雜化。
城域群聚規劃
本節並不聲稱是城域集群設計的綜合指南，而只是展示瞭如果您決定建造這樣一個系統時應該制定的主要方向。 因此，在實際實施metrocluster時，一定要讓儲存系統廠商（也就是我們）和其他相關係統進行協商。
場地
如上所述，城域集群至少需要三個站點。 儲存系統和相關係統將運作的兩個資料中心，以及仲裁員將工作的第三個站點。
資料中心之間的建議距離不超過40公里。 較大的距離很可能會導致額外的延遲，這在城域集群的情況下是非常不受歡迎的。 我們提醒您，延遲最多應為 5 毫秒，但建議將延遲控制在 2 毫秒以內。
建議在規劃過程中檢查延誤。 任何在資料中心之間提供光纖的或多或少成熟的提供者都可以很快組織品質檢查。
至於仲裁員先前的延遲（即第三個站點和前兩個站點之間），建議的延遲閾值最多為 200 毫秒，即透過 Internet 的常規企業 VPN 連線是合適的。
交換和網絡
與複製方案不同的是，複製方案只需連接不同站點的儲存系統即可，而城域叢集方案則需要將不同站點的主機與兩個儲存系統連接起來。 為了更清楚地說明區別，兩種方案如下所示。
從圖中可以看出，我們的站點1主機同時查看儲存系統1和儲存系統2。同樣，相反，站點2主機同時查看儲存系統2和儲存系統1。 也就是說，每個主機都可以看到兩個儲存系統。 這是城域叢集運作的先決條件。
當然，沒有必要用光纖電纜將每台主機連接到另一個資料中心；沒有連接埠或光纖電纜就足夠了。 所有這些連線都必須透過乙太網路10G+或FibreChannel 8G+交換器進行（FC僅用於連接主機和儲存系統進行IO，複製通道目前僅可透過IP（乙太網路10G+）使用。
現在簡單介紹一下網路拓撲。 重要的一點是子網路的正確配置。 有必要立即為以下類型的流量定義多個子網路：
- 將在儲存系統之間同步資料的複製子網路。 可能有幾個，在這種情況下並不重要，這完全取決於當前（已經實現的）網路拓撲。 如果有兩個，那麼顯然它們之間必須配置路由；
- 主機將透過其存取儲存資源的儲存子網路（如果是 iSCSI）。 每個資料中心都應該有一個這樣的子網路；
- 控制子網，即管理儲存系統的三個站點上的三個可路由子網，仲裁器也位於其中。
我們在這裡不考慮用於訪問主機資源的子網，因為它們高度依賴任務。
將不同的流量分離到不同的子網路非常重要（將副本與 I/O 分離尤其重要），因為如果將所有流量混合到一個「厚」子網路中，那麼該流量將無法管理，並且在兩個資料中心的條件這仍然可能導致不同的網路衝突選項。 我們不會在本文的框架內深入探討這個問題，因為您可以閱讀有關如何利用網絡設備製造商的資源規劃數據中心之間延伸的網絡的信息，其中對此進行了非常詳細的描述。
仲裁器配置
仲裁器必須透過 ICMP 和 SSH 協定提供對儲存系統所有管理介面的存取。 您還應該考慮仲裁器的故障保護。 這裡有一個細微差別。
仲裁器故障轉移是非常理想的，但不是必要的。 如果裁判在錯誤的時間跌倒了怎麼辦？
- 正常模式下 Metrocluster 的運作不會改變，因為arbtir對正常模式下metrocluster的運作絕對沒有影響（它的任務是及時切換資料中心之間的負載）
- 此外，如果仲裁器因某種原因倒下並在資料中心發生事故時“休眠”，則不會發生切換，因為沒有人發出必要的切換命令並組織法定人數。 這種情況下，metrocluster會變成帶有複製的常規方案，災難發生時需要手動切換，影響RTO。
由此得出什麼結論呢？ 如果確實需要確保最小 RTO，則需要確保仲裁器具有容錯能力。 有兩種選擇：
- 在容錯虛擬機管理程式上啟動帶有仲裁器的虛擬機，幸運的是所有成人虛擬機管理程式都支援容錯；
- 如果在第三個站點（在傳統辦公室）您懶得安裝普通集群並且沒有現有的 hypervozor 集群，那麼我們提供了仲裁器的硬體版本，它是在一個 2U 盒子中製作的，其中有兩個普通集群x-86 伺服器可以正常工作，並且可以在本地故障中倖存下來。
我們強烈建議確保仲裁器的容錯能力，儘管 Metrocluster 在正常模式下不需要它。 但理論和實踐都表明，如果建立真正可靠的防災基礎設施，那麼最好還是謹慎行事。 最好保護您自己和您的企業免受“卑鄙法則”的影響，即避免仲裁員和安裝儲存系統的網站之一發生故障。
解決方案架構
考慮到上述需求，我們得到以下通用解決方案架構。
LUN 應均勻分佈在兩個站點上，以避免嚴重過載。 同時，在調整兩個資料中心的規模時，不僅應該包括雙倍磁碟區（這是在兩個儲存系統上同時儲存資料所必需的），還應該包括雙倍的IOPS 和MB/s 效能，以防止應用程式效能下降其中一個資料中心發生故障。
另外，我們注意到，透過正確的調整方法（即，假設我們提供了適當的 IOPS 和 MB/s 上限，以及必要的 CPU 和 RAM 資源），如果儲存系統之一Metro叢集出現故障，在一台存儲系統臨時工作的情況下，不會出現效能嚴重下降的情況。
這是因為，當兩個網站同時運行時，同步複製會「吃掉」一半的寫入效能，因為每個事務必須寫入兩個儲存系統（類似於 RAID-1/10）。 因此，如果其中一個儲存系統發生故障，複製的影響會暫時消失（直到故障儲存系統恢復），寫入效能會提高一倍。 當發生故障的儲存系統的 LUN 在工作儲存系統上重新啟動後，由於來自另一個儲存系統的 LUN 的負載出現，這種兩倍的增加就消失了，並且我們恢復到了故障之前的相同效能等級。 “墜落”，但僅限於一個站點的框架內。
借助合理的規模調整，您可以確保使用者根本不會感覺到整個儲存系統故障。 但我們再次重申，這需要非常仔細的尺寸調整，順便說一下，您可以免費聯繫我們:-)。
設定城域集群
設定 Metrocluster 與設定常規複製非常相似，我們在 。 因此，我們只關注差異。 我們在實驗室裡搭建了一個基於上述架構的工作台，只是一個最小版本：兩個透過10G乙太網路連接的儲存系統，兩個10G交換器和一台主機，透過交換器查看兩個具有10G連接埠的存儲系統。 仲裁器在虛擬機器上運作。
為副本配置虛擬 IP (VIP) 時，您應該選擇 VIP 類型 - 對於 Metrocluster。
我們為兩個LUN 創建了兩個複製鏈接，並將它們分佈在兩個存儲系統上：存儲系統1 上的LUN TEST 主節點（METRO 鏈路）、存儲系統2 上的LUN TEST2 主節點（METRO2 鏈路）。
對於它們，我們配置了兩個相同的目標（在我們的例子中是 iSCSI，但也支援 FC，設定邏輯是相同的）。
儲存系統1：
儲存系統2：
對於複製連接，在每個儲存系統上進行映射。
儲存系統1：
儲存系統2：
我們設定了多路徑並將其呈現給主機。
設立仲裁員
您不需要對仲裁器本身執行任何特殊操作；您只需在第三個網站上啟用它，為其提供 IP 並透過 ICMP 和 SSH 配置對其的存取。 設定本身是從儲存系統本身執行的。 在這種情況下，在城域叢集中的任何儲存控制器上配置一次仲裁器就足夠了；這些設定將自動分發到所有控制器。
在遠端複製>> Metrocluster（在任何控制器上）>> 部分中，按一下「配置」按鈕。
我們輸入仲裁器的IP，以及兩個遠端儲存控制器的控制介面。
之後，您需要啟用所有服務（「重新啟動所有內容」按鈕）。 如果以後重新配置，必須重新啟動服務才能使設定生效。
我們檢查所有服務是否正在運行。
這樣就完成了 Metrocluster 設定。
碰撞測試
在我們的例子中，崩潰測試將非常簡單且快速，因為複製功能（切換、一致性等）已在 。 因此，要測試metrocluster的可靠性，我們檢查故障偵測、切換的自動化以及是否存在記錄遺失（I/O停止）就足夠了。
為此，我們透過物理關閉兩個控制器來模擬其中一個儲存系統的完全故障，首先開始將大檔案複製到必須在另一個儲存系統上啟動的 LUN。
禁用一個儲存系統。 在第二個儲存系統上，我們在日誌中看到與相鄰系統的連線已遺失的警報和訊息。 如果設定了透過 SMTP 或 SNMP 監控的通知，管理員將收到相應的通知。
整整 10 秒後（在兩個螢幕截圖中都可見），METRO 複製連線（故障儲存系統上的主連線）自動成為工作儲存系統上的主連線。 使用現有映射，LUN TEST 仍然可供主機使用，記錄略有下降（在承諾的 10% 之內），但沒有中斷。
測試成功完成。
總結一下
目前在 AERODISK Engine N 系列儲存系統中實施的城域叢集完全可以解決需要消除或最大限度減少 IT 服務停機時間的問題，並確保其以最低的勞動力成本 24/7/365 運作。
當然，我們可以說，所有這些都是理論、理想的實驗室條件等等……但我們有許多已實施的項目，其中我們已經實施了抗災功能，並且系統運作完美。 我們的一個相當知名的客戶，在防災配置中只使用了兩個存儲系統，他已經同意發布有關該項目的信息，所以在下一部分我們將討論實戰實施。
謝謝，我們期待進行富有成效的討論。
來源： www.habr.com