Open vSwitch là gì và hoạt động như thế nào

Trong một Private Cloud OpenStack, mọi gói tin ra vào máy ảo đều đi qua một switch chạy bằng phần mềm trên host. Với phần lớn triển khai, switch đó là Open vSwitch (OVS). Bài này trả lời ba câu hỏi: OVS là gì, gói tin đi qua nó như thế nào, và vì sao các hệ thống lớn thường không điều khiển OVS trực tiếp mà qua OVN.

Open vSwitch là gì

Open vSwitch là một switch ảo đa lớp (multilayer), mã nguồn mở theo giấy phép Apache 2. Nó hỗ trợ OpenFlow, có cơ sở dữ liệu cấu hình riêng (OVSDB) và được thiết kế cho môi trường production, nơi cấu hình mạng phải được tự động hóa và điều khiển bằng chương trình thay vì bằng tay.

OVS chạy trên host hypervisor và làm hai việc: nối các VM trên cùng một host với nhau, và nối chúng ra mạng vật lý hoặc tới VM ở host khác qua tunnel. Nó được viết cho các hypervisor Linux như KVM và Xen, module kernel của nó nằm trong Linux mainline từ phiên bản 3.3, và nó sớm trở thành switch ảo mặc định trong OpenStack. Ngoài OpenStack, OVS còn được dùng với các SDN controller như OpenDaylight, ở edge và cho service chaining.

Vì sao lớp truy cập mạng chuyển vào host

Trước ảo hóa, mỗi máy chủ cắm cáp vào một cổng switch vật lý. Khi một host chạy hàng chục VM, mỗi VM cần cổng Ethernet riêng, và những cổng đó không thể là cổng vật lý. Lớp truy cập vì vậy chuyển vào phần mềm: mỗi VM hay container có một cổng Ethernet ảo cắm vào switch ảo, switch ảo cắm vào NIC vật lý.

Sơ đồ trong bài gốc tóm tắt vị trí này: các VM nối vào một Open vSwitch, OVS nối ra card mạng, kèm bốn nhóm năng lực là bảo mật, giám sát, QoS và điều khiển tự động.

Switch bằng phần mềm làm được những thứ switch vật lý khó làm ở cùng chi phí: thêm bớt cổng tức thì khi VM được tạo hay xóa, mạng overlay chạy đè lên mạng vật lý, cô lập lưu lượng giữa các tenant, và một điểm điều khiển tập trung cho cả cụm.

Kiến trúc: ba thành phần chính

OVS gồm ba phần, hai ở userspace và một ở kernel:

Thành phần	Vị trí	Vai trò
ovs-vswitchd	userspace	Daemon chính. Đọc cấu hình từ OVSDB, tạo bridge và datapath, giữ các bảng OpenFlow và quyết định gói tin đi đâu. Kết nối tới OpenFlow controller bên ngoài nếu có.
ovsdb-server	userspace	Cơ sở dữ liệu cấu hình có giao dịch: bridge, port, tunnel, QoS, controller. ovs-vswitchd theo dõi DB và tự cập nhật khi DB thay đổi.
Datapath	kernel hoặc userspace	Nơi gói tin thực sự được chuyển tiếp. Datapath kernel là module openvswitch của Linux. Datapath userspace dùng cho DPDK, AF_XDP và các hệ điều hành không phải Linux.

Bộ công cụ quản trị làm việc với từng lớp: ovs-vsctl sửa cấu hình trong OVSDB, ovs-ofctl xem và sửa bảng OpenFlow, ovs-dpctl nhìn vào datapath flow, ovs-appctl gửi lệnh tới daemon đang chạy. Sơ đồ kiến trúc trong bài gốc xếp đúng ba lớp này, với hai mũi tên upcall và reinject nối kernel với userspace.

Lưu ý Từ phiên bản 3.0, mã nguồn module kernel đã bị gỡ khỏi cây mã OVS. OVS userspace làm việc với module openvswitch có sẵn trong Linux mainline. Khi chọn phiên bản OVS, hãy đối chiếu với phiên bản kernel của distro trong bảng tương thích ở FAQ Releases.

Gói tin đi qua OVS như thế nào

Đây là phần quyết định hiệu năng và hay bị hiểu sai. OVS có hai loại flow:

• OpenFlow flow nằm trong ovs-vswitchd. Đây là chính sách: nhiều bảng, có priority, do controller hoặc người vận hành đặt. Đây là thứ duy nhất người dùng và controller điều khiển trực tiếp.
• Datapath flow nằm trong kernel (hoặc datapath userspace). Chỉ một bảng, không có priority, đơn giản hơn nhiều. Chúng là cache của kết quả tra bảng OpenFlow.

Một gói tin đi như sau:

1. Gói tin đến datapath. Datapath tra bảng flow của mình.
2. Không khớp flow nào (cache miss): datapath gửi gói lên ovs-vswitchd qua upcall.
3. ovs-vswitchd chạy gói qua các bảng OpenFlow, ra tập hành động: chuyển ra cổng nào, gắn VLAN, đóng gói tunnel, hay bỏ.
4. ovs-vswitchd cài một datapath flow mô tả kết quả đó xuống kernel, rồi trả gói về datapath (reinject) để chuyển tiếp.
5. Các gói tiếp theo của cùng luồng khớp datapath flow và được chuyển tiếp ngay trong kernel.

Hệ quả: gói đầu tiên của mỗi luồng mới đắt hơn hẳn các gói sau, nên tải có nhiều kết nối ngắn tạo áp lực lên ovs-vswitchd nhiều hơn tải có ít kết nối dài. Số liệu missed và lost của datapath cho biết bao nhiêu gói phải lên userspace, và bao nhiêu gói bị rơi trước khi tới nơi.

Giới hạn Datapath flow không thể cài sẵn trước khi có gói tin: userspace phải thấy gói thật mới biết kernel phân tích gói đó như thế nào. Tài liệu OVS cũng ghi rõ datapath flow là chi tiết cài đặt, có thể thay đổi giữa các phiên bản, nên không xây công cụ vận hành dựa vào chúng.

Những tính năng đáng để ý khi vận hành

Danh sách tính năng của OVS dài. Với một Private Cloud, các nhóm sau là thứ thường dùng tới:

Nhóm	Tính năng	Dùng để
Phân đoạn mạng	VLAN 802.1Q, trunk và access port	Tách mạng tenant và mạng quản trị trên cùng NIC
Overlay	Tunnel Geneve, VXLAN, GRE	Nối VM giữa các host mà không phụ thuộc VLAN vật lý
Uplink	NIC bonding, có hoặc không có LACP	Dự phòng và gộp băng thông ra switch vật lý
Chất lượng dịch vụ	QoS và policing	Giới hạn hoặc ưu tiên băng thông theo cổng
Quan sát	NetFlow, sFlow, port mirroring	Biết lưu lượng nào đang đi qua host khi xử lý sự cố
Điều khiển	OpenFlow 1.0 và các phần mở rộng, OVSDB có binding C và Python	Tự động hóa, tích hợp SDN controller và CMS

Từ OVS đến OVN

OVS ra đời năm 2009 như một lựa chọn mã nguồn mở thay cho switch ảo độc quyền. Nhưng OVS chỉ là switch trên từng host. Nó không có control plane trung tâm và không có API cấp cao: muốn có một mạng ảo trải trên 50 host, ai đó phải cấu hình bridge, tunnel và flow trên cả 50 host, bằng CLI của OVS hoặc bằng một controller tự viết.

Open Virtual Network (OVN) ra đời từ chính đội phát triển OVS để lấp khoảng trống đó. OVN giữ nguyên OVS ở dataplane cùng các tính năng của nó (OpenFlow, DPDK) và thêm một lớp trừu tượng ở trên: logical switch, logical router, ACL (security group), DHCP. Người vận hành hay CMS khai báo mạng logic mình muốn, OVN biến nó thành flow trên từng host. Theo tài liệu ovn-architecture, lớp đó gồm:

• OVN Northbound DB: nhận cấu hình mạng logic từ plugin của CMS, ví dụ OVN ML2 plugin của Neutron, bằng khái niệm logical switch, router, port, ACL.
• ovn-northd: dịch cấu hình logic thành logical flow trong Southbound DB.
• OVN Southbound DB: trung tâm của hệ thống, chứa logical flow, danh sách chassis và địa chỉ overlay của từng host.
• ovn-controller: chạy trên từng hypervisor và gateway. Nó đọc Southbound DB, rồi nối vào ovs-vswitchd với vai trò OpenFlow controller và vào ovsdb-server cục bộ để lập trình OVS trên host đó.

Sơ đồ OVN trong bài gốc đặt các mảnh này cạnh OpenStack: Neutron server nối qua OVN ML2 plugin vào Northbound DB, ovn-northd đứng giữa hai DB, ovn-controller trên từng compute node đẩy OpenFlow xuống OVS cục bộ.

Kết quả là cùng một dataplane OVS, nhưng cấu hình chuyển từ mệnh lệnh trên từng host sang khai báo một lần ở trung tâm. Với CloudMaster, đây là lý do chính để dùng OVN làm backend cho Neutron.

Điều cần kiểm tra trước khi chọn

Nếu bạn đang thiết kế hoặc rà soát mạng của một Private Cloud, bốn câu hỏi sau đáng trả lời sớm:

1. Datapath nào? Datapath kernel đủ cho phần lớn tải doanh nghiệp. Chỉ cân nhắc DPDK khi tải mạng rất lớn và đội vận hành đã quen với nó.
2. OVS thuần hay OVN? Với OpenStack, Neutron có cả driver ML2/OVS và ML2/OVN. OVN gọn hơn về cấu hình, nhưng tài liệu Neutron vẫn liệt kê một số khoảng cách so với ML2/OVS, ví dụ metering hay IPv6 NDP proxy. Đọc danh sách đó trước khi quyết định.
3. Phiên bản OVS và kernel có khớp nhau không? Module kernel đến từ Linux, không từ gói OVS. Kiểm tra bảng tương thích của upstream với distro bạn dùng.
4. Bạn sẽ quan sát bằng gì? Bật sFlow hoặc NetFlow từ đầu, và xem số liệu missed/lost của datapath khi có sự cố để biết vấn đề nằm ở control plane hay dataplane.

Nếu muốn đối chiếu thiết kế mạng hiện tại với cách CloudMaster triển khai Neutron với OVN, bạn có thể đặt lịch trao đổi với kỹ sư. Chúng tôi xem kiến trúc, quy mô và yêu cầu dự phòng rồi nói rõ phần nào phù hợp, phần nào không.