SIOS 技術加入 Nutanix Elevate 合作夥伴計劃

西奧斯科技公司。宣布其加入Nutanix Elevate 合作夥伴計劃，標誌著為 Nutanix AHV 環境中的關鍵應用程式提供易於使用的 HA 叢集解決方案的里程碑。

授予 SIOS 的 Nutanix Ready 驗證稱號的完成證明了 SIOS生命守護者和資料管理員與 Nutanix 基礎設施的互通性。作為此次驗證的一部分，兩家合作夥伴正在合作幫助共同客戶從持續創新中受益。

SIOS 的業績記錄包括成功為客戶實施 HA 和 DR，在全球安裝了 80,000 多個許可證，保護各行業公司的應用程式。

LifeKeeper 和 DataKeeper 產品已完成驗證測試，這可以讓客戶對解決方案的兼容性更有信心。 LifeKeeper for Linux 使 Nutanix 能夠為客戶提供簡單、可靠的 HA，以實現以深厚的 HA 專業知識為後盾的業務關鍵型應用程式。透過SIOS 產品，具有本質複雜環境（例如SAP、HANA、SQL Server 以及在SUSE Linux、Red Hat Linux、Oracle Linux、Rocky Linux 和Windows Server 中運行的其他環境）的Nutanix 客戶可以透過實作、維護來節省時間並消除代價高昂的停機時間。

SIOS 全球行銷副總裁Margaret Hoagland 表示：「加入Nutanix Elevate 合作夥伴計畫證明了我們致力於為客戶提供強大的HA 解決方案、擴大我們的覆蓋範圍並為Nutanix 用戶提供他們所需的可靠性和簡單性，以確保不間斷的運行其關鍵應用程式的操作。

榮獲「Nutanix Ready Validated」稱號的 SIOS 產品包括：

• Linux 版 LifeKeeper 9.8.0
• 適用於 Windows 8.10.0 的 LifeKeeper
• 適用於 Windows 8.10.0 的資料管理器

LifeKeeper for Linux 為最廣泛的 Linux 作業系統發行版、版本和平台提供 HA；本地、虛擬和雲端。 SIOS 的 HA/DR 產品組合包括頻寬高效、基於主機的區塊級複製、應用程式復原套件 (ARK)，以支援 SAP、HANA 和其他流行資料庫和應用程式的應用程式感知，以及通用的可自訂 ARK。 LifeKeeper for Linux 為應用程式、資料庫和儲存提供自動監控、問題檢測和智慧恢復，以確保關鍵系統和應用程式保持高可用性。

有關 SIOS-Nutanix 解決方案的更多信息

逐步操作 – OCI 中的 SQL Server 2019 故障轉移群集實例 (FCI)

介紹

如果您在 Oracle 雲端基礎架構 (OCI) 中部署關鍵業務應用程序，那麼了解並利用 OCI 提供的可用性 SLA（服務等級協定）以獲得最佳正常運行時間和可靠性至關重要。 OCI 的 SLA 根據您選擇的部署策略而有所不同：

跨可用性域部署：當您在同一 OCI 區域內的不同可用性網域中部署兩個或多個虛擬機器 (VM) 時，OCI 提供 99.99% 的可用性 SLA。

跨故障域部署：如果跨故障域部署虛擬機，OCI 提供 99.95% 的可用性 SLA。需要注意的是，並非每個 OCI 區域都有多個可用性域，因此在某些區域，跨故障域部署將是您唯一的選擇。

單一虛擬機器部署：對於涉及單一虛擬機器的部署，SLA 為 99.9%。

此框架表示 OCI 根據您部署 VM 的方式保證一定程度的外部連線：

請務必注意，SLA 涵蓋虛擬機器本身的可用性，而不是其上執行的應用程式或服務的可用性。為了確保應用程式可用性，需要採取額外的措施，例如應用程式監視、復原計畫、資料複製和交易複製（適用於 SQL Server 等資料庫）。策略可能包括負載平衡、叢集或資料複製，以有效管理應用程式可用性。

為了滿足 OCI 中 99.99% 可用性 SLA 的標準，必須跨多個可用性網域部署虛擬機器。這篇文章將指導您設計 OCI 基礎設施，以促進跨可用性網域的 SQL Server 故障轉移叢集實例，從而確保關鍵業務應用程式的最大正常運作時間和可靠性。

建立 VCN 和子網

在本指南中，我假設您對 Oracle 雲端基礎架構 (OCI) 有一定的了解並對網路概念有基本的了解。我將透過描述來說明常見的配置任務，並在必要時提供額外的指導來應對 OCI 網路中遇到的一些常見挑戰。

從深思熟慮的網路計劃開始至關重要。本文檔不會涵蓋雲端網路規劃的複雜性，因此以下範例應僅被視為多種可能性之一。您的網路配置可能會有很大差異。但是，一個重要的考慮因素是規劃至少使用三個可用性域，為每個叢集節點分配一個，為檔案共用見證分配另一個。叢集所需的重要一點是每個可用性域必須位於不同的子網路中。

儘管我們沒有涵蓋跨故障域而不是可用性域的配置，但這同樣適用於跨故障域的叢集 – 所有節點必須駐留在不同的子網路中。

在我們的場景中，我們將在 OCI 中的單一虛擬雲網路 (VCN) 內跨三個不同的可用性域設定三個子網路。

VCN：10.0.0.0/16

• AD1：10.0.0.0/18
• AD2：10.0.64.0/18
• AD3：10.0.128.0/18

OCI 的使用者介面可能會發生變化，但在撰寫本文時，在 OCI 控制台中建立新 VCN 和三個子網路的過程非常簡單。具體細節可以在 OCI 文件中或透過其使用者介面找到，它會引導您完成 VCN 和子網路建立的必要步驟。

創建VCN

在 VCN 中建立三個子網

建立 Internet 網關

互聯網網關是我們的實例存取互聯網的方式。在您的網路中，您可能不希望實例能夠存取互聯網，但在本範例中，我們將啟用它並將其新增至我們的預設路由表中。

編輯預設安全列表

編輯路由表

編輯路由表，以便所有發送到 VCN 外部的流量都透過 Internet 閘道進行路由。

建立網路安全群組

編輯安全列表

這些設定允許跨可用性網域不受限制的訪問，並允許從任何地方進行 RDP 存取。您可以考慮限制哪些 IP 位址可以 RDP 到您的實例，甚至設定一個專門用於從公共網路進行 RDP 存取的「跳轉虛擬機器」。

編輯 DHCP 選項

為了讓 Active Directory 正常運作，您必須在 DHCP 選項中將 DC1 設定為主 DNS 伺服器，如下所示。在本例中，我們將其設定為 10.0.0.100，這是我們正在設定的網域控制器的靜態 IP。您還應該將您的網域新增至自訂搜尋網域。在本例中，我們將使用名為 datakeeper.local 的網域，稍後我們將在配置網域控制站時建置該網域。

配置虛擬機

現在 VCN 已配置完畢，是時候開始設定虛擬機器了。在此範例中，我們將使用Windows Server 2022 和SQL Server 2019。 。

在開始之前，制定計劃再次很重要。在這種情況下，您需要規劃伺服器名稱、IP 位址及其可用區佈局。如前所述，每個叢集節點和檔案共用見證都必須駐留在不同的可用區中。

在範例配置中，我們將在實例 (DC1) 中部署 Active-Directory，該實例也將充當檔案共用見證。

AD1 – DC1 (10.0.0.100)

AD2 – SQL1 – (10.0.64.100, 10.0.64.101, 10.0.64.102)

AD3 – SQL2 – (10.0.128.100, 10.0.128.101, 10.0.128.102)

您可能已經注意到，每個叢集節點（SQL1、SQL2）都有三個 IP 位址。第一個位址是實例的私有IP位址。另外兩個 IP 位址將會作為輔助位址新增到每個實例上。這些 IP 位址包含與 SQL Server FCI 網路名稱資源關聯的核心叢集 IP 位址和虛擬 IP 位址。

當我們配置叢集節點時，我們將使用不包含 SQL Server 軟體的基本 Windows Server 2022 映像。相反，我們將下載 SQL Server 安裝媒體並使用永久 SQL Server 許可證，而不是 Marketplace 上提供的「即用即付」許可證。

以下部分說明了配置本範例中使用的三個虛擬機器的過程。

在FD1中配置DC1

選擇執行個體類型時，您必須根據工作負載適當調整執行個體類型。這與您調整實體伺服器大小以在本地使用時所做的類似，但不同之處在於，如果您首次過度配置或配置不足，或者您的工作負載隨著時間的推移增加或減少。

指定實例詳細資料時，請確保選擇正確的 VCN 和子網路以進行正確放置。在第一個畫面上，您也可以指定要與該執行個體關聯的靜態 IP。

在 FD2 中配置 SQL1

如前所述，此範例使用 Windows Server 2022 的基本安裝。

在 FD3 中設定 SQL2

添加額外的捲

叢集中的每台伺服器都需要至少一個額外的磁碟區。這些磁碟區對於 SQL Server FCI 的儲存需求至關重要，並由 SIOS DataKeeper 複製。

多卷

您可以新增多個磁碟區來分隔資料、日誌和備份。

儲存類型：多種儲存類型可供選擇，以滿足不同的需求。

附著方法

有多種方法可以將儲存空間連接到伺服器。

配置範例

下面，我們提供了螢幕截圖，展示了多種可能的儲存配置之一。這是一個實際範例，有助於理解設定過程。此程序應在 SQL1 和 SQL2 上完成。

建立區塊卷

首先，在正確的可用性網域中為 SQL1 和 SQL2 建立區塊磁碟區。

附加卷

現在卷已創建，您必須將它們附加到實例。

需要記住的要點

設定靈活。您可以根據您的特定需求配置一個或多個磁碟區。

考慮適合您的配置的不同儲存類型和連接方法。

新增輔助 IP 位址

為了讓 Windows Server 故障轉移叢集在 OCI 中正常運作，您必須將叢集 IP 位址新增為附加到 SQL1 和 SQL1 的虛擬網路介面 (VNIC) 上的輔助位址。您還記得，我們​​討論過在每個叢集節點上使用以下 IP 位址。

	SQL1	SQL2
主要地址	10.0.64.100	10.0.128.100
集群IP 1（核心集群資源）	10.0.64.101	10.0.128.101
叢集IP 2（SQL Server叢集IP）	10.0.64.102	10.0.128.102

在 SQL1 和 SQL2 上，編輯附加的 VNIC 以新增輔助位址。

建立網域

為了實現彈性，您應該在不同的可用區域配置多個 AD 控制器，但出於本指南的目的，我們將只配置一個 AD 控制器。請依照下面的螢幕截圖在 DC1 上設定 AD。

使用實例詳細資料部分中所列的憑證登入。系統將提示您重設密碼。

啟用 Active Directory 網域服務

將伺服器升級為網域控制器

在開始此程序之前，請在伺服器上啟用本機管理員帳戶並設定密碼。如果不這樣做，當您嘗試升級網域控制站時，您將收到此訊息。

啟用管理員帳戶並設定密碼後，繼續進行部署後配置

在啟用 Active Directory 網域服務之前，您必須啟用本機管理員帳戶並使用該帳戶登入。

使用您喜歡的 RDP 程序，使用與執行個體關聯的公共 IP 位址連接到 DC1。新增 Active Directory 網域服務角色。

安裝完成後，將此伺服器提升為網域控制站。

出於我們的目的，我們將建立一個新網域。

重新啟動 DC1 並繼續下一部分。

將 SQL1 和 SQL2 新增至網域

準備儲存

將 SQL1 和 SQL2 新增至網域後，使用您建立的網域管理員帳戶連線到執行個體以完成其餘的設定步驟。您需要做的第一件事是附加並格式化我們新增到 SQL1 和 SQL2 的 EBS 卷，如下所示。

配置故障轉移集群功能

在 SQL1 和 SQL2 上啟用故障轉移群集功能。

在 SQL1 和 SQL2 上執行此 PowerShell 命令

安裝-WindowsFeature-名稱故障轉移群集-IncludeManagementTools

驗證您的集群

從 SQL1 或 SQL2 執行此 PowerShell 命令

測試集群-節點 sql1,sql2

根據您使用的 Windows Server 版本，您將看到一些有關網路和可能儲存的警告。網路警告可能會告訴您每個叢集節點都可以透過單一介面存取。早期版本的 Windows 會警告您缺少共用儲存。

您可以忽略這兩個錯誤，因為它們在 OCI 託管的叢集中是預期的。只要您沒有收到錯誤，就可以繼續下一部分。如果您收到任何錯誤，請修復它們，然後再次執行驗證並繼續下一部分。

建立集群

接下來，您將建立叢集。在下面的範例中，您會注意到我使用了我們計劃使用的兩個 IP 位址：10.0.64.101 和 10.0.128.101。您可以從任一群集節點執行此 Powershell。

新叢集 -名稱 cluster1 -節點 sql1,sql2 -靜態位址 10.0.64.101, 10.0.128.101

請注意：不要嘗試透過 WSFC GUI 建立叢集。您會發現，由於執行個體使用 DHCP，GUI 不會為您提供為叢集指派 IP 位址的選項，而是會散佈重複的 IP 位址。

新增文件共享見證

為了維持集群仲裁，您需要新增見證人。在 OCI 中，您要使用的見證類型是檔案共用見證。檔案共享見證必須駐留在與兩個群集節點不同的故障域中的伺服器上。

在下面的範例中，將在駐留在 FD1 中的 DC1 上建立檔案共用見證。

在 DC1 上，建立檔案共用並指派叢集名稱物件 (CNO) 對該資料夾的讀寫權限。在您建立的資料夾的「共用」和「安全性」標籤上新增 CNO 的權限，在下面的範例中，我建立了一個名為「見證」的資料夾。

建立資料夾並向 CNO 指派適當的權限後，請在 SQL1 或 SQL2 上執行下列 PowerShell 命令。

設定 ClusterQuorum -Cluster cluster1 -FileShareWitness \\dc1\Witness

當您在 SQL1 或 SQL2 上啟動故障轉移群集管理器時，您的群集現在應如下所示。

建立 SQL Server FCI

安裝DataKeeper集群版

在繼續執行後續步驟之前，您需要在 SQL1 和 SQL2 上安裝 DataKeeper Cluster Edition。下載安裝執行檔並在兩個節點上執行 DataKeeper 安裝程式。請參閱SIOS文檔有關安裝的具體指導。

建立 DataKeeper 卷資源

在任一叢集節點上啟動 DataKeeper UI 並建立 DataKeeper 磁碟區資源，如下所示。

連接到兩台伺服器，首先是 SQL1，然後是 SQL2

如果您已連接到兩台伺服器且儲存配置正確，則伺服器概述報告應如下所示。

按一下建立作業以啟動作業建立精靈

DataKeeper 支援同步和非同步複製。對於同一區域內的可用區之間的複製，請選擇同步。如果您想跨區域甚至跨雲端提供者複製，請選擇非同步

這裡點選“是”，將DataKeeper Volume資源註冊到叢集的Available Storage中

DataKeeper 磁碟區 D 現在顯示在故障轉移群集管理器的可用儲存中。

在 SQL1 上安裝 SQL Server FCI 的第一個節點

現在核心叢集已創建，且 DataKeeper 磁碟區資源位於可用儲存中，是時候在第一個叢集節點上安裝 SQL Server 了。如前所述，此處的範例說明了使用 SQL 2019 和 Windows 2022 的群集配置，但無論您嘗試部署哪個版本的 Windows Server 或 SQL Server，此範例中描述的所有步驟實際上都是相同的。

請依照下面的範例在 SQL1 上安裝 SQL Server

您在下方指定的名稱是客戶端存取點。這是應用程式伺服器想要連接到 SQL Server FCI 時將使用的名稱。

在此畫面上，您將新增我們先前在規劃部分中確定的 SQL1 輔助 IP 位址第1部分這個系列的。

在此範例中，我們將 tempdb 保留在 D 磁碟機上。但是，為了獲得最佳效能，建議您將 tempdb 放置在非複製磁碟區上。

在 SQL2 上安裝 SQL Server FCI 的第二個節點

現在是在 SQL2 上安裝 SQL Server 的時候了。

在兩個群集節點上安裝 SQL Server 後，故障轉移群集管理器應如下所示。

安裝 SQL Server Management Studio

在 SQL Server 版本 2016 及更高版本上，您必須以單獨的選項下載並安裝 SSMS，如下所示。注意：在 SQL Server 的早期版本中，SQL Server Management Studio (SSMS) 是您可以在 SQL 安裝期間選擇安裝的選項。

安裝 SSMS 後，透過用戶端存取點連接到叢集。您的 SQL Server FCI 應該如下所示。

多子網路注意事項

在 OCI 中執行 SQL Server FCI 的最大考慮因素之一是群集節點駐留在不同的子網路中。 Microsoft 開始透過在 Windows Server 2008 R2 中新增「OR」功能來考慮群集節點可能駐留在不同子網路中的事實，如 Microsoft文件。

取自SQL Server 多子網路叢集 (SQL Server)

文件中所述的重要內容是網路名稱資源上的 RegisterAllProvidersIP 概念，在建立 SQL Server FCI 時預設啟用該概念。如上所述，啟用此功能後，將在 DNS 中使用網路名稱資源註冊兩個 A 記錄，每個 IP 位址對應一筆記錄。

使用“OR”功能，只有與活動子網路關聯的 IP 位址才會在線，而另一個將顯示為離線。如果您的用戶端支援將 multisubnetfailover=true 新增至連接字串，則將同時嘗試兩個 IP 位址，且用戶端將自動連接到活動節點。這是最簡單的，也是多子網路叢集中客戶端重定向的預設方法。

該文件接著說，如果您的用戶端不支援 multisubnetfailover=true 功能，則您應該「嘗試將每個附加 IP 位址的用戶端連接字串中的連線逾時調整 21 秒。這可確保客戶端的重新連線嘗試在能夠循環存取多子網路 FCI 中的所有 IP 位址之前不會逾時。

停用 RegisterAllProvidersIP 是另一個可行的選項。透過停用 RegisterAllProvidersIP，您在 DNS 中將只有一筆 A 記錄。每次群集故障轉移時，DNS A 記錄都會更新為與名稱資源關聯的活動群集 IP 位址。

此方案配置的缺點是您的用戶端將快取舊 IP 位址，直到生存時間 (TTL) 到期。為了最大限度地減少重新連線的延遲，建議您變更名稱資源上的 TTL。描述了這個過程這裡下面顯示了將 TTL 設定為 5 分鐘的範例。

取得 ClusterResource -名稱 sqlcluster |設定 ClusterParameter -名稱 HostRecordTTL -值 300

請記住，對 AD 整合 DNS 伺服器的變更也可能需要一些時間才能傳播到整個林。

概括

本技術指南全面概述了在 Oracle 雲端基礎架構 (OCI) 中設定 SQL Server 2019 故障轉移叢集執行個體 (FCI)。首先強調了解 OCI 可用性 SLA 的重要性，該 SLA 根據部署策略而有所不同：跨可用性域部署為 99.99%，跨故障域部署為 99.95%，單一虛擬機部署為 99.9%。該指南強調，SLA 涵蓋虛擬機器可用性，而不是其上執行的應用程式或服務，因此需要採取額外的措施來確保應用程式可用性。

該指南詳細介紹了在 OCI 中建立虛擬雲端網路 (VCN) 和子網路的初步步驟，強調需要一個能夠容納至少三個可用性域以實現叢集目的的網路規劃。每個可用性域必須位於不同的子網路中，這項要求也適用於跨故障域的叢集。它提供了在單一 VCN 內跨不同可用性域設定三個子網路的特定配置。

此外，該指南還描述了建立網際網路閘道以及編輯預設安全性清單和路由表以促進跨可用性網域的存取和安全性的過程。它還介紹了用於 Active Directory 相容性的 DHCP 選項配置，並概述了使用 Windows Server 2022 和 SQL Server 2019 配置虛擬機器的步驟，強調了規劃伺服器名稱、IP 位址和可用區放置的重要性。

然後，該指南深入研究了新增額外磁碟區以滿足 SQL Server FCI 儲存需求，詳細介紹了建立區塊磁碟區並將其附加到執行個體的過程。它還指導如何在 OCI 中設定 Windows Server 故障轉移叢集的輔助 IP 位址。

接下來，本指南介紹了網域控制器設置，包括啟用 Active Directory 網域服務以及將伺服器升級為網域控制站。它逐步介紹了在 SQL1 和 SQL2 上準備儲存和啟用故障轉移群集功能，以及群集驗證和建立過程。

該指南進一步討論了新增檔案共用見證以維護叢集仲裁以及安裝 DataKeeper Cluster Edition 以進行磁碟區複製。它提供了在叢集節點和 SQL Server Management Studio 上安裝 SQL Server 的逐步方法，以及多子網路部署的注意事項。

總而言之，本指南提供了在OCI 中部署和配置SQL Server 2019 FCI 的詳細藍圖，涵蓋從網路設定和VM 配置到叢集、儲存配置和網域控制設定等各個方面，確保關鍵業務應用程式的正常運作時間和可靠性最大化。

在此下載逐步指南。

經許可轉載安全作業系統

選擇正確的高可用性解決方案的四個技巧

高可用性和勒布朗是有史以來最偉大的 (GOAT) 爭論

我在黑桃牌上輸了。我在卡胡特輸了。我在一場籃球比賽中輸給了同一個友好的競爭對手布蘭登。因此，為了分散他的注意力，我又開始辯論——“勒布朗是有史以來最偉大的！”接下來的緊張氣氛充滿了來回的咆哮，其中夾雜著一些籃球巨星的名字：邁克爾喬丹、朱利葉斯歐文、威爾特張伯倫、鮑勃庫西、沙克、比爾拉塞爾、傑裡·韋斯特、史蒂芬·庫裡、凱文·杜蘭特、科比·布萊恩、魔術師和值得，以及勒布朗。他爭辯說：“你怎麼能說勒布朗是最偉大的，科比有殺手本能！”我們的口頭爭論將擴大到有什麼要求，是什麼讓某人成為偉大對話的一部分，甚至是討論的一部分的候選人。他們是否需要長壽、得分記錄、防守能力、其他榮譽和榮譽？他們至少應該獲得多少個最有價值球員獎？他們時代的超越又如何呢？怎麼樣這個或那個，當然，我的朋友布蘭登總是很快就會添加標題！

如何選擇最佳的高可用性解決方案

但是，這有什麼關係高可用性？很高興你問了。您多久被要求從眾多競爭者中提供或選擇最佳可用性或更高可用性的解決方案？您已經確定，因意外應用程式崩潰或生產伺服器停機而毀掉的最後一個週末，也是因缺乏自動監控和復原而毀掉的最後一個週末。但是，在 Microsoft 故障轉移叢集、SuSE High Availability Extensions、PaceMaker、NEC ClusterPro、vWare HA、SIOS Protection Suite 和 SIOS AppKeeper 等眾多知名解決方案中，哪種解決方案最好？我在與史上最偉大的比賽中學到的四件事將幫助您解決高可用性的困境。

醫管局的要求

首先，有什麼要求？如果我想要有史以來最好的純射手，我會很容易地把史蒂芬·庫裡包括在內。如果我想要最令人生畏的身體存在，我會和沙克這樣的人一起去。如果我需要最好的隊友、助攻王或全能的優秀球員，那麼我認為勒布朗·詹姆斯、魔術師約翰遜、傑裡·韋斯特、拉里·伯德都在討論之中。同樣，在開始建立 HA 解決方案之前，請先了解您的需求。是資料複製必需的還是可選的？你需要SQL或者您同樣傾向於使用其他資料庫？還需要哪些應用程式和軟體包？您是否需要一個可以引導您進入雲端的解決方案，但首先它必須馴服遺留系統、vmWare 和實體系統？您是一家全 Windows 應用程式商店，還是兩者的混合體？也試著想想你的團隊。您的人員流動率是否很高，導致管理多個解決方案變得困難，培訓課程是否必不可少，以及現實生活中的人們在支持批判的？您需要易用性還是只注重堅固性？產品、產品和公司的壽命和穩定性在哪裡？

其次，你如何確定你的需求的優先順序？您將如何根據既定要求優先考慮優秀者？我的朋友布蘭登總是很快就給出標題。他總是反駁，詹皇有幾個冠軍？在他的辯論中，頭銜才是王道。我通常會諷刺地反駁說，即使是替補席上的第 12 個人也能獲得戒指。我要強調的是，羅伯特·霍里是一位出色的大前鋒，他擁有的頭銜比詹皇和喬丹還要多。就需求的優先順序進行坦率和誠實的對話。當您選擇 HA 解決方案時，與 RTO/RPO 相比，易用性、作業系統支援和應用程式支援範圍有多重要？哪些功能和要求被認為是必須具備的、應該具備的、最好擁有的。身為客戶體驗副總裁，我們曾經遇到一位客戶，他堅持集群軟體支援32個節點，儘管他們並沒有計劃建造超過2個或3個節點的集群。確定清單的優先順序。

測量災難復原的 RPO 和 RTO

第三，您如何衡量這些要求？您將如何根據既定要求來衡量偉大人物？籃球統計數據很有趣、資訊豐富，但常常具有誤導性。布蘭登經常提醒我檢查得分冠軍是如何贏得的，就像我教贏得了多少冠軍一樣。我們經常對誰能更好地開始或結束比賽以及如何真正衡量動力、強度和獲勝意願進行諷刺。同樣，當您梳理文獻時，請仔細研究概念驗證細節，確定並定義如何衡量 RPO 和 RTO 等內容。 RTO 是基於客戶端重新連線時間還是應用程式重新啟動時間？您是否正在測量 RTO故障轉移（伺服器崩潰）恢復（應用程式崩潰）、手動切換（管理操作），或以上全部？如果應用程式效能對您很重要，那麼該衡量標準是什麼樣的？是讀取效能、寫入效能還是基於客戶端的實際或特徵工作負載？想想基準適合什麼地方，或適合嗎？另外，請誠實地說明您將數字與什麼進行比較。在正常操作和復原期間測量更快的資料庫查詢時間很重要，但如果解決方案的其餘部分產生了使用者體驗更高的延遲怎麼辦？

評估高可用性和災難復原

最後，繼續評價。從朱利葉斯在底線搖晃嬰兒入睡，到喬丹從罰球線起跳，再到史蒂芬庫裡在半場線內邁出一步，籃球比賽一直在演變。 「喬丹規則」和「壞小子時代」的狂妄已經被一套有利於並強調技巧、力量和技巧結合的規則所取代。同樣，技術格局也在不斷變化。當 Solaris 和 MP-RAS 伺服器佔據主導地位時，進入前十名的解決方案可能無法適應 Linux、Windows 或其他變體的靈活性。利用光纖通道功能的基於 SAN 的解決方案可能已過時雲端和無SAN世界。所以，不斷評估偉大。持續關注前十名的解決方案如何順應趨勢，或者更好的是，仍然在製造它們。

雖然我與 Brandon 的爭論仍在繼續，而且很可能在幾代人之後，甚至我們的孩子也不會選出贏家，但您可以選擇正確的 HA 解決方案來滿足您的企業可用性需求。聯絡 SIOS 代表協助您了解、確定優先順序並衡量 SIOS 保護套件超出您要求的能力。

經許可轉載安全作業系統

災難復原解決方案：如何處理“建議”與“要求”

假設您遇到問題雲端叢集環境，並且您必須聯絡您的應用程式供應商之一才能解決該問題。他們為您提供了解決方案，但他們在回覆中指出，「不建議」配置這些系統的方式。您如何處理這些資訊？畢竟，到目前為止，一切都運作良好，並且可能需要大量時間和資源才能以「推薦」方式重新配置它們。另一方面，供應商推薦它肯定是有原因的，對吧？如果它會導致其他併發症怎麼辦？讓我們來看看建議的具體構成，以及從接受的任何一方處理建議的方法。

容災方案推薦配置

您應該開始考慮如何處理建議，從字面上理解它，定義為「關於最佳行動方案的建議或提議」。我們已經可以在這裡看到一些提示，說明我們如何使用“建議”和“提案”一詞來識別它們。從這個角度來看，很容易拒絕供應商的推薦，因為它不方便，或者可能被認為是不必要的。

然而，在對建議採取任何行動之前，請確保更務實地審視它。畢竟，供應商建議這種特殊的配置是有原因的。他們對你的成功就像你對持續關係的一部分一樣感興趣，所以它肯定會帶來某種積極的好處。如果沒有建議的配置，您可能更容易出現某些類型的錯誤。這也可能是性能下降的情況，一切正常，但可能會工作得更好或更快。考慮到這一點，現在投入時間和精力來滿足這些建議，而不是在您受到不遵循建議的缺點的影響後才開始這樣做，不是更好嗎？

如何處理建議之外的災難復原解決方案配置

現在，我們可以透過匯集討論的兩端來建構我們對建議的全面看法。總結的版本是：「不遵循供應商的建議也沒關係，只要您知道為什麼建議這樣做並接受這樣做的潛在缺點」。關鍵的第一步始終是與供應商交談。向他們詢問為什麼推薦它、擁有它與不擁有它的影響、他們是否有任何方法或程序可以輕鬆過渡到推薦的環境，以及您能想到的任何其他可以幫助您更好地了解自己和內部團隊的資訊.一旦您了解了影響，如果您有適當的理由，您就可以拒絕它。拒絕建議的一個很好的理由是出於安全目的。也許推薦的環境會關閉或規避您已採取的某些安全措施，因此使用該環境不僅會讓您更容易受到攻擊，而且還可能導致違反SLA、合作夥伴協議或您必須遵守的標準。在這種情況下，您可以告知供應商您不遵循建議配置的原因。這對供應商也非常有利，因為他們可以接受此回饋，並在未來實施改進，從而同時實現建議的配置和安全措施。如前所述，他們也為您的成功進行了投資，因此這對每個人來說都是雙贏。

災難復原解決方案要求

但有時，對供應商告訴您的內容說「不」並不那麼容易。這就是從供應商「建議」到供應商「要求」的跨越邊界，這是不可避免的。當它作為一項要求呈現給您時，您就無法拒絕遵循它。儘管如此，與建議一樣，重要的是要了解為什麼它是一項要求，以及它實際上是什麼要求。作為您與供應商商定的 SLA 或產品、應用程式或服務的 TSA 的一部分，可能需要某些實踐。在這些情況下，確實必須做出滿足此要求所需的變更。需求通常也屬於技術方面。例如，磁碟大小、I/O 容量或可用電腦資源的規範，僅舉幾例。這些往往是應用程式按預期工作所必需的，因此確保滿足這些要求的價值是顯而易見的。

災難復原解決方案的靈活性

僅僅因為您必須遵守要求並不意味著您必須簡單地辭職。理解為什麼要製定這項要求仍然具有很大的價值。與推薦一樣，與您的供應商交談至關重要。也許您不喜歡該要求的原因源於誤解，與您的供應商討論原因可以揭示這一點並消除一些擔憂。同樣，您對這些要求的回饋對於您的供應商改進產品或服務非常重要，並幫助他們了解您所看到的以不同方式做某事的價值。所需要的只是啟動一個對話框。

SIOS 高可用性和災難復原

SIOS科技公司提供高可用性和災難復原透過針對最重要應用程式的叢集管理來保護和最佳化 IT 基礎架構的產品。今天聯繫我們有關我們的服務和專業支援的更多資訊。

經許可轉載安全作業系統

在 Linux 上使用 SIOS LifeKeeper 設定 NFS 檔案見證的逐步指南

SIOS Lifekeeper 和基於 NFS 的文件見證入門

在高可用集群，見證人對於保證集群的完整性和可靠性起著至關重要的作用。沒有第三個節點，可能很難達到法定人數，因為沒有數據可以幫助打破兩個節點都認為應該上線的平局（這稱為裂腦）。您可以透過多種方式解決此問題，例如，透過提供專用見證伺服器、整個叢集可見的共用儲存路徑，或簡單地透過在叢集本身中擁有更多節點（至少 3 個！）。值得慶幸的是，SIOS 生命守護者為在 Linux 環境中設定高可用性叢集提供了強大的解決方案，並且配置見證以提高仲裁是一項重要功能。

在本指南中，我們將引導您完成在 Linux 上使用 SIOS LifeKeeper 設定基於 NFS 的檔案見證的步驟，幫助您增強叢集應用程式的可用性和彈性。

目標：

使用基於 NFS 的儲存見證實現 2 節點集群，如下圖所示：

先決條件：開始之前，請確保您具備以下條件：

• Linux 伺服器是使用管理權限（即根存取權限）進行設定和連接的。
• SIOS LifeKeeper 已安裝或下載並準備安裝在每台伺服器上。
• NFS 共用可供叢集中的所有伺服器存取。

步驟 1：安裝/修改 SIOS LifeKeeper：

我們需要在此階段安裝 LifeKeeper 或重新執行安裝程式以新增 Witness 功能，除非您之前已包含它。

就我而言，我使用的是 RHEL8.8，因此我將在使用 RHEL8.8 所需的補充包運行安裝之前安裝 ISO。

[root@server1-LK ~]# mount /root/sps.img /mnt/loop -t iso9660 -o 循環

[root@server1-LK ~]# cd /mnt/loop/

[root@server1-LK 循環]# ./setup –addHADR /root/HADR-RHAS-4.18.0-477.10.1.el8_8.x86_64.rpm

這裡，我們目的的重要部分是啟用見證功能，如下面的螢幕截圖所示。但是，您還需要一個額外的許可證文件，您可以在此處添加該文件，也可以稍後透過命令列新增：

否則，根據您的目的配置 LifeKeeper，或者如果已經配置，只需在包含「使用仲裁/見證功能」選項後繼續完成設定即可。

如果您決定透過命令列新增許可證，請在叢集中的每個節點上執行以下命令，並使用許可證檔案的正確路徑：

[root@server1-LK ~]# /opt/LifeKeeper/bin/lkkeyins /<許可證文件路徑>l/quorum-disk.lic

步驟 2：設定並掛載共用儲存：

確保叢集中的所有伺服器都可以存取共用儲存。您可以使用“mount”命令或“findmnt”檢查每個伺服器，以驗證是否已在本機安裝：

[root@server1-LK 循環]# mount | grep NFS

/var/lib/nfs/rpc_pipefs 上的 sunrpc 類型 rpc_pipefs (rw,relatime)

172.16.200.254:/var/nfs/general on /nfs/general 類型 nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,
proto=tcp=timesproto 2、sec=sys、clientaddr=172.16.205.151、local_lock=none、addr=172.16.200.254)

或者

[root@server1-LK ~]# findmnt -l /nfs/general

目標來源 FSTYPE 選項

/nfs/general 172.16.200.254:/var/nfs/general nfs4 rw,relatime,vers=4.2,rsize=1048576,
wsize=1048576,namlen=255,hard,proto=tcp,wsize=1048576,namlen=255,hard,
proto=tcp,sectimeo=600, =sys，clientaddr=172.16.205.151，local_lock=無，addr=172.16.200.254

如果您仍需要自行掛載共享，請依照以下步驟操作：

首先，確認您可以在主機伺服器上看到 NFS 共用。

[root@server1-LK ~]# showmount -e 172.16.200.254

172.16.200.254 的導出清單：

/首頁172.16.205.244,172.16.205.151

/var/nfs/一般 172.16.205.244,172.16.205.151

就我而言，我想掛載“/var/nfs/general”共享。

要掛載此共享，首先請確保您計劃掛載的目錄存在。如果沒有，請創建它：

[root@server1-LK ~]# mkdir -p /nfs/general

現在，您可以使用以下命令手動掛載共享以確認可以連接，並且它可以工作：

[root@server1-LK ~]# mount 172.16.200.254:/var/nfs/general /nfs/general

最後，一旦滿意，將掛載點添加到您的 /etc/fstab 檔案中，以便它將在啟動時掛載：

[root@server1-LK ~]# cat /etc/fstab

#

# /etc/fstab

# 由 anaconda 創建於 2024 年 1 月 25 日星期四 12:07:15

#

# 透過引用，可存取的檔案系統維護在「/dev/disk/」下。

# 有關更多信息，請參閱手冊頁 fstab(5)、findfs(8)、mount(8) 和/或 blkid(8)。

#

# 編輯此檔案後，執行 ‘systemctl daemon-reload’ 來更新 systemd

從該檔案產生的 # 個單位。

#

/dev/mapper/rhel-root/xfs 預設 0 0

UUID=6b22cebf-8f1c-405b-8fa8-8f12e1b6b56c /boot xfs 預設 0 0

/dev/mapper/rhel-swap 無 交換預設值 0 0

#為 NFS 共享添加

172.16.200.254:/var/nfs/general /nfs/general nfs4 預設 0 0

現在，您可以使用 mount 命令確認它已安裝：

[root@server1-LK ~]# mount -l | grep NFS

/var/lib/nfs/rpc_pipefs 上的 sunrpc 類型 rpc_pipefs (rw,relatime)

172.16.200.254:/var/nfs/general on /nfs/general 類型 nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
hard,proto=tcp=timesproto 2、sec=sys、clientaddr=172.16.205.151、local_lock=none、addr=172.16.200.254)

從上面突出顯示的文字可以看到，現在已經成功安裝了。在所有伺服器上重複此操作，直到確定所有伺服器都已安裝共享，然後再繼續。

步驟 4：檢查您的主機名稱並配置 /etc/default/LifeKeeper 設定：

您可以透過在每個節點上執行以下命令來查看 LifeKeeper 所知道的每個伺服器的主機名稱：

/opt/LifeKeeper/bin/lcduname

您需要新增到 /etc/default/LifeKeeper 檔案的設定範例：

WITNESS_MODE=存儲

QWK_STORAGE_TYPE=文件

QWK_STORAGE_HBEATTIME=6

QWK_STORAGE_NUMHBEATS=9

QWK_STORAGE_OBJECT_server1_LK_localdomain=/nfs/general/nodeA

QWK_STORAGE_OBJECT_server2_LK_localdomain=/nfs/general/nodeB

對於“QWK_STORAGE_OBJECT_<server-name>”，您需要為每個節點聲明它，它是使用您的主機名稱、路徑以及見證文件本身的所需位置形成的。

需要注意的是，如果主機名稱包含“-”或“.”，請將其替換為底線“_”（例如 lksios-1 → lksios_1 或 lksios-1.localdomain → lksios_1_localdomain ）。

在我的範例中，我有以下主機名稱：

server1-LK.localdomain

server2-LK.localdomain

這意味著添加以下“QWK_STORAGE_OBJECT_”定義：

QWK_STORAGE_OBJECT_server1_LK_localdomain=/nfs/general/nodeA

QWK_STORAGE_OBJECT_server2_LK_localdomain=/nfs/general/nodeB

此外，我們需要調整 /etc/default/LifeKeeper 中的現有設定之一：

QUORUM_MODE=存儲

為了幫助理解為什麼我們將 WITNESS_MODE 和 QUORUM_MODE 設定為存儲，請查看下表：

支持仲裁模式和見證模式的組合

LifeKeeper 支援以下組合。

我們有一個雙節點集群，想要使用外部存儲來進行仲裁，因此唯一支援的組合是兩個值的「存儲」。但是，您可以從表中看到，當您需要更多節點時，這可以非常靈活，提供多種方式來實現通訊並提供法定人數。

第四步：初始化見證檔：

若要初始化見證檔案並啟用其使用，您必須在每個節點上執行以下命令：

[root@server1-LK ~]# /opt/LifeKeeper/bin/qwk_storage_init

運行時它將暫停，直到每個節點完成，因此在叢集中的第一個節點上執行命令，然後在第二個節點上執行命令，依此類推，然後返回檢查命令是否完成且沒有錯誤。

例子：

[root@server1-LK ~]# /opt/LifeKeeper/bin/qwk_storage_init

好的：LifeKeeper 正在運行。

ok：LifeKeeper 許可證金鑰已成功安裝。

ok：QWK 參數有效。

/nfs/general/nodeA 的 QWK 物件尚不可用。

/nfs/general/nodeA 已存在，但不存在 QWK_STORAGE_OBJECT：覆蓋？ （是/否）：是

ok：QWK物件的路徑有效。

好的：下：/opt/LifeKeeper/etc/service/qwk-storage：1377s

ok：本節點QWK物件初始化完成。

/nfs/general/nodeB 的 QWK 物件尚不可用。

/nfs/general/nodeB 的 QWK 物件尚不可用。

/nfs/general/nodeB 的 QWK 物件尚不可用。

/nfs/general/nodeB 的 QWK 物件尚不可用。

/nfs/general/nodeB 的 QWK 物件尚不可用。

/nfs/general/nodeB 的 QWK 物件尚不可用。

/nfs/general/nodeB 的 QWK 物件尚不可用。

ok：仲裁系統已準備就緒。

ok: 運行: /opt/LifeKeeper/etc/service/qwk-storage: (pid 14705) 1s, 正常down

成功的。

第 5 步：驗證配置：

可以透過執行以下命令來驗證配置：

/opt/LifeKeeper/bin/lktest

如果發現任何錯誤，它們將被列印到終端上。在下面的範例中，我沒有替換主機名稱中的特殊字符，因此它突出顯示無法找到儲存。

[root@server1-LK ~]# /opt/LifeKeeper/bin/lktest

/opt/LifeKeeper/bin/lktest: /etc/default/LifeKeeper[308]: QWK_STORAGE_OBJECT_server1_LK.localdomain=/nfs/general/nodeA: 找不到

/opt/LifeKeeper/bin/lktest: /etc/default/LifeKeeper[309]: QWK_STORAGE_OBJECT_server2_LK.localdomain=/nfs/general/nodeB: 找不到

FS UID PID PPID C CLS PRI NI SZ STIME TIME CMD

4 S 根 2348 873 0 TS 39 -20 7656 15:49 00:00:00 lcm

4 S 根 2388 882 0 TS 39 -20 59959 15:49 00:00:00 ttymonlcm

4 S 根 2392 872 0 TS 29 -10 10330 15:49 00:00:00 液晶

4 S 根 8591 8476 0 TS 19 0 7670 15:58 00:00:00 lcdremexec -d server2-LK.localdomain -e — cat /proc/mdstat

您也可以透過命令列確認見證文件正在更新，如下所示：

[root@server1-LK ~]# cat /nfs/general/nodeA

簽名=lifekeeper_qwk_object

local_node=server1-LK.localdomain

時間=2024年2月15日星期四14:10:56

序列=157

節點=server2-LK.localdomain

通訊狀態=UP

校驗和=13903688106811808601

使用 NFS 的成功文件共享見證

使用 NFS 設定檔共享見證非常簡單！如果您僅限於兩個節點，但需要更好地應對腦裂事件，那麼它可能會很強大，特別是在雲中，您可以利用AWS 的EFS 之類的東西……另一個重要部分可以是利用更多的通訊路徑，但這是一個不同的部落格。但是，透過遵循本指南中概述的步驟，您可以增強叢集應用程式的彈性並最大限度地降低停機風險。請始終參考SIOS文檔以及進一步指導和優化高可用性設定的最佳實踐。它是公開的並且非常全面！

SIOS 高可用性和災難復原

SIOS科技公司提供高可用性和災難復原透過針對最重要應用程式的叢集管理來保護和最佳化 IT 基礎架構的產品。今天聯繫我們有關我們的服務和專業支援的更多資訊。

經許可轉載安全作業系統