6. High Availability & Data Model
Mục lục
Section 9 — High Availability và Horizontal Scaling
Nguyên tắc thiết kế
Tất cả nodes đều active/active. Không có active/standby. Không có single point of failure.
Khi node bị quá tải: thêm instance mới → load tự động redistribute. Không cần restart hay reconfigure.
9.1 Control Node HA
vRouter Agent không "hỏi" ai để biết Control Node nào đang sống — nó chỉ đơn giản đọc một danh sách địa chỉ IP đã cấu hình sẵn trong file config của chính nó ([CONTROL-NODE].servers = ip1:5269 ip2:5269...), tự xáo trộn thứ tự để load-balance thô, và khi một node trong danh sách chết thì lập tức chuyển sang node kế tiếp — không cần chờ hay hỏi thêm ai.
vRouter Agent
│
├──── XMPP ──────► Control Node 1 (Active)
└──── XMPP ──────► Control Node 2 (Active)
Cả hai connections đều live.
vRouter nhận state từ cả hai.
Local best-selection (giống BGP bestpath).
Failure scenario:
Control Node 1 dies
│
▼
vRouter Agent: detects connection loss
→ flush state từ Node 1
→ dùng state từ Node 2 (đã có sẵn, up-to-date)
→ pick node tiếp theo trong static server list đã cấu hình sẵn
→ connect to Control Node 3
→ receive full state sync
Traffic không bị gián đoạn trong quá trình failover.
Scale-out: Thêm Control Node mới → cập nhật danh sách [CONTROL-NODE].servers trong config của từng vRouter Agent (và reload) để agent biết node mới tồn tại.
9.2 Configuration Node HA
Cassandra cluster với replication:
Config Node 1 Config Node 2 Config Node 3
Cassandra ──────── Cassandra ──────── Cassandra
replica A replica B replica C
Có thể mất 1 hoặc 2 node mà không mất data.
Khi Control Node cần resync với Config Node mới:
1. Mark all state as "stale"
2. Subscribe RabbitMQ trên Config Node mới, đọc lại toàn bộ object cần thiết từ Cassandra
3. Receive full replay of current state
4. New state replaces stale state
5. Flush remaining stale state (nếu có deleted objects)
9.3 vRouter HA Chi Tiết
Khi vRouter Agent crash/restart:
Trạng thái trước crash:
Forwarding plane: Routes, flow table đầy đủ
Agent: running, connected to control nodes
Agent crash:
└── Forwarding plane: tiếp tục chạy (HEADLESS MODE)
• Forward traffic theo stale state
• Không xử lý first-packet flow mới đúng cách
• Không cập nhật routes mới
Agent restart:
1. Connect đến 2 control nodes
2. Mark all local state as "stale"
3. Receive full state từ control nodes qua XMPP
4. Install fresh state vào forwarding plane
5. Flush remaining stale state (đã bị xóa trên controller)
6. Bình thường trở lại
Khi vRouter Forwarding Plane crash:
Forwarding plane crash (kernel module crash/reload):
└── Tất cả VMs trên server mất kết nối mạng
Không có workaround — single instance per server
Recovery:
1. Kernel module reload
2. vRouter Agent detect forwarding plane loss
3. Agent re-install toàn bộ state từ memory
4. Kết nối mạng VMs được restore
Thời gian downtime: vài giây đến vài chục giây.
9.4 Analytics HA
Analytics Node 1 Analytics Node 2 Analytics Node 3
Collector Collector Collector
NoSQL DB ─────────── NoSQL DB ─────────── NoSQL DB
(replication) (replication) (replication)
Khi một Analytics Node fail:
→ Generators (vRouter, Control Node) chuyển sang node khác trong static server list đã cấu hình
→ Data được buffered trong quá trình chuyển (minimal loss)
→ REST API clients cũng dùng static list các Analytics Node để tìm node mới
What Happens If...
| Scenario | Traffic ảnh hưởng? | Config change ảnh hưởng? | Recovery |
|---|---|---|---|
| 1 Control Node fail | Không | Không (redundant nodes) | Auto |
| Tất cả Control Node fail | Không (stale state) | Có (không tạo VM mới) | Restart controllers |
| 1 Config Node fail | Không | Không (Cassandra HA) | Auto |
| Tất cả Config Node fail | Không | Có | Restart config nodes |
| vRouter Agent fail | Không (headless) | Không | Auto restart |
| vRouter FWD Plane fail | Có (server bị ảnh hưởng) | Không | Reload kernel module |
| Analytics Node fail | Không | Không | Auto |
Section 10 — Data Model: Nền tảng kiến trúc
Mental Model
Hãy nghĩ về hệ thống quản lý bất động sản.
High-level model = Hợp đồng thuê nhà: "Khách hàng A thuê tầng 5, 200m², điều kiện: có wifi, có điều hòa, không hút thuốc".
Low-level model = Hướng dẫn kỹ thuật: "Cài router Cisco model X tại rack 5A, VLAN 500, IP range 192.168.5.0/24, firewall rule deny port 25".
Schema Transformer = Nhân viên kỹ thuật dịch hợp đồng thành hướng dẫn triển khai.
10.1 Hai tầng Data Model
HIGH-LEVEL SERVICE DATA MODEL
(ngôn ngữ business intent)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Objects: Tenant, Project, Virtual Network,
Security Policy, Service Instance,
Security Group, Floating IP, Gateway
Được tạo bởi: Orchestrator (OpenStack), Admin GUI
Lưu tại: Cassandra (qua Config Node)
API: Auto-generated REST API từ data model
╔═══════════════════════╗
║ Schema Transformer ║ ← Compilation step
║ (SDN as a Compiler) ║
╚═══════════════════════╝
LOW-LEVEL TECHNOLOGY DATA MODEL
(ngôn ngữ network protocol)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Objects: Routing Instance, Route Target,
VNI (VXLAN Network Identifier),
BGP Peering Session, MPLS Label,
Forwarding Policy
Được tạo bởi: Schema Transformer (auto-generated)
Lưu tại: Cassandra
Consumed by: Control Node (qua RabbitMQ notify + đọc Cassandra)
10.2 Cấu trúc phân cấp DAG
Toàn bộ object trong data model — Tenant, Project, Virtual Network, VM... — được tổ chức thành một DAG (Directed Acyclic Graph): một cấu trúc dạng cây/đồ thị mà mọi liên kết (edge) đều có hướng, và không có đường nào đi vòng lại thành vòng lặp (acyclic). Object cha "sở hữu" object con — điều này quyết định trực tiếp đến cách Contrail cô lập tenant.
Administrative Domain (root)
│
│ (Ví dụ: một data center)
│
├── Tenant "Coca-Cola"
│ ├── Project "Production"
│ │ ├── Virtual Network "web-tier" (10.1.1.0/24)
│ │ │ ├── VM "web-01" (10.1.1.3)
│ │ │ └── VM "web-02" (10.1.1.4)
│ │ ├── Virtual Network "app-tier" (10.1.2.0/24)
│ │ ├── Security Policy "web-to-app"
│ │ ├── Service Instance "firewall-1" (FW VM)
│ │ └── Security Group "web-servers"
│ └── Project "Dev"
│ └── Virtual Network "dev-net" (10.99.1.0/24)
│
└── Tenant "Pepsi"
└── Project "Production"
└── Virtual Network "pepsi-web" (10.1.1.0/24)
(Cùng IP range với Coca-Cola nhưng hoàn toàn isolated)
Quy tắc DAG:
- Xóa parent → tự động xóa toàn bộ subtree.
- Object có thể reference object khác (reference count).
- Không thể xóa object đang được referenced.
- Weak reference: có thể reference object chưa tồn tại (sẽ được tạo sau).
10.3 Backward Compatibility — Tại sao quan trọng
💡 Hình dung như thế này: Giống như việc thêm một ô cột mới vào bảng Excel đang được nhiều người dùng cùng lúc — người dùng cũ (dùng version cũ) vẫn phải đọc được file, không được xóa hay đổi tên ô cũ. Chỉ được thêm mới.
Contrail là distributed system với nhiều module. Khi update data model:
- Không thể update tất cả module cùng một lúc.
- Một số module có thể chạy version cũ trong khi update.
- Module cũ phải tiếp tục hoạt động đúng.
Quy tắc bắt buộc:
- Không được thay đổi semantics của existing object/link.
- Chỉ được add (không được remove/rename).
- Module cũ nhận object mới → phải ignore gracefully.
- Changes phải incremental (không cần full recompile).
Ví dụ thêm level "Department" giữa Tenant và Project:
TRƯỚC: SAU:
Tenant Tenant
└── Project ├── Project (vẫn valid, backward compat)
└── Department
└── Project (mới)
Project vẫn có thể là con trực tiếp của Tenant (backward compat) HOẶC là con của Department (mới). Không thể vừa là con của cả hai.
10.4 Programming Model
💡 Hình dung như thế này: Giống như nhân viên làm việc tốt trong môi trường năng động — họ không giữ thông tin trong đầu mà ghi vào hệ thống chung (DB), khi đi vắng/restart thì đọc lại từ hệ thống và tiếp tục được. Không cần sếp phải brief lại từ đầu.
Tất cả module phải:
- Event-driven: Lắng nghe pub/sub bus (Redis), react khi có update.
- Restartable: Crash → reconnect → reacquire state → tiếp tục.
- Elastic: Có thể chạy nhiều instance, tự coordinate qua distributed DB.
- Stateless (mostly): State lưu trong DB hoặc "trong network" (peers), không giữ local state khó recover.
Nắm được kiến trúc, forwarding, protocol và khả năng chịu lỗi — giờ là lúc ráp mọi thứ lại thành các use case thực tế, so sánh Contrail với giải pháp MPLS VPN truyền thống, và đi qua một kịch bản end-to-end đầy đủ.
Nguồn tham khảo
- Contrail Discovery Service (dùng để vRouter Agent/Control Node tự tìm instance khả dụng của nhau) đã bị deprecated từ Contrail Controller 4.0, thay bằng static server list cấu hình sẵn trong từng module (
[CONTROL-NODE].servers,[DNS].servers,[DEFAULT].collectors...) — mỗi module tự randomize danh sách để load-balance và chuyển sang node kế tiếp ngay khi phát hiện mất kết nối, không cần hỏi lại discovery server — tf-specs: Contrail 4.0 Removal of Discovery Service; Juniper Contrail 4.0 Release Notes, truy cập 08/2026 - IF-MAP đã bị deprecated từ Contrail Controller 4.0, thay bằng RabbitMQ notify + đọc object từ Cassandra — tf-specs: Control-node gets configuration from Cassandra, truy cập 08/2026