網絡研討會：無需企業版即可在 AWS 上實現具有災難恢復能力的 SQL Server

註冊點播網絡研討會

您知道有幾個因素會影響您的工作負載性能、成本和可用性嗎？在雲中運行 SQL Server 工作負載時，沒有一種放之四海而皆準的方法，您可能不需要升級。參加本次會議，了解在優化 AWS 上的數據庫性能的同時擴展您的 IT 預算資金的策略。

經許可轉載自信息系統

 

更好地維護高可用性集群需要考慮的十個問題

維護是每個公司生命週期的一部分。每個基礎設施都在不斷移動和變化，即使是那些正在走向生命終結的基礎設施。您的團隊可能在您過去所做的事情上取得了很大的成功，但隨著系統變得越來越複雜，您過去認為成功的事情可能需要更新。這裡有十個問題需要改進集群維護, 最大化高可用性，並最大限度地減少停機時間。

系統維​​護時如何保證高可用

1. 業務利益相關者最好的日子是什麼時候？

與計劃外停機不同，這些是多個團隊、系統和互連資源根本無法用於計劃活動的窗口。例如，一家公司需要每月進行系統合規性檢查和安全檢查。在此期間，業務運營被檢查員、審計員等關閉。

2. 團隊安排維護的最佳日期是什麼時候？

作為客戶體驗副總裁，我們與許多對某些事件和活動有限制日期的團隊密切合作。您的團隊可能負責不止一組系統和服務器，並向具有關鍵應用程序和基礎架構的多個團隊報告。了解哪些日子最適合團隊可以幫助您避免分心、衝突和由於已知資源限製而浪費的時間。

3. 什麼日期和時間最適合合作夥伴、顧問和非公司承包商？

關鍵基礎設施通常包括許多與公司人員配置沒有直接關係的其他供應商和供應商。這些資源包括操作系統、安全和 HA 供應商和顧問，以及來自基礎架構提供商和其他合作夥伴的架構師。提前了解哪些日子最好或包含在您的支持層中對於正確安排和人員配備至關重要。

隨著全球團隊的增加，為所有這些資源找到合適的時間是另一個需要回答的重要問題。EST、IST、EMEA 和其他地區的資源最佳時間是什麼時候？

4. 維護的預期範圍是什麼？維護活動的預期結果是什麼？整體思考。

超越對應用程序的簡單維護，考慮包括它運行的整個環境。最近，一位計劃升級其應用程序的客戶決定同時升級其操作系統。不幸的是，這種範圍上的微小變化帶來了比預期更大的後果。他們的應用程序不支持新升級的操作系統，問題接踵而至。確保明確定義維護窗口的範圍，並詳細說明該範圍的結果。僅僅說環境有效是不夠的。盡可能詳細說明預期版本、行為和可衡量的結果。查看更多關於IT 彈性。

5. 維護窗口的時間長度是多少（預期的，允許的）？

理想情況下，我們都希望有所有的時間來執行維護，但客戶遍布世界各地意味著對計劃停機時間的容忍度很小——即使是關鍵任務也是如此。當您計劃維護時，預計停機時間有多長？你真的能滿足最大允許窗口嗎？如果不是，那麼您將需要重新計劃維護事件。

6. 回滾計劃是什麼？

雖然我們希望沒有任何問題，但我們應該意識到我們正在處理軟件、複雜的環境和配置，以及由許多團隊處理的許多移動部分。回滾計劃——即將系統恢復到維護前的版本和設置的方法——是必不可少的。確保如果出現問題，您有回滾計劃，例如完整備份或機器映像。查看更多關於災難恢復.

7. 所涉及的各個團隊成員是誰，他們的角色和職責是什麼？是否明確定義了所有必需的角色和職責？

作為客戶體驗副總裁，我們的團隊參與了一項維護活動，由於關鍵團隊成員失踪，該活動遇到了無法預料的延誤。在製定計劃和架構時，請務必確定團隊成員以及所需的 IT 角色和職責。正如高級支持工程師 Greg Tucker 提醒客戶的那樣，HA 涉及環境的每一層，包括存儲、網絡、計算、操作系統、安全、策略等。

8. 維護計劃記錄在哪裡？最後一次審查、更新和測試計劃是什麼時候？

成功是美好的，但它也會讓你沾沾自喜或自得其樂。經過多年的成功，您的過程可能不再被詳細記錄或被積極遵循。回答這些問題可以確保您的團隊繼續取得成功。

9. 在生產計劃之前的測試/QA 中解決了哪些問題？

感謝您繼續測試維護步驟。確保將在測試環境中解決的問題正確添加到生產維護計劃中。SIOS 客戶成功團隊已經看到客戶執行 QA 測試、發現錯誤假設並進行必要的更正，但未能將這些更正放入他們的生產清單中。

10. 您的計劃中缺少誰或缺少什麼？

既然您已經查看了計劃、時間安排、團隊、角色和架構，最後一個問題仍然存在：缺少誰或缺少什麼？作為最後一步，查看您的計劃並提出以下問題：“我們的計劃中缺少誰？” 另外，考慮問“我們的計劃中缺少什麼？” 作為客戶體驗副總裁，我與我們的團隊一起審查了無數客戶的活動計劃。最令人難忘的維護計劃審查之一揭示了回滾計劃中的一系列步驟，包括從克隆圖像和備份數據恢復服務器。但是，映像克隆和數據備份步驟並未包含在任務列表中。他們被忽視了，並被認為是在流程的早期完成的。

系統維​​護是保持高可用性的關鍵要素

系統維​​護是維護計算機系統的關鍵和必要部分。維護可以是糾正錯誤、引入新的軟件功能或使系統適應新的用例。當所討論的系統是對組織保持業務連續性至關重要的業務關鍵系統時，制定一個深思熟慮的計劃是必不可少的。考慮這十個問題和您自己的其他問題，以確保您的維護滿足業務需求，而不會出現不必要的風險或延誤。

聯繫 SIOS今天介紹高可用性和災難恢復解決方案。

經許可轉載自信息系統

視頻：HANA 多目標功能演示

適用於 Linux 的 SIOS LifeKeeper 的 HANA 應用程序恢復套件 (ARK) 提供 HANA 特定的智能以及手動配置和管理任務的自動化，從而節省時間並消除人為錯誤的風險。 SIOS LifeKeeper 在配置期間自動驗證用戶輸入，並自動執行監控、故障轉移和復制管理，以提供符合 SAP 最佳實踐的可靠故障轉移。

經許可轉載自信息系統

我們將 HANA Multitarget 打造成為遊戲規則的改變者

代表創建新的 SIOS 工程團隊HANA 多目標SIOS LifeKeeper for Linux v. 中的功能 9.7.0，我們為我們的成就感到自豪和興奮。 在我們開始實施之前，一個經驗豐富的軟件開發團隊花了幾個月的時間進行規劃。 我們研究了許多客戶用例、技術要求和不可能的相互依賴列表，以創建既獨特又強大的功能。

工程師對 HANA 多目標功能的看法

HANA 集群環境本質上是複雜的。 這就是為什麼想要使用競爭集群軟件將第三個節點添加到他們的 HANA 集群的客戶必須使用一些非常複雜的腳本，並在發生故障轉移或故障恢復時繼續編寫對集群的任何更改的腳本。 對於這些產品，發生故障轉移後，您必須執行大量手動驗證步驟以確保可以執行接管。 與那些產品不同，LifeKeeper 9.7.0 可以訪問有關集群中所有 HANA 節點的詳細信息，從而使其成為一個更加穩定和可靠的 HA 環境。 例如，它可以確定哪些節點可用並能夠進行接管，還可以查看發生故障轉移後是否有數據丟失。 這非常重要，尤其是在多個節點發生故障時。

在多節點環境中可靠地管理故障轉移和復制的複雜性隨著每個節點的增加呈指數級增長。 例如，集群軟件將如何選擇故障轉移到哪個節點？ 數據存儲在三個幾乎相同的位置，哪個存儲位置最新且最準確？ 您如何防止不同節點上的數據出現分歧的“裂腦”場景？ 如果兩個節點發生故障，故障轉移和復制步驟應該是什麼？ 三？ 我們面臨著思考故障場景的各種組合併確保 SIOS 在每個場景中維護數據保護和可靠故障轉移的挑戰。

救生員比競爭產品更深入地監控環境，並且對管理故障轉移有嚴格的要求。 新的 9.7.0 版本的 LifeKeeper 增強了跟踪 HSR 層次結構的能力，並管理複雜的三節點和四節點 HSR 集群的故障轉移，以確保它們快速且高度可靠。

我們著手為 HANA 創建業界最自動化和最可靠的多目標集群環境，我相信我們成功了。

為什麼 HANA Multitaget 提供最可靠的集群環境

• 我們在嚴格測試上投入的時間與在開發上投入的時間一樣多，以確保系統盡可能地可預測和穩定。
  我們消除了驚人數量的手動步驟。 與其他集群軟件無可比擬。 SIOS LifeKeeper 是迄今為止最自動化和最可靠的多目標集群解決方案。
• 在研究和開發方面投入了大量精力。 在確定最終實施之前，該團隊研究了多個設計選項。
• 在我們開發並測試了第三個節點功能後，我們繼續努力支持第四個 DR 節點，為我們的客戶提供更加可靠和穩定的災難恢復。
• 整個團隊確實盡可能認真地對待測試，並在開發過程中不斷測試 HANA 故障轉移和恢復過程。
• 我們的文檔團隊還努力創建有關 LifeKeeper 控制的 HANA 多目標系統的實施、操作和管理的詳細、易於使用的文檔。

我們相信新的 LifeKeeper HANA Multitarget 會改變遊戲規則，為客戶提供業內最自動化、最可靠的故障轉移集群解決方案。觀看演示的新功能以查看其功能。

聯繫 SIOS今天了解有關 LifeKeeper 的 HANA 多目標功能的更多信息。

經許可轉載自信息系統

永遠在線應用程序的基本需求

從關鍵任務到日常運營

在當今“永遠在線”的世界中，技術在組織的效率和競爭力方面發揮著至關重要的作用。 一些應用程序被歸類為“關鍵任務”，表明它們對組織的核心運營至關重要。 這些應用程序需要高可靠性和可用性，因為任何停機或故障都會產生重大後果。 此外，日常業務運營中使用的日常應用程序對於組織的成功至關重要。 因此，保證高可用性所有關鍵應用程序的可靠性至關重要。 在這篇博客中，我們將深入探討為什麼始終在線的應用程序在當今快節奏和競爭激烈的商業環境中至關重要。 此外，我們將探索組織可以做些什麼來確保他們的應用程序具有高可用性和可靠性。

客戶和員工期望 24/7 應用程序可用性

首先，客戶和員工希望應用程序能夠從任何設備和任何位置全天候 24/7 可用。 在當今的數字時代，應用程序停機或性能低下會導致收入損失、聲譽受損，甚至客戶流失。 例如，考慮一個電子商務網站在關鍵銷售期間遇到停機。 客戶可能會變得沮喪並放棄他們的購物車，從而導致收入損失並可能損害公司的聲譽。 同樣，如果員工無法訪問基本應用程序，他們可能無法完成工作，從而導致生產力下降並可能影響組織的整體成功。

此外，隨著越來越多的組織將其運營轉移到雲端，確保應用程序的可用性和可靠性變得更加重要。 在雲環境中，諸如 ERP 之類的複雜系統可能跨多個服務器、數據中心甚至地理區域運行。 這種複雜性使快速識別和解決問題變得更具挑戰性，因此組織必須擁有強大的監控和警報系統，以確保他們能夠迅速響應出現的任何問題。

組織如何確保應用程序始終在線

那麼，組織可以做些什麼來確保他們的應用程序始終在線？ 一種方法是實施穩健的災難恢復包括冗餘系統和故障轉移機制的計劃。 這種方法有助於確保如果一個組件出現故障，另一個組件可以無縫接管，而不會導致停機或中斷。 組織還必須投資於必要的基礎架構和工具，以持續監控其應用程序並在問題變得嚴重之前主動解決任何問題。

此外，組織可以利用自動化等技術來提高其應用程序的可用性和可靠性。 例如，自動化日常任務有助於降低人為錯誤的風險，並在問題變得嚴重之前快速解決問題。

無論它們是否是關鍵任務，確保應用程序可用且可靠以保持生產力、效率和客戶滿意度至關重要。 組織需要投資於必要的基礎架構、工具和流程，以確保其應用程序具有高可用性和可靠性。 他們還應該準備好迅速採取行動，以應對可能出現的任何問題。 最終，始終在線的應用程序方法是組織在當今快節奏和競爭激烈的商業環境中取得成功的關鍵因素。

經許可轉載自信息系統