Tổng quan

Sau khi Broadcom thâu tóm VMware vào tháng 11/2023, hàng loạt thay đổi lớn về giấy phép đã được áp dụng. Đặc biệt, mức phí thuê bao tăng đột biến cùng với việc cắt giảm hỗ trợ đã khiến nhiều doanh nghiệp gặp phải khó khăn không nhỏ. Chính vì vậy, ngày càng nhiều công ty bắt đầu tìm kiếm những giải pháp thay thế để thoát khỏi gánh nặng chi phí từ VMware.

Với chính sách của Broadcom nổi tiếng trong việc thâu tóm các công ty rồi tối ưu hóa lợi nhuận tương xứng với số tiền khổng lồ đầu tư, việc tăng giá cũng như cắt giảm các bộ phận, sản phẩm không hiệu quả VMware là điều không cần phải bàn cãi.

Tuy nhiên, trên hành trình “thoát VMware”, không ít doanh nghiệp lại đối mặt với nguy cơ rơi vào cái bẫy khác: bị khóa chặt vào những sản phẩm đắt đỏ, chứa đầy tính năng thừa mà họ không thực sự cần, do các nhà cung cấp dịch vụ đám mây đưa ra.

Trước thực tế đó, các hệ thống ảo hóa xây dựng trên nền tảng mã nguồn mở đang nổi lên như một lựa chọn hấp dẫn. Không chỉ loại bỏ được phí bản quyền, các giải pháp này còn giúp doanh nghiệp tránh tình trạng bị “trói chân” bởi nhà cung cấp, đồng thời tận dụng được sức mạnh từ cộng đồng rộng lớn luôn sẵn sàng hỗ trợ và cải tiến liên tục.

Thách thức đối với VMware

Tôi lần đầu tiên biết đến VMware vào năm 2002, khi đó nó vẫn còn là một trình ảo hóa loại 2 (Type 2 hypervisor). Ấn tượng nhất là khả năng chuyển đổi liền mạch giữa phiên bản máy ảo và desktop cá nhân với sản phẩm VMware Workstation. Sau đó, VMware giới thiệu các sản phẩm máy chủ (server products) như ESX, vCenter và câu chuyện bắt đầu từ đó.

Khi còn sử dụng mô hình bản quyền trả phí cố định theo CPU, VMware có chi phí khá dễ chịu đối với các doanh nghiệp, đồng thời dịch vụ hỗ trợ và bảo trì cũng hoạt động rất trơn tru.

Tuy nhiên, kể từ khi Broadcom mua lại VMware, hàng loạt thay đổi chiến lược lớn đã được triển khai đột ngột. Trong đó đáng chú ý nhất là:

• Chuyển đổi từ mô hình chi phí cố định sang mô hình thuê bao (subscription).
• Ngừng gia hạn hỗ trợ và đăng ký (support & subscription renewals) cho các sản phẩm vĩnh viễn (perpetual license) trước đây.

Điều này thực tế có nghĩa là:

• Việc chuyển sang mô hình thuê bao khiến giá tăng 100–300% đối với nhiều doanh nghiệp trên toàn cầu — vượt ngoài ngân sách của phần lớn tổ chức.
• Chi phí trước đây tính theo CPU nay được tính theo số nhân (core). Mặc dù công ty tuyên bố đã giảm giá trên mỗi core, nhưng tổng chi phí vẫn rất cao.
• Với mô hình thuê bao, các doanh nghiệp bị buộc phải mua cả gói sản phẩm, trong đó có nhiều công cụ không thật sự cần thiết.
• VMware ngừng hỗ trợ cho các hợp đồng bán vĩnh viễn cũ, và những khách hàng này cũng không được chuyển đổi sang hệ thống thuê bao mới.
• Gần đây hàng loạt những lỗ hỏng bảo mật CVE ở mức critical của VMware cũng được thông cáo trên các diễn đàn buộc ngừoi dùng phải upgrade lên phiên bản mới nhân. Dù rằng chưa có một báo cáo cụ thể nào về việc khai thác các CVE này để chiếm quyền nhưng đây cũng có thể là nước đi chiến lược của Broadcom nhầm buộc người dùng phải chuyển đổi san phiên bản subscription càng sớm càng tốt.

Những thay đổi này đã khiến người dùng VMware trên toàn thế giới vô cùng phẫn nộ. Các khảo sát ban đầu cho thấy nhiều CIO và lãnh đạo công nghệ đang có xu hướng từ chối hệ thống mới của VMware, dù nó có mang lại những cải tiến hay dịch vụ hỗ trợ nào đi nữa — thay vào đó, họ tập trung tìm kiếm các giải pháp thay thế. Và điều đó hoàn toàn có lý. Quyết định này của VMware đã gây thiệt hại nghiêm trọng cho hàng nghìn doanh nghiệp, cả trong ngắn hạn lẫn dài hạn.

Sơ lược về ảo hóa Type 1

Phương pháp ảo hóa này được các doanh nghiệp lớn sử dụng phổ biến, với mục đích chạy nhiều máy ảo (virtual machines) trên một máy vật lý duy nhất. Chúng ta gọi chúng là máy ảo (virtual machine) hoặc phiên bản ảo (virtual instance). Máy chủ vật lý sẽ cung cấp một lớp trừu tượng hóa (abstraction layer) giúp mỗi máy ảo hoạt động như một máy vật lý độc lập.

Ngoài ra, còn có một phiên bản “nhẹ” hơn của ảo hóa loại 1 (Type 1 virtualization). Dạng ảo hóa này thường được sử dụng trong các dịch vụ serverless (không máy chủ), là công nghệ mới có thời gian chạy và khởi động cực kỳ ngắn. Ví dụ điển hình là AWS Fargate, một dịch vụ serverless dựa trên hypervisor kiểu nhẹ.

Hai công nghệ ảo hóa nhẹ phổ biến nhất hiện nay là Cloud Hypervisor và Firecracker. Trong đó, Firecracker được phát triển dựa trên KVM, sử dụng rất ít thiết bị ảo khi khởi động (như network, compute, I/O…), chỉ ảo hóa các thành phần thật sự cần thiết, giúp thời gian khởi động chỉ khoảng 100–200 mili-giây.

Lưu ý quan trọng: Container không phải là công nghệ ảo hóa! Trên Internet có rất nhiều bảng so sánh hypervisor sai lệch, trong đó liệt kê Docker hay Kubernetes như là công nghệ ảo hóa — điều này hoàn toàn sai. Cũng có rất nhiều ý kiến về việc Container sẽ thay thế hoàn toàn Virtual Machine, nhưng cá nhân tôi thấy vẫn còn rất lâu nữa, hầu hết những cơ sở dữ liệu, ứng dụng quản trị doanh nghiệp hiện tại vẫn buộc phải hoạt động trên Virtual Machine hoặc Baremetal vì tính ổn định, môi trường độc lập, tối ưu và lưu trữ dài hạn.

Container không phải là công nghệ ảo hóa. Chúng được thiết kế để tạo – hủy – khởi tạo lại nhanh chóng, trong khi máy ảo lại được thiết kế để chạy liên tục lâu dài. Về bản chất, container không cung cấp “lớp trừu tượng cách ly” (isolated abstraction layer) — điều kiện tiên quyết của ảo hóa loại 1 (Type 1 virtualization).

Những lựa chọn mới

Khi việc triển khai nhiều hypervisor cùng lúc ngày càng trở nên phức tạp, các doanh nghiệp bắt đầu tìm đến những giải pháp thay thế. Một số lựa chọn tiêu biểu có thể kể đến như XCP-ng, Proxmox, OpenStack và Nutanix, những nền tảng được xem là giải pháp thay thế khả thi cho VMware.

Trong phần này, tôi sẽ đề cập đến các giải pháp thay thế VMware phù hợp cho các mô hình triển khai quy mô nhỏ.

Khi nói “quy mô nhỏ”, tôi muốn nhắc đến những hệ thống mà quản trị viên có thể dễ dàng ghi nhớ địa chỉ IP của các máy, thường được sử dụng trong các doanh nghiệp vừa và nhỏ (SME). Những hệ thống này thường có từ 3 node cho đến khoảng 8–10 node tính toán (compute nodes).

Ở quy mô này, việc triển khai công cụ quản lý (management tool) trên các hypervisor là điều rất quan trọng. Các nền tảng hypervisor hiện nay đều cung cấp những công cụ quản lý mạnh mẽ, hoạt động hiệu quả trong môi trường 3–10 node.

Tuy nhiên, có một hiểu lầm khá phổ biến mà bạn cần tránh. Ví dụ: nếu hệ thống của bạn có 3 node ở site 1 và 6 node ở site 2, điều đó không có nghĩa là bạn có 9 hypervisor trong cùng một cụm (cluster). Vì thế, đừng vội mở rộng sang mô hình quy mô lớn nếu chưa thật sự cần thiết.

Tôi khuyến nghị bạn nên tham khảo ý kiến chuyên gia hoặc đơn vị tư vấn kỹ thuật trong những trường hợp như vậy, bởi mỗi mô hình triển khai đều có những ràng buộc và phụ thuộc riêng — và thực tế, hệ thống của bạn có thể phức tạp hơn bạn nghĩ.

Công nghệ tương ứng

Hyper-V

Bỏ qua những tranh cãi về chi phí bản quyền và ràng buộc nhà cung cấp (vendor lock-in), Hyper-V vẫn là một ứng viên đáng cân nhắc. Công nghệ này có nguồn gốc từ Connectix VirtualPC – một dự án được Microsoft mua lại từ rất sớm. Định dạng đĩa ảo VHD (Virtual Hard Disk) của VirtualPC chính là nền tảng quan trọng đã góp phần định hình nên thị trường ảo hóa hiện đại.

Điểm mạnh của Hyper-V nằm ở sự tích hợp chặt chẽ với hệ sinh thái Microsoft – đặc biệt nếu doanh nghiệp bạn đã sử dụng Windows Server, Active Directory hay Azure. Tuy nhiên, rào cản lớn nhất vẫn là chi phí license và nguy cơ phụ thuộc sâu vào hệ sinh thái độc quyền.

KVM – Lựa chọn nhẹ, mạnh và phổ biến

Nếu bạn đang tìm kiếm một giải pháp mã nguồn mở, linh hoạt và đáng tin cậy, thì KVM (Kernel-based Virtual Machine) gần như là ứng viên hàng đầu.

Việc triển khai KVM khá đơn giản, thậm chí được xem là dễ dàng nhất trong nhóm hypervisor loại 1 (Type 1 Hypervisor). Tuy nhiên, để tận dụng tối đa sức mạnh của KVM, bạn cần có kiến thức vững về hệ điều hành Linux – từ cấu hình mạng, lưu trữ đến tối ưu kernel.

Không phải ngẫu nhiên mà phần lớn các nền tảng đám mây lớn như OpenStack, Red Hat Virtualization hay Hyperscaler đều chọn KVM làm hypervisor mặc định. Nó mang lại hiệu năng cao, độ ổn định vượt trội và hoàn toàn không bị ràng buộc bởi mô hình thương mại nào.

XCP-ng – Người kế thừa của XenServer

XCP-ng ra đời sau khi Citrix giới hạn tính năng của phiên bản cộng đồng XenServer, và được phát triển bởi Vates – nhóm đứng sau Xen-Orchestra. Dù không “ồn ào” như các đối thủ khác, XCP-ng vẫn kiên trì phát triển và xây dựng một cộng đồng người dùng trung thành, đặc biệt trong giới doanh nghiệp sử dụng Xen.

Với nhiều giải pháp ổn định và giàu tính năng, XCP-ng ngày nay còn hỗ trợ mô hình HCI tích hợp (Linbit, DRBD) – giúp triển khai ảo hóa đi kèm lưu trữ phân tán dễ dàng hơn. Cá nhân tôi đã sử dụng XenServer và XCP-ng suốt 15 năm cho các hệ thống quan trọng như SAP, Oracle DB, HA Cluster, MSSQL Server, và kết quả rất ấn tượng:

Tuy nhiên, XCP-ng vẫn còn một số điểm yếu cần lưu ý:

• CentOS 7 – nền tảng gốc đã ngừng cập nhật.
• Xen – gặp khó khăn trong việc duy trì các bản vá bảo mật mới.
• Network stack – hạn chế và khó tích hợp các tính năng mạng hiện đại của Linux.
• Integrated Storage – vẫn đang ở giai đoạn beta thử nghiệm.

Proxmox:

Proxmox là giải pháp thay thế đầy tiềm năng nhất cho các mô hình triển khai quy mô nhỏ. Tôi khuyến nghị sử dụng Proxmox cho các hệ thống có tối đa khoảng 8–10 node, thậm chí có thể nhiều hơn.

Nền tảng này cung cấp sẵn giải pháp lưu trữ Ceph và backup tích hợp, không yêu cầu giấy phép bản quyền để bắt đầu. Tất cả các tính năng đều có sẵn mặc định, cho phép người dùng lựa chọn giữa LXC (container) và KVM (ảo hóa toàn phần).

Nếu bạn có cụm hypervisor dưới 8–10 node, thì Proxmox là nền tảng lý tưởng dành cho bạn. Tôi đã sử dụng Proxmox khoảng ~10 năm trong nhiều môi trường sản xuất khác nhau (SAP, Oracle DB, Windows…). Trong suốt thời gian đó, rất ít sự cố xãy ra, đặc biệt là về dịch vụ clustering. Nhờ có kinh nghiệm Linux nội bộ, tôi có thể tự giải quyết hầu hết các vấn đề. Tôi rất khuyến nghị Proxmox như một hypervisor Type 1 và nền tảng điều phối (orchestration) đáng tin cậy.

Tuy nhiên, Proxmox vẫn có một số điểm yếu cần lưu ý:

• Cluster services: sử dụng SQLite và shared quorum.

• Network stack: bị giới hạn bởi Linux; tuy nhiên, hiện Proxmox đã giới thiệu SDN stack mới.

• Storage: Định hướng tích hợp sâu với Ceph, các tính năng hỗ trợ Storage chuyên dụng chưa được sâu

• Có thể gặp lỗi (buggy) khi triển khai ở quy mô lớn.

Các dự án vẫn đang ở giai đoạn Beta & đã lỗi thời

Harvester (vẫn ở giai đoạn Beta): Harvester sử dụng KVM làm hypervisor, cụ thể là KubeVirt. Các instance được tạo bên trong container, điều này làm tăng độ phức tạp. Tuy nhiên, Harvester áp dụng mô hình HCI (Hyper-Converged Infrastructure), cung cấp đầy đủ các thành phần cần thiết như lưu trữ và mạng. Trong môi trường thử nghiệm của chúng tôi, Harvester tiêu tốn rất nhiều tài nguyên CPU ngay cả khi không có instance nào đang chạy trên hệ thống. Harvester là một giải pháp đầy hứa hẹn, nhưng vẫn đang trong giai đoạn Beta và chưa thể sử dụng trong môi trường production.

KubeVirt (không có nền tảng áp dụng thực tế): Việc sử dụng KubeVirt một mình để thay thế hypervisor là rất thách thức. Nó phù hợp với những người có kinh nghiệm về OpenShift (có tích hợp KubeVirt) hoặc Kubernetes, muốn triển khai một stack ảo hóa. Tuy nhiên, hãy chuẩn bị tinh thần đối mặt với nhiều trường hợp sử dụng chưa được kiểm thử. Bên cạnh đó đây vẫn đang là công nghệ tiềm năng để hợp nhất việc quản trị VM và container trên cùng một hệ thống K8S, hiện tại dự án này dược Redhat đầu tư mạnh trong sản phẩm OpenShift Virtualization của họ.

RHEV (đã ngừng phát triển): Ban đầu được phát triển bởi Red Hat và sau đó thuộc sở hữu của IBM, dự án này đã được chuyển sang nền tảng OpenShift. Mặc dù thời điểm kết thúc vòng đời (EOL) được công bố là năm 2026, nhưng các bản cập nhật sẽ kết thúc vào tháng 9/2024.

oVirt (đã ngừng phát triển): oVirt, phiên bản mã nguồn mở của RHEV, vẫn đang được phát triển nhưng đã mất dần sự quan tâm của cộng đồng. Nó gặp phải nhiều vấn đề trong thiết kế, đặc biệt ở các thành phần như Gluster, NFS, quản lý image và mạng.

Private Cloud

OpenNebula

Giải pháp này hoạt động tốt với các hệ thống triển khai quy mô nhỏ, gần như “chạy được ngay” sau khi cài đặt. Tuy nhiên cộng đồng người dùng còn khá nhỏ, nên việc tìm tài liệu hay người hỗ trợ là rất hạn chế. Các hệ thống lớn sẽ cần có sự hỗ trợ chuyên nghiệp hơn và được cồng đồng đóng góp mã nguồn cũng như liên tục có các bản nâng cấp tính năng.

CloudStack

Dù từng được kỳ vọng rất lớn từ những năm 2010, CloudStack lại không mang đến kết quả như mong đợi. Dự án này hướng đến cùng phân khúc với OpenStack, cùng kiểu sản phẩm và mục tiêu tương tự. Thời điểm đó, CloudStack được đánh giá là dễ triển khai, nhưng lại không nhận được sự ủng hộ của các nhà sản xuất phần cứng lớn và cộng đồng mã nguồn mở. Trong thế giới open source, bạn nên “đi cùng đám đông”, vì sức mạnh cộng đồng nằm ở số đông.

Ý tưởng hỗ trợ nhiều hypervisor và không phụ thuộc vào phần cứng cụ thể nghe có vẻ hay, nhưng thực tế lại khiến việc triển khai trở nên phức tạp. Tài liệu mặc định của CloudStack đã lỗi thời; dù vẫn có vài triển khai hoạt động ổn định, nhưng hỗ trợ cộng đồng rất yếu.

Virtuozzo

Đây là một phiên bản OpenStack thương mại, thuộc về một nhà cung cấp cụ thể. Virtuozzo có cơ sở người dùng thực tế và bản thân công ty là đơn vị cung cấp chính. Bạn có thể yêu cầu họ triển khai toàn bộ hệ thống Private Cloud được quản lý. Họ quảng bá rằng cung cấp HCI sẵn có, nhưng tài liệu kỹ thuật lại không nêu rõ các giải pháp sử dụng. Đáng tiếc, phần lớn tài liệu của họ chỉ mang tính marketing.

Platform9

Đây là một cái tên quen thuộc trong thị trường Private Cloud, với kinh nghiệm lâu năm về OpenStack. Trong hơn 10 năm qua, họ đã có nhiều đóng góp giá trị cho cộng đồng OpenStack. Platform9 hiện sử dụng KubeVirt làm hypervisor stack. Dù chưa có dịp kiểm thử giải pháp nào của họ, nhưng nhìn chung đây là một nhà cung cấp khá tiềm năng. Giống như Virtuozzo, hiện vẫn chưa có bản triển khai thực tế để thử nghiệm trực tiếp.

OpenStack — Giải pháp Cloud thực sự

OpenStack nổi bật là giải pháp Cloud mã nguồn mở thực thụ duy nhất trên thị trường hiện nay. Với cộng đồng phát triển mạnh mẽ, OpenStack cung cấp các khối hạ tầng nền tảng có thể triển khai ở bất cứ đâu, kể cả tại tầng biên mạng. Nhờ tính linh hoạt và khả năng mở rộng, OpenStack cho phép vận hành hiệu quả các dịch vụ tối thiểu cần thiết tại biên, đồng thời hỗ trợ mạnh mẽ bare metal, container và máy ảo (VMs).

Hiện có thể phân loại 6 nhóm triển khai và phân phối OpenStack phổ biến như sau:

1. Vendor-specific (Huawei, Fujitsu, v.v.) – Một số hãng công nghệ lớn cung cấp OpenStack tích hợp sẵn với phần cứng và phần mềm của họ.
2. Red Hat – Được biết đến với đóng góp lớn cho dự án OpenStack, Red Hat cung cấp tài liệu toàn diện và các bản phân phối thương mại có hỗ trợ kỹ thuật.
3. Canonical – Với giải pháp “Sunbeam”, Canonical tích hợp MaaS (Metal as a Service) và Juju cùng nhiều công cụ khác. Họ có gói hỗ trợ trả phí “Pro” và cả sản phẩm MicroCloud (dù chúng tôi chưa thử nghiệm). MicroCloud có vẻ triển khai các instance qemu thông qua LXD container.
4. OpenStack – Open Source – Phiên bản mã nguồn mở, được cộng đồng hoặc các công ty hỗ trợ duy trì.
5. Triển khai bằng Kubernetes (StarlingX, Helm) – Dự án StarlingX kết hợp Kubernetes với OpenStack, nhưng hiện được xem là đã lỗi thời. Ngoài ra, cũng có bản triển khai Helm do cộng đồng OpenStack hỗ trợ.
6. Triển khai bằng Ansible (Kolla-Ansible) – Kolla-Ansible là công cụ giúp triển khai OpenStack bằng Ansible, giúp tự động hóa và đơn giản hóa toàn bộ quá trình triển khai.

Kết luận: Con đường sau VMware – mở ra kỷ nguyên tự do hạ tầng

Sau hơn hai thập kỷ thống trị lĩnh vực ảo hóa, VMware đang đánh mất vị thế vốn có của mình khi những thay đổi về giấy phép và mô hình thuê bao từ Broadcom đã khiến hàng loạt doanh nghiệp phải tìm hướng đi mới. Điều này không chỉ đơn thuần là “chuyển công cụ”, mà còn là cuộc chuyển mình chiến lược – từ phụ thuộc vào nền tảng thương mại sang chủ động kiểm soát hạ tầng của chính mình.

Các giải pháp mã nguồn mở như KVM, Proxmox, XCP-ng, OpenStack hay các nền tảng hybrid như Virtuozzo, Platform9 đang dần chứng minh sức mạnh của mình: chi phí hợp lý, tính linh hoạt cao và cộng đồng hỗ trợ mạnh mẽ. Từ quy mô nhỏ vài node đến hạ tầng Cloud phân tán, doanh nghiệp nay có thể tự xây dựng hệ thống ảo hóa hiệu quả, minh bạch và bền vững hơn bao giờ hết.

Tuy nhiên, không có giải pháp nào “vạn năng”. Mỗi nền tảng đều có điểm mạnh – điểm yếu, và quyết định lựa chọn phụ thuộc rất nhiều vào mục tiêu, quy mô, năng lực nội bộ và định hướng dài hạn của doanh nghiệp. Những đơn vị sở hữu đội ngũ am hiểu Linux và open source chắc chắn sẽ có lợi thế lớn trong việc khai thác sức mạnh thực sự của các giải pháp này.

Thế giới đang bước vào giai đoạn mà ảo hóa không còn chỉ là câu chuyện kỹ thuật, mà là nền tảng cho tự do công nghệ. Thay vì bị ràng buộc trong mô hình thương mại khép kín, các doanh nghiệp đang dần nhận ra giá trị to lớn của mã nguồn mở, tự chủ hạ tầng và cộng đồng toàn cầu — nơi mọi cải tiến đều được chia sẻ và phát triển không ngừng. Tôi sẽ tiếp tục phân tích sâu hơn về các giải pháp Cloud Opensource ở các bài viết tiếp theo cũng như đưa ra các khuyến nghị hữu ích cho các doanh nghiệp trong quá trình chuyển đổi này.