災難頻傳世界的資料復原策略

災難頻傳世界的資料復原策略

在以軟體工程、系統管理和客戶支援為根基的職位上工作，人們有獨特的機會了解各種配置和無數的問題。此外，這樣的職位也能讓人們了解使用者的各種需求、痛點和顧慮，而純工程職位的人可能無法接觸到這些。

在支援團隊工作了近 5 年的時間後，我注意到與我合作過的各個團隊都存在一些模式。此外，當被要求幫助進行各種配置時，我有獨特的機會在不同的用例和根本原因之間進行比較。 。因此，當我開始與新團隊合作時，我希望確保已經打好了基礎。建立這個基礎意味著確保管理實踐有利於與 HA/DR 套件進行最佳協作，確保團隊知道如何設計高可用性以及如何利用系統上軟體之外的實用程式來取得成功。這個基礎對於確保團隊知道如何達到或超越他們的營運標準至關重要。總結一下常見問題以及他們的答案，為那些對實施高可用性解決方案或者只是想改用新的高可用性解決方案。無論您是剛開始學習系統管理/系統工程的學生，還是被要​​求擴展職責範圍以包括系統架構規劃的資深軟體工程師，以下幾點都可以幫助您充分利用高可用性/災難復原套件。

不用多說，以下的問題總結了我在我的工作中看到的常見談話要點，並將幫助您更輕鬆地理解關鍵概念並找到合適的解決方案。

什麼是災難復原？它包含哪些內容？

災難復原，當與高可用性，致力於優化復原時間目標 (RTO) – 服務復原前無法存取的時間 – 以及復原點目標 (RPO) – 從備份還原時可以承受的資料遺失。這恢復時間目標描述系統可以停機多長時間並且仍然符合操作標準。通常，這個指標以百分比來表示——常見的「五個九的正常運作時間」指的是 99.999% 的正常運作時間，或每年最多停機 5 分鐘左右。恢復點目標有點複雜，它描述了在符合操作標準的情況下可以遺失的資料量。例如，如果系統在災難發生後不會遺失任何數據，則稱為「零 RPO」。將系統想像成存在於時間線上，並將恢復點目標視為以下問題的答案會很有幫助：「如果系統遭遇災難，那麼在系統時間線上可以『倒回』多久並仍然滿足操作標準」？

災難復原與傳統的因應中斷的方法有何不同？

傳統上，如果沒有高度可用的基礎設施，遭遇災難的環境可能需要較長的復原時間。需要恢復系統，可能需要解決問題，並且管理員需要啟動應用程式。根據問題的嚴重程度，可能需要數小時或更長時間才能恢復正常運作。團隊必須有效率並保持緊密溝通，以確保服務順利恢復，以免在恢復營運時面臨進一步延誤的風險。此外，此類中斷期間遺失的資料可能會非常多。如果最近沒有進行備份，或者無法存取最新數據的副本，那麼團隊可能會依賴已經「過時」的數據，並由於關鍵數據的遺失而在組織範圍內遭遇營運挫折。從客戶的角度來看待問題，當您需要線上服務時，您願意等待多長時間才能獲得該服務？身為顧客，如果網路店面遺失了您的交易記錄，您能接受嗎？

當引入高可用性基礎設施、鏡像儲存方法以及協調高可用性的方法時，影響 RTO 和 RPO 的因素都會得到最佳化，並且可以更從容地應對災難。高可用性基礎設施是冗餘的，因此可以使用備用系統來接管作業。此外，協調器（用於管理叢集環境的軟體）能夠系統地在備用系統上啟動服務，並且比手動幹預具有更高的回應能力、可靠性和效率。因此，復原時間目標減少了，災難復原不再需要幾個小時，而是只需要幾分鐘甚至更短的時間。

高可用性基礎設施的另一個方面是資料冗餘。磁碟可以“鏡像”，其中連接到不同系統的磁碟都可以即時接收完全相同的資料。因此，上述備用系統上可用的資料可以是精確的副本，從而有效地維護災難發生之前的資料備份。反過來，當服務恢復時，應用程式將以接近零的恢復點目標運行，當編排器將操作移至備用系統時，將恢復點目標保持在最新的運行狀態。

組織在設計高可用性災難復原 (HADR) 策略時最常犯的錯誤是什麼？如何避免這些錯誤？

最常見的失誤之一是缺乏 QA/測試環境。 SIOS 客戶體驗團隊已經對多個此類情況做出了回應，其中組織嘗試執行應用程式/作業系統修補/升級或者僅僅是由於規劃不充分或某種不幸的不相容而導致的日常維護和體驗問題。然後，有一個停機時間這發生在環境中，維護過程變成了恢復過程。這會導致延遲、複雜性以及在生產環境中出現螺旋式問題的可能性。

到目前為止，可以向組織提供的最大建議是創建以品質保證能力運行的生產環境的一對一副本。生產中需要發生的每個程序都應首先在 QA 環境中經過「彩排」。這使得組織可以自由地執行計劃的運作並進行改進，而不會危及基礎設施的生產能力。在安全、低風險的環境中進行操作練習可確保團隊準備好在生產環境中進行操作，而不會遇到意外問題的風險，也不必在壓力下「脫離腳本」快速正確地做出反應。如果 QA 環境中出現問題，則可以聯繫支援團隊，並調查該問題，以確保該問題的安全性，避免影響業務營運。這可以大大提高以受控、有計劃和有效的方式找到解決方案並將其實施到運營中的可能性。

上述 QA 環境的好處對任何組織都很重要；然而，隨著組織採用更複雜的維護策略，這種測試環境的存在變得更加重要。使用這種測試環境不僅有利於更順暢的升級流程，而且還允許公司在採用引入複雜性的維護模型時降低風險，以便在維護活動期間恢復更高的系統可用性。在任何情況下，在 QA 環境中測試維護計劃，根據「彩排」的結果改進計劃，並利用從這種實踐中獲得的經驗，使組織能夠管理生產系統，同時最大限度地降低遇到問題的風險。

消除單點故障的重要性是什麼？

團隊可能遇到的另一個常見障礙是架構中的“最薄弱環節”，它無法從環境其他方面所獲得的規劃程度中受益。最好用一個例子來描述這一點。 SIOS 客戶體驗團隊曾經與一位客戶合作，該客戶圍繞著保持SAP 應用程式在他們的環境中運行，並且很好地避免了影響運行 SAP 應用程式的系統的問題。不幸的是，該客戶投入了大量的規劃精力來保護他們的應用程序，而沒有投入同樣的規劃精力來保護其環境的其他方面。因此，所有系統都依賴單一的內部 DNS 系統來解析其私有網路內的主機。儘管盡一切努力保護樹液，當他們的 DNS 系統出現問題時，整個環境都會遇到嚴重問題，因為名稱解析不再可用。實際上，為保護 SAP 應用程式所付出的努力並沒有幫助他們的環境度過這個問題，因為 DNS 是所有其他系統正常運作所依賴的「薄弱環節」。在規劃環境時，退一步看大局至關重要——注意架構中出現的最薄弱的環節。改善最薄弱的環節可以提高整個環境抵禦災難的可能性。

對於嚴重依賴雲端服務的組織，他們如何防範區域或地區範圍的災難？

只需在地理上分配資源，即可防範區域性或區域性災難。例如，有人可能在美國東部地區託管其主要應用程式伺服器。然後，為了防止影響美國東部地區的停電，在遠離美國東部地區（可能是美國西部地區）的「災難復原站點」中託管了備用系統。雖然這確實引入了一些額外的步驟來確保跨區域的通信，但這種努力是無價的，因為它可以防止區域和區域範圍內的災難。透過在美國西部地區提供應用程式服務，可以承受雲端供應商美國東部地區全面中斷的情況。針對特定區域發生的中斷的保護並不需要很複雜，並且確保存在災難復原站點來承擔操作將提高生產環境中的應用程式可用性和資料冗餘。

您建議組織如何平衡實施強大的 HA/DR 策略的複雜性和成本與業務敏捷性的需求？

人們普遍認為 HA/DR 解決方案要么複雜，要么昂貴，或者兩者兼而有之。基於這個假設，我們必須對眼前的風險保持清醒的認知。系統是為了某些商業目的而運作的，這意味著收入的產生。當系統因停電而癱瘓時，造成的損失遠不止於收入損失。如果沒有 HA/DR 策略，發生中斷時員工就需要積極排除故障，從而產生員工工時成本，並將其計入停機成本，甚至可能是在員工沒有得到充分休息且無法做好最佳工作準備的時候。除此之外，當員工必須將任務切換到解決生產問題，然後再切換回其正常職責時，還會因正常職責的中斷和延遲/緩慢而產生揮之不去的附帶成本。更進一步的是，聲譽成本可能會導致無法辨識收入機會。例如，如果你想到“CrowdStrike”？即使這不會立即帶來問題和相關的負面報道CrowdStrike 在 2024 年 7 月經歷的災難，在撰寫本文時（2025 年 3 月 25 日），其股價才剛恢復到 2024 年 7 月 19 日發行前的水平。考慮到配置 HA/DR 解決方案的機會成本，上述因素可能會大幅改變分析。通常，SIOS 客戶發現實施 HA/DR 解決方案從長遠來看可以為他們節省金錢。此外，憑藉 SIOS 技術數十年來對 HA/DR 產品的改進和迭代，配置此類解決方案的複雜性比以往任何時候都更加容易和簡單。如果存在一些因素仍然讓人擔心將 HA/DR 解決方案引入生產環境的複雜性，SIOS Technology 提供的專業服務可以幫助培訓團隊、執行安裝和配置活動，或者只是驗證現有配置。有了這些機會，將高可用性引入​​系統架構不僅比以前更簡單，而且實施速度也比以前更快。最後，對於擔心由於獨特配置而導致的複雜性或試圖達到 HA/DR 解決方案的最大效用的組織，我們世界一流的支援團隊可以幫助您充分發揮任何實施的潛力。

SIOS 技術的解決方案如何協助組織實施您所倡導的災難復原方法？

SIOS Technology 的解決方案可以滿足前面提到的所有方面，以下列舉其中的一些：

我們採用現代災難復原方法LifeKeeper 和 DataKeeper 產品，我們統稱為SIOS 保護套件。無論是在 Linux 還是 Windows 上，這些產品都可以提供叢集範圍的資源協調，以確保快速有效地應對災難，同時確保資料在備用系統上複製和可用。 LifeKeeper 監控應用程式的故障並在節點之間進行通信，以確保系統是應用程式復原的有效目標。 Datakeeper 即時複製數據，以確保備用系統能夠在出現問題時繼承應用程式並繼續使用最新的可用數據進行操作。這些產品協同工作，最大限度地縮短應用程式停機時間，並最大限度地減少災難發生時的資料遺失。

這些產品還可完全整合到您的環境中。有一些機制可以提供高效的網路控制，以便客戶端始終可以解析與應用伺服器的連接。所採用的解決方案不僅可以監控應用程式或系統的特定元件，還可以監控整個系統和環境。透過使用「仲裁」功能，可以在「大局」層級監控環境，以確保應用程式在正確的系統上恢復並且資料受到保護。由於 SIOS Protection Suite 針對各種災難場景都採取了保護措施，因此能夠做出適當的回應。

SIOS Protection Suite 也能夠跨區域工作，提供我們所討論的針對區域或地區級災難的保護。應用程式可以跨區域遷移，資料可以跨區域複製，就像在同一區域內複製一樣容易。此外，環境可以是多層的。可以在主區域中託管多個節點，並充當活動系統或備用系統，從而快速響應系統級問題，同時還可以維護不同區域的災難復原站點，以確保以相同的速度和保護效力來防範區域級災難。

最後，SIOS Protection Suite 產品受益於數十年的實際使用。它已經在各種場景和部署配置中得到了檢驗，並受益於多年的易用性改進。因此，這是一個靈活、易於採用且可無縫融入生產環境的解決方案。採用 SIOS Protection Suite 可以避免設計和配置 HA/DR 解決方案的複雜性，並享受豐富的開發歷史和無數改進的好處，再加上世界一流的支援團隊，可以在出現任何問題或疑慮時提供協助。除此之外，您還有機會進行 SIOS Protection Suite 產品的協作安裝或驗證程序，確保您的環境能夠應對世界可能遇到的任何挑戰。最後，對於需要經驗豐富的員工並希望最大限度地利用 SIOS Protection Suite 及其組件的團隊，SIOS 提供培訓活動，團隊可以與我們的員工合作，了解正在發揮作用的組件，並進行積極的討論，以促進深入的理解，確保員工能夠立即掌握實施解決方案所需的所有信息，以最大限度地發揮其潛力。

保護您的業務免遭停機和資料遺失—請求演示或者開始免費試用看看 SIOS 的實際運作情況。

作者：Philip Merry，CX – SIOS Technology Corp. 軟體工程師

經許可轉載SIOS

DataKeeper 與棒球：災難復原的策略性舉措

DataKeeper 與棒球：災難復原的策略性舉措

在我的整個職業生涯中，資料管理員正在成為「智囊團」和「茶歇間」閒聊中的業界標準，當談到資料保護和災難復原。美國著名的消遣活動棒球與 DataKeeper 相比如何？儘管我是這項運動的忠實粉絲，但由於這兩件事看似毫無關聯，因此還是存在一些相似之處。

制定成功的資料保護計劃

首先，棒球和 DataKeeper 都需要一個周密的「比賽計畫」。在棒球比賽中，球隊會進行練習並製定計劃以擊敗對手，希望取得勝利。同樣，DataKeeper 需要一種「發人深省」的策略來確保資料保護得到利用，並且在發生災難性事件時可以恢復。

其次，團隊合作仍然至關重要。內野手、外野手、經理和球童各自扮演特定的角色，以確保獲得最大的勝利機會。使用 DataKeeper，可能會涉及多個團隊，例如資料庫管理員、基礎設施人員、客戶體驗/支援、管理等等。所有人都應該投入大量精力來有效地保護和恢復資料。

棒球和 DataKeeper 的不同之處：IT 領域的風險更高

有一些差異不容忽視。雖然輸掉一場棒球比賽，特別是世界大賽第 7 場、最後一局、2 出局、3 個球 – 2 次好球，可能會讓人“沮喪”，但使用 DataKeeper 時，風險要高得多。遺失資料可能會對企業帶來嚴重後果。雖然棒球運動員需要一套獨特的運動技能，但 DataKeeper 是需要企業系統和相關流程知識的解決方案。

總而言之，雖然棒球和 DataKeeper 看起來完全不同，但我們可以得出一些相似之處。兩者都需要：

• 策略
• 團隊合作
• 。 。 。和專業知識

無論您是棒球迷還是 IT 專業人士，顯然，要想取得成功都需要一定的技能和奉獻精神。

您的資料保護計劃是什麼？

查看提供的遊戲計劃/解決方案us.sios.com/solutions/

玩球。 。 。

作者：Gregory A. Tucker，SIOS 資深產品支援工程師

經許可轉載SIOS

SQL Server 停機風險預算

SQL Server 停機風險預算

在這TechRadar Pro 文章「SQL Server 停機風險預算」中，SIOS 的 Dave Bermingham 強調了將業務連續性計劃與實際預算相結合的重要性，以減輕關鍵任務 SQL Server 部署中的中斷。他建議組織評估每個 SQL Server 執行個體的重要性，以了解停機的潛在影響（包括收入損失、生產力下降、資料損壞和法律處罰），並分配適當的資源（無論是內部部署、雲端還是混合資源），以確保做好應對災難的準備。 號

轉載自SIOS

從 Linux 的 SIOS DataKeeper 遷移到 DRBD

從 Linux 的 SIOS DataKeeper 遷移到 DRBD

SIOS 於 2019 年推出了分散式複製區塊裝置 (DRBD) 復原套件SIOS LifeKeeper Linux 版本 9.9.0。從SIOS 資料管理員對於想要在 Linux 中嘗試 DRBD 功能的人來說，將 Linux 遷移到 DRBD 是一個簡單的過程生命守護者以及以前熟悉 DRBD 的人。

了解 DRBD 及其在 LifeKeeper 中的優勢

DRBD 是一種基於軟體的、無共享的、複製的儲存解決方案，用於在主機之間鏡像區塊設備（硬碟、分區、邏輯磁碟區等）的內容。 LifeKeeper for Linux DRBD 復原工具包提供了配置和控制 DRBD 資源以實現高可用性的能力。

比較 Linux 版 SIOS DataKeeper 與 DRBD

Linux 版 SIOS DataKeeper 為 LifeKeeper 環境提供了整合的資料鏡像功能。對於想要建構高可用性集群（使用 SIOS LifeKeeper）沒有共享儲存或只是想在伺服器之間即時複製業務關鍵資料。

SIOS DataKeeper 提供同步或非同步磁碟區級鏡像，將資料從主伺服器（鏡像來源）複製到一個或多個備份伺服器（鏡像目標）。本部落格不包含創建 PostgreSQL 資源的步驟，但可以找到有關使用 SIOS LifeKeeper 配置 PostgreSQL 的更多信息這裡。

如何將 PostgreSQL 資料庫遷移到 DRBD

1. 透過 LifeKeeper UI 停止 PostgreSQL 應用程式

lkcli 資源刪除 –tag pgsql-demo

1. 為 PostgreSQL 資料庫和日誌檔案建立資料備份

cp -pra /pgsql-demo* /備份/

1. 使用臨時檔案系統位置建立新的 DRBD 資源。

lkcli 資源建立 drbd –tag drbd-pgsql-demo –device /dev/mapper/singledrbd-lk1 –fstype ext3 –mount_point /tmp/pgsql-demo

確保選擇與先前的 DataKeeper for Linux 資源相同的 fstype。所選設備也應足以容納 PostgreSQL 資料庫資料集的資料和日誌量。

1. 將DRBD資源擴展到目標伺服器。

lkcli 資源擴充 drbd –tag drbd-pgsql-demo –dest node-a –device /dev/xvdc3 –mode 同步 –laddr 10.15.29.165 –raddr 10.15.27.49

1. 使 PostgreSQL 資料庫的檔案系統資源停止服務。

lkcli 資源刪除 –tag /pgsql-demo

1. 更改 /tmp/pgsql/demo 目錄的擁有者和群組。

chown postgres：postgres /tmp/pgsql/demo

1. 將資料複製到 DRBD 鏡像檔案系統。

cp -pra /備份/* /tmp/pgsql-demo

1. 使新建立的 DRBD 檔案系統資源停止服務。

lkcli 資源刪除 –tag /tmp/pgsql-demo

1. 打破先前檔案系統和 DataKeeper for Linux 資源之間的依賴關係

lkcli 依賴刪除 –parent /pgsql-demo –child datarep-pgsql-demo

打破檔案系統和 DRBD 資源之間的依賴關係。

lkcli 依賴刪除 –parent /tmp/pgsql-demo –child drbd-pgsql-demo

1. 重新建立現有 /pgsql-demo 檔案系統和 drbd 資源之間的依賴關係

lkcli 依賴建立 –parent /pgsql-demo –child drbd-pgsql-demo

1. 啟動 pgsql-demo 資源

lkcli 資源恢復 –tag pgsql-demo

開始在伺服器“node-b”上恢復“pgsql-demo”

等待伺服器啟動….完畢

伺服器已啟動

成功恢復伺服器“node-b”上的“pgsql-demo”

1. 連接資料庫並驗證資料庫連線。

例如：

psql -p 3308 -h /pgsql-demo/socket -U psql

psql -p <埠> -h <套接字目錄> -U <資料庫使用者>

1. 刪除臨時 DRBD 檔案系統資源

lkcli 資源刪除 /tmp/pgsql-demo

1. 刪除 DataKeeper for Linux 的資料代表和暫存檔案系統資源。

lkcli 資源刪除 –tag datarep-pgsql-demo

15. 驗證切換和連接

為什麼要從 Linux 版 SIOS DataKeeper 遷移到 DRBD？

對於那些想要在 LifeKeeper 中試驗 DRBD 功能的人以及那些以前更熟悉 DRBD 或想要利用 DRBD 更快的異步複製速度和更廣泛的核心支援的人來說，從 SIOS DataKeeper for Linux 遷移到 DRBD 是一個簡單的過程。

準備好開始使用 DRBD 了嗎？立即聯絡 SIOS了解 LifeKeeper 如何幫助您順利遷移並充分利用 DRBD 的潛力，實現高可用性和災難復原

作者：Cassius Rhue，SIOS Technology Corp. 客戶體驗副總裁

經許可轉載SIOS

為什麼無儲存/無節點仲裁對於叢集可用性有害？

為什麼無儲存/無節點仲裁對於叢集可用性有害？

一般來說，法定人數是指出席並作出決定的一群人或團體。

在 LifeKeeper 中，Quorum 強制達成共識，使用叢集中節點的狀態來執行處理叢集內節點故障的下一步。生命守護者quorum 可以在三種模式下運行；儲存、多數和 TCP 遠端（TCP 遠端僅適用於 LifeKeeper for Linux）。

• 儲存 Quorum 使用共用儲存裝置來追蹤叢集中其他系統提供的更新，如果某個系統不提供更新，Quorum 會將叢集標記為失敗。
• 多數仲裁依賴奇數個集群的結構其中一個節點充當見證節點，以確定叢集中是否有一個或所有節點無法通訊
• 透過指定連接埠上的 TCP/IP 服務進行 TCP 遠端連接，以驗證叢集中的節點是否可以相互通訊。

了解集群中仲裁的重要性

Quorum 的目的是透過採取補救措施來應對意外情況，從而維持應用程式的可用性。它透過減少裂腦情況的風險並透過維持集群中所有節點之間的通訊來減少停機時間來實現這一點。

集群中沒有仲裁的情況下運作的風險

使用未配置 Quorum 的群集有風險。以下場景將討論缺乏法定人數的後果以及實施法定人數的重要性。

情境 1：減少停機時間

當一個或多個系統因不可避免的因素（例如當機或網路通訊暫時故障）而無法使用時，可能會發生意外停機。

有了儲存這樣的仲裁或 TCP 遠端配置，可以使用存取儲存設備和/或連接埠來追蹤叢集中的通訊狀態。這項額外措施可以防止可能導致嚴重停機的不必要的故障轉移。在其他情況下，Quorum 將採取措施關閉或重新啟動伺服器以將其恢復到健康狀態並避免更長的停機時間。

場景 2：腦裂

一個裂腦就是當叢集中的多個系統認為它們是主伺服器的時候。當主伺服器與輔助伺服器失去通訊時，就會發生這種情況，並且輔助伺服器認為主系統已發生故障。這會導致集群中出現兩個活躍的主系統。

如果配置了多數法定人數，則會提供另一個系統作為見證人，以投票決定哪個系統應該作為主系統，從而防止發生裂腦。

為什麼適當的仲裁配置很重要

操作集群沒有儲存或多數法定人數是危險的，因為它增加了因腦裂和/或網路中斷而導致資料遺失或長時間停機的風險。使用 Quroum 可以提供應對措施，確保集群始終健康並且任何不健康的系統都得到適當處理。

立即聯絡 SIOS了解我們的高可用性解決方案如何協助您正確配置仲裁並保護您的叢集。

作者：Alexus Gore，SIOS Technology Corp. 客戶體驗軟體工程師

經許可轉載西歐斯