VMware NSX – Network Virtualization (Phần 1)

Phần 1: Giới thiệu

Với sự phát triển, công nghệ ảo hóa ra đời đặc biệt là ảo hóa máy chủ đã đem tới những siêu lợi ích về đơn giản hóa cơ sở hạ tầng, tăng cao khả năng hoạt động cũng như tận dụng triệt để nguồn tài nguyên và nhiều lợi ích khác. Không đừng ở đó, VMware vừa cho ra đời sản phẩm VMware NSX giúp ảo hóa cả hạ tầng network.Nếu đối với bộ sản phẩm vSphere giúp thu gom các tài nguyên vật lý máy chủ (Server Hypervisor) như CPU,RAM,NIC…để cung cấp cho các máy ảo (VM) thì nay với NSX với  Network Hypervisor/Network Virtualization Platform là 1 bộ chi tiết các thiết bị ảo như Switch, Router, Firewall, Balancer..v..v.  cung cấp dịch vụ mạng (thiết bị mạng) từ lớp 2 tới lớp 7.

H1: Mô hình tương quan giữa ảo hóa máy chủ và ảo hóa mạng

Với việc ảo hóa hạ tầng mạng, thì việc thêm, xóa, thay đổi các thiết bị nay chỉ với vài click chuột đơn giản mà không cần setup phần cứng phức tạp. Đây sẽ là bước ngoặt cho các hệ thống mạng trong tương lai.

1. Thành phần trong VMware NSX:
VMware chia mô hình VMware NSX thành 3 phần: Management Plane, Control Plane và Data Plane.

a. Management Plane (Bảng quản lý)

NSX Manager là giao diện quản lý web-based cho phép quản trị viên có thể thêm bớt, giám sát hệ thống mạng ảo, tương tự như snapshot VM của vSphere, NSX có khả năng snapshot trạng thái các thiết bị ảo cũng như backup/restore.

b.Control Plane (Bảng điều khiển/kết nối)

NSX Controller tiếp nhận các API của vSphere và các Hypervisor khác (Xen, KVM…) và liên lạc với vSwitch, Gateway để forward thông tin.
Cần tối thiểu 3 NSX Controller trong 1 Controller Cluster để đảm bảo tính sãn sàng và trong NSX Controller (vẫn có quyền cài 1) chỉ forward các thông tin liên quan Control Plane, không chứa thông tin của Data Plane.
NSX Controller cũng liên lạc với các NSX Egde (Brigde,Gateway).

c. Data Plane

Data Plane gồm có NSX vSwitch sẽ liên lạc trực tiếp với Control Plane. Với môi trường sử dụng vSphere thì NSX vSwitch dựa trên VDS ( Virtual Distributed Switch) và Open vSwitch cho Hypervisor khác.
vSwitch hỗ trợ các tính như Routing, Firewall, VXLAN, Balancer…v.v.v.

Tuy NSX hỗ trợ cho cả các Hypervisor khác (KVM, Xen) nhưng thực tế vẫn có sự khác biệt giữa 2 mô hình : thuần vmware và thập cẩm.

* Mô hình đa Hypervisor (Xen/KVM/ESXi):
Với mô hình này lớp Control Plane hay rõ hơn là Controller phải là thiết bị vật lý và NSX Gateway cũng là thiết bị vật lý.

Hiện nay Hyper-V vẫn chưa được đề cập tới trong VMware NSX.

*Mô hình thuần VMware (ESXi only)
Ơ mô hình này, được hỗ trợ từ A-Z các chức năng ảo thiết bị như Controller, NSX Edge và VDS của VMware
Lúc này NSX Manger sẽ cùng làm việc nang hàng với  vCenter

Ở bài tới, sẽ đi sâu hơn vào các thành phần của VMware NSX

VMware vSphere 4: Tổng quan virtual network

Ngay từ những phiên bản đầu tiên Vmware đã khẳng định được vị thế của mình trong làng công nghệ ảo hóa. Không đơn thuần mà Vmware được đánh giá cao như thế nó là sự nỗ lực nghiên cứu phát triển không ngừng trong lĩnh vực ảo hóa máy chủ. Hạ tầng Virtual Network của Vmware tiềm tàng các đặc tính mạnh mẽ nhất hỗ trợ tối đa cho các thiết kế hạ tầng network enterprise. Chúng có thể được quản lý riêng lẻ trên từng cá thể host của môi trường ảo cũng như  quản lý tập trung nhất thông qua sản phẩm Vmware vCenter.

Nhìn chung hạ tầng network của Vmware gồm các thành phần như hình sau:

Tình từ trên xuống có các thành phần như sau:

Nic ảo (card mạng ảo) là thiết bị network giao tiếp chính giữa các VMs với hạ tầng network bên dưới cả ảo lẫn physical. Trong quá trình dài phát triển của mình VMware cho ra đời nhiều phiên bản, dòng Nic ảo khác nhau cho môi trường ảo như

• Vlance ( một dạng cacrd hỗ trợ cho các dòng OS cũ chỉ support 10Mbps
• VMxnet là một dòng card hỗ trợ tối ưu hóa network cho các VMs nhưng đòi hỏi phải cài đặt driver trong Vmware Tools
• Flexible là một định nghĩa card khá đặc biệt nếu sử dụng nó thì bạn đầu boot và sử dụng network sẽ hoạt động như Vlance khi thiết lập vmware tools và cái đặt các driver vmware thì sẽ hoạt động ở dạng VMxnet
• E1000: tiếp theo đó là sự ra đời cho dòng Nic E1000 nó là kết quả của quá trình giả lập hoạt động cấu trúc của card Intel 82545EM Gigabit Ethernet NIC. Tuy nhiên driver của thiết bị này không có sẵn trên tất cả OS mà chỉ có trên các phiên bản từ Linux versions 2.4.19, Windows XP Professional x64 Edition và  Windows Server 2003 (32-bit) trở lên.
• Về sau là sự phát triển của dòng VMxnet là VMxnet2 và VMxnet3 ngoài nâng cao khả năng hiệu suất còn có một số tính năng đặc biệt khác như jumbo frames , hardware offloads…

P/s: một VM tối đa được add 10 Nic ảo

Bản thân Host ESX/ESXi cũng sẽ có một hoặc nhiều Nic ảo để dành cho hoạt động giao tiếp với bên ngoài như vCenter. Trong các phiên bản trước thì đối với trường hợp này sẽ có 2 khái niệm:

Service Console: thực chất chỉ là tên một tên gọi bản chất của nó là một OS thu nhỏ gồm nhiều thành phần service: firewall, Simple Network, Management Protocol (SNMP) agents, web server…phục vụ cho nhu cầu tương tác với ESX và VMs được đóng gói sẵn trong các phiên bản trước nhằm cung cấp các giao diện quản lý trực tiếp trên host. Nhưng vì trong quá trình vận hành chúng trở nên không cần thiết nên đuợc lược bỏ đi trong các phiên bản sau này (từ bản 4 là không còn).

VMKernel: là lõi điều khiển chính cho toàn bộ hoat động bên dưới của các VMS hỗ trợ tương tác với phần cứng như quản lý lịch CPU, quản lý memory cũng như các tiến trình xử lý network bên trong các vswitch VMkernel bản thân nó cũng có một IP riêng dùng cho việc liên lạc với vCenter, vMotion, Fault tolerance, quản lý từ xa….

Lớp kế tiếp trong môi trường mạng ảo của Vmware là thành phần quan trong nhất nó chính là hệ thống các switch ảo. Mặc định mỗi host ESX/ESXi sẽ có một hệ thống switch riêng gọi là Virtual Standard Switch (vSwitch)

Mỗi host sẽ có một bộ vSwitch trong bộ đó sẽ có nhiều switch ảo. Trên mỗi vSwitch sẽ có nhiều port ngoài port cho service console và vmkernel dành cho host thì các port còn lại dành cho máy ảo nên còn gọi là VM port tuy nhiên trên các vSwitch để có thể plug Nic ảo vào vSwitch chúng ta cần thiết lập nên các nhóm port (Port Group) để có thể tùy nhu cầu mà thiết lập các policy khác nhau cho các nhóm port khác nhau ( I/O, Vlan, failover…) ngoài ra để đi ra được môi trường mạng bên ngoài thì mỗi vSwitch cần có ít nhất một Nic thật hay còn gọi là uplink mỗi vSwitch có thể mang theo nhiều uplink để failover, Load Balancing (tập hợp các uplink lúc này gọi là Nic Teaming) tuy nhiên chú ý là một NC thật chỉ  thuộc một vSwitch. Một số tác dụng của vSwitch như sau:

• Kết nối các máy ảo trong cung một host
• Kết nối giữa các máy ảo khác host với sự hỗ trợ của các uplink
• Kết nối giữa các máy ảo và máy vật lý trong hệ thống mạng
• Phuc vụ cho các truy cập Service console (chỉ trên ESX)
• Phục vụ VMkernel phục vụ mục đích  VMotion, iSCSI, NFS, hoặc fault tolerance logging và quản lý trên ESXi.

Trên cơ bản vSwitch hoạt động không khác gì các switch thông thường tuy nhiên chúng không hỗ trợ các giao thức STP, VTP. Vì trong môi trường mạng thật nhiệm vụ của switch là kết nối và mở rộng thêm hạ tầng tuy nhiên trong môi trường ảo thì các switch ảo trên đó có thể có hằng trăm port nên việc kết nối các switch lại để mở rộng hạ tầng là không cần thiết. Đồng nghĩa việc các switch ảo này nằm ở lớp access cuối cùng không kết nối thêm switch nào nữa nên không xảy ra loop mà không xảy ra loop thì không cần STP đồng thời cũng chẳng có môi trường để cần sử dụng giao thức VTP. Nhưng vẫn hỗ trợ Vlan nhưng theo một phương thức khác điền hình là 3 loại thiêt kế:

• Virtual switch tagging (VST mode)
• Virtual machine guest tagging (VGT mode)
• External switch tagging (EST mode)

Tuy nhiên việc sử dụng vSwitch trong môi trường mạng thật tế đã đem đến nhiều phiến phức trên mỗi host phải cấu hình từng bộ vSwitch, port group… để đảm bảo tính chung nhất cho toàn hệ thống đảm bảo cho các tính năng Migration do đó bài toán đặt ra là chúng ta cần một hệ thống vDS có thể quản lý tập trung được. Và để giải quyết bài toán tập trung này VMware đã xây dựng lên một khái niệm switch mới và chỉ có thể cấu hình và phân phôi từ vCenter Server gọi là Virtual Distributed Switch (vDS). Cấu hình sẽ được lưu trong database và phân phối đến từng host qui định.

So Sánh vSwitch và vDS

Ngoài việc khác nhau ở mặt quản lý tập trung thì hoạt bên trong giữa vSwitch và vDS vẫn có một số giống và khác nhau:

Giống nhau:

• Đều làm việc ở Layer 2
• Hỗ trợ việc đóng gói và vận chuyển vlan
• Có thể có một hay nhiều uplink (Nic teaming)
• Quản lý I/O chiều ra cho các luu thông traffic

Khác nhau (chỉ trên vDS):

• Hỗ trợ quản lý I/O cả hai chiều
• Quản lý tập trung qua giao diện quản lý của vCenter Server
• Hỗ trợ Private vLan (PVLANS)

Ngoài ra còn một loại switch ảo đặc biệt thuộc hãng thứ 3 là Cisco phát triển đưa vào hoạt động trong môi trường ảo của VMware gọi là Cisco Nexus 1000 loại này cũng tương tự như vDS đều có thể quản lý tập trung. Tuy nhiên đây là sản phẩm dựa trên nền tảng network của Cisco nên nó mang lại những khác biệt vượt trội về policy, security, QoS…

Qua phần 1 của loạt bài về netowrk này hẳn các bạn đã nắm rõ sơ bộ về “hình hài” của hệ thống virtual network trong VMware vSphere 4. Nếu chưa rõ vui lòng xem lại VMware vSphere 4: Tổng quan virtual network (P.1). Tiếp theo loạt bài này chúng ta sẽ đi sâu về các thuật ngữ , các tính năng tùy chọn trong một Virtual Switch (vSwitch lẫn vDSwitch).

Trước hết chúng ta cần view lại một tý về một ví dụ điển hình khi thiết kế một vSwitch

Trong ví dụ bên trên là một vSwitch điển hình với một Port Group dành cho máy ảo và một VMkernel dành cho việc quản lý, vmotion, smotion… của máy host. Và ở đây chúng ta cần nhắc lại một số quy tắc:

• Một vNic chỉ plug được một port trong portgroup trên vSwitch
• Một host có thể có nhiều vSwitch cùng tồn tại
• Một vSwitch có thể có nhiều port manangement cũng như có thể có nhiều port group với các policy khác nhau như Vlan, security, control I/O network…
• Và để traffic network để đi ra được hệ thống switch physical thì chúng ta cần một đến nhiều uplink (NIC physical) khi mà một vSwitch có hơn hai uplink thì một tính năng đặc biệt sẽ có trong từng Port Groupđược gọi là NIC teaming

 NIC TEAMING

Ban đầu NIC Teaming trong một portgroup sẽ mặc định disable trừ khi chúng ta bật tính năng này lên. Tính năng này cho phép chúng ta quy định các thức làm việc của một nhóm các uplink trong một portgroup với sự hỗ trợ của các tùy chọn : load balancing, failover…

Xin nhắc lại là tính năng này là một policy về loadbalancing và failover nó chỉ được cấu hình ở mức độ portgroup thay vì vSwitch vì đơn giản policy này sẽ giúp chúng ta uyển chuyển hơn trong việc quản lý các nhóm máy ảo trên hệ thống với cơ chế loadbalancing, failover khác nhau.

Trong tính năng này cái chúng ta quan đầu tiên và quan trọng đó là các thức để load balancing các port uplink với bất cứ luồng traffice nào từ portgroup cấu hình muốn đi ra mạng physical bên ngoài.

Chúng ta tổng cộng có tất cả 4 cách thức Load Balancing khác nhau được VMware hỗ trợ:

Route based on the originating virtual port ID

Trong phương thức cân bằng tải này sẽ dựa trên cơ chế mỗi port trong một port group sẽ mapping (ánh xạ) với một physical NIC bằng cách chia đều port cho các card physical như hình sau

Một số điều lưu ý là chúng sẽ không quan tâm đến VM bên trên nên sẽ có trường hợp một VM 2 vNic có thể sẽ cùng dùng chung một physical Nic. Và bên cạnh đó với phương thức này tại một thời điểm một vNIC chỉ có thể đi ra một physical NIC. Nên phương thức này không thể xem như một phương thức cân bằng tải hiệu quả.

Kết quả cũng diễn ra tương tự với phương thức tiếp theo

Route based on source MAC hash

Với phương thức Route based on the originating virtual port ID thay vì dựa theo thứ tự port để phân chia ra các physical NIC thì với phương thức thứ hai này lại dựa vào MAC address cùa  vNIC để phân chia việc mapping physical nên gần như kết quả không gi mới mẻ so với phương thức đầu.

Đển với phương thức thứ 3 cũng là phương thức được đánh giá là giải quyết được bài toán Load Balancing thực sự

Route based on IP hash

Tại sao phương thức này được đánh giá cao về loadbalancing đo chính là vì phương thức chọn physical NIC của nó cực kỳ linh động với nhiều trường hợp. Phương thức của nó dựa trên việc băm (IP source + IP dest) và kết quả đó sẽ được dùng để quyết định lần lượt mỗi des IP khác nhau sẽ đi ra một physical NIC khác nhau. Giải quyết bài toán là tại một thời điểm có thể dùng cả physical NIC. Điển hình với 2 physical NIC 1GB chúng ta có thể đạt tới mức sử dụng 2GB thay vì dùng 2 phương thức trên chỉ tối đa một NIC 1GB.

Tuy nhiên nó không có lợi trong trường hợp một session truyền tải một lượng lớn data vì tất cả cũng chỉ sẽ đi qua một uplink do chi có một dest duy nhất trong một session. Ngoài ra với kiểu thiết kế dung Route baed on IP hash thì các up link phải cũng nối vào một physical switch để không gặp tình trạng một physical switch sẽ thấy MAC Vm trên nhiều port switch khó để dự đoán NIC nào sẽ nhận được gói tin trả về. Chú ý một điều “Route based on IP hash” chỉ quản lý chiều đi còn chiều về là tùy thuộc switch physical nhưng do switch physical đều lưu bảng Mac table rằng có nhiều port ra cho cùng một MAC address hiển nhiên nó sẽ broadcast ra các port đó. Nên thường thiết kế sử dụng Ethernet Channel để đạt hiệu quả cao hơn cho cả hai chiều.

Bên cạnh đó với thiết kế các uplink hoạt động dạng Ethernet Channel trên physical switch thì chỉ có một policy là route based on IP hash là có thể sử dụng trong trường hợp này.

Use explicit failover order

Phương thức này hoạt độngdựa theo thứ tự sắp xếp các NIC trong bảng như bên dưới để quyết định NIC hoạt động.

NETWORK FAILOVER DETECTION

Bản thân NIC teaming ngoài mặt hoạt động loadbalancing thì bản thân nó còn có khả năng xử lý failover. Tuy nhiên cái mà chúng ra quan tâm là làm sao nhận dang là failed. Bao gồm 2 tùy chọn:

Link status only

Phương thức này xác định một uplink là failed dựa trên trạng thái port của uplink. Khi port này mất tin hiệu với switch đồng nghĩa với việc việc nó failed. Tuy nhiên mấu chốt đây là nó chỉ có thể nhận dang failed với switch gần nhất cắm trực tiếp vào nó.

Trong khi hệ thống mạng chúng ta có thể có nhiều switch nối với nhau và nó trợ thành điểm yếu chết người cho phương thức này. Nó có thể nhận dạng failed trên switch thứ 1 gần nó nhưng khi switch thứ 2 thứ 3.. có tình trạng port failed thì nó không nhận dạng được. Để giải quyết tình thế này chúng ta cần áp dụng khái niệm gọi là Link state Tracking (cisco) hãng khác còn có tên gọi là Link Dependency

Tính năng này cho phép nhóm các port có mối liên hệ với nhau thành nhóm “quan hệ” với nhau. Ví dụ như hình trên port nối với uplink trái là port A và port còn lại trên cung switch là port B. Lúc này 2 port A và B chúng ta cấu hình Link state Tracking thì khi đầu B failed thì đồng nghĩa đầu A failed chung để giải quyết trường hợp bên trên khi đường đi switch 2 switch 3 failed… Trên thực tế Link State Tracking cần được cấu hình liên tục cả một chuỗi các switch đảm bảo bất cứ segment nào down cũng sẽ được hê thống VMware nhận dạng.

Beacon Probing

Ngoài việc có thể giải quyết bằng link state tracking VMware còn đưa ra một tùy chọn mới là Beacon Probing đây là một cơ chế đặt ra nó liên tục theo thời gian gửi đi và lắng nghe các tin phản hồi trên tất cả các NIC trong team và dùng thông tin này để nhận định tình trạng failed trên các NIC. Mục tiêu đặt ra cho cơ chế này là nhận dạng failed trong các trường hợp về cáp, switch bao gồm cả switch trực tiếp với NIC và các switch khác trên đường đi traffic, bên cạnh đó hỗ trợ một phần nào đó việc xác nhận cấu hình sai Vlan, port.. trên hệ thống switch.

Phương thức hoạt động của Beacon là theo định kỳ gửi các gói tín hiệu broadcast (tất cả VLAN đang có) ra tất cả các NIC trong Team.  Các physical switch lúc này sẽ tiếp nhận và đẩy ra các port cùng broadcast domain. Bên cạnh đó các NIC khác trong Team sẽ là các đối tượng chính tiếp nhận gói tin này. Nếu sau khi gửi tin bất kỳ một uplink nào trong Team không nhận được “3 tín hiệu” liên tục đồng nghĩa nó đang trạng thái lỗi.

Trên thực tế Beacon chỉ có lợi điểm khi hoạt động trong một nhóm nhiều hơn 3 NIC bởi khi chỉ có 2 NIC một khi fail xảy ra hệ thống sẽ không đảm bảo việc NIC nào sẽ đặt trong trạng thái fail loại bỏ việc sử dụng nó vì lúc này cả hai đều không nhận được tín hiệu của nhau.

Notify switches

Đây là một tùy chọn nhăm hỗ trợ giảm thời gian xây dựng lại bảng MAC table trên các switch thật. Cơ chế như sau khi NIC Teaming xảy ra bất kỳ sự kiện nào trong danh sách sau:

• Máy ảo được khởi động
• Một sự kiện vMotion xảy ra
• MAC address máy ảo bị thay đổi
• Failover và Failback trong NIC teaming xảy ra

Một khi xảy ra một trong các sự kiện say hệ thống sẽ sử dụng Reverse Address
Resolution Protocol (RARP) để thông báo sự thay đổi cho hệ thống switch thật về vị trí máy ảo hoặc MAC address trên hệ thống ảo giảm độ trễ cho phần network khi vMotion, change MAC address… xuống thấp nhất có thể.

Failback

Tính năng này cho phép khôi phục trạng thái active của một Uplink khi trải qua trang thái failed và đã được khôi phục chức năng.

Traffic Shapping

Là một tính năng hỗ trợ việc giới hạn băng thông “đi ra” (outbound) trên nhóm port group cụ thể bao gồm trong đó là 3 thông số cấu hình chính:

• Average Bandwidth – lượng data trung bình mỗi giây truyền qua vSwitch
• Peak Bandwidth – băng thông tối đa mà vSwitch có thể cho qua
• Burst size – lượng data tối đa trong một chu kỳ

Security

Về bảo mật thì trong port group khá hạn chế chủ yếu gồm có 3 thông số chính:

Promiscuous Mode: mặc định là tắt trên tất cả máy ảo. Tính năng này sẽ hạn chế việc nghe trôm các gói tin unicast của các đối tượng khác trong cùng network.

MAC Address Changes: Đảm bảo sự toàn vẹn của các luồng traffic thông qua vSwitch đến máy ảo. Nếu cấu hình Reject thì mọi traffic đến VM sẽ bị drop nếu như Mac address trong file cấu hình VMware khác Mac Address hoạt động trong quá trình truyền tải dữ liệu

Forged Transmits: Đảm bảo sự toàn vẹn của các luồng traffic từ VMs đi đến vswitch. Khi bật reject hệ thống sẽ drop mọi traffic đi ra nếu như Mac address trong file cấu hình VMware khác Mac Address hoạt động trong quá trình truyền tải dữ liệu

Vì thế khi cấu hình Network Load Balancing nên chú ý cấu hình Accept cho hai tính năng MAC Address Changes và Forged Transmits