虛擬雲網路

網路虛擬化NSX 技術文章系列二百二十一: NSX Federation:方案說明與討論(七)

作者: Colin Jao 饒康立 – VMware資深技術顧問,主要負責VMware NSX產品線,目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。

我們的客戶在使用NSX時,不一定都有使用T0/T1/Overlay網路,但幾乎每個都會使用分散式防火牆以及群組等安全功能。在許多與不同客戶及合作夥伴的討論內,也都有收到詢問如果企業有多站點,比如說主站點以及DR站點的狀況,可否只需要設一次防火牆,同樣的配置,不用在主站點設一次,DR站點一模一樣的又設一次呢?

有兩種做法。一個是標準的NSX Multisite,在系列文內第一篇有討論過,如果主中心與DR站點都是給同一組NSX Management Cluster進行管理,那當然防火牆的配置只需要下一次,同時在主站點以及DR站點都會生效。但NSX Multisite的問題在於NSX Management Cluster必須都放在同一個站點內,當主站點失效,整個NSX Management Cluster都會掉下來,此時在DR站點雖然可以備份還原的方式重建NSX環境,但時間就拉很長了。

第二種方法就是現在和大家介紹的Federation的做法。回憶一下,在Federation的環境內,

  • 每個站點有自己的Local NSX Managers / vCenter。有兩個站點會有Active / Standby的Global NSX Managers
  • 當我們把防火牆規則、群組等在Global Managers內配置時,Global Manager會把這些資訊推送到每一個站點的Local Managers內。這代表,我們僅需要在Global Manager內配置一次,然後每個站點的Local NSX Managers內就都知道防火牆規則以及群組了。
  • 第三件事是個重點:各站點的Local Manager間會互相交談,交換彼此間的物件資訊。什麼意思呢?比如說,站點A會告訴站點B,Group-CRM這個群組內,在我身上有哪些虛機。站點B也會回頭告訴站點A,我們站點內也有哪些虛機在Group-CRM這個群組內。這樣,Local Manager就會知道在整個Federation的環境內,Group-CRM總共應該包含哪些虛機/IP了。

好的,我想同樣地以實際例子舉例給大家看。下圖內是我們在前面一直用的範例,在這邊,我們的應用內有四個虛機,web-01 / web-02 / app-01 / db-01,這些虛機都在同一個Global-APP-Segment內,但是分佈在不同的站點上。

這裡我們要做的群組以及防火牆配置如下圖,環境內

  • 應用內虛機分為Web / AP / DB 三個群組,然後所有的虛機合起來是Global-Application群組
  • 在分散式防火牆內,我們可以配置群組間的關係,下圖右方內列出如用戶可以透過HTTP / HTTPS連到Web群組,Web群組可以TCP 8443 Port連到AP群組,預設值要Reject,像這些。

好,首先我們來看在Global Manager內進行的群組配置如下面三張圖。如同前面網誌討論,Global物件的配置需要在Active Global Manager內,我們在台北的GM內配置了前述的四個群組,同時也把對應的虛機放進去。下面大家可以看到配置出的四個群組,另外對應到Global-Application這個群組,在台北Location內包含了web-01 / app-01 / db-01的虛機,新竹Location內包含了web-02的虛機:

回到台北與新竹的Local Manager介面內,大家會看到這些配置直接被推送過來。下圖是Group的顯示,在台北與新竹的LM內都一樣。而且在每個群組後面會特別打上GM的符號,代表這個物件是由Global Manager那邊推送過來:

下面是重點,我們分別在台北與新竹的Local Manager內看Global-Application這個群組裡面的成員。首先是台北的Local Manager內:

接下來是新竹端的Local Managers,同樣看Global-Application這個群組裡面的成員:

上面要讓大家看到什麼呢?當我們在Global Manager內建立了群組並指定了成員,相關的資訊會推送到Local Manager內。更重要的,台北與新竹的Local Manager不僅知道『自己』在此群組內的成員(上面列出的虛機),而且可以透過彼此的資訊交換,知道整個Federation環境內,全站點在群組內的所有成員(台北與新竹所有虛機的IP地址)。因此,即使一個業務的成員是分佈在不同站點內,Local NSX Manager也可以正確地辨識出來,而在防火牆內做出正確的防護判斷。

所以下面的三張圖就是在Global Manager介面,以及分別於台北 / 新竹 Local Managers內的防火牆配置,大家可以看到是一模一樣的。管理者只需要在GM上面配置一次,在各地的Local Manager上面就會有相同的配置:

很快做一個檢證:我們登入在台北site的web-01,首先確認一下自己的IP是172.28.100.11。接著,由web-01去ping web-02,由防火牆規則1000003內,這會被阻擋。但當我們由web-01啟動ssh去連web-02,由防火牆規則1000002則可以成功。結果請看下圖:

本文結束前,就NSX Federation內的安全防護,再進行幾個說明:

  • 上面的例子內,虛機是放在Overlay Segment上。我們很多客戶採用NSX時純粹只用微分段,虛機放在Vlan Segment內。NSX Federation內,上面的異動不會有影響,無論虛機在Overlay / Vlan上,防火牆 / 群組的功能都可生效
  • 大部分用戶在採用分散式防火牆以及群組時,還會使用Tag,在虛機上面以scope/tag標註機器是屬於哪個應用/哪個部門,然後在群組內以Tag來辨識哪些虛機可加入此群組。本文寫作時,NSX-T為3.1版尚未支持Global Tag的功能,但在後續的版本內應會支援,管理者就應該可以在Global Manager內同樣去配置tag到整個環境內了。

先到此為止,下篇是本系列的最後一篇,我們會就NSX Federation內常被客戶及經銷夥伴詢問到的問題與大家進行討論。

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注