遠距離辦公時，要如何保證公司內部資料不會遺失？ 當資料搬上雲端，伺服器如何保障系統可以持續作業？ 您希望出現問題的時候可以在幾分鐘內自動恢復服務？ 採用SIOS高可用、災備的軟體解決方案，可為企業節省時間與開支！ 現在聚碩提供免費試用14天(僅限台灣地區），快來申請吧！ 無論是在本地或者雲端，專門為SQL，Oracle，SAP 等APP提供高可用性的軟體解決方案。
案例研究:AppKeeper 提供 24 小時監控自由以及大幅降低成本
案例研究:AppKeeper 提供 24 小時監控自由以及大幅降低成本
領先的數位廣告代理的 IT 部門需要一種簡單、經濟高效的方法,為在 AWS EC2 中運行的應用程式提供保護,同時消除警報風暴和不必要的 IT 任務。他們實現了 AppKeeper 和分鐘,並看到了應用程式可用性的即時、節省成本的改進。
INFOBAHN集團是INFOBAHN集團(INFOBAHN Group,Inc.)的子公司,是一家總部位於東京的數位廣告公司,為客戶擁有的媒體提供數位品牌、廣告和內容管理。INFOBAHN Group Inc. 的 IT 部門是一個小型部門,為其客戶擁有的媒體及其姊妹公司 Mediagene Inc. 提供完整的 Web 伺服器管理服務,該公司是主要內容媒體網站的所有者,如"日本 Gizmodo"、"cafeglove"、"生活駭客"(日文版)、"商業資訊日本"、"ROOMIE"等。
環境
使用 Amazon Web 服務 (AWS) 的 INFOBAHN 客戶中約有 80% 依賴內容管理系統 (CMS) 向讀者提供最新內容。由於 INFOBAHN 的客戶對這些 CMS 工具的停機時間和嚴格可用性 SLA 寄予厚望,因此他們將運行在伺服器上的伺服器的監視和管理外包給託管服務提供者 (MSP)。
挑戰與挑戰
對於 INFOBAHN 來說,他們同時滿足自己的內部、客戶和可用性服務級別協定 (SLA) 非常重要。他們還使用 MSP 監視其某些內部伺服器,同時監視其他伺服器,這需要自己進行更密切的管理。
"雖然我們可以繼續將伺服器的監控外包給客戶的系統。此模型不適用於我們的內部伺服器,因為它不會隨著業務規模的擴大而擴展,"INFOBAHN集團 IT 部門經理 Yu 天野之彌說。INFOBAHN已經每月花費近1,400美元來監控其內部伺服器,而他們的內部團隊無法自行管理更多的伺服器。
天野之彌和他的同事日夜收到故障通知。每個通知都要求天野之彌或其同事放棄所有內容,調查原因並解決問題。
評價
天野之彌認識到他們需要更好的解決方案,因此考慮了 SIOS 技術針對 AWS EC2 的 SIOS AppKeeper 可用性軟體。他們測試AppKeeper與他們的WordPress伺服器,通過關閉它的Apache服務,並檢查AppKeeper通知電子郵件和故障日誌,以驗證狀態和行動由AppKeeper。
"我們多次執行驗證測試,包括停止服務,並確認服務按預期啟動。我們可以看到 AppKeeper 是可靠的。我們還發現,經過非常簡單的配置過程,它提供了自動監控和恢復服務,"天野之彌說。
解決方案
SIOS AppKeeper 作為軟體即服務提供,支援 AWS EC2 服務和實例的自動監控和恢復。它通過 AWS API 監控它們,並快速檢測故障並從故障中恢復。
AppKeeper 通過檢測並首次重新啟動應用程式服務自動還原應用程式操作。此步驟通常在幾秒鐘內還原服務。如果服務重新啟動失敗,則重新啟動整個實例。它發佈故障報告,根據從虛擬機服務和 AWS 恢復之前和之後獲得的相關信息顯示任何故障發生和恢復。
如果客戶選擇 EC2 自動縮放功能,他們可以輕鬆地添加更多實例以進行 AppKeeper 保護。AppKeeper 將自動縮放以近乎即時地監視這些新實例,如果需要,將自動應用指定的設置。
研究結果
2017 年 3 月初,INFOBAHN 開始使用 SIOS 應用程式保持器監控其內部伺服器。"通過線上註冊流程提交 AWS 認證後,我要做的就是選擇我希望 AppKeeper 在檢測到故障時採取的步驟的設置。只需點擊在線使用者指南中所述的螢幕即可配置 AppKeeper,只需 10 到 15 分鐘,「天野之彌說。
天野之彌說,自從他們開始使用SIOS應用程式保持以來,沒有失敗,他們無法自動恢復。SIOS 應用程式保持器甚至幫助他們免受人為錯誤。"有時,其他 IT 成員無意中將活動目錄伺服器關閉。我收到來自 AppKeeper 的電子郵件通知時,我出去說服務已經恢復。恢復是如此順利,我甚至沒有注意到它,直到我被告知,"天野之彌笑了起來。
INFOBAHN 正在考慮擴大 AppKeeper 的使用範圍,以監控其所有內部 AWS 伺服器。他們還考慮在未來為客戶專案使用 AppKeeper。天野之彌說:「如果我們有SIOS AppKeeper,我們可以在一台帶有 AWS 的伺服器上安裝必要的 CMS,如 WordPress 和可移動類型,並提供附加價值,使服務在發生故障時自動恢復。
關於 SIOS 應用程式保持者
SIOS AppKeeper 軟體持續監控和保護 AWS EC2 中的應用程式免受服務中斷和停機,同時無需昂貴且耗時的手動干預。
欲瞭解更多資訊,HTTPs://us.sios.com/products/sios-appkeeper/
註冊 SIOS 應用程式保持器的免費試用版
適用於 S/4HANA 和其他 SAP 平台的高可用性和 DR
SAP 是企業應用軟體的市場領導者。多年來,SAP 幫助各種規模和所有行業的公司高效運營,多年來建立了依賴於其平臺的企業生態系統。事實證明,全球 77% 的交易收入涉及 SAP 系統。
SAP 應用程式涉及公司的許多關鍵部分,例如其 ERP、製造、業務流程、客戶服務等。它已成為許多企業賴以經營才能正常運行的生命線。因此,高可用性已成為公司管理層在其 SAP 系統方面最關心的問題之一。
在本文中,我們將在高級別上討論什麼是 HANA 系統複製、它的工作原理、在高可用性方面有哪些限制,以及我們如何克服這些限制。我們還將討論 HANA 高可用性選項以及主要區別是什麼,以便您可以為正確的工作選擇正確的工具。
為了選擇適合 HA 的解決方案,您可能需要在一天結束時問自己一些關鍵問題:
- 滿足時間目標 (RTO)
—— SAP 可以關閉多長時間才能恢復?
- 滿足回復點目標 (RPO)
——復原服務時資料可能有多舊
- 滿足可用性服務等級協定 (SLA)
——你需要多少時間?
SAP HANA 系統複製
SAP HANA 系統複製是一種可靠的數據保護和災難恢復解決方案,可提供 HANA 資料庫與同一資料中心、遠端網站或雲端中的輔助位置的連續同步。
系統複製是軟體附帶的標準 SAP HANA 功能。使用此功能,所有數據都會複製到輔助網站,數據會預載入到輔助網站上的記憶體中,從而顯著縮短恢復時間目標 (RTO)。因此,在故障轉移的情況下,輔助網站將能夠接管,甚至無需執行 HANA DB (重新)啟動,並在故障轉移時立即作為主資料庫工作。但是,故障轉移必須由使用sr_takeover命令的管理員手動觸發,並且要反轉複製,或者故障回主,還需要發出單獨的命令。
以下是 HA 和 DR 的 HANA 系統複製方法的一些要點:
- 冗餘伺服器/節點
- HANA 系統複製的記憶體中資料庫(在「日誌重播」模式下)
- 多個複製選項:同步、同步、非同步
- 支援主動-活動(輔助級唯讀)
- 透過 HANA 駕駛艙、HANA 工作室或命令列進行設置和管理
限制
- 未監視應用程式行程或複製失敗以及自動故障移轉
- 容錯移轉、反向複製和故障復原必須手動執行 – 需要執行許多手動步驟
- 無虛擬 IP
- 沒有整合的 HA 故障轉移業務流程與 SAP ASCS 等。元件
現在您可能從上述點推斷出,HANA 系統複製旨在防止數據丟失。因此,當主節點出現問題時,管理員可以手動運行”sr_takeover”命令,以便主系統的問題不會關閉整個 SAP 設置,該設置依賴於 HANA 資料庫的長期停機時間。然而,許多這項工作必須手動進行,並且依賴於人工干預,雖然對 DR 足夠好,但它並不能為 HA(需要防止停機)提供理想的情況。
SIOS 高可用性叢集
SIOS 面向 SAP 的高可用性軟體可讓您在實體、虛擬、雲端(公共、私有和混合)和高性能快閃記憶體環境的任何配置(或組合)中保護 SAP S/4HANA。SIOS 軟體提供簡單靈活的配置、快速複製以及對整個 SAP S/4HANA 環境的全面監控和保護。
專門用於 SAP S/4HANA 和 HANA 資料庫。SIOS 可用於補充 SAP 已經在使用 HANA 系統複製(添加到其上)執行的操作,以提供真正的高可用性 – 自動監視關鍵 HANA 應用程式進程,並提供自動故障轉移、故障恢復(包括虛擬 IP),即使您在單個 HANA 節點中具有多實例也是如此。
以下是 SAP HANA HA 和 DR SIOS 保護套件的一些要點:
- 在雲端交叉 AZ 和 AR 中工作
- 為關鍵的 SAP HANA 資料庫元件提供自動容錯偵測與故障轉移:
— SAP HANA 主機代理
— SAP HANA 樹苗
— SAP HANA 複製 - 將自動化 SAP HANA 複製接管、切換
- 自動反向複製
- 驗證並監視 HANA 資料庫是否正在執行
- 提供虛擬 IP
- 與 ASCS 等的「完整堆疊」故障轉移業務流程。SAP 元件
為 HANA 資料庫安裝和設定 HA 的四個步驟
我們不會討論如何配置 SAP HANA 的具體步驟,因為已經有許多在線資源涵蓋這些步驟。但在高級別上,您需要執行 4 個基本步驟:
- 安裝 SAP HANA
- 設定 HANA 系統複製
檢視 – https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.02/en-US/676844172c2442f0bf6c8b080db05ae7.html - 安裝 SIOS 保護套件
參見 – http://docs.us.sios.com/spslinux/9.4.1/en/topic/sios-protection-suite-for-linux-installation-guide - 在 GUI 中使用 HANA 回復工具套件(精靈)來保護 HANA
請參考 – http://docs.us.sios.com/spslinux/9.4.1/en/topic/sap-hana-recovery-kit
安裝過程流與其他 SAP 元件(ASCS、ERS、PAS、Web 調度程式等)也類似。
使用 SIOS 保護套件軟體中包含的 HANA 修復工具組,您基本上可以使用 SIOS Lifekeeper 管理 GUI 中的精靈,快速保護 HANA 資料庫實例,為用戶端分配虛擬 IP 位址以進行連接到它,並管理整個堆疊。您可以擁有多實例環境,解決方案將管理所有實例、虛擬 IP 等。在完全整合的 GUI 中,它非常容易配置、管理 SIOS HA 上的整個 SAP 環境。
用於 SAP 的全面 HA/DR 堆疊 –
除了 HANA 資料庫之外,SIOS 保護套件還為關鍵的 SAP 服務和支援應用程式提供保護,所有這些服務都可以從同一 GUI 進行管理:
- 主應用程式伺服器 (PAS)
- ABAP SAP 中央服務 (ASCS)
- SAP 中央服務 (SCS)
- 佇列與訊息伺服器
- 將佇列複製伺服器 (ERS)
- 資料庫(Oracle、Sybase、MaxDB、HANA 等)
- 分享及/或複製檔案系統
- 邏輯卷 (LVM)
- NFS 安裝及匯出
- 虛擬 IP
雲中群集
將 SAP 遷移到雲端時,關鍵挑戰之一是如何保護 SAP 資料庫以及 SAP 應用程式堆疊在 SAP 支援的體系結構中。SIOS 一直是這一舉措的前沿,由 SAP 以及所有主要雲供應商設計、認證和支援。
下圖是一個高級設計,用於瞭解如何跨不同可用性區域甚至區域部署一對 S/4HANA 系統。在雲端環境中,由於供應商在 AZ 之間的延遲非常低,因此完全可以在 AZ 中使用同步複製,從而創建一對高度可用的 S/4HANA 系統,不僅針對 HA,還用於 DR。這是因為 AZ 在地理上是獨立的資料中心,這與本地 DR 資料中心的當地語系化程度非常類似,即它們之間的高度冗餘高速網路連接。
為什麼要用 SIOS 於 SAP 而不使用開源 HA?
這個問題總是會出現在人們的腦海裡,因為一些Linux供應商已經提供了他們的HA擴展(HAE)或集群,為什麼有人想要使用商業第三方HA解決方案,如SIOS?
- 開源 HA 作為某些作業系統類型「企業 SAP」擴展訂閱的一部分提供 – 它的成本,它絕對不是免費的,並且並非所有的 Linux 風格都受支援。SIOS 支援所有主要的 Linux 風格,包括紅帽、SUSE、Centos 和 Oracle Linux。適用於希望為其 ASCS 或內容伺服器等運行 Windows 的客戶。SIOS 還具有 Windows 群集支援基於 Windows 的解決方案,使其成為整個 SAP 環境的一站式商店,而不管平臺如何。
- 商業 HA 支援 – 操作系統供應商依賴開源社區進行 Bug 修復,如果 Bug 需要較長的時間才能由活動較少的參與者解決,則這可能是個問題。SIOS 為商業支援提供專門的支援和開發團隊,僅針對其高可用性解決方案,並立即提供 24×7 支援解決方案,當出現可能開發的問題時,將給予客戶更多的信心。
- 開源工具需要通過命令行進行複雜的設置和管理。它們由不同的元件組成,如起搏器、Corosync等。由不同的開源倡議維護。SIOS 為基於嚮導的設置和管理提供一體式 GUI。它允許人們在幾個小時(而不是數周/月)內部署 SAP HA。
- SIOS 透過 GUI 中的精靈為所有需要 HA 的 SAP 和雲端元件提供預建構的應用程式監視和故障轉移業務流程,而不是使用仍需要大量的手動配置的 HA 擴展。
- 自動確保 SAP ERS 始終在 ASCS 的相反節點中運行 – SIOS 即使在多節點 ASCS 設置中也能提供智慧,如果發生故障轉移,並且 ASCS 故障轉移到運行的 ERS 節點,當原始 ASCS 節點恢復時,ERS 會自動切換,以便鎖始終獲得所需的冗餘。開源解決方案需要手動完成此操作,因此會影響可靠性和可用性,尤其是在多次故障和恢復時。
- SIOS 減少了實施/管理時間和成本,實施和維護 HA 的時間越小,您花在其他更重要的任務上的時間就越多。
- 開源使用其STONITH機制,這種機制在雲環境中是難以可靠的,SIOS提供了多塊功能的方法,以防止假故障轉移和分裂腦-仲裁見證,多通信。路徑(心跳)已被證明在許多場景中高度可靠。
總結
SAP HANA 系統複製功能作為軟體的一部分,在硬體或系統故障出現問題時,可很好地保護資料庫免受數據丟失的影響。但是,如果要求高可用性,它仍然需要第三方解決方案,以獲得一些自動監視、故障轉移業務流程、虛擬 IP 等。雖然 SAP 的企業 Linux OS 訂閱形式有開源選項,但它們肯定不是免費的,並且技術支援仍然有限,因為它們完全依靠開源社區來維護起搏器、Corosync 等。專案。並獲得貢獻者的支援。本機系統複製(開源 HAE)也有限制,可以由像SIOS這樣的商業軟體解決方案供應商克服。
因此,SIOS 作為可靠的第三方高可用性解決方案供應商,可幫助確保企業客戶獲得其關鍵任務 SAP 系統操作所需的可靠性和高可用性,讓您高枕無憂,從而證明自己是 SAP HANA 系統複製的非常可行的補充解決方案,SAP 和所有主要的操作系統和平臺供應商也完全支援該解決方案。
作者：
Jason 胡
IT 專業人員,20 多年來一直專注於高可用性和災難恢復。目前受雇於SIOS技術公司,擔任亞太地區的戰略業務發展。
網路研討會:Oracle 資料庫雲中高可用性
網路研討會:Oracle 資料庫在雲端中的高可用性
遷移到雲不需要涉及對體系結構和應用程式設計的破壞性更改。保持高可用性冗餘和對 HA 群集的體系結構更改的成本也不高。
即使 Oracle 從 19c 開始從標準版中刪除 RAC 功能,並終止對 12c 的支援,您仍可以透過 SIOS 等第三方 HA 解決方案實現高可用性。無需升級到企業版 Oracle DB 即可節省高達 70% 的成本。
在此 1 小時的在線會話中,瞭解如何實現上述目標等。這包括為您的組織使用 Oracle 和其他應用程式時的成本節約。所有這些都不影響雲中 99.99% 的上山時間要求。
議程
- 將 Oracle DB 移至雲的好處
- 在雲端中移至 Oracle 的高效能使用的挑戰
- 重要原因:與使用 Oracle RAC/Dataguard 相比,成本優勢
- 雲架構上的 Oracle 和 SIOS HA
- Q&a
雲中的 Oracle DB HA:
節省成本並減少移轉後的停機時間
您的 Oracle 雲工作負載
現場網路研討會 – 2020年4月23日,星期四
SGT 下午 12 點,美國東部時間下午 2 點,PHT 上午 11 點,美國東部時間上午 9:30
使用一些最苛刻的企業在亞太地區,包括 – AGL澳大利亞 • 珀斯體育場 • 交通部和主要道路澳大利亞 • 英格姆斯集團澳大利亞 • 克裡斯·奧布萊恩醫院 • 韓國教育局 • LG Display Korea • 三菱重工 • NH 銀行韓國 • 柬埔寨長野賭場 • 野村研究所 (上海) • 松下亞洲 • Razer 亞太私人有限公司 • 三星韓國 • Zespri 紐西蘭
SQL Saturday：Azure IaaS中SQL Server的高可用性和災難恢復
Azure IaaS中SQL Server的高可用性和災難恢復
演講者：Jason Aw
持續時間：60分鐘
等級：初級
跟踪：應用程序，DBA和數據庫開發
首席執行官只是要求您將所有SQL Server實例移至Azure，或者您正在部署一個全新的應用程序，並希望利用Azure IaaS來託管SQL Server。除了安全性和性能之外，您最緊迫的問題可能是確保在Azure中運行的SQL Server具有高可用性。
雖然SQL Server的本地高可用性和災難恢復選項已經很好地定義，但將這些實例移動到Azure會立即帶來一些問題和挑戰。我可以簡單地將SQL Server故障轉移群集實例提升並遷移到雲端嗎？我是否需要升級到SQL Server企業版和我們的Always On Availability Groups？那麼共享存儲和故障轉移群集呢？那麼災難恢復，我有什麼選擇？負載均衡器，故障域，可用區，Azure站點恢復和區域對，這些是什麼以及為什麼它們對我很重要？
具有20年經驗的高可用性和災難恢復專業人員Jason Aw解釋了所有這些以及更多細節。
隨附材料
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- 6
- …
- 79
- Next Page »