OVN và Neutron: control plane thay cho agent trong OpenStack

Open vSwitch lo việc chuyển mạch ảo bên trong từng hypervisor. Khi cụm OpenStack lên đến hàng chục, hàng trăm node, giữ cho cấu hình OVS trên mọi node nhất quán bằng agent và script trở thành gánh nặng vận hành. OVN (Open Virtual Network) giải quyết việc đó bằng một control plane tập trung, khai báo, đồng bộ qua database. Bài này so sánh ML2/OVS với ML2/OVN, đi qua từng thành phần trong kiến trúc OVN, cách tài nguyên Neutron ánh xạ sang OVN, và đường lần vết khi có sự cố.

So sánh ML2/OVS và ML2/OVN

Với ML2/OVS, mỗi chức năng mạng là một agent riêng (L3, DHCP, metadata), tất cả nói chuyện với neutron-server qua RabbitMQ. Với ML2/OVN, Neutron mô tả mạng mong muốn dưới dạng đối tượng logic và ghi vào database; các daemon của OVN tự dịch mô tả đó thành flow OpenFlow trên từng node.

Chức năng	ML2/OVS	ML2/OVN	Điều thay đổi
Giao tiếp control plane	RPC qua RabbitMQ	Giao thức OVSDB, theo sự kiện	Bỏ phụ thuộc RabbitMQ cho phần mạng, ít thành phần hơn
Routing L3	L3 agent trên network node, compute node nếu bật DVR	Logical router của OVN, floating IP phân tán (tùy chọn)	Routing phân tán là mặc định, không cần agent
Router HA	Tùy chọn, dùng VRRP	Có sẵn, dùng BFD giữa các gateway chassis	Failover nhanh hơn, không cần cấu hình thêm
DHCP	DHCP agent, dnsmasq trong namespace qdhcp	ovn-controller trả lời DHCP bằng OpenFlow	Bỏ DHCP agent và namespace qdhcp
Metadata	Metadata agent qua namespace qrouter hoặc qdhcp	Phục vụ ngay trên compute node, namespace ovnmeta	Bỏ điểm lỗi tập trung trên network node
BGP	neutron-dynamic-routing	ovn-bgp-agent	Tích hợp trực tiếp với control plane OVN

Tóm lại: OVN thay các agent của Neutron bằng một control plane dựa trên database và sự kiện, nhưng vẫn dùng OVS để chuyển tiếp gói tin. Khả năng mở rộng vì vậy không còn bị giới hạn bởi chi phí quản lý agent.

Lưu ý Tài liệu Neutron liệt kê những điểm ML2/OVN chưa làm được so với ML2/OVS: IPv6 NDP proxy, phân mảnh gói East-West qua router, neutron-metering-agent, một số rule QoS theo packet rate. Đối chiếu trang “Gaps from ML2/OVS” với yêu cầu của bạn trước khi chọn.

Kiến trúc OVN từ trên xuống

Kiến trúc có hai lớp. Control plane gồm Neutron, mechanism driver ML2/OVN và hai database của OVN. Data plane gồm các gateway node và compute node, mỗi node chạy OVS và ovn-controller riêng.

Control plane: Neutron, NBDB, ovn-northd, SBDB

Mechanism driver ML2/OVN dịch các đối tượng của OpenStack (network, subnet, router, port, security group) thành thực thể logic của OVN và ghi vào OVN Northbound Database (NBDB). NBDB là trạng thái mạng mong muốn, diễn đạt bằng logical switch, logical router, ACL, NAT.

Daemon ovn-northd đọc NBDB và dịch sang OVN Southbound Database (SBDB): các logical flow, danh sách chassis (node chạy ovn-controller), và bảng binding cho biết port logic nào đang ở chassis nào.

Data plane: ovn-controller và OVS trên từng node

Trên mỗi compute node và gateway node chạy ovn-controller. Nó kết nối tới SBDB, đăng ký node làm một chassis, rồi đóng vai trò OpenFlow controller cho ovs-vswitchd tại chỗ: tạo integration bridge (thường là br-int), các tunnel port tới chassis khác, và toàn bộ flow OpenFlow để hiện thực hóa topology logic. OpenFlow là giao thức OVS dùng để quyết định match gói nào, rồi forward, drop hay sửa gói. Với ML2/OVN, bạn không viết flow nào bằng tay.

Mỗi node cũng có một ovsdb-server cục bộ giữ cấu hình OVS của chính nó. Vì flow đã được cài vào OVS tại chỗ, datapath tiếp tục chuyển tiếp lưu lượng đang có khi NBDB hoặc SBDB trung tâm tạm thời không truy cập được. Thay đổi mới (tạo VM, sửa security group) phải chờ control plane trở lại.

Overlay và provider network

Lưu lượng tenant giữa các node đi qua tunnel nối các br-int. Encapsulation OVN ưu tiên giữa các hypervisor là Geneve, vì header Geneve mang được logical input port, điều VXLAN không làm được. VXLAN dùng được với OVN từ bản 20.09, nhưng có giới hạn: tối đa 4095 logical network, 2048 port mỗi network, và không hỗ trợ ACL match theo logical ingress port.

Provider network và external network đi qua một bridge riêng (thường là br-ex), nối với br-int bằng patch port. Ánh xạ giữa tên physical network và bridge khai báo trong ovn-bridge-mappings của từng chassis.

Gateway node và hai chiều lưu lượng

Lưu lượng East-West (VM tới VM, kể cả qua router giữa hai subnet) đi thẳng giữa các compute node. Logical router của OVN là phân tán, không có node nào đứng giữa.

Lưu lượng North-South cần gateway. Mỗi logical router có một distributed gateway port gắn với một hay nhiều gateway chassis. SNAT (VM không có floating IP đi ra ngoài) luôn qua gateway chassis đang active. Khi có nhiều gateway chassis, chỉ một chassis active tại một thời điểm; OVN dùng BFD để theo dõi và chuyển sang chassis kế tiếp khi chassis ưu tiên cao hơn mất liên lạc.

Floating IP có hai chế độ, chọn bằng một tham số duy nhất cho cả cụm, enable_distributed_floating_ip:

• Tập trung: cả SNAT lẫn floating IP đi qua gateway node. Compute node không cần kết nối ra external network.
• Phân tán (DVR): lưu lượng floating IP đi thẳng từ compute node qua provider bridge. Mỗi compute node cần cổng vật lý ra external network.

Một node trở thành gateway chassis khi được đánh dấu trên OVS của nó:

ovs-vsctl set open . external-ids:ovn-cms-options="enable-chassis-as-gw"

Ở cụm nhỏ hoặc hyperconverged, gateway và compute có thể là cùng một node. Cách khác hay gặp: các node control plane của OpenStack kiêm vai trò gateway.

Tài nguyên Neutron ánh xạ sang OVN

Đối tượng Neutron	Thực thể OVN	Ghi chú
Network	Logical switch	Một logical datapath
Port	Logical switch port	SBDB ghi port đang ở chassis nào
Subnet có DHCP	DHCP_Options gắn vào port	ovn-controller trả lời tại chỗ, không có dnsmasq
Router	Logical router	Phân tán theo thiết kế
Floating IP	Rule NAT dnat_and_snat	Ở gateway hoặc compute tùy chế độ
Security group	Port group pg-<id> cộng ACL	Port không có security group vào neutron_pg_drop

Metadata là ngoại lệ, vì OVN không có sẵn. Trên mỗi compute node, Neutron tạo namespace ovnmeta-<network-id> cho từng network có VM, trong đó HAProxy chuyển request tới dịch vụ metadata qua Unix socket. Thành phần này là neutron-ovn-metadata-agent; các bản Neutron mới gộp nó thành extension metadata của OVN agent. Đây là agent duy nhất còn lại trên compute node.

Giới hạn Vì DHCP do OVN trả lời bằng flow, security group phải cho phép lưu lượng DHCP một cách tường minh; ML2/OVS trước đây tự thêm rule này. Tài liệu Neutron ghi đây là một trong các khác biệt so với ML2/OVS.

Lần vết sự cố theo đúng một đường

Khi mạng không như mong đợi, đi theo đúng đường mà cấu hình đã đi. Một lệnh gọi Neutron API phải để lại dấu vết ở từng tầng:

# 1. Neutron có nhận và lưu đúng đối tượng không
openstack port show <port-id>

# 2. NBDB: logical switch, port, router, NAT, ACL đã có chưa
ovn-nbctl show
ovn-nbctl lr-nat-list <router>

# 3. SBDB: port đã bind vào chassis nào, gateway chassis nào active
ovn-sbctl show
ovn-sbctl list Port_Binding <port-id>

# 4. OVS: flow đã được cài trên br-int của node đó chưa
ovs-ofctl -O OpenFlow15 dump-flows br-int | grep <mac-or-ip>

Tầng nào thiếu dấu vết, lỗi nằm ở tầng ngay trước đó: không có trong NBDB thì xem log neutron-server; có trong NBDB mà không có trong SBDB thì xem ovn-northd; có trong SBDB mà không có flow thì xem ovn-controller trên chassis tương ứng. Với một luồng cụ thể, ovn-trace cho biết gói tin giả định đi qua pipeline logic thế nào; Neutron có ml2ovn-trace để gọi nó bằng tên đối tượng Neutron.

Điểm cần kiểm tra trước khi vận hành

OVN giảm số thành phần phải vận hành, nhưng đòi hỏi hạ tầng bên dưới nhất quán. Những chỗ hay gây sự cố:

1. Chassis trùng: cài lại node mà không xóa chassis cũ khỏi SBDB, port binding kẹt ở chassis không còn tồn tại.
2. MTU: overlay Geneve thêm header, MTU trên underlay và trên VM phải khớp, lệch là gói lớn bị phân mảnh hoặc rơi im lặng.
3. Floating IP và NAT: chế độ tập trung hay phân tán quyết định node nào cần cổng ra external network. Chọn sai là floating IP tới được từ một số node, không từ node khác.
4. Bridge mapping: ovn-bridge-mappings lệch giữa các chassis, hoặc tên physical network không khớp với Neutron, provider network chỉ chạy trên một phần cụm.
5. HA của control plane: neutron-server sau load balancer, OVSDB chạy cluster hoặc active/passive sau VIP, ovn-northd có failover. Thiếu một trong ba là mất control plane khi node database hỏng.

Nếu đang cân nhắc chuyển từ ML2/OVS sang ML2/OVN, hoặc thiết kế cụm mới, hãy bắt đầu từ ba câu hỏi: floating IP tập trung hay phân tán, node nào làm gateway chassis, và bạn đang dùng tính năng nào trong danh sách gaps. Trả lời được ba câu đó, phần còn lại của kiến trúc gần như tự xếp vào chỗ.