Thông tin chung
Software Defined Networking (SDN) với Windows Server 2016 và System Center Virtual Machine Manager 2016 (SCVMM 2016). Ở bài đăng trên wiki này là phần đầu tiên trong tổng số năm phần sẽ được xuất bản trong những tuần tiếp theo. Các bài viết dựa trên một bản tóm tắt (Whitepaper), mà tôi đã viết sau bài phát biểu của mình tại hội nghị CDC 2023, mà tôi đã thuyết trình cùng với Petra Lipp. Whitepaper này chỉ dành riêng cho các độc giả đã đăng ký nhận bản tin. Bạn có thể nhận được toàn bộ Whitepaper dưới dạng PDF nếu đăng ký nhận bản tin của chúng tôi.
Kiến trúc Microsoft SDN
Thực ra, SDN đã có mặt trong Windows Server từ phiên bản 2012 R2. Microsoft đã giấu công nghệ này ở nhiều vị trí khác nhau trong hệ điều hành và SCVMM. Để cô lập các mạng, tiêu chuẩn GRE (Generic Routing Encapsulation) đã được sử dụng. Tuy nhiên, GRE không được thịnh hành trên thị trường cho mục đích này. Hiện nay, đa số các nhà cung cấp mạng đang sử dụng tiêu chuẩn VXLAN (Virtual Extensible LAN), điều này dẫn đến Microsoft đã triển khai giao thức này trên cloud Microsoft Azure và bây giờ cung cấp các thành phần tương ứng trên Windows Server 2016.
Ghi chú: VXLAN hiện là giao thức chuẩn cho SDN. Tuy nhiên, GRE vẫn được hỗ trợ, vì vậy các cài đặt hiện tại vẫn có thể tiếp tục sử dụng. Tuy nhiên, không có kế hoạch chuyển đổi từ GRE sang VXLAN và điều này có nghĩa là cần phải cài đặt lại từ đầu."Trước tiên, chúng ta hãy xem qua hình ảnh kiến trúc dưới đây, được lấy từ thư viện Microsoft TechNet.
Trung tâm của kiến trúc SDN mới là một vai trò máy chủ mới, chỉ có sẵn trong phiên bản Datacenter của Windows Server 2016, được gọi là Network Controller. Chúng ta cần sử dụng hệ thống W2016 Datacenter vật lý hoặc ảo, trên đó vai trò máy chủ này được cài đặt và cấu hình. Và tại sao chúng ta cần nhiều hơn một? Kỹ thuật thì chỉ cần một phiên bản của Network Controller là đủ. Tuy nhiên, để đảm bảo tính sẵn sàng cao, Microsoft khuyên nên có ít nhất 3 phiên bản cho các môi trường sản xuất.
Network Controller có hai giao diện lập trình ứng dụng (API), gọi là Northbound API và Southbound API. Thông qua Southbound API, Network Controller liên lạc với các thiết bị mạng vật lý và ảo, ví dụ như switch vật lý trong tủ máy chủ (Top of Rack – TOR) hoặc các switch ảo trong hệ thống Hyper-V Host. Thông qua Northbound API, Network Controller nhận được hướng dẫn hoặc chính sách từ các công cụ quản lý mạng khác về cách các thiết bị mạng được kết nối thông qua Southbound API xử lý lưu lượng mạng.
Để truyền thông giữa Network Controller và các thành phần mạng khác, trong một nền tảng Microsoft SDN, ta phải sử dụng mạng quản lý (logic) có sẵn trong mỗi trung tâm dữ liệu, được tôi gọi là NC_Management trong bài viết này.
Chú ý: Việc nhúng Network Controller vào mạng NC_Management không dẫn đến việc lưu lượng mạng của các máy ảo khách cũng chạy qua mạng này. Chúng ta sẽ giới thiệu thêm các mạng logic khác để giải quyết vấn đề này.Northbound API được thiết kế dưới dạng Representational State Transfer (REST) API, do đó, bất kỳ công cụ quản lý nào hỗ trợ giao thức này đều có thể được sử dụng để truyền các chính sách đến Network Controller. Ngoài ra, API này còn cung cấp khả năng theo dõi và thu thập thông tin khi gặp sự cố để tiến hành khắc phục lỗi.”
Microsoft hiện tại cung cấp các công cụ quản lý sau để quản lý Network Controller:
- Các lệnh PowerShell Cmdlets
- Azure Resource Manager (ARM)
- System Center 2016 Virtual Machine Manager (SCVMM 2016)
Đặc biệt, SCVMM 2016 cung cấp một giao diện đồ họa dễ sử dụng cho việc cấu hình Network Controller và cũng cung cấp tất cả các chức năng thông qua các PowerShell Cmdlets riêng của nó. Chúng ta sẽ xem xét điều này cụ thể hơn sau.
Network Controller sau đó phân phối các chính sách được nhận thông qua Northbound API của nó thông qua Southbound API đến các thiết bị mạng liên quan. Đối với các máy chủ Hyper-V, đây là một phần mở rộng Hyper-V Switch mới (Extension) có tên Microsoft Azure VFP Switch Extension. VFP đại diện cho “Virtual Filtering Platform”.
Do đó, kiến trúc SDN của Microsoft bao gồm 3 tầng, như hình dưới đây thể hiện.
Ảo hóa mạng
Các mạng ảo logic riêng biệt có thể được định nghĩa cho các nhóm khách hàng VM (thường được gọi là VM “Tenant”). Các mạng này hoàn toàn cách ly lẫn nhau, ngay cả khi chúng có các tham số mạng giống nhau như phạm vi địa chỉ IP hoặc VLANIDs. Sự cách ly lưu lượng dữ liệu bên trong một mạng ảo như vậy được thực hiện thông qua việc “đóng gói” các gói dữ liệu theo giao thức VXLAN.
Giao thức VXLAN
Các VM trong mạng ảo thường sử dụng các địa chỉ IP được đặc biệt cho khách hàng (“Customer Addresses” – CAs), không được quản lý bởi nhà cung cấp trung tâm dữ liệu và các thiết bị mạng trong trung tâm dữ liệu không thể làm gì với chúng. Khi một VM khách hàng muốn giao tiếp với một VM khách hàng khác, nó sẽ gửi một gói dữ liệu Ethernet qua bộ chuyển mạng của nó, trong một môi trường Hyper-V, nó sẽ gửi qua Hyper-V Switch của máy chủ nơi nó đang chạy. Trong Hyper-V Switch, nó sẽ kiểm tra xem VM đích có đang chạy trên cùng một máy chủ hay không. Nếu có, gói dữ liệu mạng sẽ được truyền trực tiếp đến VM tương ứng.
Nếu VM đích đang chạy trên máy chủ khác, gói dữ liệu sẽ được đóng gói vào một gói dữ liệu mạng mới với địa chỉ IP được quản lý bởi nhà cung cấp trung tâm dữ liệu (“Provider Addresses” – PAs) theo giao thức VXLAN và được gửi đến máy chủ đích qua UDP. Máy chủ đích sau đó có thể giải nén gói dữ liệu gốc và chuyển tiếp cho VM tương ứng.
Để đảm bảo sự phân bổ đúng cho một gói dữ liệu khách hàng được đóng gói, mỗi mạng khách hàng ảo được gán một VXLANID duy nhất khi được tạo ra thông qua Bộ điều khiển mạng. VXLANID này có chiều dài 24 bit. Vì vậy, có thể xác định được tới 16 triệu mạng khách hàng. Khi đóng gói một gói dữ liệu khách hàng, VXLANID của mạng khách hàng được thêm vào phía trước của gói dữ liệu khách hàng như tiêu đề, để khi giải nén dữ liệu trên host đích, nó có thể được định tuyến đến mạng khách hàng tương ứng.
Để truyền thông giữa các máy ảo khách hàng, chúng ta cần một (và chỉ một) mạng logic được quản lý bởi nhà cung cấp, qua đó các gói dữ liệu khách hàng được gói gọn bằng giao thức VXLAN và được chuyển tiếp. Đối với các thiết bị mạng khác như switch hoặc router trong mạng, các gói dữ liệu của các máy ảo khách hàng là “vô hình” và không cần các hoạt động quản lý khác.
So sánh với phương pháp trước đây để ảo hóa mạng với VLANIDs, mỗi mạng khách hàng phải được xác định bởi một VLANID duy nhất được quản lý bởi nhà cung cấp và phân phối cho tất cả các thiết bị mạng. Vì VLANIDs chỉ có độ dài 12 bit, số lượng mạng khách hàng cũng bị giới hạn chỉ khoảng 4096.
Mạng logic để chuyển tiếp các gói dữ liệu được gói gọn bằng VXLAN thường được gọi là mạng HNVPA (mạng ảo hóa mạng Hyper-V với địa chỉ nhà cung cấp) trong môi trường SDN của Microsoft.
Vì vậy, ảo hóa mạng với VXLAN đơn giản hóa quản lý mạng đáng kể trong một trung tâm dữ liệu, vì nhà cung cấp không còn phải quan tâm đến việc cô lập các mạng khách hàng một cách rõ ràng.
Load Balancing
Đối với các VM cung cấp tải trọng công việc tương tự nhau trong một mạng lưới ảo khách hàng (ví dụ: cụm máy chủ web), cân bằng tải (SLB) có thể được xác định bằng phần mềm dưới dạng một nhóm SLB. Việc cân bằng tải được thực hiện bởi các VM độc lập được quản lý bởi Bộ điều khiển mạng. Các VM SLB sau đó cũng cho phép truy cập từ bên ngoài vào các nhóm SLB trong mạng lưới ảo khách hàng.
Một nhóm SLB chứa các địa chỉ IP ảo của các VM khách hàng được xác định để thực hiện cân bằng tải (được gọi là địa chỉ IP động – DIP ở đây). Nhóm được gán một địa chỉ IP công khai (PublicIP). PublicVIP thường có thể được truy cập qua Internet, để người dùng bên ngoài có thể kết nối với chúng.
Bộ điều khiển mạng chuyển giao các định nghĩa này đến các VM SLB thông qua mạng quản lý NC_Management. Chúng lại đưa ra PublicVIP qua giao thức BGP trên một router BGP trung tâm, cung cấp kết nối với thế giới bên ngoài. Truyền thông giữa các VM SLB và router BGP thường được thực hiện thông qua một mạng lưới logic riêng với tên Transit.
Bây giờ, khi một yêu cầu đến router BGP với một địa chỉ VIP công khai đã biết, nó được chuyển tiếp qua một VM SLB trong mạng lưới Transit để được xử lý tiếp theo. Vì tất cả các VM SLB đều chứa các định nghĩa của nhóm giống nhau, nên có nhiều lựa chọn để chuyển tiếp. Vì vậy, chúng tôi cũng nói về một bộ chuyển tiếp SLB hoặc SLB-MUX. Khi chuyển tiếp, địa chỉ đích của yêu cầu được ghi đè bằng địa chỉ SLB-MUX trong mạng Transit.
Để làm điều này, địa chỉ đích trong yêu cầu được ghi đè bằng DIP đã được xác định và gói tin được đóng gói bằng VXLAN và truyền qua mạng HNVPA tới máy chủ Hyper-V tương ứng. Máy chủ Hyper-V giải nén gói tin và chuyển tiếp đến máy ảo tương ứng.
Máy ảo sau đó tạo ra một phản hồi, có địa chỉ đích là địa chỉ khách hàng ban đầu và địa chỉ nguồn là DIP của nó. Switch trong máy chủ Hyper-V thay thế DIP này bằng PublicVIP được gán cho SLB-Pool và sau đó gửi gói tin qua cổng mạng Internet trực tiếp đến khách hàng gốc. Vì vậy, khách hàng không biết về các bước chuyển tiếp khác nhau trong môi trường SLB-MUX.
Remote Access Service (RAS) Multitenant Gateways
Remote Access Service (RAS) Multitenant Gateways Trong mô tả trên cho chức năng Load Balancing, tôi đã tóm tắt cách xử lý yêu cầu của một khách hàng duy nhất từ internet trong một môi trường SDN. Tuy nhiên, trong nhiều trường hợp, không chỉ cần thiết để thiết lập kết nối từ một hệ thống khách hàng đơn lẻ đến các máy ảo của một khách hàng, mà còn cần kết nối các mạng bên ngoài với các hệ thống ảo của một khách hàng.
Để làm được điều này, trình điều khiển mạng cung cấp chức năng Remote Access Service (RAS) Multitenant Gateway. Đây là các máy ảo riêng (tương tự như các hệ thống SLB-MUX) được quản lý bởi trình điều khiển mạng. Sau đó, các kịch bản từ xa sau đây có thể được thực hiện:
Site-to-Site VPN Point-to-Site VPN GRE Tunneling Định tuyến động với Border Gateway Protocol (BGP)
Tôi sẽ không đề cập nhiều đến các chủ đề này, vì chúng ta cần các hệ thống từ xa tương ứng để cấu hình, điều này xa vượt qua chủ đề SDN. Có thể chúng ta sẽ quay lại với chủ đề này trong bài đăng của chính mình sau này.
SDN-Topology
Sau khi chúng ta đã giải thích một số đặc điểm cơ bản của kiến trúc SDN của Microsoft, chúng ta muốn xem xét ngắn gọn làm thế nào để tất cả điều này có thể ánh xạ vào một môi trường vật lý.
Logical networks
Đây là một tóm tắt về các mạng logic cần thiết trong một môi trường SDN:
- NC_Management – Đây là mạng trung tâm, qua đó tất cả các hệ thống trong một “Software Defined Datacenter” (SDDC) được quản lý và cấu hình, bao gồm các bộ điều khiển mạng với các thành phần SDN như SLB-MUXe và cổng vào, các máy chủ Hyper-V, cũng như các hệ thống cơ sở hạ tầng khác như Active Directory, DNS và SCVMM. Bộ điều khiển mạng cũng nhận và phân phối các hướng dẫn cho các thành phần SDN thông qua mạng này.
- HNVPA – Các gói mạng được đóng gói bằng giao thức VXLAN của các VM khách hàng di chuyển qua mạng này giữa các máy chủ Hyper-V.
- Transit – Mạng này được sử dụng cho việc giao tiếp giữa các hệ thống SLB-MUX và thế giới bên ngoài, ví dụ như với một BGP-Router được kết nối với Internet.
Ba mạng logic này cùng tạo nên cột sống của SDN. Chúng phải có sẵn trong tất cả các máy chủ Hyper-V tham gia và được kết nối với các công tắc ảo. Mỗi mạng này đều có một bể địa chỉ IP riêng. Bên cạnh đó, chúng cũng có thể được tùy chọn cách ly lẫn nhau bằng các VLAN, tuy nhiên điều này không bắt buộc (tôi sẽ không sử dụng chúng trong môi trường Lab sẽ được mô tả sau).
Đối với các kịch bản đặc biệt, có thể cần thêm các mạng logic khác, nhưng không cần phải có sẵn trên các Hyper-V Hosts:
- PublicVIP – Mạng này là cổng kết nối đến và từ Internet. Trong thực tế, địa chỉ IP được sử dụng sẽ là địa chỉ công cộng và không có sự cô lập bằng VLAN IDs.
- PrivateVIP – Mạng này chứa các địa chỉ riêng, cho phép các máy khách nội bộ như quản lý SLB và các dịch vụ nội bộ khác có thể giao tiếp với nhau.
- GREVIP – Mạng này chứa địa chỉ IP ảo cho các điểm cuối của các kết nối Site-to-Site (S2S) với các mạng bên ngoài (Tenant), trong đó sử dụng giao thức GRE.
Bên cạnh các mạng logic đặc biệt SDN này, trong một trung tâm dữ liệu còn có các mạng logic khác, ví dụ như kết nối lưu trữ, nhưng chúng ta không muốn xem xét thêm ở đây.
Phần cứng Hyper-V
Để triển khai một môi trường SDN, chúng ta cần có một số máy chủ Hyper-V với phiên bản Windows Server 2016 Datacenter Edition. Tối thiểu nên có 3-4 hệ thống có sẵn, tốt nhất là được tổng hợp thành một Hyper-V Failover Cluster. Trong một môi trường sản xuất, chúng ta sẽ sử dụng nhiều hệ thống hơn nhiều.
Network hardware
Đối với phần cứng mạng, thực tế thì SDN không đặt ra các yêu cầu đặc biệt về phần cứng mạng trong các Hyper-V Hosts. Tuy nhiên, cần lưu ý rằng toàn bộ lưu lượng mạng SDN sẽ chạy qua các ảo hóa Switch trong các Hyper-V Hosts, do đó yêu cầu băng thông và tính sẵn có cao. Do đó, ta nên xem xét sử dụng tính năng Teaming của các adapter mạng trong các Hyper-V Hosts là một lựa chọn, nhưng điều đó không bắt buộc.
Để Teaming, có thể sử dụng cả hai loại Teaming “truyền thống” dựa trên hệ điều hành Windows và “Switch Embedded Teaming” (SET) trong Hyper-V Switch của Server 2016. Nếu có thể sử dụng với các adapter mạng hiện có, thì nên sử dụng SET.
Kết hợp tất cả các thành phần đã mô tả
Nếu chúng ta kết hợp tất cả các thành phần đã mô tả ở trên trong một môi trường SDN, thì chúng ta sẽ có một hình ảnh sau đây cho Topologie SDN:
Mô tả cấu trúc của một mạng SDN dưới đây, được lấy từ nguồn https://docs.microsoft.com/en-us/windows-server/networking/sdn/plan/plan-a-software-defined-network-infrastructure#network-controller-software-load-balancer-and-ras-gateway-deployment.
Ở tầng thấp nhất là mạng vật lý và các mạng SDN logic được tích hợp trong đó. Mạng này được kết nối với các bộ điều khiển mạng của tất cả các máy chủ Hyper-V, có thể được tập hợp lại thành các nhóm trên máy chủ Hyper-V. Nếu bạn đã định nghĩa các mạng SDN logic như là các VLAN, thì quan trọng là cần thiết phải đặt chế độ Trunk cho các cổng trên các Switch vật lý mà Hyper-V Host kết nối để đảm bảo rằng tất cả các mạng SDN đều có sẵn trên các Hyper-V Switch ảo.
Các Hyper-V Switch ảo trình bày các mạng SDN cho các VM cơ sở hạ tầng đang chạy trên máy chủ, chẳng hạn như bộ điều khiển mạng, SLB-MUXe hoặc Gateway, để họ có thể kết nối với chúng qua các bộ chuyển mạch ảo.
Các bộ chuyển mạch ảo trong Hyper-V Switch kết nối các adapter mạng ảo của các VM khách với mạng HNVPA. Quá trình đóng gói và giải nén dữ liệu của khách thuê bao sử dụng giao thức VXLAN sẽ được thực hiện tại các bộ chuyển mạch ảo Hyper-V.
Other infrastructure systems
Để xây dựng một môi trường SDN, ngoài các hệ thống Hyper-V Compute, chúng ta còn cần một số hệ thống cơ sở hạ tầng khác:
- Active Directory với DNS.
- Một hệ thống với System Center Virtual Machine Manager (SCVMM) 2016 để quản lý môi trường SDN.
- Một BGP Router cung cấp kết nối với mạng công cộng.
Trong bài đăng tiếp theo, tôi sẽ quay trở lại với các hệ thống này khi chúng ta xây dựng môi trường thực hành của mình.
