23 11 月, 2022 |
Azure 上的 SAP 高可用性最佳實踐Azure 上的 SAP 高可用性最佳實踐在以下視頻中,擁有 20 年 SAP 經驗的 Microsoft 高級 SAP 架構師 Bala Anbalagan 解釋了配置高可用性以保護 Azure 中的 SAP 解決方案的最佳實踐。 他還回顧了在雲中實施 HA 解決方案時經常犯的錯誤,以及用戶在配置 SIOS LifeKeeper 時應該了解的關鍵因素。 在雲端配置 SAP 高可用性解決方案Bala 解釋說,每個 SAP 用戶都應該記住,高可用性解決方案是必不可少的,尤其是在雲端。 任何云提供商都需要對其環境進行更改。 儘管他們的硬件基礎設施服務水平很高,但也會有短暫的停機時間,這可能會使您的 SAP 系統完全崩潰。 用戶正確配置 SAP HA 也很重要。 安裝 HA 解決方案的主要目的是防止停機,但如果你沒有正確地做到這一點,你只是在浪費時間和金錢,不管你在哪個雲中運行。 必須遵循雲提供商的配置規則。 如果您錯誤地配置了 HA 或未能測試故障轉移和故障回复,它可能會在您最意想不到的時候導致業務中斷——尤其是在高利用率期間。 是什麼讓配置 SIOS 如此簡單?SIOS 有一個非常簡單的配置過程。 基本上,您只需要在每個集群節點中安裝 LifeKeeper,並根據您要恢復的應用程序使用不同類型的 SIOS 應用程序特定恢復工具包 (ARK) 模塊(LifeKeeper 隨附)。 此外,使用簡單的 GUI 可以很容易地遵循該過程 – 智能是內置的,您無需更改 GUI 的細節。 它會自動檢測大部分信息,進一步簡化設置過程。 知道要使用哪個 ARK 以及如何使用它在配置過程中很重要。 ARK 是一個軟件模塊,它為 LifeKeeper 軟件提供特定於應用程序的智能。 SIOS 為不同的應用程序提供單獨的 ARK。 例如,對於 SAP HANA,您安裝 SIOS SAP HANA 方舟使 LIfeKeeper 能夠自動執行配置步驟、檢測故障並為 SAP HANA 管理可靠的故障轉移,同時保持 SAP 的最佳實踐。 在 Azure 中為 SAP 實施 HA 的最大錯誤用戶通常實施Azure 中 SAP 解決方案的高可用性使用與在本地環境中相同的過程。 他們需要改變心態。 始終確保遵循雲提供商提供的建議,即閱讀文檔並按照雲提供商的建議保留參數。 另一個常見的錯誤是增加了太多的複雜性。 一些客戶將所有東西都放在一個集群中,但集群應該為不同的服務器分開。 使集群太大會增加不必要的複雜性和潛在風險。 當涉及到 HA 集群時,在各個方面進行徹底的測試是至關重要的。 在上線之前以及定期(和頻繁)測試 HA 配置是您可以做的最好的事情,以防止意外停機。 學習更多關於SAP 高可用性以下視頻中的最佳實踐或聯繫我們以獲取有關為雲中的基本應用程序實施高可用性和災難恢復的更多信息。 經許可轉載自信息系統
|
20 11 月, 2022 |
HA 和 DR 的簡單日子已經一去不復返了HA 和 DR 的簡單日子已經一去不復返了翻閱電視頻道,我偶然發現了電影“他只是沒那麼喜歡你”和德魯·巴里摩爾 (Drew Barrymore) 的場景,講述了我們大多數人在 2022 年對技術,尤其是高可用性和災難恢復的感受:“我懷念那些日子你有一個電話號碼和一台答錄機,那台答錄機有一盒磁帶,而那一盒磁帶要么有一個人的留言,要么沒有。 現在你只需要四處檢查所有這些不同的門戶網站,就會被七種不同的技術拒絕。 太累了。”有時,您不希望只有一個雲,甚至沒有云平台嗎?一個數據庫運行在一個操作系統上;並且只需要擔心一個前端應用程序。 但是,世界已經發生了變化,而且發展得更快,也變得更加複雜。技術的進步、併購的影響以及我們 24/7 社會日益增長的胃口和節奏,數十億消費者正在尋找最新的交易和最好的體驗,這意味著簡單的日子已經一去不復返了。 關於您的可用性的 4 個硬道理
當然,您的企業環境並不簡單。您有遺留系統和應用程序,幾乎是自打孔卡以來就存在的那種。您擁有專為新一代應用程序和數據庫打造的新系統。此外,您擁有十年前創建的解決方案以彌合差距或跨越從一個平台遷移到另一個平台的時間,但儘管您盡了最大努力,這些系統仍然存在。 除了這些挑戰之外,還有越來越多的系統和 IT 資源來自於公司 U 的併購。在新時代交付 HA 並不像您想像的那麼簡單。
作為客戶體驗副總裁,我們已經看到了不良架構造成的損害。雖然部署 HA 軟件絕對有助於提高應用程序和數據庫的可用性,但 HA 軟件永遠無法完全克服不完整的需求、糟糕的網絡、缺少冗餘硬件或其他缺少的架構組件。我們的團隊曾經與一位客戶合作,以糾正在高峰運行時間導致系統不穩定的規模過小的環境。由於他們糟糕的架構,包括網絡和硬件不穩定,他們的團隊經常發現他們自己在爭先恐後地從可避免的停機問題中恢復過來。為了擁有一個完整、健全、高可用性和彈性的解決方案,您需要部署出色的軟件作為健全架構的一部分。
開發企業級、高度可用的彈性 HA 解決方案,建立在具有增長能力的可靠架構之上,並不是一個簡單的過程。針對彈性、應用程序和數據可用性進行設計和架構並不像從貨架上拿一盒蛋糕那麼容易。投入一系列工具、來自不同團隊的流程、混合的 SLA 以及各種操作系統、應用程序、數據庫和平台,您就有了需要幫助的秘訣。 最近,我採訪了一位在企業支持環境中工作 20 年的老手。他描述了他的許多同行,有時甚至是他自己,都無法承受維護關鍵企業可用性的重擔。您的管理員不僅在凌晨 2 點起床處理災難性的多系統、多應用程序、幾乎完全崩潰的數據中心時需要幫助,而且在企業可用性的日常辛勤工作中也需要幫助技術複雜的時代。
“雖然公共雲提供商通常會在其服務水平協議中保證一定程度的可用性,但這些 SLA 僅適用於雲硬件。”雲提供商 SLA 未涵蓋應用程序停機的許多其他原因,包括:
作為客戶體驗副總裁,我們已經看到了一兩件事,包括遞歸例程中退出失敗導致的拒絕服務攻擊、系統耗盡、健康的關鍵應用程序的安全軟件隔離、內核恐慌以及隨機運行的虛擬機重啟。如果您的 HA 策略僅依賴於管理程序的 SLA,您的解決方案可能沒有您想像的那麼高可用。 您需要保護關鍵應用程序集群軟件可以監視和檢測問題,可靠地響應問題,並在必要時將操作轉移到備用服務器,以確保您的產品和服務在需要的時間和地點保持可靠和可用。 我們的單一數據中心變成了一系列的雲平台,跨越了幾十個數據中心。我們的 skunk work 應用程序已經成為我們必須跨 Windows、Linux 和一些不同的 *Nix 變種管理的關鍵前端、中間件和後端解決方案的一部分。技術的進步意味著我們的高可用性變得更加複雜,需要更好的架構。這也意味著我們的團隊需要更多幫助來管理這一切,如果我們不小心,可能意味著我們仍然容易受到攻擊和暴露。您的團隊面對的最多的是四個真相中的哪一個? 客戶體驗副總裁 Cassius Rhue 經許可轉載自信息系統 |
15 11 月, 2022 |
SIOS LifeKeeper for Windows 中的新驅動程序為您做了什麼?SIOS LifeKeeper for Windows 中的新驅動程序為您做了什麼?在未來數年加強共享和無 SAN 環境中的數據保護。可口可樂、KitKat、SalesForce 和適用於 Windows 的 SIOS LifeKeeper有共同點?這裡有一些提示:
這些公司對其標誌性產品、服務和解決方案進行了重大改進,以更好地為客戶服務,適應未來並為未來做好準備,並利用自身優勢。以類似的方式,SIOS 對我們的 SIOS LifeKeeper for Windows 產品進行了顯著改進。 在 LifeKeeper for Windows 版本 8.9.0 之前,共享存儲功能(包括 I/O 防護和驅動器識別和管理)由 NCR_LKF 驅動程序處理。從 SIOS LifeKeeper for Windows 版本 8.9.0 開始,SIOS Technology Corp. 重新設計了共享存儲驅動程序架構。 從當前版本開始,NCR_LKF 驅動程序已被刪除並由 SIOS ExtMirr 驅動程序取代,SIOS ExtMirr 驅動程序是 SIOS DataKeeper / SIOS DataKeeper Cluster Edition 的 SANless 存儲複製背後的引擎。 SIOS LifeKeeper for Windows 中 NCR_LKF 架構變化的五個顯著優勢:
ExtMirr 驅動程序提供了一個更現代的過濾器驅動程序來管理共享存儲功能。雖然 NCR_LKF 驅動程序專注於“保持燈亮”和“數據安全”,但驅動程序的體系結構落後於更現代的驅動程序。ExtMirr 驅動程序維護了數據保護,同時更兼容、更現代並且更容易在新版本的 Windows 操作系統中得到支持。
SIOS DataKeeper 和 SIOS DataKeeper Cluster Edition 中使用的驅動程序包括一個強大的防護架構。 雖然 NCR_LKF 驅動程序能夠進行 I/O 防護,但新驅動程序更加健壯並且已經在 SAN 和 SANless 環境中進行了測試。 增強的 I/O 防護利用受保護卷中的捲鎖和節點所有權信息。
利用 DataKeeper 產品中使用的 ExtMirr 驅動程序的 I/O 防護意味著 LifeKeeper for Windows 解決方案增加了與 DataKeeper 產品線的集成。ExtMirr 驅動程序還包括最新的Microsoft 驅動程序簽名並與強制執行驅動程序簽名和安全啟動的操作系統無縫協作。
ExtMirr 驅動程序為客戶和管理員提供了大量命令行實用程序,用於獲取和管理卷的狀態。emcmd 命令是兩個 SIOS DataKeeper 產品的本機命令。 它們現在可用於更輕鬆地管理 SIOS LifeKeeper 共享卷配置。 利用 LifeKeeper for Windows 產品的共享存儲和復製配置的客戶和合作夥伴現在可以了解和使用單一的命令行工具集。 emcmd 工具取代了以前的 volume.exe、volsvc 和類似的 NCR_LKF 過濾器驅動程序管理工具(鎖定、解鎖等)。
通過將 ExtMirr 驅動程序添加到適用於 Windows 的 SIOS LifeKeeper 中,共享存儲配置以及復製配置現在將在更新、新功能和修復方面得到提升。 雖然 NCR_LKF 驅動程序為 I/O fencing 提供了堅實的基礎和穩定的基礎,但切換到 ExtMirr 驅動程序意味著客戶將看到相同的強度和穩定性,並且對新產品支持的更新速度更快將兩個產品對齊到一個驅動程序可能不會與 SalesForce Classic 到 Lightning 更新一樣華麗,但它增加了重要的功能,增加了 SIOS DataKeeper 和 SIOS LifeKeeper 解決方案的強度和壽命,並將在未來幾年加強共享和無 SAN 環境中的數據保護。 客戶體驗副總裁 Cassius Rhue 經許可轉載自信息系統 |
11 11 月, 2022 |
如何重新創建文件系統和鏡像資源以確保大小信息正確如何重新創建文件系統和鏡像資源以確保大小信息正確使用高可用性 (HA) 集群時,必須確保集群中所有節點的配置相互並行。 這些“鏡像”配置有助於最大限度地減少集群上的故障點,提供更高標準的 HA 保護。 例如,我們已經看到在源節點上更新了鏡像大小但在目標節點上沒有更新相同信息的情況。 鏡像大小不匹配導致 LifeKeeper 無法在故障轉移的目標節點上啟動。 以下是在目標節點上使用與源相同的大小信息重新創建鏡像資源的推薦步驟: 腳步:
![]()
![]()
![]() 然後,為子資源標記選擇文件系統資源 (/mnt/sps)。 ![]() 這將導致兩個層次結構,一個具有 IP 資源 (VIP),一個具有文件系統資源 (/mnt/fs) 和鏡像資源 (datarep-sps)。
![]()
示例:掛載 /dev/sdb1 /mnt/sps
![]()
![]()
當資源“擴展”完成後,選擇“完成”,然後選擇“完成”。 ![]()
![]()
![]() 經許可轉載自信息系統 |
9 11 月, 2022 |
解釋切換、故障轉移和恢復之間微妙但關鍵的區別解釋切換、故障轉移和恢復之間微妙但關鍵的區別高可用性是一個專長,與大多數專長一樣,它有自己的詞彙和術語。 我們的客戶通常對 IT 非常了解,但如果他們沒有在 HA 環境中工作,我們的一些常見 HA 術語可能會給他們和我們造成相當大的混亂。 它們聽起來很簡單,但在 HA 的上下文中具有非常具體的含義。這裡討論了其中三個術語——切換、故障轉移和恢復。 什麼是切換?切換是一種用戶發起的通過行動高可用性(HA) 集群解決方案用戶界面或 CLI。 在切換中,用戶手動啟動更改受保護應用程序的源或主服務器的操作。 在典型的切換場景中,所有正在運行的應用程序和依賴項都按順序停止,從父應用程序開始,到所有子/依賴項都停止時結束。 一旦應用程序及其依賴關係停止,它們就會在新指定的主服務器或源服務器上以有序的方式重新啟動。 例如,如果您有資源 Alpha、Beta 和 Gamma。 資源 Alpha 取決於資源 Beta 和 Gamma。 資源 Beta 取決於資源 Gamma。在切換事件中,首先停止資源 Alpha,然後是 Beta,最後是 Gamma。一旦所有三個都停止,切換將繼續使資源在預期服務器上進入操作狀態。該過程從資源 Gamma 開始,然後是 Beta,最後是資源 Alpha 的啟動操作完成。 關鍵要點:如果沒有失敗導致該動作,那麼它是一個切換 什麼是故障轉移?故障轉移操作通常是響應服務器崩潰或意外/計劃外重新啟動的非用戶啟動操作。 考慮具有兩個節點(節點 A 和節點 B)的 HA 集群的場景。在這種情況下,所有關鍵應用程序 Alpha、Beta 和 Gamma 都在節點 A 上啟動並運行。 在這種情況下,當節點 A 遇到意外/計劃外的重新啟動、斷電、停止或恐慌時,就會發生故障轉移。 一旦 HA 軟件檢測到節點 A 在集群中不再正常運行並且在操作上可用(由解決方案定義),它將觸發故障轉移操作以恢復對可用集群節點上的關鍵應用程序、資源、服務和依賴項的訪問, 在這種情況下是節點 B。在故障轉移場景中,由於節點 A 經歷了崩潰(或其他模擬的即時故障),因此節點 A 上沒有進程可以停止,因此一旦處理了適當的檢測和隔離操作,節點 B 將立即開始恢復過程資源。 與切換情況一樣,該過程從資源 Gamma 開始,然後是 Beta,最後是資源 Alpha 的啟動操作完成。 傳統上,故障轉移操作比切換需要的時間更少。 這是因為處理一個故障轉移不需要在前一個主(運行中或活動)節點上停止(或靜默)任何資源。 ![]() 關鍵要點:發生故障轉移以響應系統故障。 什麼是恢復?恢復事件很容易與故障轉移混淆。 當進程、服務器、通信路徑、磁盤甚至集群資源發生故障並且高可用性軟件響應於識別的故障而運行時,就會發生恢復事件。 大多數 HA 軟件解決方案能夠以多種方式處理恢復事件。 最突出的方法包括:
由於恢復策略的多種變化,很容易看到類似於切換行為的恢復事件。 在方法 1 和 5 中經常出現這種情況。 在這些場景中,應用程序和服務在遠程節點上啟動之前以有序的方式優雅地停止。 方法 2 和 3,客戶經常會看到類似於故障轉移的行為。 在方法 2 和 3 中,主服務器由 HA 軟件重新啟動或隔離,這會創建類似於故障轉移的可觀察行為。方法 4 通常是一個很少使用的選項,但它混合了切換和故障轉移。方法 4 從正常停止應用程序和服務開始,然後重新啟動應用程序和服務(很像切換)。 但是,如果應用程序和服務的本地重新啟動失敗,系統將重新啟動(很像故障轉移),但實際上不會失敗到遠程集群節點。 雖然很少見,但通常在存在不平衡集群的情況下調用方法 4,或者與基於策略的方法一起使用。 關鍵要點:恢復事件取決於選擇的方法 供應商之間的 HA 術語是一個常見術語可以具有不同含義的領域。 當您使用企業應用程序部署和維護集群解決方案時,請確保您了解解決方案提供商關於故障轉移、切換和恢復的條款。而且,當你在做的時候,確保你知道餐廳會把醬汁放在一邊(放在碟子裡),還是放在一邊(你的土豆泥) 經許可轉載西歐 |