SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Archives for 9 月 2021

華為雲SQL Server故障轉移集群實例部署

by Leave a Comment

華為雲高可用ECS IaaS

*免責聲明：雖然以下內容完全涵蓋了我們產品範圍內的高可用性部分，但這只是一個設置“指南”，應根據您自己的配置進行調整。

概述華為雲是一家領先的雲服務提供商，不僅在中國，而且在全球擁有許多數據中心。 他們匯集了華為在ICT基礎設施產品和解決方案方面30多年的專業知識，致力於提供可靠、安全、高性價比的雲服務，為應用賦能、駕馭數據的力量，幫助各種規模的組織在當今時代發展。智能世界。 華為雲還致力於通過技術創新，帶來實惠、有效、可靠的雲和人工智能服務。

DataKeeper 集群版為華為雲提供跨可用區的單個區域內的虛擬私有云（VPC）複製。 在這個特定的 SQL Server 群集示例中，我們將在三個可用區中啟動四個實例（一個域控制器實例、兩個 SQL Server 實例和一個仲裁/見證實例）。

華為雲SIOS Datakeeper HA架構

DataKeeper集群版支持集群外的數據複製節點，所有節點都在華為雲中。 在這個特定的 SQL Server 群集示例中，在三個可用區中啟動了四個實例（一個域控制器實例、兩個 SQL Server 實例和一個仲裁/見證實例）。 然後在第二個區域中啟動一個額外的 DataKeeper 實例，包括兩個區域中的 VPN 實例。 請參見配置從集群節點到外部容災站點的數據複製想要查詢更多的信息。 有關使用多個區域的其他信息，請參閱連接不同地域的兩個VPC .

華為雲SIOS Datakeeper 容災架構

DataKeeper集群版還支持集群外的數據複製節點，只有集群外的節點在華為雲中。 在這個特定的 SQL Server 集群示例中，WSFC1 和 WSFC2 位於復製到華為雲實例的現場集群中。 然後在華為雲的某個區域中啟動一個額外的 DataKeeper 實例。 請參見配置從集群節點到外部容災站點的數據複製想要查詢更多的信息。

華為雲SIOS Datakeeper混合容災架構

要求

描述 要求
虛擬私有云 在具有三個可用區的單個區域中
實例類型 最小推薦實例類型：s3.large.2
操作系統 請參閱 DKCE 支持矩陣
彈性IP 一個彈性IP地址連接到域控制器
四個實例 一個域控制器實例、兩個 SQL Server 實例和一個仲裁/見證實例
每個 SQL 服務器 ENI（彈性網絡接口）有 4 個 IP · 在 Windows 中靜態定義並由 DataKeeper 集群版使用的主 ENI IP · 三個 IP 由 ECS 維護，同時由 Windows 故障轉移集群、DTC 和 SQLFC 使用
卷 三個卷（僅限 EBS 和 NTFS） · 一個主卷（C 驅動器） · 兩個附加卷 o 一個用於故障轉移群集 o 一個用於 MSDTC

發行說明在開始之前，請確保您閱讀了DataKeeper 集群版發行說明了解最新信息。 強烈建議您閱讀並理解DataKeeper 集群版安裝指南.

創建虛擬私有云 (VPC)虛擬私有云是您在使用 DataKeeper Cluster Edition 時創建的第一個對象。

*虛擬私有云 (VPC) 是一種隔離的私有云，由公共雲中可配置的共享計算資源池組成。

  1. 使用註冊時指定的電子郵件地址和密碼華為雲, 登錄華為雲管理控制台.
  2. 來自服務下拉，選擇虛擬私有云.

  1. 在屏幕右側，單擊創建專有網絡並選擇您要使用的區域。
  2. 輸入要用於 VPC 的名稱
  3. 通過輸入您的虛擬私有云子網來定義您的虛擬私有云子網CIDR（無類別域間路由）如下所述
  4. 輸入子網名稱，然後單擊立即創建.

*路由表將自動創建，並與新 VPC 具有“主要”關聯。 您可以稍後使用它或創建另一個路由表。

*有用的鏈接：華為的創建虛擬私有云 (VPC)啟動實例下面將引導您將實例啟動到您的子網中。 您需要在一個可用區中啟動兩個實例，一個用於域控制器實例，另一個用於 SQL 實例。 然後，您將在另一個可用區中啟動另一個 SQL 實例，在另一個可用區中啟動一個仲裁見證實例。

*有用的網址：華為雲ECS實例

  1. 使用註冊時指定的電子郵件地址和密碼華為雲, 登錄華為雲管理控制台.
  2. 來自服務清單下拉，選擇彈性雲服務器.

  1. 選擇購買 ECS按鈕並選擇計費模式、區域和可用區（可用區）來部署實例
  2. 選擇您的實例類型。 (筆記：選擇 s3.large.2 或更大。）。
  3. 選擇一個圖像。 在公共圖像下，選擇Windows Server 2019 數據中心 64 位英文版圖片
    1. 為了配置網絡，選擇您的 VPC。
    2. 為了子網，選擇要使用的子網，選擇手動指定的 IP 地址並輸入您要使用的 IP 地址
    3. 選擇安全組使用或編輯並選擇一個現有的。
    4. 分配 EIP如果需要ECS實例上網
    5. 點擊配置高級設置並為 ECS 提供一個名稱，使用密碼為了登錄方式並提供管理員登錄的安全密碼
    6. 點擊立即配置在高級選項添加一個標籤命名您的實例並單擊確認
  4. 對實例進行最終審查並單擊提交.

*重要的：記下此初始管理員密碼。 需要登錄到您的實例。

對所有實例重複上述步驟。

連接到實例您可以通過以下方式連接到域控制器實例遠程登錄從 ECS 窗格。

以管理員身份登錄並輸入您的管理員密碼.

*最佳實踐：登錄後，最好更改密碼。

配置域控制器實例現在已經創建了實例，我們開始設置域服務實例。

本指南不是關於如何設置 Active Domain 服務器實例的教程。 我們建議閱讀文章關於如何設置和配置 Active Directory 服務器。 了解即使實例在華為雲中運行，這也是 Active Directory 的常規安裝，了解這一點非常重要。

靜態 IP 地址為您的實例配置靜態 IP 地址

  1. 連接到您的域控制器實例。
  2. 點擊開始/控制面板.
  3. 點擊網絡和共享中心.
  4. 選擇您的網絡接口。
  5. 點擊特性.
  6. 點擊Internet 協議版本 4 (TCP/IPv4) ， 然後特性.
  7. 獲取您當前的IPv4地址,默認網關和DNS服務器對於網絡接口從亞馬遜.
  8. 在裡面Internet 協議版本 4 (TCP/IPv4) 屬性對話框，在使用以下 IP 地址， 輸入您的IPv4地址.
  9. 在裡面子網掩碼框中，鍵入與您的虛擬私有云子網關聯的子網掩碼。
  10. 在裡面默認網關框中，鍵入IP地址的默認網關，然後單擊好的.
  11. 為了首選 DNS 服務器， 輸入您的域控制器的主 IP 地址（例如 15.0.1.72）。
  12. 點擊好的，然後選擇關閉. 出口網絡和共享中心.
  13. 在其他實例上重複上述步驟。

將兩個 SQL 實例和見證實例加入域*在嘗試加入域之前進行這些網絡調整。 在您的網絡適配器上，將首選 DNS 服務器添加/更改為新的域控制器地址及其 DNS 服務器。 在此更改後使用 ipconfig /flushdns 刷新 DNS 搜索列表。 在嘗試加入域之前執行此操作。

*確保這件事核心網絡和文件和打印機共享Windows 防火牆中允許選項。

  1. 在每個實例上，單擊開始，然後右鍵單擊計算機並選擇特性.
  2. 在最右邊，選擇更改設置.
  3. 點擊改變.
  4. 輸入一個新的計算機名稱.
  5. 選擇領域.
  6. 進入域名–（例如 docs.huawei.com）。
  7. 點擊申請.

*用控制面板確保所有實例都使用您所在位置的正確時區。

*最佳實踐：建議將系統頁面文件設置為系統管理（非自動）並始終使用 C: 驅動器。

控制面板 > 高級系統設置 > 性能 > 設置 > 高級 > 虛擬內存。 選擇系統管理大小,卷 C：只有，然後選擇放保存。

為兩個 SQL 實例分配輔助私有 IP除了主 IP，您還需要向每個 SQL 實例的彈性網絡接口添加三個額外的 IP（輔助 IP）。

  1. 來自服務清單下拉，選擇彈性雲服務器.
  2. 單擊要為其添加輔助私有 IP 地址的實例。
  3. 選擇NIC > 管理虛擬 IP 地址.
  4. 點擊分配虛擬 IP 地址並選擇手動的輸入實例子網範圍內的 IP 地址（例如。 對於 15.0.1.25，輸入 15.0.1.26）。 點擊好的.
  5. 點擊更多的IP 地址行上的下拉菜單，然後選擇綁定到服務器，選擇要綁定IP地址的服務器和網卡。
  6. 點擊好的以保存您的工作。
  7. 執行上述兩個 SQL 實例.

*有用的網址：管理虛擬 IP 地址綁定虛擬IP地址到彈性公網IP或彈性雲服務器創建和附加卷DataKeeper 是一個塊級卷複製解決方案，它要求集群中的每個節點都具有相同大小和相同驅動器號的附加卷（系統驅動器除外）。 請查閱體積注意事項有關存儲要求的其他信息。

創建卷在每個可用區為每個 SQL Server 實例創建兩個卷，總共四個卷。

  1. 來自服務清單下拉，選擇彈性雲服務器.
  2. 單擊您要管理的實例
  3. 前往磁盤標籤
  4. 點擊添加磁盤要添加您選擇和大小的新卷，請確保選擇與您打算將其附加到的 SQL 服務器相同的可用區中的捲
  5. 選中復選框以同意 SLA 並提交
  6. 點擊返回服務器控制台
  7. 附如果需要，磁盤到 SQL 實例
  8. 對所有四個卷執行此操作。

*有用的網址：彈性卷服務配置集群在安裝 DataKeeper Cluster Edition 之前，重要的是將 Windows Server 配置為使用節點多數仲裁（如果有奇數個節點）或節點和文件共享多數仲裁（如果有偶數個節點）。 除本主題外，請參閱 Microsoft 群集相關文檔以獲取分步說明。筆記：微軟發布了一個修補程序對於 Windows 2008R2，它允許禁用節點投票，這可能有助於在某些多站點群集配置中實現更高級別的可用性。

添加故障轉移群集將故障轉移群集功能添加到兩個 SQL 實例。

  1. 發射服務器管理器.
  2. 選擇特徵在左窗格中，然後單擊添加功能在裡面特徵這開始添加功能嚮導.
  3. 選擇故障轉移集群.
  4. 選擇安裝.

驗證配置

  1. 打開故障轉移集群管理器.
  2. 選擇故障轉移群集管理器，選擇驗證配置.
  3. 點擊下一個，然後添加你的兩個SQL實例.

筆記：要搜索，請選擇瀏覽，然後點擊先進的和立即查找. 這將列出可用實例。

  1. 點擊下一個.
  2. 選擇僅運行我選擇的測試然後點擊下一個.
  3. 在裡面測試選擇屏幕，取消選擇貯存然後點擊下一個.
  4. 在出現的確認屏幕上，單擊下一個.
  5. 審查驗證總結報告然後點擊結束.

創建集群

  1. 在故障轉移集群管理器， 點擊創建集群然後點擊下一個.
  2. 輸入你的兩個SQL實例.
  3. 在驗證警告頁面，選擇不然後點擊下一個.
  4. 在用於管理集群的接入點頁面，為您的 WSFC 集群輸入一個唯一的名稱。 然後輸入故障轉移群集 IP 地址對於集群中涉及的每個節點。 這是三個中的第一個次要 IP 地址之前添加到每個實例。
  5. 重要提示！取消選中“將所有可用存儲添加到集群”複選框。 DataKeeper 鏡像驅動器不能由集群本地管理。 它們將作為 DataKeeper 捲進行管理。
  6. 點擊下一個在確認
  7. 在概括頁面，查看所有警告，然後選擇結束.

配置仲裁/見證

  1. 在您的仲裁/見證實例（見證）上創建一個文件夾。
  2. 共享文件夾。
    1. 右鍵單擊文件夾並選擇分享給/特定的人……
    2. 從下拉菜單中選擇每個人然後點擊添加.
    3. 在下面權限級別， 選擇讀/寫.
    4. 點擊分享， 然後完畢. （記下要在下面使用的此文件共享的路徑。）
  3. 在故障轉移集群管理器, 右鍵單擊集群並選擇更多操作和配置集群仲裁設置. 點擊下一個.
  4. 在選擇仲裁配置， 選擇節點和文件共享多數然後點擊下一個.
  5. 在配置文件共享見證屏幕，輸入之前創建的文件共享的路徑，然後單擊下一個.
  6. 在確認頁面，點擊下一個.
  7. 在概括頁面，點擊結束.

安裝和配置 DataKeeper在配置基本集群之後但在創建任何集群資源之前，安裝和許可DataKeeper 集群版在所有集群節點上。 見DataKeeper 集群版安裝指南詳細說明。

  1. 跑DataKeeper 設置安裝DataKeeper 集群版在兩個 SQL 實例上。
  2. 輸入您的註冊碼並在出現提示時重新啟動。
  3. 啟動數據管理員圖形用戶界面和連接到服務器.

*筆記: 使用的域或服務器帳戶必須添加到本地系統管理員組。 該帳戶必須在安裝了 DataKeeper 的每台服務器上都具有管理員權限。 參考DataKeeper 服務登錄 ID 和密碼選擇了解更多信息。

  1. 右鍵單擊工作並連接到兩個 SQL 服務器。
  2. 創建工作對於您將創建的每個鏡像。 一個用於您的 DTC 資源，一個用於您的 SQL 資源。
  3. 當詢問您是否要將捲自動註冊為集群卷時，選擇是的.

*筆記：如果在 Windows “Core”（無 GUI 的 Windows）上安裝 DataKeeper Cluster Edition，請務必閱讀Windows 2008R2/2012服務器核心平台上安裝和使用DataKeeper詳細說明。

配置 MSDTC

  1. 對於 Windows Server 2012 和 2016，在故障轉移群集管理器 GUI ， 選擇角色，然後選擇配置角色.
  2. 選擇分佈式事務協調器 (DTC) ，然後單擊下一個.

*對於 Windows Server 2008，在故障轉移群集管理器 GUI ， 選擇服務和應用，然後選擇配置服務或應用程序然後點擊下一個.

  1. 在客戶端接入點屏幕，輸入名稱，然後輸入MSDTC IP 地址對於集群中涉及的每個節點。 這是三個中的第二個次要 IP 地址之前添加到每個實例。 點擊下一個.
  2. 選擇MSDTC 體積然後點擊下一個.
  3. 在確認頁面，點擊下一個.
  4. 一旦概括頁面顯示，點擊結束.

在第一個 SQL 實例上安裝 SQL

  1. 在域控制器服務器上創建一個文件夾並共享它..
    1. 例如具有“所有人”權限的“TEMPSHARE”。
  2. 創建一個子文件夾“SQL”並將 SQL .iso 安裝程序複製到該子文件夾中。
  3. 在 SQL 服務器上，創建一個網絡驅動器並將其附加到域控制器上的共享文件夾。
    • .例如“net use S:\TEMPSHARE
  4. 在 SQL 服務器上，將出現 S: 驅動器。 CD 到 SQL 文件夾並找到 SQL .iso 安裝程序。 右鍵單擊 .iso 文件並選擇山. setup.exe 安裝程序將與 SQL .iso 安裝程序一起出現。

F:>Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

  1. 在設置支持規則， 點擊好的.
  2. 在產品密鑰對話框，輸入您的產品密鑰然後點擊下一個.
  3. 在許可條款對話框，接受許可協議然後點擊下一個.
  4. 在產品更新對話框，點擊下一個.
  5. 在設置支持文件對話框，點擊安裝.
  6. 在設置支持規則對話框，您將收到警告。 點擊下一個，忽略此消息，因為它預計在多站點或非共享存儲集群中。
  7. 核實集群節點配置然後點擊下一個.
  8. 配置您的集群網絡通過為您的 SQL 實例添加“第三個”輔助 IP 地址，然後單擊下一個. 點擊是的繼續進行多子網配置。
  9. 進入密碼對於服務帳戶並單擊下一個.
  10. 在錯誤報告對話框，點擊下一個.
  11. 在添加節點規則對話框中，可以忽略跳過的操作警告。 點擊下一個.
  12. 驗證功能並單擊安裝.
  13. 點擊關閉以完成安裝過程。

在第二個 SQL 實例上安裝 SQL安裝第二個 SQL 實例與第一個類似。

  1. 在 SQL 服務器上，創建一個網絡驅動器並將其附加到域控制器上的共享文件夾，如上文針對第一台 SQL 服務器所述。
  2. 安裝 .iso 安裝程序後，運行SQL 設置再次從命令行以跳過證實打開一個命令窗口，瀏覽到您的SQL安裝目錄並輸入以下命令：

設置 /SkipRules=Cluster_VerifyForErrors /Action=AddNode /INSTANCENAME=”MSSQLSERVER” (筆記：這假設您在第一個節點上安裝了默認實例）

  1. 在設置支持規則， 點擊好的.
  2. 在產品密鑰對話框，輸入您的產品密鑰然後點擊下一個.
  3. 在許可條款對話框，接受許可協議然後點擊下一個.
  4. 在產品更新對話框，點擊下一個.
  5. 在設置支持文件對話框，點擊安裝.
  6. 在設置支持規則對話框，您將收到警告。 點擊下一個，忽略此消息，因為它預計在多站點或非共享存儲集群中。
  7. 核實集群節點配置然後點擊下一個.
  8. 配置您的集群網絡為您的 SQL 實例添加“第三個”輔助 IP 地址，然後單擊下一個. 點擊是的繼續進行多子網配置。
  9. 進入密碼對於服務帳戶並單擊下一個.
  10. 在錯誤報告對話框，點擊下一個.
  11. 在添加節點規則對話框中，可以忽略跳過的操作警告。 點擊下一個.
  12. 驗證功能並單擊安裝.
  13. 點擊關閉以完成安裝過程。

通用集群配置本節描述了一個常見的 2 節點複製集群配置.

  1. 初始配置必須從數據管理員用戶界面在集群節點之一上運行。 如果無法在集群節點上運行 DataKeeper UI，例如在僅 Windows Core 的服務器上運行 DataKeeper，請在任何運行 Windows XP 或更高版本的計算機上安裝 DataKeeper UI，然後按照僅核心用於通過命令行創建鏡像和註冊集群資源的部分。
  2. 一旦 DataKeeper UI 運行，連接到每個節點在集群中。
  3. 創建工作使用 DataKeeper UI。 此過程創建一個鏡像並將 DataKeeper Volume 資源添加到可用存儲。

！重要的：確保虛擬網絡名稱為了網卡連接在所有集群節點上都是相同的。

  1. 如果需要額外的鏡子，您可以向作業添加鏡像.
  2. 隨著DataKeeper 卷現在在可用存儲空間，您可以像創建集群中的共享磁盤資源一樣創建集群資源（SQL、文件服務器等）。 除上述內容外，請參閱 Microsoft 文檔以獲取有關分步群集配置說明的其他信息。

與集群（虛擬）IP 的連接除了主IP和從IP，您還需要在華為雲中配置虛擬IP地址，以便它們可以路由到主節點。

  1. 來自服務清單下拉，選擇彈性雲服務器.
  2. 單擊要為其添加群集虛擬 IP 地址的 SQL 實例之一（一個用於 MSDTC，一個用於 SQL 故障轉移群集）
  3. 選擇NIC > 管理虛擬 IP 地址.
  4. 點擊分配虛擬 IP 地址並選擇手動的輸入實例子網範圍內的 IP 地址（例如。 對於 15.0.1.25，輸入 15.0.1.26）。 點擊好的.
  5. 點擊更多的IP 地址行上的下拉菜單，然後選擇綁定到服務器, 選擇要綁定 IP 地址的服務器和 NIC 卡。
  6. 對 MSDTC 和 SQLFC 虛擬 IP 使用相同的步驟 4. 和 5
  7. 點擊好的以保存您的工作。

管理一旦 DataKeeper 卷註冊到 Windows Server 故障轉移群集，該卷的所有管理都將通過 Windows Server 故障轉移群集界面完成。 DataKeeper 中通常可用的所有管理功能將被禁用在集群控制下的任何卷上。 相反，DataKeeper Volume 集群資源將控製鏡像方向，因此當 DataKeeper Volume 在節點上聯機時，該節點將成為鏡像的源。 DataKeeper Volume 集群資源的屬性還顯示基本的鏡像信息，例如鏡像的源、目標、類型和狀態。

故障排除使用以下資源幫助解決問題：

其他資源：循序漸進：在 Windows Server 2008 R2 上配置 2 節點多站點集群——第 1 部分—— http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -第1部分/循序漸進：在 Windows Server 2008 R2 上配置 2 節點多站點集群——第 3 部分—— http://clusteringformeremortals.com/2009/10/07/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -第 3 部分/

開始很好，但保持正常運行時間需要警惕

by Leave a Comment

開始很好，但保持正常運行時間需要警惕

作者 Isabella Poretsis 說：“開始一件事情很容易，完成它才是最大的障礙。”召開啟動會議真是太好了。它令人振奮，令人興奮。 經理和領導者興奮地看著綠地，樂觀情緒高漲。但是，這個開球時刻，甚至成功部署的香檳爆破時刻都只是開始。 保持正常運行時間需要持續保持警惕。

關鍵應用程序和數據庫的高可用性和難以捉摸的 4 個 9 正常運行時間不是一時發生的，而是要不斷努力結束破壞葡萄園的小狐狸。及時了解威脅、及時了解更新以及經過適當培訓和準備是您的團隊“永遠無權休假”的工作。

對於那些希望保持正常運行時間保持警惕的人，這裡有五個提示：

1. 監控環境

企業軟件中很少有人仍然遵循“設置並忘記它”的心態。一切，從你打開盛大的開瓶香檳的那一天到現在，一直在走向衰落的狀態。如果您沒有監控服務器、工作負載、網絡流量和硬件（虛擬或物理），您可能會失去正常運行時間和穩定性。

2. 執行維護

在二十多年的軟件開發和服務中，我一直注意到的一件事是所有軟件都帶有更新。應用它們。請記住執行合理的維護策略，包括獲取和驗證備份。 一位技術作家建議您唯一後悔的更新是您未能進行的更新。

3. 不斷學習

當我剛從 CE-211 實驗室實習時，我拔掉了實驗室服務器的令牌環的一端，這是我對高可用性的第一次介紹。幾分鐘後管理員就出現在我面前。聽完之後，他給了我一個教育。理想情況下，您和您的團隊希望在不關閉網絡的情況下學習，但您絕對希望繼續學習。查看有關現有技術、新版本、新興基礎設施的付費課程。檢查您的供應商，了解與您的流程、環境、軟件部署和公司企業相關的課程和項目。如果錢是一個問題，許多事情的免費課程也存在。

4. 乘以學習

除了不斷學習之外，還要製定一個成倍增長的學習計劃。作為 SIOS 的客戶體驗副總裁，我們看到了分享學習成果的團隊與不分享學習成果的團隊之間的巨大差異。分享他們的學習經驗的團隊避免了影響停機時間的知識差距。知道你學到了什麼的最好方法是把它教給別人。 在學習過程中，與團隊成員分享學習經驗，以減少因錯誤而導致停機的風險，並因此而休假。

5. 好好收場。 . .在下一個開始之前

所有項目、服務器和軟件都有結局。好收場。正確退役。通過關閉未完成的部分、記錄哪些進展順利、哪些不順利以及接下來要做什麼來開始下一個階段、部署、軟件關係等。善待您現有的供應商。您稍後可能會再次需要它們。在進行新部署之前了解現有系統和高可用性解決方案。這個正確的結局可以幫助你從一個更好的起點重新開始，走向更強大的結果。

保持系統高可用性是一個持續的過程。設置並忘記它是一個很好的口號，但現實是正常運行時間需要保持警惕、持續監控、適當維護和持續。

– 客戶體驗副總裁 Cassius Rhue 經許可轉載SIOS

理解和避免裂腦情景

by Leave a Comment

 

 

理解和避免裂腦情景

裂腦。 我們博客的大多數讀者都聽說過這個詞，在計算環境中，也就是說，我們不得不同情那些第一個心理形像是如果有人有兩個大腦會導致的混亂同時。

什麼是故障轉移群集裂腦方案？

在故障轉移集群裂腦場景中，兩個節點都不能與另一個節點通信，備用服務器可能會提升自己成為活動服務器，因為它認為活動節點出現故障。 這導致兩個節點都變為“活動”，因為每個節點都會將另一個節點視為失敗。 因此，由於兩個節點上的數據都會發生變化，數據完整性和一致性會受到損害。 這被稱為裂腦。

如果不採取適當的步驟來避免它們，SAP HANA 資源層次結構可能會發生兩種類型的腦裂情況。

  • HANA 資源裂腦： HANA 資源在多個集群節點上處於活動狀態 (ISP)。 這種情況通常是由影響集群節點之間通信路徑的臨時網絡中斷引起的。
  • SAP HANA 系統複製裂腦： HANA 資源在主節點上為 Active (ISP)，在備份節點上為 Standby (OSU)，但數據庫正在運行並註冊為兩個節點上的主複製站點。 這種情況通常是由於在故障轉移期間無法停止先前主節點上的數據庫、為數據庫啟用了自動啟動，或者數據庫管理員在集群軟件環境之外的輔助複製站點上手動運行“hdbnsutil -sr_takeover” .

避免裂腦問題

避免或解決方案中每種類型的裂腦情景的建議SIOS 保護套件集群環境如下。

在裂腦情況下，每隔 quickCheck 時間間隔（默認為 2 分鐘），就會記錄一條類似於以下內容的消息並將其廣播到所有打開的控制台，直到問題得到解決。

EMERG:hana:quickCheck:HANA-SPS_HDB00:136363:WARNING: 服務器 hana2-1 和 
hana2-2 之間發生臨時通信故障。需要手動干預以最大程度地降低數據丟失的風險。 
要解決這種情況，請停止使用以下資源層次結構之一：hana2-1 上的 HANA-SPS_HDB00 或 
hana2-2 上的 HANA-SPS_HDB00。 
資源層次結構停止服務的服務器將成為輔助 SAP HANA 系統複製站點。

解決建議：

  1. 調查每個集群節點上的數據庫以確定哪個實例包含最新或相關的數據。 該決定必須由熟悉數據的合格數據庫管理員做出。
  2. 包含需要保留的數據的節點上的 HANA 資源在 LifeKeeper 中將保持 Active (ISP)，並且將重新註冊為輔助複製站點的節點上的 HANA 資源層次結構將在救生員。 右鍵單擊 HANA 資源層次結構中應停止服務的節點上的每個葉資源，然後單擊中止服務…
  3. 一旦 SAP HANA 資源層次結構成功退出服務，LifeKeeper 將在下一個 quickCheck 間隔（默認為 2 分鐘）內將備用節點重新註冊為輔助複製站點。 一旦複製恢復，備用節點上不存在於主動節點上的任何數據都將丟失。 備用節點重新註冊為輔助複製站點後，SAP HANA 層次結構已返回到高度可用的狀態。

SAP HANA 系統複製裂腦解決方案

而在這種裂腦場景中，會記錄一條類似於以下內容的消息，並將其廣播到所有打開的控制台。 檢查間隔（默認為 2 分鐘），直到問題得到解決。

EMERG:hana:quickCheck:HANA-SPS_HDB00:136364:WARNING: SAP HANA 數據庫 
HDB00 正在運行，並在 hana2-1 和 hana2-2 上註冊為主要主機。 
需要手動干預以最大程度地降低數據丟失的風險。 要解決這種情況，
請通過在該服務器上運行命令“su – spsadm -c “sapcontrol -nr 00 
-function Stop””來停止 hana2-2 上的數據庫實例 HDB00。 一旦停止，
它將成為輔助 SAP HANA 系統複製站點。

解決建議：

  1. 調查每個集群節點上的數據庫，確定Standby節點上是否存在重要數據，而Active節點上不存在。 如果在裂腦狀態下重要數據已經提交到 Standby 節點上的數據庫，則需要手動將數據複製到 Active 節點。 該決定必須由熟悉數據的合格數據庫管理員做出。
  2. 一旦任何丟失的數據從備用節點上的數據庫複製到活動節點，通過運行 LifeKeeper 警告消息中給出的命令停止備用節點上的數據庫：

    su – adm -c “sapcontrol -nr <Inst#> -function Stop” 其中是 HANA 安裝的小寫 SAP 系統 ID，<Inst#> 是 HDB 實例的實例編號（例如，實例編號、例如，HDB00 是 00）

  3. 一旦數據庫成功停止，LifeKeeper 將在下一個 quickCheck 間隔（默認為 2 分鐘）內將備用節點重新註冊為輔助複製站點。 一旦複製恢復，備用節點上不存在於主動節點上的任何數據都將丟失。 備用節點重新註冊為輔助複製站點後，SAP HANA 層次結構已返回到高度可用的狀態。

了解常見的裂腦場景並採取這些步驟來緩解它們可以節省您的時間並保護數據完整性。

經授權轉載SIOS

高可用性架構和最佳實踐

by Leave a Comment

 

 

高可用性架構和最佳實踐

關於高可用性的 13 個鮮為人知的事實

1. Hypervisor HA 與應用程序 HA 不同

一個關鍵的誤解是，我之所以具有高可用性，是因為我的硬件或虛擬機管理程序中有冗餘。 但是，硬件和管理程序冗餘並不能保證高可用性用於應用程序。 也不能保證應用程序的編排將在失敗時正確執行。

2. 在高可用性中，更大並不等於更好

如果你是一名力量舉運動員，更大的重量更好，更小的代表更好。 或者，如果我們談論擁抱。 （你還記得擁抱是我們見到來自不同城鎮的朋友時經常做的事情，我們有一段時間沒見過了。）但是，更大並不總是意味著更好。 例如，更大的腎結石肯定不是更好。 在更高的可用性中，創建更大、更複雜的解決方案並不總是意味著您將提高您的高可用性。 這可能意味著您的可用性相同或更少。 這也可能意味著您有一個更大、更複雜的系統，其中包含許多移動部件，需要在停機時進行分類。

3. 一切都失敗了……有時

應用程序編程語言可以追溯到 1950 年代。 雖然語言、處理器、IDE 和代碼質量有所提高，但現實是“所有應用程序都會在某個時候失敗”。由於異常、錯誤、未處理的終止、意外終止、資源耗盡等導致的失敗時有發生。 仍然需要一個主動/主動或主動/被動應用程序可用性策略。

4. 關注“為什麼”和“如何”一樣多

我們跳入任務完成模式的自然傾向是一種必要的資產，但需要通過我們對為什麼的問題的回答來加以調節和引導。 在不了解業務、應用程序、數據庫和利益相關者要求的情況下向環境添加解決方案將導致：

  • 失敗
  • 超支
  • 表現不佳
  • 混亂和過度架構
  • 上述所有的

與其只關注實現可用性，不如花費必要的資源和精力來了解業務需求和“為什麼”的答案

5. 未修補的問題是常見的遺憾來源

做或不做，後果自負。 所有未修補的問題的後果是後悔。 作為客戶體驗副總裁，我親眼目睹了由於客戶未能及時解決已知問題而導致的停機。

6. 未記錄的問題也會導致停機

描繪場景。 一位新管理員正在調查網絡上的服務器。 使用情況報告表明服務器未處於活動狀態，並且沒有連接任何客戶端。 新管理員無法識別服務器，也沒有發現“標籤”、文檔或其他標識符，因此認為應該關閉它。 不幸的是，未記錄和未通信的實例實際上是一個備用服務器，當主服務器意外崩潰時，刪除它會導致停機。 這不是虛構的故事，而是一個新管理員的真實故事，他錯誤地將服務器識別為空閒 QA 系統並在修補練習之前將其關閉。

7、自滿也是敵人

如果內部或云中或介於兩者之間的任何地方的可用性是我們可以“設置並忘記”的，我們都會喜歡它。但是，生活中很少有事情真的像“設置並忘記它”那樣簡單。未來可用性的最大敵人之一是您現在的高可用性成功。 當災難很少發生並且團隊確信他們已經實現了持續穩定時，自滿情緒就會介入。 成功誘使我們認為什麼都不會改變，因此對高可用性的自滿是高可用性的敵人。 企業周圍和企業內部的事物正在發生變化。 雲在變化，您的業務需求在變化，應用程序和操作系統也在變化。

8.改變很難

改變很難。 問問那些一直試圖在睡前放棄第二塊蛋糕的愛吃甜食的人吧。 即使在高可用性中也會出現類似的阻力。 團隊，即使是那些經歷過災難的團隊，即使改變是好的，也往往不願意改變。 他們需要遠見、對原因的理解和支持。 其他擁有解決方案的團隊不願意提高高可用性，因為害怕引入不穩定或將自己暴露在新的風險中。

9.所有的改變都不是好的改變

改變是好的，當改變是好的。 在考慮對更高可用性解決方案和架構進行更改時，根據目標、要求以及在提高可用性的範圍內分析更改至關重要。 提高穩定性、增加對關鍵組件的保護、消除變通方法、優化服務可用性並經過全面測試的更改都是很好的更改。

10. 便宜並不總是更好

便宜並不總是更好。 雖然更便宜的解決方案通常具有較低的價格標籤，但它們也可能帶有許多限制，使其不太理想。 當價格標籤較低時，請注意缺少的功能，例如缺乏應用程序意識、有限的編排、隱藏的複雜性、手動恢復和故障轉移，並且僅限於沒有用戶驗證。 更便宜的解決方案也可能不包括客戶支持。 請務必了解您的更便宜的解決方案是否包含支持，或者支持是否是額外的、大量的附加成本。

這同樣適用於減少計算、磁盤或存儲的更便宜的部署。 雖然價格標籤和每月成本可能較低，但您的解決方案也可能以不太理想的容量運行。

11.響亮不等於有效

聽說過那個叫狼來了的男孩的故事。 產生警報風暴的應用程序監控解決方案遲早會被忽略。 擁有提供警報的解決方案固然很棒，但如果該解決方案錯誤地或過多地觸發了關鍵警報，則它是無效的。

12. 高可用性是一種文化和心態，而不僅僅是產品或硬件解決方案

軟件、硬件、流程、解決方案和服務都是高可用性的一部分。 但是，如果沒有跨 IT 職能和業務部門的支持，它將充滿挫敗感並不斷成為預算討論的來源，而不是關於價值、業務穩定性、提高客戶滿意度和降低風險的討論。

13.現在還不晚

希望不是實現高可用性的策略，希望您不會遇到嚴重災難或應用程序故障也不需要成為策略。 即使距離上次災難已經過去數週或數月，現在也可以設計和構建高度可用的企業架構。

聯繫 SIOS了解更多高可用性解決方案為您的應用程序。

– 客戶體驗副總裁 Cassius Rhue 轉載自SIOS

簡化雲遷移的 12 個問題

by Leave a Comment

簡化雲遷移的 12 個問題

雲遷移最佳實踐

“雲變得越來越複雜”，這是一個長達一小時的網絡研討會中的第一個聲明，詳細介紹了雲計算和雲遷移的繁榮帶來的變化和機遇。演示者繼續概述了傳統 IT 現在在其遷移過程中面臨的與雲相關的事情。自動售貨機,天藍色, GCP或其他供應商。

在向雲的傳統過渡過程中，出現了九個方面的複雜性：

  • 定義
  • 價錢
  • 聯網
  • 安全
  • 用戶、角色和配置文件
  • 申請和許可
  • 服務和支持
  • 可用性
  • 備份

作為 SIOS Technology Corp 的客戶體驗副總裁，我已經看到以下領域如何影響向雲的過渡。 為了減輕這些複雜性，消費者正在轉向託管服務提供商、雲解決方案架構師、承包商和顧問，以及大量相關服務、指南、博客文章和相關文章。 通常在轉向外部或外包資源的過程中，雲的複雜性並未完全消除。取而代之的是，公司及其僱傭的團隊來協助或將他們過渡到雲計算仍然會遇到障礙、減速帶、小問題和挫折。

大多數情況下，遷移到雲的過程中出現的這些並發症和減速來自十二個懸而未決的問題：

  1. 我們遷移到雲的目標是什麼？
  2. 您當前的內部部署架構是什麼？您有文檔、列表、流程圖或食譜嗎？
  3. 您的目標雲提供商平台是否支持您的所有應用程序、數據庫、可用性和相關供應商？
  4. 您當前的本地風險和限制是什麼？哪些應用程序不受保護，本地面臨的最常見問題是什麼？
  5. 誰負責雲架構和設計？這種架構和設計將如何考慮您當前的定義和雲提供商的定義？
  6. 誰是關鍵利益相關者，他們的里程碑、業務驅動因素和業務項目的截止日期是什麼？
  7. 您是否與供應商分享了您的項目計劃和里程碑？
  8. 當前的流程、治理和業務要求是什麼？
  9. 遷移預算是多少？它是否包括人員擴充、培訓和服務？ 您對持續維護、許可和運營費用的估計是多少？
  10. 您的團隊現有的技能和職責是什麼？
  11. 誰將負責更新治理、流程、新的雲模型以及各種傳統角色和職責？
  12. 哪些應用程序、服務或功能將從 IaaS 遷移到 SaaS 模型？

了解您的雲目標

那麼，回答這十二個問題將如何改善您的雲遷移。 正如您從問題中看到的，了解您的雲目標是第一步，也是最重要的一步。“AWS、Azure 或 Google 等雲服務提供商可以提供特定應用程序所需的服務器、存儲和通信資源”這一點幾乎被普遍接受，但對於許多客戶而言，這只會消除“他對計算機的需要”。硬件和管理該硬件的人員。”由於這一事實，客戶通常專注於設備或數據中心的整合或縮減，而沒有考慮到他們仍然需要考慮的額外雲機會和差距。 例如，雲做消除硬件管理，但它“才不是消除應用程序及其依賴項對監控和恢復的所有需求，”因此，如果您的目標是從雲中獲得所有可用性，您可能無法實現該目標，或者它可能需要的不僅僅是在本地移動到IaaS 模型。了解您的目標對幫助您規劃雲之旅大有幫助。

了解您當前的本地架構

正確遷移到雲（或任何新平台）所需的第二類關鍵問題是了解當前的本地架構。 此步驟不僅有助於識別需要可用性的關鍵應用程序，還有助於識別它們的底層依賴關係，以及基於雲的存儲、網絡和計算變化對這些應用程序、數據庫和備份解決方案所需的任何更改。回答這個問題也是評估您的應用程序和雲解決方案的準備情況以及量化您當前的風險的關鍵步驟。

當您討論和量化當前的限制時，會從解決這些問題中受益匪淺的第三個領域出現。通常，我們會看到發現的這一階段為雲中不存在的當前解決方案的局限性打開了大門。例如，最近我們的服務團隊與受 SQL 數據庫集群性能問題影響的客戶合作。一位協助遷移的 SIOS 專家詢問了解決方案和架構以及 VM 大小調整決策。 片刻之後，部署了一個更大的應用程序大小的實例，以糾正客戶由於對計算、內存和存儲的本地限製而接受的限制。同樣，我們也曾與對存儲敏感的客戶合作過。由於磁盤容量限制，他們將運行具有較小磁盤和頻繁調整大小策略的應用程序。 雖然應該考慮存儲成本，但以最小的利潤運行可能成為過去的限制。

了解業務和治理變化

最後一組問題可幫助您的團隊了解需要更新或替換的日程安排、業務影響、截止日期和治理變更，因為它們可能不再適用於雲。 遷移到雲可以是一個平穩的過渡和旅程。但是，如果無法評估您在旅程中的位置以及何時需要完成旅程，可能會變成一場噩夢。 了解時機很重要，可以通過考慮利益相關者、應用程序供應商、業務里程碑和業務季節來獲得極大的幫助。自私地，SIOS Technology Corp. 希望客戶了解他們的里程碑，因為作為服務提供商，它最大限度地減少了意外。 但是，我們也鼓勵客戶回答這些問題，因為他們經常發現部門和利益相關者之間存在分歧。 DBA 認為轉換將在本月的最後一個週末進行，但財務部門打算在同月的最後一個週末結賬；或者 IT 團隊認為轉換可以在星期一發生，但應用程序團隊要到星期三才可用，也許最重要的是，法律團隊還沒有梳理新的 NDA、協議、許可和治理變更所需的清單以將其拉下來全部一起。

當客戶帶著安全感和同理心解決問題時，經常出現的問題是碎片、所有權、流程和決策者的難題，需要使用雲提供商的框框和關於預算、人員配備、培訓的誠實對話重新組合在一起，和服務。最終的結果可能不是一次完美的遷移，但肯定會是一次成功的遷移。

如需有關雲遷移策略和高可用性實施的幫助，請聯繫 SIOS Technology Corp. – Cassius Rhue，客戶體驗副總裁 了解有關常見問題的更多信息雲遷移挑戰.

閱讀關於一些誤解雲中的可用性。

轉載自SIOS