| 24 4 月, 2024 |
SIOS 技術加入 Nutanix Elevate 合作夥伴計劃 |
||||||||||||||||||||||||||||
| 22 4 月, 2024 |
逐步操作 – OCI 中的 SQL Server 2019 故障轉移群集實例 (FCI) |
||||||||||||||||||||||||||||
| 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 檔案見證的逐步指南
在 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 支援以下組合。
| 法定模式 | |||||
| 多數 | tcp_遠端 | 貯存 | 無/關 | ||
| 見證模式 | 遠端驗證 | 支援3個或更多節點 | 支援3個或更多節點 | 不支援 | 支援3個或更多節點 |
| 貯存 | 不支援 | 不支援 | 支援2到4個節點之間 | 不支援 | |
| 無/關 | 支援3個或更多節點 | 支援2個或更多節點 | 不支援 | 支持的 | |
我們有一個雙節點集群，想要使用外部存儲來進行仲裁，因此唯一支援的組合是兩個值的「存儲」。但是，您可以從表中看到，當您需要更多節點時，這可以非常靈活，提供多種方式來實現通訊並提供法定人數。
第四步：初始化見證檔：
若要初始化見證檔案並啟用其使用，您必須在每個節點上執行以下命令：
[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 基礎架構的產品。今天聯繫我們有關我們的服務和專業支援的更多資訊。
經許可轉載安全作業系統