NFV — Network Functions Virtualization (Phần 2): Ứng dụng, triển khai và case study thực tế

Mục lục

• 7. Ứng dụng thực tiễn của NFV
• 8. Các giải pháp triển khai NFV trên thị trường
• 9. Case study 2017: Triển khai thử nghiệm hệ thống NFV
• 10. Case study 2017: Công cụ giám sát hệ thống NFV tự phát triển
• 11. Tổng kết và nhìn lại
• 12. Phụ lục: Alarm Framework và Monitor Driver của Tacker

Bài viết gồm 2 phần. Phần 2 (dưới đây) trình bày ứng dụng thực tiễn, các giải pháp triển khai trên thị trường, case study 2017 và phụ lục. Phần 1 trình bày lý do NFV ra đời, khái niệm, kiến trúc ETSI và quan hệ NFV–SDN: NFV — Network Functions Virtualization (Phần 1).

---

7. Ứng dụng thực tiễn của NFV

7.1. NFV Infrastructure as a Service (NFVIaaS)

Khi xây hạ tầng ảo hóa để triển khai NFV, phần lớn nhà cung cấp dịch vụ nghĩ ngay tới mô hình đám mây nội bộ (Private Cloud). Vấn đề là không phải nhà cung cấp nào cũng đủ tiềm lực trải hạ tầng của mình rộng khắp để phục vụ khách hàng ở mọi nơi — với nhà cung cấp quy mô nhỏ, tự đầu tư một hạ tầng ảo hóa quy mô lớn lại càng là bài toán khó.

Giải pháp: nhà cung cấp dịch vụ lớn, đủ tiềm lực hoặc ở vị trí địa lý thuận lợi, tự xây hạ tầng ảo hóa NFV của mình rồi cho các nhà cung cấp nhỏ hơn hoặc ở khu vực khác thuê lại — mô hình này gọi là NFVIaaS (NFV Infrastructure as a Service), bao gồm cả dịch vụ hạ tầng tính toán/lưu trữ (IaaS) lẫn hạ tầng mạng (NaaS).

Ví dụ: nhà cung cấp A cho nhà cung cấp B thuê hạ tầng ảo hóa để chạy một phần hệ thống CDN của B — B chỉ quản lý được các VNF CDN của mình, không tác động gì tới hạ tầng bên dưới của A. Mô hình còn có thể mở rộng thêm: nhà cung cấp cài thêm công cụ hỗ trợ lên hạ tầng của mình, tạo thành nền tảng cho các doanh nghiệp khác (không phải nhà mạng) xây dựng ứng dụng/dịch vụ riêng — tương đương một dịch vụ PaaS (Platform as a Service).

7.2. vCPE — Ảo hóa thiết bị tại nhà khách hàng

Hạ tầng viễn thông và di động truyền thống đòi hỏi rất nhiều thiết bị chuyên dụng đắt đỏ — từ kiến trúc EPC (Evolved Packet Core) của mạng lõi di động đến các trạm phát sóng (Mobile Base Station). Ứng dụng NFV cho phép nhà mạng thay thế một phần hoặc toàn bộ các thiết bị này bằng máy chủ, switch, thiết bị lưu trữ phổ thông — tiết kiệm chi phí đầu tư/vận hành/điện năng, đồng thời tăng độ linh hoạt và khả năng ứng phó sự cố.

Ứng dụng tiêu biểu nhất là vCPE (virtual Customer Premises Equipment) — ảo hóa hoàn toàn hoặc một phần các thiết bị CPE (router Internet, set-top box,...) thành VNF. Khách hàng không còn phải tự cấu hình phức tạp từng dịch vụ; thay vào đó chỉ cần một cổng portal để theo dõi và yêu cầu mở rộng/kết thúc dịch vụ.

Có hai cách tiếp cận về vị trí đặt thiết bị chạy vCPE:

• VNF at Premise (Distributed vCPE): thiết bị chạy vCPE đặt tại chính vị trí khách hàng, tối ưu để chạy VNF theo nhu cầu — khách hàng không cần can thiệp phần cứng/phần mềm, mọi thứ (nâng cấp, mở rộng) được nhà cung cấp cấu hình từ xa. Cách này phụ thuộc nhiều vào độ ổn định mạng truy cập và giới hạn phần cứng ban đầu; các khách hàng cũng không chia sẻ được tài nguyên ảo hóa với nhau, gây lãng phí. Bù lại, triển khai khả thi và dễ vì không thay đổi nhiều kiến trúc tổng thể — chỉ cần cấp CPE mới tối ưu hơn.
• VNF at CO/PoP (Centralized vCPE): vCPE đặt tại trung tâm dữ liệu nhà cung cấp — mỗi khách hàng có một virtual Edge CPE riêng phục vụ mình, khách hàng chỉ cần một thiết bị thu/phát tín hiệu đơn giản để kết nối vào. Cách này giảm mạnh chi phí đầu tư/vận hành CPE, thuận tiện quản trị và tính cước, nhưng đòi hỏi nhà cung cấp đầu tư ban đầu lớn để nâng cấp/xây mới data center.

Trong thực tế triển khai, nhiều kiến trúc còn kết hợp thêm SDN vào vCPE để tối ưu hơn nữa về hiệu năng và điều khiển luồng dữ liệu.

7.3. Service Chaining và VNF Forwarding Graph

Một hàm chức năng mạng (Network Function — NF) đơn lẻ đã có thể là một dịch vụ mạng, nhưng để tối đa hóa lợi ích, nhà cung cấp dịch vụ thường xâu chuỗi các NF lại với nhau — gọi là Function Chaining hay Service Chaining — tạo thành dịch vụ phức tạp hơn cho hệ thống viễn thông. Chuỗi NF như vậy gọi là Network Function Forwarding Graph; khi áp dụng ảo hóa, các VNF (kết hợp cả PNF sẵn có nếu cần) nối lại thành một VNF Forwarding Graph (VNFFG).

Ưu điểm dễ thấy nhất: vì các NF chạy trên môi trường ảo hóa, tính sẵn sàng và độ linh hoạt rất cao — quản trị viên triển khai, co giãn, thu hồi hay phục hồi VNF khi có sự cố một cách nhanh chóng, và có thể lập trình để thay đổi đường đi của luồng dữ liệu qua các VNF một cách tự động, linh hoạt, tập trung.

7.4. Tiềm năng ứng dụng NFV tại Việt Nam

Bản gốc tài liệu này (viết năm 2017) đánh giá tiềm năng NFV cho hai nhóm đối tượng tại Việt Nam:

• Nhà cung cấp dịch vụ Internet/viễn thông (Viettel, VNPT, FPT, CMC,...): ảo hóa hạ tầng mạng viễn thông/di động giúp triển khai và quản lý dịch vụ nhanh, linh hoạt hơn trên phần cứng phổ thông — đặc biệt khi kết hợp SDN có thể tối ưu truyền dẫn và chia sẻ tài nguyên hạ tầng kết nối. Áp dụng dịch vụ hàm chức năng mạng ảo còn giúp quản lý tốt hơn dịch vụ Internet/Thoại/Truyền hình, đồng thời cắt giảm chi phí triển khai/bảo trì/đào tạo cho thiết bị CPE tại nhà khách hàng.
• Công ty, tổ chức kinh doanh trên Internet (ví dụ nhóm doanh nghiệp media/giải trí, trường đại học,...): sử dụng dịch vụ hàm chức năng mạng ảo (Load Balancing, Firewall) từ nhà cung cấp viễn thông để tiết kiệm chi phí đầu tư/vận hành thiết bị CPE, hoặc tự ảo hóa hạ tầng phần cứng sẵn có để tiết kiệm chi phí mua sắm mới.

---

8. Các giải pháp triển khai NFV trên thị trường

8.1. Khối NFVI: OpenStack và OPNFV

OpenStack là giải pháp xây dựng hạ tầng ảo hóa tiêu biểu nhất cho NFVI/VIM, gồm nhiều dự án con phối hợp với nhau:

Dự án con	Vai trò
Compute (Nova)	Quản lý tài nguyên tính toán (CPU, RAM) của máy ảo
Network (Neutron, networking-sfc)	Quản lý tài nguyên mạng, liên kết giữa các máy ảo
Storage (Cinder)	Quản lý tài nguyên lưu trữ (HDD, SSD) của máy ảo
Orchestration (Heat)	Điều phối ứng dụng đám mây qua template định nghĩa sẵn
Workflow (Mistral)	Quản lý, thực thi quy trình tác vụ cho Tacker và các dịch vụ khác
Telemetry (Ceilometer)	Đo lường, thu thập dữ liệu từ các dịch vụ khác trong OpenStack

OpenStack cung cấp nền móng vững chắc cho kiến trúc NFV — phù hợp triển khai, điều phối, quản lý VNF, quản lý nhiều data center từ một giao diện. Kiến trúc mở, khả năng tương thích module hóa với nhiều dự án khác là nền tảng để nhà mạng/doanh nghiệp thiết kế hệ thống NFV đúng nhu cầu riêng. Khả năng của OpenStack đã được kiểm chứng ở nhiều hệ thống lớn (NASA, CERN, AT&T, China Mobile, SK Telecom, Ericsson,...); dự án Neutron cũng đã phát triển ổn định, được dùng rộng rãi trong thực tế — và phần lớn giải pháp MANO trên thị trường đều hỗ trợ OpenStack làm VIM.

OPNFV (Open Platform for NFV) ra đời tháng 9/2014 do Linux Foundation khởi xướng, nhằm tạo nền tảng hợp nhất đáp ứng tiêu chuẩn khắt khe của nhà cung cấp dịch vụ, tăng tốc đưa sản phẩm/dịch vụ NFV mới ra thị trường. OPNFV tích hợp nhiều dự án (OpenStack, KVM, LXD, Ceph, OpenDaylight,...) cùng các giải pháp tối ưu chuyển tiếp gói tin (FD.io, DPDK, ODP), chạy được trên nhiều kiến trúc phần cứng phổ thông (x86 Intel, ARM). Bằng cách đóng gói mọi thành phần vào một tập tin ISO duy nhất và tự động hóa cấu hình bằng Ansible/Puppet, OPNFV giúp kỹ sư giảm thời gian thiết lập để tập trung kiểm thử giải pháp NFV.

Bản gốc tài liệu ghi nhận cấu hình phần cứng tối thiểu để triển khai OPNFV khi đó khá cao — chỉ phù hợp công ty/phòng nghiên cứu lớn:

Phần cứng	Yêu cầu
Số node	Tối thiểu 3 node: 1 Fuel deployment master, 1 Controller, 1 Compute
CPU	Mỗi node tối thiểu 1 CPU hỗ trợ ảo hóa (từ Intel Xeon E3 trở lên)
RAM	Mỗi node tối thiểu 16GB
Disk	Mỗi node tối thiểu 256GB, ổ cứng 10.000 RPM
Network	Mỗi node tối thiểu: 1 card PXE Boot từ Fuel Master + 1 card cấu hình VLAN (PUBLIC, MGMT, STORAGE, PRIVATE)

Vì yêu cầu phần cứng cao này, nhóm tác giả quyết định không dùng OPNFV cho phần thử nghiệm mà tự xây hạ tầng ảo hóa riêng trên nền OpenStack (xem Mục 9).

⚠️ Cập nhật hiện trạng (2026): OPNFV không còn tồn tại như một dự án độc lập. Cuối năm 2020, OPNFV phát hành bản cuối cùng dưới tên riêng, sau đó sáp nhập với dự án CNTT (Cloud iNfrastructure Telco Taskforce) để hình thành Anuket — dự án chung dưới LF Networking, chính thức ra mắt đầu năm 2021. Anuket kế thừa mục tiêu tăng tốc tích hợp/triển khai hạ tầng NFV của OPNFV, đồng thời mở rộng phạm vi sang cả CNF (container hóa) chứ không chỉ VNF dạng VM. Xem chi tiết ở mục Nguồn tham khảo.

8.2. Khối MANO: OpenBaton, Open Source MANO, Tacker

Nhóm tác giả khảo sát ba giải pháp MANO tuân theo chuẩn ETSI phổ biến nhất tại thời điểm 2017: OpenBaton, Open Source MANO và Tacker.

OpenBaton

Dự án mã nguồn mở về khối MANO, phát triển theo chuẩn ETSI bởi Viện nghiên cứu Fraunhofer FOKUS (Đức). OpenBaton cung cấp: một NFVO điều phối hoạt động hệ thống (quản lý thông tin VNF/NS, tương tác với nhiều VNFM/VIM khác nhau); một generic VNFM có thể mở rộng cho nhiều loại VNF, đi kèm generic EMS thực thi script cấu hình trong VM; driver tương tác với VIM (chỉ mới hỗ trợ OpenStack và OpenVIM tại thời điểm khảo sát); hệ thống kiểm soát lỗi và tự động mở rộng; giao diện quản lý web cùng hệ thống giám sát dựa trên Zabbix.

Bản gốc nhận định: tài liệu hướng dẫn rõ ràng, yêu cầu phần cứng không cao, hỗ trợ OpenStack phù hợp hạ tầng dự kiến triển khai — nên nhóm chọn OpenBaton để thử nghiệm ở Mục 9. Điểm trừ ghi nhận khi đó: dự án còn non trẻ, chưa hỗ trợ khởi tạo VNF Forwarding Graph hoàn chỉnh, quy mô cộng đồng nhỏ nên độ ổn định và hỗ trợ người dùng còn hạn chế.

⚠️ Cập nhật hiện trạng (2026): tổ chức GitHub openbaton gần như ngừng hoạt động — phần lớn repository lõi (NFVO, dashboard, docs, bootstrap) không còn commit nào kể từ khoảng 2019–2020. Dự án không có thông báo chính thức "khai tử", nhưng trên thực tế đã ở trạng thái dormant nhiều năm, không còn phù hợp để triển khai mới. Nếu tìm hiểu MANO nguồn mở ngày nay, ETSI OSM và Tacker (xem bên dưới) là hai lựa chọn còn được duy trì tích cực.

Open Source MANO (OSM)

Dự án mã nguồn mở được chính ETSI đỡ đầu, hướng tới sản phẩm MANO chất lượng cao, tương thích nhiều loại VNF. Về chức năng, OSM cung cấp một NFVO (gồm Network Service Orchestrator + Resource Orchestrator, có thể kết nối nhiều loại VIM — OpenVIM, OpenStack, VMware, AWS — và nhiều SDN Controller — OpenDaylight, ONOS, Floodlight) cùng một VNFM phổ thông, hỗ trợ kết nối tới VNFM đặc biệt riêng nếu cần. OSM cung cấp sẵn VIM riêng là OpenVIM, đồng thời tương thích các VIM khác kể cả nền tảng đám mây công cộng như AWS — mở đường cho các giải pháp NFV chạy trên Hybrid Cloud.

Tại thời điểm khảo sát (OSM 2.0), tài liệu hướng dẫn chưa thật đầy đủ, và yêu cầu phần cứng khá cao so với các lựa chọn khác:

Phần cứng	Yêu cầu (OSM 2.0, 2017)
Số node	Tối thiểu 1 node
CPU	Tối thiểu 4 CPU hỗ trợ ảo hóa
RAM	Tối thiểu 16GB
Disk	Tối thiểu 40GB HDD
Network	Tối thiểu 1 card mạng có kết nối Internet

Đây là con số nêu ở bản gốc — vốn cũng chưa tính đến phần hạ tầng ảo hóa riêng (thường chiếm nhiều tài nguyên hơn hẳn). Vì vậy nhóm tác giả quyết định không dùng OSM cho phần thử nghiệm năm 2017.

⚠️ Cập nhật hiện trạng (2026): đây là thay đổi lớn nhất so với năm 2017 — OSM hiện đã ở Release NINETEEN (2025), sau một chặng đường phát triển rất dài từ bản 2.0. ETSI duy trì nhịp phát hành đều đặn hai bản mỗi năm, có cả bản Long-Term-Support (LTS, gần nhất là Release EIGHTEEN, 9/2025); codebase đã hiện đại hóa toàn diện — Python 3.13, Angular mới cho GUI, cài đặt dạng Helm chart hợp nhất trên Kubernetes, hỗ trợ mô hình "Applications" khai báo (declarative) thay vì chỉ VNF/NS truyền thống. OSM ngày nay được xem là giải pháp MANO mã nguồn mở trưởng thành và phổ biến nhất, khác hẳn hình ảnh "còn sơ khai" mà bản gốc ghi nhận năm 2017.

Tacker

Dự án chính thức của OpenStack đảm nhiệm vai trò MANO trong kiến trúc NFV, tuân theo kiến trúc MANO chuẩn ETSI, cung cấp một NFVO và một trình quản lý phổ thông cho VNF. Bản phát hành Ocata (khi đó là bản OpenStack mới nhất) đã cho Tacker khả năng triển khai và điều phối dịch vụ mạng đầu cuối hoàn chỉnh — dù dự án vẫn còn non trẻ, phiên bản khi đó mới ở mức 0.7.

Tacker gồm các thành phần chính: NFVO (điều phối hệ thống — quản lý VIM Instance, Network Service Instance, VNF Forwarding Graph); VNFM (quản lý vòng đời VNF Instance — khởi tạo/cập nhật/xóa, cấu hình, tự sửa lỗi, co giãn); NFV Catalog (tập tin mô tả để khởi tạo VNF/NS/VNFFG); và các API kết nối dashboard (Horizon) cùng CLI quản trị. Tacker dùng Heat và Keystone để kết nối xuống hạ tầng ảo hóa (Nova, Neutron,...).

Quy trình khởi chạy một VNF của Tacker: quản trị viên chọn VNFD từ VNFD Catalog → NFVO đọc đặc tả, chuyển yêu cầu sang Heat → Heat cấp phát tài nguyên ảo hóa thành VM → Management driver giám sát quá trình khởi tạo VNF → SFC driver điều khiển khởi tạo VNFFG giữa các VNF (gọi Neutron-SFC để nối các VM thành Port Chain, xử lý luồng dữ liệu theo Flow Classifier định nghĩa trong VNFFGD) → Monitor driver giám sát VNF vừa khởi tạo (có thể kết hợp Ceilometer) → khi có sự cố/nhu cầu mở rộng, monitor driver báo lại cho infra driver xử lý (scale up, respawn).

Tại thời điểm khảo sát, Tacker mới chỉ tương tác được với VIM là OpenStack; khả năng cài Tacker độc lập để triển khai multi-site VIM còn chưa ổn định, và khả năng tương thích với các trình quản lý SDN ngoài (như OpenDaylight) vẫn còn hạn chế.

⚠️ Cập nhật hiện trạng (2026): Tacker là dự án duy nhất trong ba lựa chọn vẫn phát triển tích cực liên tục cho tới nay, theo đúng nhịp release của OpenStack (gần nhất: 2025.1, 2025.2). Thay đổi kỹ thuật đáng chú ý nhất: Tacker hiện đã hỗ trợ Kubernetes làm một loại VIM bên cạnh OpenStack — nghĩa là VNF/CNF giờ có thể được điều phối chạy trên cả VM lẫn container, khác hẳn giới hạn "chỉ OpenStack" mà bản gốc ghi nhận năm 2017.

So sánh ba giải pháp MANO tại thời điểm khảo sát (2017):

Giải pháp	VIM hỗ trợ	Ưu điểm	Khuyết điểm
OpenBaton 3.0	OpenStack, hỗ trợ viết plugin VIM riêng	Tài liệu rõ ràng, yêu cầu phần cứng thấp, hỗ trợ phát triển VNFM/NFVO riêng dựa trên thư viện có sẵn	Thiếu ổn định, còn nhiều lỗi, chức năng còn ít
Open Source MANO 2.0	AWS, VMware, OpenStack, OpenVIM	Hỗ trợ kết hợp public cloud (AWS), hỗ trợ nhiều loại VIM/SDN Controller	Còn sơ khai, thiếu tính năng; yêu cầu phần cứng khá cao
Tacker 0.7.0 (Ocata)	OpenStack	Yêu cầu phần cứng chấp nhận được, tài liệu tương đối rõ ràng, tương thích tốt với OpenStack, hỗ trợ đầy đủ VNFD/VNFFGD/NSD	Chỉ hỗ trợ OpenStack làm VIM, kết nối với SDN Controller còn chưa tốt

Qua khảo sát, nhóm tác giả chọn OpenBaton và Tacker để tiến hành triển khai thử nghiệm (Mục 9), dùng chung nền NFVI/VIM là OpenStack.

---

9. Case study 2017: Triển khai thử nghiệm hệ thống NFV

📌 Đây là case study lịch sử. Toàn bộ Mục 9 và Mục 10 ghi lại nguyên trạng những gì nhóm tác giả (Trần Thành Công, Nguyễn Đức Duy) đã tự tay triển khai và đo đạc trong khóa luận tốt nghiệp năm 2017 — số node, địa chỉ IP, phiên bản phần mềm đều giữ nguyên như bản gốc, không được cập nhật theo hiện trạng 2026 của các dự án liên quan (xem hiện trạng cập nhật ở Mục 8). Mục đích giữ nguyên là để tài liệu này còn giá trị tham khảo về cách một hệ thống NFV thật được lắp ráp từ các khối lý thuyết ở Mục 5–7, chứ không nhằm hướng dẫn triển khai theo đúng phiên bản này ở thời điểm hiện tại.

9.1. Thử nghiệm với OpenBaton

Tại thời điểm Release 3.0, OpenBaton mới chỉ hỗ trợ một VIM duy nhất là OpenStack, nên mô hình thử nghiệm gồm:

• OpenStack phiên bản Ocata (2 node): Controller (Compute Server, Network Server, Glance Server, Heat Server, Ceilometer Server) và Compute (OpenvSwitch Agent, Nova compute agent, Neutron-OVS Agent).
• OpenBaton phiên bản 3.2.0 (1 node).

Hai node Controller/Compute của OpenStack quản lý tài nguyên ảo hóa (CPU, RAM, network) và cấp cho OpenBaton sử dụng; OpenBaton khởi tạo VNF/NS dựa trên nền hạ tầng đó. Mô hình mạng dùng self-service Layer 3.

Kết quả: nhóm triển khai thành công mô hình OpenStack kết hợp OpenBaton và khởi tạo được các network service demo qua giao diện quản lý của OpenBaton.

Nhận xét của nhóm tác giả (2017):

Ưu điểm	Khuyết điểm
Dễ cài đặt mô hình thử nghiệm	Độ ổn định chưa cao
Yêu cầu phần cứng đơn giản	Chưa hỗ trợ tập tin đặc tả VNFFGD
Tài liệu hướng dẫn rõ ràng	Khả năng phát triển NS/VNF riêng còn khó khăn

9.2. Thử nghiệm với Tacker

Tacker tại thời điểm khảo sát cũng chỉ hỗ trợ một VIM duy nhất là OpenStack. Mô hình thử nghiệm dùng OpenStack Ocata, trải trên 2 site:

• Site 1 — OpenStack Ocata (4 node): 1 Controller Node (Compute, Network với networking-sfc, Glance, Tacker, Heat, Ceilometer, Mistral, Cinder), 2 Compute Node (OpenvSwitch Agent, Nova compute Agent, Neutron-OVS Agent), 1 Storage Node (Cinder-Volume).
• Site 2 — DevStack All-in-one (1 node): rút gọn nhưng vẫn đủ dịch vụ cần thiết (Nova, Neutron với networking-sfc, Glance, Heat, Ceilometer).

Controller node ở Site 1 được cài thêm Tacker (VNFM + NFVO), trở thành khối MANO đầy đủ điều khiển hạ tầng ảo hóa ở cả hai site.

Kết quả: nhóm triển khai thành công mô hình OpenStack dùng Tacker làm MANO, và triển khai thử nghiệm được các VNF demo qua Tacker.

Nhận xét của nhóm tác giả (2017):

Ưu điểm	Khuyết điểm
Tài liệu hướng dẫn khá chi tiết	Độ ổn định chưa cao
Yêu cầu phần cứng chấp nhận được	Cài đặt Tacker độc lập thành node MANO riêng còn chưa ổn định
Hỗ trợ đầy đủ VNFFGD và NSD (NSD chỉ có ở bản OpenStack Ocata)	Vẫn còn xuất hiện nhiều lỗi khi vận hành

9.3. So sánh và lựa chọn

OpenBaton tương đối đơn giản, dễ cài, nhưng lượng tính năng, độ ổn định và khả năng tùy biến VNF/VNFFG/NS chưa cao. Tacker tuy cũng còn non trẻ nhưng tương thích tốt hơn với hạ tầng OpenStack sẵn có, khả năng mở rộng qua API nguồn mở cao hơn, và hỗ trợ tùy biến VNF/VNFFG/NS tốt hơn. Vì vậy nhóm tác giả quyết định dùng Tacker để tiếp tục triển khai dịch vụ mạng thử nghiệm ở phần tiếp theo.

9.4. Triển khai VNF thực tế: vIMS và VNF Forwarding Graph

Sau khi có hệ thống NFV hoàn chỉnh (Tacker + OpenStack), nhóm tác giả đề xuất áp dụng vào hai tình huống thực tế tại Việt Nam thời điểm đó:

Trường hợp 1 — Khó triển khai dịch vụ mạng phức tạp như IMS: IMS (IP Multimedia Subsystem) là kiến trúc mạng hỗ trợ nhiều phương thức truy cập (vô tuyến lẫn hữu tuyến) dùng giao thức IP, phục vụ được nhiều dịch vụ viễn thông (gọi thoại, fax, email, Web,...). Triển khai IMS truyền thống đòi hỏi phần cứng chuyên biệt, kiến trúc phức tạp cùng các hệ thống đi kèm (quản lý cước, giám sát) — khiến các đơn vị không chuyên về viễn thông (doanh nghiệp nhỏ, trường đại học) khó tự triển khai một hệ thống nội bộ.

Đề xuất: đóng gói sẵn một dịch vụ vIMS mẫu thành tập tin đặc tả — quản trị viên chỉ cần dùng VNFD tương ứng là triển khai nhanh được một hệ thống IMS đầy đủ tính năng gọi thoại/gọi video. Nhóm dùng Project Clearwater để demo — kiến trúc IMS nói chung khá phức tạp, nhưng khi đã đóng gói thành template mẫu, việc triển khai trở nên đơn giản hơn nhiều.

⚠️ Cập nhật hiện trạng (2026): Metaswitch (chủ sở hữu Project Clearwater) đã ngừng hỗ trợ chính thức dự án này từ 1/12/2019. Mã nguồn vẫn còn công khai trên GitHub cho cộng đồng tham khảo, nhưng không còn được phát triển tiếp — sản phẩm thương mại kế thừa của Metaswitch là Clearwater Core vẫn tiếp tục hoạt động độc lập.

Đồ hình mạng demo vIMS:

Kết quả: nhóm triển khai thành công VNF vIMS Clearwater qua dashboard, hai người dùng đăng ký tài khoản (ID 6505550148 và 6505550381) trên phần mềm VoIP client Jitsi, và thực hiện được cuộc gọi video giữa hai tài khoản — xác nhận luồng end-to-end của một dịch vụ mạng phức tạp có thể triển khai nhanh qua NFV.

Trường hợp 2 — Quản trị hạ tầng mạng của đơn vị nhỏ/vừa: các đơn vị không chuyên viễn thông (doanh nghiệp nhỏ, đơn vị hành chính/giáo dục như trường Đại học Khoa học Tự nhiên) thường phải đầu tư/thay thế thiết bị mạng đắt đỏ định kỳ, khả năng co giãn quy mô dịch vụ hạn chế — quá tải giờ cao điểm, lãng phí điện năng giờ thấp điểm — và bất kỳ thay đổi thiết bị nào cũng có nguy cơ ảnh hưởng toàn bộ dịch vụ đang chạy.

Đề xuất: (1) tận dụng phần cứng phổ thông cũ để dựng một hệ thống NFV hoàn chỉnh, vừa tiết kiệm đầu tư vừa chủ động giấy phép phần mềm — hạ tầng ảo hóa này còn tận dụng được cho các nhu cầu khác (lưu trữ, tính toán tập trung); (2) ứng dụng VNF Forwarding Graph để linh hoạt điều chỉnh luồng dữ liệu — thêm/bớt/điều chỉnh theo chính sách để ứng phó nhanh khi có sự cố (DDoS, thiết bị nhiễm mã độc, hỏng phần cứng).

Demo dùng VNF chạy OpenWRT (hệ điều hành mã nguồn mở, tùy biến cao, đóng vai trò router ảo) — hai VNF này được tạo tự động qua VNFD, sau đó nối chuỗi thành dịch vụ mạng phức tạp hơn bằng VNF Forwarding Graph. Luồng dữ liệu người dùng từ máy Source tới máy Dest bị buộc phải đi qua các VNF OpenWRT và chịu các rule được cấu hình sẵn trên đó:

Kiểm chứng qua traceroute: trước khi tạo VNFFG, traceroute từ Source tới Dest chỉ đi qua router trung gian giữa hai mạng.

$ traceroute 192.168.100.115
# Output minh họa — trước khi tạo VNFFG
traceroute to 192.168.100.115, 30 hops max
 1  10.0.10.1 (10.0.10.1)  0.412 ms
 2  192.168.100.115 (192.168.100.115)  1.203 ms

(Output minh họa — cấu trúc đúng theo traceroute thật, số liệu cụ thể chỉ mang tính minh họa; bản gốc không đính kèm output số liệu chi tiết.)

Sau khi tạo VNFFG1 (mapping VNFD của VNF1, VNF2 vào VNFFGD, với rule: gói UDP từ Dest phải đi qua Forwarder VNF1 → VNF2), traceroute lại từ Source tới Dest cho thấy gói tin buộc phải đi qua VNF1 và VNF2 trước khi đến Dest:

$ traceroute 192.168.100.115
# Output minh họa — sau khi tạo VNFFG1
traceroute to 192.168.100.115, 30 hops max
 1  10.0.10.115 (10.0.10.115)  0.389 ms   [VNF1]
 2  10.0.10.111 (10.0.10.111)  0.671 ms   [VNF2]
 3  10.0.10.1 (10.0.10.1)  0.933 ms
 4  192.168.100.115 (192.168.100.115)  1.548 ms

(Output minh họa — cấu trúc đúng theo traceroute thật, số liệu cụ thể chỉ mang tính minh họa.)

Nội dung VNFFGD của VNFFG1 (tập tin đặc tả dùng để tạo VNFFG ở bước trên), rút gọn theo mô tả gốc:

# VNFFGD của VNFFG1 — cấu trúc minh họa theo mô tả gốc của tài liệu
vnffgd:
  name: VNFFG1
  forwarding_paths:
    - path: [VNF1, VNF2]        # Forwarder theo đúng thứ tự
      classifier:
        ip_proto: 17             # UDP
        source: Dest             # traffic từ máy Dest

(Cấu trúc minh họa dựa theo mô tả gốc: VNFFGD ánh xạ tên VNFD của VNF1/VNF2 làm Forwarder, Flow Classifier lọc gói UDP — IP Protocol 17 — theo Source Port ID của máy Dest.)

Trong Tacker Dashboard, nhóm tác giả lần lượt thực hiện các thao tác: tạo VNF vIMS Clearwater từ dashboard, đăng ký tài khoản người dùng tại tổng đài vIMS, thực hiện cuộc gọi video giữa hai tài khoản, xem thông tin chi tiết VNF1/VNF2, xác nhận VNF OpenWRT đã bật rule forward gói tin, rồi tạo VNFFG1. Tóm tắt lại các bước thao tác và kết quả quan sát được (nguyên bản là ảnh chụp màn hình Tacker Dashboard, không còn giữ được trong quá trình chuyển tài liệu — mô tả lại theo đúng trình tự và nội dung ghi nhận trong bản gốc):

Kết quả này xác nhận đúng cơ chế Service Chaining đã trình bày ở Mục 7.3: đường đi của gói tin bị "ép" đi qua đúng thứ tự VNF theo rule định nghĩa trước — hoàn toàn không cần đấu lại dây vật lý nào, chỉ bằng thao tác cấu hình VNFFGD.

---

10. Case study 2017: Công cụ giám sát hệ thống NFV tự phát triển

📌 Vẫn thuộc case study 2017 — cùng lưu ý như Mục 9: giữ nguyên nội dung gốc, không cập nhật theo hiện trạng hiện tại của Tacker/Ceilometer.

10.1. Thực trạng

Tại thời điểm khảo sát, hệ thống theo dõi (monitoring) đi kèm Tacker vẫn còn ở giai đoạn sơ khai — dù đã điều khiển luồng và khởi tạo VNF khá tốt, việc theo dõi chỉ dừng ở kỹ thuật heartbeat đơn giản: biết VNF/VIM còn sống hay không. Giao diện quản lý VIM chỉ hiển thị các event cơ bản (CREATE khi đăng ký VIM, MONITOR khi hệ thống ổn định, ERROR khi báo lỗi); giao diện VNF Manager cũng tương tự — chỉ có trạng thái ACTIVE/ERROR và IP quản lý. Không có thông tin chi tiết hơn về tài nguyên (CPU/RAM/network) đang tiêu thụ ra sao.

Việc thiếu tính năng giám sát chuyên sâu khiến quản trị viên gặp khó khi cần lên kế hoạch tài nguyên hoặc phát hiện sớm sự cố. Vì vậy nhóm tác giả tự phát triển một công cụ giám sát bổ sung cho Tacker, tận dụng API sẵn có từ các dự án khác trong hệ sinh thái OpenStack.

10.2. Kiến trúc

Công cụ tích hợp với Horizon (dashboard OpenStack) để hiển thị thông tin qua đồ thị thời gian thực, giúp quản trị viên có cái nhìn trực quan hơn thay vì chỉ đọc trạng thái ACTIVE/ERROR. Phạm vi ban đầu tập trung vào: lượng vCPU/RAM/Disk khả dụng của VIM, lưu lượng mạng vào/ra và tốc độ truyền gói tin của từng VNF — kiến trúc có thể mở rộng thêm (số gói lỗi/hủy, tốc độ đọc/ghi ổ cứng,...).

Quy trình theo dõi VNF: dựa trên API của Tacker, công cụ lấy stack_id của VNF → thông qua Heat, lần lượt lấy resource_id và instance_id (Nova) cũng như port_id (Neutron) → dựa trên các ID này, gửi request tới Ceilometer để lấy các chỉ số Network.incoming.bytes, Network.outgoing.bytes, cpu_util, memory.usage của VNF đó.

Quy trình theo dõi VIM: vì một hệ thống NFV thực tế thường có nhiều site ở nhiều vị trí địa lý khác nhau, công cụ cần quản lý tập trung các VIM này. Nhóm dựa trên API sẵn có của Tacker để lấy auth_url, user/password, project_name của từng VIM, rồi từ đó truy xuất thông tin hệ thống của từng site (số vCPU, dung lượng bộ nhớ, dung lượng đĩa hiện tại). Nắm được thông tin này giúp quản trị viên lên kế hoạch cấp phát tài nguyên và chọn vị trí phù hợp nhất khi khởi tạo VNF mới.

10.3. Kết quả

Nhóm xây dựng thành công công cụ giám sát với kiến trúc trên, thể hiện được thông tin lưu lượng mạng của VNF theo thời gian thực — biểu đồ cho biết thông lượng đang chạy qua từng VNF/nhóm VNF tại nhiều thời điểm khác nhau. Công cụ hoàn toàn có thể mở rộng để phục vụ các use case như vCPE, vRAN,... — nhà cung cấp Internet theo dõi được tốc độ sử dụng thực tế và lượng dữ liệu tiêu thụ của người dùng, từ đó quản lý chất lượng dịch vụ và tính cước tốt hơn. Trình theo dõi VIM giúp việc quản lý tài nguyên các VNF dễ dàng và tiện lợi hơn, đặc biệt hữu ích với hệ thống NFV có nhiều VIM ở các vùng địa lý khác nhau.

Giao diện gốc gồm hai nhóm màn hình chính trên Horizon (ảnh chụp gốc không còn giữ được, tóm tắt lại nội dung từng màn hình theo bản gốc):

---

11. Tổng kết và nhìn lại

11.1. Kết quả đạt được (2017)

Về lý thuyết, nhóm tác giả đã hệ thống hóa được: tổng quan công nghệ NFV, quá trình phát triển, kiến trúc, lợi ích, use case và tiềm năng ứng dụng tại Việt Nam; mối liên hệ giữa SDN và NFV; khảo sát và đánh giá các giải pháp NFV thời điểm đó (OpenStack, OPNFV, Tacker, Open Source MANO, OpenBaton).

Về triển khai thực nghiệm: xây dựng thành công hạ tầng NFV trên nền OpenStack; thử nghiệm hai mô hình MANO khác nhau (OpenBaton, Tacker); triển khai dịch vụ mạng vIMS; triển khai use case VNF Forwarding Graph; phát triển plugin giao diện giám sát VIM/VNF cho Tacker.

11.2. Hướng phát triển đề xuất (2017)

Nhóm tác giả đề ra bốn hướng mở rộng cho đề tài: nghiên cứu sâu hơn các công nghệ tối ưu hiệu năng của NFVI (DPDK, SR-IOV, Huge Pages, CPU Pinning); triển khai thử nghiệm NFV kết hợp SDN; ứng dụng công nghệ Container vào triển khai VNF; và phát triển Portal quản lý/triển khai dịch vụ mạng qua GUI kéo-thả.

11.3. Nhìn lại sau gần một thập kỷ

Điều thú vị khi đọc lại khóa luận này ở thời điểm hiện tại: hướng phát triển thứ ba mà nhóm tác giả đề xuất năm 2017 — "ứng dụng công nghệ Container vào việc triển khai các VNF" — chính xác là con đường mà toàn ngành NFV đã đi theo trong những năm sau đó.

Khái niệm VNF trong toàn bộ tài liệu này gắn liền với máy ảo (VM): mỗi VNF là một VM chạy phần mềm thực hiện chức năng mạng. Từ khoảng 2018 trở đi, cùng với sự trưởng thành của Kubernetes trong giới hạ tầng viễn thông, ngành xuất hiện thêm khái niệm CNF (Cloud-native Network Function) — cùng một chức năng mạng đó, nhưng đóng gói chạy trong container thay vì VM, thường được điều phối bằng Kubernetes thay vì (hoặc song song với) OpenStack. Theo cách ETSI phân loại, CNF không phải một khái niệm tách biệt khỏi VNF, mà là "một dạng đặc biệt của VNF" — vẫn được điều phối qua kiến trúc NFV MANO và các descriptor công nghệ-trung lập (TOSCA, YANG) đã trình bày ở Mục 5.6, chỉ khác runtime bên dưới là container thay vì VM.

Tacker — MANO nhóm tác giả chọn dùng năm 2017 — là minh chứng rõ nhất cho xu hướng này: như đã cập nhật ở Mục 8.2, Tacker giờ hỗ trợ Kubernetes làm một loại VIM song song với OpenStack, nghĩa là cùng một MANO có thể điều phối cả VNF chạy VM lẫn CNF chạy container. Đây cũng chính là cách đọc hợp lý nhất cho khóa luận này ở thời điểm hiện tại: phần kiến trúc ETSI (Mục 5), quan hệ NFV–SDN (Mục 6) và các ứng dụng thực tiễn (Mục 7) vẫn là nền tảng khái niệm không đổi; phần công nghệ cụ thể (Mục 8–10) nên được đọc như một lát cắt lịch sử của năm 2017, đối chiếu với các ghi chú cập nhật hiện trạng đã chèn xuyên suốt bài để biết công nghệ nào còn sống, công nghệ nào đã lùi vào lịch sử.

---

12. Phụ lục: Alarm Framework và Monitor Driver của Tacker

12.1. Alarm monitoring framework của Tacker

Tacker có sẵn một framework theo dõi VNF dựa trên cơ chế alarm-trigger, xây trên nền monitor driver của Tacker. Để dùng tính năng này, cần khai báo thêm mục policies trong VNFD trước khi khởi tạo VNF.

# Cấu hình alarm-trigger trong VNFD — minh họa cấu trúc, dựa theo mô tả gốc của tài liệu
vdu1:
  monitoring_policy:
    cpu_util:
      alarm_actions:
        alarm: respawn
      properties:
        threshold: 50
        period: 65     # giây

(Cấu trúc field minh họa theo mô tả gốc: alarm này tạo lại máy ảo — respawn — khi CPU sử dụng vượt 50% trong vòng 65 giây liên tục.)

Alarm framework của Tacker hỗ trợ các hành động: scaling, log, respawn, log_and_kill — quản trị viên tùy chọn hành động này trong tập tin TOSCA ứng với từng điều kiện cụ thể. Dù chưa hoàn chỉnh ở thời điểm khảo sát, framework này có khả năng ứng dụng cao nhờ cơ chế kích hoạt tự động theo policy.

12.2. Viết một monitor driver mới cho Tacker

Tacker cho phép người dùng tự phát triển thêm driver riêng để theo dõi trạng thái VNF trong quá trình triển khai. Để viết một module theo dõi mới, cần kế thừa lớp mẫu:

tacker.vnfm.monitor_drivers.abstract_driver.VNFMonitorAbstractDriver

Lớp này định nghĩa các hàm cơ bản cần override khi viết driver mới:

Hàm	Vai trò
get_type(self)	Trả về loại của monitor driver (ví dụ: ping)
get_name(self)	Trả về tên plugin
get_description(self)	Trả về mô tả của driver
monitor_get_config(self, plugin, context, vnf)	Trả về cấu hình driver dưới dạng dictionary Python
monitor_url(self, plugin, context, vnf)	Trả về URL dùng để theo dõi VNF
monitor_call(self, vnf, kwargs)	Trả về True nếu VNF hoạt động tốt, hoặc failure/calls-capacity-reached nếu có lỗi

Ví dụ driver có sẵn — ping — được đăng ký như sau:

[tacker.tacker.monitor_drivers]
ping = tacker.vnfm.monitor_drivers.ping.ping:VNFMonitorPing

Nếu monitor_call trả về kết quả khác True, kết quả đó cần được nối với một hành động cụ thể trong file cấu hình TOSCA của VNFD, ví dụ:

vdu1:
  monitoring_policy:
    ping:
      actions:
        failure: respawn

Trong ví dụ này, vdu1 dùng driver theo dõi ping; khi monitor_call trả về sự kiện failure, Tacker sẽ tự động respawn lại vdu1. Một ví dụ khác, dùng driver http-ping với tham số cấu hình riêng:

vdu2:
  monitoring_policy:
    http-ping:
      monitoring_params:
        port: 8080
        url: ping.cgi
      actions:
        failure: respawn

Ở đây, vdu2 dùng http-ping — ngoài hành động respawn khi thất bại giống ví dụ trên, driver này còn cấu hình thêm tham số theo dõi riêng (port, url) để xác định chính xác endpoint cần kiểm tra sức khỏe của VNF.

---

Xem lại Phần 1: Kiến trúc và lý thuyết nền tảng.

---

Nguồn tham khảo

Nguồn gốc: Nội dung kỹ thuật cốt lõi (kiến trúc ETSI NFV, các giải pháp triển khai, case study thực nghiệm) được biên tập lại từ khóa luận tốt nghiệp cử nhân CNTT "Tìm hiểu NFV và triển khai hệ thống thử nghiệm" — Trần Thành Công (1312057) và Nguyễn Đức Duy (1312084), GVHD: ThS. Lê Ngọc Sơn, Bộ môn Mạng máy tính và Viễn thông, Khoa Công nghệ Thông tin, Trường Đại học Khoa học Tự nhiên TP.HCM, 2017. Các claim đã lỗi thời được đối chiếu và cập nhật theo nguồn dưới đây.

• OpenBaton (tổ chức GitHub openbaton) không còn hoạt động tích cực — phần lớn repository lõi không có commit mới kể từ 2019–2020 — 2026, GitHub: openbaton.
• Tacker vẫn đang phát triển tích cực theo nhịp release OpenStack (2025.1, 2025.2) và đã có đặc tả hỗ trợ Kubernetes làm VIM bên cạnh OpenStack — 2025, OpenStack Tacker Specifications, Kubernetes as VIM in Tacker.
• ETSI Open Source MANO đã phát hành tới Release NINETEEN (2025), với Release EIGHTEEN (9/2025) là bản Long-Term-Support gần nhất — xa hình ảnh "còn sơ khai ở bản 2.0" mà bản gốc ghi nhận năm 2017 — 2025, ETSI: OSM Release EIGHTEEN, ETSI: OSM Release NINETEEN.
• OPNFV phát hành bản cuối cùng dưới tên riêng cuối 2020, sáp nhập với CNTT thành dự án Anuket dưới LF Networking từ đầu 2021 — LF Networking: LF Networking Launches Anuket.
• Metaswitch ngừng hỗ trợ chính thức Project Clearwater từ 1/12/2019; mã nguồn vẫn công khai trên GitHub nhưng không còn phát triển tiếp — Project Clearwater Documentation.
• CNF (Cloud-native Network Function) là một dạng đặc biệt của VNF theo phân loại ETSI, chạy trên container/Kubernetes thay vì VM nhưng vẫn được điều phối qua kiến trúc NFV MANO và descriptor công nghệ-trung lập (TOSCA, YANG) — IEEE ComSoc: ETSI NFV evolution, containers, kubernetes, and cloud-native virtualization initiatives, Red Hat: VNF and CNF, what's the difference?.