SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

6常見的雲遷移挑戰

by Leave a Comment

6常見的雲遷移挑戰

作為提供SIOS客戶體驗的軟件工程師，我經常幫助那些將其內部高可用性群集環境遷移到雲的公司。

雲遷移是一個過程，而不是目標。當我們吸引客戶過渡到雲時，通常是在計劃過程的後期，這不是理想的選擇，但在雲遷移中卻並非罕見。以下是我們經常看到的六個雲遷移挑戰。

  1. 時間–了解將數據傳輸到雲需要多長時間

    將您的數據從本地部署到雲需要多長時間？根據您的應用程序，數據類型和雲提供商的不同，它可能會有很大的不同。一個經常被忽略的細節是將數據從主節點同步到輔助節點，有時甚至同步到災難恢復（DR）站點所需的時間。不考慮重新同步時間的客戶在數據複製時會費時費力。

  2. 成本–了解雲內數據傳輸的成本影響

    在雲區域內的數據傳輸是免費的。區域之間的數據傳輸將產生費用。通常，我們看到的架構中，主節點和輔助節點位於一個區域內的單獨雲可用性區域中。引入災難恢復站點時，成本可能會大大增加，因為災難恢復站點將始終位於另一個區域。SAP NetWeaver等數據豐富的應用程序的災難恢復可能會抑制跨區域複製的成本。

  3. 區域間複製

    區域間複製帶來了另一個挑戰：複製類型。可用區內的異步或同步複製由客戶的RTO和RPO要求確定。無論實例大小如何，跨區域之間進行數據複製時都會遇到一些延遲。SIOS建議在區域之間進行異步複製，以減少該延遲的影響。 並發實驗室提供了一些有關EC2區域之間的延遲的有見地的信息。

    雲遷移並發實驗室

  4. 雲配置怪癖

    可以從雲中部署現成的OS映像。這種便利需要付出一定的代價，這為配置管理引入了另一個因素。SuSE Enterprise Linux映像中包含的針對雲進行了優化的cloud-init服務可以刪除用戶定義的虛擬IP地址。沒有什麼能像阻止虛擬IP地址每兩分鐘消失一樣阻止PoC了！

  5. 雲安全

    雲計算的規模提供了比企業在本地數據中心中提供的更高的安全性。雲工作負載甚至不知道就利用了尖端的安全性。例如，默認情況下，AWS EC2實例會阻止實例本身未發送或未發送給實例本身的任何流量。這是確保云中網絡安全的重要功能。如果系統需要網絡地址轉換（NAT），則EC2的默認安全措施將導致IP地址失敗。從控制台禁用源/目的地檢查將解決此問題。根據用戶對AWS的熟悉程度，這可能需要幾次點擊到幾次支持電話之間。了解系統如何在環境中進行交互的細節是成功進行雲遷移的關鍵。

  6. 雲用戶驗收測試（UAT）

    需要提醒來自本地系統的客戶，資源不再是限制因素。在雲中，可以毫不費力地複制系統並在生產環境中隔離運行，這在內部部署中並不簡單。按需訪問IT資源允許HA和DR的UAT擴展到“關閉主節點”之外。網絡可能遭到破壞，內核可能會崩潰，甚至數據庫也可能損壞，而這些都不會影響生產！識別和測試這些方案可以改善HA和DR的狀態。

執行成功的雲遷移需要所有利益相關者的投入。高可用性和災難恢復是任何企業工作負載的核心方面。無論SIOS已經是您當前系統的一部分，還是將來雲遷移的一部分，請讓我們參與其中！

-哈里森·豪威爾（Harrison Howell），客戶體驗軟件工程師

經SIOS許可轉載

適用於Linux 9.5版的SIOS保護套件就在這裡！

by Leave a Comment

適用於Linux 9.5版的SIOS保護套件就在這裡！

我們很自豪地宣布推出適用於Linux 9.5版的SIOS保護套件。該產品引入了先進的自動化和可感知應用程序的監視功能，使其成為業界最全面的現成的SAP S / 4HANA集群軟件。

我們知道嘗試手動構建SAP S / 4HANA集群很麻煩，以確保所有HANA服務都將故障轉移到正確的位置並以正確的順序啟動。數小時的腳本編寫，測試和處理工作。賭注很高。弄錯了，可能意味著故障轉移不會發生或變得更糟–停機時間，數據丟失，大量加急的用戶通話。

因此，我們為使用HANA系統複製（HSR）的兩節點SAP S / 4HANA數據庫配置添加了智能應用程序可用性。我們構建此版本的目的是消除構建和管理集群的麻煩和風險。

SIOS Protection Suite v9.5可以自動化和監視

從簡單的，嚮導驅動的配置開始，該配置實際上會驗證您的輸入。無需花費大量時間進行手動腳本編寫…或在出現問題時查找錯誤的按鍵。

它監視從應用程序到硬件，服務器和網絡的HANA堆棧中的所有進程-不僅檢查服務器是否像其他集群軟件一樣可操作。

與其他觸發所有故障轉移的群集解決方案不同，如果SIOS Protection Suite檢測到問題，它會自動採取適當的恢復操作–無論是只是重新啟動服務，在使用中的節點上進行恢復還是將故障轉移編排到輔助節點上節點。

說到故障轉移編排，它將自動確保始終保留特定於SAP的最佳實踐。例如，它可以確保在故障轉移或切換時，ASCS永遠不會位於具有主應用程序的服務器上或與ERS處於同一服務器上。

如果嚮導驅動的配置還不容易，我們還添加了新的命令行界面（CLI）克隆功能，通過導入CLI進行配置，您就可以部署SIOS集群。您還可以導出現有集群的CLI指令以創建其克隆。

現在，借助適用於Linux的SIOS Protection Suite，您可以快速輕鬆地創建高可用性群集，以保護任何應用程序。其中包括停機和災難造成的SQL Server，Oracle，SAP和S / 4HANA。

要求免費試用

經SIOS許可轉載

EC2監控最佳實踐：使用SIOS AppKeeper保護Amazon EC2上的NGINX Web服務器

by Leave a Comment

NGINX是一個Web服務器，還可以充當負載平衡器，反向代理等。它們之間，NGINX和Apache一起提供了超過50％的網絡流量。  如今，許多公司正在使用Amazon Linux，Red Hat Linux和Ubuntu在Amazon EC2環境上運行其NGINX開源或NGINX Plus Web服務器。

每個人都同意，最佳做法是監視EC2上的NGINX之類的應用程序，并快速響應任何系統異常情況。  用戶期望其應用程序能夠快速訪問並保持正常運行時間。

在Amazon EC2上監視NGINX Web服務器的當前選擇

許多公司正在部署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：EC2上NGINX Web服務器的自動修復

我們的許多客戶都選擇使用SIOS AppKeeper來保護其NGINX Web服務器。  儘管他們可以選擇標準的應用程序性能監視（APM）解決方案或第三方監視解決方案，但他們選擇依靠AppKeeper來自動恢復服務或發生故障的整個EC2實例。  我們將看一下其中的一些原因，並與您分享一個簡短的視頻，展示AppKeeper如何與NGINX一起使用。

SIOS AppKeeper是一項SaaS服務，易於安裝和配置並監視在Amazon EC2上運行的任何應用程序，例如NGINX Web服務器及其“ nginx”，“緩存管理器”和“工作程序”服務。  當檢測到異常時，AppKeeper會自動重新啟動服務，如果該操作不起作用，它將重新啟動整個實例。  無需再仔細閱讀痛苦的日誌以查明失敗的原因，或升級到開發人員以重新啟動服務或昂貴的外包費用。  AppKeeper提供了“設置並忘記”功能，因此您可以放心知道NGINX Web服務器正在遵循EC2監視最佳實踐並且運行正常，或者如果遇到任何問題將很快重啟。

Wistia視頻縮略圖

如今，數百家公司依靠AppKeeper來保持其云環境正常運行。  我們邀請您觀看此快速視頻，以演示AppKeeper如何保護NGINX Web服務器。

如果您想親自嘗試SIOS AppKeeper，我們提供14天的免費試用期。  只需單擊此處進行註冊。

什麼是Amazon CloudWatch？

by Leave a Comment

什麼是Amazon CloudWatch

 

什麼是Amazon CloudWatch？

您可以使用CloudWatch做什麼以及需要考慮的一些障礙

隨著AWS在雲市場中佔據主導地位，許多公司正在使用Amazon AWS將其本地系統遷移到雲中。  那麼，應該如何管理在AWS環境中運行的系統？

在此博客文章中，我們將介紹AWS提供的監視服務Amazon CloudWatch的功能，以及實現它的挑戰以及如何解決它們。

使用Amazon CloudWatch密切監視您的AWS環境

為了確保您擁有穩定的雲環境，快速檢測異常（“系統損害”）並及時做出響應非常重要。  對於任何遷移到雲的組織而言，監視已成為一項重要且必要的任務。  這與管理本地應用程序和基礎結構沒有什麼不同。那麼，您應該如何在AWS環境中進行監控？一種選擇是使用Amazon CloudWatch，它監視CPU，內存和磁盤使用情況，並在超過預定閾值時通知您。  另外，您可以設置自己的指標來監視各種項目，例如應用程序日誌。

關於Amazon CloudWatch的最好之處在於，它是AWS本身提供的一項服務。  它與Amazon EC2和其他AWS服務具有很高的親和力，因此它可以快速響應頻繁的功能擴展和規範更改，並可以輕鬆支持AWS Auto Scaling，後者會根據負載自動增加或減少資源。  Amazon CloudWatch可根據每種環境的獨特情況提供精確的監控。

Amazon CloudWatch實施挑戰

儘管Amazon CloudWatch非常適合擁有經驗豐富的雲工程師和DevOps團隊的組織，但一般用戶應該注意一些事項。

Amazon CloudWatch可有效監視組織的AWS環境，但它需要一定水平的技能和知識來配置和部署。  尤其是當您設置自己的指標，設置警報或考慮到Auto Scaling時，複雜性會增加。 例如，如果要設置監視，這很容易，但是如果要設置電子郵件，重新啟動，自動縮放等，則可能會遇到困難，具體取決於資源情況。

如果您要使用“發生錯誤時重新啟動服務器”之類的指示來自動化恢復過程，則必須首先使用AWS Lambda腳本創建恢復方案，該腳本提供了有關條件和要採取的措施的詳細說明。  您的團隊對AWS Lambda有多熟悉？

Amazon CloudWatch的主要優點是您可以密切監視您的環境，但是要做到這一點，您必須事先為每個系統正確設計要監視的項目以及何時監視閾值等。  這些設計任務可能會花費很多時間。  當然，您的關鍵任務系統需要以這種方式進行嚴密監視，但是這種詳細程度和復雜程度並不適合所有系統。對於某些網站，例如內部網站或WordPress服務器，您將希望最大程度地降低運營和人工成本。在這種情況下，我們建議您考慮使用一種更易於操作和管理的工具。

SIOS AppKeeper，用於監視在AWS上運行的操作系統和應用程序服務

對於非關鍵任務應用，我們建議使用SIOS Technology的SIOS AppKeeper。  AppKeeper易於安裝和配置，並可監視在EC2實例上運行的應用程序的服務（進程）。  當檢測到錯誤時，AppKeeper會自動重新啟動服務，並在必要時重新啟動實例。  即使是初次遷移到雲的用戶也可以設置AppKeeper來監視其EC2實例並自動恢復，而無需具備複雜的腳本編寫技能。

使用AppKeeper，無需選擇要監視的單個服務。您只需選擇要監視的EC2實例以及要自動執行的操作即可。  您始終可以更詳細地了解要監視哪些服務以及如何監視這些服務，但是AppKeeper的設計使其易於配置。  當檢測到錯誤或從中自動恢復錯誤時，會記錄並存儲故障日誌，以便以後可以調查故障原因。

使用AppKeeper進行AWS EC2監控

建議您不要根據Amazon SLA和恢復要求清點環境清單，而要使用SIOS AppKeeper監視您想減少運營開銷的系統和應用程序，而不是使用Amazon CloudWatch來密切監視AWS環境中的所有內容。

請繼續關注未來的博客文章，我們將更詳細地比較如何設置CloudWatch和AppKeeper以執行相同的功能。

了解有關SIOS AppKeeper的更多信息

註冊免費試用SIOS AppKeeper

 

測試/質量保證系統是企業可用性的關鍵部分

by Leave a Comment

測試/質量保證系統是企業可用性的關鍵部分

測試/質量保證系統是企業可用性的關鍵部分

“我可以吻你，”這就是三十年前一個朋友向我衝來時對我脫口而出的意思。在前往我們地區最大的樂隊比賽之一的途中，她已將簧片放到薩克斯管上。我不知道它們是誰，但是當我看到一堆蘆葦在公交車上的座位上時，我把它們撿起來，帶他們去了暖身區。熱身三分鐘後，她的第一個簧片破裂了，當她伸手去拿空口袋進行替換時，她驚慌失措。當我找到我發現它們的管道時，她脫口而出：“我現在可以吻你。”

擔任SIOS Technology Corp.客戶體驗副總裁 在可用性頻譜的不同階段，我與許多企業客戶和合作夥伴一起工作感到非常獨特和獨特。有時，我有機會與最終客戶一起解決問題，緩解問題和進行改進。在其他時候，我們的團隊會與合作夥伴和客戶積極合作，以設計和實現企業可用性，以保護其係統免於停機。最近的一次客戶體驗使我想起了大約30年前發生的一件事情，當時我的朋友脫口而出：“我可以吻你。”

我和我的團隊正在打客戶電話。通話從平時的歡愉，介紹和對客戶企業環境的概述開始。通話30分鐘後，一切進展順利。他們的體系結構紮實，周到並且記錄良好。他們的團隊知識淵博，技術精湛，經驗豐富。但是隨後，客戶暗示，由於節省了成本，他們將不打算維護專用的測試/質量系統。我深吸了一口氣。  實際上，這更像是呼氣，就像是從腸子上沖來的空氣一樣。我準備做出回應，但在此之前，我的聲音就爆發了。  “停機的首要原因是缺乏流程，”合作夥伴代表架構師在與我們的電話中大聲喊道。經過短暫的開玩笑，客戶同意維護測試/ QA系統，我差點脫口而出：“我可以親你！”

在許多企業部署的前線（新系統，數據中心遷移和系統更新）中，我在支持和服務部門的團隊已經看到許多問題，這些問題可以通過利用測試系統/群集來解決。

測試/質量系統是避免停機的HA策略的重要組成部分。與維護企業部署相關的常見任務（例如補丁，更新和配置更改）存在風險。巨大的風險。

通常在生產中進行測試的風險包括幾個嚴重的潛在災難性問題： 

  • 數據損壞或無效
  • 受保護的數據洩漏
  • 錯誤的收入確認（取消的訂單等）
  • 重載系統
  • 對其他生產系統的意外副作用或影響
  • 錯誤率高，可觸發警報並呼叫人員
  • 偏斜的分析（流量漏斗，A / B測試結果等）
  • 充滿腳本和漫遊器活動的不正確流量日誌（a）

如果客戶嘗試在生產中進行風險較大的更改，則結果可能會非常有害。除了上面列出的那些故障之外，還有更多的停機時間風險，應用程序安裝損壞，以及在某些情況下不可逆轉的損壞。以客戶X（在製造業中知名的SAP Enterprise商店）為例。

在從信譽良好的站點上讀取緊急通知後，OS管理員迅速將其生產節點更新為可用的最新內核更新。在數小時內，生產節點開始了一系列未啟動的崩潰和內核崩潰。他急忙安裝了與他的配置不兼容的內核。現有應用程序軟件包，設備，文件系統和相關軟件包的組合。這導致生產中斷，並向多個供應商幾次高優先級升級。

將補丁程序應用於測試/ QA或沙箱系統時，可以管理和驗證補丁程序和關鍵修訂，以減少生產力損失和計劃外停機。在類似生產的環境中測試應用程序使您能夠發現無法預料的問題，並在這些問題對您的操作產生不利影響之前進行糾正。產前設計和測試消除了代價高昂的業務中斷，改善了客戶體驗並保護了品牌。

使用測試質量檢查系統改善生產可用性和過程

這些是使用測試/質量檢查系統可以改善生產可用性和過程的基礎知識。 與生產環境類似的受控環境（必須與生產環境盡可能相似）必須具有以下功能：

  1. 測試內核更新和安全更新
  2. 驗證設置和配置調整
  3. 重現生產問題並測試軟件更新和補丁
  4. 驗證應用程序版本兼容性，並減少由於不兼容的更改而導致停機的風險
  5. 提供一個安全的空間來練習和修訂上線，維護，中斷和其他企業程序活動
  6. 在不影響企業客戶的情況下培訓新員工和團隊成員

如果您具有用於部署關鍵企業可用性軟件的測試/質量檢查環境，我現在可以親吻您。有了這種環境，您的團隊就可以“測試，驗證和驗證（2）”體系結構，業務需求，用戶場景，以及與與生產環境最相似的一個系統或一組系統的一般集成-您知道賺錢。當然，您仍然必須安排窗口來維護生產系統並在其上執行測試，但是要在這之間完成一個安全的緩衝步驟之後。

—客戶體驗副總裁Cassius Rhue

————-

參考文獻：

  1. https://opensource.com/article/19/5/dont-test-production已訪問2020年5月4日
  2. https://www.softwaretestingclass.com/system-testing-what-why-how/訪問時間：5/4/2020