Trong bài viết trước của chúng tôi về Open vSwitch (OVS), chúng ta đã khám phá cách OVS trở thành nền tảng của các trung tâm dữ liệu hiện đại và mạng được định nghĩa bằng phần mềm (SDN). Như chúng ta đã thảo luận, OVS cung cấp nền tảng cho việc chuyển mạch ảo bên trong các hypervisor, kết nối các máy ảo (VM) và container thông qua các đường dẫn dữ liệu (datapath) hiệu suất cao, có thể lập trình được.

Tuy nhiên, khi ảo hóa và các môi trường đám mây như OpenStack phát triển, việc quản lý OVS ở quy mô lớn trở nên ngày càng phức tạp. Mỗi node hypervisor yêu cầu cấu hình thông qua các agent hoặc tập lệnh (script), và việc duy trì sự nhất quán trên các môi trường phân tán đặt ra nhiều thách thức vận hành.

Đó là khi Open Virtual Network (OVN) xuất hiện.

OVN mở rộng OVS bằng cách giới thiệu một control plane tập trung, mang tính khai báo để quản lý các mạng ảo, bộ định tuyến và chính sách bảo mật ở quy mô lớn. Thay vì cấu hình thủ công các luồng (flow) hoặc dựa vào các agent trên từng node, OVN abstract các yếu tố này thành các cấu trúc logic — switch, router, port và NAT — tất cả được đồng bộ hóa tự động thông qua cơ sở dữ liệu và các trình nền (daemon).

Trong bài viết này, chúng ta sẽ đi sâu vào cách OVN hoạt động, cách các tài nguyên Neutron ánh xạ tới các thành phần OVN.

So sánh nhanh: Neutron ML2/OVS vs. ML2/OVN

OpenStack Neutron từng dựa vào ML2/OVS (Open vSwitch) cho mạng ảo trong các bản phát hành cũ hơn của OpenStack. ML2/OVN (Open Virtual Network) là một giải pháp thay thế mới hơn, hiệu quả hơn và có khả năng mở rộng tốt hơn, thay thế nhiều agent cũ và hàng đợi tin nhắn bằng một Control Plane phân tán tích hợp sẵn.

Trong bảng dưới đây, chúng tôi nêu bật những khác biệt chính giữa ML2/OVS và ML2/OVN và những lợi ích chính của việc sử dụng OVN.

ML2/OVS	ML2/OVN	Lợi ích của OVN
Giao tiếp qua Rabbit MQ	Giao tiếp qua Giao thức OVSDB + Event	Loại bỏ sự phụ thuộc vào RabbitMQ, giảm độ phức tạp và cải thiện khả năng mở rộng.
L3 agent chạy trên network node và compute node (tùy chọn DVR)	Router logic OVN + Floating IP phân tán (tùy chọn)	Định tuyến phân tán gốc (native) cho hiệu suất cao hơn và giảm chi phí vận hành.
Router HA là tùy chọn (VRRP)	Router HA native (BFD)	Tích hợp sẵn dự phòng với khả năng chuyển đổi dự phòng nhanh hơn và cấu hình đơn giản hơn.
DHCP agent	OpenFlow + DHCP gốc	Loại bỏ các DHCP agent độc lập, đơn giản hóa quản lý và cải thiện độ tin cậy.
Metadata agent	Agent chạy trên các node tính toán	Dịch vụ metadata phân tán giảm các điểm lỗi đơn lẻ và tăng khả năng phục hồi.
Định tuyến động BGP	OVN BGP agent	Tích hợp liền mạch với Control Plane OVN để thiết lập dễ dàng hơn và hiệu suất tốt hơn.
OVN VTEP gateway	OVN VTEP gateway	Tích hợp trực tiếp với các cổng mạng vật lý (VTEP) để kết nối lai (hybrid) mượt mà hơn.

Về cơ bản, OVN thay thế các agent của Neutron bằng một Control Plane dựa trên cơ sở dữ liệu và sự kiện, trong khi vẫn sử dụng OVS để chuyển tiếp dữ liệu. Điều này làm cho nó mạnh mẽ, nhất quán và có khả năng mở rộng hơn cho các triển khai lớn. Khả năng mở rộng của OVS thường bị hạn chế bởi chi phí quản lý của agent, trong khi OVN có khả năng mở rộng cao và không cần agent ngay từ đầu.

Tổng quan Kiến trúc OVN

Sơ đồ dưới đây minh họa cách OVN tích hợp với OpenStack Neutron để cung cấp một kiến trúc mạng phân tán và có khả năng mở rộng hoàn toàn.

Ở phía trên cùng của sơ đồ, bạn có thể thấy Control Plane, bao gồm Neutron, Mechanism Driver ML2/OVN và hai thành phần chính là Northbound - NBDB và Southbound - SBDB của OVN.

Data plane được hiển thị bên dưới, chia thành ba loại node: Node Controller, Node Gateway và Node Compute.

OpenStack Neutron tương tác với Northbound (control) plane thông qua Mechanism Driver ML2/OVN. Lớp này xử lý việc dịch các đối tượng SDN cấp cao của OpenStack (mạng, bộ định tuyến, cổng, mạng con, v.v.) thành các thực thể logic OVN tương ứng. Cấu hình được lưu trữ trong OVN Northbound Database (NBDB), đại diện cho trạng thái mạng logic mong muốn.

Southbound (data) plane dịch ý định logic này thành các quy tắc chuyển tiếp thực tế. Thông qua daemon ovn-northd, các cấu hình từ NBDB được chuyển đổi thành các hướng dẫn luồng cấp thấp hơn trong OVN Southbound Database (SBDB), sau đó được tiêu thụ bởi các tiến trình ovn-controller chạy trên mỗi node. Các bộ điều khiển này lập trình các phiên bản Open vSwitch (OVS) cục bộ — thiết lập các đường hầm (tunnel), cầu nối (bridge) và quy tắc OpenFlow để hiện thực hóa cấu trúc liên kết mạng trong thời gian thực.

Bản thân OpenFlow là giao thức mà OVS sử dụng để xác định cách xử lý các gói tin — nó cài đặt các match-action trong switch, ra lệnh lưu lượng nào chuyển tiếp đi đâu, loại bỏ hoặc sửa đổi. OVN tự động tạo và quản lý các quy tắc OpenFlow cấp thấp này theo cấu hình và các thực thể được tạo trong Neutron.

Mỗi node compute và gateway chạy máy chủ OVSDB và ovn-controller riêng, đảm bảo rằng mạng cục bộ (datapath) vẫn tiếp tục hoạt động ngay cả khi Control Plane trung tâm tạm thời không khả dụng. Bên dưới, OVS vẫn sử dụng OpenFlow để quản lý lưu lượng, nhưng tất cả cấu hình giờ đây được điều khiển tự động bởi cơ sở dữ liệu OVN thay vì các agent Neutron riêng lẻ.

Tùy thuộc vào chế độ triển khai, các node gateway có thể hoạt động ở hai chế độ:

1. North–South mode: xử lý định tuyến ra bên ngoài, NAT và Floating IP, kết nối mạng tenant với thế giới bên ngoài.
2. East–West mode: tập trung vào lưu lượng nội bộ phân tán giữa các VM trên các node compute.

Trong các thiết lập nhỏ hơn hoặc siêu hội tụ (hyperconverged), cả hai chế độ có thể chạy trên cùng một node, kết hợp chức năng gateway và compute. Hoặc, trong trường hợp các node Control Plane OpenStack chạy API OpenStack cũng có thể đóng vai trò là node gateway.

Cuối cùng, Overlayed network (thường là VXLAN) kết nối các cầu nối OVS (br-int, br-tun, br-ex) trên các node cụm, cung cấp sự cô lập cho lưu lượng tenant. OVN metadata agent thay thế các agent L3, metadata và DHCP truyền thống của Neutron, đơn giản hóa hoạt động trong khi vẫn duy trì khả năng tương thích với REST API của OpenStack.

Khi khắc phục sự cố OVN, điều quan trọng là phải hiểu những gì xảy ra bên dưới sau khi một lệnh gọi API Neutron được thực hiện — từ các bản cập nhật trong NBDB, đến việc dịch chúng trong SBDB, tới các quy tắc OpenFlow thực tế được áp dụng trong OVS. Khả năng hiển thị này là chìa khóa để chẩn đoán các vấn đề đồng bộ hóa hoặc lập trình luồng.

Kết luận

Hiểu rõ luồng lưu lượng của OVN và nắm vững các công cụ khắc phục sự cố của nó là điều cần thiết để vận hành một môi trường OpenStack ổn định và dễ dự đoán. Như chúng ta đã thấy, từ các vấn đề chassis duplication và phân mảnh MTU đến hành vi Floating IP, luồng NAT và sự không khớp ánh xạ thiết bị, OVN cung cấp các khả năng mạnh mẽ, nhưng nó cũng đòi hỏi sự điều chỉnh cẩn thận về cấu hình và cơ sở hạ tầng.

Nhiều thách thức trong số này sẽ dễ quản lý hơn đáng kể khi OVN được sử dụng trong một kiến ​​trúc sạch sẽ, nhất quán và được hỗ trợ đầy đủ.