Skip to main content

OVS Phần 1: Bức Tranh Tổng Quan

Phần 1/21 trong loạt Open vSwitch (OVS) — bài mở đầu bắt buộc đọc trước mọi module. Không có cấu hình sâu trong phần này, chỉ có bức tranh tổng quan: OVS là gì, đứng ở đâu, và các mảnh ghép liên hệ nhau ra sao. Đọc xong, Module 1 sẽ đưa bạn vào cài đặt và lab OVS đầu tiên.

Mục tiêu bài học: sau bài này bạn sẽ hiểu OVS giải quyết bài toán gì mà switch vật lý đang vận hành (Juniper/Huawei/Nokia) không giải quyết được, phân biệt được OVS với Linux bridge truyền thống, và nắm được sơ đồ tổng của các mảnh ghép — ovs-vswitchd, ovsdb-server, OpenFlow, OVN — trước khi bài sau đào sâu từng mảnh.

Người đọc giả định: bạn đã vững networking vật lý (VLAN, routing, BGP/OSPF, có thể đã vận hành VXLAN-EVPN trên fabric spine-leaf) nhưng chưa quen phần ảo hóa/SDN. Bài này cố tình liên hệ ngược về những gì đã biết ở mỗi bước, thay vì coi bạn là người mới hoàn toàn với networking.

Ba câu hỏi mà bài này trả lời:

  1. OVS giải quyết bài toán gì mà Linux bridge và switch vật lý bạn đang vận hành không giải quyết được?
  2. Bốn mảnh ghép ovs-vswitchd, ovsdb-server, OpenFlow, OVN quan hệ với nhau ra sao?
  3. Loạt bài này đi theo lộ trình nào, và vì sao đúng thứ tự đó?

Mục lục​

1. Vì sao OVS ra đời?​

Hình dung bạn đang vận hành một fabric spine-leaf vật lý: leaf switch có access port, trunk port, VLAN, và mọi thay đổi (thêm VLAN, sửa port) đi qua CLI hoặc automation (Ansible, NETCONF) tới đúng một thiết bị vật lý, một lần. Cấu hình đó tồn tại ổn định — leaf switch không "biến mất" hay "di chuyển sang rack khác" trong lúc bạn không để ý.

Giờ chuyển bối cảnh sang bên trong một hypervisor — phần mềm chạy ngay trên server vật lý, có nhiệm vụ tạo và quản lý nhiều máy ảo (VM) cùng lúc trên đúng một phần cứng, mỗi VM tưởng như đang sở hữu riêng cả CPU/RAM/NIC của mình dù thực chất đang chia sẻ tài nguyên với các VM khác (ví dụ cụ thể: KVM, Xen, ESXi). Mỗi server vật lý chạy hàng chục VM, mỗi VM có một virtual NIC (vNIC) cần được "cắm" vào đâu đó để ra được mạng — và bên trong hypervisor đó cũng cần một con switch, chỉ khác là con switch này chạy hoàn toàn bằng phần mềm. Vấn đề nảy sinh không phải vì thiếu một switch phần mềm (Linux đã có bridge từ rất lâu), mà vì môi trường ảo hóa multi-server có ba đặc điểm mà một switch truyền thống — kể cả switch vật lý bạn đang dùng — không được thiết kế để xử lý:

  1. Endpoint di động, thay đổi liên tục: VM được tạo, xóa, và quan trọng nhất — di chuyển (live migration/vMotion) từ server vật lý này sang server vật lý khác trong khi vẫn đang chạy. Trạng thái mạng của VM đó (ACL, QoS, port mirroring đang áp cho nó) phải "đi theo" VM, không được ở lại trên switch cũ.
  2. Cấu hình phải lập trình được, không chỉ CLI từng máy một: Với hàng trăm, hàng nghìn hypervisor, không ai SSH vào từng máy để gõ lệnh. Cần một cách để phần mềm bên ngoài (orchestrator như OpenStack, Kubernetes CNI) tự động tạo/xóa/sửa cấu hình switch qua một giao diện chuẩn hóa, theo thời gian thực.
  3. Cần duy trì logical abstraction xuyên nhiều host: nhiều tenant, nhiều mạng ảo (virtual network) cùng tồn tại trên chung một hạ tầng vật lý, và ranh giới giữa chúng phải nhất quán trên mọi server — không phải cấu hình rời rạc, độc lập từng máy.

Đây chính xác là điều tài liệu chính thức của dự án nêu ra: Open vSwitch "nhắm tới các triển khai ảo hóa đa server (multi-server virtualization deployments) — một bối cảnh mà stack cũ (Linux bridge truyền thống) không phù hợp", đặc trưng bởi "endpoint có tốc độ thay đổi cao, nhu cầu duy trì logical abstraction, và (đôi khi) tích hợp/offload xuống phần cứng switching chuyên dụng". Nguyên văn dự án còn nhấn mạnh: "mọi trạng thái mạng gắn với một network entity (ví dụ một VM) cần dễ dàng nhận diện và di chuyển được (migratable) giữa các host khác nhau". Không phải để chạy theo trào lưu "SDN cho vui".

💡 Hình dung như thế này: switch vật lý bạn đang vận hành giống một cái bàn làm việc cố định trong văn phòng — gán cho ai thì người đó ngồi ở đúng bàn đó, đổi chỗ là việc hiếm và có kế hoạch trước. OVS giống một chiếc ghế văn phòng có bánh xe gắn theo từng nhân viên: nhân viên (VM) di chuyển sang bàn khác (server vật lý khác) bất cứ lúc nào, và mọi thứ thuộc về họ — tài liệu, cấu hình, quyền truy cập (ACL, QoS, mirroring) — phải "lăn theo" ngay lập tức, không bị bỏ lại ở bàn cũ.

Open vSwitch ra đời (khởi xướng bởi đội ngũ Nicira, khoảng 2009) để trở thành con switch phần mềm giải quyết đúng ba đặc điểm trên: quản lý được từ xa qua giao diện chuẩn hóa, mở forwarding logic ra để lập trình được (thay vì cố định như một switch L2 học-MAC truyền thống), và giữ trạng thái mạng gắn liền với từng VM khi nó di chuyển. Module kernel của OVS được đưa thẳng vào Linux mainline từ kernel 3.3 (phát hành tháng 3/2012); năm 2016, dự án chính thức trở thành một Linux Foundation Collaborative Project, vận hành dưới một Technical Steering Committee (TSC) đa vendor thay vì thuộc riêng một công ty.

2. OVS đứng ở đâu: so với Linux bridge và switch vật lý?​

So với Linux bridge​

Linux đã có sẵn một bridge (brctl, hay giao diện mới hơn qua ip link) từ rất lâu trước OVS — về bản chất nó là một switch layer 2 học-MAC theo chuẩn 802.1D, chạy hoàn toàn trong kernel. Với một mạng đơn giản (vài VM trên một host, không cần tự động hóa xuyên nhiều host), Linux bridge vẫn là lựa chọn hợp lý và nhẹ hơn OVS.

Vấn đề là Linux bridge được thiết kế cho một switch độc lập, tĩnh, cấu hình tại chỗ — đúng mô hình mà Mục 1 vừa nói là không còn phù hợp với môi trường ảo hóa đa server. Nó không có khái niệm điều khiển từ xa theo giao thức chuẩn, không có data model kiểu database để orchestrator query/subscribe thay đổi, và không expose forwarding logic ra ngoài để lập trình theo flow — cấu hình xong là cố định, muốn đổi hành vi forward phải đổi cách khác (VLAN, iptables...) chứ không có một pipeline match/action thống nhất.

OVS thêm gì vào bức tranh đó?​

OVS giữ nguyên khả năng làm một switch layer 2/3 bình thường, nhưng thêm ba thứ mà Linux bridge không có, đúng theo tinh thần "trạng thái mạng phải typed, có data model, và di chuyển được" mà Mục 1 đã trích:

  • OVSDB — một database thật (không phải file cấu hình rời rạc) mô tả toàn bộ trạng thái switch: bridge nào, port nào, gán VLAN gì, tunnel nào. Orchestrator bên ngoài connect vào, đọc/ghi, và subscribe thay đổi theo thời gian thực.
  • OpenFlow — thay vì hành vi forward cố định kiểu "học MAC rồi forward", OVS expose một pipeline match/action lập trình được: một controller bên ngoài có thể cài đặt "packet khớp điều kiện X thì làm hành động Y". Đây chính là nền tảng của SDN (Software-Defined Networking) — mô hình tách logic điều khiển (control plane, "quyết định forward thế nào") ra khỏi từng thiết bị riêng lẻ, đưa nó vào một phần mềm trung tâm lập trình được. Nhờ nền tảng đó, một SDN controller (như OVN — Open Virtual Network, sẽ giới thiệu ở Mục 3) có thể áp logic phức tạp (security group, logical routing) mà không cần đổi phần mềm switch.
  • Tunneling tích hợp sẵn — VXLAN, GRE, Geneve được hỗ trợ như một loại port ngay trong OVS, không cần công cụ ngoài. Đây là điểm sẽ nối trực tiếp với kiến thức EVPN/VXLAN bạn đã có trên fabric vật lý — Module 2 của loạt bài này (bài 9) sẽ đối chiếu trực tiếp VXLAN trên OVS với VXLAN trên leaf switch.
Physical Switch vs Linux Bridge vs Open vSwitchPhysical Switch (leaf)Linux BridgeOpen vSwitchCLI/NETCONF oneach physical devicebrctl / ip link,no centralized DBOVSDB — data model,orchestrator query/subscribeFixed forwarding(MAC learning + VLAN + vendor ACL)Fixed forwarding(802.1D, not programmable)OpenFlow — pipelineprogrammable match/actionNo "VM migration"port stays fixed in placePort state boundto 1 host, does not moveState (ACL/QoS/mirror)migrates with VM across hostsOVS does not replace the leaf switch — it lives inside the hypervisor,as the "layer 0" switch before VM traffic reaches the physical NIC,then continues up to the real leaf switch via the uplink.The same VXLAN concept you use on the leaf (EVPN) also worksdirectly on OVS — covered in detail in Module 2, Lesson 9.

So với switch vật lý bạn đang vận hành​

Nói ngắn gọn theo đúng ngôn ngữ bạn đã quen: OVS là con switch "ảo" sống bên trong hypervisor, đứng trước leaf switch vật lý trong đường đi của traffic, không phải một sản phẩm thay thế leaf switch. Một VM gửi packet ra ngoài: packet đi qua vNIC → OVS bridge (switching, có thể cả VXLAN encap nếu overlay được terminate ngay tại OVS) → uplink vật lý của server → cổng access/trunk trên leaf switch thật. Từ góc nhìn leaf switch, cả một server chạy hàng chục VM có thể chỉ xuất hiện như một endpoint duy nhất trên một VXLAN tunnel — hoặc nếu OVS được cấu hình bridge thẳng VLAN ra ngoài, leaf switch vẫn thấy MAC của từng VM như bình thường. Cách hai lớp này phối hợp cụ thể (ai làm VTEP, ai giữ EVPN adjacency) là chủ đề của Module 2 — bài toán kiến trúc thật sự thú vị nằm ở việc overlay có thể được terminate ở OVS (host-based VXLAN) hoặc ở leaf switch (network-based VXLAN), và lựa chọn này ảnh hưởng trực tiếp tới thiết kế fabric bạn đang vận hành.

3. Sơ đồ kiến trúc tổng: vswitchd, ovsdb-server, OpenFlow, OVN​

Tài liệu kiến trúc chính thức của dự án liệt kê rõ các thành phần chính trong một bản phân phối OVS:

  • ovs-vswitchd — daemon chính, thực sự "là" switch: nhận packet, quyết định forward đi đâu, phối hợp với kernel module để đạt hiệu năng cao, hoặc chạy hoàn toàn trong userspace khi không có kernel module hỗ trợ (tài liệu OVS lưu ý chế độ userspace thuần với NIC thường — không phải DPDK — vẫn được xem là thử nghiệm (experimental) và có chi phí hiệu năng).
  • ovsdb-server — một database server nhẹ, giữ toàn bộ cấu hình (bridge, port, VLAN, QoS, controller, manager...) dưới dạng transactional database, giao tiếp qua OVSDB management protocol (chuẩn hóa tại RFC 7047, giao thức JSON-RPC).
  • ovs-dpctl — công cụ cấu hình trực tiếp kernel module (ít dùng hàng ngày, chủ yếu để debug datapath).
  • ovs-vsctl — công cụ dùng hàng ngày để query/sửa cấu hình, nói chuyện với ovsdb-server (Module 1, bài 5, sẽ thực hành công cụ này).
  • ovs-ofctl — công cụ quản trị OpenFlow switch: xem flow table hiện tại (dump-flows), tự tay cài flow test (add-flow) — đây là cửa sổ để nhìn thẳng vào forwarding pipeline, khác hẳn ovs-vsctl (Module 1, bài 6, sẽ thực hành công cụ này).

Điểm quan trọng nhất cần khắc vào đầu ngay từ bài này: OVSDB và OpenFlow là hai giao thức tách biệt, phục vụ hai mục đích khác nhau, dù cùng nói chuyện với ovs-vswitchd.

  • OVSDB trả lời câu hỏi "bridge/port/tunnel nào tồn tại, cấu hình ra sao" — đây là slow/config state: tạo bridge, gán VLAN cho port, khai báo một tunnel VXLAN. RFC 7047 nói rõ: OVSDB hỗ trợ tạo/sửa/xóa datapath (bridge), cấu hình controller/manager, tạo port và tunnel interface, tạo queue và QoS policy — nhưng không thao tác theo từng flow, việc đó nhường hẳn cho OpenFlow.
  • OpenFlow trả lời câu hỏi "packet khớp điều kiện gì thì làm hành động gì" — đây là fast/flow state: match trên các trường header (MAC, IP, port, VLAN tag...), rồi action (forward ra port nào, sửa trường nào, drop). OVS hỗ trợ OpenFlow 1.0 cộng nhiều phần mở rộng riêng.

💡 Hình dung như thế này: OVSDB giống bản vẽ sơ đồ mặt bằng của một tòa nhà — phòng nào tồn tại, cửa nào thông ra đâu, ai được cấp thẻ vào khu nào; bản vẽ này ít khi đổi và đổi cũng chậm. OpenFlow giống người bảo vệ đứng gác ngay tại từng cửa, ra quyết định tức thời cho từng người đi qua ("người này qua được, người kia chặn lại, người kia rẽ sang cửa khác") — quyết định đó có thể đổi liên tục trong ngày mà không cần vẽ lại bản mặt bằng.

Nhầm hai thứ này là nguồn gốc phần lớn bối rối khi mới học OVS.

Một controller bên ngoài (SDN controller) thường dùng cả hai cùng lúc: OVSDB để dựng "khung xương" (bridge, port) và OpenFlow để "bơm logic" vào khung xương đó — chính là cách OVN (Open Virtual Network, Module 4) vận hành: ovn-controller chạy trên mỗi hypervisor, một mặt connect tới ovsdb-server cục bộ để theo dõi/điều khiển cấu hình OVS, mặt khác connect tới ovs-vswitchd với vai trò một OpenFlow controller để lập trình pipeline, dịch logical network (logical switch, logical router mà admin khai báo trong OVN Northbound DB) thành flow OpenFlow thật chạy trên từng host.

OVS Architecture — a Single HostOVN (Module 4) — logical networkovn-controller runs on every hostOVSDBOpenFlowovsdb-serverconfig state — RFC 7047 (JSON-RPC)ovs-vswitchdflow state — OpenFlow 1.0 + extensionsovs-vsctl reads/writes through here2 separate daemons, config kept in syncDatapath — kernel module(or userspace/DPDK — Module 3, Lesson 14)ovs-ofctl dump-flows /add-flow inspect hereVM1 vNIC(tap/vhost-user)VM2 vNICuplink NIC→ real leaf switchovsdb-server = "what config exists" (bridge, port, VLAN, tunnel) — slow, rarely changesovs-vswitchd + datapath = "where packets go" (OpenFlow match/action) — fast, changes constantlyOVN sits on top, using both channels to turn "logical network" into real flows→ Module 1 practices ovs-vsctl (OVSDB) and ovs-ofctl (OpenFlow) separately

Tách bạch được hai lớp này ngay từ đầu là điều quan trọng nhất bài này muốn để lại: khi bạn thấy ovs-vsctl add-br br0 — đó là OVSDB, đang tạo "khung xương". Khi bạn thấy ovs-ofctl dump-flows br0 — đó là OpenFlow, đang cho xem "logic đang chạy" bên trong khung xương đó. Hai công cụ, hai giao thức, cùng phục vụ một ovs-vswitchd.

4. Nhìn thử OVS lần đầu​

Chưa cần cài đặt hay dựng topology gì — Module 1 (bài 4) sẽ làm việc đó kỹ. Ở đây chỉ cần xác nhận hai điều: các binary trên có tồn tại trên máy không, và một switch OVS "trống" (chưa có bridge nào) trông ra sao.

# Kiểm tra các binary chính đã cài chưa (nếu chưa, Module 1 bài 4 sẽ hướng dẫn cài)
ovs-vsctl --version
ovs-vswitchd --version
ovs-ofctl --version
# Output minh họa — số phiên bản cụ thể tùy bản OVS đang cài, cấu trúc dòng đúng theo thực tế
ovs-vsctl (Open vSwitch) 3.7.1
ovs-vswitchd (Open vSwitch) 3.7.1
ovs-ofctl (Open vSwitch) 3.7.1
# ovs-vsctl show: liệt kê toàn bộ cấu hình hiện có trong OVSDB (bridge, port, controller...)
# Trên một máy vừa cài xong, chưa tạo bridge nào — lệnh này trả về rỗng, không có gì để in ra.
sudo ovs-vsctl show

Không có output nào cả (khác với switch vật lý, nơi luôn có ít nhất VLAN 1 mặc định) là đúng — OVSDB lúc này chưa có bridge nào được khai báo. Module 1, bài 5 sẽ tạo bridge đầu tiên bằng ovs-vsctl add-br, và khi đó lệnh show mới bắt đầu có nội dung để nhìn.

5. Lộ trình học phía trước​

ModuleNội dungTrọng tâm
Module 1 — Nền tảng (Bài 2–6)OVS là gì so với Linux bridge, kiến trúc chi tiết vswitchd/ovsdb-server/kernel vs userspace datapath, cài đặt & lab đầu tiên, ovs-vsctl, ovs-ofctl cơ bảnLàm quen công cụ, chạy được lab đầu tiên
Module 2 — Trung cấp (Bài 7–11)OVS + KVM/libvirt, VLAN trunking/isolation, tunnel VXLAN/GRE/Geneve (đối chiếu trực tiếp với EVPN vật lý), bonding/LACP, QoSĐưa OVS vào một topology thật, nối được với kiến thức fabric bạn đã có
Module 3 — Nâng cao (Bài 12–16)OpenFlow pipeline sâu (flow table, priority, match/action), connection tracking (conntrack), DPDK, hardware offload (TC flower/SmartNIC), giám sát (sFlow/IPFIX/mirroring)Hiểu forwarding pipeline ở mức thực chiến, tối ưu hiệu năng
Module 4 — Chuyên gia/SDN (Bài 17–21)OVN (logical switching/routing), OVS trong OpenStack Neutron, OVS trong Kubernetes (OVN-Kubernetes/Antrea), troubleshooting nâng cao, tổng kết OVS vs fabric VXLAN-EVPN vật lýTích hợp SDN thật, ra quyết định kiến trúc hybrid
Phụ lục (mở khi cần)Case study, so sánh sản phẩm, câu hỏi hay gặpBổ sung ngoài lộ trình chính, không nhồi vào bài đã có
OVS Learning Roadmap21 lessons across 4 modules — sequential order recommendedPart 1You are hereModule 1FoundationsLessons 2-6Module 2IntermediateLessons 7-11Module 3AdvancedLessons 12-16Module 4Expert / SDNLessons 17-21Appendixopened when a topic warrants itEach module builds on tools/concepts learned in the previous one

Thứ tự này không ngẫu nhiên: mỗi module xây trên khái niệm của module trước — OpenFlow pipeline (Module 3) chỉ thực sự "vào đầu" nếu bạn đã quen ovs-ofctl từ Module 1; OVN (Module 4) chỉ dễ hiểu nếu bạn đã tự tay tạo flow OpenFlow thủ công ít nhất một lần trước đó, để thấy rõ OVN đang "tự động hóa" đúng việc từng làm tay.

Nếu bạn chỉ đọc kỹ được một mục trong bài này, hãy chọn Mục 3 — toàn bộ phần còn lại của loạt bài chỉ là biến tấu trên đúng bốn mảnh ghép đó.

Bài tập cuối bài​

  1. Trên một máy Linux bất kỳ bạn có quyền truy cập (không cần production), chạy ip link show type bridge (hoặc brctl show nếu có cài) để xem hệ thống hiện có Linux bridge nào không, và ghi lại output — dùng để đối chiếu khi Module 1 tạo bridge OVS đầu tiên, so sánh cách hai loại bridge này xuất hiện trong hệ thống.

    # Output minh họa — máy chưa từng tạo bridge nào
    (không có dòng nào được in ra)

    # Output minh họa — máy có cài Docker (Docker daemon tự tạo bridge docker0 khi khởi động)
    3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
        link/ether 02:42:1a:2b:3c:4d brd ff:ff:ff:ff:ff:ff

    (Output minh họa — cấu trúc đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ, dùng để tự đối chiếu. Nếu máy có cài Docker, gần như chắc chắn sẽ thấy docker0 — đó cũng là một Linux bridge thật, không phải khái niệm riêng của Docker.)

  2. Từ trí nhớ (không nhìn lại bài), vẽ tay sơ đồ ở Mục 3 — chỉ cần 4 hộp (ovsdb-server, ovs-vswitchd, datapath, OVN) và các đường nối đúng loại giao thức (OVSDB hay OpenFlow) giữa chúng. So lại với SVG trong bài — nếu vẽ sai chiều mũi tên hoặc gán nhầm giao thức, đọc lại Mục 3 trước khi sang Module 1.

Nguồn tham khảo​

Tiếp theo: Module 1, Bài 2 — OVS là gì (so sánh chi tiết với Linux bridge, khi nào dùng cái nào).