24 docs tagged with "sdn"

Mục lục

Mục lục

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.

Phần 10/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 9, nơi bạn đã dựng tunnel VXLAN/Geneve/GRE để một OVS host tự làm VTEP, gửi traffic đã đóng gói ra khỏi uplink NIC. Bài này lùi lại một bước, xử lý đúng câu hỏi nằm ngay dưới lớp overlay đó: bản thân cái uplink NIC ấy thường không chỉ có một sợi — một host production luôn có ít nhất hai NIC lên fabric để vừa tăng băng thông vừa chống đứt cáp/đứt switch. Đó chính là bài toán bonding/LACP — y hệt khái niệm port-channel/LAG bạn đã cấu hình hàng ngày trên leaf switch, chỉ khác giờ nó chạy ngay trong OVS. Đọc xong, Bài 11 sẽ sang QoS và rate limiting.

Phần 11/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 10, nơi bạn đã gộp nhiều uplink NIC thành một bond để tăng băng thông và chống đứt liên kết. Bài này xử lý một câu hỏi khác hẳn: giả sử băng thông đã đủ, làm sao đảm bảo một VM ồn ào không nuốt hết băng thông của các VM khác, và loại traffic quan trọng luôn được ưu tiên khi uplink bắt đầu nghẽn — đúng bài toán QoS/policer bạn đã cấu hình trên switch vật lý, giờ chuyển vào OVS. Đây là bài cuối của Module 2 — Trung cấp. Đọc xong, loạt bài sẽ sang Module 3, bắt đầu bằng Bài 12 — OpenFlow pipeline sâu.

Phần 12/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 11, nơi bạn đã dựng hai cơ chế QoS (ingress_policing và QoS/Queue với linux-htb) để kiểm soát băng thông — bài cuối cùng của Module 2 — Trung cấp. Bài này mở đầu Module 3 — Nâng cao, và quay thẳng lại công cụ đã học sơ ở Bài 6: ovs-ofctl. Bài 6 mới dừng ở đúng một flow table (table=0), add-flow/dump-flows cơ bản, và action NORMAL. Bài này đào sâu điều Bài 6 chỉ nhắc lướt qua một câu — pipeline OpenFlow thật của OVS có tới hàng trăm table nối tiếp nhau, và biết cách packet nhảy qua chúng, đọc đúng output dump-flows thực chiến, cùng công cụ trace packet giả lập, là kỹ năng nền tảng cho mọi thứ Module 3 xây tiếp (conntrack, DPDK, hardware offload). Đọc xong, Bài 13 sẽ sang connection tracking (conntrack).

Phần 13/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 12, nơi Mục 4 đã liệt kê sơ field ct_state (32-bit, read-only, dùng dạng +trk+new/+trk+est...) rồi hẹn lại đúng câu: "packet chưa đi qua action ct() thì mọi field connection-tracking đều bằng 0 (trạng thái 'untracked'); Bài 13 sẽ đào sâu toàn bộ cơ chế conntrack, bao gồm chính xác các flag trk/new/est/rel nghĩa là gì và khi nào dùng". Đây là bài thứ hai của Module 3 — Nâng cao, tiếp tục dùng đúng khái niệm multi-table pipeline vừa học ở Bài 12 — rule stateful gần như luôn được tách riêng ra một table trong pipeline, không nhồi chung với ACL hay L2 forward. Đọc xong, Bài 14 sẽ chuyển sang DPDK — userspace datapath tăng tốc.

Phần 14/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 13, nơi Mục 2 đã dùng đúng lệnh sudo ovs-vsctl get bridge br0 datapath_type để phân biệt một bridge đang chạy kernel datapath (trả về chuỗi rỗng, tương đương system) hay userspace datapath (trả về netdev). Bài 14 đào sâu đúng nhánh netdev đó, khi nó được tăng tốc bằng DPDK — công nghệ đã được nhắc tên (chưa giải thích) từ Bài 3. Đây là bài thứ ba của Module 3 — Nâng cao, sau OpenFlow pipeline sâu (Bài 12) và connection tracking (Bài 13). Sau bài này, Bài 15 sẽ chuyển sang hardware offload (TC flower, SmartNIC) — bước tiếp theo tự nhiên khi ngay cả DPDK cũng chưa đủ, cần đẩy hẳn việc forward xuống phần cứng chuyên dụng.

Phần 15/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 14, nơi Mục 5 đã chỉ ra cái giá thật của DPDK nếu ngay cả một core CPU chạy 100% cũng không còn đáng đánh đổi, hoặc traffic đã vượt quá khả năng của bất kỳ core CPU nào dù dùng DPDK, bước tiếp theo là đẩy hẳn việc chuyển mạch ra khỏi CPU — xuống thẳng phần cứng NIC. Đây là bài thứ tư của Module 3 — Nâng cao, sau OpenFlow pipeline sâu (Bài 12), connection tracking (Bài 13) và DPDK (Bài 14). Sau bài này, Bài 16 sẽ chuyển sang giám sát (sFlow, IPFIX, port mirroring).

Phần 16/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 15, nơi câu đúc kết cuối bài đã cảnh báo ngoài đếm byte trên từng flow, làm sao thật sự quan sát traffic đang chạy qua OVS — sao chép nguyên vẹn để bắt gói, lấy mẫu thống kê để nhìn xu hướng, hay xuất thành flow record để phân tích/billing? Đây là bài cuối của Module 3 — Nâng cao. Sau bài này, Bài 17 mở đầu Module 4 — Chuyên gia/SDN tích hợp, đi sâu vào OVN.

Phần 17/21 trong loạt Open vSwitch (OVS) — mở đầu Module 4 pipeline OpenFlow nhiều bảng, conntrack, DPDK, hardware offload, giám sát. Bài 1 Mục 3 đã nhắc tên OVN và nói OVN dùng "cả OVSDB lẫn OpenFlow", kể tên ovn-controller cùng Northbound DB/Southbound DB — nhưng bỏ sót hẳn một mảnh trung tâm: ovn-northd. Bài 17 vá đúng mảnh còn thiếu đó và dựng lại toàn cảnh kiến trúc OVN từ đầu.

Phần 18/21 trong loạt Open vSwitch (OVS) — bài đầu tiên của Module 4 áp OVN vào một Cloud Management System (CMS) thật, thay vì lab ovn-nbctl tự tay như Bài 17. Neutron — hệ thống networking của OpenStack — chính là CMS kinh điển nhất gắn với OVN, và cũng là nơi kiến trúc "agent tự tính OpenFlow" (thứ Bài 1-16 vẫn ngầm giả định) và kiến trúc OVN (Bài 17) cùng tồn tại song song dưới một framework tên ML2 (Modular Layer 2). Bài này không giải thích lại OVN từ đầu — mọi khái niệm NB DB/SB DB/ovn-northd/ovn-controller đã học ở Bài 17 được dùng lại nguyên vẹn, chỉ nối thêm phần Neutron đứng ở đâu trong chuỗi đó.

Phần 19/21 trong loạt Open vSwitch (OVS) — Bài 18 vừa cho thấy một Cloud Management System (CMS) là OpenStack Neutron có thể cắm thẳng vào OVN core (Bài 17) qua đúng vai trò "OVN/CMS Plugin", trong khi vẫn giữ song song một kiến trúc khác hoàn toàn không dùng OVN (ML2/OVS, agent Python tự tính flow). Bài 19 lặp lại đúng cấu trúc câu chuyện đó ở một CMS khác hẳn OVN-Kubernetes không dùng lại nguyên xi mô hình triển khai OVN "giáo khoa" đã học ở Bài 17 — nó đổi hẳn sang một kiến trúc mới gọi là "interconnect", đây sẽ là trọng tâm Mục 2-3 của bài.

Phần 2/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 1, nơi đã so sánh OVS với Linux bridge ở mức khái quát (Mục 2). Bài này đào sâu: Linux bridge thực sự làm được gì, giới hạn thật sự nằm ở đâu, và tiêu chí cụ thể nào giúp bạn quyết định dùng cái nào cho một tình huống thật. Đọc xong, Bài 3 sẽ mổ xẻ kiến trúc bên trong OVS (ovs-vswitchd, kernel datapath) — phần mà bài này chỉ chạm tới ở mức "chúng là hai thứ khác nhau".

Phần 20/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 19, bài cuối trước khi series khép lại ở Bài 21 (tổng kết OVS vs fabric vật lý). Suốt 19 bài trước, bạn đã học rải rác gần chục công cụ khác nhau — ovs-vsctl show ở Bài 5, ovs-ofctl dump-flows ở Bài 6, ovs-appctl dpctl/dump-flows ở Bài 3, ofproto/trace ở Bài 12, tcpdump ở Bài 9/13 — mỗi công cụ xuất hiện đúng lúc cần minh họa một khái niệm cụ thể, không có bài nào gộp chúng lại thành một quy trình debug hoàn chỉnh. Bài này làm đúng việc đó overlay terminate ở OVS hay ở fabric vật lý.

Phần 21/21 — bài chốt của loạt Open vSwitch (OVS). Hai mươi bài trước đã đi từ một câu hỏi rất cụ thể ở Phần 1 ("overlay có thể được terminate ở OVS hoặc ở leaf switch") tới toàn bộ chi tiết kỹ thuật cần để tự trả lời câu hỏi đó OVN giờ có thể tự mình nói chuyện BGP EVPN thẳng với fabric vật lý, không cần leaf switch hay gateway trung gian nào làm hộ việc đó nữa.

Phần 3/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 1 (đã giới thiệu sơ lược ovs-vswitchd/ovsdb-server ở Mục 3) và Phần 2 (đã khẳng định OVS và Linux bridge là hai kernel module hoàn toàn tách biệt). Bài này mở nắp máy: bên trong OVS thực sự có những mảnh nào, và một packet đi qua chúng theo đường nào. Đọc xong, Bài 4 sẽ đưa bạn vào cài đặt và dựng lab OVS đầu tiên bằng tay.

Phần 4/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 1 (tổng quan), Phần 2 (so sánh Linux bridge) và Phần 3 (kiến trúc bên trong). Ba bài trước toàn nói bằng lời và output minh họa. Bài này khác hẳn: từ đây bạn tự tay gõ lệnh, tự tay xác nhận. Đọc xong, Bài 5 sẽ đào sâu ovs-vsctl — tạo port, gán VLAN, quản lý OVSDB.

Phần 5/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 4, nơi bạn đã gõ ovs-vsctl add-br/add-port chỉ để dựng lab cho xong, chưa giải thích kỹ công cụ đang dùng là gì. Bài này quay lại đúng ovs-vsctl, đào sâu: vòng đời đầy đủ của bridge/port, cách gán VLAN, và cách nhìn thẳng vào OVSDB — chính là database Bài 1 Mục 3 đã nhắc tên nhưng chưa ai thật sự mở ra xem. Đọc xong, Bài 6 sẽ chuyển hẳn sang ovs-ofctl — công cụ đọc/ghi flow table OpenFlow, khác hoàn toàn với ovs-vsctl.

Phần 6/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 5, nơi bạn đã học ovs-vsctl thao tác trên OVSDB: vòng đời bridge/port qua add-br/add-port/del-, cờ --may-exist/--if-exists để script chạy lại được nhiều lần, ba loại interface system/internal/tap, gán VLAN bằng tag=/trunks=, so sánh ovs-vsctl show với ovsdb-client dump, và cách gộp nhiều lệnh vào một transaction atomic bằng --. Toàn bộ mục đó là cấu hình switch — OVSDB. Bài này chuyển hẳn sang hành vi forward packet* — OpenFlow, việc ovs-ofctl làm — và đây là bài cuối Module 1 (Nền tảng). Đọc xong, Module 2 bắt đầu từ Bài 7 với OVS + KVM/libvirt, gắn VM thật vào bridge bạn đã dựng.

Phần 7/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 6, mở đầu Module 2 (Trung cấp). Module 1 đã trang bị đủ bộ công cụ nền tảng (ovs-vsctl, ovs-ofctl) trên một bridge dựng bằng namespace/veth thủ công — Module 2 đưa những công cụ đó vào tình huống thật đầu tiên: một VM chạy trên KVM/libvirt cần lên mạng qua OVS. Namespace/veth ở Bài 4-6 chỉ là mô hình thu nhỏ để học công cụ; từ bài này, "port" không còn là thứ bạn tự tay add-port, mà là thứ một hệ thống khác — libvirt — tự tạo ra và xóa đi theo đúng vòng đời của VM.

Phần 8/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 7, nơi VLAN chỉ xuất hiện đúng một câu set port vnet0 tag=100 áp lại nguyên xi cú pháp Bài 5. Bài 5 Mục 3 đã nhắc tên cột vlanmode và nói nó quyết định 5 hành vi khác nhau, nhưng chỉ dừng ở hai trường hợp cơ bản (access, trunk) rồi hẹn đào sâu ở đây. Bài này mở đúng cái hẹn đó: 5 giá trị vlanmode đầy đủ, một trunk port thật nối hai OVS bridge, và dot1q-tunnel — chế độ QinQ dễ hiểu nhầm nhất trong toàn bộ schema Port.

Phần 9/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 8, nơi bạn đã đào sâu vlan_mode và cách một trunk port giữ nguyên VLAN tag giữa hai OVS bridge. Bài này chuyển hẳn sang một lớp khác của OVS — không còn switching thuần trong một L2 domain, mà là tunnel: đóng gói cả một khung Ethernet vào trong một gói IP khác để nó "đi xuyên" qua một mạng L3 trung gian, y hệt nguyên lý bạn đã học ở loạt EVPN và ở GRE Tunnel, chỉ khác nơi việc đóng gói đó diễn ra. Đây cũng là bài quan trọng nhất của Module 2, vì nó nối thẳng vào kiến thức VXLAN/EVPN bạn đã có sẵn trên fabric vật lý. Đọc xong, Bài 10 sẽ chuyển sang bonding/LACP trên OVS.

Phần 1/18 trong loạt Tungsten Fabric vRouter — bài mở đầu bắt buộc đọc trước mọi module. Chưa có lab, chưa có CLI sâu — bài này chỉ trả lời ba câu hỏi: vRouter là gì, tại sao series này lại tồn tại song song với series Contrail Architecture (Juniper)/Part%201.Tong%20Quan%20va%20Kien%20Truc%20Tong%20The.md) đã publish, và series này sẽ đưa bạn đi đâu. Module 1 (Bài 2 trở đi) mới bắt đầu đào sâu và dựng lab thật.