顯示具有 SDN 標籤的文章。 顯示所有文章
顯示具有 SDN 標籤的文章。 顯示所有文章

前言

在 VMware VMworld 2016 大會上,由 VMware 執行長 Pat Gelsinger 正式發表 SDDC 軟體定義資料中心願景中最要的運作元件 VMware vSphere 6.5 及 VMware vSAN 6.5 正式推出,並且在日前 2016 年 11 月 15 日時 VMware 官方正式宣佈 vSphere 6.5 新版發佈,同時提供相關新版產品映像檔的下載。



站長將不定期撰寫相關新功能簡介文章: (更新文章符號 💩)

【簡介】




【vCenter Server】




【Security】




【Storage】




【VMware Taiwan vSphere 6.5 新功能介紹】



前言

日前 (2016.12.8),在 Taiwan 舉辦的 VMware Taiwan vForum 2016 議程簡報已經開放下載了,有興趣的朋友可以參考看看。

簡報下載

主題演講




分會場 1、軟體定義資料中心




分會場 2、軟體定義儲存




分會場 3、軟體定義網路及安全




分會場 4、多雲維運與自動化




分會場 5、行動終端應用




分會場 6、Cloud Native


前言

昨天晚上在微軟官方網站 TechNet Evaluation Center 上,正式釋出 Windows Server 2016 TP5 (Technical Preview 5)。同時,System Center 2016 TP5 也釋出了。同樣的,在 Windows Server 2016 當中仍維持 Standard 及 DataCenter 版本,功能簡述如下:

Windows Server 2016 Standard
  • Up to 2 VM's or Hyper-V containers
  • Unlimited Windows containers
  • New Nano Server deployment option for "just enough OS"
Windows Server 2016 Datacenter
  • Unlimited VM's and Hyper-V containers
  • Unlimited Windows containers
  • New Nano Server deployment option for "just enough OS"
  • Shielded VM's and Host Guardian Service
  • Storage features, including Storage Spaces Direct and Storage Replica
  • New networking stack



免費電子書

在 4/20 時 Microsoft Press blog 也釋出 Free ebook: Introducing Windows Server 2016 Technical Preview 免費電子書。



其它參考資源

前言

微軟新世代 Windows Server 2016 雲端作業系統,在 2014 年 10 月 1 日時正式發佈第一版的「技術預覽(Technical Preview,TP1)」版本,接著在 2015 年 5 月發佈 TP2 技術預覽版本、2015 年 8 月發佈 TP3 技術預覽版本。最新版本,則是在 2015 年 11 月時所發佈的 TP4 技術預覽版本。

系列文章

站長與 TechNet 台灣部落格 合作,撰寫 Windows Server 2016 攻略連載文章將分為 Compute / Storage / Network 三大主題 (共 8 篇文章):

【Compute】


【Storage】


【Network】


前言

日前 (2015.12.9),在 Taiwan 舉辦的 VMware Taiwan vForum 2015 議程簡報已經開放下載了,有興趣的朋友可以參考看看。

簡報下載

主題演講



分會場 1、資料中心虛擬化



分會場 2、網路暨安全虛擬化



分會場 3、儲存虛擬化



分會場 4、雲端基礎架構管理



分會場 5、行動終端應用管理



分會場 6、Cloud Native Application for DevOps


VMware NSX 學習筆記


NSX Edge Firewall

NSX Edge Firewall 擔任如同傳統硬體防火牆,也就是擋著「外 -> 內」的攻擊。NSX Edge Firewall 其實就是 vShield Edge VM,因為它是高度客製化的 Linux(VM),所以其實防火牆功能就是 NetFilter (IPTable)

預設情況下 Firewall Policy為「外 -> 內 Deny」,採取 Rules First-Match 的防火牆規則讀取方式,最多支援 2,000 筆規則,連線數的部份則跟部署的資源有關。

Firewall Rules 中有 Default, Internal, User 三種類型:
  • Default: 就是預設規則(可以多條或多組)。
  • Internal: User Define Chain (服務分類的概念),這樣的設計的目的是可以「降低規則比對次數,提升運作效能」,但只有系統自已使用,管理者無法手動建立此規則。
  • User: 實際執行的 Rules,GUI 設定只能是 User。

此外,比較特別的部份是可以識別 vSphere 相關物件如 Cluster, Resource Pool...等,且內建多種常用服務如 Exchange...etc,你可以選一堆組成 Service Group,以因應內部的 VM 服務。Incoming 角度是從 Edge 來看 (外 -> 內 VM),Outgoing 角度是從 Edge 來看 (內 VM -> 外)。

Distributed Firewall

以往的防火牆,只能擋住外到內的部份,主機之間的攻擊行為防護只能依靠 Guest OS 內建防火牆,但是在管控上並不方便且會影響效能。因此,不同於以往的設計 Distributed Firewall 是擋在「每台 VM」前面的 Firewall (所以 Guest OS Firewall 可以關閉)。



Distributed Firewall,它是內嵌在 VMkernel 當中(座落於 vNIC Level)。原則上可以處理 L2 ~ L4 (L2 MAC、L3 IP、L4 TCP/UDP/Port),在優先權上,L2 的 Rules 會優先處理。在 GUI 設定介面中「Ethernet」其實就是 L2 Rules,而「General」就是 L3,L4 Rule,簡單來說,Distributed Firewall會先比對 L2 Rule 後,再比對 L3,L4 Rule 最後比對 Default Rule。此外 Distributed Firewall Rules 會「跟著 VM 走」,所以不用怕 vMotion 之後防火牆規則會跑掉的問題。


在規則管理上由 vSphere Web Client 統一進行規則設定的動作,透過 NSX Manager 把防火牆規則派送到每一台所屬的 ESXi Host 當中 (NSX Controller 不負責這部份)。


在防火牆規則中的 SECTION 只是「容器」的概念(管理用途),跟先前提到 NSX Edge Firewall 的 Internal 不同。現在,透過 NSX 網路虛擬化的 Distributed Firewall 功能,除了能定義 VM 與 VM 之間是否能互通之外,即使不同網段的 VM 也能進行定義。


雖然 Distributed Firewall 防火牆規則看似複雜,但其實每台 VM 的 Distributed Firewall,只會載入必要的也就是跟自身有關的防火牆規則,跟自身無關的規則並不會載入。



Flow Monitoring

Flow Monitoring 功能,主要是看 NSX 物件相關流量以及除錯之用。同樣的,你可以透過 vSphere 的相關物件,來進行流量過濾的動作以便於你找出問題的根本原因。

Role-Based Access Control

Role-Based Access Control 驗證機制,可以支援 LDAP, Windows AD, NIS...等驗證方式。當然,在權限的部份也會有「繼承 (Inheritance)」的特性。

Service Composer

Service Composer 是一種 Template 的概念,它可以整合 3-Party 到 NSX 環境中如 IDS/IPS, Anti-Virus...等。匯入後,首先就是要跟 NSX Manager 進行介接的動作 (Register 的概念)。


舉例來說,當你導入防毒機制後,會進行 VM 掃描動作,若發現病毒則會將該 VM 移至「隔離區 (Quarantine)」,當威脅排除後才能回到正常工作區域。


Other Monitoring Options

除了剛才介紹的 Flow Monitoring 機制之外,你也可以使用 Syslog 機制來幫助你除錯並了解系統資訊。此外,也可以整合 vCenter Log Insight 機制。

學習資源


VMware NSX 學習筆記


NSX Edge Gateway

本章將說明 NSX Edge Gateway 所能任的角色,例如,NAT、Load Balancing、VPN 以及本身所具備的 HA(High Availability) 高可用性…等特色功能。

NAT(Network Address Translation)

簡單來說,你可以讓 NSX Edge Gateway 搖身一變成為 NAT 裝置,它支援 Source NAT / Destination NAT等機制,它其實就是採用 Linux Kernel (NetFilter) 也就是 IPTables 來處理 NAT 的部份。下列為 Source NAT 的應用情境。


Destination NAT 的應用部份,其實就等同於是 Mapping IPPort Forwarding 等機制的應用。


LB (Load Balancing)

NSX Edge Load Balancing 的負載平衡機制,支援二種模式分別是「One-arm Mode (Layer7, HTTP/HTTPs)」及「Inline Mode (Layer4, TCP)」。


One-arm Mode
One-Arm Mode 也常稱為 Proxy Mode,此方式的負載平衡優點是架構設計簡單且容易部署。但是,缺點是你必須要有負載平衡的每個網段,可以整合「HTTP X-Forwarded-For」機制來重新導向 IP 位址。


Inline Mode
Inline Mode 也常稱為 Transparent Mode,此架構的優點在於不用做 Source NAT 的動作,可以有效降低負載平衡的工作負載。但是,不能與 Distributed Router 共用,因為後端的 Web Server 必須要把 NSX Edge 設定為 Default Gateway。


HA (High Availability)

NSX Edge Gateway 本身的 HA 機制 (同樣以 EMC AutoStart Manager 機制建立),二台主機之間的 Heartbeat 及資料同步,都是採用 Internal Port Group 來達成 (169.254.1.x)。心跳偵測的部份是由 Active Node 送出 Heartbeat 訊號,預設 Dead Timer 是 15 秒 (最少可調整為 6 秒),當 Active 死掉時「Session 會中斷必須重連」,因為是 Standby 接手所以 Session 要重連。此外,啟動 HA 機制之後,系統會「自動」產生 Anti-Affinity 規則。


當啟動或停用 HA 機制時,持續 ping 時會發現掉 2 個 ping 封包,若啟用 HA 機制時「不填」 Management IP 的話,跟 Control VM 一樣,就會自已產生 169.254.1.x 處理,若是觸發 HA 事件切換時則是會掉 3 個 ping 封包,它不會 Failback (原來的 Active 回來後不會搶回去)。可以透過指令「shows service high availability」來確認,目前哪一台是 Active 哪台是 Standby 及運作狀態。


VPN

NSX Edge Gateway 支援的 VPN 種類有三種,分別是 Site-to-Site, L2, SSL…等。值得注意的部份是,如果伺服器的 CPU 有支援 AES-NI 的話(CPU 從 Westmere 世代開始就支援 AES-NI),屆時可以加速加解密的效率,可提升約 30% ~ 40%


IPSec VPN 的部份,最多支援 64 Tunnels 及 10 Sites,支援的加密演算法有 AES (預設值)、AES256、TripleDES。在 Site-to-Site 之間的溝通,採用常用的 IKEv1(phase1, phase2)、ESP。


在 GUI 設定畫面中「internal (指的就是 local)」、「uplink (指的就是 peer)」。


SSL VPN 的部份,支援 25 個使用者帳號及相關認證機制。


VMware NSX 學習筆記


NSX Routing(OSPF, IS-IS, BGP)

NSX Routing (在 vCloud 環境的話則是使用 vShield Edge)。首先,了解 OSPF (Open Shortest Path First)、IS-IS (Intermediate System to Intermediate System)、BGP (Border Gateway Protocol) 等動態路由的運作流程。簡單來說 OSPF 常用於「內部路由」的部份,而 IS-IS 則是決定「最佳路由」的部份,而 BGP 則是「外部路由」的部份。

OSPF

AS (Autonomous System) 自治系統區 (Default Area 0, 51),一般來說相同的 AD 會採用 OSPF,不同 AS 則採用 BGP。預設情況下每 10 秒鐘,透過 hello packets 機制(發送用Multicast),尋找附近(鄰居, 身體同一網段共用同 Area ID) Router 的狀態。OSPF 採用  Dijkstra 演算法,來找到最佳路由路徑或最低路由成本 (NSX 支援 OSPF v2)。

OSPF Packet 的 Header 為 24 bytes,包含 OSPF 版本、RID(Router ID)、Area ID…etc。預設的 OSPF Area Type 大致三大類 Normal Area, Stub Area, NSSA(Not so Stubby Area),每個 Area 自行維護 Link-State Database。
  • Normal Area: 處於 Non-Backbone Area,從 Backbone 接收「Full Routing」資訊。
  • Stub Area: 處於 Non-Backbone Area,從 Backbone 接收「Default Route」資訊。
  • NSSA: 處於 Non-Backbone Area,從 Backbone 接收「Default Route」資訊。可以導入外部路由並送至 Stub Area,但無法從其它 Area 獲得 AS 外部路由。

IS-IS

其實與 OSPF 機制很像有二種 Level,分別是 Level 1 對應到 OSPF 非骨幹部份,以及 Level 2  對應到 OSPF 骨幹部份。用在大型路由區域的動態路由協定,它座落在 Layer2 所以可以路由「Non-IP Traffic」。

BGP

支援 iBGP / eBGP,且 BGP Peer 之間透過 TCP Port 179 進行溝通。

NSX Logical Router

Distributed Logical Router 運作在 VMkernel 當中,負責 Data Plane 東西向的流量,可以優化路由及 Data path 且支援單一租戶或多租戶環境。

NSX Controller 集中「部署、管理」Logical Router,每台 Distributed Logical Router 可以有 1000 Interface,NSX 架構中最多可以有 1200 台 Distributed Logical Router,每台 ESXi Host 最多 100 台 Distributed Logical Router。


以往當 VM 虛擬主機在不同的二台 ESXi 主機要互相溝通時,網路流量一定會流出 Layer2 實體層,這種非最佳流量的傳送行為稱之為「Hairpinning」。


現在,在 NSX 網路虛擬化環境中,當處於不同 VXLAN 的 VM 虛擬主機要互相溝通時,透過 NSX Edge Gateway 轉介,在 Layer3 就處理好整個傳輸流程如下:


1. 雖然二台 VM 虛擬主機身處於同一台 ESXi 主機,但是卻處於不同的 VXLAN 5001/5002
2. VXLAN 5001 中的 VM 發送 Frame 到 Logical Switch 至 vDS,因為 VM 處於不同 VXLAN 所以 ESXi 將 Frame 轉送到 Default Gateway (也就是 NSX Edge Gateway)。
3. 運作 NSX Edge Gateway 的 ESXi 主機,收到遠端 ESXi 主機傳來的 Frame。
4. 運作 NSX Edge Gateway 的 ESXi 主機,將收到的 Frame 傳給其上運作的 NSX Edge Gateway。
5. NSX Edge Gateway 確認路由路徑後,發回應 Packet 給剛才遠端的 ESXi 主機,一樣到 vDS 然後到 VXLAN 5002 的 Logical Switch。
6. 確認後,傳送 Frame 給 VXLAN 5002 的 VM。
7. VXLAN 5001 的 VM 順利與 VXLAN 5002 的 VM 進行溝通。

Distributed Logical Router

它座落在 VMkernel 層級 (Kernel Module) 中,並且可以處理 VXLAN -> VLXAN 或 VLAN -> VLAN 的流量,也可以處理實體或虛擬網路的路由 (VXLAN -> VLAN 是稍後會介紹的 Layer 2 Bridge 功能)。


如同上述範例所說的溝通情境,當二台 VM 虛擬主機在同一台 ESXi 主機,但是卻身處於不同 VXLAN 時,流量到了 ESXi VMkernel 層 (Data Plane) 之後,就可以直接路由流量了(記憶體網路流量),而必出去問 NSX Edge Gateway 再回來。



由 NSX Controller Cluster 當中的三台來負責分發,LR Control VM 所學習到的路由 (跨 ESXi 主機) 給 Distributed Logical Router。

Distributed Logical Router 擁有 LIFs (Logical Interfaces),你可以想成是實體 Router 的網路介面,它包含了 IP Address、ARP Table,且每台 Distributed Logical Router 可以配置多個 LIFs (最多 1000),分別連接到 Logical Switch 或 vDS Port Group。

在 LIF 當中的 MAC Address 稱為 vMAC(virtual MAC),所有的 VM vMAC 不會儲存到 Layer2 Switch 當中,因為這些 vMAC 是在 VXLAN 當中的,因此實體網路其實看不到 VM,且 VM 會以 vMAC 當成 Default Gateway 的 MAC Address。而 pMAC(physical MAC) 則是對應到 uplink,用來處理 VLAN LIF 以連接到實體網路。
  • VXLAN LIF: Distributed Logical Router 用來介接 Logical Switch,採用 vMAC。
  • VLAN LIF: Distributed Logical Router 用來介接 vDS Port Group,或其它更多 VLAN,採用 pMAC。


每個 VLAN LIF 中存在一個 Designated Instance,負責解析 ARP 並回應給主機,當 ARP Request 封包送到 vDS Port Group 時,就是由 Designated Instance 負責。NSX Controller會在所有主機中選舉,然後推送 Designated Instance 給勝出的那台主機,當發生故障事件時,NSX Controller 會在存活的主機中再次選舉,然後更新資訊給其它存活主機知悉。

Logical Router Control VM (其實就是 vShield Edge),也是從 NSX Manager 挖 Logical Router Control VM 的 OVA 出來部署,它的 HA 機制是採用 AutoStart Manager 來處理,會再長一台 VM 出來,共二台來達成 Active-Standby,同時在 Firewall 內會多規則 169.254.1.1/30、169.254.1.2/30 來進行 Heartbeat 行為。值得注意的部份是,當啟用/關閉 HA 機制,會暫時無法運作!!
  • vCenter *1 (VM)
  • NSX Manager *1 (VM, Management Plane)
  • NSX Controller *3 (VM, Control Plane, 由 NSX Manager 挖 OVA 部署)
  • Logical Router Control VM (VM, Control Plane, 由 NSX Manager 挖 OVA 部署)
  • Logical Router is On Daemon (ESXi Kernel Module, Data Plane)


所以 Management, Control, Data Plane,這三個層級之間的網路流量到底是如何進行傳送? 詳見下圖


了解後,我們來看看一些典型部署模型。首先,是比較簡單的「One-Tier」架構。


接著來看看比較複雜的架構「Two-Tier」。


現在,有了 Distributed Router 之後,當 VM 虛擬主機需要互相溝通時,在同一台 ESXi Host 網路流量的流向。簡單來說,當 ARP 封包到 Distributed Router 後,因為在同一台便直接查到 ARP Table,所以直接回覆網路流量並進行後續溝通 (記憶體流量)。


即使二台 VM 位於不同台 ESXi Host,流量也不會跑到實體 Layer2 層,而是在 VXLAN Transport Network 層就處理好。


Layer 2 Bridging

Layer 2 Bridging 簡單來說,是為了「VXLAN <-> VLAN」之間能夠互通。Layer 2 Bridging 必須要搭配 Distributed Router 才行,若是 VXLAN <-> VXLAN 及 VLAN <-> VLAN 則必須要 Layer3 Routing 設備才能夠互通。


簡單來說,很重要的原則是,只要是可以在虛擬環境交換的流量都會使用 VXLAN,只有需要到實體網路時才會採用 VLAN 流量。此外,Layer 2 Bridging 的 Data path 完全在 VMkernel 進行交換,在 vDS 的 dvPort Type 中稱為 Sink Port,以進行引導封包的橋樑。請注意!! Distributed Routing 及 Layer2 Bridging 「不可」同時運作於 Logical Switch 中。

Bridge Instance 會將學習到的VM虛擬主機 MAC Address,傳送給 NSX Controller(更新 ARP Table)。但是,NSX Controller 只會「選定一台 ESXi」來擔任,也就是把 Bridge Instance是跑在 Control VM Active 當中的那台 ESXi 主機上 (以避免過多的 Broadcast 流量影響網路環境)。所以,發生故障事件後,此時 Standby 主機便立即接手成 Active 角色。


現在,讓我們來看看 VXLAN <-> VLAN 之間,網路流量的的 Flow 流向。從 VXLAN -> VLAN 的 ARP 流程,首先說明 ARP RequestVXLAN -> VLAN 當中的運作:


1. VM1 發送 ARP Request。
2. 因為 VM1 所在的 ESXi 主機,並不知道目的地端的 VM 虛擬主機 MAC Address(IP3, MAC3)。所以,ESXi 主機便詢問 NSX Controller 目的地 MAC Address。
3. NSX Controller 也不知道目的地 MAC Address,所以 VM1 所在的 ESXi 主機,便送出 Broadcast 給 VXLAN 5001 中所有的 ESXi 主機 (VTEP)。
4. VXLAN 5001 中所有的 ESXi 主機收到 Broadcast 之後,轉發給其上運作的 VM 虛擬主機。
5. 與原有的 ARP 行為一樣,當 VM2 收到後請求封包後,因為跟它無關所以就 Drops Frame。
6. Bridge Instance 同樣的也收到請求封包,因為身上有 VXLAN 5001 及 VLAN 100。
7. 因此將 Broadcast 轉送到 VLAN 100 的實體網路去。
8. 實體交換器收到 Broadcast 後,便針對 VLAN 100 所屬的 Port 號進行封包廣播的動作。
9. VM3 主機收到,並確認自已就是 VM1 要找的機器,進入 ARP Response 的回應動作。

接著,來看看 ARP ResponseVLAN -> VXLAN 當中的運作:


1. VM3 送出ARP Response,變成來源端是 MAC3 而目的地端是 MAC1。
2. ARP 回應封包從 VM 虛擬主機,至運作 VM3 的實體主機及實體交換器的 Port。
3. 將 ARP 回應封包,回給剛才送 ARP 請求的 Port。
4. Bridge Instance 的 VLAN 100 介面,收到 ARP Response 封包。
5. Bridge Instance 記錄學習到的 MAC 後,把 ARP Response 封裝後送給處於 VXLAN 5001 的 VM1。
6. ARP 回應封包,到達 VM1 所在的 ESXi 主機,接收學習後轉送給其上運作的 VM1。
7. VM1 虛擬主機,順利收到 VM3 的回應封包,二台主機後續便可順利溝通。

透過 Bridge Instance 運作機制,順利橋接二邊 (VLAN <-> VXLAN) 之後,接著便採用 Unicast 的方式,進行後續的溝通處理作業。


1. VM1(VXLAN 5001) 及 VM3(VLAN 100) 的二台虛擬主機,已經完成了 ARP 查找流程。
2. VM1 的 ESXi 主機,已經把學習到的 MAC(VM3),記錄在本身的 MAC Address Table 當中。
3. VM1 的 ESXi 主機,直接把網路流量傳給 Bridge Instance (不用向之前還要 Broadcast 整個 VXLAN)。
4. Bridge Instance 收到後,因為剛才的 ARP 查找流程中,也已經學習到 MAC(VM3)。因此,便可以直接進行轉發作業。
5. Bridge Instance 轉發封包給 VLAN 100 的 Switch。
6. VM3 所在的 ESXi 主機收到封包。
7. VM3 順利收到 VM1 傳來的封包。

後續,從 VLAN 端發起的 ARP Request,以及 VXLAN 回應的 ARP Response,其實與剛才所述內容相同,只是方向不一樣而以。

NSX Edge Services Gateway

NSX Edge Gateway (也是 vShield Edge VM),負責南-北向 Plane 的溝通作業,所以會有二隻腳串連上下層 (vDS 及 Logical Switch)。此外,它的 HA 機制也是 AutoStart Manager (Active-Standby HA 機制)。

接著,讓我們來看看 NSX Edge 可以擔任的項目,其中它的 Firewall 功能是指「整體」的(網段...etc),而非 Data Plane 中每台 VM 前的 Distributed Firewall。


由前面的範例情境中,你可以了解到 NSX Edge Gateway,擔任的工作負載也很吃重。所以必須要給序適當的硬體資源,比較特別的部份是當給的資源太少時,系統會「自動補足」成最低的需求 (給超過當然沒問題!!)


此外,先前提到 NSX 網路虛擬化環境支援動態路由機制,這部份的工作負載便是由 NSX Edge Gateway 來負責,支援的動態路由有 OSPF, IS-IS, BGP。最後,針對剛才所述的 NSX Edge Gateway 功能,可能還是覺得很籠統。讓我們來看看它詳細的功能項目:

  • Firewall
  • NAT (Network Address Translation)
  • DHCP
  • Routing
  • Load Balancing
  • Site-to-Site VPN
  • SSL VPN
  • L2VPN
  • High Availability
  • DNS / Syslog