理解和避免裂腦情景

裂腦。 我們博客的大多數讀者都聽說過這個詞，在計算環境中，也就是說，我們不得不同情那些第一個心理形像是如果有人有兩個大腦會導致的混亂同時。

什麼是故障轉移群集裂腦方案？

在故障轉移集群裂腦場景中，兩個節點都不能與另一個節點通信，備用服務器可能會提升自己成為活動服務器，因為它認為活動節點出現故障。 這導致兩個節點都變為“活動”，因為每個節點都會將另一個節點視為失敗。 因此，由於兩個節點上的數據都會發生變化，數據完整性和一致性會受到損害。 這被稱為裂腦。

如果不採取適當的步驟來避免它們，SAP HANA 資源層次結構可能會發生兩種類型的腦裂情況。

• HANA 資源裂腦： HANA 資源在多個集群節點上處於活動狀態 (ISP)。 這種情況通常是由影響集群節點之間通信路徑的臨時網絡中斷引起的。
• SAP HANA 系統複製裂腦： HANA 資源在主節點上為 Active (ISP)，在備份節點上為 Standby (OSU)，但數據庫正在運行並註冊為兩個節點上的主複製站點。 這種情況通常是由於在故障轉移期間無法停止先前主節點上的數據庫、為數據庫啟用了自動啟動，或者數據庫管理員在集群軟件環境之外的輔助複製站點上手動運行“hdbnsutil -sr_takeover” .

避免裂腦問題

避免或解決方案中每種類型的裂腦情景的建議SIOS 保護套件集群環境如下。

在裂腦情況下，每隔 quickCheck 時間間隔（默認為 2 分鐘），就會記錄一條類似於以下內容的消息並將其廣播到所有打開的控制台，直到問題得到解決。

EMERG:hana:quickCheck:HANA-SPS_HDB00:136363:WARNING: 服務器 hana2-1 和 
hana2-2 之間發生臨時通信故障。需要手動干預以最大程度地降低數據丟失的風險。 
要解決這種情況，請停止使用以下資源層次結構之一：hana2-1 上的 HANA-SPS_HDB00 或 
hana2-2 上的 HANA-SPS_HDB00。 
資源層次結構停止服務的服務器將成為輔助 SAP HANA 系統複製站點。

解決建議：

1. 調查每個集群節點上的數據庫以確定哪個實例包含最新或相關的數據。 該決定必須由熟悉數據的合格數據庫管理員做出。
2. 包含需要保留的數據的節點上的 HANA 資源在 LifeKeeper 中將保持 Active (ISP)，並且將重新註冊為輔助複製站點的節點上的 HANA 資源層次結構將在救生員。 右鍵單擊 HANA 資源層次結構中應停止服務的節點上的每個葉資源，然後單擊中止服務…
3. 一旦 SAP HANA 資源層次結構成功退出服務，LifeKeeper 將在下一個 quickCheck 間隔（默認為 2 分鐘）內將備用節點重新註冊為輔助複製站點。 一旦複製恢復，備用節點上不存在於主動節點上的任何數據都將丟失。 備用節點重新註冊為輔助複製站點後，SAP HANA 層次結構已返回到高度可用的狀態。

SAP HANA 系統複製裂腦解決方案

而在這種裂腦場景中，會記錄一條類似於以下內容的消息，並將其廣播到所有打開的控制台。 檢查間隔（默認為 2 分鐘），直到問題得到解決。

EMERG:hana:quickCheck:HANA-SPS_HDB00:136364:WARNING: SAP HANA 數據庫 
HDB00 正在運行，並在 hana2-1 和 hana2-2 上註冊為主要主機。 
需要手動干預以最大程度地降低數據丟失的風險。 要解決這種情況，
請通過在該服務器上運行命令“su – spsadm -c “sapcontrol -nr 00 
-function Stop””來停止 hana2-2 上的數據庫實例 HDB00。 一旦停止，
它將成為輔助 SAP HANA 系統複製站點。

解決建議：

1. 調查每個集群節點上的數據庫，確定Standby節點上是否存在重要數據，而Active節點上不存在。 如果在裂腦狀態下重要數據已經提交到 Standby 節點上的數據庫，則需要手動將數據複製到 Active 節點。 該決定必須由熟悉數據的合格數據庫管理員做出。
2. 一旦任何丟失的數據從備用節點上的數據庫複製到活動節點，通過運行 LifeKeeper 警告消息中給出的命令停止備用節點上的數據庫：
   

   su – adm -c “sapcontrol -nr <Inst#> -function Stop” 其中是 HANA 安裝的小寫 SAP 系統 ID，<Inst#> 是 HDB 實例的實例編號（例如，實例編號、例如，HDB00 是 00）

3. 一旦數據庫成功停止，LifeKeeper 將在下一個 quickCheck 間隔（默認為 2 分鐘）內將備用節點重新註冊為輔助複製站點。 一旦複製恢復，備用節點上不存在於主動節點上的任何數據都將丟失。 備用節點重新註冊為輔助複製站點後，SAP HANA 層次結構已返回到高度可用的狀態。

了解常見的裂腦場景並採取這些步驟來緩解它們可以節省您的時間並保護數據完整性。

高可用性架構和最佳實踐

關於高可用性的 13 個鮮為人知的事實

1. Hypervisor HA 與應用程序 HA 不同

一個關鍵的誤解是，我之所以具有高可用性，是因為我的硬件或虛擬機管理程序中有冗餘。 但是，硬件和管理程序冗餘並不能保證高可用性用於應用程序。 也不能保證應用程序的編排將在失敗時正確執行。

2. 在高可用性中，更大並不等於更好

如果你是一名力量舉運動員，更大的重量更好，更小的代表更好。 或者，如果我們談論擁抱。 （你還記得擁抱是我們見到來自不同城鎮的朋友時經常做的事情，我們有一段時間沒見過了。）但是，更大並不總是意味著更好。 例如，更大的腎結石肯定不是更好。 在更高的可用性中，創建更大、更複雜的解決方案並不總是意味著您將提高您的高可用性。 這可能意味著您的可用性相同或更少。 這也可能意味著您有一個更大、更複雜的系統，其中包含許多移動部件，需要在停機時進行分類。

3. 一切都失敗了……有時

應用程序編程語言可以追溯到 1950 年代。 雖然語言、處理器、IDE 和代碼質量有所提高，但現實是“所有應用程序都會在某個時候失敗”。由於異常、錯誤、未處理的終止、意外終止、資源耗盡等導致的失敗時有發生。 仍然需要一個主動/主動或主動/被動應用程序可用性策略。

4. 關注“為什麼”和“如何”一樣多

我們跳入任務完成模式的自然傾向是一種必要的資產，但需要通過我們對為什麼的問題的回答來加以調節和引導。 在不了解業務、應用程序、數據庫和利益相關者要求的情況下向環境添加解決方案將導致：

• 失敗
• 超支
• 表現不佳
• 混亂和過度架構
• 上述所有的

與其只關注實現可用性，不如花費必要的資源和精力來了解業務需求和“為什麼”的答案

5. 未修補的問題是常見的遺憾來源

做或不做，後果自負。 所有未修補的問題的後果是後悔。 作為客戶體驗副總裁，我親眼目睹了由於客戶未能及時解決已知問題而導致的停機。

6. 未記錄的問題也會導致停機

描繪場景。 一位新管理員正在調查網絡上的服務器。 使用情況報告表明服務器未處於活動狀態，並且沒有連接任何客戶端。 新管理員無法識別服務器，也沒有發現“標籤”、文檔或其他標識符，因此認為應該關閉它。 不幸的是，未記錄和未通信的實例實際上是一個備用服務器，當主服務器意外崩潰時，刪除它會導致停機。 這不是虛構的故事，而是一個新管理員的真實故事，他錯誤地將服務器識別為空閒 QA 系統並在修補練習之前將其關閉。

7、自滿也是敵人

如果內部或云中或介於兩者之間的任何地方的可用性是我們可以“設置並忘記”的，我們都會喜歡它。但是，生活中很少有事情真的像“設置並忘記它”那樣簡單。未來可用性的最大敵人之一是您現在的高可用性成功。 當災難很少發生並且團隊確信他們已經實現了持續穩定時，自滿情緒就會介入。 成功誘使我們認為什麼都不會改變，因此對高可用性的自滿是高可用性的敵人。 企業周圍和企業內部的事物正在發生變化。 雲在變化，您的業務需求在變化，應用程序和操作系統也在變化。

8.改變很難

改變很難。 問問那些一直試圖在睡前放棄第二塊蛋糕的愛吃甜食的人吧。 即使在高可用性中也會出現類似的阻力。 團隊，即使是那些經歷過災難的團隊，即使改變是好的，也往往不願意改變。 他們需要遠見、對原因的理解和支持。 其他擁有解決方案的團隊不願意提高高可用性，因為害怕引入不穩定或將自己暴露在新的風險中。

9.所有的改變都不是好的改變

改變是好的，當改變是好的。 在考慮對更高可用性解決方案和架構進行更改時，根據目標、要求以及在提高可用性的範圍內分析更改至關重要。 提高穩定性、增加對關鍵組件的保護、消除變通方法、優化服務可用性並經過全面測試的更改都是很好的更改。

10. 便宜並不總是更好

便宜並不總是更好。 雖然更便宜的解決方案通常具有較低的價格標籤，但它們也可能帶有許多限制，使其不太理想。 當價格標籤較低時，請注意缺少的功能，例如缺乏應用程序意識、有限的編排、隱藏的複雜性、手動恢復和故障轉移，並且僅限於沒有用戶驗證。 更便宜的解決方案也可能不包括客戶支持。 請務必了解您的更便宜的解決方案是否包含支持，或者支持是否是額外的、大量的附加成本。

這同樣適用於減少計算、磁盤或存儲的更便宜的部署。 雖然價格標籤和每月成本可能較低，但您的解決方案也可能以不太理想的容量運行。

11.響亮不等於有效

聽說過那個叫狼來了的男孩的故事。 產生警報風暴的應用程序監控解決方案遲早會被忽略。 擁有提供警報的解決方案固然很棒，但如果該解決方案錯誤地或過多地觸發了關鍵警報，則它是無效的。

12. 高可用性是一種文化和心態，而不僅僅是產品或硬件解決方案

軟件、硬件、流程、解決方案和服務都是高可用性的一部分。 但是，如果沒有跨 IT 職能和業務部門的支持，它將充滿挫敗感並不斷成為預算討論的來源，而不是關於價值、業務穩定性、提高客戶滿意度和降低風險的討論。

13.現在還不晚

希望不是實現高可用性的策略，希望您不會遇到嚴重災難或應用程序故障也不需要成為策略。 即使距離上次災難已經過去數週或數月，現在也可以設計和構建高度可用的企業架構。

聯繫 SIOS了解更多高可用性解決方案為您的應用程序。

– 客戶體驗副總裁 Cassius Rhue 轉載自SIOS

將應用程序遷移到雲端

我們怎麼去那裡？

在您的雲和更高可用性之旅中，請考慮作者和企業家的建議Nilofer Merchant（有下面的一個鏈接就可以了） .

在不到 72 小時內，我已經多次回答了同一個問題：你如何獲得那裡?開始是我的一個大女兒問我如何去學校相關的約會，接著是一個年幼的孩子問我去商店的路線，最後我的大女兒問我如何到達特定目的地在該州的某個地方。 他們都問了同樣的問題。 但在每種情況下，問題的背景和預期的答案都大不相同。 作為作家和企業家尼羅弗商人說，很多關於“你如何到達那裡？”這個問題的答案。不僅取決於你那裡，但也對你這裡.

您當前的應用程序“在這裡”是什麼？

弄清楚如何移動你的第一步應用那裡（到雲，或到雲中更高的可用性）是正確命名“這裡”。那麼，你的“這裡”是什麼？你對這個問題的回答可以像我和女兒們談話的地點一樣多種多樣。 我的一個女兒從我們家的背景下問道。 另一個的背景是從一個不同狀態的起點開始，最小的從一個理論的地方問起（希望我們能得到奶昔）。

當你考慮你的定義和“這裡”的細節時，首先要問一些基本問題：

1. 你的是什麼關鍵應用，它們是如何受到保護的？
2. 你在哪裡部署高可用性保護為您的應用程序？
3. 如何保護您的關鍵數據？
4. 您目前的團隊規模是多少？
5. 您對保護應用程序和數據的解決方案和服務的信心如何？
6. 您的關鍵企業系統和應用程序工作負載當前在哪裡運行？
7. 如果您在本地，那是本地服務器還是虛擬機？ 或者這裡是私有云，還是沒有 HA 的公共雲？
8. 您遷移到雲和在雲中管理應用程序的預算是多少？
9. 你“在這裡”有什麼疲倦、不確定、不安或不滿？

定義“這裡”是起點，它幫助我們感覺我們朝著更好的“那裡”前進，所以慢慢來。想想在你的“這裡”的參數中還有什麼形狀、定義、限製或存在？“這裡”是多產品部署、全球 IT 團隊基礎設施，還是其他一些多地點、多辦公室安排？您的團隊是全球分佈、外包還是組合？如果你看看你的“這裡”有什麼突出的地方，你的團隊、公司、產品或企業標誌是什麼？什麼是關鍵且經常出現的痛點，例如缺乏培訓、缺少冗餘、架構指南不完整、對現有解決方案感到失望、雲複雜性、

你的“那裡”是什麼？ 私有云、公共雲、混合雲還是多雲？

在你弄清楚你的“這裡”之後，從商人的文章中解脫出來的第二步是“弄清楚’那裡’可能是什麼。 作為客戶體驗副總裁，我曾與許多客戶合作過，他們希望“那裡”有一個零停機時間、計劃內或計劃外的環境，或者應用程序故障轉移是無縫的並且在兩分鐘或更短的時間內完成。 其他客戶的目標不那麼高，尋求適合五 (5) 到九 (9) 分鐘窗口內的停機時間，或者更喜歡更長的窗口，並根據對故障通知的響應進行手動覆蓋選項。 還有一些客戶希望“那裡”有更好的通知、清晰的解決方案和建議、特定於應用程序的編排，以及通過供應商和合作夥伴的專家來增強他們的團隊的方式。那麼你的“那裡”的主要特點是什麼？ 你買得起什麼？

當您查看“這裡”的辛勤回答時，有什麼特別之處？需要解決“這裡”的哪些項目，以創建更理想的團隊、企業、可用性、數據中心和生活的未來版本。 您的“那裡”是否包括更多的彈性和冗餘、更多的應用程序編排、更好的分析或更低的成本？私有云、公共雲、混合雲或多雲在您的“那裡”中處於什麼位置？你的“這裡”如何改善，因為你已經做到了“那裡”。

從“這裡”到“那裡”

根據Merchant 的說法，最後一步是“弄清楚我們從’這裡’ 到’那裡’ 的方式。 如果在你的“這裡”很難，那麼只有投入工作去思考“那裡”可能是什麼才有意義。 換句話說，不要簡單地將您的應用程序遷移到雲中。 考慮創建滿足您所有期望的結果所需的資源和服務。 想一想專注於專門構建的高可用性解決方案的供應商、解決方案提供商、服務團隊和公司可以幫助您“實現目標”。

與我女兒的“那裡”不同，沒有用於繪製從“這裡”到“那裡”或云遷移的旅程的 Waze。 但是，通過仔細考慮您當前的情況，包括您的痛苦、挫折、預算限制和您想要的結果，您可以得出一個不僅僅是簡單的雲遷移的解決方案。 它可能意味著更令人滿意的日常體驗，不受對應用程序故障和停機時間的恐懼以及故障排除和最終用戶投訴的麻煩的影響。

在計劃將應用程序遷移到雲時聽取商家的建議可以為您帶來廣泛的可能性，從定義更強大的架構、更改 HA 軟件解決方案、與服務提供商合作、遷移到多雲、混合雲或其他雲模型。這甚至可能意味著重新使用您自己的數據中心。

20 多年來，SIOS 一直在幫助企業實施高可用性和災難恢復保護本地、雲和混合雲環境中的關鍵應用程序。 我們可以提供專業知識，幫助您完成從“這裡”到“那裡”乃至更遠的應用程序 HA 和 DR 之旅。 有關更多信息，請聯繫 SIOS – 客戶體驗副總裁 Cassius Rhue