確保訪問關鍵教育應用程式

教育和資訊科技 (IT) 越來越密不可分。所討論的 IT 是否是支援課堂白板的應用程式、支援大學註冊系統的資料庫、學習管理系統 (LMS)，還是控制學生進入實驗室、宿舍和餐廳的建築維護系統（如果是關鍵組件）如果您的IT 基礎設施突然陷入癱瘓，教師、管理員和學生都無法完成他們應該完成的任務。該機構的使命被中斷。如果中斷太頻繁，如果學生、教師和管理人員的經驗受到影響，機構本身的聲譽也會受到影響。

IT 基礎架構旨在確保對教育體驗至關重要的應用程式的高可用性 (HA)，可以最大限度地降低這些系統因任何原因變得無回應時可能發生的中斷和聲譽損失的風險。在這種情況下，HA 基礎設施被定義為能夠確保關鍵應用程式在不低於 99.99% 的時間內可用性的基礎設施。換句話說，這意味著您的關鍵應用程式每月不會意外離線超過四分鐘。

如何實現 HA？這個問題很容易回答，但這並不是您需要問的唯一問題。同樣重要的是：哪些應用程式非常重要以至於需要 HA 配置？從本質上講，為HA 配置的IT 基礎架構具有一組或多組輔助伺服器和儲存子系統，這些伺服器和儲存子系統位於不同的地理位置（如果您的主伺服器駐留在本地或單獨的可用性中，則可以是遠端資料中心）區域 [AZ]（如果您的伺服器駐留在雲端）。如果某些原因導致主伺服器上執行的應用程式停止回應，管理應用程式的 HA 軟體會立即將應用程式故障轉移到輔助伺服器，您的關鍵應用程式將從主伺服器停止回應的位置再次啟動。根據您計劃複製的主伺服器的大小和效能特徵，輔助伺服器可能會很昂貴，因此您不太可能為 HA 配置所有學術應用程式。一旦確定哪些應用程式值得對 HA 進行投資，您就會知道需要在哪裡建立 HA 環境。

實現高可用性的選擇

一旦您選擇了要保護的應用程序，您實現 HA 的選項就會變得更加清晰。它們在 Windows 還是 Linux 上運作？您的資料庫管理系統 (DBMS) 是否內建對 HA 配置的支援？如果是這樣，它的限制是什麼？例如，如果您的關鍵應用程式在 Windows 和 SQL Server 上執行，您可以使用 SQL Server 本身的可用性群組 (AG) 功能來啟用 HA。或者，您可以使用第三方 SANless 叢集工具來設定 HA，該工具提供 SQL Server 中的 AG 服務不提供的選項。如果您試圖保護來自多個供應商的資料庫伺服器，或者如果您的某些關鍵應用程式在Windows 上運行而其他應用程式在Linux 上運行，則使用支援多個DBMS 和作業系統的HA 解決方案將有助於您管理HA 的能力平台。與同時處理多個資料庫本機 HA 服務的潛在複雜性和繁瑣相比，選擇適應不同 DBMS 和作業系統平台的叢集解決方案可以簡化管理。

透過資料庫本機 HA 解決方案確保高可用性

如果您使用資料庫本機 HA 解決方案（例如 SQL Server 的 AG 功能），該軟體會將主 SQL Server 資料庫中的所有資料同步複製到輔助系統伺服器上該資料庫的相同執行個體。如果某些原因導致主伺服器停止回應，AG 元件中的監控功能將自動導致輔助伺服器接手。由於AG功能即時複製了所有數據，因此輔助伺服器可以立即接管，幾乎不會出現服務中斷或資料遺失的情況。

許多資料庫本機 HA 工具都以類似的方式運作。不過，在考慮資料庫本機方法時，有一些注意事項：如果 HA 服務捆綁到 DBMS 本身中，它們可能只會複製與該 DBMS 關聯的資料。如果其他關鍵資料駐留在主伺服器上，則在資料庫本機 HA 場景中，這些資料不會複製到輔助伺服器。資料庫本機服務複製的內容可能還有其他限制。例如，如果您使用捆綁到 SQL Server 標準版中的基本 AG 功能，則每個 AG 只能將單一 SQL 資料庫複製到單一輔助位置。如果您的應用程式涉及多個 SQL 資料庫，您可以建立多個基本 AG，但您無法控制在故障轉移情況下每個 AG 是否同時進行故障轉移，否則可能會出現問題。解決此限制的一種方法是使用捆綁到SQL Server Enterprise Edition 中的Always On AG 功能，該功能可以將多個SQL 資料庫複製到多個輔助伺服器，但如果您的應用程式不這樣做，請從授權角度來看，這可能會變得非常昂貴否則，請使用 SQL Server Enterprise Edition 的任何功能。

其他資料庫本機 HA 解決方案可能有類似的限制，因此在投資這種方法之前一定要了解它們。

透過 SANless 叢集確保高可用性

作為資料庫本機 HA 方法的替代方法，您可以使用第三方工具建立 SANless 叢集。如上述 AG 配置一樣，SANless 叢集軟體會自動將資料從主伺服器同步複製到輔助伺服器；如果主伺服器無回應，它還會安排立即故障轉移到輔助伺服器。由於故障轉移只需幾秒鐘，管理員、教師和學生對關鍵應用程式的存取幾乎不會中斷。

SANless 叢集和資料庫本機方法之間的關鍵差異在於實際細節。SANless 叢集方法與資料庫無關。它複製指定儲存卷上的任何資料。這可能包括來自多個供應商的多個資料庫、文字檔案、視訊檔案或任何其他可用性很重要的教育資產。如果資料庫本機 HA 方法需要升級到更昂貴的資料庫版本，這可以為機構節省大量資金。最後，如前所述，如果您試圖保護在多個操作環境中執行的應用程式和數據，SANless 叢集方法可能比單一資料庫本機方法更易於管理。您可以使用 SANless 叢集來確保 Windows 或 Linux 環境中的高可用性，這可以消除因操作環境而異的資料庫本機方法部署所帶來的複雜性。

經許可轉載安全作業系統

網路研討會：雲端中的災難復原：了解 SQL Server 的挑戰和策略

註冊參加點播網路研討會

確保雲端中的高可用性 (HA) 和災難復原 (DR) 對許多組織來說可能是一個挑戰。與雲端中 HA/DR 相關的挑戰包括利用不同雲端供應商的各種工具的複雜性、資料主權考量、合規性挑戰以及持續的成本管理。

本次網路研討會將討論應對這些挑戰的方法，強調冗餘和故障轉移對於不間斷服務和資料保護的重要性，並探討有關雲端彈性的常見誤解以及強大的備份和災難復原策略的必要性。

經許可轉載安全作業系統

使用 SIOS LifeKeeper 在 AWS 中透過 HANA 3 節點 HSR 叢集建置高可用性

簡介：如何確保資料庫的 HA 和 DR

在 AWS 中建立高度可用的 SAP HANA 環境是許多企業的關鍵任務。本指南提供了使用以下命令設定 3 節點 HANA 系統複製 (HSR) 叢集的詳細演練：SIOS 生命守護者在AWS中，確保資料庫彈性和高可用性。

先決條件

• 能夠部署 EC2 執行個體的 AWS 帳戶。
• SIOS LifeKeeper 軟體
• SIOS LifeKeeper 評估或永久許可證
• SAP HANA 軟體
• 熟悉 AWS 服務和 SAP HANA。

步驟 1：準備您的 AWS 環境

EC2執行個體部署

在 AWS 中部署三個 EC2 執行個體。這些實例將充當 HANA 叢集的主節點、輔助節點和第三節點。確保它們符合 SAP HANA 和 SIOS LifeKeeper 的硬體和軟體要求。確保在建置實例時遵循 SAP HANA 大小調整指南。

網路設定

配置您的 VPC、子網路和安全群組，以允許節點之間進行通訊並允許存取必要的服務。

在不同區域配置 HANA 節點時，您可以使用 SIOS LifeKeeper for Linux Route53 應用程式復原套件或 ARK 保護 DNS 名稱。以下是 AWS 中 3 節點 HANA 資料庫的架構：

設定儲存時，請為 /usr/sap、/hana/data、/hana/log 和 /hana/shared 使用單獨的 EBS 磁碟區。

我們有 2 個 VPC，每個區域一個。我們需要在 VPC 之間設定對等互連，並將路由新增至路由表中，以確保伺服器可以相互通訊。我們還需要修改安全群組以允許伺服器之間的流量。

最後，我們需要建立一個包含兩個 VPC 的託管區域，並新增用於與活動 HANA 節點通訊的網域和主機名稱的記錄。

步驟 2：安裝並設定 SAP HANA

每個節點上的安裝

在每個 EC2 執行個體上安裝 SAP HANA。確保所有節點的版本一致，以避免相容性問題。這是迄今為止最具挑戰性的過程。

首先確定您的安裝設定。對於我來說，我使用以下內容：

SID：D11

• HANA實例數量：11
• Route53 中的 HANA 資料庫 FQDN：saphana.sapdemo
• Node1 主機名稱：sapdemohana1
• 節點2主機名稱：sapdemohana2
• Node3 主機名稱：sapdemohana3
• 例型：r5.4xlarge

本地實例儲存：

• 30GB /（根卷）
• 15GB/usr/sap
• 60GB /hana/共享*
• 200GB /hana/數據
• 200GB /hana/日誌

*對於此安裝，這些 HANA 資料庫伺服器之間未共用儲存。如果您嘗試使用共用存儲，您將無法建立相同的伺服器，因為 hdblcm 將阻止安裝並出現有關 SID 和實例已存在的錯誤。

在每個節點上獨立安裝 HANA 伺服器軟體，就好像它是一個獨立系統一樣。確保安裝了所有必需的庫，對於 RHEL 8，它們位於 SAP note 2772999 中。您需要確保在安裝 compact-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm 後創建符號鏈接通過運行： ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6

• yum install xorg-x11-server-Xorg xorg-x11-xauth -y #for LifeKeeper GUI
• yum 安裝 nfs-utils

建立分割區、格式化儲存並附加它。建立您的交換文件。

我在所有主機上建立 RSA 金鑰，然後透過將公鑰新增至 .ssh/authorized_keys 檔案來允許 root ssh 在 hana 節點之間登入。這將使安裝變得更加容易。

裝載 HANA 安裝媒體磁碟區。

• yum localinstall compat-sap-c++-10-10.2.1-11.el7_9.x86_64.rpm
• yum localinstall compat-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm
• mkdir /usr/sap/lib
• ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6
• 百勝安裝 compat-sap-c++-10 libatomic -y

從正確的 hana 安裝媒體目錄運行 hdblcm。在所有節點上成功安裝 HANA 後，您就可以開始下一步了。

系統複製設定

您需要在啟用 HSR 之前進行備份：

• su – <SID>adm [即。蘇-d11adm]
• hdbsql -i <實例編號>adm -u system -p <密碼> [即。hdbsql -i 11 -u系統-p「密碼123」]
• 使用檔案備份資料(‘/usr/sap/<SID>/HDB<實例編號>’) [即。使用檔案備份資料(‘/usr/sap/D11/HDB11’)

在所有節點上重複上述備份過程。

在每個節點上配置 HANA 系統複製：

在主 HANA 系統上啟動 HDB 實例（如果尚未執行）： sapcontrol -nr <實例編號> -function StartSystem HDB [即：sapcontrol -nr 11 -function StartSystem HDB]

在主站啟動 HSR： hdbnsutil -sr_enable –name=<主站台名稱> [即。hdbnsutil -sr_enable –name=sapdemohana1

停止輔助 HANA 系統上的 HDB 實例： sapcontrol -nr <實例編號> -function StopSystem HDB [即。sapcontrol -nr 11 -function StopSystem HDB]

在其他 HANA 系統中，備份 KEY 和 DAT 檔案並將主 KEY 和 DAT 檔案複製到所需位置：

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>。 DAT.BAK [即。mv /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT.BAK]

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>. KEY.BAK [即。mv /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY.BAK]

• scp root@<主節點>:/usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/資料/SSFS_<SID>.DAT [即。scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT]

• scp root@<主節點>:/usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/ key/SSFS_<SID>.KEY [即。scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY]

確保金鑰和 dat 檔案的擁有者是 <SID>adm sapsys：

• [root@sapdemohana2 ~]# ls -l /usr/sap/D11/SYS/global/security/rsecssfs/data/
• 總計 12
• -rw-r–r– 1 d11adm sapsys 2960 年 1 月 3 日 22:19 SSFS_D11.DAT
• -rw-r–r– 1 d11adm sapsys 2960 年 1 月 3 日 22:15 SSFS_D11.DAT.BAK

將附加 HANA 系統註冊到主 HANA 系統 – 必須以管理員使用者身分完成：

• hdbnsutil -sr_register –name=<輔助 HSR 名稱> –remoteHost=<SAP HANA 系統的主主機名稱> –remoteInstance=<遠端實例編號> –operationMode=<delta_datashipping | 日誌重播 | logreplay_readaccess> –replicationMode=<同步 | 同步記憶體 | 異步>

[IE。hdbnsutil -sr_register –name=sapdemohana2 –remoteHost=sapdemohana1 –remoteInstance=11 –operationMode=logreplay –replicationMode=sync]

檢查所有系統上的 HSR 狀態，以管理員使用者身分執行以下命令： d11adm@sapdemohana4:/usr/sap/D11/HDB11>hdbnsutil -sr_state

一旦所有系統都在線，您就可以進入下一步。

步驟 3：安裝 SIOS LifeKeeper

AWS CLI 安裝

安裝 AWS CLI 並使用具有以下權限的金鑰對其進行配置：

路由表（後端）配置：

• ec2:描述路由表
• ec2:替換路由
• ec2:描述網路介面屬性
• ec2:修改網路介面屬性
• 彈性IP（前端）配置：
• ec2:描述地址
• ec2:關聯地址
• ec2:解除關聯位址

LifeKeeper安裝

在每個節點上安裝 SIOS LifeKeeper。這涉及運行安裝腳本並遵循安裝嚮導，該嚮導將指導您完成必要的步驟。對於此安裝，我使用網路、Route53 ARK 和資料庫、SAP HANA ARK 以及見證功能。

編輯 /etc/selinux/config 檔案並停用 selinux：

我還更改了主機名稱並編輯了 /etc/hosts 檔案。最後編輯 /etc/default/LifeKeeper 檔案並將 /usr/local/bin 加入到 PATH 中：

更改 NOBCASTPING=1：

我還將 QUORUM_LOSS_ACTION 更改為 osu：

確保 Xwindows 可以工作。我從.bashrc 中刪除cp 別名，並將/opt/LifeKeeper/bin 和/usr/local/bin 加入到我的.bash_profile 中，並將ec2-users .Xauthority 檔案複製到root 和<SID>adm 主目錄，以便Xwindows將工作：

我更改 root 密碼並重新啟動。在啟動 LifeKeeper GUI 之前。確保 HSR 在所有節點上都在線並且所有節點都已註冊：

配置

啟動 LifeKeeper GUI：lkGUIapp 並使用 root 使用者和密碼登入：

點選連線按鈕登入叢集中的其他節點：

登入所有節點後，按一下「建立通訊路徑」按鈕：

當它要求本地伺服器時點擊下一步，然後按住 Shift 並選擇所有節點：

點擊“接受預設值”並在完成後點擊“完成”。再次點擊「建立通訊路徑」按鈕，這次更改為第二個節點：

點擊下一步並選擇第三個節點：

按一下“下一步”按鈕，直到您可以按一下“接受預設值”按鈕。當完成擊中完成。現在點選「建立資源層次結構」按鈕：

選擇 IP 套件並點擊下一步：

點擊下一步，直到到達 IP 資源頁面。這裡輸入 0.0.0.0 並點選下一步：

點擊下一步，直到到達“創建”按鈕。點擊建立按鈕：

完成後點選下一步：點選接受預設值，目標伺服器顯示第二個節點：

完成後點擊下一個伺服器：

點擊“接受預設值”，顯示第三個節點，完成後點擊“完成”：

命中完成：

現在我們有了一個 IP 資源，我們可以新增 Route53 資源，這將更改 dns 條目以將 FQDN 解析為活動節點 IP 位址。在這種情況下，saphana.sapdemo 將解析為 sapdemohana1 的 IP 位址 (172.31.0.25)。點擊「建立資源層次結構」按鈕開始這個過程：

選擇 Route53 並點選下一步：

繼續點擊下一步，直到到達網域。它應該預先填入活動託管區域名稱。點擊下一步。

輸入所有內容將用於連接 HANA 資料庫的主機名，然後點擊下一步：

點擊下一步，直到到達建立按鈕，然後點擊建立按鈕。完成後點選下一步：

在預擴展精靈中點選接受預設值：

完成後點擊下一個伺服器：

目標伺服器將顯示第三個節點。點擊接受預設值：

完成後點選“完成”。然後點選“完成”。然後您可以展開樹。開啟與第二個節點的終端會話並 ping HANA 資料庫的 FQDN [即。ping -c3 saphana.sapdemo]

右鍵單擊 sapdemohana3 下的頂部 Standby，然後選擇 In Service：

在下一個畫面上點選“服務中”，然後在完成後點選“完成”：

轉到終端機視窗並重複 ping 測試：

您可以看到主機名稱現在解析為 sapdemohana3。在繼續下一步之前，將 sapdemohana1 重新投入使用。

步驟 4：將 SAP HANA 與 SIOS LifeKeeper 集成

資源層次結構創建

使用 LifeKeeper GUI，在每個節點上為 SAP HANA 建立資源層次結構。此設定對於管理故障轉移和復原過程至關重要。確保 HSR 在節點 1 上處於活動狀態並且其他節點已註冊：

點選建立資源按鈕：

選擇 SAP HANA 復原工具包並點選下一步，直到到達 IP 位址畫面：

選擇無並點選下一步：

點擊下一步，直到到達「建立」畫面並點擊「建立」：

建立後點選下一步，然後接受節點2的預設值：

當node2完成後，再次點選「Next Server」並接受預設值：

完成後點選“完成”，然後點選“完成”：

右鍵點選 Hana Hierarchy 並選擇 Create Dependency：

對於子資源標籤，從下拉清單中選擇route53資源，然後點選下一步：

按一下建立依賴項：

按一下“完成”。然後選擇查看展開樹：

如果一切都是綠色的，我們就準備好測試了。

第 5 步：測試和驗證

故障轉移/切換測試

進行徹底的故障切換測試，確保在主節點發生故障時系統能夠正確切換到輔助或第三節點。此測試應包括網路故障、硬體問題和軟體崩潰等場景。

我們將執行的第一個測試是切換，用於執行維護活動或計劃停機。右鍵點選第二個節點並選擇 In Service – Takeover with Handshake…

點選執行接管：

此測試將切換到第二個節點，以最大限度地減少使用者的停機時間。當第二個節點啟動並運行時，點擊完成：

一段時間後，節點 1 將恢復待機狀態 – 同步。

現在我們可以執行故障轉移測試。開啟節點 2 的終端並輸入 echo c > /proc/sysrq-trigger 以模擬系統崩潰。您將看到節點 1 接管，因為它具有最高優先權 1：

最終，一切都會恢復正常：

您可能想要測試許多其他類型的故障場景。只需在開始測試之前確保備用節點同步即可。

資料同步驗證

驗證資料是否在所有節點之間正確複製。節點間資料的一致性對於 HSR 設定的完整性至關重要。

效能監控

定期監控 SAP HANA 實例和 LifeKeeper 設定的效能。檢查是否有任何可能表明潛在問題的異常或問題。檢查 /var/log/lifekeeper.log 檔案以確保一切都按預期執行。您可能需要根據網路效能調整心跳定時器和心跳失去次數。這些可以在 /etc/default/LifeKeeper 檔案中配置。可調參數為 LCMHBEATTIME 和 LCMNUMHBEATS。您也可以使用指令 lcdstatus -q 從命令列檢查 Lifekeeper 的狀態。

結論

使用 SIOS LifeKeeper 在 AWS 中設定 3 節點 HANA HSR 叢集涉及詳細的規劃和執行。透過仔細遵循這些步驟，您可以在雲端建立強大、有彈性且高度可用的 SAP HANA 環境，確保您的關鍵資料保持可存取且安全。適用於 Linux 的 SIOS LifeKeeper 讓 SAP HANA 的管理、監控和維護變得快速、輕鬆。

SIOS提供資源和訓練對於我們所有的產品。

經許可轉載安全作業系統

 

美國國家首都地區利用 SIOS DataKeeper 保護關鍵緊急調度服務

SIOS DataKeeper 保護 Azure SQL Server 上的關鍵 CAD-EX CAD2CAD 軟體

直到最近，調度員還使用電腦輔助調度 (CAD) 系統來推測鄰近轄區單位的可能位置和可用性，但要請求調度，他們必須透過專用電話線致電鄰近機構，以驗證單位的實際位置和可用性。此過程減慢了回應時間，並且無法讓急救人員存取調度機構可能提供的關鍵事件詳細資訊。

為了提高效率，NCR 機構領導層和新興數位概念(EDC) 合作創建了資料交換中心(DEH)，這是一個資料交換和功能互通性平台，旨在為NCR 緊急服務機構成員提供對資料和應用程序的安全存取。他們使用國家資訊交換模型 (NIEM) 來確保系統、通訊和程序的互通性。

DEH已成為全國緊急應變高效區域合作的典範。確保國家首都地區高效的緊急調度服務 SIOS DataKeeper 保護 Azure 中 SQL Server 上的關鍵 CAD-EX CAD2CAD 軟體。

主要的 DEH 資訊交換是 CAD 到 CAD (C2C) 交換，它使所有 NCR DEH 機構的調度員能夠立即了解前線資源位置、資源可用性，並共享相關事件的最新資訊。所有C2C Exchange 連接成員轄區的CAD 系統。

NCR DEH C2C Exchange 使用在 Windows 伺服器上執行的 Microsoft SQL Server 資料庫，並部署在 Azure 商業雲端中。鑑於這些系統的關鍵性，DEH 要求為 C2C 交換平台提供高可用性資料保護。故障轉移叢集而不增加複雜性 在涉及資料庫的傳統Windows 高可用性(HA) 環境中，配置了兩個或多個資料庫實例節點。具有共用儲存體（通常是 SAN）的 Windows Server 故障轉移叢集。

資料庫在主節點上運行，HA 故障轉移軟體監控其運行情況。如果偵測到問題，HA 軟體會協調資料庫操作的故障轉移到叢集中的備用輔助節點。在雲端和其他共享儲存不可用且經濟高效的環境中，複製用於透過同步每個集群節點上的本地儲存來創建 SANless 集群，以便在發生故障轉移時，輔助節點可以繼續運行使用當前資料進行操作。

在專案的早期階段，NCR IT 團隊已在多個環境中部署了 C2C Exchange 平台。這包括費爾法克斯縣本地資料中心，以及隨後在多個第三方、國家和本地託管提供者環境中的資料中心。在這些環境中，C2C Exchange 資料庫部署體系架構使用 Microsoft SQL Server Enterprise Edition 和 Always On 可用性群組。

隨著專案的擴展，NCR IT 團隊積極利用先進的雲端技術，將 C2C 平台部署到 Azure 商業雲端。雲端提供了在更虛擬的環境中管理 C2C 平台所需的靈活性和服務等級。

Azure 雲端也讓 NCR 部署更具成本效益、高可用性的資料庫叢集解決方案，以自信地交付 C2C Exchange 應用程式數據，同時降低與 SQL Server Enterprise Edition 相關的較高授權成本。

解決方案

NCR DEH C2C Exchange 開始使用 SIOS DataKeeper Cluster Edition 軟體建立 SANless 集群，以保護其 C2C Exchange 資料在 Azure 商業雲中的可用性。軟體在兩節點主動-被動 Windows Server 故障轉移叢集配置上執行，利用 SQL Server 標準版和 Always On 故障轉移叢集。

SIOS DataKeeper 軟體使用頻寬高效、基於主機的區塊級複製來同步所有資料庫叢集節點上的本機儲存。如果偵測到應用程式可用性問題，操作會自動轉移到輔助節點，無需手動幹預。雲端供應商保證的服務水準確保硬體可操作性，但不包括與軟體和網路相關的應用程式停機原因。

結果

NCR DEH C2C Exchange 已在 Azure 商業雲中使用 SIOS DataKeeper 叢集版軟體兩年多了。參與互通性計劃的人數增加。除了最初的成員外，該計劃現在還包括華盛頓都會機場管理局 (MWAA)、弗吉尼亞州的勞登縣和威廉王子縣，以及馬裡蘭州的蒙哥馬利縣和喬治王子縣。C2C 交易所管理著數千個共享單元，每年在這些參與者之間共享數十萬起事件的數據。

使用 SIOS DataKeeper Cluster Edition 在雲端建立高可用性資料庫叢集既快速又簡單。EDC 首席技術長兼聯合創始人 Greg Crider 表示：“我們只需將 SIOS DataKeeper 安裝到 Windows Server 故障轉移群集節點，將本地節點存儲配置為 SIOS 託管存儲以進行複製，並且它可以無縫運行。” “SIOS DataKeeper 叢集軟體的另一個好處是，它使我們能夠透過按需轉換叢集節點來對資料庫執行定期、滾動的軟體維護，而無需計劃內停機或服務中斷。”

自從在 NCR C2C Exchange 中實作 SIOS DataKeeper 以來，沒有出現涉及資料庫的停機問題或節點之間的資料遺失問題。EDC 總裁、執行長兼聯合創始人Chris Wiseman 補充說：「雖然出現了一些意想不到的、無法控制的網路問題，但資料庫很快就發生了故障，C2C 交換操作仍在繼續，最終用戶沒有受到服務長期減少的影響。SIOS DataKeeper 軟體使我們能夠提供更高層級的資料保護和交付，而無需更昂貴的 SQL Server Enterprise Edition 授權。這為我們的利益相關者每年持續節省大量資金。”

DHS/SAFECOM 在視訊連結中介紹了具有 SIOS DataKeeper 保護的 NCR C2C 交換。最近，銀行、公寓大樓和療養院同時發生三起大火，這一點受到了考驗。CAD 系統之間的互通性在確保快速、有效率地回應這些事件方面發揮了關鍵作用。

EDC 正在透過其商用 NG-CAD-X C2C Exchange 產品在美國其他市場擴大 C2C Exchange 的採用。這種功能先進的 C2C 產品正在由丹佛市中北部全災區和佛羅裡達州東南部地區實施。NG-CAD-X 與NCR C2C Exchange 訊息相容，部署在Azure 政府雲端中，以實現除消防和EMS ESF 之外的CJIS 合規性和執法採用，並且還將SIOS DataKeeper Cluster Edition 實施到其所有資料庫架構中上面強調的操作和成本效益原因。「策略夥伴關係在為我們的客戶提供市場上最佳技術解決方案方面發揮著重要作用。SIOS DataKeeper 是我們系統不可或缺的一部分，並且是有價值的 EDC 合作夥伴。” EDC 副總裁 Kevin Konczal 說。

下載pdf

經許可轉載安全作業系統

網路研討會：保護 Azure 上的 SAP 和 SAP S/4HANA：災難復原最佳實踐

在當今的數位環境中，保護 SAP 和 SAP S/4HANA 等關鍵業務應用程式的安全對於防範可能影響業務連續性的潛在災難至關重要。Azure 利用雲端運算的強大功能，為 SAP 和 SAP S/4HANA 環境提供強大的災難復原解決方案。此點播研討會討論了保護 Azure 上的 SAP 和 SAP S/4HANA 系統的最佳實踐，包括以下策略：資料複製、備份和復原、高可用性和故障轉移。SAP on Azure 雲端的 Microsoft Fast Track 高級客戶工程師 Harikrishna Madathala 分享見解、實用技巧和實際範例，協助實施災難復原最佳實踐，以保護 Azure 上的 SAP 和 SAP S/4HANA 部署，確保最高等級關鍵業務應用程式的安全性、彈性和可用性。

經許可轉載安全作業系統