使用VMware NSX從硬件提升網絡性能存在一些問題，即哪個團隊應該在發生網絡故障時介入其中。

技術進步可以擾亂它們的實現和IT行業的采納方式。

就拿服務器虛擬化舉例吧。虛擬服務器帶有虛擬交換機，使“煙囪式服務器”管理員處理網絡或與其相關的事情時很不爽。對于堅持服務器、存儲和網絡團隊三種豎井模型的企業來說，服務器虛擬化迫使服務器與網絡工程師不得不商議一個新的界定標準。物理網絡并未發生多大改變，但所有虛擬的東西(Cisco Nexus 1000 v除外)都成為服務器團隊的職責范圍。

存儲也類似。虛擬機文件系統讓存儲抽象出來，存儲管理員完全丟失了他們支持的工作負載的蹤跡。SAN團隊不會參與部署每一臺新服務器，服務器虛擬化看到虛擬機實例出現，而不給存儲工程師提供反饋。

在這兩種情況下，VMware vCenter Server為管理虛擬化服務器和抽象存儲提供了一致性的環境。因為服務模式是集中服務，服務器團隊自然承擔了責任。

當虛擬化是服務幾種，服務器團隊想當然成為該技術的擁有者。團隊之間有清晰的劃分———網絡團隊提供VLAN(虛擬局域網)，存儲團隊提供LUN(邏輯單元號)。前提是企業只允許有MBA學位的人來掌控。

 [[147543]]

NSX提出難題

當虛擬化成為網絡中心時會發生什么?如果沒有虛擬化x86服務器，我們該虛擬化網絡嗎?提及VMware NSX平臺時，企業的水就給攪渾了。

當你擁有核心技術硬件，就要承擔責任。但存在一個問題：在NSX中實現網絡虛擬化是以網絡為中心的，并非由服務器驅動。你無需將NSX加載到已有的交換機基礎架構上，而是建立在現有vSphere部署之上。所以管理虛擬網絡，你必須記住三件事：

基于角色的訪問控制(RBAC)是一把雙刃劍

你可能想通過實施RBAC，將運維職責劃分為兩個或以上的同等部分，以此解決服務器與網絡之間的爭論。VMware NSX促進這種配置，內置角色從只讀審計師到擁有至高權限的企業管理者。但請注意：狹隘來說，NSX在管理訪問過程中，可能***加強服務器與網絡的沖突，而不是采用矩陣型，或混合的操作方法。記住，支持現代基礎架構的技術在發生變化，所以你的工程師團隊也應該發生轉變。

讓團隊進行故障診斷和操作培訓，而不是簡單地在組織結構圖使用使用RBAC覆蓋。不僅可以確保運營問題在物理或虛擬網絡得到快速解決，而且在與NSX合作時你會給團隊一個通用詞匯表。

以全新的高度看待網絡問題

我不會講一個冗長可笑的IT問題將其歸咎于“網絡”。

但我將會時刻提醒你為什么我們喜歡指責網絡：因為在如今的基礎設施中，網絡是大家都有的。我們很隨意地使用網絡術語，它可能代表著幾乎任何東西，從斷開的電纜到網關協議列表。

VMware NSX，類似其他覆蓋解決方案，在物理網絡上增加了虛擬化網絡層。這項技術聽起來不怎么樣，但對運營團隊來說，網絡覆蓋的影響有價值的，尤其是診斷與故障排除。一旦網絡工程師的工具失去覆蓋網絡的可見性，傳統故障診斷方法的開放系統會發生沖突。NSX工程師的故障排除可能阻礙低能見度及底層實體網絡基礎設施的健康。

最糟糕的情況是：物理網絡團隊和虛擬網絡團隊相互指責：“我們的網絡是完好的，一定是他們的網絡出現問題。”

通過部署一個完善的監控產品檢查物理網絡和虛擬網絡的健康，可以避免這種情況的發生。如果選擇Cisco或VMware銷售的產品，或選擇第三方廠商作為客觀性能和健康信息的來源，就會獲得效益。除了消除指責，這樣做會聚焦于工程師解決問題根源的事件。

了解你的問題

很容易認可NSX，但請務必注意最初購買的原因。也許你想要改善的安全問題處于網絡的復雜地帶，也許你想應用期待已久的vSphere網絡，或者你想更側重于賦予虛擬化工程師控制配置網絡、防火墻和政策的權利，盡可能快速而方便地配置虛擬機。

簡單來說，你可以很容易地判定在NSX的成功實現和操作方面，哪個團隊能取得***利益，它就應該負責運作。