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

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

Windows 集群

Windows 集群

如何在 Windows 中實現高可用性

為減少系統停機時間並確保 Windows 的高可用性，IT 最佳實踐建議您將服務器（或節點）集群化，以便在一個節點出現故障時，一個或多個其他節點自動接管處理。 這也稱為 Windows 群集。

需要集群軟件來監控主節點的運行狀況並在檢測到問題時啟動恢復操作。 HA 集群還需要一種方法來確保在發生故障時輔助節點訪問存儲中數據的最新版本。在大多數情況下，這是通過將集群的所有節點連接到同一個共享存儲來實現的。 集群節點應該在地理上分開，以保護應用程序免受站點範圍和區域性災難的影響。

在 Windows Server 環境中，Microsoft 在 Windows Server 平台中包含了 Windows Server 故障轉移群集 (WSFC)。

什麼是 Windows Server 故障轉移群集？

使用 WSFC，每個活動節點都有一個具有相同硬件規格並共享相同存儲的備用節點。 第三個節點通常配置為“見證”服務器，其唯一目的是確保主節點正常運行，如果檢測到問題，則向備用節點發出故障轉移操作的需要。

除了監控集群的健康狀況外，WSFC 中的節點還協同工作，共同提供：[1]

• 資源管理 –單個節點提供物理資源，例如 SAN 和網絡接口。 託管應用程序註冊為集群資源，並且可以配置對其他資源的啟動和運行狀況依賴性。
• 故障轉移協調——每個資源都託管在一個主節點上，可以自動或手動轉移到一個或多個輔助節點。 發生故障轉移時會通知節點和託管應用程序，以便它們能夠做出適當的反應。 WSFC 與 Microsoft Always On Availability Groups 和 Always On Failover Clustering 協同工作，以協調 Microsoft SQL Server 環境中的故障轉移。

SIOS DataKeeper 如何補充 WSFC

WSFC 需要共享存儲以確保所有集群節點在發生故障轉移時訪問最新數據。 通常，公司使用昂貴的 SAN 硬件來確保數據冗餘。 SAN 代表單點故障風險。 而且，如果您想在具有相同 Windows Server 故障轉移群集保護的雲中運行您的應用程序，則沒有可用的 SAN。

SIOS DataKeeper 集群版通過消除對共享存儲的需求，無縫集成並擴展 WSFC 和 SQL Server Always On Failover 群集。 它提供性能優化的、基於主機的複制，以同步所有集群節點中的本地存儲，創建無 SAN 集群。 當 WSFC 管理集群時，SIOS DataKeeper 執行存儲的同步或異步複製，讓備用節點在發生故障轉移時立即訪問最新數據。 SIOS DataKeeper 不僅消除了 SAN 的成本、複雜性和單點故障風險，還允許您在本地存儲中使用最新的快速 PCIe 閃存和 SSD，以單一成本實現性能和保護 -有效的解決方案。

使用 SIOS DataKeeper，您還可以平衡每個應用程序的網絡帶寬和 CPU 利用率。

• 如果快速復制至關重要，SIOS DataKeeper 可以實現 90% 以上的帶寬利用率以加速數據同步。
• 如果最小化網絡影響是您的首要任務，SIOS DataKeeper 提供集成的壓縮和帶寬限制。

此外，SIOS DataKeeper 的目標快照功能讓您可以從輔助節點運行時間點報告，以卸載可能影響主節點性能的工作負載。 這使您可以更快地查詢和運行報告並做出更快的決策。

與 WSFC 配合使用，SIOS DataKeeper Cluster Edition 使用您選擇的行業標準硬件和本地附加存儲在“無共享”或無 SAN 配置。[2] SIOS DataKeeper 還為雲環境中的關鍵業務應用程序提供高可用性和災難恢復保護，例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Services，而不會犧牲性能。

SIOS 保護套件 – 在沒有 WSFC 的情況下保護 Windows 環境

適用於 Windows 的 SIOS 保護套件包括 DataKeeper、SIOS LifeKeeper 和可選的應用程序恢復工具包，用於領先的應用程序和基礎設施操作。 它是一個緊密集成的集群解決方案，結合了高可用性故障轉移集群、連續應用程序監控、數據複製和可配置的恢復策略，以保護您的業務關鍵應用程序和數據免受停機和災難的影響。

分佈式元數據和通知

WSFC 服務和節點的元數據/狀態託管在集群中的每個節點上。 當任何節點上發生更改時，更新的信息會自動傳播到所有其他節點。

SIOS 保護套件不需要 WSFC，因為 SIOS 會監控應用程序環境（包括服務器、操作系統和數據庫）的健康狀況。 它可以在本地和同一站點或其他位置的另一個集群服務器上停止和重新啟動應用程序。 當檢測到問題時，SIOS 保護套件會自動執行恢復操作並自動管理級聯和優先級故障轉移。

借助 SIOS 保護套件，您可以使用您選擇的 SAN 或 SANless 集群，使用各種存儲設備，包括直連存儲、iSCSI、光纖通道等。

SIOS Protection Suite for Windows 可以滿足您的高可用性和災難恢復需要在單個站點內和跨多個站點。

流行的 SIOS Windows 集群解決方案

下面更詳細地討論了一些最流行的 SIOS Windows 集群解決方案——適用於 SQL Server、SAP 和基於雲的環境。

適用於 SQL Server、SAP、S/4HANA 和 Oracle 的 Windows 集群

SIOS 為應用程序和數據提供全面的 SAP 認證保護，包括高可用性、數據複製和災難恢復。 為了在 Windows 環境中保護 SAP，SIOS 保護套件包括 SIOS LifeKeeper，它可以監控整個應用程序堆棧。 無論您是將 Oracle 數據庫與 SAP 一起使用還是運行獨立的 Oracle 應用程序，SIOS 都會保護您的 Oracle 數據庫——您只需選擇與您的配置相匹配的應用程序恢復工具包。

雲中的 Windows 集群

無論您是需要 SIOS DataKeeper 在雲中啟用 Windows Server 故障轉移群集，還是需要 SIOS Protection Suite for Windows 進行應用程序監控和故障轉移編排，以及高效的塊級數據複製，SIOS 都能提供完整的配置靈活性。 SIOS 允許您在物理、虛擬、雲或混合雲基礎架構的任意組合中創建集群。 例如，使用 WSFC，SIOS DataKeeper 可以：

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

SIOS DataKeeper Cluster Edition 可以提供跨雲的高可用性集群保護

結論

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

• 西澳大利亞的珀斯體育場實施了帶有 WSFC 的 SIOS DataKeeper，為其 Hyper-V 虛擬機提供高可用性。
• 支付寶 ( paygoutilities.com )，總部位於美國，使用 WSFC 實施 SIOS DataKeeper，為 AWS 上的 SQL Server 提供高可用性。
• 總部位於日本的 Toyo Gosei 使用 WSFC 實施了 SIOS DataKeeper，為他們在 Azure 上的 SAP 應用程序提供高可用性和災難恢復。

有關支持 Windows 環境的高可用性/災難恢復解決方案的更多信息，請單擊此處[TM(1].

參考https://www.techopedia.com/definition/24358/windows-clustering https://searchwindowsserver.techtarget.com/definition/Windows-Server-failover-clustering https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15[1] https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15[2]無共享架構 (SN) 是一種分佈式計算架構，其中每個更新請求都由單個節點（處理器/內存/存儲單元）滿足。 https://en.wikipedia.org/wiki/Shared-nothing_architecture轉載自SIOS