關於VMware NSX在多資料中心間的應用，前面幾篇文章已經討論過二層三層網路面所面臨的問題，但若依然採用傳統的實體安全設備，將會浮出其他安全問題，針對這種狀況，本文將詳細說明在跨中心架構內進行微分段東西向防護的功能。
而新增時，只要選取「Mark this section for Universal Synchronization」這個Section，就會變成通用防火牆區塊，如圖4所示。
 |
| ▲圖4 勾選「Mark this section for Universal Synchronization」選項以變成通用防火牆區塊。 |
這麼一來，而所有在此Section內建立的規則，就都會是配置到所有Cross-VC NSX領域內的通用規則。
其他的防火牆配置方式很直覺，大家請自行在測試環境或是VMware HoL內進行驗證吧！但繼續要和大家談的是通用分散式防火牆的技術限制。
熟知NSX安全方案的人想必清楚，微分段技術除了能進行以虛機為單位的東西向防護外，另一個更棒的特性是能夠和虛擬化環境管理整合，而藉此可以得到以下兩項好處：
‧可以直接把虛擬化物件，例如虛機、叢集、Port Group、資源池等作為防火牆來源與目的地，直接與網路地址脫鉤。
‧可以建立安全群組，採用動態條件，比如說虛機的名稱，或是指定的安全標籤等等，動態地將虛機加入防護的目標，達成安全自動化。
但在Cross-VC NSX環境內，上述的好處受到極大的限制，這並不單純只是技術還沒做出來，而是實際架構的問題。
實際動手設定找出問題
以下面的例子來說，如果目前有一台VM-A在Site 1、VM-B在Site 2，兩個虛機在同一個二層網段內，而要用分散式防火牆進行VM-A與VM-B之間的阻隔。此時，如果是在原本單一vCenter的環境內，防火牆規則會很簡單，如表1所示。
表1 防火牆規則設定
在NSX的運作環境裡，實際的情況應該會像以下所描述的：
1. 向vCenter詢問VM-A與VM-B的UUID，並採用VMtools/Spoofguard的方式，查出對應的IP地址。
2. 將IP地址寫成防火牆規則，發送到每一台vSphere Host。
但是在Cross-VC的環境內，有多台vCenter與多台NSX Manager。狀況來了！上面的例子是，當Site 1內的NSX Manager 1進行查詢時，vCenter 1知道VM-A是誰，但會有一個問題出現，VM-B不歸vCenter 1管，因此解析不出IP。
同樣地，Site 2內的vCenter 2知道VM-B是誰，但不歸他管的VM-A也無法解析。
如此看來，目前通用型分散式防火牆在運用上有下列的限制：
1. 可以支援IP或是IPSets作為來源與目的地，與一般實體防火牆一樣。
2. 不能採用虛擬化物件，像是直接選擇虛機、叢集、資源池、Port Group等。因為這些物件都僅是限制於單一vCenter內的物件定義。
3. 可以採用安全群組，但安全群組內只能使用VM Name或Security Tag進行定義。而且在運用時，同一個安全群組內的所有虛機「都必須位於同一個資料中心（vCenter）內」。
簡而言之，如果資安管理者希望能夠使用到安全群組的機制進行防火牆規則的優化與自動化，目前主要支援的情境為Active-Standby的災備情境。
或者，即使是Active-Active，同業務的虛機也應該隨時都在同一邊，如果有遷移的需求，則要整組業務進行搬移，如圖5所示。
 |
| ▲ 圖5 同業務的虛機應該隨時都在同一邊，如果有遷移的需求，則要整組業務進行搬移。 |
如果今天單一業務有出現Cross-VC的網路流，此時除非是用標準的IP/IPSets，不然極有可能由於上面敘述的原因而出現原本資安管理者所設計的防火牆規則無法生效的情況。
結語
以上的數篇投稿，是對於NSX在多資料中心間的應用部署方式介紹。跨中心方案無論在各個IT領域都是個需要詳加規劃的架構，而原本在實體環境可能已經相當複雜，再加上雲資料中心內的特性，如業務機器、業務環境快速新增與異動、虛機容易飄移、管理需要集中化等等，在在都讓傳統實體規劃模式力有未逮。
但希望大家在這幾篇的連續討論下能夠看到，藉由NSX對應到多中心內的設計架構，一個接近全自動、集中管理、跨中心、安全且優化的雲方案，是有機會在各位的環境內實現的。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞