SIOS SANless clusters High-availability Machine Learning monitoring
採用合適的高可用性方案，確保您的關鍵業務 Linux 應用程式持續穩定運作。本白皮書將 SLES HAE 和 RHEL HA 中的開源高可用性框架 Pacemaker 與 SIOS LifeKeeper for Linux（一款功能齊全的商業高可用性和災難復原平台）進行比較。
了解架構、部署、管理和長期可靠性方面的關鍵差異如何影響實際結果。無論您是經驗豐富的 Linux 高可用性專家，還是需要更簡單、更可預測的解決方案，本指南都能幫助您選擇最合適的方案。
下載該文檔，使您的 Linux 高可用性策略與您的技能、基礎架構和可用性要求相符。
經許可轉載SIOS
最近，我讀了一本關於數學史的書（當然，大家都會讀）。這本書主要講述了古巴比倫和埃及的抄寫員早期的數學發展和實踐，以及他們如何將數學知識過渡到我們熟知的古希臘數學家，例如畢達哥拉斯和阿基米德。探索人類如何學習推理和解釋周圍的世界總是令人著迷。在閱讀的過程中，我注意到許多行為和方法，即使是對簡單的算術都一竅不通的人，也運用了這些方法。我認為這些方法同樣適用於商業和人際關係！
我從他們處理一些複雜的除法和平方根運算的方法中汲取了靈感。他們會用一個稍大、更容易計算的數字和一個稍微小一點的數字來取平均值。用這種方法得到的結果與電子計算器顯示的結果相比，往往驚人地準確。我甚至在學校學習平方根的時候也用過這種方法。例如，16 和 25 分別是 4 和 5 的完全平方數，所以 20 的平方根大約是 4.5（用計算機的話是 4.47）。
所以，如果你遇到需要處理棘手溝通的情況，尤其是在需要態度強硬或劃定界限，卻又不知如何把握分寸的時候，不妨試試這個近似方法：找出明顯過於嚴格的最低限度，再找出明顯過於寬鬆的上限，最後取一個介於兩者之間的平均值。
只要你能為正確答案設定一些合理的“參考點”，就能比較接近你想要的答案。但如果參考點範圍太廣，反而會適得其反。
例如，假設你有一個大客戶，他要求的服務遠遠超出了你們最初約定的範圍。你可以把“超出範圍”的界限設定為“無論如何，我都會滿足他們的所有要求”，顯然，這超出了他們的預期，因為這本來就是你們最初約定的內容。反之，你的「超出範圍」的界線可能是「我不需要做任何超出合約明確規定的事情」。這在理論上似乎很有吸引力，有時也確實有效，但在這種情況下，它顯得過於僵化，可能會損害雙方的關係。我們需要更精確地設定界線。
那麼，讓我們從光譜的低端開始。或許你可以先列出你絕對會做並且已經同意完成的任務，然後再考慮他們提出的其他要求。一旦這些任務確定下來，無需再做任何考慮，就審視一下他們提出的其他要求，判斷哪些完全不合理或目前無法實現；這些要求就屬於你做得過頭了，應該從執行清單中排除。
現在，對於那些仍在考慮範圍內的項目（這些項目並非明顯屬於「必須做」或「絕對不能做」的範疇），您已經處於近似區域。這樣一來，你無需在所有事項中糾結該如何處理，而是可以縮小範圍，更精準地確定問題所在。把這些事項放在一起，直到你感覺自己已經掌握了在這種情況下應該採取的合適做法，然後再和你的伴侶討論。此外，你甚至可能還有一些協商的空間！
現在我們已經看到了眾多方法中的一種，你可以將這些源自古代、看似矛盾卻又不夠精確的數學度量方法，運用到你自己的挑戰中！畢竟，在那個時代，數學所要解決的問題和挑戰更根植於文明的日常需求，而不是登月或化學合成等宏大事業。重要的不是數學的起源，而是你如何運用它來思考。提供卓越的客戶體驗。
作者：Matthew Pollard，SIOS客戶體驗軟體工程師
經許可轉載SIOS
在《企業時報》文章SIOS 合作夥伴聯盟總監 Harry Aujla 探討了為何災難復原 (DR) 在保護 SAP 環境和確保業務連續性方面應與高可用性 (HA) 同等重要。他闡明了 HA 和 DR 之間的區別，強調 HA 旨在確保系統在局部故障期間持續運行，而 DR 則專注於在網路攻擊或自然災害等重大事件發生後恢復業務運營。
本文概述了災難恢復投入不足所帶來的業務、財務和監管風險，並引導讀者了解兩種核心恢復模型：站點級恢復和應用級恢復，重點介紹了每種模型的優勢、權衡取捨和成本考慮。 Aujla 總結道，SAP 災難復原沒有一成不變的模式，他敦促各組織根據業務優先順序、服務等級要求和停機容忍度來製定策略，從而建立一個具有彈性和實用性的復原計畫。
經許可轉載SIOS
當設計驅動創造時，成果便易於溝通。以設計為先導的理念能夠創造出便於個人有效訓練的解決方案。運用設計原則來傳達目標，可以帶來易於維護和改進的解決方案。當然，當解決方案基於工具建構時，工具的設計使用方式必須與它所支援的解決方案的設計結合起來考慮。
所選工具會將它們的設計假設強加於使用它們的項目中。如同先前的相關部落格文章所述設計理念和目標一致是創建易於理解的解決方案的第一步。當然，專案中使用的工具可能包含與專案設計理念格格不入的模式。
初始設計與所用工具之間的衝突會造成複雜性，並降低解決方案的有效性。因此，必須選擇合適的工具，使其使用與專案設計一致。當工具與設計協調一致時，複雜性就會降低。在高可用性和災難復原的背景下，設計與所用工具協調一致的影響尤其顯著。
高可用性和災難復原設計通常預設了複雜性。IT基礎架構設計模式為了滿足高可用性和災難復原固有的高標準，個別基礎設施元件越來越需要嘗試在各自的範圍內實施相應的模式。
各個組成部分共同努力解決以下問題：高可用性和災後復原就其作用而言，由於組件採用不同的設計原則來解決高可用性和災難復原問題，環境必然會變得臃腫。
工具不斷發展，並可能形成相互競爭的設計原則，然而，環境需要的是具有凝聚力的設計。隨著原本互不相關的工具開始互相干擾，複雜性也滲透到基礎架構中。隨著IT系統在用途和可用性標準方面的不斷提升，遵循凝聚力設計並實現互補工具的基礎設施的重要性也日益凸顯。技術進步為實現高可用性和災難復原提供了多種策略，IT基礎設施也在不斷發展，以適應針對其他用例量身定制的設計模式。只要看看…常見的雲端設計模式微軟在其文件中發布了這些模式。每種模式的適用性顯而易見，但模式之間也可能存在衝突。模式重疊難以處理，這會使IT基礎架構的設計過程變得複雜。基礎設施通常需要採用多種設計模式，因此，越來越需要那些「互不干擾」的模式。
作者：Philip Merry – SIOS 軟體工程師
經許可轉載SIOS
合理的記憶體分配是任何系統中都至關重要但卻常常被忽略的組成部分。高可用性 (HA) 環境當伺服器出現記憶體分配問題時，其影響會波及整個集群，導致應用程式效能下降、複製速度減慢，甚至故障轉移失敗。在更嚴重的情況下，記憶體耗盡可能會中斷 SIOS 工具，例如…DataKeeper 和 LifeKeeper這進一步增加了發生不可預測和意外行為的風險。了解記憶體對高可用性環境的影響是維持系統穩定性、效能和可預測故障轉移行為的關鍵。
下面，我們將探討為什麼合理的記憶體分配至關重要，需要注意哪些症狀，以及記憶體相關問題如何影響系統的可靠性。簇在 LifeKeeper/DataKeeper 環境中。
記憶體不足最顯著的影響之一是複製效能下降。諸如此類的產品資料保管員DataKeeper 依賴對系統記憶體的持續存取來緩衝寫入操作。當記憶體受限時，佇列開始填充，複製速度減慢，在某些情況下，鏡像可能會因資源耗盡而掛起。這會導致重新同步操作耗時遠超預期，尤其是在高寫入速率的環境中。此外，DataKeeper 應用程式的非正常終止會導致某些進程未被監控/處理，從而在再次「啟動」DataKeeper 服務時出現意外行為。
當系統記憶體不足時，作業系統可能會開始對活動進程進行分頁或交換。在運行諸如以下應用程式的高可用性環境中：SQL Server這會導致查詢速度變慢、回應延遲以及磁碟活動頻繁，因為記憶體頁需要不斷移動。這些延遲通常會加劇故障轉移時間，因為在故障轉移事件期間，服務需要更長時間才能優雅地停止或重新啟動。
高可用性解決方案依賴節點間及時的心跳通訊。當記憶體耗盡時，負責發送或處理心跳訊息的執行緒可能會延遲。即使是很小的延遲也會導致原本健康的節點看起來沒有回應，造成不必要的資源浪費。故障轉移或者，在最糟糕的情況下，裂腦事件。
記憶體不足通常會導致特定的系統訊息（Windows 或 Linux）。這些訊息可能包括可用記憶體不足的警告、頁面調度活動激增，或作業系統終止進程以回收記憶體。對於運行複製驅動程式或高可用性 (HA) 服務的系統，這些警告通常預示著更嚴重的問題即將出現。
在虛擬化環境中，即使虛擬機器報告「可用」內存，也可能出現內存問題。像虛擬機器管理程式這樣的VMware，Hyper-V， 或者雲端平台可能會透過諸如記憶體氣球或過度分配等技術來限制記憶體存取。這會悄無聲息地影響虛擬機器效能，導致複製延遲、心跳問題等，且難以找到問題的根本原因。
在以下情況下，您可能需要增加或調整記憶體分配：
在 HA 環境中，記憶體不僅用於提升效能；它還有助於確保可預測的故障轉移行為，並防止級聯服務中斷。
記憶體壓力幾乎會對高可用性 (HA) 環境的每一層都產生負面影響，從複製驅動程式到應用程式效能和故障轉移時間。合理的記憶體分配有助於確保可預測的效能、穩定的叢集通訊以及故障轉移發生時的可靠恢復。透過主動監控和規劃記憶體使用情況，組織可以…避免不必要的停機時間並維持其係統所需的高可用性。如果記憶體分配問題影響了高可用性效能或故障轉移行為，申請SIOS演示看看我們如何幫助提高可靠性。
作者：Aidan Macklen，SIOS Technology Corp. 的助理產品支援專家。
經許可轉載SIOS