Rocky Linux hay AlmaLinux: chọn gì cho VPS?
Rocky Linux và AlmaLinux đều rebuild từ nguồn RHEL, hỗ trợ 10 năm. Với AlmaLinux 10, CPU cũ hơn Intel Haswell vẫn được hỗ trợ, Rocky Linux 10 thì không.
Rocky Linux so với AlmaLinux: câu trả lời ngắn gọn
Với gần như mọi server, chọn Rocky Linux hay AlmaLinux đều không có đáp án sai. Cả hai dự án đều build lại cùng mã nguồn Red Hat Enterprise Linux (RHEL), nên cung cấp cùng các package với vòng đời hỗ trợ 10 năm. Khác biệt là có thật, nhưng chủ yếu nằm ở cách quản trị dự án và một số trường hợp đặc biệt, không nằm trong công việc vận hành server hằng ngày.
Có 2 yếu tố quyết định khi đây không phải lựa chọn ngẫu nhiên. AlmaLinux 10 vẫn cung cấp bản build cho các processor cũ hơn Intel Haswell, còn Rocky Linux 10 thì không. Điều này quan trọng với phần cứng VPS (virtual private server) giá rẻ hoặc đời cũ. AlmaLinux cũng cam kết tương thích ABI thay vì hành vi giống hệt, điều này quan trọng nếu bạn chạy sản phẩm của vendor có ma trận hỗ trợ nghiêm ngặt.
Nguồn gốc của cả hai bản phân phối
Vào ngày 8 tháng 12 năm 2020, dự án CentOS thông báo CentOS Linux 8, một bản rebuild của RHEL 8, sẽ kết thúc vào cuối năm 2021. Trước đó, bản này được công bố với thời hạn hỗ trợ đến năm 2029. Hướng đi tương lai của dự án là CentOS Stream. Thông báo đó mô tả CentOS Stream là bản theo sát phía trước một bản phát hành RHEL hiện tại và đóng vai trò là nhánh phát triển upstream của RHEL. CentOS Linux 7 vẫn giữ lịch trình ban đầu và hết vòng đời vào ngày 30 tháng 6 năm 2024.
Vấn đề không nằm ở CentOS Stream. Vấn đề là vòng đời dự kiến kết thúc vào năm 2029 đã bị rút ngắn 8 năm, trong khi chỉ được thông báo trước khoảng 1 năm, trên những máy đã cài đặt hệ điều hành. Rocky Linux và AlmaLinux tồn tại vì lý do đó. Cả hai xuất hiện vào năm 2021 và đều hướng đến cùng một mục đích: cung cấp một bản rebuild RHEL miễn phí để quản trị viên có thể cài đặt rồi để nguyên trong một thập kỷ.
Điểm chung giữa Rocky Linux và AlmaLinux
Hãy bắt đầu từ đây, vì phần giống nhau chiếm phần lớn bức tranh. Cả hai đều được build lại từ cùng source RHEL upstream, nên đều có cùng phiên bản package, cùng dnf package manager, cùng chính sách SELinux (security enhanced Linux), cùng firewalld front end và cùng bố cục unit systemd. Các file cấu hình nằm ở cùng đường dẫn. Hướng dẫn viết cho bản này thường dùng được cho bản kia, chỉ cần đổi tên.
Cả hai đều bám sát các bản phát hành minor của RHEL. AlmaLinux 10.2 được phát hành vào 26 May 2026, còn Rocky Linux 10.2 vào 28 May 2026. Dòng 9 cũng phát hành trong cùng tuần: AlmaLinux 9.8 vào 26 May 2026 và Rocky Linux 9.8 vào 27 May 2026. Trước đó, khoảng cách lớn hơn. AlmaLinux 10.0 được phát hành vào 27 May 2025, còn Rocky Linux 10.0 vào 11 June 2025.
Khoảng cách này liên quan đến bộ cài của bản phát hành minor, không liên quan đến bảo mật. Cả hai dự án đều liên tục phát hành errata giữa các bản minor, mỗi dự án từ dịch vụ errata riêng. Việc image .2 xuất hiện muộn hơn hai tuần không có nghĩa là hệ thống không được cập nhật bản vá trong hai tuần.
Cả hai cũng kế thừa mô hình vòng đời 10 năm từ RHEL: khoảng 5 năm hỗ trợ đầy đủ, sau đó 5 năm chỉ bảo trì bảo mật. Dòng 10 của cả hai sẽ được hỗ trợ đến năm 2035.
Ai đứng sau từng dự án?
Rocky Linux thuộc Rocky Enterprise Software Foundation (RESF), một public benefit corporation tại Delaware do Gregory Kurtzer, đồng sáng lập CentOS, thành lập. Vào tháng 11 năm 2022, RESF đã phê chuẩn điều lệ và quy chế, chuyển quyền kiểm soát khỏi tay người sáng lập và đặt quyền này trong cơ cấu văn bản đó. CIQ, công ty cũng do Kurtzer thành lập, là nhà tài trợ sáng lập và bán dịch vụ hỗ trợ thương mại cho Rocky Linux.
AlmaLinux thuộc AlmaLinux OS Foundation, một tổ chức phi lợi nhuận 501(c)(6) được thành lập tại Delaware vào tháng 3 năm 2021. Hội đồng quản trị do các thành viên của foundation bầu theo nhiệm kỳ 4 năm lệch nhau, biên bản họp được công bố trong vòng 14 ngày, và một điều khoản trong quy chế ngăn bất kỳ chủ lao động nào nắm hơn một ghế có quyền biểu quyết trong hội đồng, bất kể họ tài trợ bao nhiêu. CloudLinux khởi động dự án và gia hạn gói tài trợ platinum vào tháng 10 năm 2024 với giá trị một triệu đô la mỗi năm. Bộ phận TuxCare của công ty bán dịch vụ hỗ trợ thương mại.
Cả hai cơ cấu đều được xây dựng để không công ty nào có thể lặp lại sự việc đã xảy ra với CentOS Linux 8, và không cơ cấu nào rõ ràng an toàn hơn cơ cấu còn lại. Điều bạn có thể thực sự kiểm tra là như nhau trong cả hai trường hợp: bạn có thể đọc quy chế và xác định tổ chức đang chi tiền.
Điều gì đã thay đổi trong 2023, và thay đổi đó còn quan trọng không?
Ngày 21 June 2023, Red Hat thông báo CentOS Stream sẽ trở thành repository duy nhất chứa các bản phát hành source code công khai liên quan đến RHEL. Trước đó, source package của RHEL xuất hiện trên git.centos.org, và các dự án rebuild lấy source từ đó. Việc gỡ feed này không khiến các bản rebuild dừng lại. Nhưng nó buộc từng dự án phải công khai cách lấy source.
Rocky đưa ra câu trả lời vào ngày 29 June 2023. Dự án lấy source của RHEL từ các container image Universal Base Image (UBI) và các public cloud instance trả phí theo mức sử dụng, dựa trên lập luận rằng "không ai có thể ngăn việc phân phối lại phần mềm GPL". Vào August 2023, CIQ, Oracle và SUSE thành lập Open Enterprise Linux Association (OpenELA), tổ chức công bố source cần thiết để rebuild Enterprise Linux tương thích từng bug. AlmaLinux không phải thành viên.
AlmaLinux đưa ra câu trả lời vào ngày 13 July 2023, và câu trả lời đó là thay đổi mục tiêu. Dự án từ bỏ khả năng tương thích 1:1 theo từng bug và chuyển sang tương thích ABI. Theo chính dự án, "chúng tôi sẽ không còn bị ràng buộc phải tương thích từng bug với Red Hat, và điều đó có nghĩa là giờ đây chúng tôi có thể tiếp nhận các bản sửa lỗi nằm ngoài chu kỳ phát hành của Red Hat". Bài viết đó cũng cho người dùng biết rằng họ có thể kỳ vọng "rất ít thay đổi" trong quá trình sử dụng hằng ngày.
Sau 3 năm, vấn đề về nguồn source trên thực tế đã được giải quyết. Cả 2 dự án đều đã phát hành mọi bản minor release của RHEL kể từ đó, với lịch phát hành tương tự nhau. Điều còn lại sau tranh luận là sự khác biệt trong cam kết của từng dự án.
Bug-for-bug hay tương thích ABI: khác nhau thế nào?
Trang chủ của Rocky Linux vẫn mô tả bản phân phối này được thiết kế để tương thích 100% với RHEL theo từng bug. Bug-for-bug nghĩa là bản rebuild tái hiện hành vi của RHEL, bao gồm cả các lỗi của RHEL. Nếu một package trong RHEL có bug, package tương ứng trong Rocky Linux cũng có bug đó. Vì vậy, workaround từ bài viết trong Red Hat Knowledgebase có thể áp dụng mà không cần chuyển đổi.
Tương thích ABI hẹp hơn và chính xác hơn. ABI, hay application binary interface, là hợp đồng nhị phân mà một chương trình đã biên dịch phụ thuộc vào: tên symbol, layout của structure, calling convention và phiên bản library. Khi giữ ổn định hợp đồng này, binary được build cho RHEL có thể load và chạy trên hệ thống. Cam kết đó không nói rằng các bug phải giống với RHEL.
Hệ quả rất rõ. AlmaLinux có thể sửa một bug trước Red Hat, đồng thời vẫn giữ một driver mà Red Hat đã loại bỏ. Cả hai việc này đều khiến hành vi của AlmaLinux khác RHEL một cách có chủ đích. Rocky Linux sẽ không làm như vậy theo thiết kế, nên hành vi của nó vẫn có thể dự đoán được theo đúng cách mà chứng nhận yêu cầu.
Vì vậy, vấn đề là bạn cần cam kết nào. Bạn cần server có hành vi giống hệt RHEL, hay cần software được build cho RHEL có thể chạy trên đó? Gần như mọi người đều cần phương án thứ hai.
Các package do vendor build cho RHEL có cài được trên cả hai hệ thống không?
Có. RPM được build cho RHEL 9 hoặc RHEL 10 cài đặt và chạy được trên cả hai hệ thống, vì ABI tương thích và vì cả hai distribution đều nhận diện với các công cụ theo cách của một hệ thống thuộc họ Red Hat. File thực hiện việc nhận diện này là /etc/os-release.
NAME="AlmaLinux"
ID="almalinux"
ID_LIKE="rhel centos fedora"Bản sao trong Rocky Linux có cùng cấu trúc với NAME="Rocky Linux" và ID="rocky", đồng thời cũng liệt kê rhel trong ID_LIKE. Một installer script đọc ID_LIKE, tìm thấy rhel và chọn nhánh Red Hat sẽ chạy được trên cả hai hệ thống. Một script chỉ so sánh ID với danh sách hard-code gồm rhel, centos và fedora sẽ fail trên cả hai, với cùng một thông báo distribution không được hỗ trợ. Đây là lỗi của script, không phải khác biệt giữa hai hệ thống.
Ngoại lệ thực tế mang tính thương mại chứ không mang tính kỹ thuật. Support matrix là tài liệu kinh doanh. Package của vendor có thể cài đặt và chạy hoàn toàn bình thường trên một distribution không được nêu trong matrix, nhưng vendor vẫn có thể từ chối hỗ trợ khi package gặp lỗi. Nếu bạn trả phí cho support, hãy đọc matrix và để matrix quyết định thay bạn. Đây là trường hợp duy nhất mà quyết định được đưa ra sẵn cho bạn.
Bản nào vẫn chạy trên CPU cũ?
RHEL 10 nâng mức kiến trúc vi mô cơ sở của x86-64 lên x86-64-v3. Mức này tương ứng với thế hệ Haswell của Intel và Excavator của AMD, đồng thời yêu cầu các phần mở rộng tập lệnh như AVX2. Rocky Linux 10 cũng theo RHEL ở điểm này. Tài liệu của Rocky Linux nêu rằng x86-64-v3 là mức cơ sở, còn v2 và các mức cũ hơn không còn được hỗ trợ.
AlmaLinux 10 cung cấp bản build v3 làm mặc định và thêm một bản build x86-64-v2 riêng. Theo cách diễn đạt của dự án, mục đích là để người dùng có phần cứng cũ hơn tiếp tục nhận cập nhật bảo mật trong 10 năm nữa. AlmaLinux cũng rebuild các gói EPEL cho kiến trúc này, vì các gói RHEL 10 của bên thứ ba nhắm đến v3. Đây là điểm cần biết trước khi dựa vào lựa chọn này: bản v2 phù hợp với bộ package mặc định và EPEL v2 do AlmaLinux cung cấp; mọi gói khác phải do bạn rebuild cho v2.
Điều này quan trọng hơn trên VPS so với phần cứng bạn sở hữu, vì bạn không chọn được CPU của host. Trên các host cũ hoặc giá rẻ, hoặc khi hypervisor trình bày một CPU model hạn chế cho guest, máy ảo có thể không expose AVX2 dù chip vật lý có hỗ trợ. Khi đó, các package được build cho v3 sẽ gọi đến những instruction mà processor không có và bị lỗi. Hãy kiểm tra instance thực tế expose những gì trước khi triển khai cả fleet lên series 10. Series 9 của cả hai distribution vẫn chạy ở mức v2. Trên instance ARM thay vì instance x86, câu hỏi này không phát sinh vì các mức kiến trúc vi mô là khái niệm riêng của x86-64.
Sự tự do tương tự cũng xuất hiện ở những phần khác trong AlmaLinux 10. Dự án đã bật lại hỗ trợ cho hơn 150 thiết bị mà upstream đã loại bỏ, bao gồm các PCI ID cho controller RAID và iSCSI cũ, đồng thời bật lại SPICE cho cả server và client. Frame pointer được bật mặc định, nhờ đó có thể profiling trên toàn hệ thống. Cam kết bug-for-bug không cho phép thực hiện bất kỳ thay đổi nào trong số này, vì vậy quyết định năm 2023 đã tạo ra không gian để dự án thực hiện chúng.
Làm thế nào để chuyển một server CentOS hoặc RHEL hiện có?
Rocky Linux phát hành các script chuyển đổi trong repository rocky-tools. migrate2rocky.sh chuyển đổi hệ thống Enterprise Linux 8 sang Rocky Linux 8, còn migrate2rocky9.sh thực hiện tương tự cho dòng 9. Mỗi script chỉ hoạt động trong cùng một major version. Tính đến tháng 8 năm 2026, repository chưa có script tương đương cho Enterprise Linux 10, vì vậy muốn chuyển sang Rocky Linux 10 thì phải cài đặt lại.
AlmaLinux phát hành almalinux-deploy.sh, hỗ trợ Enterprise Linux 8, 9 và 10, đồng thời chuyển đổi được từ CentOS Stream, Oracle Linux, RHEL, Rocky Linux, MiracleLinux và Virtuozzo Linux trên các kiến trúc x86_64, aarch64, ppc64le và s390x. Bạn nên đọc các giới hạn được ghi trong tài liệu trước khi bắt đầu. Chỉ boot loader GRUB2 được hỗ trợ trên các hệ thống cần boot loader. Ngoài ra, kernel tùy chỉnh như UEK (unbreakable enterprise kernel) của Oracle không được tự động gỡ bỏ, khiến máy không thể boot khi bật Secure Boot.
Để chuyển giữa các major version, AlmaLinux duy trì ELevate, được xây dựng trên framework leapp của Red Hat. Các đường dẫn được tài liệu hỗ trợ là CentOS 7 sang EL8, AlmaLinux 8 hoặc CentOS Stream 8 sang EL9, và AlmaLinux 9 hoặc CentOS Stream 9 sang EL10. Tài liệu ghi đích là EL8, EL9 hoặc EL10 thay vì nêu tên một bản phân phối cụ thể, vì bạn sẽ chọn Enterprise Linux đích.
Mọi cách chuyển đổi này đều thay đổi các release package và cài đặt lại một phần lớn của hệ thống. Trước tiên, hãy tạo snapshot tại provider. Hãy chạy quá trình chuyển đổi bên trong screen hoặc tmux theo khuyến nghị trong tài liệu của AlmaLinux, vì nếu kết nối SSH bị ngắt giữa chừng, máy có thể rơi vào trạng thái mà bạn không muốn phải debug từ rescue console.
Vậy nên chọn bản nào?
Với workload VPS thông thường, bản nào cũng được. Cả hai cài cùng các package và đều hết hỗ trợ trong cùng một năm. Hãy chọn một bản, dùng nó trên mọi server bạn vận hành, rồi không phải bận tâm thêm. Tính nhất quán quan trọng hơn khác biệt giữa hai bản, vì một fleet kết hợp sẽ tăng gấp đôi số image và nguồn errata bạn phải theo dõi. Chi phí đó tăng nhanh khi bạn quản lý nhiều server Linux cùng lúc.
Các trường hợp ngoại lệ khá hẹp, và mỗi trường hợp đều được quyết định bởi một yếu tố nằm ngoài sở thích của bạn.
- CPU của host cũ hơn Haswell, hoặc hypervisor không expose AVX2 cho guest. AlmaLinux 10 có build x86-64-v2. Rocky Linux 10 thì không.
- Một vendor mà bạn trả phí hỗ trợ chỉ định một distribution trong support matrix của họ. Hãy dùng distribution đó.
- Bạn cần hành vi giống hệt RHEL để phục vụ chứng nhận hoặc audit. Mục tiêu được Rocky Linux công bố là tương thích từng bug, còn mục tiêu của AlmaLinux thì nói rõ là không như vậy.
- Bạn đang chuyển đổi một server đang chạy thay vì dựng server mới. Bộ công cụ của AlmaLinux hiện hỗ trợ nhiều distribution nguồn hơn và nhiều major version hơn, bao gồm Enterprise Linux 10.
Nếu câu hỏi thực sự là chọn Enterprise Linux hay một nền tảng khác, thì thứ bạn đang chọn là mô hình vòng đời. Một distribution Enterprise Linux cho bạn 10 năm sử dụng cùng một bộ package mà không phải lập kế hoạch nâng version. Các bản Ubuntu long term support cho bạn 5 năm standard support, cùng supported upgrade path mỗi 2 năm. Đây là một lựa chọn khác, được phân tích trong phần so sánh Ubuntu LTS và các bản interim. Dù cài bản nào, giờ đầu tiên trên máy cũng giống nhau. Vì vậy, hãy làm theo 10 phút đầu tiên trên một VPS mới trước khi đưa bất kỳ thứ gì lên máy.
FAQ
Rocky Linux hay AlmaLinux gần Red Hat Enterprise Linux hơn?
Theo mục tiêu được công bố, Rocky Linux gần hơn. Trang chủ của dự án mô tả bản phân phối này được thiết kế để tương thích 100% với RHEL theo từng lỗi, nghĩa là nó hướng đến việc tái hiện hành vi của RHEL, kể cả các lỗi của RHEL. Ngày 13 July 2023, AlmaLinux thông báo sẽ thay vào đó nhắm đến khả năng tương thích ABI (application binary interface). Vì vậy, phần mềm được build cho RHEL vẫn chạy được trên AlmaLinux, trong khi code bên dưới có thể đã bao gồm các bản sửa lỗi mà RHEL chưa phát hành. Đối với phần mềm máy chủ thông thường, hai bản phân phối này tương đương. Nếu chứng chỉ yêu cầu hành vi đúng theo RHEL, khác biệt này là điểm cốt lõi.
Có thể chuyển từ Rocky Linux sang AlmaLinux mà không cần cài lại không?
Có, theo hướng đó. almalinux-deploy.sh của AlmaLinux liệt kê Rocky Linux 8, 9 và 10 trong số các nguồn được hỗ trợ, cùng với CentOS Stream, Oracle Linux, RHEL và MiracleLinux. Chiều ngược lại bị giới hạn hơn: repository rocky-tools của Rocky chỉ cung cấp script chuyển đổi cho Enterprise Linux 8 và 9, nên tính đến August 2026 chưa có cách chuyển tại chỗ sang Rocky Linux 10. Hãy tạo snapshot trước khi chuyển đổi và chạy quy trình từ một session vẫn tồn tại khi kết nối bị ngắt, vì quy trình này thay thế các release package và cài lại phần lớn hệ thống.
Package được build cho RHEL có chạy được trên cả hai không?
Có, đối với các RPM package thông thường và repository của bên thứ ba. Cả hai bản phân phối đều giữ ABI của RHEL và đều tự nhận diện bằng ID_LIKE="rhel centos fedora" trong /etc/os-release. Vì vậy, package hoặc installer script kiểm tra hệ thống thuộc họ Red Hat sẽ chọn đúng nhánh xử lý. Ngoại lệ nằm ở chính sách thương mại, không phải kỹ thuật: vendor có thể chỉ hỗ trợ các bản phân phối được nêu trong support matrix, dù package vẫn cài đặt và chạy được trên cả hai. Nếu bạn trả phí hỗ trợ, hãy dựa vào support matrix.
Nên dùng bản nào trên VPS giá rẻ có CPU cũ?
AlmaLinux, nếu bạn muốn dùng dòng 10. RHEL 10 nâng mức CPU tối thiểu của x86-64 lên cấp microarchitecture v3. Mức này cần CPU tương đương Intel Haswell hoặc AMD Excavator, và Rocky Linux 10 cũng theo mức yêu cầu đó. AlmaLinux 10 cung cấp thêm một bản build x86-64-v2 cho phần cứng cũ hơn, với thời hạn cập nhật bảo mật 10 years. Hãy kiểm tra CPU mà instance của bạn cung cấp trước khi quyết định, vì máy ảo nhìn thấy model CPU do hypervisor cung cấp, không phải lúc nào cũng thấy đầy đủ instruction set của máy host. Dòng 9 của cả hai bản phân phối vẫn chạy được trên phần cứng v2.