醫療保健的高可用性

醫療保健的高可用性

保護醫療保健和生命科學的關鍵應用

醫療保健信息系統、ERS 和 EHS

SIOS 高可用性集群和復制軟件可確保關鍵應用程序、數據庫和 EHS 系統從基礎設施、網絡和應用程序故障中自動恢復，從而保持關鍵患者記錄和其他數據受到保護、應用程序在線、滿足法規要求以及用戶高效工作。

本地、雲、混合雲

SIOS 使您能夠靈活地在物理服務器、虛擬化服務器和雲中為 Windows 或 Linux 環境構建 SAN 和 SANless 集群。在本地或靈活、可擴展的雲環境（例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Platform）中運行業務關鍵型 EHR 應用程序，而無需犧牲性能或 HA/DR 保護。

輕鬆滿足可用性 SLA 和 RTO/RPO

輕鬆地將受 Windows Server 故障轉移群集保護的本地應用程序遷移到雲端，而無需中斷，或構建內置特定於應用程序的智能的 Linux 群集環境。跨雲可用區或區域配置集群以實現最大程度的 HA/DR 保護，或創建混合雲或多雲配置以輕鬆滿足可用性 SLA 和 RTO/RPO。

為關鍵 EHS 系統提供 HA

SIOS 產品可保護運行電子健康記錄 (EHR) 應用程序的關鍵數據庫免遭停機和數據丟失。Athena Health、Cerner Corporation、eClinicalWorks、Epic Systems、GE Healthcare、Greenway Health、Kareo、MEDITECH、McKesson、Xtelligent 等。

保護 Windows 應用程序和數據庫

將 SIOS DataKeeper 添加到 Windows Server 故障轉移群集環境中，以創建傳統共享存儲群集不可能或不切實際的 SANless 群集，例如雲和混合雲環境。快速、高效的基於主機的複制可同步所有集群節點上的本地存儲，以實現最大的配置靈活性。或者，將復制添加到現有的基於 SAN 的 Windows 集群以進行災難恢復。

使用 SIOS DataKeeper Cluster Edition 軟件在物理、虛擬或云環境中保護您的業務關鍵型 Windows 應用程序和 EHR 系統及其運行的數據庫，包括 Microsoft SQL Server、Oracle。

• 配置靈活性 – 保護所有服務器工作負載。在單個站點內或跨數據中心進行複制。
• 節省成本 – 高級集群，無需昂貴的應用程序升級（例如 SQL Server 企業版）
• 降低複雜性 – 將本地 WSFC 遷移到雲而不造成中斷

保護 Linux 應用程序中的應用程序

SIOS 集群跨雲區域或可用區進行獨特的故障轉移，以實現真正的 HA 保護。SIOS Protection Suite 包括適用於領先應用程序、ERP 和數據庫的強大應用程序恢復套件，可自動執行手動任務、監控整個應用程序堆棧並確保故障轉移維持特定於應用程序的最佳實踐。

• 高級自動化 – 自動驗證的用戶輸入消除了對昂貴的專業技能的需求以及手動腳本固有的風險，以在復雜的 EHR 環境中配置和管理集群
• 深度應用監控——監控整個應用環境
• 應用程序感知的自動故障轉移 – 保持符合應用程序最佳實踐，以實現可靠的故障轉移，不會出現意外。

經許可轉載安全操作系統

為什麼 SIOS HANA 多目標自動化比您想像的更重要

為什麼 SIOS HANA 多目標自動化比您想像的更重要

Larry（化名）是一位 SIOS 客戶，過去曾部署過用於高可用性和災難恢復 (HA/DR) 的複制解決方案。當他啟動 PoC 來測試 Linux 的雙節點複製解決方案時，使用SIOS 生命守護者和DataKeeper複製一樣，他的首要任務是保護數據完整性。Larry 的 PoC 測試清單包括標準項目，其中包括：數據庫啟動/停止、將數據庫遷移到備份節點、維護活動和服務器故障轉移等等。Larry 堅信該解決方案能夠實現快速服務器切換（即優雅的遷移）和快速故障轉移（即突然強制遷移）應用程序、數據庫、存儲和服務從一台服務器到另一台服務器的遷移。但是，他更加強烈和熱情地認為此類活動不應導致數據丟失。

通過避免腦裂來保護數據完整性

除了這些標準測試之外，拉里還添加了特定測試來試圖強制“裂腦“ 設想。腦裂是指當集群成員無法相互通信，但處於運行和可操作狀態，並隨後同時獲得公共資源的所有權時，就會發生這種情況。實際上，兩名公交車司機正在爭奪方向盤。由於其破壞性，腦裂可能會導致數據丟失或數據損壞，最好通過使用一種機制來確定哪個節點應保持活動狀態（驅動總線）以及哪個節點應停止寫入磁盤來避免。

雖然在部署使用仲裁和仲裁加見證功能的集群中，裂腦場景相對不常見，但隨著每個節點添加到集群配置，解決裂腦問題的難度呈指數級增加。在具有三個或更多節點的多目標配置中，集群軟件不僅必須協調故障轉移到正確的節點，還必須自動將復制從新的主節點切換到第三節點，以維持災難恢復保護，同時確保在不同節點之間進行正確仲裁。節點。在其他集群解決方案中，必須手動編寫這些複雜的操作腳本，並在發生故障轉移時手動更新以恢復正常操作，並且當發生腦裂時，只會變得更加困難。

由於 SIOS LifeKeeper 的功能和改進以及SAP HANA 應用程序恢復套件（方舟），拉里很難引入裂腦場景。然而，當他最終設計出一款產品時，他因了解 SIOS 產品用於保護數據的邏輯而受益匪淺。Larry 認識到 SIOS 集群軟件提供的數據保護設計的高度複雜性。他選擇了 SIOS LifeKeeper。

SIOS HANA 多目標自動化差異

像 Larry 這樣的場景只是 SIOS 的 HANA 多目標自動化比您想像的更重要的九個原因之一。以下是全部九個：

1. 增強保護
   SIOS 的解決方案簡化了多目標場景中 HANA 數據庫資源的保護。基於嚮導的選項可快速檢測當前配置並將信息精確添加到 LifeKeeper 配置中。錯誤檢測既簡潔又信息豐富，可以幫助用戶解決任何問題並隨後節省時間。
2. 簡化管理
   Natalie（化名）負責 HANA 多節點配置。當服務器出現故障或需要維護時，Natalie 利用不同的腳本和工具來執行所需的操作。然而，這是不可擴展的。遷移到 SIOS LifeKeeper 後，Natalie 和團隊有一個簡單的 UI 來執行所有核心任務，例如停止和重新啟動 HANA 和 HANA 系統複製。此外，如果發生災難，團隊可以使用單一、簡化的 SIOS UI，而無需搜索最新的運行手冊、查找正確腳本的副本或在凌晨 2 點致電 Natalie。。
3. 簡化監控
   SIOS UI 中直觀的狀態報告為團隊提供了一種快速的方法來確定複製地位。與使用監控板和自製腳本的集合相比，使用單一工具可以簡化管理並節省時間。
4. 自動恢復
   某些 HANA HSR 解決方案能夠在這兩個節點之間執行 HANA 複製的故障轉移。然而，管理員通常必須在系統故障轉移後重新註冊複製。如果有三個或更多節點，管理員是否了解如何更新第三個或第四個節點上的註冊？他們會記得正確使用同步和異步嗎？SIOS 解決方案能夠處理三個甚至四個節點的多目標複製，並在出現故障後無縫地自動註冊目標節點。
5. 靈活性和可擴展性
   通過兩個、三個或四個節點組合來保護 HANA 集群的能力意味著客戶可以靈活地提高可用性和災難恢復級別。具有法定人數的兩個節點客戶能夠提供針對災難的可用性保護，並利用具有握手功能的 HANA 接管，以接近零停機時間處理維護活動。部署三個節點的客戶可以通過在不同的數據中心或區域中部署具有異步複製功能的第三個節點來獲得額外的災難恢復功能。為了獲得更多好處，三節點客戶可以部署具有存儲仲裁的第四個節點，以啟用高可用性和災難恢復如果整個數據中心丟失。
6. 數據保護
   讓我們回到拉里的問題。他在主節點 A 上運行 HANA，並向節點 B 和 C 進行多目標複製。當您的手動工作以災難告終時會發生什麼？哪個節點是主節點？當節點 A 崩潰時，一切是否同步？如何避免出現錯誤的節點？除了在多目標 HSR 配置中添加對三個或更多節點的支持之外，新的 HANA ARK 還包括額外的管理工具，可以在發生災難或不幸的腦裂事件時提供幫助。

   HANA_DATA_OUT_OF_SYNC_<tag> 標誌可防止用戶意外在錯誤的系統上恢復數據庫。HANA_LAST_OWNER_<tag> 標誌可幫助管理員了解在備用節點不同步的情況下何時對主系統執行了操作。該標誌告訴管理員該節點是最後一個所有者，並且應該在其中恢復複製。當備用數據庫之間的所有通信暫時丟失然後恢復時，HANA_DATA_CONSISTENCY_UNKNOWN_<tag> 幫助 SIOS 自動解決並恢復複製。當與最佳實踐、仲裁部署和適當的調整結合使用時，這些工具可以讓像 Larry 這樣的管理員避免腦裂，並在發生腦裂時安全地恢復。

7. 報告、性能和災難恢復
   當然，多目標的真正好處在於額外的節點以及這些節點解鎖的功能。在同一數據中心使用三個節點可以通過 logreplay_readaccess 參數釋放更多報告的潛力，同時仍然在災難恢復站點維護一個節點。此外，SIOS 對不同複製模式的支持使用戶可以選擇擁有同步節點和異步節點，以便跨數據中心（或區域）獲得更好的性能。
8. 持續測試
   您的團隊多久測試一次自製腳本？您的運行手冊中有關配置、管理和凌晨 2 點場景的審核頻率如何。HANA 多目標解決方案不僅經過 SIOS 工程師、QA 和客戶體驗專家的持續測試，而且還在每個版本和更新中針對 HANA 故障轉移和恢復流程持續進行測試和驗證。
9. 廣泛的文檔
   不久前，我們的團隊與一位客戶合作進行集群管理。雖然他的前任對他們的環境非常了解，但員工晉升和重組讓許多 IT 人員負責他們知之甚少的系統。當被問及其配置的操作手冊和文檔時，客戶無法從以前的團隊或以前的管理員那裡找到詳細信息。除了堅如磐石的自動化、管理、監控、恢復和數據保護之外，SIOS 多目標解決方案還包括有關由 LifeKeeper 控制的 HANA 多目標系統的實施、操作和管理的詳細且易於使用的文檔。

利用 SIOS 的整體解決方案意味著客戶可以受益於一致、及時的監控和檢測、快速、可靠和高效的恢復，以及保證高可用性和災難恢復保護的全自動解決方案。聯繫我們有關 SAP HANA 多目標自動化的更多信息。

-Cassius Rhue，客戶體驗副總裁

經許可轉載安全操作系統

在不花費大量資金的情況下實現 SQL Server 的 HA/DR

在不花費大量資金的情況下實現 SQL Server 的 HA/DR

高可用性和災難恢復 (HA/DR) 是所有數據庫環境的基本要求，尤其是關鍵任務數據庫環境。然而，許多企業面臨著在不大幅增加成本的情況下實現 HA/DR 的挑戰。如果您正在努力解決這些問題，本文將為您提供有效的解決方案。

SQL Server 標準版被廣泛使用，但它有一定的局限性：它僅支持集群中的兩個節點。但是，通過利用 SIOS DataKeeper Cluster Edition 的功能，您可以克服此限制，從而能夠將數據複製到第三個節點以進行災難恢復。

此策略允許您使用 SQL Server 標準版創建 SANLess SQL Server 故障轉移群集實例 (FCI)，而不是升級到 SQL Server 企業版並使用 Always On 可用性組，從而為您節省 70% 以上的 SQL Server 許可費用。

本博文旨在指導您完成使用 SIOS DataKeeper 在不屬於集群的第三個節點上進行數據恢復的過程。

配置您的節點

在此場景中，我們假設您在集群中配置了兩個節點，即 DataKeeper-1 和 DataKeeper-2。這些節點的 E 驅動器相互複製。此外，DataKeeper-1 正在復製到第三個節點 DataKeeper-3，該節點不屬於集群。需要注意的是，對於 SQL Server Standard Edition，第三個節點永遠不能成為群集的一部分。

準備第三個節點

首先，確保 DataKeeper-3 與集群分離。這樣，您現在就有了一個雙節點集群（DataKeeper-1 和 DataKeeper-2），其中 SQL Server 配置為故障轉移集群實例，但仍使用複製到第三個節點 DataKeeper-3SIOS數據管理器。

引導災難恢復過程

那麼，這在實際災難中會如何發揮作用呢？以下是您需要遵循的步驟：

1. 模擬災難：在本例中，為了模擬災難，我們使 SQL Server 在集群（DataKeeper 1 和 2）上脫機。
2. 切換到 DataKeeper 3：當 SQL Server 離線時，我們切換到 DataKeeper-3。然而，DataKeeper 3 上的捲 E 最初無法訪問。
3. 解鎖音量：要解鎖 DataKeeper-3 上的捲，您需要執行名為“emcmd”的教程視頻中所示的命令行操作。切換量’
4. 附加數據庫：在真正的災難中，您需要在 DataKeeper-3 上運行一個獨立的 SQL Server 實例。然後，您可以從此獨立實例附加用戶定義的數據庫。
5. 複製回集群：DataKeeper-3 上寫入的數據將復制回 DataKeeper-1 和 DataKeeper-2。這可以使用 SIOS DataKeeper 界面進行驗證。

災後恢復

災難解決後，您可以使用類似的過程將捲切換回原始源。

通過利用 SIOS DataKeeper Cluster Edition，您可以實施穩健、經濟高效且高效的解決方案高可用性/災難恢復適用於您的 SQL Server 環境的策略。此過程不僅無需升級到 SQL Server Enterprise Edition，從而有助於節省大量成本，而且還可以確保災難期間的數據可用性和快速恢復。

查看這個視頻了解該過程的完整演練，並確保您的 SQL Server 保持彈性，而無需花費太多。

經許可轉載安全操作系統

金融服務

金融服務

對於銀行、信用合作社、支付服務和其他金融服務組織來說，關鍵系統幾分鐘的停機可能會造成昂貴的代價，並且對組織及其品牌造成損害。停機可能會導致客戶不滿、負面新聞和社交媒體、IT 資源耗盡、監管問題以及最終用戶生產力降低。

SIOS 集群軟件為各種關鍵交易、處理和管理系統（包括會計、網上銀行、支付管理、移動股票交易、點對點交易）提供靈活、經濟高效的高可用性（99.99% 應用程序正常運行時間）和災難保護。點對點借貸等等；在本地以及雲、混合雲和多雲環境中。

• 保護 Windows 或 Linux 環境中的交易、處理和管理財務系統
• 監控和保護應用程序運行和可用性
• 將關鍵系統遷移到雲端，而不犧牲 HA 或配置靈活性
• 通過自動重啟功能最大限度地減少故障轉移的需要
• 具有特定於應用程序的智能的可靠故障轉移

雲端HA

雲基礎設施不會自動提供應用程序級 HA 或災難恢復保護。雲可用性服務級別協議僅適用於硬件，這可能無法確保應用程序或數據庫保持可訪問。

雲中應用程序的 SIOS HA 集群可跨雲區域和可用區進行故障轉移。雲中傳統的共享存儲集群配置成本高且複雜，有時甚至不可用。SIOS DataKeeper Cluster Edition 提供塊級複製以同步每個集群節點之間的本地存儲。這使得備用節點能夠訪問主節點存儲的相同副本並且 RPO 為零。

滿足嚴格的可用性 SLA

SIOS 集群軟件監控應用程序可用性，如果檢測到威脅，該軟件會將應用程序操作轉移到備用服務器，在該服務器上操作將繼續進行，停機時間最短，數據丟失幾乎為零。

災難恢復

某些應用程序需要防止災難損壞本地或云中的本地 IT 基礎設施。SIOS 集群軟件支持跨地理位置分離的集群節點以及跨雲區域和可用區的故障轉移，以實現完整的災難恢復保護。

經許可轉載安全操作系統

呼叫中心和計算機輔助設計

呼叫中心和計算機輔助設計

計算機輔助調度和 CAD2CAD

在當今復雜的公共安全環境中，對信息協調的需求比以往任何時候都更加重要。SIOS 知道計算機輔助調度 (CAD) 系統的可用性和可靠性關係到生死。這些系統使緊急 911 接線員和調度員能夠確定事件呼叫的優先順序並記錄事件呼叫、調度急救人員並協調響應。CAD 系統捕獲並傳播關鍵信息，例如事件類型和位置、警察、急救人員和消防隊的位置和可用性；以及已知的現場危險；實時。確保正常運行時間是謹慎的做法。由於這些系統的緊急性質，即使 CAD 和 CAD2CAD 系統短暫停機，也可能會延遲響應時間並妨礙動態緊急情況下的資源協調。一些社區集中應急資源以提高效率和快速響應。他們使用 CAD2CAD 軟件連接 CAD 系統，以實現社區間、機構間的協調與協作。

高可用性和災難恢復

SIOS集群軟件為CAD系統提供高可用性和災難保護，有效保證99.99%的正常運行可用性。SIOS 軟件監視 CAD 應用程序環境，如果檢測到問題，則會自動將操作故障轉移到備用集群節點。

Windows 中 CAD 系統的 HA

如果您的 CAD 或 CAD2CAD 系統在 Microsoft Windows 服務器上運行，請將 SIOS DataKeeper 軟件添加到 Windows Server 故障轉移群集環境中，以消除共享存儲的成本和停機風險。

削減軟件許可成本

有多種方法可以創建基於雲的 CAD 或 CAD2CAD 中心，以防止停機和災難。SIOS 軟件監視 CAD 或 CAD2CAD 中心應用程序以檢測問題並確保其正常運行。如果出現問題，它會自動安排故障轉移到備用集群服務器。對於在 Microsoft Windows 服務器上運行的系統，只需添加 SIOS DataKeeper Cluster Edition 即可實現簡單、經濟高效的 SANless 集群。基於 SIOS DataKeeper 主機的塊級複製可快速高效地將本地存儲數據複製並同步到備用服務器，而不會減慢或乾擾 CAD 和/或 CAD2CAD 系統的運行。

經許可轉載安全操作系統