咨詢師Glen Kemp分享了一位客戶在遇到平臺Bug之后重新評估網絡虛擬化好處的案例。
任何新技術或現有技術的迭代都會使事件變得更快、更便宜或減少運營花費。服務器虛擬化肯定能產生這些結果，而現在網絡虛擬化正在吸引越來越多的關注。然而，一些最新項目證明了虛擬化案例并不一定是這樣的。
按照我作為一名安全和IT咨詢師的經驗，我曾經看到過一些客戶跟隨潮流購買了安全虛擬化產品，將許多服務都整合到一個平臺上。這樣可以顯著節省電源和減少維護費用。這一切都很好：合唱隊在看不見的地方高唱贊歌，告訴人們新技術是如何讓生活變得更好。
但是，它并不適用于一些情況——至少一開始是不適合的。
這就是我要說的。有這樣一個例子，一個客戶在使用虛擬化框架不久之后，就遇到了一個嚴重的平臺Bug。問題的細節并不重要，但是它的影響卻很大。在虛擬化之前，這種問題的影響范圍很有限，但是共享平臺的層疊故障導致許多個業務單元發生中斷。這個問題很難修復，它需要安裝幾個補丁才能讓平臺保持穩定運行。但是，所造成的損失已經成定局。對于管理層而言，他們對于網絡虛擬化的信任已經完全消失。因此，他們提議對網絡進行全面更新;這時我開始參與項目。這個計劃是完全更換平臺，逐漸減小組織對于共享物理基礎架構的依賴。
這不是我第一次見證同類項目的發生。我已經看到過幾個案例了，客戶選擇從虛擬化網絡功能(VNF)退回到相對更為常規的網絡設計。表面上，在分布式集群上運行VNF應該可以實現令人期盼的成本節約。然而，我發現它也一樣會顯著增加系統的復雜性，特別是在監控和管理方面。
不小心的話虛擬化系統就可能影響其他運營
所有虛擬化的核心都藏著一種妥協，用戶只能減輕它的影響卻無法完全消除它。虛擬化系統共享著物理資源，即使有資源保護、調度及其他“軟”控制，虛擬化系統仍然會對各自產生負面影響。在很多時候，它們并不會互相干擾，只要有恰當的系統管理，許多系統都可以共享相同的硬件。對于大多數最終用戶而言，共享資源可以減少運營成本。
服務器、網絡和安全虛擬化技術都共享一個致命要害：每一個節點(交換機或虛擬實例)都有的軟件系統。它可能是虛擬機管理程序、共享控制面板或集群協議。網絡/服務器/安全等組件的運行依賴于這些服務。這本身沒有問題，因為到達臨界點之前它們都是完全可靠的。
要記住IT運營的兩個不變事實：有Bug，也會有補丁(接下去就是人終究有死和必須交稅)。如果運氣好，問題的根源和影響都會被修復。硬件和軟件供應商會在后續的升級和自動恢復中改進產品，但是有時候這些過程不可避免地會出現錯誤。在上面的客戶案例中，問題跟蹤后發現是由于內存泄漏引起的——任何供應商都可能(也確實)會有這樣的問題。但是，一定上層作了決策，我們也不得不實施決議的計劃。
讓虛擬鏈路重新變成物理鏈路
遷移網絡的短期影響是可以預見的：需要使用大量的銅線和機架將虛擬鏈路重新變成物理鏈路。除了這些大件的工程問題，還有許多并行流程可用于零碎部件。在完成更換之后，由于“技術水平發展”，基礎架構的總容量實際上會比以前增加了。然而，由于有更多的處理器和接口，因此跟蹤通過基礎架構的流量會變得更加困難。
在虛擬化環境中，一個集群通常等同于一個管理接口。在物理環境中，幾十個不同的管理接口部署在一起會形成一種巨大的管理難題。雖然可以使用一些元素管理工具來創建跨越物理基礎架構的策略，但是它們還無法完全解決所有的管理問題。例如，對于管理員基于角色的訪問控制作一點點小修改都會向80臺設備發送請求。為了解決這些模板型問題，使用自動化工具是理所當然的方法。然而，由于組織的管理層已經拋棄了像虛擬化這樣的“成熟”技術，因此可以想像他們對于NetOps風格的系統管理的態度(不會太好)。
同時，有一些小問題取代了用戶的大問題;客戶選擇對抗100只小馬，而不是一只小馬。毫無疑問，這個公司在放棄網絡虛擬化的好處之后是在逆流而上;但是在這個案例中，可用性壓倒(幾乎)了所有其他的問題。人們其實沒有必要害怕到放棄虛擬化，但是也需要一定的執著力。而且，人們必須要有一定的克制力，接受讓許多硬件和軟件閑置的事實，然后騎著小馬去迎接挑戰。
京公網安備 11010502049343號