Sự Cố Lưu Trữ Khiến Tôi Phải Suy Nghĩ Lại Mọi Thứ
Sáu tháng trước, một trong những VPS sản xuất của tôi báo lỗi đầy đĩa lúc 3 giờ sáng. Không có gì lạ — ngoại trừ filesystem root đang ở mức 94% trong khi partition tôi để dành cho backup gần như chưa dùng, chỉ 12%.
LVM truyền thống về mặt kỹ thuật có thể giải quyết được, nhưng sau khi quản lý hơn 10 VPS Linux trong ba năm, tôi đã học theo cách khó nhất rằng thao tác resize dưới áp lực chính là lúc xảy ra sai sót. Sự cố đó thúc đẩy tôi nghiêm túc đánh giá Stratis Storage — thứ tôi đã bỏ qua từ khi nó xuất hiện trong RHEL 8.
Sáu tháng sau, tôi có cái nhìn rõ ràng hơn về nơi Stratis phát huy tác dụng và nơi nó còn hạn chế. Thực tế phức tạp hơn những gì tài liệu chính thức mô tả.
Tại Sao Quản Lý Lưu Trữ Truyền Thống Không Còn Đủ
Nguyên nhân gốc rễ của sự cố 3 giờ sáng không phải là thiếu đĩa — mà là sự cứng nhắc của partition. Cụ thể:
- Partition tĩnh được chia khi provisioning server, nhiều tháng trước khi các mẫu sử dụng thực tế trở nên rõ ràng
- Logical volume LVM có thể được mở rộng, nhưng đòi hỏi can thiệp thủ công và tiềm ẩn rủi ro khi resize trên filesystem đang chạy
- Không có nén dữ liệu tích hợp — tôi đang trả tiền cho lưu trữ mà đáng ra có thể tiết kiệm được
- LVM có hỗ trợ snapshot nhưng cồng kềnh và dễ cấu hình sai
Về cơ bản, các công cụ lưu trữ Linux truyền thống được thiết kế cho thời đại mà bố cục đĩa được xác định từ đầu và hiếm khi thay đổi. Các workload hiện đại — container, database, log tăng trưởng không thể đoán trước — không còn phù hợp với mô hình đó nữa.
ZFS giải quyết hầu hết những vấn đề này một cách xuất sắc, nhưng vấn đề bản quyền khiến nó không có mặt trong kernel tree mặc định trên các hệ thống RHEL/CentOS/AlmaLinux. Btrfs có trong kernel và ngày càng mạnh hơn, nhưng vẫn còn tiếng tăm không ổn định dưới tải ghi cao — các vấn đề RAID 5/6 là có thật, được ghi chép đầy đủ, và chưa được giải quyết hoàn toàn tính đến kernel 6.x. Đó là khoảng trống mà Stratis đang cố lấp đầy.
Stratis Thực Sự Là Gì (và Không Phải Là Gì)
Stratis không phải là một filesystem mới. Đây là lớp quản lý lưu trữ cục bộ nằm trên các công nghệ hiện có: device-mapper thin provisioning xử lý việc mở rộng pool, XFS xử lý filesystem thực tế, và stratisd là daemon điều phối mọi thứ thông qua D-Bus.
Xây dựng trên XFS có nghĩa là Stratis kế thừa hàng thập kỷ độ trưởng thành của filesystem trong khi bổ sung các tính năng mà XFS đơn thuần không thể cung cấp:
- Thin provisioning: Filesystem báo cáo nhiều dung lượng hơn thực tế tồn tại, mở rộng theo yêu cầu khi pool tăng trưởng
- Snapshot: Snapshot copy-on-write mà không cần phân bổ không gian trước
- Storage pooling: Nhiều block device xuất hiện như một pool duy nhất
- Mã hóa tùy chọn: Tích hợp Clevis/Tang cho mã hóa đĩa ràng buộc mạng
Cần nói thẳng về những hạn chế: nén dữ liệu gốc không có trong Stratis 3.x. Tính năng này có trong lộ trình nhưng chưa được phát hành. Tương tự với deduplication và bất kỳ thứ gì vượt ra ngoài dự phòng cơ bản cho RAID. Nếu nén dữ liệu là ưu tiên chính của bạn ngay lúc này, ZFS hoặc Btrfs mới là câu trả lời thành thật.
So Sánh Các Lựa Chọn: Stratis vs. LVM vs. ZFS vs. Btrfs
LVM + XFS/ext4
Vẫn là lựa chọn trưởng thành nhất hiện có. Thao tác resize là thủ công, không có snapshot gốc ở tầng filesystem, nhưng ổn định tuyệt đối và được hỗ trợ ở khắp nơi. Tốt nhất cho các cài đặt cần kiểm soát tối đa và ít trừu tượng hóa hơn sự tiện lợi.
ZFS trên Linux (OpenZFS)
Đầy đủ tính năng với nén, dedup, RAID-Z và công cụ snapshot xuất sắc. Yêu cầu bộ nhớ tăng nhanh — chỉ riêng ARC cache có thể chiếm 1–4 GB trên pool bận rộn, khá đau với các VPS nhỏ hơn. Gói zfs-dkms hoạt động tốt trên Ubuntu/Debian nhưng gây khó khăn khi cập nhật kernel trên các hệ thống RHEL. Vấn đề bản quyền không đáng lo cho sử dụng cá nhân hay mã nguồn mở; chỉ quan trọng nếu tổ chức bạn có ràng buộc pháp lý xung quanh CDDL.
Btrfs
Có trong kernel, giàu tính năng, và ngày càng ổn định cho các cài đặt đĩa đơn và RAID 1. Dùng cho máy tính cá nhân? Không có gì phàn nàn. Server sản xuất xử lý thông lượng ghi cao liên tục — chẳng hạn, một instance PostgreSQL bận rộn hoặc container host với hàng trăm image layer — tôi vẫn muốn một giai đoạn burn-in cẩn thận trước khi cam kết.
Stratis
Phù hợp nhất cho môi trường RHEL/AlmaLinux/Fedora khi bạn muốn tính năng lưu trữ hiện đại mà không cần tranh luận về bản quyền ZFS. Lệnh CLI đơn giản hơn đáng kể so với LVM tương đương, và thin provisioning giải quyết trực tiếp vấn đề phải xác định kích thước partition từ đầu. Không phải lựa chọn đúng nếu nén dữ liệu là không thể thiếu ngay lúc này.
Cài Đặt Stratis: Ví Dụ Thực Tế
Dưới đây là cài đặt chính xác tôi sử dụng trên server AlmaLinux 9 mới. Trước khi chạm vào bất kỳ hệ thống sản xuất nào, tôi đã thử chuỗi lệnh này trên VM cục bộ — một thói quen đã cứu tôi khỏi nhiều hơn một sai lầm đáng xấu hổ.
Cài Đặt
# Cài đặt daemon stratisd và công cụ CLI
sudo dnf install stratisd stratis-cli -y
# Kích hoạt và khởi động daemon
sudo systemctl enable --now stratisd
# Kiểm tra trạng thái hoạt động
sudo systemctl status stratisdTạo Storage Pool
Thêm hai block device vào một pool là cốt lõi của mô hình thin provisioning. Trong ví dụ này, /dev/sdb và /dev/sdc mỗi cái 20 GB, cho tổng pool vật lý 40 GB:
# Liệt kê các block device khả dụng trước
lsblk
# Tạo pool tên 'datapool' với hai thiết bị
sudo stratis pool create datapool /dev/sdb /dev/sdc
# Xác nhận pool đã được tạo
sudo stratis pool listKết quả mong đợi:
Name Total Physical Properties UUID
datapool 40 GiB / 592 MiB in use ~Ca,~Cr,~Op a1b2c3d4-...Các cờ ~Ca,~Cr,~Op nghĩa là cache, mã hóa và overprovisioning đều tắt — cài đặt mặc định hợp lý cho lần đầu tiên cài đặt.
Tạo Filesystem
Thin provisioning trở nên thú vị ở đây. Một filesystem có thể báo cáo 1 TiB cho hệ điều hành dù pool vật lý chỉ có 40 GB. Nghe có vẻ đáng lo cho đến khi bạn hiểu rằng XFS sẽ không thực sự tiêu thụ không gian đó — nó chỉ tăng khi dữ liệu được ghi:
# Tạo filesystem trong pool
sudo stratis filesystem create datapool appdata
# Liệt kê các filesystem
sudo stratis filesystem list
# Mount filesystem
sudo mkdir /mnt/appdata
sudo mount /dev/stratis/datapool/appdata /mnt/appdata
# Kiểm tra dung lượng được báo cáo (sẽ hiển thị 1TiB — đây là bình thường)
df -h /mnt/appdataĐể tự động mount khi khởi động lại, thêm vào /etc/fstab:
# Lấy UUID
sudo blkid /dev/stratis/datapool/appdata
# Thêm vào /etc/fstab
UUID=<your-uuid> /mnt/appdata xfs defaults,x-systemd.requires=stratisd.service 0 0Đừng bỏ qua tùy chọn x-systemd.requires=stratisd.service. Nó yêu cầu systemd khởi động stratisd trước khi thực hiện mount này. Bỏ sót điều này, và bạn sẽ mất 20 phút debug lỗi khởi động như tôi đã từng — trong lần deploy đầu tiên của mình.
Thêm Dung Lượng Vào Pool
Đây là tính năng lẽ ra đã cứu tôi lúc 3 giờ sáng. Khi pool sắp đầy, thêm một đĩa mới chỉ cần một lệnh — không cần unmount, không cần resize, không cần lo lắng:
# Thêm block device mới vào pool hiện có
sudo stratis pool add-data datapool /dev/sdd
# Pool tự động mở rộng — không cần resize filesystem
sudo stratis pool listCác filesystem trong pool thấy dung lượng bổ sung ngay lập tức. Trong thực tế, tôi đã thêm đĩa 20 GB vào pool đang chạy với ghi dữ liệu tích cực — thao tác hoàn thành trong chưa đầy hai giây và log ứng dụng không ghi nhận bất kỳ gián đoạn nào.
Snapshot
# Tạo snapshot trước khi thực hiện thao tác rủi ro
sudo stratis filesystem snapshot datapool appdata appdata-snap-20260819
# Liệt kê tất cả filesystem bao gồm snapshot
sudo stratis filesystem list datapool
# Mount snapshot để kiểm tra dữ liệu
sudo mkdir /mnt/snap
sudo mount /dev/stratis/datapool/appdata-snap-20260819 /mnt/snap
# Rollback: unmount fs đang chạy, snapshot trở thành origin mới
# (cần xóa và tạo lại — chưa có lệnh rollback đơn lẻ)Sau Sáu Tháng: Đánh Giá Thành Thật
Thin provisioning và mở rộng pool hoạt động chính xác như quảng cáo. Ba server riêng biệt, ba lần thêm dung lượng giữa chừng hoạt động, không có phút downtime nào — điều đó một mình đã đủ để biện minh cho việc áp dụng trong trường hợp của tôi.
Tuy nhiên, vẫn còn những vấn đề thô, và đáng biết trước. Rollback snapshot còn yếu so với ZFS — trong khi zfs rollback là một lệnh duy nhất, Stratis đòi hỏi xóa và tạo lại filesystem từ snapshot. Giám sát mức dùng pool là thủ công trừ khi bạn tự xây dựng cảnh báo quanh đầu ra của stratis pool list; không có thông báo ngưỡng tích hợp trong stratisd 3.x. Và nén dữ liệu vẫn chưa được phát hành — nếu đó là yếu tố quyết định, Stratis chưa sẵn sàng.
Đối với các server thuộc họ RHEL chạy workload container hóa hoặc database với mẫu tăng trưởng không thể đoán trước, Stratis nằm ở vị trí trung gian hữu ích. Chi phí quản lý so với LVM thuần là thấp hơn đáng kể, lệnh dễ đọc, và thin provisioning giải quyết trực tiếp vấn đề phân chia partition đã cắn tôi lúc 3 giờ sáng.
Hãy bắt đầu với một server không quan trọng. Chạy trong một tháng. Kiểm tra log stratisd, theo dõi mức dùng pool, thực hiện bài kiểm tra snapshot và phục hồi. Thay đổi lưu trữ luôn cần được xác nhận trong môi trường cụ thể của bạn trước khi đặt dữ liệu quan trọng vào đó — Stratis cũng không ngoại lệ quy tắc đó, dù giao diện CLI có vẻ thân thiện đến đâu.
