高可用性軟件可防止SAP停機
我們每個人都需要購買保險-為我們的汽車,房屋,我們的生命。沒有人願意為我們希望永遠不必使用的服務付費。但是我們都知道我們應該以防萬一。大多數人要么推遲保險,直到不幸的事情發生,要么買最便宜的,或者實際上做功課,然後從他們信任的人那裡購買。 最後一組通常表現最好。
SIOS SANless clusters High-availability Machine Learning monitoring
我們每個人都需要購買保險-為我們的汽車,房屋,我們的生命。沒有人願意為我們希望永遠不必使用的服務付費。但是我們都知道我們應該以防萬一。大多數人要么推遲保險,直到不幸的事情發生,要么買最便宜的,或者實際上做功課,然後從他們信任的人那裡購買。 最後一組通常表現最好。
保險通常是針對消費者的,但對企業也至關重要。您擁有運行您的業務的計算機系統和應用程序。 如果它們由於某種原因而失敗,則您希望您的業務繼續運營,否則可能會因丟失交易和客戶數據而蒙受數百萬美元的業務損失,並給您在客戶中的聲譽帶來無法彌補的損失。 高可用性軟件是您防止系統停機的“保證”。這不是您不能忽略的事情。這不是您可以信任的隨硬件或軟件基礎結構一起提供的東西。您想使用一家擁有數十年高可用性專業知識並且知道如何保持系統正常運行的公司的高可用性解決方案。
當今企業中使用的關鍵應用程序之一是基於HANA內存數據庫的SAP S / 4HANA。 到2025年,大多數SAP客戶將被要求在SAP上運行HANA數據庫。 您想從一家了解高可用性,了解SAP,了解HANA並了解如何確保您的關鍵SAP應用程序和業務繼續平穩運行的公司中找到智能的HANA可用性解決方案。
SIOS Technology是值得信賴的可靠高可用性軟件公司。LifeKeeper for Linux產品的9.5版本包含一個新的HANA應用程序恢復工具包。這將為您提供保持SAP和HANA環境運行所需的一切。 需要有關此版本的更多信息嗎?觀看這次採訪。
經SIOS許可轉載
作為提供SIOS客戶體驗的軟件工程師,我經常幫助那些將其內部高可用性群集環境遷移到雲的公司。
雲遷移是一個過程,而不是目標。當我們吸引客戶過渡到雲時,通常是在計劃過程的後期,這不是理想的選擇,但在雲遷移中卻並非罕見。以下是我們經常看到的六個雲遷移挑戰。
將您的數據從本地部署到雲需要多長時間?根據您的應用程序,數據類型和雲提供商的不同,它可能會有很大的不同。一個經常被忽略的細節是將數據從主節點同步到輔助節點,有時甚至同步到災難恢復(DR)站點所需的時間。不考慮重新同步時間的客戶在數據複製時會費時費力。
在雲區域內的數據傳輸是免費的。區域之間的數據傳輸將產生費用。通常,我們看到的架構中,主節點和輔助節點位於一個區域內的單獨雲可用性區域中。引入災難恢復站點時,成本可能會大大增加,因為災難恢復站點將始終位於另一個區域。SAP NetWeaver等數據豐富的應用程序的災難恢復可能會抑制跨區域複製的成本。
區域間複製帶來了另一個挑戰:複製類型。可用區內的異步或同步複製由客戶的RTO和RPO要求確定。無論實例大小如何,跨區域之間進行數據複製時都會遇到一些延遲。SIOS建議在區域之間進行異步複製,以減少該延遲的影響。 並發實驗室提供了一些有關EC2區域之間的延遲的有見地的信息。
可以從雲中部署現成的OS映像。這種便利需要付出一定的代價,這為配置管理引入了另一個因素。SuSE Enterprise Linux映像中包含的針對雲進行了優化的cloud-init服務可以刪除用戶定義的虛擬IP地址。沒有什麼能像阻止虛擬IP地址每兩分鐘消失一樣阻止PoC了!
雲計算的規模提供了比企業在本地數據中心中提供的更高的安全性。雲工作負載甚至不知道就利用了尖端的安全性。例如,默認情況下,AWS EC2實例會阻止實例本身未發送或未發送給實例本身的任何流量。這是確保云中網絡安全的重要功能。如果系統需要網絡地址轉換(NAT),則EC2的默認安全措施將導致IP地址失敗。從控制台禁用源/目的地檢查將解決此問題。根據用戶對AWS的熟悉程度,這可能需要幾次點擊到幾次支持電話之間。了解系統如何在環境中進行交互的細節是成功進行雲遷移的關鍵。
需要提醒來自本地系統的客戶,資源不再是限制因素。在雲中,可以毫不費力地複制系統並在生產環境中隔離運行,這在內部部署中並不簡單。按需訪問IT資源允許HA和DR的UAT擴展到“關閉主節點”之外。網絡可能遭到破壞,內核可能會崩潰,甚至數據庫也可能損壞,而這些都不會影響生產!識別和測試這些方案可以改善HA和DR的狀態。
執行成功的雲遷移需要所有利益相關者的投入。高可用性和災難恢復是任何企業工作負載的核心方面。無論SIOS已經是您當前系統的一部分,還是將來雲遷移的一部分,請讓我們參與其中!
-哈里森·豪威爾(Harrison Howell),客戶體驗軟件工程師
經SIOS許可轉載
我們很自豪地宣布推出適用於Linux 9.5版的SIOS保護套件。該產品引入了先進的自動化和可感知應用程序的監視功能,使其成為業界最全面的現成的SAP S / 4HANA集群軟件。
我們知道嘗試手動構建SAP S / 4HANA集群很麻煩,以確保所有HANA服務都將故障轉移到正確的位置並以正確的順序啟動。數小時的腳本編寫,測試和處理工作。賭注很高。弄錯了,可能意味著故障轉移不會發生或變得更糟–停機時間,數據丟失,大量加急的用戶通話。
因此,我們為使用HANA系統複製(HSR)的兩節點SAP S / 4HANA數據庫配置添加了智能應用程序可用性。我們構建此版本的目的是消除構建和管理集群的麻煩和風險。
從簡單的,嚮導驅動的配置開始,該配置實際上會驗證您的輸入。無需花費大量時間進行手動腳本編寫…或在出現問題時查找錯誤的按鍵。
它監視從應用程序到硬件,服務器和網絡的HANA堆棧中的所有進程-不僅檢查服務器是否像其他集群軟件一樣可操作。
與其他觸發所有故障轉移的群集解決方案不同,如果SIOS Protection Suite檢測到問題,它會自動採取適當的恢復操作–無論是只是重新啟動服務,在使用中的節點上進行恢復還是將故障轉移編排到輔助節點上節點。
說到故障轉移編排,它將自動確保始終保留特定於SAP的最佳實踐。例如,它可以確保在故障轉移或切換時,ASCS永遠不會位於具有主應用程序的服務器上或與ERS處於同一服務器上。
如果嚮導驅動的配置還不容易,我們還添加了新的命令行界面(CLI)克隆功能,通過導入CLI進行配置,您就可以部署SIOS集群。您還可以導出現有集群的CLI指令以創建其克隆。
現在,借助適用於Linux的SIOS Protection Suite,您可以快速輕鬆地創建高可用性群集,以保護任何應用程序。其中包括停機和災難造成的SQL Server,Oracle,SAP和S / 4HANA。
經SIOS許可轉載
NGINX是一個Web服務器,還可以充當負載平衡器,反向代理等。它們之間,NGINX和Apache一起提供了超過50%的網絡流量。 如今,許多公司正在使用Amazon Linux,Red Hat Linux和Ubuntu在Amazon EC2環境上運行其NGINX開源或NGINX Plus Web服務器。
每個人都同意,最佳做法是監視EC2上的NGINX之類的應用程序,并快速響應任何系統異常情況。 用戶期望其應用程序能夠快速訪問並保持正常運行時間。
許多公司正在部署Amazon CloudWatch來監視其應用程序,甚至通過開發腳本或使用AWS Lambda來創建某種程度的自動化。 但是,使用自定義指標正確配置Amazon CloudWatch並設置Amazon Lambda需要一定數量的技術專長,而這可能是許多公司所無法提供的。 然後,隨著應用程序的發展,維護任何腳本都需要付出成本和精力。
另一種選擇是部署應用程序性能監視(APM)解決方案,例如New Relic,Dynatrace,Datadog或LogicMonitor中的一種。 APM解決方案很棒。 他們在監視您的所有系統以及查明發生的情況和原因方面做得非常好。 他們創建可以與您的開發團隊共享並由您的開發團隊解釋的日誌,以重新創建問題並確保不再發生。 但是事情是這樣的:APM解決方案提供了許多您必須分類的數據(將“信號與噪音分離''),並且它們在故障發生時無法恢復。 在減少NGINX Web服務器的停機時間時,APM工具只是解決方案的一部分。
但是有些公司沒有內部人員或工具來自己監控EC2環境。這就是為什麼他們選擇將任務外包給託管服務提供商的原因。 與MSP一起管理環境有一些非常實際的好處,例如,隨著環境的擴展而不必僱用更多的員工,或者不必對團隊進行新技術培訓。 MSP可以提高投資效率,因為它們可以將其投資分散到許多客戶。 但是有缺點。 在某些情況下,您可能會陷入高額的固定成本合同,並且如果遇到問題並且必須逐步解決這些問題,成本可能會上升。 而且,您將失去監視環境的團隊與負責構建和部署應用程序的團隊之間的連續性。
無論您是選擇投資APM解決方案還是將其外包給MSP,您都仍然需要考慮在發生故障時以及從故障停機時恢復NGINX Web服務器的速度。 我們想提出另一種選擇:使用SOIS AppKeeper進行自動修復。
我們的許多客戶都選擇使用SIOS AppKeeper來保護其NGINX Web服務器。 儘管他們可以選擇標準的應用程序性能監視(APM)解決方案或第三方監視解決方案,但他們選擇依靠AppKeeper來自動恢復服務或發生故障的整個EC2實例。 我們將看一下其中的一些原因,並與您分享一個簡短的視頻,展示AppKeeper如何與NGINX一起使用。
SIOS AppKeeper是一項SaaS服務,易於安裝和配置並監視在Amazon EC2上運行的任何應用程序,例如NGINX Web服務器及其“ nginx”,“緩存管理器”和“工作程序”服務。 當檢測到異常時,AppKeeper會自動重新啟動服務,如果該操作不起作用,它將重新啟動整個實例。 無需再仔細閱讀痛苦的日誌以查明失敗的原因,或升級到開發人員以重新啟動服務或昂貴的外包費用。 AppKeeper提供了“設置並忘記”功能,因此您可以放心知道NGINX Web服務器正在遵循EC2監視最佳實踐並且運行正常,或者如果遇到任何問題將很快重啟。
如今,數百家公司依靠AppKeeper來保持其云環境正常運行。 我們邀請您觀看此快速視頻,以演示AppKeeper如何保護NGINX Web服務器。
如果您想親自嘗試SIOS AppKeeper,我們提供14天的免費試用期。 只需單擊此處進行註冊。
隨著AWS在雲市場中佔據主導地位,許多公司正在使用Amazon AWS將其本地系統遷移到雲中。 那麼,應該如何管理在AWS環境中運行的系統?
在此博客文章中,我們將介紹AWS提供的監視服務Amazon CloudWatch的功能,以及實現它的挑戰以及如何解決它們。
為了確保您擁有穩定的雲環境,快速檢測異常(“系統損害”)並及時做出響應非常重要。 對於任何遷移到雲的組織而言,監視已成為一項重要且必要的任務。 這與管理本地應用程序和基礎結構沒有什麼不同。那麼,您應該如何在AWS環境中進行監控?一種選擇是使用Amazon CloudWatch,它監視CPU,內存和磁盤使用情況,並在超過預定閾值時通知您。 另外,您可以設置自己的指標來監視各種項目,例如應用程序日誌。
關於Amazon CloudWatch的最好之處在於,它是AWS本身提供的一項服務。 它與Amazon EC2和其他AWS服務具有很高的親和力,因此它可以快速響應頻繁的功能擴展和規範更改,並可以輕鬆支持AWS Auto Scaling,後者會根據負載自動增加或減少資源。 Amazon CloudWatch可根據每種環境的獨特情況提供精確的監控。
儘管Amazon CloudWatch非常適合擁有經驗豐富的雲工程師和DevOps團隊的組織,但一般用戶應該注意一些事項。
Amazon CloudWatch可有效監視組織的AWS環境,但它需要一定水平的技能和知識來配置和部署。 尤其是當您設置自己的指標,設置警報或考慮到Auto Scaling時,複雜性會增加。 例如,如果要設置監視,這很容易,但是如果要設置電子郵件,重新啟動,自動縮放等,則可能會遇到困難,具體取決於資源情況。
如果您要使用“發生錯誤時重新啟動服務器”之類的指示來自動化恢復過程,則必須首先使用AWS Lambda腳本創建恢復方案,該腳本提供了有關條件和要採取的措施的詳細說明。 您的團隊對AWS Lambda有多熟悉?
Amazon CloudWatch的主要優點是您可以密切監視您的環境,但是要做到這一點,您必須事先為每個系統正確設計要監視的項目以及何時監視閾值等。 這些設計任務可能會花費很多時間。 當然,您的關鍵任務系統需要以這種方式進行嚴密監視,但是這種詳細程度和復雜程度並不適合所有系統。對於某些網站,例如內部網站或WordPress服務器,您將希望最大程度地降低運營和人工成本。在這種情況下,我們建議您考慮使用一種更易於操作和管理的工具。
對於非關鍵任務應用,我們建議使用SIOS Technology的SIOS AppKeeper。 AppKeeper易於安裝和配置,並可監視在EC2實例上運行的應用程序的服務(進程)。 當檢測到錯誤時,AppKeeper會自動重新啟動服務,並在必要時重新啟動實例。 即使是初次遷移到雲的用戶也可以設置AppKeeper來監視其EC2實例並自動恢復,而無需具備複雜的腳本編寫技能。
使用AppKeeper,無需選擇要監視的單個服務。您只需選擇要監視的EC2實例以及要自動執行的操作即可。 您始終可以更詳細地了解要監視哪些服務以及如何監視這些服務,但是AppKeeper的設計使其易於配置。 當檢測到錯誤或從中自動恢復錯誤時,會記錄並存儲故障日誌,以便以後可以調查故障原因。
建議您不要根據Amazon SLA和恢復要求清點環境清單,而要使用SIOS AppKeeper監視您想減少運營開銷的系統和應用程序,而不是使用Amazon CloudWatch來密切監視AWS環境中的所有內容。
請繼續關注未來的博客文章,我們將更詳細地比較如何設置CloudWatch和AppKeeper以執行相同的功能。