| 18 12 月, 2020 |
計算雲中的應用程序可用性
計算雲中的應用程序可用性在雲中部署關鍵業務應用程序時，您要確保它們具有高可用性。 好消息是，如果您進行適當的計劃，則可以實現99.99％（4-nines）的可用性或更高。 但是，計算您的真實可用性可能並不像看起來那樣簡單。 在考慮可用性時，您必須考慮使訪問應用程序成為可能的關鍵組件，我將其稱為可用性鏈。 可用性鏈的組成部分是：
您的應用程序只有最弱的鏈接才可用，並且您向鏈中添加的每個其他鏈接的停機時間都會成倍增加。讓我們檢查每個鏈接。 計算可用性三個主要的雲服務提供商中的每一個都有一些相似之處。 這三個平台的共同點是它們將致力於計算的服務級別協議（SLA）。 當您在不同可用性區域中配置了兩個或多個VM時，所有三個VM的公共雲提供商的SLA為99.99％。請記住，此SLA僅保證在任何給定時間對其中一個VM的遠程訪問，它不保證VM內運行的服務或應用程序的可用性。如果在單個數據中心內部署單個VM，則此SLA的範圍從“每小時90％”（AWS）到99.5％（Azure和GCP）或99.9％（使用Premium SSD時，Azure單個VM）。 真正的高可用性從99.99％開始，因此第一步是確保您的應用程序可用，是確保該應用程序分佈在兩個或多個跨越可用區的VM中。 通過將兩個VM分佈在兩個可用區中，可以為您提供至少其中一個VM的99.99％的可用性，您可以得出以下理論：如果三個VM分佈在三個可用區中，則您的可用性將甚至超過99.99％。 儘管雲提供商的SLA永遠不會保證可用性超過99.99％（無論使用的可用性區域有多少），但是如果您使用純統計信息，您可能會得出結論，您的可用性可能會高達99.999999％或8尼茲。可用性，每月停機時間為26.30毫秒。 1-（。0001 * .0001）= .99999999 具有三個可用區的99.999999％可用性？ 不要四處引用那個數字。 但是請記住，如果兩個可用性區域可以為您提供99.99％的可用性，這是有道理的。 可以肯定地說，三個可用區將為您提供超過99.99％的可用性。 計算只是可用性鏈中的一個環節。 我們仍然必須解決網絡，存儲和其他相關服務，這些都代表了可能的故障點。 網絡可用性為了使您的應用程序可用，客戶端與應用程序之間的每個網絡躍點以及應用程序依賴的所有資源都必須可用，並且必須在可容忍的延遲範圍內工作。 您需要了解數據庫服務器，應用程序服務器，Web服務器和客戶端之間的網絡鏈接，以準確了解網絡可能在哪裡發生故障。 請記住，可用性鏈中的鏈接越多，總體可用性就越低。 儘管標準計算SLA涵蓋了同一vNet中虛擬機之間的網絡可用性，但是您可能仍在使用其他網絡服務。 這只是您可能會使用的網絡服務的一些示例，這些示例會影響整體應用程序的可用性。 快速路線– 99.95％ 基於到目前為止所學的知識，讓我們看一下跨兩個可用區部署的應用程序的可用性。 99.99％的計算可用性 99.99％負載均衡器可用性 .9999 * .9999 = .9998 99.98％的可用性=每月約9分鐘的停機時間 既然我們已經解決了計算和網絡可用性問題，那麼讓我們繼續進行存儲。 存儲空間現在這裡是故事多毛的地方。 看一下以下存儲SLA https://azure.microsoft.com/zh-CN/support/legal/sla/storage/v1_5/ https://cloud.google.com/storage/sla https://aws.amazon.com/compute/sla/ 顯然，Azure和Google在塊存儲解決方案上提供了99.9％的SLA。 AWS在這裡沒有特別提及EBS。 他們只談論虛擬機，並按小時而不是其他雲提供商那樣按月衡量其單實例虛擬機的可用性。 為了便於討論，讓我們使用Azure和GCP均已發布的99.9％可用性保證。 在前面的示例的基礎上，讓我們為方程式添加一些存儲空間。 99.99％的計算可用性 99.99％負載均衡器可用性 99.9％託管磁盤 .9999 * .9999 * .999 = .9988 99.88％的可用性=每月約53分鐘的停機時間。 53分鐘的停機時間比我們在先前示例中計算的9分鐘的停機時間要長得多。 我們如何才能最大程度地降低99.9％的存儲可用性的影響？ 我們必須在存儲中建立更多的冗餘！ 幸運的是，在計劃應用程序可用性時，我們通常會包括存儲冗餘。 例如，當我們站起Web服務器時，每個Web服務器通常會將數據存儲在本地連接的磁盤上。 部署域控制器時，Microsoft Active Directory負責在所有域控制器之間複製AD信息。 對於類似SQL Server的情況，我們利用AlwaysOn可用性組或SIOS DataKeeper來保持數據在本地連接的磁盤之間的同步。 我們跨不同可用性區域分佈的數據副本越多，我們越有可能倖免於難。 例如，將數據存儲在不同可用性區域中的兩個不同磁盤上的應用程序將受益於冗餘，而不是99.9％的可用性，它更有可能實現99.9999％的存儲可用性。 1 –（.001 * .001）= .999999 如果將其放到先前的方程式中，圖片將開始看起來更亮一些。 .9999 * .9999 * .999999 = .9998 通過跨多個可用區（因此跨多個磁盤）複製數據，我們有效地減輕了與雲存儲相關的停機時間。 應用程序和相關服務的可用性您已盡力確保計算，網絡和存儲的可用性。 但是應用程序本身呢？ 某些應用程序可以通過在同一應用程序的多個實例之間進行負載平衡來橫向擴展並提供冗餘。 想想典型的Web服務器場，您通常可以在其中平衡五台服務器之間的Web請求。 如果您丟失一台服務器，則負載平衡器僅將其從旋轉中刪除，直到再次響應為止。 其他應用程序則需要更多的維護和監視。 以SQL Server為例。 通常，“始終在線可用性組”或“故障轉移群集實例”用於監視數據庫可用性，並在數據庫由於應用程序或系統級故障而變得無響應時使用恢復操作。 儘管沒有針對SQL Server可用性解決方案的已發布SLA，但通常公認的是，如果將SQL Server正確配置為具有高可用性，則SQL Server可以提供99.99％的可用性。 您可能依賴於其他基於雲的服務，例如託管的Active Directory，託管的DNS，微服務，甚至雲門戶本身的可用性都應納入整體可用性方程中。 概要應用程序可用性是所有活動部分的總和。 僅在一個區域中跳過會成倍地影響應用程序的整體可用性。 花點時間研究可用性鏈中的所有鏈接是否存在漏洞，包括計算，網絡，存儲，應用程序和相關服務。 總的來說，這裡列出的數字是最壞的情況，希望您的實際可用性超過已發布的SLA。 做好家庭作業，並提防任何不能保證99.99％可用性的服務，這是被認為具有高可用性的典型閾值。 本文未解決人為錯誤和安全問題。 您可以使您的應用程序盡可能地高可用性。 但是，如果您尚未採取措施保護應用程序免受外部威脅和愚蠢的人為錯誤，那麼在可用性方面，所有賭注都沒有了。 |
||||
| 11 12 月, 2020 |
使用Datadog進行Amazon EC2監控？ 與SIOS AppKeeper配對以進行自動修復 |
5， 定義警報條件
| {
“ instanceId”：“ {{EC2實例ID}}”， “名稱”：“ nginx” } |
自定義標題：選中該複選框並輸入以下內容
| { “內容類型”：“應用程序/ json”， “ accept”：“ application / json”， “ appkeeper-integration-token”：“ {{獲取AppKeeper外部集成令牌}}中獲得的令牌” } |
完成後，按“保存”。
第八步：將AppKeeper連接到綜合測試
接下來，我必須配置AppKeeper（註冊的Webhooks集成），以便在發生Synthetics監視警報時調用它。
從菜單的“ UX監視”>“綜合測試”中打開在“使用Datadog配置綜合監視”中設置的測試用例。
從右上方的變速箱中選擇“編輯測試詳細信息”，然後在“ 5.輸入以下值”中輸入以下值。 通知您的團隊”框以保存更改。
| @webhook-{{Datadog中Webhook集成的名稱}} |
※您可以設置“如果顯示器尚未解決則重新通知”。如果AppKeeper第一次無法恢復，則可以重試。測試不是必需的，但是我們建議您將其設置為（[10 minutes]最小間隔）。
安裝完成。
第九步：通過再次運行測試來確認集成
然後，我確認如果Datadog檢測到它關閉，AppKeeper將還原Web服務器。
打開您剛剛從Datadog中的UX監視>綜合測試中設置的綜合監視測試用例。
單擊右上角的“恢復測試”，然後打開“合成”監視。
現在，Datadog將定期執行Synthetics監視。
測試結果表明服務器已成功訪問。
接下來，我創建了網絡服務器的偽故障，以測試AppKeeper的自動修復。
由於很難造成真正的失敗，因此我停止了該服務，並造成了無法查看網頁的情況。為此，我連接到使用SSH安裝Nginx服務器並停止Nginx的EC2實例。
| sudo systemctl停止nginx |
短暫等待後，Datadog檢測到Web服務器不再可訪問。
Datadog中的“綜合測試”頁面還顯示測試用例失敗。
如果測試用例失敗，Datadog將通知AppKeeper Synthetics監視失敗。
當AppKeeper收到通知時，它將自動嘗試重新啟動Nginx。
因此，如果您稍等片刻，就會發現Datadog的Synthetics監控檢查將再次通過。
另外，如果您登錄到AppKeeper儀表板，則會看到恢復已執行。
–
在本練習中，我以Web服務器（Nginx）為例，通過Datadog自動執行檢測故障並通過AppKeeper恢復服務的過程。
通過將Datadog與EventBridge和Lambda集成或創建自定義腳本，可以實現類似的自動化。
但是，如果您經常添加目標實例或重新啟動各種服務，則維護EventBridge和Lambda或腳本的成本和復雜性將會增加。
AppKeeper已與Datadog進行了可靠的集成，並且您可以輕鬆地將目標實例添加到應用程序中，從而可以輕鬆地將自動化添加到DevOps環境中以減少停機時間。
如果您當前正在使用Datadog，並且想試用AppKeeper的Restart API，請先在此處註冊我們的14天免費試用版（安裝免費試用版後即可購買訂閱）。然後單擊此處以請求免費試用。 我們將引導您完成整個過程，並為您提供免費的評估令牌，以幫助您入門。
申請評估令牌
謝謝。我希望您能藉此機會更多地了解SIOS AppKeeper，它可以自動監視和恢復在EC2上運行的應用程序。
-SIOS Technology技術團隊的Tatsuya Hirao。
經SIOS許可轉載
5個跡象表明，要修復高可用性，需要花費比博客文章更多的時間
5個跡象表明，要修復高可用性，需要花費比博客文章更多的時間
標誌在那裡。 警告燈閃爍。在您的直覺中，您可以感覺到它。 也許你睡不著您的高可用性問題很深。 但是，也許您不太確定。
1.如果您認為雲SLA是高可用性所需的全部
雲解決方案在提高硬件可用性和彈性方面取得了巨大進步。 但是，應用程序高可用性不僅需要選擇正確的管理程序或云提供商，還需要更多。 雲或虛擬化提供商提供的SLA不能阻止您的高可用性策略。 正如Wired所引用的那樣，“ 2011年4月近四天的Amazon中斷並未違反Amazon的EC2 SLA，正如FAQ所解釋的那樣，“保證了在365年內某個區域內99.95％的服務可用性。”在這篇DZone文章中，我們自己的David Bermingham詳細細分了雲SLA和應用程序可用性之間的差異。 如果您想要一個高度可用的基礎架構，則它還必須包括在數據和應用程序層的監視，恢復和彈性。
2.如果您僅使用開源操作系統隨附的高可用性群集
如果是這樣，那麼您很可能沒有根據與操作系統捆綁在一起的數據庫來選擇數據庫，那麼為什麼僅根據該標準選擇HA解決方案。 捆綁的工具在提供額外的保證，可能性和功能方面大有幫助。 但是，儘管易於訪問，捆綁的工具和OS群集軟件並不總是能夠滿足您的SLA，RPO，RTO和可用性要求。 如果您的企業具有操作系統的組合，則您的團隊可能需要導航不同工具並了解它們如何集成在一起的幫助。 這就好比選擇樹籬修剪器，然後將路left割草機推到路緣石上，在13洞5杆洞（奧古斯塔）上塑造“杜鵑花”形狀。 兩台割草機都旨在割草，但是您有多少時間？ 您將如何處理複雜性？ 您會信任哪個？ 您的高可用性策略所需要的不只是考慮與操作系統捆綁在一起的便利性，否則，您將運行MySQL而不是SAP HANA。
3.如果您認為企業應用程序許可（例如SQL Enterprise或Oracle Enterprise）與企業高可用性相同
除了增加成本外，許多企業應用程序許可證還提高了應用程序在某些高可用性方案中恢復的能力。 但是，整個企業極不可能基於單個應用程序。 您的高可用性不僅需要高可用性的數據庫解決方案。 您將需要一個企業級應用程序監視和恢復解決方案，該解決方案需要對所有應用程序和數據庫的廣泛支持。 此外，您不僅需要管理和復制數據庫數據的能力，還需要管理和復制關鍵應用程序和配置數據的能力。 單個數據庫或簡單應用程序的可用性是一回事，但是複雜，多部分應用程序和支持數據庫的HA卻大不相同。 在故障轉移/切換之前，期間和之後，需要提供更多的服務，需要協調的更多部分，要協調的更複雜的體系結構，要遵循的更具體的最佳實踐。 超出您企業許可證所支付的價格。
4.如果您的停機時間在增加，而停機時間在減少
在許多領域，生活的節奏都在不斷增加。 您的團隊最後一次從備份中恢復，手動重新啟動被認為是關鍵的應用程序或重新啟動一組故障的虛擬機或節點是什麼時候？ 中斷事件的速度不能繼續超過可持續性，或者您的團隊有能力從消防轉向防火和防火。 “你只能跑那麼久這麼久（Carey Nieuwhof）。”對於某些人來說，您交火已經太久了，而且停機時間比正常運行時間更為普遍。
5.如果您的第一個故障轉移測試是在生產服務器上
最近的一位客戶指出，不可能針對每種可能的災難情況進行測試。 隨著新軟件的創建，部署，更新和修補，更高可用性方面的挑戰越來越大。 但是，您的實時生產數據不是找出不能一起很好發揮作用的地方。 儘管Go-Live和Post-Go-Live總是會帶來很多驚喜，但是無法真正進行故障轉移和在備份節點上運行不應是其中之一。
精練博客可以為您提供有用的提示和見解，以定義，重新定義和提高您的更高可用性。 但是，如果警告信號消失了，您已經用某種“足夠”來換取了真正的可用性，那麼修復該問題所需要的不僅僅是博客文章，或者是在可用性世界中搜尋每篇博客文章來解決的問題。您的醫管局。
–客戶體驗副總裁Cassius Rhue
經SIOS許可轉載
9個跡象表明您存在應用程序可用性問題
SIOS AppKeeper現在可在AWS Marketplace中使用
SIOS AppKeeper現在可在AWS Marketplace中使用
使您可以更輕鬆地在您的DevOps環境中添加自動修復。
今天，我們很高興地宣布，我們的SIOS AppKeeper解決方案現已在AWS Marketplace上提供，AWS Marketplace是一個數字目錄，其中包含來自獨立軟件供應商的數千個軟件清單，可輕鬆查找，測試，購買和部署在Amazon Web Services上運行的軟件（AWS）。 現在，最終用戶和AWS Partner Network（APN）成員比以往任何時候都更容易嘗試，獲取和部署SIOS AppKeeper，以向其DevOps環境添加自動修復。單擊此處以在AWS Marketplace中查看AppKeeper。
SIOS AppKeeper持續監視和保護您在Amazon EC2上運行的應用程序。 自2017年以來，我們一直在日本銷售AppKeeper，並於今年初將SaaS服務推向了美國市場。我們創建AppKeeper是為了響應我們從遷移到雲的客戶那裡聽到的需求，他們關心的是減少潛在的停機時間，同時努力解決資源有限的問題。 如果您想觀看有關如何安裝和使用AppKeeper的視頻，請單擊此處。
AWS EC2應用程序監視– SIOS AppKeeper |操作系統
Amazon EC2用戶多長時間遇到一次停機？ 根據我們的客戶數據，只有三個Amazon EC2實例的普通客戶每月至少要經歷一次停機時間。那可能是由於軟件配置錯誤等引起的。
超越應用程序監視，提供自動修復
許多AWS用戶正在部署應用程序性能監視（APM）解決方案（例如來自AppDynamics，Datadog，Dynatrace或New Relic的解決方案）來監視其AWS環境。但是，這些僅使您警惕某些事情發生的事實以及發生的原因。 他們不會採取任何措施來減少停機時間。
這就是AppKeeper的用武之地。 如果AppKeeper在Amazon EC2上運行的任何應用程序服務中都檢測到停機，它將通過重啟受影響的服務並在必要時重啟實例來自動響應。 AppKeeper解決了85％的應用程序服務故障。 通過自動恢復，減少了IT團隊對昂貴的外包監控或乾擾的需求。從AppKeeper了解有關APM自動化的更多信息。
如果已經檢測到Amazon EC2停機，並且已經在使用APM解決方案並希望將功能擴展到包括自動修復的AWS客戶，則可以利用AppKeeper的webhooks API與他們選擇的APM解決方案集成。
為什麼我們決定將SIOS AppKeeper列出到AWS Marketplace
自2014年以來，在SIOS Technology Corporation，我們與Amazon AWS建立了戰略合作夥伴關係，主要圍繞我們的SIOS DataKeeper和SIOS LifeKeeper高可用性解決方案。SIOS Technology是當今的APN高級合作夥伴，我們共享100個共同客戶。
既然我們已經為SIOS AppKeeper的有效性提供了客戶證明（這裡是您可能會喜歡的一些最新案例研究），我們希望使Amazon客戶和APN合作夥伴更容易嘗試，購買和使用AppKeeper。據許多估計，使用AWS Marketplace中的軟件的活躍AWS客戶超過200,000，他們都在利用AWS Marketplace輕鬆進行雲計算之旅時發現，獲取和使用補充解決方案的便利性。
克里斯·格魯斯（Chris Grusz）說：“我們的亞馬遜朋友再好不過了：“隨著我們的客戶將越來越多的應用程序遷移到雲中，他們正在尋求靈活性，以平衡可用性水平和所有應用程序的成本。” Amazon Web Services，Inc. AWS市場總監。“我們很高興歡迎SIOS AppKeeper加入AWS Marketplace，並在發生性能變化時為我們的客戶提供更多選擇。”
有興趣保護EC2應用程序免受不必要的停機影響的AWS客戶現在可以自己快速試用AppKeeper，並且可以在自己的Amazon Enterprise Discount Plan中購買AppKeeper。SIOS AppKeeper的起價為每個實例每月40美元。
合作夥伴現在將AppKeeper集成到他們的客戶解決方案中
現在有許多合作夥伴將AppKeeper集成到其客戶解決方案中，並且在AWS Marketplace中提供了AppKeeper，這意味著APN成員可以更輕鬆地評估該解決方案是否適合其業務和客戶。 託管服務提供商（MSP）開始將AppKeeper納入他們如何監視和管理客戶的AWS環境中，以減少停機時間和自身運營成本。其他ISV正在將AppKeeper的自動修復功能集成到自己的雲管理解決方案中，AWS諮詢合作夥伴正在打包AppKeeper，因為他們為客戶開發並在AWS上部署了應用程序。
有興趣評估AppKeeper是否適合其業務的APN成員應通過電子郵件d-yoshioka@us.sios.com與我們聯繫。
我們希望您自己嘗試SIOS AppKeeper（我們有14天的免費試用期和簡單的安裝過程），並加入許多現在放鬆的客戶，他們知道他們已經進行了自動修復以減少任何Amazon EC2停機時間他們可能會經歷。