通過集群化、復制、快照、微服務和應用程序設計來提高企業工作負載的應用程序彈性和可用性。

應用程序的彈性和可用性是現代企業工作負載的關鍵屬性。應用程序需要在硬件故障發生后，扛過服務故障(例如負載平衡器和域名系統錯誤)保持工作狀態，并且可以忍受局域網和互聯網中斷的影響。每個事件都可能會影響業務收入、聲譽甚至法規的符合性。以下五種方法幫助您增強應用程序彈性和服務可用性。

集群化增加應用程序彈性

群集幾乎是最普遍的用于增強應用程序的彈性、性能和可用性的方法。應用程序的某一實例擁有的吞吐能力是有限的—它只能在給定的時間內做一定量的工作。如果您推送的應用程序超出其容量—期望其每秒處理的比其可以處理的事務更多—應用程序將遭遇性能降低甚至是崩潰并變得無法工作。該應用程序工作負載的每個附加實例可以增加應用程序的有效容量，并允許集群實現比單個工作負載實例能夠處理更多的工作。這是可擴展性聚類的概念。如果企業需要從應用程序獲得更多的工作能力，您可以將更多負載平衡的節點部署到應用程序集群。

但附加的節點將增強應用程序的可用性，這對于應用程序高可用性(HA)相當關鍵。如果某一節點出現故障，則集群中的其他節點將共享計算負載。負載平衡器可以識別故障節點，并將應用流量重新分配給其余節點。這樣一來該應用程序仍然可工作。在很多情況下，用戶永遠都不會注意到這一問題。節點可以在同一數據中心本地，也可以分布在不同的數據中心，以防止可能出現的設施故障、互聯網中斷和其他潛在的威脅。

RAID和復制是存儲可用性的基礎

RAID仍然是存儲可用性的重要特性。RAID 0(條帶化)不提供數據保護，而是將數據分散到多個磁盤上，同時主軸用以提高存儲性能。RAID 1(鏡像)將一個磁盤的數據復制到另一個磁盤。如果一個磁盤發生故障，則副本可無縫地接管，您可以從工作副本中替換和重建發生故障的磁盤。RAID 5在多個磁盤或RAID組之間分散數據和奇偶校驗。如果磁盤發生故障，剩余的奇偶校驗信息可以重構丟失的數據，并重建有缺陷的磁盤的內容。這樣可以保護存儲設備組免受單磁盤故障的影響。RAID 6也可在多個磁盤間分散數據，但包含雙層奇偶校驗信息。這可以容忍和重建兩個同時的磁盤故障——該技術被稱為雙重奇偶校驗。

您還可以將RAID技術進行組合以實現多重優勢。例如，將RAID 5或RAID 6組(RAID 1)鏡像到第二個磁盤組，其結合了性能并確保在重建故障磁盤時快速訪問數據。您可以制定最適合每個給定業務應用程序的存儲保護方案。

復制可以在兼容的存儲子系統之間進行，但IT經常使用它從一個數據中心站點定期復制數據到輔助站點或公有云——即某一非現場或遠程位置，可以幫助防止數據丟失一個嚴重的設施問題。您可以在本地存儲資源之間同步執行復制，其中延遲不是重要因素，或遠程存儲資源之間的異步執行，其中延遲可能很大。您可以同時使用和復制RAID。

快照和遷移提供的靈活性

虛擬化技術允許您在數據中心服務器上配置、部署和管理現代企業應用程序作為虛擬機。虛擬機提供了巨大的靈活性，因為與物理服務器相比，計算資源的利用率更高，同時也保證了共享同一物理系統的每個虛擬機的充分邏輯隔離。即使虛擬機砸死服務器內存空間中作為映像存在，但仍然必須保護這些映像不受服務器故障和應用程序崩潰的影響，從而可能危及虛擬機并導致應用程序無法使用。

然而，并不是所有的工作負載都那么重要，可以證明在集群和其他應用程序可用性選擇方面的投資。快照是在服務器內存中將虛擬機的時間點狀態復制到存儲中的文件的常見方法。您可以經常捕獲并輕松恢復快照——將應用程序恢復到當時時間點的狀態。通常情況下，應用程序中斷時IT人員使用快照進行應用程序回滾和快速恢復。您還可以使用快照創建重復的應用程序實例——通常用于應用程序測試、開發和評估。

在數據中心內或遠程數據中心之間的虛擬化服務器之間遷移虛擬機非常簡單。遷移通常用于工作負載平衡等任務。這允許IT管理員調整固定服務器上的工作負載數量，以優化可用的計算資源或通過將工作負載移動到具有更多計算資源可用性的另一臺服務器來提高應用程序性能。為了防止工作負載中斷，在監控和管理工具檢測到該服務器運行狀況的問題時，先將VM從服務器遷移出去。您還可以手動調用遷移以在服務器上執行例行維護過程。

微服務和容器為虛擬化提供新的機會

應用程序設計的一大新興趨勢是放棄傳統的單片設計并將應用程序重新映射為使用API傳達命令和數據的更小的“無狀態”功能或服務的集合。這就是微服務的方法。您可以分別構建、測試、部署和擴展每個組件。而且由于每個組件都是無狀態的，所以一個組件的故障或故障不會導致整體應用中嚴重的數據丟失或不穩定;您可以簡單地重新啟動某一出現問題的組件。

更新微服務應用程序更加容易。盡管單片應用程序更新將需要完整的功能回歸測試，但組件更新只需要測試該特定組件。由于組件是獨立存在的，因此在單片應用程序中經常存在的相互狀態關系并不存在而無需測試。

構成微服務應用程序的組件經常部署到虛擬化容器之中。容器是用于提供服務器資源的替代化虛擬化技術。每個虛擬機提供完全隔離的操作環境，每個容器共享相同的底層操作系統、驅動程序和其他依賴項。這種共享方法使每個容器的體積之小和資源有效性都達到極限，允許更多容器駐留在同一臺服務器上。容器可被快速創建和銷毀，因此您可以根據需要對構成微服務應用程序的組件進行啟動和擴展。

在設計階段預先構造應用程序彈性

應用程序彈性通常涉及工作負載在其某一或多個組件中發生故障后的生存能力，以及仍可為業務及其用戶提供最佳可能的服務的程度。這意味著您本應將可用性集成到現代應用程序的設計和測試階段之中。

更新微服務應用程序更加容易。盡管單片應用程序更新將需要完整的功能回歸測試，但組件更新只需要測試該特定組件。由于組件是獨立存在的，因此在單片應用程序中經常存在的相互狀態關系并不存在而無需測試。

構成微服務應用程序的組件經常部署到虛擬化容器之中。容器是用于提供服務器資源的替代化虛擬化技術。每個虛擬機提供完全隔離的操作環境，每個容器共享相同的底層操作系統、驅動程序和其他依賴項。這種共享方法使每個容器的體積之小和資源有效性都達到極限，允許更多容器駐留在同一臺服務器上。容器可被快速創建和銷毀，因此您可以根據需要對構成微服務應用程序的組件進行啟動和擴展。

在設計階段預先構造應用程序彈性

應用程序彈性通常涉及工作負載在其某一或多個組件中發生故障后的生存能力，以及仍可為業務及其用戶提供最佳可能的服務的程度。這意味著您本應將可用性集成到現代應用程序的設計和測試階段之中。

應用程序靈活性討論的一部分以應用程序架構和設計為中心。微服務器方法只是構建復雜高度可擴展應用程序的新興設計范例的一種流行演示。自動化以及編排提供擴充組件，并根據流量需求隨時間變化自動平衡負載提供了相應能力。例如，如果較大應用程序的一個組件或功能需要處理更多的流量請求，那么您可以復制該組件(僅復制該組件)來處理額外的流量。

彈性應用程序設計的思考

彈性的應用程序設計，如微服務器，需要重新關注測試和審查每項對應用程序的更改。了解每個組件、模塊、服務或依賴關系的損失將如何影響應用程序的整體可用性。如果應用程序在測試期間不符合既定目標，則不應將其發布到生產環境中。有時，您必須改進相關服務或依賴關系(如存儲)的可用性，以滿足應用程序的可用性目標。

您還必須評估應用程序的安全性，作為用戶授權和對外部和內部攻擊的硬度的測量方法。衡量業務數據的安全性，并確保只有授權用戶可以訪問應用程序的數據，并保護數據免遭丟失或被盜。這可能包括某種形式的身份和訪問管理框架，以及在運行和非運行狀態下一定級別的數據加密。

此外，評估應用程序的可擴展性，以確定如何輕松地擴展工作負載以滿足流量需求。現代模塊化應用程序往往更加容易進行擴充，因為通常可以通過更少的計算資源來更快地(通常是自動的)部署其他組件并平衡負載。

所有這些概念經常伴隨著綜合的應用程序性能管理工具，旨在幫助您了解工作負載在生產環境中如何執行其設計目標。

應用程序也經常設法接受無狀態設計。基本上，無狀態功能從外部獲取所需要的所有數據，執行其各自的任務，然后將其結果傳遞給用戶或其他功能——不考慮模式、選集、選擇或配置偏好對功能行為的負面影響。如果功能發生故障，您可以簡單地重新啟動它，而免受數據損失數據的風險。

作者：Stephen J. Bigelow

來源：51CTO