在傳統基礎設施中維持高可用性的三大挑戰

在傳統基礎設施中維持高可用性的三大挑戰

對於依賴持續存取應用程式、服務和資料的組織而言，高可用性 (HA) 至關重要。無論是支援面向客戶的平台還是內部業務運營，停機都可能迅速導致經濟損失、生產力下降和聲譽損害。儘管許多公司由於成本、相容性或業務需求而繼續使用傳統基礎設施，但隨著時間的推移，在舊環境中維護高可用性變得越來越困難。傳統 IT 系統通常會引入現代平台旨在避免的技術限制和營運風險。

傳統基礎設施最常見的問題之一是軟體包、函式庫和系統元件之間日益增長的不相容性。老舊技術通常基於多年前設計的緊密耦合依賴關係構建，當時解耦理念尚未真正實踐應用。隨著時間的推移，這些系統變得難以更新，因為軟體已經發生了巨大變化，或者不再維護。

以下是一些使用老舊基礎設施時可能遇到的問題範例：

• 更新一個軟體包或庫可能會無意中破壞依賴舊版本的其他元件。我以前就遇到過這種情況，一個依賴項導致另一個依賴項，如此循環往復，結果幾個小時就過去了，因為你得重新編譯十幾個軟體包！
• 缺乏關於服務如何互動的文件可能會使升級變得困難。
• 最後，現代監控、安全或自動化工具可能無法與過時的系統無縫整合。在高可用性環境中，即使是微小的相容性問題也可能引發重大中斷。

將基礎設施現代化規劃納入您的高可用性策略。

保持高可用性老舊的基礎設施會帶來技術和營運方面的挑戰。軟體包不相容、供應商支援有限以及內部專業技術水平下降都可能威脅系統穩定性，並增加停機風險。

儘管傳統系統可能繼續發揮重要的業務功能，但企業應積極規劃基礎設施現代化，改善文件編寫規範，並投資於知識轉移，以免關鍵專業技能流失。強大的高可用性策略旨在確保未來長期可靠性、安全性和營運彈性。

作者：Cassy Hendricks-Sinke，SIOS IT 維運資深系統工程師

經許可轉載SIOS

LifeKeeper 通用應用程序，用於高可用性和災難復原

LifeKeeper 通用應用程序，用於高可用性和災難復原

保護業務關鍵型應用程式的成功關鍵

高可用性和災難復原必須涵蓋廣泛的應用場景。應用場景的數量與組織的數量一樣多，遠遠超出任何單一解決方案的能力範圍。高可用性和災難復原該解決方案旨在為各種場景提供開箱即用的支援。雖然許多常見應用程式都有豐富的可用高可用性和災難復原解決方案，但更具體的用例會限制可用於保護業務關鍵型應用程式的方案選擇。

當然，LifeKeeper 無法開箱即用地涵蓋所有用例。然而，LifeKeeper 提供了一個通用且靈活的框架，可以適應各種用例，從而彌補這一不足。雖然功能強大，但對於外行人來說，這個框架可能顯得複雜。本部落格旨在幫助您在為特定用例構思通用應用程式復原工具包時獲得一些幫助。

相關部落格和背景閱讀推薦

本部落格假設讀者已熟悉 LifeKeeper 資源層級架構和 LifeKeeper 叢集。如需了解這些主題的背景知識，請參閱下方列出的部落格。此外，本部落格還基於先前關於如何利用 LifeKeeper 中的「快速服務保護應用程式復原工具包」（QSP ARK）來彌合潛在用例與支援的保護機制之間差距的部落格（連結如下）。

• Linux叢集/Windows 叢集（本文由SIOS全球銷售與行銷副總裁霍格蘭女士及SIOS行銷團隊撰寫）

• 應用智能與高可用性（本文由SIOS資深軟體工程師Hendricks-Sinke女士撰寫）
• 資源行動和背景通用應用程式復原工具包（本文由資深技術推廣專家伯明罕先生撰寫）
• 在 GenApp 和 QSP 之間進行選擇：為您的關鍵應用程式量身定制高可用性（本文由 SIOS 資深軟體工程師 Hendricks-Sinke 女士撰寫）。

然而，本部落格將探討當 QSP ARK 無法滿足特定應用程式或用例的高可用性和災難復原需求時可用的選項。

應用概念化和方法定義

詢問有關應用程式健康狀況的最細微的問題

系統管理和軟體工程都是非常注重細節的領域。一個問題背後可能包含許多因素，因此很難找到一個簡單直接的答案。在日常對話中，這很容易理解。但在程式碼中，複雜的答案卻難以實現。提出「最小問題」的做法，就是將問題聚焦到盡可能小的層面，同時確保答案符合明確的標準。

「應用程式是否正在運行？」這是一個「大」問題，可能需要詳細的答案。應用程式確實在運行，但沒有響應。應用程式確實在運行，但它運行在另一個系統上，而不是你正在討論的這個系統。答案的標準很模糊，而且答案本身也很微妙——開發人員通常都不願意處理這種細節。

“應用程式進程是否正在運行？應用程式是否正在積極回應查詢？”

雖然表述起來更冗長，但這卻是一個更小的問題。它清晰地定義了答案為“是”或“否”的條件。儘管這項改變有所改進，但它還不是「最小」的問題。先前的問題同樣陷入了「X 和 Y 是否都為真？」的陷阱。 「是」或「否」的答案無法提供足夠的細節來獨立判斷 X 和 Y 的真假。最小的問題需要具體性；它必須能夠全面洞察整體中最小元素的狀態。 「應用程式的進程是否在目標系統上運行？」這是一個小問題——在本例中，這就是最小的問題。請記住，可能存在多個「最小」的問題——在本例中，「應用程式是否回應查詢」也符合條件。

雖然問題幾乎可以無限細分，但還是存在一個限度。 「最小的問題？」這句話的意思是「提出一個能夠提供有用/可操作資訊的最小問題」。問「我是否在去費城的火車上？」就足夠了；進一步問「我是否在去費城的火車上，費城是哪個方向？」可以提供更多資訊——但這並不能提供可操作的資訊。我無法改變火車的行駛方向。我只能從「我是否在去費城的火車上？」這個問題的答案中判斷是否需要打電話通知老闆我會遲到。

雖然在這個例子中這一點很明顯，但在開發通用應用程式時就不那麼顯而易見了。在保護通用應用程式的整個過程中，仍然需要著眼於全局。這和其他事情一樣，都是一項技能──透過實踐和協作，就能判斷哪些問題是最根本的問題，哪些細微之處不再能提供更多有用的資訊。

通用應用程式復原工具包的建構基礎是將廣泛的問題分解為針對各個組成部分的更小、更具體、更有針對性的問題。每個「大問題」都可以透過其中涉及的各個組成部分的解答綜合起來得到解答。

一旦將問題分解成最小的組成部分，需要傳遞的訊息就會變得清晰得多。在了解了所需資訊後，開發通用應用程式復原工具包的剩餘工作就變成如何從現有資訊中提取所需資訊。必須利用已有的資訊進行工作。

使用應用程式 API 和 LifeKeeper API

應用程式通常會提供圖形使用者介面 (GUI) 來顯示資訊或應用程式發生的變更。雖然這對於人為操作來說非常方便，但當管理工作由應用程式執行時，這種方式就顯得不太實用。 GUI 是供人使用的，而應用程式（為了避免大量的程式設計工作和不必要的複雜性）並不具備像人一樣與另一個應用程式的 GUI 進行互動的能力。對於 LifeKeeper 和通用應用程式資源而言，通用應用程式復原工具包的操作腳本與受保護的應用程式之間的資訊交換必須透過應用程式介面 (API) 來完成。

LifeKeeper 提供自己的 API，用於與 LifeKeeper 本身、其層級結構以及層級結構中的資源進行互動。對於 LifeKeeper 的 API，產品內建的命令列實用程式在通用應用程式中最易於使用。一般建議僅使用 LifeKeeper 產品文件中概述的命令列實用程式（Linux 命令文檔/Windows 命令文檔應該使用這些命令。即使有了這項建議，使用這些命令時也應謹慎細緻，以確保不會產生意外後果。

當然，LifeKeeper並非通用應用程式保護的唯一要素。受保護的應用程式還需要提供API，以便操作腳本能夠利用該API來實現預期結果。開發通用應用程式復原工具包確實需要了解受保護應用程式的API，以及如何在構成該工具包的操作腳本中使用該API。

在恢復腳本中使用返回碼和輸出流

無論是 LifeKeeper 的 API 還是受保護的應用程序，資訊主要以兩種方式輸出：

• 回傳代碼
• 輸出流（有時稱為“STDOUT/STDERR 輸出”或簡稱“終端輸出”）

回傳碼如何幫助判斷成功或失敗

從廣義上講，返回碼提供了一種快速判斷實用程式是否成功的方法。通常（在 shell 環境中），回傳碼 0 表示成功，而非零回傳碼表示失敗。

根據應用場景的不同，返回碼的具體值可以提供更多關於所遇到錯誤的資訊。通常，只需檢查返回碼即可推斷透過應用 API 執行的操作的結果。

在一些更複雜的情況下，返回碼可能僅用於告知程式在呼叫應用程式 API 後應採取何種操作。當處理與底層元素狀態相關的實用程式時，返回碼尤其有用。

輸出流如何提供更詳細的應用程式信息

輸出流雖然在程式中使用起來比較複雜，但有時對於資訊交換或驗證結果來說是必不可少的。例如，如果執行一個實用程式來取得系統主機名，僅憑回傳碼無法確定主機名稱是什麼，除非該實用程式成功取得了主機名稱。在某些情況下，即使 API 實用程式已獲取到要求的信息，它也可能返回成功返回碼，但該信息的有效性仍需根據具體情況進行評估。

無論使用返回碼還是輸出流，開發通用應用程式都需要利用現有資訊。在思考如何實現資源操作（下一節將詳細介紹）或確定應用程式或 LifeKeeper 資源的相關資訊時，請嘗試從返回碼和輸出流的角度思考，而不是從圖形使用者介面 (GUI) 的角度思考。想像一下透過電話傳遞訊息會很有幫助。也就是說，當實用程式的輸入和輸出能夠準確地作為輸入或輸出進行報告時，資訊傳遞、操作定義和場景處理才能達到最佳效果。

建構通用應用程式保護的基礎

本節主要著重於策略的概念性闡述。這些策略為思考應用程式奠定了基礎，其核心在於如何透過對應用程式提出的問題和採取的操作的回應來進行分析。接下來，我們將更具體地探討 LifeKeeper 以及通用應用程式恢復工具包的創建過程。同時，這些策略與其他技能一樣，需要透過實踐來提升。無論是在技術交流、撰寫流程文檔，或是其他任何工作中，練習這些概念化策略不僅能帶來短期益處，更能帶來長期的益處。

需要協助保護不符合標準高可用性模型的關鍵業務應用程式嗎？ SIOS 可以幫助您評估環境並確定合適的 LifeKeeper 方法。申請演示今天。

作者：Philip Merry，SIOS Technology Corp. 的 L3 支援工程師

經許可轉載SIOS

SIOS 企業支援指南：您的計畫涵蓋哪些內容

SIOS 企業支援指南：您的計畫涵蓋哪些內容

您的 SIOS 企業支援計畫包含哪些內容？

以下是一些關於企業級支援涵蓋範圍和不涵蓋範圍的快速提示，以及根據三種常見場景，從哪裡獲取更多資訊。

全天候支援關鍵系統停機

場景 1：下班後系統宕機

瓊的團隊：現在是美國東部時間週日晚上7點。 SIOS LifeKeeper叢集節點之間的例行切換原本應該很簡單，但意外情況發生了，導致切換失敗。儘管團隊盡了最大努力解決問題，叢集仍處於宕機狀態。瓊需要幫助，但她不確定自己的SIOS技術支援計畫是否涵蓋週末，也不知道需要多久才能聯繫到技術支援人員。

在事件發生前已購買（或續約）企業級支援服務的客戶，可享有每週 7 天、每天 24 小時全天候支援服務。此支援服務包括週末和假日，以解決關鍵問題。關鍵問題是指生產系統或應用程式宕機，導致客戶資料無法透過 SIOS 程式存取。對於所有優先級 1（關鍵）問題，即正常運作導致無法存取生產資料的問題，SIOS 承諾在 2 小時內回應。

如果 Joan 擁有有效的企業支持，她可以聯繫 SIOS 支援團隊，她的非工作時間問題將得到解決。

安裝和配置支援

場景二：需要安裝協助

斯科特的團隊：現在是周四下午4點（美國東部時間）。新基礎設施項目的批准已經完成，包括關鍵應用程式和資料所需的高可用性配置。在啟動會議上，利害關係人推遲了上線日期。因此，團隊需要盡快完成系統安裝和配置，以避免服務中斷。斯科特的團隊知道如何配置應用程式和伺服器，但他們希望確保高可用性解決方案安裝正確。他們需要幫助，但斯科特不確定他們的支援計劃是否涵蓋安裝錯誤的幫助。

由於 Scott 的團隊正處於部署階段，新的基礎設施專案涉及的系統尚未經過驗證或成功投入生產。如果 Scott 的團隊擁有有效的 SIOS 企業級支持，他將可以存取 SIOS 產品文件和安裝指南。但是，Scott 的企業級支援不包含安裝和設定的協助，但他可以聯絡 SIOS 銷售代表安排付費的專業服務安裝。這項服務將確保 Scott 的團隊獲得正確安裝、配置和驗證叢集所需的協助。 SIOS 提供廣泛的…專業服務旨在幫助客戶快速、經濟高效地實施、管理和維護其高可用性環境。

故障轉移後的根本原因分析 (RCA)

場景 3：故障轉移後根本原因分析支持

阿莫爾的團隊：現在是星期二凌晨2點（美國東部時間）。 AjaxBjax公司的所有應用團隊都收到了警報。保護公司最關鍵應用系統的叢集正在進行故障轉移。阿莫爾查看了應用程式控制面板，發現故障轉移成功，所有應用程式都正常運作。然而，阿莫爾知道管理層會要求一些解釋和保證。阿莫爾想確保所有應用服務都已啟動並正常運行，但他不確定他們的支援計劃是否涵蓋這種情況。

Amol 的團隊正在尋求根本原因分析 (RCA)，並確保他們的系統能夠持續運作。 Amol 的數據可以訪問，他的應用程式功能齊全。他的系統並非關鍵的生產伺服器宕機，也不是 P1 級問題。但是，如果 AjaxBjax 公司為其集群購買了有效的企業級支持，他們就可以聯繫 SIOS 支援團隊，獲得週一至週五（美國東部時間）全天候的 RCA 問題指導。 Amol 凌晨 2 點的來電將轉接到 SIOS 經驗豐富的支援中心，該中心的團隊將立即開始與 Amol 合作。

關於聯絡 SIOS 支援的其他問題

Amol 和 Joan 透過企業支援熱線（美國：877.457.5113；國際：+1.803.808.4270）聯繫了技術支援。 Scott 則透過購買配置和安裝協助服務而非直接聯繫技術支援團隊獲得了所需的幫助。但對於其他情況呢？ Scott、Amol、Joan 和其他用戶如何了解更多關於他們的支援等級和支援詳情的資訊？或者他們的產品是否已進入維護或擴展支援階段？

當您需要了解有關支援協議的更多資訊時，可以查閱隨每份訂單提供的 SIOS 技術支援協議 (TSA)。您也可以在我們的網站上輕鬆找到 TSA。下載站點您可以透過發送電子郵件至 SIOS 支援團隊提出請求。support@us.sios.com此外，產品時間表和支援等級資訊可在網路上找到，網址為：產品生命週期頁。

如果客戶已經了解其計劃涵蓋的內容，但需要幫助解決問題、解答一般性問題、進行根本原因分析、獲取最新軟體或獲取更多信息，可以通過以下方式提交新案例：支援門戶可透過網站或發送電子郵件至支援收件匣support@us.sios.com一旦您的案件創建完成，團隊將努力提供及時的回覆和解決方案。

作者：卡修斯‧魯，客戶體驗副總裁

經許可轉載SIOS

為什麼沙箱環境對高可用性至關重要

為什麼沙箱環境對高可用性至關重要

說服管理層投資非生產基礎設施

說服管理階層投資非生產基礎設施並非易事。如果處理不當，關於增設測試叢集或沙箱環境的討論很快就會演變成抱怨要為環境（基礎設施、軟體、IT資源、應用程式和許可證）支付雙倍費用，以及指責測試人員。叢集“不產生任何收入”。關於成本的討論逐漸演變成各種斷言，例如備份、DevOps 和軟體運作手冊已經使測試環境過時。

然而，如果沒有與生產環境完全相同的測試環境，其成本通常會比額外搭建一個測試集群的成本高出指數級。這些額外成本往往以計劃外停機、資料損壞、緊急修復以及工程團隊壓力過大等形式隱藏起來。

10 個問題有助於論證沙盒環境的必要性

如果您在為建立合適的沙盒環境爭取預算審批方面遇到困難，不妨向您的領導團隊提出以下 10 個問題。這些問題能將討論的重點從重複集群的成本轉移到確保業務免受損失的價值。

1. 停機時間究竟會對我們的組織造成多大的損失？

首先要考慮的是最終結果。如果部署失敗，生產高可用性叢集宕機，會對組織造成多大的損失？每小時損失多少？我們公司每個業務部門的資源消耗率是多少？

這個問題將討論從模糊的說法引向了更具體的層面，例如每分鐘的收入損失、停機期間員工閒置的工資，以及更難以量化的聲譽損失。如果生產中斷每小時造成 30 萬美元的損失，那麼每年只需避免一次 4 小時的停機，就能節省 120 萬美元。有了這些切實可行的商業數據，實施沙箱系統以降低高成本停機風險的投資報酬率就一目了然了。

2. 我們每個月執行多少次維護活動？

很簡單：頻率等於風險敞口。風險敞口等於額外成本。如果您每週都部署更新、修補程式或設定更改，那麼一年下來就相當於擲骰子 52 次。回顧問題 1：由於修補程式更新失敗導致的停機一小時會對組織造成多少損失？現在，將這個損失乘以您的維護頻率。

正如SIOS的副軟體工程師Tristan Allen提醒客戶的那樣，一個與生產環境完全相同的沙箱提供了一個寶貴的環境，“可以在其中對新功能、配置變更和補丁進行全面測試。除了功能測試之外，QA環境還允許進行流程驗證、性能基準測試、負載測試和安全驗證。這些對於識別瓶頸至關重要。”漏洞或者，在整合問題有機會影響最終用戶或損害您的環境之前就將其解決。 」

發布和維護更新的速度加快，使得安全保障機制變得特別必要。

3. 我們對部署到生產環境有多大信心？

每次更新到生產環境時，團隊是否都提心吊膽？我們聽過多少次「只是改了一行程式碼而已」這種說法？就算只是一行程式碼的偏差或空指標錯誤，都可能造成嚴重的宕機。您對團隊確保新部署的軟體包不存在編碼錯誤、邏輯缺陷、架構問題、第三方相容性問題或排序錯誤的能力有多大信心？

您的團隊對您的健康狀況有多大信心？生產環境如果您的生產環境不穩定，沙箱叢集可以讓您驗證部署流程本身，從而顯著降低緊急回滾的成本和壓力，並可以預先驗證修復方案。

4. 我們對直接在生產環境中應用安全修補程式的風險承受能力如何？

安全性修補程式不容商榷，但有時它們會與現有庫或配置衝突。直接在生產環境中套用核心補丁或資料庫更新是一種冒險行為。

身為客戶體驗副總裁，我們直接與客戶合作，回滾了直接應用於生產環境的核心更新。雖然更新修復了一個問題，但卻產生了意想不到的副作用，嚴重影響了儲存層，導致死鎖、應用程式崩潰和其他瓶頸。

如果您難以證明部署完整QA叢集的必要性，不妨問問您的管理團隊：我們是否願意為了應用安全修補程式而冒著影響關鍵業務應用程式的風險？沙箱環境可讓您先在完全相同的環境中套用這些補丁，確保「修復」安全漏洞不會「破壞」業務。除了修補程式之外，它還允許您部署新的應用程式和更新，以探索可能出現的任何安全漏洞或風險。

5. 資料損壞會對財務和營運造成哪些影響？

停機是暫時的，但資料遺失可能是永久性的。底層儲存的不相容變更、應用程式邏輯錯誤或裝置驅動程式問題都可能悄無聲息地損壞數據，而這種損壞往往不易察覺。您是否希望在生產環境中發現，備份工具的更新導致您無法再備份或還原關鍵應用程式資料？

當你意識到生產環境中的錯誤時，可能已經造成數週的資料損壞。或者，你可能會遇到危機，發現備份資料無法在新更新的軟體上恢復。沙箱環境允許你針對真實資料的副本運行資料完整性測試、資料遷移、模式更新、驅動程式更改，甚至複製軟體場景，從而確保即使資料遺失或損壞，也發生在安全的環境中，而不是在向客戶計費的環境中。

6. 我們能否承受第三方整合悄無聲息地失敗？

您的應用程式可能依賴 API、第三方身份驗證、第三方應用程式或其他形式的依賴項。這些依賴項在高負載下，尤其是在叢集環境中，行為會有所不同。

不相容的變更通常並非源自於程式碼本身，而是源自於程式碼與基礎架構的互動方式。如果一項變更在開發人員的筆記型電腦上運作正常，但在分佈到三個節點上時卻失敗了，那麼這將導致業務中斷。沙箱環境可以在這些「在我機器上運作正常」的錯誤影響到客戶之前將其捕獲。

7. 我們為真正的災難復原場景做好了多少準備？

大多數組織都有災難復原 (DR) 計劃紙面上的計劃固然美好，但未經測試的計劃只是假設。驗證災難復原策略的唯一方法是執行它，模擬整個站點故障或資料損壞事件。如果沒有沙箱集群，測試災難復原計畫就只能針對生產環境。這會帶來風險、成本、危險的物流以及停機時間。

如果沒有沙箱集群，您必須故意將產生收益的系統離線，以驗證它們能否重新上線。這需要網路、儲存、資料庫和應用團隊之間進行大量的協調。在生產環境中進行這種操作的成本，就像在漏水的系統中安裝一個不斷運作的水錶一樣。

除了停機時間之外，在生產環境中測試災難復原場景本身就會帶來風險和複雜性。風險在於需要處理即時數據，並確保嚴格遵守所有數據保護步驟。複雜性通常不在於故障轉移本身，而在於復原。一旦成功故障轉移到備用站點或備份節點，將生產叢集還原到原始狀態（故障復原）就是一個複雜且高風險的操作。

提醒管理階層，沙盒環境的成本可以讓團隊在工作時間內模擬災難性故障並執行完整的復原流程，而不會影響使用者。團隊可以協作完善“運行手冊”，安全地查找並解決流程缺陷，並進行充分的演練，這樣，當真正的災難來臨時，團隊就能執行一套精心設計的流程，而不是進行一次危險的首次嘗試。

9. 我們如何引進新供應商並培訓現有團隊？

卓越的組織會為新團隊成員、供應商和服務提供者制定完善的IT入職流程。這些組織深知，結構化的入職框架對新團隊成員至關重要。他們重視並優先創建學習管理系統，並創造一個資源豐富的企業文化，幫助新員工了解他們將要管理、維護和更新的關鍵高可用性環境。他們也深諳持續學習的價值，並積極主動地保持團隊技能的精湛。

如果沒有與生產環境直接相同的沙箱系統，您的 IT 入職培訓就必須利用您的生產集群。這意味著新畢業的大學生要學習如何運作…補丁管理在公司最重要的業務機器上，高可用性 (HA) 環境下的安全軟體和應用程式更新至關重要。如果操作人員遇到運作手冊中不清楚或恰好缺失的環節，對生產力造成的損失以及對自身和企業聲譽造成的損害風險可能是毀滅性的。

在倡導建立沙盒環境時，應強調持續引入供應商、合作夥伴和託管服務提供者的重要性，以及缺乏讓他們了解業務或探索流程的環境所帶來的風險。如果您的組織沒有沙盒系統，不妨向領導階層提出以下幾個問題：

• 我們的新團隊成員將要去哪裡了解他們將要管理、維護和更新的環境？
• 他們將如何保持技能與時俱進？
• 必要時，我們會使用哪些系統來妥善安排下一批團隊成員的入職？

10. HA工具保險的費用是否比災害造成的損失便宜？

最後，讓我們來談談最棘手的問題：工具和硬體的成本。

高可用性聚類軟體相關的計算成本並非免費。然而，請將沙箱許可和基礎設施的年度成本與一次重大停機、回溯或資料遺失事件的成本進行比較。幾乎在所有情況下，預防成本都遠低於補救成本。

沙盒環境是一項業務連續性投資

正如SIOS的副軟體工程師Tristan Allen在他的部落格中總結的那樣：

品質保證和生產環境在確保系統平穩運作方面發揮著至關重要的作用。透過隔離環境、進行全面測試以及謹慎管理部署，IT 團隊可以減少停機時間、保持高可用性，並實現無縫更新過渡。

如果您的管理團隊難以理解完整沙盒環境的優勢，不妨試著向他們提出以下幾個問題。透過這些問題，您可以將討論從過於簡單的成本問題引向更聚焦的對話，從而更好地理解沙盒環境的益處。業務連續性這使得管理層更容易批准該預算項目。沙盒集群並非奢侈品，而是企業降低風險的寶貴資產。

申請演示了解 SIOS 如何透過彈性高可用性和災難復原解決方案幫助您降低停機風險。

作者：Cassius Rhue，SIOS客戶體驗副總裁

經許可轉載SIOS

繼承 DataKeeper

繼承 DataKeeper

繼承 DataKeeper 環境意味著什麼

繼承的概念通常讓人聯想到資產從一個人傳給另一個人。韋氏字典和其他字典對繼承的定義是：

遺產是指逝者留下的資產、財產，有時還包括債務，透過遺囑、信託或州無遺囑繼承法分配給受益人。遺產通常包括現金、房地產、股票、債券、個人物品（珠寶、汽車）和商業權益。

在IT領域，繼承的概念帶了數位化的色彩。當系統管理員繼承一個使用諸如以下工具的集群時：資料保管員他們處理的不是珠寶或房地產之類的有形資產，而是數位資源——想想配置、角色和關鍵容量資源。雖然我們希望這筆遺產是某人從公司退休或獲得應有的晉升的結果，但我們還是祈禱它不是因為有人去了「天上的巨型資料中心」。 （沒錯，幽默是IT專業人士的應對機制！）

所以，如果您有幸獲得現有的 1×1 集群，其中包含 SQL Server 角色和相關的 DataKeeper 磁碟區資源，那麼您該從哪裡開始呢？您應該採取哪些步驟來確保順利完成入職和知識移轉流程？

為了幫助指導這一過渡，以下是一些你應該問自己或你的管理團隊的關鍵問題：

帳戶管理問題

客戶經理詳情

• 目前負責該帳戶的客戶經理是誰？
  • 他們的聯絡方式是什麼（電子郵件、電話等）？

許可資訊

• 您的授權協議、合約和續約情況如何？
• 有哪些即將到期或需要續約的許可證需要注意？
• 我可以在哪裡存取許可入口網站？我是否擁有必要的憑證？

DataKeeper 管理問題

了解環境

• 評估現有基礎設施，包括Windows Server故障轉移群集設定、伺服器、儲存等。
• DataKeeper目前正在保護哪些工作負載和應用程式？

配置和管理

• 熟悉DataKeeper配置。
  • 目前使用的非同步和同步鏡像類型有哪些？
  • 叢集節點是如何設定的？
  • 涉及哪些儲存措施？

維護和軟體更新

• 如何隨時了解 DataKeeper 的新版本、修補程式和更新？

測試故障轉移和恢復

• 偶爾測試故障轉移，以確保高可用性和災難復原配置按預期工作。
• 發生災難時，鏡像資料是否一致且可恢復？

了解資源所有權和依賴關係

一旦你盡可能地了解了你的遺產，下一步就是開始照顧你所繼承的財產，正如上圖所示。當你「繼承」了某項財產的所有權時，SQL Server 叢集因此，識別並與所有受集群管理影響的跨職能團隊進行溝通至關重要。由於涉及的領域眾多，以下是一些需要重點關注的關鍵領域：

SQL Server 或應用程式團隊

• 主動接收有關 SQL Server 名稱或執行個體任何計畫變更的通知
• 獲悉可能影響叢集效能的大型 SQL 插入或操作
• 請提供資料庫檔案、備份和快照的具體位置資訊。

網路團隊

• 溝通將 SQL 角色或相關資源遷移到不同網路的計劃。
• 分享有關新 IP 位址或其他可能影響叢集運作的網路相關變更的信息

儲存團隊

• 對於這些，在更改來源磁碟區和目標磁碟區（例如，調整大小、格式化或新增分割區）時要謹慎，因為這可能會對 DataKeeper 複製產生影響。
• 現有鏡像伺服器的頻寬是否足夠？
  • 您能否與網路團隊合作，確保頻寬充足，並與其他應用程式隔離以避免瓶頸？

為什麼運作手冊在 DataKeeper 環境中如此重要：

運作手冊是確保系統順利運作的關鍵組成部分，為使用 DataKeeper 的環境、叢集管理員及相關技術提供了有效的解決方案。理想情況下，精心編寫的運作手冊應該是一份“動態文件”，隨著時間的推移不斷更新，反映基礎設施、工作流程和最佳實踐的變化。如果之前的管理員已經盡職盡責地做好了準備工作，那麼您的運作手冊應該全面涵蓋以下方面：

• 故障/修復：解決已知問題，這些問題可能出現在「堆疊」中的任何位置，例如，從物理層一直到應用層。
• 工作流程：部署軟體和管理日常集群操作
• 維護：怎麼樣補丁管理執行資料庫備份等操作
• 供應商支援：如何到達 SIOS微軟、AWS 和其他供應商
  • 最重要的是，何時「主動聯繫」他們？

繼承 DataKeeper 的關鍵要點

這篇部落格重點討論了在進行此類轉型時需要考慮的幾個重要方面，包括帳戶管理、資源所有權、跨職能協作以及運行手冊的價值。 **然而，需要注意的是，這些只是眾多考量因素中的一部分，還有一些因素可能超出本文的討論範圍。每個環境都是獨一無二的，成功的叢集管理需要對具體的基礎設施、依賴關係和工作流程有透徹的了解。

好好享受你的「遺產」吧…

不要一次把錢全部花光…

申請演示了解 SIOS DataKeeper 如何協助簡化叢集管理並支援高可用性。

作者：Greg Tucker，SIOS 資深產品支援工程師

經許可轉載SIOS