NFV — Network Functions Virtualization (Phần 1): Kiến trúc và lý thuyết nền tảng
Mục lục
- 1. Vì sao ngành viễn thông cần đến NFV?
- 2. NFV là gì?
- 3. Lợi ích NFV mang lại
- 4. NFV ra đời và chuẩn hóa như thế nào?
- 5. Kiến trúc NFV theo chuẩn ETSI
- 6. NFV và SDN
Bài viết gồm 2 phần. Phần 1 (dưới đây) trình bày lý do NFV ra đời, khái niệm, kiến trúc ETSI và quan hệ NFV–SDN. Phần 2 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: NFV — Network Functions Virtualization (Phần 2).
1. Vì sao ngành viễn thông cần đến NFV?
Hình dung bạn là kỹ sư mạng tại một nhà cung cấp dịch vụ Internet. Một khách hàng doanh nghiệp gọi điện, yêu cầu triển khai gấp một firewall chuyên dụng cho chi nhánh mới — hợp đồng chỉ kéo dài 3 tháng. Theo quy trình truyền thống, bạn phải: xác định thiết bị phù hợp, đặt hàng, chờ giao (có khi vài tuần), lắp đặt, đấu dây, cấu hình, kiểm thử — rồi mới đưa vào vận hành. Ba tháng sau, hợp đồng kết thúc, thiết bị đắt tiền đó lại nằm kho.
Đây không phải tình huống hiếm. Giai đoạn 2015–2020, lưu lượng Internet toàn cầu được dự báo tăng từ 10GB lên 25GB/người/tháng, có thể chạm mốc 2.3 zettabyte vào năm 2020, còn tốc độ băng thông rộng gần như tăng gấp đôi (theo Cisco Visual Networking Index 2015–2020). Tại Việt Nam, thời điểm đó Viettel cũng bắt đầu triển khai 4G trên diện rộng — kéo theo áp lực xây mới hạ tầng bên dưới. Nhu cầu tăng nhanh hơn tốc độ nhà mạng có thể mua sắm và lắp đặt thiết bị chuyên dụng.
Cách làm truyền thống — mỗi dịch vụ mạng gắn với một thiết bị phần cứng chuyên dụng của một hãng (Cisco, Juniper,...) — bộc lộ rõ những bất cập:
- Chi phí đắt đỏ: mỗi chức năng (firewall, NAT, IDS, DNS,...) cần một thiết bị riêng, giá thành cao và gắn chặt với giấy phép phần mềm của từng hãng.
- Thời gian triển khai lâu: quy trình mua sắm → lắp đặt → đấu dây → cấu hình → kiểm thử → vận hành có thể mất vài ngày đến vài tuần, trong khi có dự án chỉ cần dùng vài giờ.
- Quản trị khó khăn và kém tương thích: thiết bị của hãng này khó nói chuyện với thiết bị hãng khác, quản lý tập trung gần như bất khả thi.
- Khó mở rộng/thu hẹp dịch vụ: muốn tăng công suất phải mua thêm thiết bị vật lý; muốn thu hẹp thì thiết bị dư thừa vẫn nằm đó, tốn điện, tốn không gian.
💡 Hình dung như thế này: Cách tiếp cận truyền thống giống việc mỗi lần cần một công cụ mới trong nhà (khoan, cưa, máy hút bụi...) bạn phải mua hẳn một cái tủ đồ nghề chuyên dụng mới, đặt cố định trong một góc nhà riêng cho nó. NFV giống việc thay toàn bộ tủ đồ nghề chuyên dụng đó bằng một chiếc máy tính đa năng, nơi "khoan" hay "cưa" chỉ còn là một phần mềm cài vào — cần dùng thì cài, hết nhu cầu thì gỡ, không phải xây thêm góc nhà nào cả.
Giải pháp mà ngành viễn thông đi tới chính là ảo hóa các chức năng mạng — tách rời phần mềm điều khiển ra khỏi phần cứng chuyên dụng, để chạy trên các máy chủ, switch và thiết bị lưu trữ phổ thông. Đó là ý tưởng cốt lõi đằng sau NFV (Network Function Virtualization), chủ đề chính của tài liệu này.
2. NFV là gì?
Network Functions Virtualization (NFV) là công nghệ ứng dụng ảo hóa và điện toán đám mây vào các máy chủ, thiết bị mạng phổ thông, nhằm tạo ra môi trường để chạy các hàm chức năng mạng ảo hóa — gọi tắt là VNF (Virtualised Network Function) — như switching, firewall, routing, load balancing,... VNF thực hiện đúng những chức năng mà thiết bị mạng vật lý truyền thống từng đảm nhiệm, chỉ khác là chạy dưới dạng phần mềm trên máy ảo.
Theo cách tiếp cận truyền thống, mỗi chức năng mạng do một hoặc vài thiết bị vật lý chuyên dụng đảm nhận: hiệu năng cao vì thiết bị chỉ làm đúng một việc, nhưng đổi lại triển khai, vận hành, mở rộng đều phức tạp. NFV đảo ngược đánh đổi đó — chấp nhận hiệu năng phần cứng phổ thông thấp hơn một chút để đổi lấy sự linh hoạt gần như tuyệt đối.
Bảng dưới so sánh trực tiếp hai cách tiếp cận trên các tiêu chí mà một nhà cung cấp dịch vụ thực sự quan tâm:
| Tiêu chí so sánh | Hạ tầng mạng truyền thống | Ứng dụng NFV |
|---|---|---|
| Chi phí phần cứng | Cao — mua trọn gói giải pháp từng hãng | Thấp — chỉ dùng phần cứng phổ thông, chủ động phần mềm |
| Tùy biến, nâng cấp phần cứng | Khó — phụ thuộc hãng, thường phải thay cả cụm | Dễ — chỉ là thiết bị phổ thông |
| Tùy biến, quản trị phần mềm | Thấp — phụ thuộc tài nguyên & hãng sản xuất | Cao — cơ chế nguồn mở, nhiều nhà cung cấp phần mềm |
| Điều khiển luồng traffic | Khó, phức tạp nếu trộn nhiều hãng | Dễ, linh động — đặc biệt khi kết hợp SDN (Mục 6) |
| Hệ sinh thái | Nhỏ, bó buộc theo từng hãng | Rộng — tương tác qua chuẩn giao tiếp chung do ETSI đặt ra |
| Hiệu năng, độ ổn định | Cao — thiết bị thiết kế chuyên biệt | Thấp hơn ban đầu, cải thiện dần theo thời gian (xem Mục 5.4) |
| Hỗ trợ kỹ thuật | Cao — đi kèm gói hỗ trợ chính hãng | Thấp hơn với giải pháp nguồn mở; thị trường thương mại còn non trẻ |
| Đào tạo nhân sự | Lệ thuộc khóa học riêng từng hãng | Dễ tiếp cận tài liệu, mã nguồn mở |
Điểm yếu lớn nhất của NFV nằm ở dòng hiệu năng: phần cứng phổ thông vốn không được thiết kế riêng cho tác vụ mạng đặc thù, nên xử lý gói tin chậm hơn ASIC/NPU chuyên dụng. Mục 5.4 sẽ giới thiệu các kỹ thuật (DPDK, SR-IOV, PCI-Passthrough) ra đời để thu hẹp khoảng cách này.
3. Lợi ích NFV mang lại
Từ những gì vừa phân tích, năm lợi ích cốt lõi mà NFV mang lại là:
- Tiết kiệm chi phí đầu tư và vận hành: dùng phần cứng phổ thông, chủ động mã nguồn phần mềm, giảm phụ thuộc chi phí bản quyền thiết bị chuyên dụng.
- Triển khai dịch vụ nhanh chóng: cài đặt, thử nghiệm, đưa dịch vụ ra thị trường trong thời gian ngắn hơn nhiều so với quy trình mua sắm phần cứng truyền thống.
- Tận dụng tối đa hạ tầng phần cứng: một hạ tầng vật lý có thể chứa nhiều hạ tầng ảo bên trên, phục vụ nhiều khách hàng, đồng thời dựng được môi trường thử nghiệm/đào tạo song song với môi trường production.
- Đơn giản hóa quản trị: qua API, template cấu hình mẫu, script tự động — quản trị viên kiểm soát tài nguyên tập trung, giảm sai sót thủ công.
- Linh hoạt theo nhu cầu khách hàng: co giãn dịch vụ theo tải thực tế — mở rộng khi cao điểm, thu hẹp khi thấp điểm để tiết kiệm tài nguyên và điện năng.
Một khảo sát của ADVA năm 2016 định lượng khá rõ lợi ích chi phí này khi doanh nghiệp chuyển sang NFV — chủ yếu đến từ việc cắt giảm CAPEX phần cứng chuyên dụng và OPEX vận hành/bảo trì so với mô hình truyền thống.
4. NFV ra đời và chuẩn hóa như thế nào?
Ý tưởng NFV không đến từ một hãng công nghệ, mà từ chính các nhà cung cấp dịch vụ mạng — những người thấy rõ nhất sự tốn kém của mô hình cũ. Tháng 10/2012, tại hội nghị SDN and OpenFlow World Congress (Darmstadt, Đức), bảy nhà mạng viễn thông hàng đầu — AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Telefónica và Verizon — cùng công bố sách trắng đầu tiên về NFV, đồng thời thành lập ETSI ISG NFV (ETSI Industry Specification Group for Network Functions Virtualization), nhóm chịu trách nhiệm phát triển các yêu cầu và kiến trúc chuẩn cho việc ảo hóa chức năng mạng.
Từ 7 thành viên sáng lập, cộng đồng ETSI ISG NFV nhanh chóng mở rộng — có giai đoạn đạt quy mô hơn 230 công ty thành viên, bao gồm nhà mạng, nhà sản xuất phần cứng và nhà cung cấp thiết bị viễn thông trên toàn cầu. Các tài liệu đặc tả mà nhóm này công bố — định nghĩa thuật ngữ, mô hình kiến trúc tham chiếu, use case chuẩn — cho đến nay vẫn là nguồn tham khảo chuẩn mực nhất cho bất kỳ ai triển khai NFV, và là cơ sở cho toàn bộ nội dung kiến trúc ở Mục 5.
Song song với ETSI, một số tổ chức khác cũng tham gia chuẩn hóa NFV theo hướng riêng: 3GPP tập trung khía cạnh mạng di động, OASIS đưa ra TOSCA — ngôn ngữ mô tả cấu hình dùng trong MANO (Mục 5.6). Về phía sản phẩm, hệ sinh thái NFV chia làm hai nhánh: các dự án nguồn mở (OPNFV, Open Source MANO, OpenBaton — xem hiện trạng cập nhật ở Mục 8) và các giải pháp thương mại (Red Hat, VMware NSX,...).
5. Kiến trúc NFV theo chuẩn ETSI
5.1. Tổng quan ba khối chính
ETSI đề ra một mô hình kiến trúc tham chiếu được cộng đồng NFV chấp nhận rộng rãi, gồm ba khối chính:
- VNF (Virtualised Network Function): phần mềm đảm nhiệm chức năng mạng đã được ảo hóa — chạy trên máy ảo, không cần phần cứng chuyên dụng. VNF nằm trên nền NFVI, được MANO và một hệ thống quản lý thực thể riêng (EMS — Element Management System) bên trong VNF theo dõi.
- NFVI (Network Functions Virtualisation Infrastructure): toàn bộ phần cứng và phần mềm cung cấp tài nguyên cho VNF hoạt động — gồm phần cứng phổ thông và một lớp ảo hóa phân tách VNF khỏi phần cứng bên dưới. NFVI do MANO quản lý và có thể trải trên nhiều vị trí địa lý.
- NFV MANO (Management and Orchestrate): điều phối và quản lý vòng đời tài nguyên vật lý, phần mềm ảo hóa và các VNF. Vì các interface giao tiếp giữa MANO và NFVI đã được ETSI chuẩn hóa, nhà phát triển không cần tự xây cả ba khối — chỉ cần tập trung vào một thành phần vẫn tương thích được với hệ sinh thái chung.
Ngoài ba khối chính, kiến trúc còn có OSS/BSS (hệ thống hỗ trợ vận hành/kinh doanh, tương tác với người vận hành và khách hàng) và Service, VNF & Infrastructure Catalog (tập tin đặc tả để khởi tạo dịch vụ, VNF hay kết nối hạ tầng nhanh chóng — chi tiết ở Mục 5.6).
5.2. VNF — Khối hàm chức năng mạng ảo hóa
Nói đơn giản, một VNF là một máy ảo được cài sẵn chức năng mạng — định tuyến, chuyển mạch, tường lửa,... Khác với PNF (Physical Network Function — thiết bị mạng vật lý truyền thống), VNF không đòi hỏi phần cứng riêng, nên triển khai, quản lý và điều phối linh hoạt hơn hẳn. Nhưng VNF không phải "muốn viết sao cũng được" — nó vẫn phải tuân theo các chuẩn thiết kế chung (3GPP, IETF,...) để tương thích được với các giải pháp khác trong hệ sinh thái.
Bên trong mỗi VNF có một EMS (Element Management System) — phần mềm điều khiển thu thập thông tin của "thiết bị ảo" này rồi báo về cho MANO xử lý, đồng thời nhận lệnh ngược lại từ MANO để thực hiện các tác vụ quản lý.
Ví dụ cụ thể — CPE (Customer Premises Equipment): đây là thiết bị cho phép người dùng kết nối vào mạng của nhà cung cấp dịch vụ, phổ biến nhất là các router/modem của FPT, VNPT, Viettel. Theo cách truyền thống, một CPE là thiết bị vật lý cài sẵn các chức năng routing, switching, PPPoE, QoS — số lượng tính năng bị giới hạn bởi chính phần cứng đó. Khi ảo hóa CPE thành vCPE, một vCPE có thể chứa nhiều VNF nhỏ, mỗi VNF đảm nhiệm một nhiệm vụ riêng (DHCP, DNS,...), xâu chuỗi lại thành dịch vụ hoàn chỉnh. Nhờ vậy nâng cấp, thêm/bớt tính năng, quản lý hàng loạt CPE trở nên đơn giản hơn nhiều so với việc phải đụng vào từng thiết bị vật lý.
Mỗi VNF có tập tin mô tả cấu hình riêng gọi là VNFD (Virtualised Network Function Descriptor) — chứa số vCPU, dung lượng RAM, số port, thông tin kết nối nội bộ giữa các thành phần trong VNF. Khi khởi tạo VNF, MANO dựa vào VNFD để yêu cầu NFVI cấp phát tài nguyên tương ứng — dù việc cấp phát thực tế đôi khi còn phụ thuộc thêm các ràng buộc khác (khả năng đáp ứng của hạ tầng lúc đó, chính sách bảo mật,...) chứ không nhất thiết bám sát VNFD tuyệt đối.
Nhìn tổng thể, một VNF trải qua vòng đời phát triển gồm 6 bước:
- Định nghĩa tập tin VNFD theo yêu cầu người dùng/khách hàng.
- Viết script quản lý vòng đời VNF — khởi tạo VM, cấu hình ban đầu, khởi chạy hoặc hủy dịch vụ.
- Phát triển image hệ điều hành cho VM sẽ chạy VNF.
- Tải VNFD lên VNF Catalog — hệ thống kiểm tra tính tương thích với tài nguyên khả dụng trước khi chấp nhận lưu.
- Triển khai thử: hệ thống cấp phát tài nguyên, cài đặt VNF.
- Chạy thử: nếu cài đặt thành công, chạy thử nghiệm để đánh giá, nghiệm thu VNF.
Về mặt kiến trúc nội bộ, một VNF được cấu thành từ một hoặc nhiều VNF Component (VNFC) — mỗi VNFC chạy trên một VM riêng trên nền NFVI. Số lượng và cách tổ chức VNFC bên trong một VNF phụ thuộc vào mục tiêu thiết kế: hiệu năng, khả năng mở rộng, độ tin cậy, bảo mật,... Một VNF giao tiếp với các khối khác trong kiến trúc NFV qua 5 loại interface chuẩn (SWA-1 đến SWA-5), do ETSI và 3GPP định nghĩa chi tiết:
| Interface | Giao tiếp với |
|---|---|
| SWA-1 | Các VNF hoặc PNF khác |
| SWA-2 | Các VNFC trong cùng một VNF |
| SWA-3 | VNF Manager (trong khối MANO) |
| SWA-4 | EMS riêng của chính VNF đó |
| SWA-5 | Khối NFVI bên dưới |
5.3. NFVI — Khối hạ tầng ảo hóa
NFVI là tập hợp phần cứng và phần mềm dùng để khởi tạo môi trường cho VNF hoạt động. Vì đây là kiến trúc mở do ETSI chuẩn hóa, doanh nghiệp có thể trộn nhiều công nghệ NFVI khác nhau (OpenStack, VMware vSphere, Red Hat, Mirantis,...) mà vẫn tương tác được với nhau, không lệ thuộc một hãng duy nhất.
ETSI chia NFVI thành ba miền con:
5.3.1. Compute Domain
Miền tính toán gồm tài nguyên phần cứng tính toán và lưu trữ vật lý bên dưới — cụ thể là:
- Vi xử lý và các thành phần tối ưu hiệu năng: có thể là chip phổ thông (ARM, Intel x86), cùng các thuật toán nén/mã hóa tối ưu để tăng cường bảo mật và khả năng xử lý gói tin.
- Lưu trữ: SSD, HDD, tape drive.
5.3.2. Hypervisor Domain
Miền ảo hóa cung cấp môi trường thực thi cho VNF — dựa vào Compute Domain để tạo ra một lớp tài nguyên (tính toán, lưu trữ) đã ảo hóa, phân tách phần cứng bên dưới với ứng dụng bên trên. Khi MANO ra lệnh, các máy ảo được tạo để chạy VNF; quản trị viên điều khiển các VM đó qua API/interface của miền này.
Trong trường hợp cần băng thông cao hơn cho VNF, lớp ảo hóa có thể cho VM kết nối trực tiếp tới phần cứng bên dưới bằng các kỹ thuật như SR-IOV, PCI Passthrough — trình bày kỹ ở Mục 5.4.
Trên nền tảng Linux, đại diện tiêu biểu cho miền này là bộ đôi KVM/Libvirt; ngoài ra còn có Xen, VMware, Hyper-V. Về quản lý lưu trữ, các giải pháp phổ biến gồm LVM, Ceph.
5.3.3. Infrastructure Network Domain
Miền hạ tầng mạng quản lý tài nguyên chuyển mạch và định tuyến của hệ thống — Top of Rack Switch, router, cáp kết nối giữa các tài nguyên tính toán và lưu trữ trong NFVI. Miền này cung cấp hạ tầng mạng ảo cho các VNF hoạt động và tương tác với nhau: tạo mạng ảo, cấp phát và quản lý không gian địa chỉ, phân tách luồng dữ liệu độc lập giữa các mạng ảo.
Đại diện cho miền này gồm: card mạng nối qua cổng PCIe, switch/router phổ thông hỗ trợ giao thức ảo hóa mạng, các công nghệ tối ưu I/O (SR-IOV, DPDK), và phần mềm ảo hóa mạng (Linux bridge, Open vSwitch).
5.4. Công nghệ tối ưu hiệu năng cho NFVI
Đây chính là lời giải cho điểm yếu đã nêu ở Mục 2: phần cứng phổ thông không sinh ra để làm tác vụ mạng chuyên biệt, nên cần thêm những kỹ thuật giúp nó "chơi ngang cơ" phần cứng chuyên dụng.
DPDK (Data Plane Development Kit)
DPDK là tập thư viện và driver cho network interface controller, giúp tăng tốc xử lý gói tin trên các dòng CPU đa nhiệm phổ thông (Intel Atom, Intel Xeon,...). Cơ chế cốt lõi: DPDK chuyển việc nhận gói tin từ mô hình push (ngắt CPU mỗi khi có gói đến) sang poll (CPU chủ động hỏi vòng), nhờ đó giảm mạnh số lần interrupt, context switch và buffer copy — những thứ vốn ngốn CPU nhất trong xử lý gói tin trên Linux kernel thông thường.
💡 Hình dung như thế này: Mô hình push giống việc bạn cứ mỗi lần có tin nhắn lại bị chuông điện thoại reo giật mình, phải dừng hết mọi việc để trả lời ngay. Mô hình poll giống việc bạn tắt chuông, cứ mỗi vài giây tự chủ động liếc màn hình kiểm tra một lần — ít bị gián đoạn hơn nhiều nếu tin nhắn đến dồn dập.
Cụ thể, DPDK có khả năng: gửi/nhận gói tin với rất ít chu kỳ CPU (thường dưới 80 chu kỳ), hỗ trợ phát triển thuật toán bắt gói nhanh kiểu tcpdump, chạy được ứng dụng mạng bên thứ ba, và tối ưu quản lý bộ đệm.
Ban đầu DPDK do Intel phát triển riêng cho chip x86, sau đó mở rộng hỗ trợ IBM Power 8, EZchip TILE-Gx, ARM,... và được nhiều hãng NIC (Intel, Cisco, Mellanox, Broadcom,...), hệ điều hành (Ubuntu, RHEL/Fedora) và nền tảng ảo hóa (KVM, VMware, Xen) tích hợp.
⚠️ Về số liệu hiệu năng cụ thể: bản gốc tài liệu này trích dẫn con số "tăng tốc 25 lần so với Linux thường" và "233 Gbps trên chip Xeon E5-2658 v4" từ thử nghiệm của Intel. Khi rà soát lại, nhóm biên tập không tìm thấy văn bản chính thức nào của Intel/DPDK Foundation xác nhận đúng hai con số này — trang lịch sử chính thức của DPDK Foundation chỉ ghi nhận mức cải thiện thông lượng khoảng 10 lần ở giai đoạn đầu, và tới 40 lần ở các bản phát hành sau này so với kernel Linux thường. Xem chi tiết ở mục Nguồn tham khảo cuối bài.
PCI-Passthrough
PCI-Passthrough cho phép gắn trực tiếp một thiết bị dùng cổng PCI (card mạng, VGA, hard-drive controller,...) trên máy host vào thẳng một máy ảo (guest) cụ thể. Máy ảo lúc này toàn quyền sử dụng thiết bị PCI đó — thậm chí máy host cũng không còn "nhìn thấy" thiết bị này cho tới khi nó được gỡ khỏi guest.
Lợi ích: tăng đáng kể hiệu năng do bỏ qua các bước trung gian; cô lập thiết bị PCI riêng cho một VM, giảm rủi ro bảo mật và nghẽn cổ chai khi nhiều VM tranh chấp cùng thiết bị vật lý; cho phép VM dùng những thiết bị PCI khó hoặc không thể ảo hóa theo cách thông thường.
Hạn chế: VM dùng PCI-Passthrough mất khả năng lưu/phục hồi/di cư (live migration) vì đã gắn chặt vào thiết bị PCI cụ thể — muốn di dời phải gỡ thiết bị khỏi hypervisor cũ rồi gắn lại ở hypervisor mới; đồng thời phải tách thiết bị đó khỏi host vật lý trước khi gán cho VM. Các hypervisor phổ biến hiện nay (KVM, VMware, Xen) đều hỗ trợ kỹ thuật này.
SR-IOV (Single Root I/O Virtualization)
SR-IOV do tổ chức PCI-SIG định nghĩa, cho phép chia sẻ một thiết bị PCIe vật lý cho nhiều máy ảo cùng sử dụng — bằng cách tạo ra nhiều hàm ảo (Virtual Function — VF) trên một hàm vật lý (Physical Function — PF), mỗi VF hoạt động tương tự một thiết bị thật độc lập.
💡 Hình dung như thế này: PCI-Passthrough giống việc bạn đưa hẳn chìa khóa xe riêng cho một người dùng toàn quyền — không ai khác đụng được vào xe đó nữa. SR-IOV giống một trạm cho thuê xe đạp công cộng: vẫn là những chiếc xe thật, nhưng mỗi người dùng nhận một chiếc "phần" của hệ thống, dùng độc lập với nhau mà không cần biết những người khác đang dùng chung hạ tầng bên dưới.
Theo spec SR-IOV của PCI-SIG, về mặt kiến trúc, một thiết bị PCIe hỗ trợ SR-IOV có thể tạo tối đa 256 VF (nhờ cơ chế ARI — Alternative Routing-ID Interpretation mở rộng Function Number lên 8 bit). Con số 256 là trần lý thuyết; trên thực tế mỗi VF vẫn tiêu tốn tài nguyên phần cứng thật, nên phần lớn NIC đời hiện nay chỉ hỗ trợ tới khoảng 64 VF/PF trước khi tranh chấp tài nguyên trở thành vấn đề. Ví dụ: một card mạng 4 port hỗ trợ SR-IOV, nếu tính theo trần lý thuyết sẽ có tối đa 4 × 256 = 1024 VF — nhưng đây chỉ là con số lý thuyết, người quản trị cần thử nghiệm và đánh giá thực tế trên chính cấu hình của mình trước khi khai thác hết công suất.
Với VM hoặc hypervisor, mỗi VF hoạt động độc lập như một thiết bị thật riêng lẻ — thiết bị vật lý bên dưới không biết đến sự hiện diện của từng VF. SR-IOV cũng có giới hạn riêng: các VF phải cùng loại với thiết bị vật lý gốc, và không thể dùng VF để cấu hình lại chính thiết bị vật lý đó.
Ngoài ba kỹ thuật trên, hệ sinh thái NFV còn có thêm NUMA, Huge Pages, ASAP2,... để tối ưu hiệu năng sâu hơn — nằm ngoài phạm vi tài liệu này.
5.5. NFV MANO — Khối điều phối và quản lý
Một hệ thống NFV thực tế có rất nhiều thành phần phức tạp đan xen: hệ thống ảo hóa (VMware vSphere, KVM), thiết bị mạng vật lý, máy ảo chứa VNF, và vô số liên kết giữa chúng — tất cả cùng tạo ra sản phẩm cuối cùng là dịch vụ mạng cho người dùng. Bài toán đặt ra: làm sao quản lý tập trung, thống nhất toàn bộ những thành phần này, với độ ổn định cao và càng ít can thiệp thủ công càng tốt? NFV MANO chính là lời giải — tương thích nhiều loại phần cứng/phần mềm, điều phối chặt chẽ giữa các thành phần.
Công việc cụ thể của MANO gồm: cấp phát và thu hồi tài nguyên NFVI (xử lý, bộ nhớ, lưu trữ, kết nối); quản lý kết nối giữa VM và VNF; khởi tạo, mở rộng, phục hồi, nâng cấp hoặc xóa VNF; theo dõi hiệu năng và các vấn đề liên quan đến NFVI.
Về mặt kiến trúc, MANO gồm ba khối con chính — NFVO, VNFM, VIM — cùng các khối lưu trữ dữ liệu hỗ trợ (Mục 5.6).
5.5.1. NFV Orchestrator (NFVO)
NFVO khởi tạo, tinh chỉnh và kết hợp các dịch vụ mạng (Network Service) lại với nhau; quản lý tài nguyên toàn cục, chứng thực, cấp quyền, và trực tiếp khởi tạo tài nguyên NFVI thông qua VIM.
5.5.2. VNF Manager (VNFM)
VNFM quản lý vòng đời của VNF — điều phối, tùy chỉnh cấu hình, làm cầu nối thông tin giữa NFVO, VIM và EMS. Cụ thể, một VNFM đảm nhiệm:
a) Quản lý vòng đời VNF (khởi tạo/hủy, bật/tắt, đổi cấu hình, nâng cấp phần mềm, phục hồi sự cố). b) Mở rộng hoặc thu hẹp VNF khi cần. c) Thu thập, giám sát thông tin hiệu suất hoạt động và các cảnh báo lỗi. d) Làm cầu nối giữa EMS bên trong VNF với NFVO và VIM.
Nhà phát triển có hai lựa chọn thiết kế VNFM: xây một Generic VNF Manager dùng chung cho mọi loại VNF (chiến lược phổ biến nhất của các nhà phát triển MANO), hoặc xây VNFM chuyên biệt cho một số VNF đặc thù (ví dụ VNF cho VoLTE) — khi đó nhà phát triển MANO chỉ cần cung cấp driver/API của NFVO để bên thứ ba tự viết VNFM riêng.
5.5.3. Virtualized Infrastructure Manager (VIM)
VIM quản lý và điều phối tài nguyên tính toán, lưu trữ, kết nối mạng của NFVI: quản lý thông tin phần cứng/phần mềm NFVI; phân phối, nâng cấp, thu hồi tài nguyên cho VNF sử dụng; tạo virtual link, virtual network, subnet, port mạng cũng như security policy; thu thập thông tin hiệu năng và lỗi.
OpenStack hiện là lựa chọn VIM phổ biến nhất nhờ quá trình phát triển lâu dài và cộng đồng lớn; ở phân khúc thương mại, VMware vSphere cũng được nhiều giải pháp MANO hỗ trợ.
5.6. Kho chứa dữ liệu của MANO
MANO cần các kho dữ liệu để theo dõi tài nguyên, đối tượng đã khởi tạo, và các tập tin mẫu dùng để triển khai — bốn kho chính:
- NFVI Resources Repository: bản ghi mô tả tài nguyên của các hạ tầng NFVI đã kết nối vào MANO qua VIM, liên tục cập nhật để quản trị viên nắm được lượng tài nguyên khả dụng.
- NFV Instances Repository: thông tin về mọi VNF/NS đã khởi tạo, mỗi đối tượng là một record được cập nhật liên tục theo vòng đời — giúp NFVO/VNFM đảm bảo tính toàn vẹn và theo dõi mối quan hệ giữa các đối tượng.
- VNF Catalog: kho chứa toàn bộ tập tin VNFD. NFVO và VNFM đều có thể truy xuất kho này cho nhiều tác vụ (khởi tạo VNF, kiểm tra tính khả dựng,...).
- Network Service Catalog: kho chứa NSD (Network Service Descriptor) — tập tin mô tả dịch vụ mạng, được tạo nên từ một hoặc nhiều VNFD thành phần.
Việc định nghĩa các trường trong VNFD được ETSI thống nhất bằng ba ngôn ngữ mô tả phổ biến:
- UML (Unified Modeling Language, do Object Management Group đề xuất) — ETSI dùng trong các tài liệu mô tả tiêu chuẩn VNFD.
- TOSCA-NFV (Topology and Orchestration Specification for Cloud Applications, do OASIS đề xuất) — mô tả đồ thị các thực thể sẽ khởi tạo và kết nối giữa chúng, cùng các sự kiện vòng đời, chính sách, ràng buộc giữa các VNF.
- YANG — khác UML và TOSCA ở chỗ hướng hẳn về mạng, mô tả dữ liệu trạng thái và cấu hình của thực thể mạng.
Một VNFD viết theo TOSCA điển hình sẽ khai báo: phiên bản TOSCA, mô tả VNFD, metadata (tên VNFD), thông tin các máy ảo sẽ triển khai (Virtual Deployment Unit), các interface sẽ tạo (Connection Point), và kết nối mạng ảo sẽ dùng (Virtual Link). Khi một VNFD được nạp lên kho chứa, MANO kiểm tra tính đúng đắn của từng trường trước khi quyết định lưu lại.
# Ví dụ rút gọn cấu trúc VNFD theo TOSCA Simple Profile — minh họa
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0
metadata:
template_name: vnfd-example
topology_template:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
properties:
num_cpus: 2
mem_size: 2048 MB
CP1:
type: tosca.nodes.nfv.CP # Connection Point
requirements:
- virtualLink: VL1
VL1:
type: tosca.nodes.nfv.VL # Virtual Link
(Cấu trúc trường minh họa theo chuẩn TOSCA Simple Profile for NFV — không phải trích nguyên văn một VNFD thật.)
Tương tự, một NSD mô tả dịch vụ mạng gồm nhiều VNF: tên các VNFD thành phần, tên các VNF sẽ khởi tạo từ những VNFD đó, và tên các mạng ảo dùng để kết nối chúng (ví dụ VNFD1 + VNFD2 → VNF1 + VNF2, nối với nhau qua đường mạng net0 ứng với VL1 và net_mgmt ứng với VL2). Khi nạp NSD lên kho chứa, MANO cũng kiểm tra tính hợp lệ của các trường tương tự như với VNFD.
Để thuận tiện phát hành, NSD và các VNFD liên quan thường được đóng gói chung thành một tập tin duy nhất theo chuẩn CSAR (Cloud Service Archive) — có thể chứa một NSD kèm các VNFD thành phần, hoặc chỉ một VNFD riêng lẻ:
package.csar
├── Definitions/ # Tập tin NSD, VNFD theo chuẩn TOSCA
├── scripts/ # Script cài đặt cho NS và các VNF thành phần
└── TOSCA-Metadata/ # Mô tả thông tin về gói CSAR này
6. NFV và SDN
6.1. SDN là gì?
Theo Open Networking Foundation, SDN (Software-Defined Networking) là một mô hình kiến trúc mạng linh động, dễ quản lý, tiết kiệm chi phí và có khả năng tương thích cao — phù hợp cho các ứng dụng tiêu tốn nhiều băng thông và thay đổi liên tục. Ý tưởng cốt lõi: tách rời rõ ràng control plane (điều khiển mạng) khỏi data plane (chuyển mạch), cho phép hạ tầng mạng bên dưới và các dịch vụ/ứng dụng bên trên hoạt động độc lập với nhau, đồng thời cho quản trị viên khả năng lập trình trực tiếp đường đi của traffic.
Ba thành phần cốt lõi trong một kiến trúc SDN:
- Controller: "bộ não" của hệ thống, cho quản trị viên cái nhìn toàn cảnh về mạng và là nơi thực hiện toàn bộ việc điều chỉnh luồng traffic — chính là Control Layer trong sơ đồ trên.
- Northbound API: các API để ứng dụng của người dùng phía trên tương tác với controller, cho phép lập trình và điều khiển dịch vụ mạng.
- Southbound API: API truyền lệnh điều khiển từ controller xuống switch/router vật lý bên dưới. Đại diện phổ biến nhất là OpenFlow — nền tảng cho phần lớn giải pháp SDN hiện nay.
Việc tách control plane khỏi data plane mang lại lợi ích cho nhiều bên: nhà sản xuất phần mềm tập trung vào sản phẩm của mình mà không lệ thuộc phần cứng một hãng cụ thể; người dùng tự do phối hợp phần mềm điều khiển và phần cứng khác nhau để đạt hiệu suất tối ưu; và quan trọng nhất với nhà cung cấp dịch vụ viễn thông — quản lý tập trung được toàn bộ hạ tầng dù thiết bị nằm rải rác ở nhiều data center.
6.2. Mối liên hệ giữa NFV và SDN
NFV và SDN xuất phát từ hai động lực khác nhau: NFV ra đời từ nhu cầu của nhà cung cấp dịch vụ muốn cắt giảm chi phí phần cứng bằng cách ảo hóa thiết bị mạng; SDN xuất phát từ giới nghiên cứu và data center, muốn tách việc điều khiển mạng khỏi thiết bị vật lý để dễ cấu hình và quản lý tập trung một lượng lớn thiết bị.
Về bản chất, hai công nghệ độc lập với nhau — mỗi bên áp dụng được vào thực tiễn mà không cần bên còn lại, và không có chuyện "cái nào tốt hơn cái nào" vì chúng phục vụ hai mục đích khác nhau:
| Tiêu chí so sánh | SDN | NFV |
|---|---|---|
| Mục đích | Phân tách control plane/data plane, quản lý tập trung, cấu hình bằng lập trình | Chuyển chức năng mạng từ phần cứng chuyên dụng sang thiết bị phổ thông |
| Đối tượng phục vụ | Viện nghiên cứu, trung tâm dữ liệu | Nhà cung cấp dịch vụ mạng |
| Thiết bị | Máy chủ, thiết bị chuyển mạch phổ thông | Máy chủ, thiết bị chuyển mạch và lưu trữ phổ thông |
| Ứng dụng | Điều phối mạng | Các thiết bị mạng ảo hóa: router, firewall, CDN,... |
| Tổ chức chuẩn hóa | Open Networking Foundation | ETSI NFV ISG |
Mục tiêu chung của cả hai vẫn là: điều khiển hạ tầng mạng dễ dàng hơn, tiết kiệm chi phí, hạn chế tương tác trực tiếp với phần cứng. Vì vậy SDN và NFV không đối chọi mà bổ sung, hoàn thiện cho nhau — quản lý tập trung của SDN kết hợp khả năng ảo hóa thiết bị của NFV tạo ra một nền tảng hạ tầng viễn thông linh hoạt hơn hẳn từng công nghệ riêng lẻ, và là một trong những nền tảng chuẩn bị cho 5G.
6.3. Kết hợp SDN vào NFV
Bản thân NFV có thể điều chỉnh luồng dữ liệu khi khởi tạo thiết bị mạng, nhưng khó điều chỉnh lại các luồng đã thiết lập sẵn — chưa kể những tính năng nâng cao như lọc gói tin, xử lý header, QoS thì các giải pháp NFV vẫn còn thiếu so với SDN, vốn sinh ra chuyên để điều chỉnh luồng dữ liệu. Kết hợp SDN vào hạ tầng NFV chính là lời giải cho khoảng trống này — theo mô hình kiến trúc tổng quan do Verizon đề xuất, việc điều chỉnh luồng dữ liệu chia làm hai giai đoạn:
- Giai đoạn 1 — Khởi tạo: do khối MANO của NFV đảm nhận. Thông tin đường mạng, liên kết giữa các VNF/VNFC và cách kết nối chúng thành một Network Service hoàn chỉnh được thể hiện trong các tập tin đặc tả (VNFD/NSD). MANO đọc các tập tin này, cấp phát tài nguyên rồi khởi tạo dịch vụ mạng hoàn chỉnh.
- Giai đoạn 2 — Sau khởi tạo: việc điều chỉnh luồng được giao lại cho SDN Controller. Khi xuất hiện luồng dữ liệu thỏa các rule đã định nghĩa sẵn, SDN Controller điều hướng luồng đi qua các VNF theo lộ trình định sẵn — người vận hành có thể lập trình sẵn hoặc điều chỉnh lại tập rule này bất cứ lúc nào cho phù hợp yêu cầu dịch vụ.
Workflow đầy đủ theo mô hình Verizon gồm 10 bước chính (1–10) và một số tương tác phụ trợ (a–h):
Chú thích chi tiết các bước 1–10 trong workflow trên:
| Bước | Mô tả |
|---|---|
| 1 | Network Engineer khởi tạo dịch vụ qua portal — danh sách dịch vụ (NAT, VPN, Load Balance,...) cùng thông số đi kèm đã có sẵn. |
| 2 | Thông tin, thông số dịch vụ được End-to-End Orchestrator (EEO) tiếp nhận. |
| 3 | EEO lấy End-to-End Service Descriptor từ template định nghĩa sẵn, xác định tài nguyên cần và vị trí cài đặt VNF mới. |
| 4 | NFVO (một thành phần trong EEO) và VNFM liên lạc để chuẩn bị khởi tạo VNF: kiểm tra tài nguyên khả dụng, cấp phép cấp phát. |
| 5a | VNFM liên hệ VIM để tạo VM cho VNF (kịch bản VNFM driven). |
| 5b | Hoặc NFVO liên hệ VIM để tạo VM (kịch bản NFVO driven). |
| 6 | VIM liên hệ NFVI để yêu cầu tài nguyên phần cứng khởi tạo VM. |
| 7 | VNFM cài đặt VNF lên các VM vừa tạo. |
| 8 | Với VNF gồm nhiều VM, VNFM yêu cầu SDN Controller tạo kết nối giữa các VM trong cùng VNF. |
| 9 | EEO yêu cầu SDN Controller nối các VNF lại thành một chuỗi dịch vụ hoàn chỉnh. |
| 10 | EEO nạp thông tin đặc thù khách hàng xuống các hàm dịch vụ mạng — ví dụ tập rule cho Firewall, IDS. |
Và các tương tác phụ trợ (a–h): (a) OSS/BSS liên hệ EEO để yêu cầu dịch vụ; (b) EEO quản lý PNF qua EMS; (c) OSS/BSS quản lý trực tiếp PNF; (d) EMS quản lý PNF; (e) EEO quản lý trực tiếp PNF; (f) SDN Controller nối PNF–PNF hoặc PNF–VNF, tận dụng hạ tầng sẵn có; (g) phần cứng NFVI gồm switch/server hiệu năng cao, không phụ thuộc hãng; (h) Service Assurance thu thập alarm, giám sát hệ thống phục vụ sửa lỗi và phân tích.
Xem tiếp Phần 2: Ứng dụng, triển khai và case study thực tế.
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.
- ETSI ISG NFV thành lập 10/2012 tại SDN and OpenFlow World Congress (Darmstadt) bởi 7 nhà mạng sáng lập (AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Telefónica, Verizon), sau mở rộng tới hơn 230 thành viên — theo tài liệu gốc của khóa luận, dẫn qua ETSI NFV White Paper 2012–2014.
- DPDK Foundation ghi nhận mức cải thiện thông lượng khoảng 10 lần ở giai đoạn đầu và tới 40 lần ở các bản phát hành sau so với Linux kernel thường; không tìm thấy xác nhận chính thức cho hai con số "tăng 25 lần" và "233 Gbps trên Xeon E5-2658 v4" mà bản gốc khóa luận trích dẫn — 2024, DPDK.org: DPDK at 15.
- SR-IOV theo spec PCI-SIG cho phép tối đa 256 VF/PF về mặt kiến trúc (qua cơ chế ARI), nhưng phần cứng thực tế hiện nay thường giới hạn khoảng 64 VF/PF — Synopsys: Optimizing PCIe SR-IOV for Numerous Functions, Intel: PCI-SIG SR-IOV Primer.