如何保護應用程序和數據庫 – SQL Server 群集

使用 SIOS 揭開 SQL 集群解決方案的神秘面紗

SQL Server 群集是用於描述通過 LAN 連接的兩個或多個物理服務器（節點）的集合的術語，每個物理服務器都承載一個 SQL Server 實例並具有對共享存儲的相同訪問權限。 每當承載 SQL Server 實例的服務器出現故障時，群集 SQL 服務器可提供高可用性和災難保護。

如果您在獨立服務器上，硬件故障可能會導致您的操作停止。 但是，通過集群，如果一個節點出現問題，您可以自動故障轉移到另一個節點 – 停機時間最短 – 並在 IT 解決問題的同時繼續讓您的用戶繼續工作。 當主服務器修復後，您可以快速恢復操作。

與使用獨立服務器相比，SQL Server 群集還可以在應用升級和安全補丁時限制停機時間。

儘管SQL Server 群集提供高可用性並最大限度地減少系統停機時間，SQL Server 群集不會提高服務器或應用程序的性能。 為了提高性能，您需要升級服務器的計算能力。

本文介紹了 SIOS SQL Server 群集解決方案，並提供了 SIOS 與 Microsoft 的 SQL 群集解決方案的高級比較。

SIOS SQL Server 集群解決方案

SIOS Technology Corp. 提供高可用性集群解決方案，幫助您從基礎架構和應用程序故障中自動恢復。 支持SQL Server 高可用性, SIOS 提供兩種解決方案：

• SIOS DataKeeper 集群版在 Windows 上運行並利用 Microsoft Windows Server 故障轉移群集 (WSFC) 為 SQL Server 群集提供共享存儲 (SAN) 或不共享存儲 (SANless)。 SANless 環境消除了單點故障，提高了複製效率，保護了 SQL Server 以外的應用程序，並保護了分佈式事務和系統數據庫。
• 適用於 Linux 的 SIOS 保護套件是故障轉移集群、持續應用程序監控、數據複製和可配置恢復策略的緊密集成組合，可在 SAN 或 SANless 環境中保護關鍵業務應用程序和數據庫，包括 SQL Server。

讓我們仔細看看每種解決方案的特點和優勢。

SIOS DataKeeper 集群版

Windows Server 故障轉移群集 (WSFC) 是 Windows Server 平台的一項功能，可提高高可用性。 WSFC 通常用於為使用 SQL Server 的應用程序提供高可用性。 在服務器或應用程序發生故障時，WSFC 協調冗餘計算資源並自動管理備用節點上 SQL Server 操作和數據的恢復。 不幸的是，如果您想在雲中運行 SQL Server 應用程序，則沒有可用的 SAN。

SIOS DataKeeper Cluster Edition 允許您輕鬆創建無 SAN WSFC，從而為在雲、VMware 或 Hyper-V 等虛擬化環境或僅使用本地存儲的物理服務器上運行的 SQL Server 應用程序實現高可用性和災難恢復。在 WSFC 管理軟件集群的同時，SIOS 集群軟件使用實時（同步或異步）塊級複製來同步本地存儲。 同步存儲在 WSFC 看來是傳統的基於 SAN 的存儲。 您還可以構建混合雲配置，以在本地數據中心和雲之間實現災難恢復保護。

SIOS DataKeeper Cluster Edition 軟件已通過 Microsoft 的全面認證，可在跨雲區域和區域的任何配置中以企業級可用性運行。

SIOS SANless 集群不僅消除了 SAN 的成本、複雜性和單點故障風險，您還可以在單一經濟高效的解決方案中使用最新的快速 PCIe 閃存和 SSD 存儲來實現性能和保護。

適用於 Linux 的 SIOS 保護套件

適用於 Linux 的 SIOS 保護套件包括：

• SIOS LifeKeeper，提供靈活的故障轉移集群軟件，監控整個應用堆棧；它根據最佳實踐協調 SQL Server 應用程序的故障轉移
• SIOS DataKeeper，它提供快速、高效的基於主機的塊級數據複製，用於在無 SAN 集群配置中鏡像本地存儲或複製到遠程位置或云以進行災難恢復
• 多應用程序恢復工具包 (ARK) 提供應用程序智能以及自動配置和驗證，以保護您的業務關鍵應用程序和數據免受停機和災難的影響。

雖然 SIOS Protection Suite 可以在 SAN 環境中運行以支持傳統的基於 HA 硬件的集群，但它也可以用於創建一種無共享的服務器集群方法，使其能夠運行 SANless。 它提供了一個強大、通用且易於配置的解決方案，具有適用於各種應用程序的自動和手動故障轉移/故障恢復策略。

SIOS 與 Microsoft SQL 集群解決方案

市場上有其他可用的 SQL Server 群集解決方案。 Microsoft 提供了一些最流行的 SQL Server 群集解決方案，包括：

• SQL Server 基本可用性組
• SQL Server Always On 可用性組
• 具有共享存儲的 SQL Server 故障轉移群集實例

SQL Server 基本可用性組在 Windows 上運行，最多支持一個兩節點群集。 它的工作方式類似於數據庫鏡像解決方案。 雖然集群和鏡像都是提高高可用性的方法，但鏡像只允許數據庫進行故障轉移。 如果您在故障轉移後需要 SQL 之外的其他服務、文件和其他資源，或者如果您有多個必須保持在一起的數據庫，則集群是更好的解決方案。

SQL Server Always On 可用性組可在 Windows 和 Linux 上運行，據微軟稱，它“提供了數據庫鏡像的企業級替代方案”。^[1]它需要昂貴的 SQL Server 企業版。

通過使用帶有 SIOS 的 SQL 群集解決方案的 SQL Server 標準版，您可以節省多達 70% 的軟件許可成本並獲得企業級群集功能。

具有共享存儲的 SQL Server 故障轉移群集實例可在 Windows 和 Linux 上運行。 它是一個單站點解決方案，需要 SAN。

不幸的是，SAN 的購買和維護成本很高，需要 SAN 管理專業知識，並且存在單點故障。 SAN 也會對數據庫性能產生負面影響。

您可以找到 SQL Server Always On、SQL Server Failover Cluster 和 SIOS DataKeeper Cluster Edition 的優缺點的更詳細比較這裡.

雲中的 SQL Server 集群

SIOS DataKeeper 和 SIOS Protection Suite for Linux 提供高可用性和災難恢復分別為在物理、虛擬、雲或混合雲基礎架構的任意組合中運行的 Windows 和 Linux 應用程序提供保護。 例如，SIOS DataKeeper 可以：

• 保護關鍵的本地或混合業務應用程序，包括 SQL Server，以保護 AWS、Azure 或 Google Cloud 中的高可用性 Windows 或 Linux 環境。
• 通過在 AWS、Azure 或 Google Cloud 中創建 Windows 或 Linux 集群來保護您的 SQL Server 雲應用程序。
• 通過跨雲可用區域或區域故障轉移 SQL Server 實例，提供站點範圍、本地或區域的高可用性和災難恢復保護。

SIOS DataKeeper Cluster Edition 和 SIOS Protection Suite for Linux 都模擬集群共享存儲，並且可以跨雲區域和可用區提供完全認證的高可用性集群保護。

最後的想法

SIOS 提供支持廣泛的應用程序、操作系統和基礎架構環境的產品，提供一個可以滿足您所有高可用性需求的單一解決方案。 這裡只是展示 SIOS 強大功能的幾個示例。

• 支付寶（ paygoutilities.com ) 使用 WSFC 實現了 SIOS DataKeeper，為 AWS 上的 SQL Server 提供高可用性。
• 一家醫療保健信息服務提供商使用 SIOS DataKeeper 在超過 18 個集群節點中保護其重要的 SQL Server，從而消除帶寬問題、改進數據保護並減少其關鍵醫療保健網絡環境中的停機時間。
• Mavis Discount Tire 使用 SIOS DataKeeper Cluster Edition 為其業務關鍵型 SQL Server 提供高可用性。

如果您正在尋找一種高可用性/災難恢復解決方案來保護 Windows 或 Linux 環境中的 SQL Server，您可以在這裡找到更多信息.

請參閱有關 SQL Server 高可用性和災難恢復的博客文章.

參考https://www.mssqltips.com/sqlservertip/1541/getting-started-with-sql-server-clustering/ https://www.brentozar.com/archive/2012/02/introduction-sql-server-clusters/^[1] https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-ver15經授權轉載西歐

為什麼需要業務連續性計劃

Facebook、Instagram 和 WhatsApp 剛剛度過了一個非常糟糕的星期一

東海岸的工作日結束了，我看到 Facebook 仍然不可用。 Facebook 在以下兩條推文中承認了這個問題。

雖然我們不知道停機的確切原因，也不知道是用戶錯誤、惡意攻擊還是意外災難性的錯誤，但我們可以在這一點上了解一些有關此停機的信息。

停機時間很昂貴

雖然我們可能永遠不知道今天所經歷的停機時間的確切成本，但有一些成本已經可以衡量。 截至撰寫本文時，Facebook 股價今天下跌 4.89%。 這是在 Facebook 和其他科技股本已殘酷的 9 月之上。

但公司的真正成本是多少？ 隨著許多品牌將社交媒體作為其營銷推廣的重要組成部分，這種中斷將如何影響未來的廣告支出？ 如果廣告商還沒有調查其他社交媒體平台，我至少希望他們調查一下。 只有時間會證明一切，但即使在這次中斷之前，我們已經看到來自其他平台的營銷支出競爭更加激烈，例如滴答聲.

為最壞的情況做計劃

事情發生了，我們知道這一點並為此做好計劃。 業務連續性計劃（BCP）應寫入地址任何可能的災難。 同樣，我們不知道這場特殊災難的確切原因，但我必須想像一下，5 小時以上的 RTO 沒有寫入 Facebook、Instagram 或 WhatsApp 貨架上的任何 BCP。

你的 BCP 裡有什麼？ 你有沒有想過任何可能的災難？ 您是否衡量了停機時間的影響並為您的業務的每個組成部分定義了足夠的恢復時間目標 (RTO) 和恢復點目標 (RPO)？ 我敢說，不可能為所有可能出錯的事情做好計劃。 但是，我建議每個人定期重新訪問您的 BCP 並對其進行更新，以包括您上次查看 BCP 時可能沒有註意到的災難。 您的 BCP 是否有全球流行病？ 如果沒有，您可能已經忙於適應“在家工作”的勞動力。 關鍵是，做最壞的打算，抱最好的希望。

災難中的通訊

發生災難時的通信應該是您 BCP 中的一章。

一名 Facebook 員工告訴路透社，所有內部工具都已關閉。 追踪此事的人士表示，Facebook 的回應變得更加困難，因為員工在關閉期間無法使用自己的一些工具。

多名員工表示，他們沒有被告知出了什麼問題。

https://www.reuters.com/technology/facebook-instagram-down-thousands-users-downdetectorcom-2021-10-04/

一個真正強大的 BCP 必須包括多種備用通信方式。 隨著您的業務分佈在多個建築物、地區或國家/地區，這一點變得更加重要。 想想你的團隊今天是如何溝通的。 電話、短信、電子郵件、Slack 可能是你的前四名。 但是，如果它們都不可用，您將如何联系您的團隊呢？ 如果您不知道，您可能想開始研究其他選項。 您可能不需要短波收音機和一群信鴿，但我敢肯定，有一個政府機構可以將這兩樣東西放在手邊，以應對“緊急情況下的碎玻璃”情況。

概括

您對您自己、您的客戶和您的投資者有責任確保您對您的業務的可用性採取一切預防措施。 確保您在創建 BCP 時投入了足夠的資源，並且負責業務連續性的團隊擁有他們需要的工具，以確保他們能夠在滿足 BCP 中定義的 RTO 和 RPO 方面發揮自己的作用。

修復您的雲之旅

在某種程度上，2020 年和 2021 年改變世界的事件幾乎重塑了我們所知道的一切，高可用性也不例外。 儘管關閉和限制，許多 IT 團隊還是將本地數據中心換成了雲。許多人都在問，“現在怎麼辦？”以下是解決 2022 年雲之旅的五件事。

1. 添加高可用性

   在推動雲計算的過程中，許多 IT 和業務領導者發現自己急於將服務和應用程序從因 COVID-19 而關閉的數據中心遷移到雲中。 其他人湧向雲端，不是因為數據中心關閉，而是為了應對需求爆炸的浪潮。 對於一些人來說，雲之旅是如此之快，以至於 HA 不包括在內，現在他們發現了應用程序仍然在雲中崩潰的艱難方式，意外中斷和計劃外停機仍然是 AWS、Azure 和GCP 與以前的數據中心一樣多。

   修復雲之旅的第一步是添加一個C . 這對您的企業意味著幾件事：

   • 設計和構建高可用性和冗餘架構
   • 選擇將保護關鍵組件和應用程序的軟件和服務
   • 定義和記錄相關的流程和程序，以及至少最低限度的治理
   • 為質量保證、程序測試和混沌測試部署生產副本

2. 擴展以提高災難恢復的可用性

   當然，並不是每個人都在不考慮某種形式的 HA 的情況下遷移到雲。 一些 IT 團隊有先見之明，不會將 HA 留在本地，但在急於上雲的過程中，他們將所有關鍵服務器都移到了同一個雲可用區。 雖然擁有一些 HA 保護比完整的漏洞要好，但如果您只將服務器和應用程序部署在單個可用區 (AZ) 中，現在是時候為備用集群節點擴展至多可用區，甚至內置通過在不同區域部署第三個節點進行災難恢復。 SIOS 已幫助數十家客戶規劃多可用區架構並添加災難恢復解決方案。

3. 建立你的團隊

   一夜之間，一些公司及其 IT 團隊從完全本地化轉變為與 Cloud Formation 模板、快速入門指南、IAM 角色、內部負載均衡器、覆蓋 IP 以及破譯 VM 大小的確切含義有關。現在是組建團隊來支持雲之旅的時候了。這將意味著幾件事：

   • 增加容量。除非您能夠完成一個完整的提升和轉變，否則您可能會擁有相同的員工來管理雲和本地應用程序。傳統解決方案以喜怒無常而著稱，需要大量工作才能保持穩定和可用。要駕馭未來的雲之旅，您需要能夠滿足可用性要求、了解雲架構並為企業需求規劃前進方向的能力。
   • 通過培訓提高技能。為您的團隊提供雲培訓。要管理和規劃課程，請通過有關雲解決方案、架構、最佳實踐和權衡的額外培訓，尋找方法來增強組織內的 IT 卓越性。訓練有素的員工不僅會在提高可用性方面獲得紅利，而且還會通過以經濟、可擴展和合乎邏輯的方式解決可用性、維護和增長問題，從而獲得紅利。翻譯：他們會在構建雲基礎架構的其餘部分時避免浪費金錢。

4. 集成自動化和分析

   作為 SIOS Technology Corp. 的客戶體驗副總裁。 我曾與幾家公司合作，這些公司在 2021 年遷移到雲，而沒有犧牲 HA、DR 或他們的團隊。如果您認真對待達到所需的正常運行時間數（99.99%）並且制定災難計劃是不可協商的，那麼是時候增加分析和額外監控的嚴格性了。 確保您的可用性解決方案具有應用程序感知自動化和編排功能，以便在發生災難或計劃外停機時進行恢復。 添加分析和自動化以鞏固您的解決方案，並使您的雲遷移從被動故障轉移到主動通知和故障發生前的緩解。想像一下，如果應用程序性能不佳，或者延遲增加、錯誤或 VM 無響應行為及時得到通知，以避免在業務高峰期出現停機。 分析也很重要，因為它們可以揭示可能已經逃離原始可用性架構的系統和應用程序。

5. 更新流程和治理

   我們認為失敗的許多事情都植根於過程的失敗。 確保您組織的流程是最新的、有據可查的、適當的溝通和遵守。 這些流程應包含與誰、什麼、何時、何地以及如何與客戶相關的業務戰略、目標和組織需求相關的一些關鍵最低要求。

   確保您的新雲環境的所有權和簽核流程有據可查。 對於從獲取基礎架構的硬件團隊轉移到雲團隊的客戶，我親眼目睹了來自衝突、衝突或未解決的角色和責任的挫敗感。 在遷移中糊塗是一組痛點，在沒有明確治理的情況下從災難中挖掘出來是一個更大、成本更高的問題。

   如果您已經實現了向雲的飛躍，那麼留在那裡並使其為您工作是旅程的下一部分。如果您的雲之旅突然或崎嶇不平，請考慮這五點來修復您的雲之旅，並了解 SIOS 技術不僅可以幫助您提高雲中的高可用性，還可以幫助您提高在雲中運行的流程。

經授權轉載西歐

如何安裝 SIOS DataKeeper Cluster Edition 許可證密鑰

一旦你安裝了SIOS DataKeeper 集群版軟件並已激活您的許可證，您需要先安裝許可證密鑰，然後才能開始。 這個 4 分鐘的視頻將回顧如何安裝 SIOS DataKeeper Cluster Edition 軟件並演示如何激活您的許可證以開始保護您的關鍵應用程序。

觀看 SIOS 支持代表演示安裝 SIOS 許可證所需的三個關鍵先決條件中的每一個：確保您擁有 SIOS DataKeeper 軟件的最新版本和更新；使用我們簡單的許可證密鑰管理器來驗證您的激活的許可證從購買的權利，下載並應用許可證密鑰並開始您的SIOS DataKeeper 軟件.

該視頻還介紹了訪問我們的過程SIOS 文檔門戶，您可以在其中找到詳細說明 SIOS DataKeeper Cluster Edition 的發行說明、安裝指南、技術文檔和信息，以及有關 SIOS 的各種主題。

查看有關如何快速簡單地完成步驟的提示和方便的見解。現在您開始使用 SIOS DataKeeper 集群軟件保護您的關鍵應用程序

 

提高集群彈性、性能和結果的四種避免策略

在 SIOS Protection Suite 集群環境中部署的簡單步驟

避免某些事情——我們以前都做過。我們在與配偶散步時在商店裡看到的舊情人，在我們“不准備購買”時看到的銷售人員，甚至在我們“度假”時看到的老闆。當我是一個開發團隊的經理時，我瞥見了一個直接報告在他們應該不在辦公室的時候在商店裡瀏覽。他們躲在衣架之間，匆匆跑下下一個過道，匆匆離開。我們以前都這樣做過，在某些情況下，出於心理健康、身體健康或隱私和個人原因，我們都需要採取一些避免措施。即使在 HA。那麼，您如何為您的高可用性環境添加規避功能，為什麼？

在高可用性中使用迴避策略的四個理由

1. 更好的性能（最小化服務器過載）

在 HA 中使用避免策略的原因之一是提高應用程序和服務器性能。考慮運行生產工作負載的三台服務器的情況，我們稱它們為 Server Alpha、Server Beta 和 Server Gamma。服務器 Alpha 和 Beta 運行由數據庫支持的關鍵應用程序，而服務器 Gamma 運行報告和數據轉換作業。如果 Server Alpha 出現故障，通常會發生故障轉移到 Server Beta。但是，由於服務器 Beta 已經在運行大量工作負載，因此產生的額外應用程序負載可能會導致服務器過載和兩個應用程序的性能不佳。因此，部署避免策略以確保選擇 Server Gamma 作為故障轉移目標可能是明智之舉。

2. 性能優化

再次考慮三個服務器的場景，Alpha、Beta 和 Gamma。服務器 Alpha 和 Beta 可擴展以處理峰值工作負載，而服務器 Gamma 是成本優化的服務器。如果 Server Alpha 和 Server Beta 出現故障，則會發生故障轉移到成本優化的服務器 Gamma。但是，此服務器無法擴展以處理峰值工作負載，也無法同時處理 Server Alpha 和 Server Beta 的工作負載。在這種情況下，可以使用避免策略通過在另一台主機可用時立即從 Server Gamma 自動移動一個或兩個工作負載來優化性能。

3. 高可用優化

HA 優化是另一種部署迴避策略的場景。 與性能優化策略一樣，HA 優化用於確保您的環境能夠承受大多數故障情況，並且您的應用程序經過優化以在任何時間點提供最高級別的可用性。HA 優化對於具有復制入隊進程的 SAP 等應用程序很重要。在任何 SAP 環境中，您都不希望 ASCS（ABAP SAP 中央服務）和 ERS（入隊複製服務）實例長時間駐留在同一服務器上，因為存在丟失鎖定和取消作業的風險。 為了防止這種情況發生，您可以使用避免策略，使 ERS 和 ASCS 實例始終在相對的集群節點上運行。考慮運行生產工作負載的三台服務器的情況，我們將它們稱為服務器 Alpha、Beta 和 Gamma。Server Alpha 正在運行 ASCS 實例，而 Server Beta 正在運行 ERS 實例。服務器 Gamma 用作服務器 Beta (ERS) 和服務器 Alpha (ASCS) 故障轉移的第三個節點。如果 Beta 崩潰，您不希望 ERS 資源與 ASCS 實例在同一節點上運行。為確保此操作，您可以部署避免策略，首先自動檢查並確保兩個應用程序位於不同的服務器上，並維護 SAP ASCS/ERS 鎖定故障轉移的最佳實踐。

4. DR 避免

假設您有兩個數據中心：City Alpha 和 City Beta，它們相距約 70 英里，您的大多數客戶都位於它們之間的中心。 但是，由於最近內部組織的變化、合併/關閉和收購以及治理要求，您的 IT 團隊必須添加位於 City Gamma 的第三個數據中心，距離 Alpha 和 Beta 大約 350 英里。現在主要在 Alpha 和 Beta 中保護的資源也擴展到 Gamma 位置。鑑於大多數用戶和團隊都在 Alpha 和 Beta 位置附近，即使是最極端的用戶也位於鄰近城市，您的團隊需要避免故障轉移到 Gamma 位置。 與其他策略一樣，DR 避免尋求通過避免 DR 節點來優化性能、輸入/輸出區域數據成本、延遲和客戶端訪問，如果任一區域內只有一個節點發生故障。它還可以確保即使兩個節點在不同的時間後都發生故障，在轉移到 DR 之前，故障轉移總是發生在集群或數據中心中的另一個節點上。那麼，您如何部署迴避策略呢？許多提供程序具有可以配置的關聯規則，而其他提供程序使用服務器優先級或手動步驟的組合。對於適用於 Linux 的 SIOS 保護套件，您可以使用多種內置方法，包括：

1. 資源優先級

如果發生故障，資源將故障轉移到剩餘優先級最低的服務器，並級聯到任何其他服務器（Alpha、Beta 和 Gamma）。Server Alpha 是Resource.HR 的主服務器，Server Beta 是Resource.MFG 的主服務器，Server Gamma 是所有資源/服務器的備份服務器。使用資源優先級，Resource.HR 在服務器 Alpha 上的優先級為一 (1)，在服務器 Gamma 上的優先級為二 (2)。而 Resource.MFG 在服務器 Beta 上的優先級為一 (1)，在服務器 Gamma 上的優先級為二 (2)。如果客戶想要優化環境的使用，那麼 Resource.HR 在 Server Beta 上的優先級可以是三 (3)，Resource.MFG 在 Server Alpha 上的優先級可以是三 (3)。如果服務器 Alpha 發生故障，資源 Resource.HR 將首先失敗到服務器 Gamma，然後再嘗試在服務器 Alpha 上投入使用（恢復）。

適用於 Linux 的 SIOS 保護套件（UI 和 CLI）允許用戶為每個服務器和資源組合指定優先級。

2. 策略或關聯規則

策略規則還可用於防止在給定服務器上發生資源恢復，從而允許資源避開可能正在運行更關鍵或資源密集型工作負載的指定服務器。典型的政策包括：

• • • • • • 默認情況下將阻止來自特定服務器的應用程序的約束策略。
          • 將阻止應用程序來自沒有足夠資源的服務器的資源策略
          • 定義允許或禁止資源進入系統的時間段的臨時策略
          • 定義首選服務器或集群內可能的應用程序所有權能力的自定義策略。

SIOS Protection for Linux CLI 允許用戶指定策略規則，這些規則可以禁用故障轉移到指定服務器的特定資源、提供保護故障的臨時策略、禁用特定應用程序類型的故障、約束策略和自定義策略。

• 特定規避資源

建立資源避免策略的最細粒度的方法是在每個層次結構中部署特定的避免腳本。這種方法將允許用戶配置特定的應用程序（例如 app1 和 app2），盡可能避免彼此，同時允許其他應用程序不受限制地運行。在我們的三個服務器（Alpha、Beta 和 Gamma）以及三個資源 app1、app2 和 app3 的情況下，此方法將提供最大的靈活性。在這個例子中，app1 和 app2 將在服務器出現故障時尋求避免配置，但 app3 將根據優先級失敗到下一個可用節點，沒有任何配置限制。

有關避免策略和資源的其他示例，請考慮適用於 Linux 的 SIOS 保護套件文件.如果客戶有兩個應用程序 app1 和 app2，他們需要盡可能在不同的節點上運行，則客戶可以使用 SIOS Protection Suite for Linux gen/app 資源和 '/opt/LifeKeeper /lkadm/bin/avoid_restore' 腳本。

– 客戶體驗副總裁 Cassius Rhue

轉載自SIOS