高可用性和災難復原無所不在：從一般概念到解決方案生成

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

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

• Linux叢集/Windows 叢集（本文由SIOS全球銷售與行銷副總裁霍格蘭女士及SIOS行銷團隊撰寫）
• 應用智能與高可用性（本文由SIOS公司IT資深系統工程師Hendricks-Sinke女士撰寫）
• 資源行動和背景通用應用程式復原工具包（本文由資深技術推廣專家伯明罕先生撰寫）
• 在 GenApp 和 QSP 之間進行選擇：為您的關鍵應用程式量身定制高可用性（本文由 SIOS 的高級系統工程師 Hendricks-Sinke 女士撰寫。）

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

快速回顧

本部落格的前一部分本文探討如何思考應用程序，以便創建通用應用程式恢復工具包，從而利用 LifeKeeper 保護該應用程式。本節將第一部分介紹的應用程式基礎應用於 LifeKeeper 的通用應用程式復原工具包框架。

由於本篇部落格系列文章最好與上一篇結合起來理解，因此這裡簡單回顧一下第一部分中提出的概念。

問一個盡可能簡單但仍能提供有用/可操作資訊的問題

在決定如何回答廣泛的問題時，將其分解成若干個答案較簡單的小問題。然後利用這些小問題，逐步建構出最初「寬泛」問題的答案。

利用所提供的信息

了解可用的工具以及這些工具如何傳遞訊息。掌握回答「最基本問題」所需的資訊後，確定如何利用應用程式 API 提供的資訊來解答這些「最基本問題」。

回顧完畢，我們終於可以開始討論 LifeKeeper 了。雖然高可用性和災難復原通常與複雜性聯繫在一起，但我們已投入大量精力，確保對特定應用程式的理解能夠輕鬆移植到通用應用程式復原工具包 (GARK) 框架中。有了之前的基礎，現在是時候以此為基礎，像 LifeKeeper 一樣思考了。

像生命守護者一樣思考

想像一下，你身處電影《怪誕星期五》的場景中，一個女孩和她的母親互換了身體，由於不熟悉彼此的日常職責而手忙腳亂。和你互換身體的人要代替你參加一個上線活動，她需要知道如何啟動關鍵應用程式、確保它們正常運行，以及如何關閉應用程式。如果你只有15分鐘的電話時間準備，你會如何向她解釋這些內容？你需要詳細說明哪些資訊才能讓她順利完成工作？

雖然這個場景是人為設計的，但它很好地展現了關鍵的資源保護操作。 LifeKeeper 管理應用程序，確保它們只在單一系統上運行；LifeKeeper 資源層級結構則確保在恢復或移除資源時，先決條件應用程式和系統資源都能按正確的順序處理。反過來，LifeKeeper 使開發人員能夠在單一系統的上下文中思考對受通用應用程式資源保護的應用程式執行的操作。將啟動、停止或查詢應用程式的過程簡化到最基本的要素，是定義通用應用程式操作腳本需要完成的任務的第一步。當啟動、停止和查詢操作依照上述策略定義後，資源操作之間便一一對應，如下所示：

• 恢復操作：應用程式啟動
• 移除操作應用程式停止
• 快速檢查操作查詢應用程式
  • 筆記對於通用應用程式資源，快速檢查操作是可選的；如果未定義快速檢查操作，則不會執行監控。但是，強烈建議定期進行應用程式監控，以確保實現高可用性和災難復原的最佳效果！
• 地方復甦行動應用程式停止和應用程式啟動（按順序）
  • 筆記對於通用應用程式資源，本地恢復操作是可選的。如果未定義本地恢復，通用應用程式資源不會嘗試在偵測到故障的系統上重新啟動以進行自我修復，而是會在故障系統上停止運行，並將應用程式的整個層次結構遷移到備用系統。

有時，LifeKeeper 需要了解正在執行的應用程式的某些詳細資訊才能執行上述操作。所有 LifeKeeper 資源（包括通用應用程式資源）都具有一個名為「資源資訊字段」的字段，其目的是向操作腳本提供這些信息，以便在資源操作期間使用。資訊欄位中包含的資源資訊可以在資源擴充時針對每個系統獨立配置，從而允許資源操作使用特定於執行操作的系統的資訊。 LifeKeeper 還提供命令列實用程序，以便輕鬆取得或設定資源資訊。

回到「怪誕星期五」的例子，如果你要和對方交換身份，你需要告訴對方哪些細節？例如應用程式檔案的關鍵路徑、命令參數的特定設定/值等等。資訊欄位非常適合存放那些必須知道才能確定應用程式其他細節的資訊。資訊欄位也非常適合插入設定值、命令參數值或其他無法透過其他方式取得的值。值得注意的是，根據 LifeKeeper 的慣例，資訊欄位在資源的生命週期內很少（甚至從未）更改。為了避免資訊欄位損壞，最好將那些在資源生命週期內會發生變化的資訊放在資源資訊之外，而是透過 LifeKeeper 資源的操作腳本以程式設計方式獲取，或透過操作腳本可以呼叫的「輔助」腳本獲取。

為了提供額外幫助，LifeKeeper 還附帶用於開發通用應用程式的模板腳本。這些腳本為通用應用程式的操作腳本提供了絕佳的起點，因為它們預先準備好了 LifeKeeper 在呼叫特定資源的操作時將使用的輸入參數。反過來，這也使得這些資訊可以在資源操作腳本中使用。

結論

LifeKeeper 提供了多種應用程式保護方式。然而，某些應用程式的需求超出了 LifeKeeper 應用程式恢復工具包 (APP) 的功能範圍。在這種情況下，高可用性和災難復原保護仍然可行，而且可能比之前想像的更容易實現。組織不應迴避通用應用；相反，它們是 LifeKeeper 提供的眾多強大工具之一，可用於提升環境的高可用性和災難復原能力。通用應用程式框架旨在兼顧易用性和靈活性。但是，如果您的組織沒有足夠的資源自行編寫通用應用程式復原工具包，SIOS 提供專業服務，由 SIOS 工程師代表您的組織協調需求並開發通用應用程式復原工具包。如果需要持續支持，SIOS 專業服務還提供擴展服務，將常規產品支援擴展到由 SIOS 專業服務開發的通用應用程式。保護組織業務關鍵型應用程式的門檻正在不斷降低，而適用於 Linux 或 Windows 的 SIOS Protection Suite 旨在引領潮流，使未受保護的應用程式成為過去式。

並非所有應用程式都適合標準的高可用性模型。 SIOS 可以協助您為業務關鍵型工作負載設計和實施合適的 LifeKeeper 解決方案。申請演示今天。

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

經許可轉載SIOS

接手 Linux 叢集的 SIOS LifeKeeper

想像一下，你站在麵包車外，手裡抱著孩子，正伸手去拿尿布包，這時一輛帶有紅色條紋的黑色大麵包車停在了你旁邊。車門緩緩打開，一群形形色色的人走了出來。一個身材魁梧的身影下了車，他那標誌性的莫霍克髮型直插雲霄，渾身散發著不容置疑的威嚴，脖子上戴著的金鍊子也格外醒目。一位經驗豐富的退伍老兵走了出來，告訴你，你現在是這項關鍵任務中不可或缺的一員。

想像一下，你坐在你最喜歡的樂團的獨家彩排現場，位置在前排左側中間。你聽著他們一首接一首地演奏你最愛的熱門歌曲。你跟著這些經典老歌的節奏，像彈空氣吉他。你完美地配合節奏，在座椅和腿上交替敲擊出鼓點。最後，你從丟棄的大杯飲料裡找到兩根吸管，用它們完美地演繹了一段鼓獨奏。漫長的等待終於結束，你終於成為了爆滿觀眾中的一員，但突然間，鼓手跑下了舞台，一位焦急的經紀人指著你，讓你上台。

大丹犬卡洛斯是「大男孩犬舍俱樂部」全場總冠軍的熱門人選。你可能只從喜歡大型犬的同事那裡聽說過卡洛斯，但今天你將看到卡洛斯的全新一面。事實上，你看到了卡洛斯的方方面面，因為他的訓練員剛剛把他送到你家，而他自己則在外面等著拖車把他的工作用車拖走，並送來一輛代步車。 「只需要一個小時，」他向你保證。但要確保一隻價值百萬美元的全場總冠軍犬的安全可不是件容易的事。

說實話，原版《天龍特攻隊》或任何現實版的《天龍特攻隊》不太可能突然停在你麵包車旁邊，把你帶走去參加一個絕密、關鍵任務、拯救國家的行動。同樣，就算你模仿吉米·亨德里克斯或希拉·E惟妙惟肖，不管有沒有用大吸管，也未必能讓你從人群中脫穎而出，成為爆滿演出的焦點。雖然你可能會看到卡洛斯或其他熱門選手或冠軍，但除非你是它們的主人、訓練員或評委，否則你不太可能在無人監管的情況下和它們待在一起。雖然這些情況發生的機率很低，但你或許會被要求接手一個 LifeKeeper for Linux 集群，這其中也蘊含著類似的風險、責任和重要性。

繼承 LifeKeeper for Linux 叢集時該怎麼辦

許多企業報告稱，停機造成的損失每小時高達30萬美元，甚至數百萬美元。為了避免災難和停機，企業通常會部署具有多層冗餘的強大架構。

除了這些冗餘措施之外，許多公司還部署了高可用性 (HA) 軟體，例如適用於 Linux 的 SIOS LifeKeeper為企業關鍵型基礎架構、應用程式和資料庫添加至關重要的監控和復原功能。 LifeKeeper for Linux 提供基礎架構、應用程式、服務和資料庫的資源監控和復原功能，確保業務連續性，並將停機時間降至最低或避免。雖然它不像黑車那樣由專人駕駛，但它對企業至關重要。

那麼，如果你突然要負責管理 LifeKeeper for Linux (LK-L) 環境，而這個環境帶來的收入比幾十個 Carlos 版本還要多，你會怎麼做？

接手 Linux 叢集 SIOS LifeKeeper 的 8 個步驟

接手 SIOS LifeKeeper for Linux 叢集的八個關鍵步驟包括：

1. 尋找並查看現有運作手冊

尋找所有現有的運作手冊。這些手冊通常儲存在先前管理員建立的文件庫中。詳細的運行手冊通常能夠提供叢集配置和架構方面的深入資訊。這些資訊對於管理和未來的維運工作都大有裨益。

2. 找到您的 LifeKeeper for Linux 產品版本

了解您的產品版本是接管集群的重要組成部分。 SIOS 會頻繁發布產品更新，提供更豐富的功能、安全性更新和改進。接手現有產品群集時，您需要知道當前版本，以便評估以下幾個因素：

1. 您的產品在產品和支援生命週期中處於什麼階段？
2. 您使用的是產品的最新版本嗎？
3. 自您使用的版本以來，該產品新增了哪些功能或修復了哪些問題？
4. 在哪裡可以找到特定版本的文件？

您可以透過使用者介面尋找產品版本。如果您的執行手冊顯示 LifeKeeper 版本為 9.8.x 或更高版本，您可以使用 https://<伺服器名稱>:5110（或 https://<伺服器 IP 位址>:5110）啟動 LifeKeeper Web 管理主控台 (LKWMC)。登入後，選擇“屬性”：

屬性頁面載入完畢後，在產品名稱下方的部分找到您的版本資訊：

如果您使用的是舊版的 Linux 版 LifeKeeper，啟用 X11 轉送並啟動 Java 使用者介面透過 SSH 客戶端會話中的命令 /opt/LifeKeeper/bin/lkGUIapp。

您也可以透過命令列查看產品版本，方法如下：

# rpm -qi steeleye-lk

啟動 Java 使用者介面並登入後，即可存取幫助中心。取得產品版本後，可透過以下方式查看產品生命週期和版本特定資訊。docs.us.sios.com

3. 查看您的技術支援協議

這技術支援協議TSA（技術支援協議）概述了SIOS為其產品提供的支援。 TSA有助於識別維護、升級等關鍵資訊。產品支援TSA 也包含產品修復資訊。此外，TSA 還提供有關 SIOS 全天候​​支援服務及其聯絡方式的重要資訊。了解 TSA 有助於確保您不會孤立無援，而是得到 SIOS 團隊的支持。了解 TSA 也有助於您明確哪些服務包含在 TSA 的服務範圍內，哪些服務不包含在內，從而避免在持續部署和維護過程中出現意外情況。

4. 接受 SIOS 管理員培訓

如果您需要立即進行過渡，可能沒有先前的管理員可以為您或您的新團隊成員提供培訓。請不要擔心。 SIOS 提供便利的線上訓練。此培訓全面概述了 LifeKeeper for Linux 產品以及管理員所需的角色和操作。如果您的客戶代表已記錄在操作手冊中，請直接聯絡他們以取得更多資訊。否則，請聯絡我們。sales@us.sios.com或者support@us.sios.com尋求幫助。

5. 建立演示或測試集群

掌握了管理員培訓後，您可以部署一個測試環境，在其中練習並磨練您的技能和理解，而不會直接危及公司的數據或應用程式。建立演示或測試集群幫助您和您的未來團隊了解產品基礎知識並熟悉使用者介面。

此外，如果您的團隊繼承了運行手冊，那麼根據該手冊建立自己的叢集有助於您驗證和更新這些手冊，以便日後使用。如果可能，請盡可能模擬生產叢集中受保護的應用程式和資料。理想情況下，您的團隊建立的測試集群應盡可能與生產系統相似。這有助於您的團隊在安全環境中了解依賴關係、行為和操作，然後再在生產環境中執行命令。請務必完成以下幾個關鍵練習：

1. 手動切換
2. 伺服器故障轉移
3. 應用程式恢復
4. 維護操作

6. 安排集群健康檢查

一個集群健康檢查全面驗證 SIOS LifeKeeper for Linux 環境。您可以將其視為對高可用性叢集的多點檢查。 SIOS 專家團隊將對系統日誌、系統設定、運行手冊、LifeKeeper 操作以及其他文件進行詳細審查和驗證，以確保 LifeKeeper 環境（包括應用程式復原工具包）配置正確且運行狀態最佳。健康檢查報告將提供改善運作、降低潛在風險以及增強產品認知度的建議。

7. 利用 SIOS 支援和專業服務

《天龍特攻隊》講述的是一個團隊的故事，而不僅僅是某個人執行一項關鍵任務。你最喜歡的樂團也不僅僅是主唱、鼓手或吉他手。他們是一群志同道合的專業人士，致力於成就偉業，創作美妙的音樂，避免讓粉絲失望，並享受場場爆滿的演出帶來的喜悅。卡洛斯的成功離不開馴馬師、美容師、教練、訓練員、遛狗員、獸醫以及許多專家和經紀人的共同努力。他們的成功是團隊合作的成果，你的成功也是。充分利用你的SIOS支援團隊。support@us.sios.com或透過支援入口網站support.us.sios.com獲取寶貴的見解和資訊。

SIOS 支援入口網站包含數百篇實用知識庫文章 (KBA)，提供最新軟體，並隨時準備協助工程師引導您邁向成功。請聯絡 SIOS 支援團隊，確保您擁有支援入口網站的登入權限，並能有效管理您的叢集。支援團隊還可以幫助您存取一系列 SIOS 資源。專業服務提供的服務包括更高級的培訓、額外的健康檢查和驗證、新群集安裝協助，或為您的第一次或任何未來的維護或上線窗口提供備用工程服務。

8. 與SIOS保持聯繫

接管新叢集後，成功的秘訣在於與 SIOS 保持密切聯繫。與您的客戶代表建立定期溝通機制。這種溝通管道能讓您及時了解新的選項和機遇，提前掌握許可證續期信息，並了解如何添加新集群以擴展對更多應用程序和服務的保護。

透過新聞簡報和電子郵件推送與 SIOS 支援團隊保持聯繫。電子郵件推送會提供任何可能影響您軟體的新功能、版本發布或重要更新的最新資訊。如果您需要進一步了解根本原因分析 (RCA) 或遇到需要其他專業人員檢查的問題，請透過支援郵箱或支援入口網站提交工單。

接手 SIOS LifeKeeper for Linux 叢集並不一定意味著要感到不知所措。申請演示了解 SIOS 如何協助您保護關鍵應用程式、降低停機風險並自信地管理高可用性。

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

經許可轉載SIOS

消除單點故障

在企業IT領域，「單點故障」（SPOF）這個詞足以讓任何系統管理員夜不能寐。 SPOF指的是基礎架構中的任何元件——無論是伺服器、網路交換器或儲存陣列——一旦發生故障，就會導致整個系統癱瘓。隨著企業對系統安全的需求日益增長，這種擔憂也愈發強烈。99.99%（或更高）正常運作時間識別和消除這些漏洞已不再是可選項，而是至關重要的要求。

如果您希望使您的基礎架構萬無一失，可以將高可用性 (HA) 與資料複製提供強大的企業級解決方案，消除單點故障，確保持續運作。

利用聚類消除單點故障的強大能力

高可用性的核心在於叢集概念。叢集由一組獨立的伺服器（節點）組成，這些伺服器（節點）配置為協同工作，以提供高度可靠的服務。這些服務可以是任何內容，從自訂應用程式到檔案共用。

在典型的HA叢集中，一個節點負責運行服務，而一個或多個節點則處於備用狀態。叢集管理軟體（例如SIOS LifeKeeper）會持續監控活動節點的運作狀況，以確保其能夠正常運作服務。

如果在主節點上偵測到嚴重故障，集群軟體它會自動協調故障轉移，將應用程式服務、IP 位址、儲存和依賴項轉移到運作正常的備用節點。透過自動化此流程，單一伺服器不再是單點故障，從而確保服務連續性，並將中斷降至最低。

消除SAN單點故障

傳統叢集通常依賴儲存區域網路 (SAN) 來提供跨節點的資料共用存取。然而，這種設計有一個關鍵的漏洞：SAN 會成為單點故障。如果共享儲存陣列發生故障，即使各個節點仍然正常運行，整個叢集也會癱瘓。

為了消除共享儲存的單點故障，管理員利用資料複製來建立「無SAN」叢集。每個節點不再依賴SAN，而是依賴自己的本地附加儲存。諸如此類的軟體SIOS 資料保管器它位於作業系統級別，並執行從活動節點儲存到備用節點儲存的連續區塊級複製。

由於資料會即時不斷複製和鏡像，備用節點始終準備好使用其本地儲存上的最新資料接管工作。

多條通訊路徑和法定人數/見證人解決方案

為了確保叢集安全運行，節點之間必須保持持續通訊以驗證彼此的狀態。它們透過交換「心跳」來實現這一點——心跳是頻繁發送的小型資料包，用於指示節點是否存活且健康。

如果備用節點停止接收心跳訊號，它可能會認為主節點已失效，並嘗試使應用程式上線。如果主節點實際上仍在運行，最終會導致兩個節點同時嘗試寫入資料——這種情況被稱為「雙節點同時寫入」。裂腦。“為避免這種情況，您應該始終為叢集配置仲裁或見證解決方案，該方案可作為決勝機制，以確定哪個節點應該安全地擁有活動工作負載。

此外，為防止網路基礎架構出現單點故障，彈性集群架構需要多條通訊路徑。透過確保節點間存在多種不同的通訊方式，可以確保單一網路交換器故障或電纜斷裂不會導致叢集邏輯中斷。

利用 SIOS 系統地尋找並消除單點故障

建立真正高可用的環境意味著要從最壞情況的角度審視您的架構。透過將 SIOS LifeKeeper 的智慧型應用監控與 SIOS DataKeeper 強大的無 SAN 複製功能結合，您可以系統地尋找並消除單點故障。

作者Trey Isaac，SIOS 資深產品支援工程師

經許可轉載SIOS

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 企業支援計畫包含哪些內容？

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

全天候支援關鍵系統停機

場景 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