了解業務關鍵型應用程序高可用性的複雜性

最大限度地減少系統、數據庫和應用程序的停機時間是最大限度提高生產力的關鍵。 現代組織依靠關鍵業務系統、數據庫和應用程序（例如企業資源規劃 (ERP)、客戶關係管理 (CRM)、電子商務、財務系統和供應鏈管理）來高效運營並提供卓越的客戶體驗. 當系統、數據庫或應用程序出現故障時，高可用性保護會恢復操作以保持業務正常運行。

什麼是高可用性？

高可用性是系統、數據庫或應用程序的一個屬性，旨在長時間連續可靠地運行。 高可用性的目標是通過合併冗餘組件和其他技術來解決系統、數據庫或應用程序中的單點故障，從而減少或消除關鍵應用程序的計劃內和計劃外停機時間。

簡單地說，高可用性確保您的系統、數據庫或應用程序按預期運行：“何時”是指系統、數據庫或應用程序必須按預期啟動和運行的時間百分比——這意味著應用程序按用戶期望和滿足的方式運行及時滿足他們的需求。

數據中心模型

高可用性服務級別協議 (SLA) 有助於確保 IT 基礎架構的關鍵組件在工作時間內正常運行和可用。 IDC 為高可用性創建了一個 SLA 模型，該模型定義了具有以下正常運行時間要求的五個級別： • AL4（持續可用性——系統容錯）：無用戶中斷，每年計劃內和計劃外停機時間總計最多不超過 5 分 15 秒（99.999% 或“五個九”可用性）。
• AL3（高可用性——傳統集群）：最少的用戶中斷和每年最多不超過 52 分 35 秒的計劃內和計劃外停機時間（99.99% 或“四個九”可用性）。
• AL2（恢復——數據複製和備份）：一些用戶中斷和每年最多不超過 8 小時 45 分 56 秒的計劃內和計劃外停機時間（99.9% 或“三個九”的可用性）。
• AL1（可靠性——熱插拔組件）：所有服務停止，每年總計 87 小時 39 分 29 秒的計劃內和計劃外停機時間（99% 或“兩個九”的可用性）。
• AL0（未受保護的服務器）：所有服務停止，並且未定義正常運行時間 SLA。

您的高可用性要求取決於整個系統、應用程序和許多其他因素的重要性，包括： • 應用程序對業務有多重要 • 客戶是否注意到影響 • 應用程序運行的頻率 • 有多少用戶受到停機影響 • 數據庫或應用程序必須以多快的速度故障轉移到冗餘系統以避免中斷 • 有多少數據損失是可以容忍的 五個九的可用性通常是為需要連續“有狀態”操作的應用程序保留的。 對於業務關鍵型應用程序，四個九的可用性是標準的。 非關鍵系統和應用程序，您可能只需要兩個九的可用性。 在確定可接受的停機時間時，重要的是要考慮： • 計劃外停機時間（即硬件或軟件故障） • 例行硬件和軟件維護的計劃停機時間 • 應用程序和數據庫級別的正常運行時間 各種高可用性解決方案可以幫助企業實現其 SLA 目標針對不同的系統、數據庫和應用程序。 儘管持續可用性 (AL4) 似乎是關鍵業務部署的最合適目標，但在成本和可用性之間找到適當的平衡點很重要。 連續可用性還會對計劃維護所需的停機時間產生負面影響，因為在應用應用程序或操作系統更新時系統通常必須脫機，而高可用性通常允許滾動更新。

高可用性指標：RTO 與 RPO

除了正常運行時間和可用性之外，恢復時間目標 (RTO) 和恢復點目標 (RPO) 是用於評估系統、數據庫或應用程序中的高可用性（以及災難恢復）的重要指標。

反收購行動是任何中斷的最大可容忍持續時間。 在線事務處理應用程序通常具有最低的 RTO，而那些業務關鍵型應用程序的 RTO 通常只有幾秒鐘。

RPO是發生故障時可以容忍的最大數據丟失量。 對於災難恢復，應用程序及其相關數據的典型 RPO 可能是 24 小時。 每晚備份可確保在發生災難時可以恢復過去 24 小時內對數據所做的任何更改。 但是，對於高可用性應用程序和數據，RPO 通常為零。 也就是說，在任何故障情況下都不應該有數據丟失。

傳統聚類

高可用性集群是一組服務器節點（和其他組件），它們支持需要最少停機時間的關鍵業務應用程序。集群軟件允許您將服務器配置為集群，以便多個服務器可以協同工作以提供高可用性並防止數據丟失。 IT 組織依靠高可用性集群來消除單點故障並將停機和數據丟失的風險降至最低。

傳統的本地高可用性集群是一組連接到共享存儲（通常是存儲區域網絡或 SAN）的兩個或多個服務器節點，這些節點配置有相同的操作系統、數據庫和應用程序（參見圖 1） ).

其中一個節點被指定為主要（或活動）節點，其他節點被指定為次要（或備用）節點。 如果主節點發生故障，集群允許系統、數據庫或應用程序的操作自動故障轉移到一個或多個輔助節點，並繼續正常運行，中斷最少。 由於輔助節點連接到同一存儲，因此操作繼續進行，數據丟失為零。 這種集群架構的好處是減少停機時間、消除數據丟失和保護數據完整性。

但是，有很多場景不需要共享存儲。 共享存儲中的故障將使所有集群脫機，從而產生單點故障 (SPoF) 風險。 SAN 存儲的擁有和管理成本高昂且複雜。 最後，在雲中使用共享存儲會顯著增加不必要的成本和復雜性。 有些雲根本不提供共享存儲選項。

如圖所示圖 2, SANless 或“無共享”集群是共享存儲的最佳替代方案。 在這些配置中，每個集群節點都有自己的本地存儲。 高效的基於主機的塊級複製用於同步集群節點上的存儲，使它們保持相同。 在發生故障轉移時，輔助節點訪問主節點使用的存儲的相同副本。 這種集群架構的優勢在於消除 SPoF、消除 SAN 成本和復雜性、在雲中易於使用和節省成本、減少停機時間並減少數據丟失。

設計原則

最先進的高可用性集群包含以下設計原則： • 當一個活動組件發生故障時，它們會自動快速地故障轉移到冗餘系統 • 它們在故障轉移期間和之後保持特定於應用程序的最佳實踐 • 它們提供手動切換和切回的能力，以實現高效測試和“滾動”維護，且成本最低計劃內停機 • 它們可以自動檢測網絡、存儲、操作系統、硬件或應用程序中的故障 • 它們可以防止在系統發生故障時丟失數據 • 它們可以跨不同地理位置的節點進行故障轉移以實現災難恢復

高可用性集群

各種集群軟件解決方案可用於 Windows、Linux 發行版和各種管理程序（虛擬機解決方案）。 一組僅支持一個操作系統，例如： • Windows 服務器故障轉移群集 (WSFC)：為 Microsoft SQL Server 和 Microsoft Exchange 等託管應用程序提供高可用性和災難恢復 • SUSE Linux Enterprise 高可用性擴展 (HAE)：支持物理和虛擬 Linux 服務器的集群，具有策略驅動的集群和連續數據複製• 紅帽起搏器（Pacemaker）：為性能、高可用性、負載平衡和可伸縮性創建單站點集群 例如，這裡列出的解決方案都不能保護在 Oracle Linux 操作系統上運行的 SAP。 因此，每個解決方案都會限制您的靈活性和部署選項。 更先進高可用性解決方案，例如適用於 Linux 的 SIOS Protection Suite，在主要 Linux 發行版（包括 Oracle Linux、Red Hat 和 SUSE）中提供應用程序感知保護。

此外，每個應用程序、數據庫和 ERP 系統都有自己的配置和持續管理要求。 為了滿足這些要求，HAE 和 Pacemaker 通常需要高度的技術技能和復雜的手動腳本，這會引入人為錯誤和不可靠的故障轉移的可能性。

通常受故障轉移集群保護的關鍵業務應用程序、數據庫和 ERP 系統的一些示例包括 SAP S/4HANA、SQL Server 和其他應用程序和數據庫。

SAP S/4HANA多家 Linux 供應商在其“Enterprise for SAP”訂閱中為 SAP 提供開源高可用性擴展。 SAP S/4HANA 環境包含多項服務，例如 ABAP SAP 中央服務 (ASCS)、評估收據結算 (ERS) 和其他 SAP 組件，這些服務需要在正確的位置進行維護並以正確的順序啟動。 在 SUSE HAE 和 Red Hat Pacemaker 等開源集群產品中，在這些複雜環境中手動配置和管理集群可能非常耗時，而且容易出現人為錯誤，從而增加災難性停機和數據丟失的風險。

創建應用程序感知的高可用性解決方案還需要在應用程序和數據庫方面具有特定的深厚專業知識。 相比之下，適用於 Linux 的 SIOS 保護套件包括用於 SAP 和 HANA 的應用程序恢復工具包，可確保故障轉移保持應用程序最佳實踐。

SAP 還提供 HANA 系統複製，這是 HANA 軟件附帶的一項功能。 它可以將 SAP HANA 數據庫持續同步到同一數據中心、遠程站點或云中的輔助位置。 數據被複製到輔助站點並預加載到內存中。 發生故障時，備站點接管，無需重啟數據庫，有助於降低RTO。 但是，必須手動觸發到主節點的故障恢復。 HSR 需要與應用感知集群軟件（如 SIOS Protection Suite）搭配使用，後者可以檢測故障並在必要時協調故障轉移。

數據庫服務器

許多公司依靠 SQL Server 作為支持重要業務功能的關鍵應用程序的後端數據庫。 Microsoft WSFC 通常用於支持 SQL Server 應用程序的 Always On 可用性組 (AG) 和 SQL Server 故障轉移群集實例 (FCI)。

但是，帶有 AG 的 WSFC 需要昂貴的 SQL Server 企業版許可。 此外，使用 FCI 時，整個實例將故障轉移到備用節點。 使用 AG，只有組中的數據庫受到保護。
使用SIOS 數據管理員WSFC 允許您使用具有成本效益的標準版許可為 SQL Server 提供高級高可用性保護。

其他應用程序和數據庫

SIOS 軟件可用於保護各種關鍵業務應用程序、數據庫和 ERP，包括 Oracle、MaxDB、MySQL、PostgreSQL 和 DB2。 SIOS 軟件支持集群和災難恢復。

在我們的下一篇博客中，我們將研究特定的行業用例，以幫助您了解不同的企業如何為其關鍵任務應用程序實現高可用性。

經許可轉載自信息系統

Epicure 使用 Amazon EC2 和 SIOS SANLess 集群軟件保護關鍵業務 SQL Server

SIOS DataKeeper Cluster Edition 軟件提供高可用性和災難保護。

Epicure 是加拿大領先的直銷公司，通過 16,000 多名顧問組成的網絡銷售健康、易於準備的食品。 該公司依靠兩個網站進行關鍵業務運營。 他們的公共網站向其客戶和有興趣成為顧問的人提供公司和產品信息、食譜、博客和註冊信息。 他們的內部網站為顧問提供有關產品的重要信息，並使他們能夠下達所有訂單。 “我們的網站對我們的業務至關重要，”Epicure 高級網絡基礎設施管理員 Russell Born 說。

環境

Epicure 的兩個網站都在使用兩個 SQL Server Standard Edition 實例的單個服務器上運行——每個網站一個。 隨著公司擴展其產品和服務，Epicure IT 部門需要更新並確保其兩個關鍵業務網站在發生故障或災難時繼續運行。 他們決定將這兩個網站從第三方託管設施遷移到其本地數據中心，並使用 Amazon Web Services EC2 雲進行災難恢復。 “通過將網站引入內部，我們可以確保我們的網站在業務持續增長的同時為我們的客戶和顧問提供出色的用戶體驗，”Born 說。

挑戰

作為此網站更新過程的一部分，Epicure IT 人員希望以一種高效、經濟的方式為兩個網站提供高可用性和災難保護，同時繼續在 SQL Server Standard Edition 的兩個實例上運行它們。

“如果我們可以為 HA 和 DR 提供更具成本效益的標準版，我們不希望因遷移到 SQL Server 企業版而增加費用，”Born 說。

解決方案

使用 SIOS DataKeeper Cluster Edition 軟件，Epicure IT 人員在主動-被動故障轉移配置中創建了一個雙節點 SANLess 集群，使每個 SQL 實例能夠獨立進行故障轉移。 一個集群節點位於 Epicure 本地數據中心，第二個節點位於 AWS EC2 雲實例中。 Epicure IT 人員創建了 SIOS SANLess 集群，並使用該軟件直觀的圖形用戶界面對其進行了配置。

結果

SIOS 軟件為 Epicure 提供了一種簡單、經濟高效的方式來為其關鍵業務 SQL Server 應用程序提供 HA 和 DR 保護，而無需構建遠程 DR 站點或購買昂貴的 SAN 存儲或 SQL Server Enterprise Edition 許可證的成本和復雜性. “SIOS 軟件使我們能夠創建一個混合解決方案，既可以節省本地運行的成本，又可以提供在雲中運行的可靠性和靈活性，”Born 說。 “因為我們知道，如果出現網站中斷，它會自動進行故障轉移，我們的 IT 團隊現在可以將注意力集中在其他優先事項上，以加強我們的業務。”

經許可轉載自信息系統

SIOS DataKeeper 集群軟件使 Gulliver International 能夠將內部 IT 系統安全地遷移到 Amazon Web Services

SIOS 軟件在 AWS 環境中提供高可用性，使領先的二手車公司能夠將所有 IT 系統遷移到雲端。

Gulliver International 是一家領先的二手車公司，總部位於東京，在日本各地擁有 420 家門店。 在接下來的四年裡，該公司計劃擴展到全球業務，在全球擁有 1600 家門店。 為確保其 IT 基礎設施能夠適應這種快速增長，該公司正在將其所有內部系統遷移到 AWS，並在全公司範圍內推廣針對所有新應用程序的“雲優先”政策。

Gulliver International 的 IT 經理月島學 (Manabu Tsukishima) 表示：“將我們的系統遷移到雲端將為我們提供快速和經濟高效增長所需的靈活性和可擴展性，同時持續為我們的客戶提供優質服務。”

挑戰

為了確保他們的雲優先計劃取得成功，Gulliver 需要保護他們的關鍵業務應用程序在雲環境中免受停機，而傳統的故障轉移集群是不可能的。

“如果沒有高效、易於實施的高可用性解決方案，我們不會考慮將我們的應用程序遷移到雲端，”Tsukishima 說。 Gulliver 選擇使用 SIOS DataKeeper 軟件，該軟件由 SIOS Technology, Inc. 在日本銷售。

解決方案

SIOS DataKeeper 軟件使 Gulliver 能夠使用 Windows Server 故障轉移集群 (WSFC) 在雲環境中構建故障轉移集群，而傳統的共享存儲集群是不可能的。

SIOS 軟件使用高效、實時的複制來同步在 AWS 環境中作為 WSFC 集群運行的服務器之間的存儲。

使用 SIOS 軟件，Gulliver 可以將兩台服務器配置為跨不同的 Amazon 可用區作為集群運行。

就像在傳統的物理環境中一樣，如果一個可用區內的AWS雲中的主服務器發生故障，WSFC將應用程序移動到位於另一個亞馬遜可用區的第二台服務器上，提供完全的雲容災和恢復.

結果

“我們對 SIOS DataKeeper 軟件為我們公司的雲優先計劃帶來的價值感到非常高興，”Tsukishima 說。 借助 SIOS DataKeeper 軟件，Gulliver 可以遷移到雲端，而不會增加現有操作的複雜性或中斷。

“通過使我們能夠以與在物理環境中相同的方式在雲中使用集群配置，SIOS DataKeeper 軟件使我們能夠遷移到 AWS，而不會犧牲應用程序保護或完全改變我們現有系統的配置。 ” Gulliver 大約 30% 的現有本地系統已遷移到 AWS，而沒有對公司的系統管理進行任何更改或增加複雜性。

隨著 Gulliver 繼續執行其擴展計劃，它很快將需要保護更大量的數據和更廣泛的應用程序。 為了滿足這一需求，它將在將系統遷移到雲端時繼續使用 SIOS DataKeeper 軟件。 作為 APN（AWS 合作夥伴網絡）的標準諮詢合作夥伴，SIOS 致力於繼續提供在 AWS 上運行的高可用性系統。”

經許可轉載自信息系統

在 AWS 中創建 HA Oracle 數據庫服務器集群

介紹作為一名負責為需要 Oracle 高可用性 (HA) 實例的關鍵業務應用程序創建 POC 的開發人員，我需要在 AWS EC2 中設置一個 Oracle EC2 HA 集群。你從哪裡開始？如果您像我們大多數人一樣，您將花費無盡的時間在谷歌上搜索您的下一個任務、閱讀文章、安裝指南、文檔和關於堆棧溢出的問題。 您會發現很多幾乎正確的答案，但它們永遠不會完全適合您的版本或環境。 更糟糕的是，您掉進了一個兔子洞，最終浪費了數天時間來構建一個無法正常工作的環境。

我將構建一系列博客，這些博客專注於設置 HA 環境以使用各種SIOS HA 解決方案例如：DataKeeper、LifeKeeper 和 SIOS Protection Suite。 如果您有我尚未涵蓋的即時需求，請告訴我，我會將您的配置移到我的待辦事項列表中。

謝謝您閱讀此篇。我希望它能讓你的生活更輕鬆。 我在下面有一個任務列表，如果您已經熟悉如何完成這些任務，您可以直接完成這些任務。 下面是執行每項任務的分步指南。

AWS HA Oracle 數據庫 SIOS Protection Suite for Linux

1. 在 Linux 上啟動 2 個 Oracle 實例
2. 讓 Xwindows 工作
3. 連接到實例並安裝額外的磁盤
4. 安裝 AWS 命令行工具包
5. 配置安全/訪問
6. 為虛擬 IP 創建路由條目
7. 禁用 ENI 的源/目標檢查
8. 編輯/etc/hosts
9. 使用 VIP 主機名配置偵聽器
10. 禁用 SELinux
11. 安裝適用於 Linux 的 SIOS 保護套件
12. 啟動 LifeKeeper
13. 連接到第二台服務器
14. 建立溝通路徑
15. 創建 DataKeeper 資源
16. 使用虛擬 IP 資源創建層次結構
17. 創建 Oracle 偵聽器資源
18. 使用 Oracle 數據庫創建層次結構
19. 使用 EC2 創建層次結構
20. 更改關機行為
21. 測試故障轉移

1. 在 Linux 上啟動 2 個 Oracle 實例

在第一篇博客中，我們將使用 SIOS LifeKeeper for Linux 在 AWS 中為 Oracle 集群設置 HA 環境。這意味著排除所有先決條件。 我將在 Oracle Linux 8 AMI 上使用 aws-marketplace/Oracle 數據庫 19.8.0 企業版。這些經常變化，很難找到適合您需要的正確的。這個 AMI 是我的第 3 次嘗試，因為由於存儲庫、許可、註冊和安全問題，在雲中安裝任何東西，尤其是 Oracle 之類的東西都非常困難。這個 AMI 實際上可以工作，因為 Oracle 已經安裝在映像上。確保操作系統版本和 Oracle DB 版本受 SIOS 支持。可以檢查這裡.

我的實例有：

21. 單一專有網絡
22. 單一區域
23. 每個服務器的不同可用區
24. 用於數據庫存儲的附加驅動器
25. 2 不同子網中每個實例的網絡接口
26. 創建 2 個彈性 IP 地址並為每個服務器附加一個

我將一個額外的磁盤附加到數據庫實例，並為冗餘通信路徑附加一個 NIC。確保兩個 NIC 位於不同的子網上。這也意味著您必須手動創建和分配彈性 IP 地址才能連接到實例。

連接到實例並安裝附加磁盤。 我正在使用 Putty 和 Xming 連接我的實例。如果使用 Xming，請確保在嘗試建立連接之前運行 Xlaunch。

啟動實例後，您需要對新磁盤進行分區。最容易找到[ ls /dev/disk/by-path ]:

現在你需要分區磁盤磁盤:

接下來在新分區上創建文件系統mkfs.xfs :

我們現在將掛載文件系統山:

最後，我們將在 fstab 中添加自動掛載磁盤的條目：

請務必注意，您不需要為 Oracle 運行安裝。AMI 已經做到了這一點，並為您創建了一個數據庫。我刪除了使用此 AMI 預先配置的數據庫，並使用 DBCA 在 /data 磁盤上創建了一個新數據庫。我啟動了數據庫並創建了一個模式並使用 SQLPLUS 添加了數據。這一切都需要您讓 Xwindows 正常工作。

2. 讓 Xwindows 工作

可以使用 Xming for Windows 設置使用 Putty 的 Xdisplay。先安裝Xming。然後確保開啟了X11轉發，在x顯示位置輸入localhost:0.0，在x權限文件中輸入路徑和xming.exe可執行文件進行本地顯示：

這解決了 Windows 方面的問題，但您仍然需要修復 Linux 方面。首先編輯 /etc/ssh/sshd_config 並取消註釋“X11Forwarding yes”。接下來是查找正確的密鑰並將其添加到 Xauthority。如果您進行了任何用戶切換，您可能必須開始一個新會話。以 ec2-user 身份登錄後運行xauth列表這將為您提供您需要添加到 Xauthority 文件中的十六進制密鑰。切換到oracle用戶：蘇 – 甲骨文。然後運行xauth 添加 $DISPLAY 。 <從 xauth 列表複製的 hexkey> 。這會將信息存儲到 /home/oracle/.Xauthority 文件中。出口回到 ec2-user。

3.連接到實例並掛載額外的磁盤

我正在使用 Putty 和 Xming 連接我的實例。如果使用 Xming，請確保在嘗試建立連接之前運行 Xlaunch。

啟動實例後，您需要對新磁盤進行分區。最容易找到[ ls /dev/disk/by-path ]:

現在你需要分區磁盤磁盤:

接下來我們在新分區上創建文件系統mkfs.xfs :

此時我們想將 /u01 重命名為 /oracle 目錄，以便我們可以將新文件系統掛載到 /u01 上，這是我們使用 AMI 構建的服務器上 Oracle 所在的位置。

使用 mkdir /u01 創建安裝點並使用 mount 安裝卷。使用 mv /oracle /u01 將文件移動到新磁盤。這將需要一些時間，因為它大約是 11GB 的數據。

最後，我們將在 fstab 中添加自動掛載磁盤的條目：

請務必注意，您不需要為 Oracle 運行安裝。AMI 已經做到了這一點，並為您創建了一個數據庫。我啟動了數據庫，創建了一個模式，並使用 SQLPLUS 添加了數據。

4. 安裝 AWS cli 工具包

我們需要 awscli 套件；所以，當我們是 root 下載文件時捲曲“https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip”-o“awscliv2.zip”

解壓文件解壓 awscliv2.zip

安裝應用程序須藤./aws/安裝

接下來通過單擊控制台右上角的帳戶在 AWS 中設置訪問密鑰，然後選擇安全憑證

單擊創建訪問密鑰：

然後單擊下載 .csv 文件：

將此文件傳輸到您的服務器上，並使用您的 csv 文件中的密鑰 ID 和訪問密鑰配置 AWS aws配置命令：

測試它是否正在使用類似的東西： aws –no-paginate –no-cli-pager ec2 描述實例

5.配置安全/訪問

首先，我將 Oracle 用戶添加到 root 和 wheel 組，賦予它偽特權（ Usermod -aG wheel oracle) .這將使 Oracle 帳戶成為 lkadmin 帳戶，使生活變得輕鬆。我將 sps.img 和許可證文件下載到兩台服務器上。

在安裝軟件之前，還需要完成一些先決條件步驟。首先為服務器配置安全組，使它們可以通過開放TCP端口5900-59010進行通信。同時打開 TCP 端口 81 和 82。 還要確保端口已為虛擬 IP 打開。

6.為虛擬IP創建路由條目

路由表需要更新才能使集群的虛擬 IP 正常工作。在此多子網集群配置中，虛擬 IP 需要位於分配給您的 VPC 的 CIDR 範圍之外。定義一個新路由，將流量定向到集群的虛擬 IP (172.30.0.101) 到主集群節點 (Oracle1) 從 VPC 儀表板中，選擇路由表，單擊編輯。添加“172.30.0.101/32”的路由，目標是主服務器上的主彈性網絡接口 (ENI)：

7. 禁用 ENI 的源/目標檢查

在 Network Interfaces 下，一次選擇一個接口，然後在 Actions 下選擇 change source/dest。

只要您沒有收到身份驗證錯誤，就說明它已正確安裝和配置。

取消勾選使能夠盒子：

對所有接口重複。

8.編輯/etc/hosts

除非您已經設置了 DNS 服務器，否則您需要在兩台服務器上創建主機文件條目，以便它們可以正確地按名稱相互解析。

9. 使用 VIP 主機名配置監聽器

編輯或創建 $ORACLE_HOME/network/admin/listener.ora 文件以指向 oracle-vip：

10. 禁用 SELinux

編輯 /etc/sysconfig/selinux 文件並設置“SELINUX=disabled”

重新啟動服務器。如果此時服務器沒有恢復，則可能是您將 SELINUX 設置保留為允許並將 SELINUXTYPE 設置為禁用，這將使實例變磚。只需取消 AWS 中的捲與您的實例的關聯並將其掛載到mount -o rw, nouuid {設備} {掛載目錄}命令到新的或現有的工作實例。編輯/{掛載目錄]/etc/sysconfig/selinux文件，修改錯誤。保存文件，卸載並取消卷與此實例的關聯，然後將其重新附加到舊實例。

11. 為 Linux 安裝 SIOS 保護套件

接下來，我以 root 身份通過安裝映像文件來安裝 SIOS 保護套件mount /home/ec2-user/sps.img /mnt/ -t iso9660 -o loop . 運行安裝程序/mnt/設置:

在 LifeKeeper 身份驗證下，我向下滾動到 lkadmin 組，按回車鍵並將 oracle 添加到“lkadmin”組：

選擇“確定”，然後選擇“完成”並按回車鍵。下一步滾動到安裝許可證密鑰文件並按回車鍵：

從這裡輸入您的許可證文件的位置和名稱：

接下來，我選擇 Recovery Kit Selection Menu 並按下回車鍵：

這裡我選擇網絡：

按空格鍵選擇 LifeKeeper Recovery Kit for EC2。 Tab 到 Done 並回車。接下來我選擇數據庫菜單，向下滾動並在 LifeKeeper Oracle RDBMS 恢復工具包上點擊空格鍵：

Tab 到 Done 或按 D 並向下滾動到 Storage 並按 Enter。接下來我按下空格鍵並選擇 DataKeeper for Linux：

Tab 到 Done 並按回車鍵或按 d 退出恢復工具包選擇，然後按 Tab 鍵到 Done 或按 D 退出 Main Configuration 菜單：

確保 LifeKeeper Startup After Install 被選中，然後最後一個選項卡完成或點擊 d，我們會看到安裝確認屏幕：

在這裡按 enter 或 y，安裝將開始。

12.啟動LifeKeeper

使用以下命令啟動 LifeKeeper GUI /opt/LifeKeeper/bin/lkGUIapp如果失敗，可能是因為您沒有登錄 .Xauthority 文件的帳戶的幻數。我以 oracle 身份登錄，然後做了一個須藤-我紮根。因此，如果我的 gui 未加載，我會將 /home/oracle/.Xauthority 文件複製到 /root ：

在這裡我以 oracle 身份登錄：

13.連接到第二個服務器

然後單擊 Cluster Connect 按鈕

以 oracle 身份登錄：

14.建立溝通渠道

單擊“創建通信路徑”按鈕：

如果出現故障，請確保禁用防火牆和 iptables。下一步：

下一步：

選擇您的第一個 IP 地址並點擊下一步：

選擇遠程IP：

下一步：

點擊創建：

下一步：

現在點擊完成：接下來我們需要通過使用輔助地址重複步驟 14 來創建第二個通信路徑。

成功建立兩條路徑後，服務器應變為綠色。

15. 創建 DataKeeper 資源

單擊“創建資源層次結構”按鈕：

選擇數據複製並點擊下一步：

點擊下一步（智能意味著在故障轉移後您需要手動故障回复）：

下一步：

選擇您的主服務器並點擊下一步：

選擇複製現有文件系統並點擊下一步：

選擇現有的掛載點並點擊下一步：

創建一個數據複製資源標籤並點擊下一步：

選擇一個文件系統資源標籤並點擊下一步：[1]

為獲得最佳性能，位圖文件應放置在臨時卷上。 出於測試目的，可以將位圖放置在 OS 磁盤上，如上所示。 選擇位圖文件位置並點擊下一步：

為啟用異步複製選擇否，然後單擊下一步：

選擇目標服務器並點擊下一步：

選擇 Switchback 類型並點擊下一步：

選擇模板優先級並點擊下一步：

選擇目標優先級並點擊下一步：

下一步：

選擇目標磁盤並點擊下一步：

下一步：

下一步：

選擇要用於復制的網絡端點並點擊下一步：

選擇掛載點，點擊下一步：

選擇資源標籤並點擊下一步：

點擊完成：

點擊完成：

如果您單擊 /u01，您將看到音量同步：

16. 使用虛擬 IP 資源創建層次結構

單擊創建資源按鈕：

選擇IP並點擊下一步：

選擇 Switchback 類型並點擊下一步：

選擇主服務器並點擊下一步：

輸入第 6 步中的虛擬 IP 地址，然後點擊下一步：

輸入 VIP 的子網掩碼並點擊下一步：

進入網絡界面，點擊下一步

輸入資源標籤並點擊下一步：

創建成功後點擊下一步：

選擇目標服務器並點擊下一步：

選擇 switchback 類型並點擊下一步：

選擇優先級並點擊下一步：

選擇優先級並點擊下一步：

完成後點擊下一步：

下一步：

選擇適當的網絡掩碼並點擊下一步：

選擇接口並點擊下一步：

選擇資源標籤並點擊擴展：

成功完成後點擊完成：

驗證後點擊完成。

17. 創建 Oracle Listener 資源

在嘗試在 LifeKeeper 中配置這些資源之前，請確保數據庫和偵聽器正在運行。單擊創建資源按鈕：

選擇 Oracle Database Listener 並點擊下一步：

選擇主服務器並點擊下一步：

輸入監聽器配置文件路徑和文件名，然後點擊下一步：

下一步：

輸入偵聽器可執行文件的路徑並點擊下一步：

選擇保護級別並點擊下一步：

選擇恢復級別並點擊下一步：

如果需要，選擇與偵聽器關聯的 IP 地址，然後點擊下一步：

輸入偵聽器標籤名稱並點擊創建：

下一步：

點擊接受默認值以在第二台服務器上構建資源：

點擊完成：

單擊完成並展開 LSNR 和 /u01：

18. 使用 Oracle 數據庫創建層次結構

單擊“創建資源層次結構”按鈕：

選擇 Oracle 數據庫並點擊下一步：

選擇 Switchback 類型並點擊下一步：

選擇服務器並點擊下一步：

選擇數據庫名稱並點擊下一步（如果出現無法找到主目錄的錯誤，請確保數據庫正在運行）：

輸入 sysdba 用戶名並點擊下一步：

輸入該帳戶的密碼，然後點擊下一步：

選擇 Oracle 監聽器並點擊下一步：

點擊創建：

創建成功後選擇下一步：

選擇接受默認值：

選擇完成：

點擊完成：擴展樹以查看所有資源：

19. 使用 EC2 創建層次結構

單擊“創建資源層次結構”按鈕：

選擇 Amazon EC2 並點擊 Next>

選擇智能並點擊下一步>

選擇您的主服務器並點擊 Next>

選擇 EC2 資源類型（我們在此示例中使用後端集群）並點擊 Next>

選擇 IP 資源並選擇 Next>

選擇 EC2 資源標籤名稱並點擊創建

成功創建資源後，點擊 Next> 幾秒鐘後，預擴展嚮導將彈出。點擊接受默認值：

檢查成功完成後，再次點擊接受默認值：

點擊完成，驗證後點擊完成：

配置完成。現在我們可以測試故障轉移。

20. 改變關機行為

默認情況下，LifeKeeper 不會故障轉移如果您只是關閉或重新啟動服務器，則資源不足。 如果您想在關閉服務器之前移動工作負載，您應該在關閉活動節點之前手動將資源移動到備用服務器。 但是，您可能希望更改默認行為以方便測試。 這是通過更改關機策略來控制的，如下所示。

右鍵單擊您的主服務器並選擇屬性：

在 General 選項卡下，將 Shutdown Strategy 更改為 Switchover Resources，然後點擊 Apply：

接下來從服務器下拉菜單中選擇輔助服務器並驗證設置更改：點擊確定：

21. 測試故障轉移

我正在從輔助服務器運行 lkGUIapp。如果您在主服務器上，退出 LifeKeeper GUI 並從輔助服務器運行它。

展開所有資源層次結構並打開與主服務器的 SSH 會話。

我也在運行 ping -i 5 到 oracle-vip：

關閉主服務器：

在我的案例中，您可以看到 IP 停止響應的時間 < 25 秒。我以 5 秒的間隔錯過了 4 次 20-23 次。現在一切都在備份服務器上處於活動狀態。因為我們的主節點仍然關閉，所以我們在層次結構上收到警告。

如果您將切回切換為智能，一旦啟動主服務器，您將必須手動在主服務器上啟動該服務。在嘗試將其投入使用之前，請確保主服務器處於 InSync 狀態：

右鍵單擊 cdb1 的 StandBy 按鈕並選擇 In Service…

點擊服務

點擊完成。

磁盤重新同步需要幾分鐘時間，但最終會完成。

恢復所有內容後，我們現在在 AWS 中擁有一個可用於開發的高可用性 Oracle 數據庫。

經許可轉載自信息系統

領先的飲料製造商保護 AWS EC2 雲中的關鍵 SAP ERP

SIOS 基於對 SAP、Amazon Web Services 和 Red Hat Linux 的認證和驗證而被選中

一家領先的香港飲料製造商生產 61 個飲料品牌，包括世界第一的軟飲料品牌，並向香港、中國大陸、台灣和美國西部的超過 7.28 億客戶分銷。

環境

該公司依靠在 Red Hat Linux 環境中運行的 SAP ERP（企業資源規劃）系統來管理各種關鍵業務運營。 SAP 環境包含各種服務，包括 ABAP（高級業務應用程序編程）、SAP 中央服務 (ASCS)、評估收據結算、Web 調度程序和 DB2 數據庫。 他們使用大型存儲區域網絡 (SAN) 進行數據存儲。 核心 SAP 應用程序處理公司飲料部門的所有業務運營。 在他們的本地數據中心，該公司使用 SAN 的數據複製和備份為該系統提供正常運行時間保護。

挑戰

公司的 IT 部門確定他們可以通過遷移到雲並使用故障轉移集群來保護他們的關鍵 SAP 系統，從而實現真正的高可用性（99.99% 的正常運行時間）、災難恢復、可擴展性和成本節約。 然而，他們意識到傳統故障轉移集群所需的 SAN 和其他共享存儲在某些雲中並不實用，在其他雲中也不可用。

評估

經過廣泛評估後，該公司選擇將他們的 SAP 環境遷移到 Amazon EC2。 他們建立了四個關鍵標準來評估他們對 HA/DR 解決方案的選擇。 他們的解決方案需要：

• 獲得與 SAP、AWS 和 Red Hat 一起使用的認證和驗證
• 提供高可用性和高性能
• 防止所有可能的故障情況
• 實現輕鬆的持續操作和維護

該公司的雲客戶經理建議他們考慮通過 AWS 中國提供的 SIOS Protection Suite。 SIOS 軟件已通過 SAP 的 NetWeaver 和 DB2 認證，並且 SIOS 在 Red Hat Enterprise 和其他 Linux 發行版上經過了全面測試和支持。 該公司在各種具有挑戰性的故障場景下對 SIOS 集群軟件進行了廣泛測試，並評估了高峰需求期間的吞吐量性能。 IT 團隊對 SIOS Protection Suite 的信心增加了，因為它通過了他們的每一項嚴格測試並被證明非常易於使用。

解決方案

適用於 Linux 的 SIOS Protection Suite 支持 SANless 故障轉移集群，為 SAP 及其關鍵服務提供完整的 HA 和 DR。 SIOS 軟件獨特地包括稱為應用程序恢復套件 (ARK) 的模塊，這些模塊提供特定於應用程序的功能，可簡化配置並確保故障轉移編排保持應用程序最佳實踐。 SAP 和 HANA ARK 可自動執行配置步驟並驗證配置輸入並管理 IP 故障轉移和啟動順序以最大限度地減少人為錯誤。 與僅驗證服務器可操作性的其他集群軟件不同，SIOS 集群軟件驗證 SAP 和關鍵服務是否正在運行、數據庫是否已安裝且可用、任何文件共享或導出是否可用以及客戶端是否能夠連接。 為確保這些服務都正常運行，SIOS 軟件持續監控服務器、虛擬機、操作系統和 SAP 軟件的所有主要組件。 為了容災保護，公司將主備集群節點分佈在不同的AWS可用區，實現地域隔離。

結果

SIOS Protection Suite 使這家領先的飲料製造商能夠滿足為其 SAP/DB2 環境制定的嚴格恢復時間和恢復點目標。 迄今為止，該配置沒有出現明顯的停機時間，包括在計劃維護期間。 而且這些結果是用最少的努力實現的，使 IT 員工可以更多地關注提高員工生產力或以其他方式改善業務運營的項目。

經許可轉載自信息系統