把一個應用遷往云計算并不是簡單地僅僅生成一個機器鏡像而已。一次云計算遷移可能會危及數據中心設施,而數據中心設施是支持應用完整性、性能、安全性以及合規性的基礎。雖然這些因素都是非常重要的,但是任何一個應用的首要關鍵就在于它是否能夠滿足業務需求,而其運行性能則是確定這一點的重中之重。
應用性能管理(APM)不僅是一個措施集,它也是一個工具包——這也是用戶體驗質量(QoE)中最為關鍵的要素之一。要么把當前APM實踐轉移至云計算,要么用與云計算友好等價的方法取代目前的做法,這是至關重要的。
傳統APM是通過以下一種或多種方法來注重應用并實現性能提升的:
流量壓縮以提高有效吞吐量;
在接入訪問端,按時間或性能關鍵的流量進行優先級排序;
對傳輸控制協議進行專門更換,以便于更好地應對丟包問題;
通過網絡實現多路平行通路,以提高有效帶寬;
跨多個服務器的流量負載平衡。
一般來說,所有這些方法都可以在連接的兩端——用戶端和服務器端——通過使用一個設施或軟件代理來實現。但是,當服務器端遷移至云計算時,這樣的實施方法就可能存在問題了,尤其是在它涉及網絡設施的情況下。云計算運營商很少會允許用戶在他們的數據中心內安裝設備,即便有時他們允許用戶這么做了,應用在云計算虛擬機中的分布也會讓應用遠離其加速設施。
這個問題的解決方案就是使用APM軟件工具而不是硬件。為了更有效地解決這個問題,APM工具必須以網絡中間件的形式存在于應用的機器鏡像中。如有需要,在服務器端基于軟件的代理仍可與設備配對,這樣的組合將至少能夠支持目前APM措施中的部分功能。
在云計算應用性能中的頑固瓶頸問題
負載平衡也帶來了具體問題,不僅是因為云計算供應商網絡不再接受外部設施,而且是因為在云計算中多個應用實例可能并不駐留在同一個數據中心內。DNS有基于軟件、分布式負載平衡的機制,但是這可能需要針對應用對它們稍作調整以便于讓應用能夠正常運行。
下一步就是解決云計算外出現的網絡性能問題了。云計算供應商通常都是通過互聯網連接至用戶并提供最佳服務的。當企業需要更高性能時,他們就必須使用虛擬專用網絡(VPN),而且也并不是所有的云計算供應商都會允許用戶通過VPN連接訪問他們的云計算的。即便供應商支持VPN接入訪問,但是網絡運營商所提供的VPN服務也有可能存在限制,而且使用VPN也會對云計算功能造成影響,例如托管點到地理區域的分派。云計算規劃師必須非常清楚每一家潛在云計算服務供應商所提供的每一個VPN選項,并應試圖找出其協議的壽命。
云計算中的性能管理可能還需要提供未能在數據中心內時刻待命可用的選項。大約三分之一的云計算規劃師都傾向于使用“云計算爆發”的方法把工作負載從數據中心遷往云計算,從而應對工作負載突增的特殊情況。很多本地的云計算應用已經擁有了“水平擴展”的功能或者自動實例化應用新副本的功能以增加用戶數量或服務交易的數量。真正的挑戰在于這種規模擴展需要規劃師進行精心規劃,并且有可能需要對應用本身進行變動。
為了進一步了解水平擴展的優點和需求,可以先構建一個簡單的工作流程圖來說明應用是如何服務特定用戶或交易的。在很多情況下,它會需要通過一個網絡服務器、一個應用服務器和一個數據庫服務器。經過對當前性能的分析,你將會知道,究竟這些環節中的哪些因素才是真正的性能瓶頸。如果一個特定應用在網絡服務器上使用了80%的處理資源,而用戶通過產品目錄進行解析,那么復制網絡服務器(以及目錄)將對應用的性能造成較為明顯的影響。如果這里只使用了20%的時間,而提供更多網絡服務器副本并沒有辦法實質性地提高性能,那么這就意味著性能瓶頸問題應該是由其他因素造成的。
數據庫訪問通常會造成新的云計算瓶頸,這是因為企業用戶往往并不愿意為網絡接入訪問和云計算存儲買單,而且他們也不愿意承擔把關鍵應用數據遷往云計算的相關安全性和合規性風險。在這種情況下,一些云計算應用就必須通過網絡從企業內部往外拉數據。在云計算爆發的情況下,這幾乎總是需要的,因為企業的主要數據都保存在應用所運行的數據中心內。
創建一個高效的數據通路是非常關鍵的,而這可能也意味著在云計算和數據中心之間的數據庫連接上增加APM措施。問題在于壓縮總是會增加延遲時間,而對于某些數據訪問策略來說,這就如同低容量問題一樣糟糕。最好的辦法就是根據接收服務請求的數據服務器的實際使用情況而不是塊級I/O命令進行規劃。這將減少數據量,并降低跨接口移動單個記錄所造成的累積延遲時間。請求/結果交換也不是延遲敏感的,因此你可以針對應用-數據庫連接增加壓縮以及其他的APM功能以提高性能。