2. Ba loại Node trong Controller
Mục lục
Section 3 — Ba loại node trong Controller
Mental Model
Hãy nghĩ về một công ty logistics lớn (như FedEx).
Configuration Node = Phòng kế hoạch. Khách hàng nói "tôi muốn gửi kiện hàng từ Hà Nội đến Sài Gòn, ưu tiên cao". Phòng kế hoạch dịch yêu cầu đó thành: "dùng xe tải loại A, tuyến đường số 5, ưu tiên level 1".
Control Node = Trung tâm điều phối vận tải. Nhận kế hoạch, giao nhiệm vụ cho từng xe, theo dõi trạng thái, điều chỉnh khi có thay đổi.
Analytics Node = Phòng báo cáo & giám sát. Theo dõi mọi hoạt động, ghi log, cảnh báo khi có bất thường, trả lời câu hỏi "tháng này xe nào chậm nhất?".
3.1 Configuration Node — "Compiler" của SDN
Simple Explanation
Configuration Node là nơi bạn nói với Contrail "tôi muốn gì" và nó tự dịch thành "cần làm gì cụ thể trong mạng".
Ví dụ:
- Bạn nói: "Tạo Virtual Network A với subnet 10.1.1.0/24 cho tenant X"
- Configuration Node tự dịch ra: "Cần route target RT:65000:100, VNI 1001, export policy RP-A-EXPORT, import policy RP-A-IMPORT"
Bạn không cần tự tính route target hay routing instance — Configuration Node lo việc đó. Nhưng vì các thuật ngữ này sẽ còn xuất hiện xuyên suốt phần còn lại của bài, đáng để biết chúng LÀ GÌ trước khi đi tiếp:
- Routing Instance: một bảng định tuyến (routing table) riêng biệt, cô lập với các routing instance khác — tương đương khái niệm VRF (Virtual Routing and Forwarding) trong mạng truyền thống. Mỗi Virtual Network trong Contrail tương ứng với ít nhất một routing instance, đó là cơ chế thật sự tạo ra sự cô lập giữa các tenant, chứ không phải VLAN.
- Route Target (RT): một thuộc tính BGP (extended community) gắn vào route để quyết định route đó được export từ routing instance nào và import vào routing instance nào. Hai routing instance chỉ "nhìn thấy" route của nhau khi chia sẻ cùng Route Target — đây chính là cơ chế BGP/MPLS VPN tiêu chuẩn (RFC 4364), Contrail chỉ áp dụng nó cho VM thay vì site khách hàng vật lý.
- VNI (Virtual Network Identifier): nhãn định danh mạng ảo, chỉ có ý nghĩa khi encapsulation được chọn là VXLAN — với encapsulation mặc định (MPLS-over-GRE/UDP), vai trò tương đương do MPLS label đảm nhiệm.
Detailed Technical Explanation
Configuration Node chứa hai loại data model và một transformation engine:
HIGH-LEVEL DATA MODEL
(ngôn ngữ business)
│
┌──────▼──────┐
│ Schema │ ← "Compiler"
│ Transformer │
└──────┬──────┘
│
LOW-LEVEL DATA MODEL
(ghi vào Cassandra)
│
┌──────▼──────┐
│ RabbitMQ │ ← Notify Control Node,
│ (pub/sub) │ Control Node đọc lại object
└─────────────┘ mới từ Cassandra
| Data Model | Được tạo bởi | Ví dụ object | Ngôn ngữ |
|---|---|---|---|
| High-level | Người dùng/Orchestrator | Virtual Network, Security Policy, Tenant, Project | Business intent |
| Low-level | Schema Transformer (auto) | Route Target, VNI, Routing Instance, BGP Peer | Network protocol |
Tại sao gọi là "SDN as a Compiler"?
Giống như compiler ngôn ngữ lập trình:
- Input: high-level code (C/Java) = high-level service data model
- Compiler: Schema Transformer = transformation engine
- Output: machine code (assembly/bytecode) = low-level technology data model
Khi bạn thay đổi high-level config, Transformer tự động re-compile và cập nhật low-level config. Just-in-time (JIT) compilation.
Component Breakdown
| Component | Chạy ở đâu | Làm gì | Giao tiếp với |
|---|---|---|---|
| REST API Server | User space | Nhận high-level config từ OpenStack (Neutron plugin) hoặc GUI | OpenStack Neutron, GUI, OSS/BSS |
| Redis | User space (in-memory) | Message bus nội bộ giữa Schema Transformer và các component khác | Internal |
| Cassandra DB | Distributed | Lưu trữ persistent cả high-level và low-level data model | Internal |
| Schema Transformer | User space | Detect change qua Redis, dịch high-level → low-level | Redis (input), Cassandra (write) |
| RabbitMQ | User space | Message bus phát notification tới Control Node mỗi khi có object mới/thay đổi trong Cassandra | Control Node |
| ZooKeeper | Distributed | Unique ID allocation, distributed transactions/locks | Internal |
Flow: Tạo Virtual Network mới
Scalability và HA
- Multiple Config Node instances chạy active/active.
- Cassandra replicate data giữa các node (fault-tolerant).
- REST API load được spread trên nhiều node.
- Nếu một Config Node fail → Control Node tự chuyển sang Config Node khác trong static server list đã cấu hình → resync bằng "mark all state stale → full replay → flush remaining stale".
3.2 Control Node — "Routing Engine" phân tán
Simple Explanation
Nếu Configuration Node là "phòng kế hoạch", thì Control Node là "người thực thi kế hoạch đó với từng thiết bị".
Control Node biết toàn bộ "bản đồ mạng" — mọi VM đang ở đâu, IP của chúng là gì, route nào đến đâu. Nó đẩy thông tin này xuống cho vRouter và đảm bảo tất cả đều nhất quán.
Detailed Technical Explanation
Control Node là logically centralized control plane — nó duy trì ephemeral network state (trạng thái mạng tạm thời, không cần persist như config).
┌────────────────────────────────┐
│ Control Node │
│ │
Cassandra ───────►│ Desired State (from Config) │
│ │ │
│ ▼ │
│ Actual State (from probes) │◄──── BGP (gateway)
│ │ │◄──── XMPP (vRouter)
│ ▼ │
│ Delta = Desired - Actual │
│ │ │
│ ▼ │
XMPP ◄──────────│ "Make it so" commands │
BGP/NC ◄────────│ │
└────────────────────────────────┘
Eventual consistency model: Control Node không đảm bảo tất cả vRouter nhận state đồng thời — nhưng cuối cùng tất cả sẽ nhất quán (eventually consistent).
Control Node Giao tiếp Với Ai?
| Đối tác | Giao thức | Mục đích |
|---|---|---|
| Configuration Node | RabbitMQ (notify) + Cassandra (read) | Nhận low-level desired state |
| Control Node khác | IBGP | Đồng bộ network state giữa controller instances |
| vRouter Agents | XMPP | Push routes + routing instance config; nhận VM route advertisements |
| Gateway Router/Switch | BGP | Exchange routes với physical network |
| Gateway Router/Switch | NETCONF | Push configuration state |
IBGP giữa các Control Node: Mỗi Control Node có toàn bộ network state của hệ thống. Chúng sync với nhau qua IBGP. Vì state tương đối nhỏ (chỉ routes của VMs, không phải toàn bộ internet routing table), nên mỗi node giữ được bản full copy trong RAM.
Flow: VM Route Propagation
What Happens If Control Node Breaks?
Triệu chứng:
• vRouter agent log: "XMPP connection lost to control-node-1"
• Mới tạo VM nhưng không reach được VM khác
• Route table trên vRouter không update khi có VM mới
Root cause:
• Control node crash
• Network partition giữa compute và control node
• Control node overload (OOM, CPU 100%)
Recovery process:
1. vRouter agent detect connection lost
2. Agent flush state từ failed control node
3. Agent dùng state từ redundant control node (đã có sẵn)
4. Agent pick control node kế tiếp trong static server list đã cấu hình sẵn
5. Reconnect và nhận full state từ control node mới
Debug commands:
# Trên compute node
contrail-status | grep "vnsw agent"
cat /var/log/contrail/contrail-vrouter-agent.log | grep "XMPP"
# Introspect vRouter agent
curl http://localhost:8085/Snh_AgentXmppConnectionStatusReq
# Xem state của từng XMPP connection
curl http://localhost:8085/Snh_XmppConnectionStats
3.3 Analytics Node — Hệ thống telemetry
Simple Explanation
Analytics Node là "hộp đen" của hệ thống — ghi lại mọi thứ xảy ra để sau này có thể debug và phân tích.
Không phải chỉ passive logging — nó có thể chủ động hỏi các component để lấy thêm chi tiết khi phát hiện có vấn đề. Điều này quan trọng vì nhiều bug network chỉ xảy ra một lần, không reproduce được.
Component Breakdown
| Component | Vai trò |
|---|---|
| Collector | Nhận Sandesh messages từ mọi component. Không filter gì cả — lưu tất cả. |
| NoSQL Database | Lưu trữ time-series data. Tối ưu cho query theo thời gian. |
| Rules Engine | Khi event X xảy ra → tự động trigger thu thập thêm data về Y. |
| REST API Server | Northbound API để client query analytics data. |
| Query Engine | Map-reduce engine. Một REST query → nhiều sub-query → aggregate kết quả. |
Sandesh Protocol
Sandesh là giao thức XML nội bộ của Contrail. Mọi component trên mọi node đều có kết nối Sandesh đến analytics node.
Hai loại message:
ASYNC (push):
Component ──────────────────► Analytics Node
"Đây là log/event/trace của tôi"
SYNC (pull):
Analytics Node ─── request ──► Component
◄── response ──
"Cho tôi biết current state của bạn"
"Aggregation" (scatter-gather): Một GET request từ client có thể được fan-out thành nhiều sub-request đến nhiều node, rồi kết quả được aggregate lại. Từ phía client thấy như một query duy nhất.
How to Observe in Production
# Query analytics REST API
curl http://<analytics-node>:8081/analytics/uves/vrouter/<hostname>
# Query flow records
curl "http://<analytics-node>:8081/analytics/query" -d '{
"table": "FlowRecordTable",
"start_time": "now-10m",
"end_time": "now",
"filter": [{"name": "sourceip", "value": "10.1.1.1"}]
}'
# Check analytics node status
contrail-status | grep analytics
# View collected logs
curl http://<analytics-node>:8081/analytics/logs?object_id=vrouter-agent
Mô hình ba loại node (Configuration, Control, Analytics) ở trên là kiến trúc kinh điển của Contrail/Tungsten Fabric. Ở các bản triển khai cloud-native mới hơn như Juniper CN2 (Kubernetes-native), ba vai trò này được tách thành nhiều microservice/container pod và quản lý bằng Kubernetes operator thay vì ba node nguyên khối — nhưng vai trò logic (compile config, phân phối route, thu thập telemetry) không đổi, phần dưới đây vẫn là nền tảng khái niệm đúng cho cả hai cách triển khai.
Ba loại node của Controller quyết định cấu hình, phân phối route, và index dữ liệu real-time — nhưng route đó cuối cùng phải "hạ cánh" xuống compute server, nơi packet của VM thực sự được forward. Phần tiếp theo đi sâu vào vRouter — cánh tay thực thi của Contrail.
Nguồn tham khảo
- IF-MAP Server đã bị deprecated từ Contrail Controller 4.0; từ bản này, thay đổi config được truyền qua RabbitMQ pub/sub (notify) và Control Node đọc lại object mới nhất trực tiếp từ Cassandra — tf-specs: Control-node gets configuration from Cassandra; Juniper Contrail 4.0 Release Notes, truy cập 08/2026
- Discovery Service cũng bị deprecated cùng đợt (Contrail 4.0), thay bằng static server list cấu hình sẵn trong từng module — không còn cơ chế "hỏi" một service riêng để tìm node khả dụng — tf-specs: Contrail 4.0 Removal of Discovery Service, truy cập 08/2026
- Kiến trúc 3-node (Config/Control/Analytics) là mô hình kinh điển; từ Tungsten Fabric 5.0 trở đi được triển khai dưới dạng microservices/container pod, và CN2 (Kubernetes-native) tách tiếp thành các Kubernetes operator/CRD riêng — Tungsten Fabric Architecture Overview, truy cập 08/2026