與高可用性相關的應用程式智能

與高可用性相關的應用程式智能

高可用性 (HA) 背景下的應用程式智慧是指系統即時了解應用程式的行為和健康狀況並做出智慧回應以保持持續服務可用性的能力。

什麼是應用智能？

那麼，什麼是應用智能？應用智能涉及監控、分析和應對多種因素。這些可以包括應用程式狀態，例如應用程式是啟動還是關閉？效能指標包括回應時間、錯誤率、吞吐量和記憶體使用率。應用程式依賴項，例如資料庫或外部服務。最後，他們會觀察使用者行為或模式。使用應用程式智慧可以更全面地了解應用程式。它使用各種數據點來對應用程式本身的狀態（而不僅僅是基礎設施）做出明智的決策。讓我們以 Web 伺服器為例；僅僅知道伺服器是否正在運作是不夠的，還要知道網站是否可以無錯誤地存取？響應是否很慢？用戶是否多次刷新並嘗試存取它？網站所依賴的資料庫是否也正常運作且可存取？以上都是應用智能認為成功的因素的例子。

LifeKeeper 如何使用應用程式智能

那麼，生命守護者使用應用程式智慧來增強關鍵應用程式的高可用性？讓我們來分析一下。LifeKeeper 使用特定於應用程式的恢復工具包 (ARK)包含每個應用程式的知識（樹液，SQL，PostgreSQL，甲骨文， ETC。 ）。這使得 LifeKeeper 能夠處理每個應用程式的啟動/關閉過程，監視應用程式和任何依賴項的健康和狀態，以及協調智慧故障轉移/故障復原操作，而不會損壞任何資料。使用者可以在 LifeKeeper 中將相關資源按層次關係分組，這使得 LifeKeeper 能夠了解不同應用程式元件之間的依賴關係（例如，當服務依賴 IP 或資料庫時）。這確保了 LifeKeeper發生故障轉移依照正確的順序和復原操作不會破壞應用程式或使其處於不一致或損壞的狀態。

此外，LifeKeeper 還會進行深度健康檢查，不僅確定伺服器是否啟動，還會進行更詳細的檢查，例如資料庫是否接受連線或 Web 服務是否會傳回預期的回應。它甚至可以監視某些預期的後台進程是否正在運行。 LifeKeeper 還使用特定於應用程式的設定檔來確保跨節點的資料配置一致性以及應用程式設定得到正確保存或恢復。最後，LifeKeeper 能夠使用自訂腳本進一步微調這些深度檢查，以智慧地支援不太常見或自主開發的應用程式。

PostgreSQL ARK：應用程式智慧的真實範例

為了更深入地了解，我們可以看看 PostgreSQL ARK 如何使用應用程式智慧。 PostgreSQL ARK 使用特定的邏輯來監控、啟動、停止和故障轉移 PostgreSQL，透過了解特定的 PostgreSQL 啟動和關閉命令、了解關鍵設定檔（如 postgresql.conf 和 pg_hba.conf）以及了解資料目錄佈局和鎖定檔案行為。

PostgreSQL 的智慧監控與有序故障轉移

此外，它不僅檢查 PostgreSQL 是否正在運行，還檢查資料庫是否回應查詢、是否可以存取正確的資料目錄以及交易日誌中是否有任何損壞？它使用依賴關係追蹤來確保 PostgreSQL 經常依賴的資源可用，例如用於客戶端連接的虛擬 IP 和用於其資料目錄的掛載儲存。這確保了 LifeKeeper 在發生故障轉移時可以按正確的順序啟動資源，例如先掛載磁碟，啟動 IP，然後啟動 PostgreSQL，然後再驗證服務健康狀況。

防止裂腦並確保資料完整性

最後，LifeKeeper 使用應用程式智慧來避免裂腦（一種多個節點認為它是「主」節點的現象）場景，透過避免啟動兩個具有相同資料目錄的活動 PostgreSQL 伺服器，並透過在寫入仍在進行時不進行故障轉移來避免資料損壞。這些是 LifeKeeper 和各種 ARK 實現應用程式智慧的所有不同方式的範例，以使組合產品盡可能具有彈性。

透過智慧高可用性增強應用程式的彈性

總之，LifeKeeper 的內建應用程式智慧透過了解應用程式的行為方式及其正確運作所需的條件，實現了精確、快速且可靠的故障轉移和復原。

確保應用程式的彈性和不間斷的服務—請求演示或者開始免費試用今天就體驗 SIOS LifeKeeper 如何使用應用程式智慧來保護您的關鍵工作負載。

作者: Cassy Hendricks-Sinke，首席軟體工程師，團隊負責人

經許可轉載SIOS

在 Nutanix 環境中選擇高可用性解決方案的 10 個注意事項

從 VMware 過渡到 Nutanix

在 Nutanix 環境中選擇高可用性解決方案的 10 個注意事項

如果您打算從 VMware 遷移到 Nutanix，確保您的關鍵應用程式保持正常運作應該是您的首要任務。雖然 Nutanix 提供了簡化管理和更好效能等諸多優勢，但其內建的高可用性僅涵蓋虛擬機，而不涵蓋應用程式本身。本文分享了十個關鍵見解，幫助您提前規劃並避免遷移期間和遷移後出現停機。您將獲得有關為 Windows 和 Linux 選擇正確的叢集解決方案、如何處理 Nutanix 中的共用儲存以及運行混合作業系統時需要考慮哪些事項的實用指導。無論您是遷移到 Nutanix AHV 還是管理混合環境，都可以了解如何簡化 HA 策略、降低風險並保護最重要的系統。

經許可轉載SIOS

我的伺服器是一次性的嗎？高可用性軟體如何適應雲端最佳實踐

我的伺服器是一次性的嗎？高可用性軟體如何適應雲端最佳實踐

在這VMblog 文章“我的伺服器是一次性的嗎？高可用性軟體如何適應雲端最佳實踐”，SIOS Technology 的軟體工程師 Philip Merry 探討了向雲端運算的轉變如何改變了伺服器在現代 IT 環境中的作用和認知。隨著自動化和基礎設施即程式碼的興起，伺服器變得越來越可拋棄，易於建立、銷毀和更換，這與 AWS 完善架構框架中概述的雲端最佳實踐相一致。然而，Merry 強調，雖然基礎設施可以視為臨時的，但在其上運行的應用程式仍然至關重要，並且必須持續可用。為了彌合這一差距，高可用性 (HA) 軟體發揮著至關重要的作用，它允許 IT 團隊透過將應用程式連續性與底層伺服器硬體分離來保持正常運行時間和可靠性。這種方法使組織能夠享受雲端環境的靈活性，同時又不影響其基本應用程式的穩定性和效能。

作者：Beth Winkowski，SIOS Technology Corp. 公共關係

經許可轉載SIOS

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

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

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

在支援團隊工作了近 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