Parallelstore & Managed Lustre — Filesystem Song Song cho AI/ML
Vì sao filesystem thường không đủ cho AI/ML quy mô lớn
Khi training một mô hình trên hàng trăm GPU/TPU đọc cùng một dataset, storage trở thành bottleneck theo cách mà Filestore và GCS FUSE không giải nổi: hàng trăm worker đọc song song hàng triệu file nhỏ, mỗi bước cần throughput aggregate cực lớn và metadata IOPS cực cao (mở/đóng/stat hàng triệu file). NFS (Filestore) đụng trần throughput của một instance; GCS FUSE đụng latency object store ở metadata. Đây là lý do tồn tại của parallel filesystem — Parallelstore và Managed Lustre — kiến trúc storage phân tán nơi dữ liệu và metadata được sharding qua nhiều node storage, cho throughput và IOPS scale gần tuyến tính với quy mô.
Điểm phân biệt cốt lõi: filesystem song song không có một "server tập trung" làm nút thắt như NFS; thay vào đó client nói chuyện song song với nhiều storage target. Đây là kiến trúc của HPC truyền thống (Lustre đã chạy các siêu máy tính lớn nhất thế giới hàng thập kỷ), nay được GCP cung cấp dạng managed cho AI/ML. File này không dạy bạn vận hành Lustre cluster — nó dạy khi nào cần parallel filesystem thay vì các lựa chọn rẻ hơn, và các đặc tính vận hành (đặc biệt mô hình độ bền) phải hiểu để không mất dữ liệu.
Parallelstore: kiến trúc và mô hình độ bền
Parallelstore là filesystem phân tán low-latency được quản lý, tối ưu cho "AI/ML training workloads, đặc biệt với file nhỏ và random read" (Parallelstore for GKE). Nó nền tảng trên DAOS (Distributed Asynchronous Object Storage), cung cấp full POSIX semantics, metadata operation throughput cao, scale tới ~1 TB/s read và hàng triệu IOPS với latency sub-millisecond (Parallelstore for GKE).
Mô hình độ bền — đọc kỹ phần này. Parallelstore được backing bởi Local SSD với erasure coding 2+1, và phải được coi là temporary storage với mean-time-to-data-loss khoảng hai tháng (Parallelstore for GKE). Đây là sự thật quan trọng nhất về Parallelstore: nó KHÔNG phải nơi lưu dữ liệu duy nhất. Erasure coding 2+1 chịu được mất một storage target, nhưng độ bền tổng thể không ngang PD/GCS — nó là storage hiệu năng cao, tạm thời.
Hệ quả kiến trúc bắt buộc: nguồn chân lý của dữ liệu phải nằm trên Cloud Storage, Parallelstore là layer hiệu năng cao được nạp từ GCS trước khi training và đẩy kết quả về GCS sau. Parallelstore tích hợp sẵn với GCS để import/export dữ liệu phục vụ đúng mô hình này. Coi Parallelstore là "RAM cho dataset" — nhanh, nhưng không bền; dữ liệu thật sống ở GCS.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: parallelstore-rwx
provisioner: parallelstore.csi.storage.gke.io
parameters:
# nạp dữ liệu từ GCS, đẩy kết quả về GCS
volumeBindingMode: Immediate
allowVolumeExpansion: falseCSI driver Parallelstore hỗ trợ dynamic provisioning, access mode RWX/ROX/RWO, tích hợp StatefulSet và Deployment (Parallelstore for GKE). Ràng buộc cần nhớ: capacity dải 12.000–100.000 GiB, deploy theo zone cụ thể, không hỗ trợ ARM; trước GKE 1.32.3 mỗi Pod chỉ một instance, từ 1.32.3 hỗ trợ nhiều instance per Pod qua node mount (Parallelstore for GKE).
Managed Lustre: HPC throughput cho AI/ML bền hơn
Managed Lustre cung cấp Lustre được quản lý — parallel filesystem chuẩn HPC — cho workload throughput cao: AI/ML training và HPC simulation (GKE storage overview). Khác Parallelstore ở định vị: Managed Lustre nhắm tới persistent, scalable, multi-Pod file access với throughput cao, RWX bền vững hơn — phù hợp khi cần một shared filesystem hiệu năng cao tồn tại lâu qua nhiều job, không chỉ scratch tạm cho một training run.
Lustre là công nghệ trưởng thành nhất trong các parallel filesystem (chạy phần lớn top-500 supercomputer), với mô hình tách metadata server (MDS) và object storage target (OST) cho phép scale metadata và data độc lập. Managed Lustre ẩn đi sự phức tạp vận hành Lustre (vốn nổi tiếng khó) sau một dịch vụ managed với CSI driver cho GKE.
Khi nào Lustre thay vì Parallelstore: khi cần filesystem bền hơn và tồn tại lâu dùng chung cho nhiều job/team, throughput HPC cao, và chấp nhận mô hình vận hành Lustre. Parallelstore nghiêng về scratch hiệu năng cực cao, tạm thời, gắn vòng đời một training run với latency thấp nhất cho file nhỏ/random read.
Khung chọn: Parallelstore vs Lustre vs Filestore vs GCS FUSE
Bốn lựa chọn shared file storage, mỗi cái tối ưu một điểm khác trên trục throughput–metadata IOPS–độ bền–chi phí:
| Tiêu chí | GCS FUSE | Filestore | Parallelstore | Managed Lustre |
|---|---|---|---|---|
| Bản chất | Object store giả lập FS | NFS managed | Parallel FS (DAOS) | Parallel FS (Lustre) |
| Throughput aggregate | Trung bình (cache) | Theo instance (giới hạn) | Rất cao (~1 TB/s) | Rất cao (HPC) |
| Metadata IOPS | Thấp (object) | Trung bình | Rất cao | Rất cao |
| File nhỏ / random read | Kém | Trung bình | Tối ưu | Tốt |
| Độ bền | Cao (GCS) | Cao (tier regional) | Thấp (temporary, ~2 tháng MTTDL) | Cao hơn Parallelstore |
| Chi phí | Thấp | Cao | Cao | Cao |
| Use case chủ đạo | Đọc dataset bất biến | Shared write POSIX | Scratch training tốc độ tối đa | HPC/AI shared FS bền |
Quy trình chọn thực dụng cho workload AI/ML:
- Dataset chỉ đọc, chi phí là ưu tiên, throughput trung bình đủ? → GCS FUSE với cache (file 7).
- Cần shared write POSIX thông thường, nhiều file vừa? → Filestore (file 6).
- Training quy mô lớn, hàng triệu file nhỏ, metadata IOPS cực cao, cần tốc độ tối đa, chấp nhận tạm? → Parallelstore (nguồn chân lý vẫn ở GCS).
- Cần parallel filesystem bền tồn tại lâu cho nhiều job/HPC? → Managed Lustre.
Sai lầm chi phí phổ biến: nhảy thẳng sang Parallelstore/Lustre cho mọi workload AI/ML vì "nó nhanh nhất", trong khi nhiều workload chỉ cần GCS FUSE + cache đủ tốt với chi phí thấp hơn nhiều. Parallel filesystem chỉ xứng đáng khi metadata IOPS hoặc aggregate throughput thật sự là bottleneck đã đo được — không phải mặc định.
Tích hợp GCS: pattern nạp/đẩy dữ liệu
Vì Parallelstore là temporary, pattern dùng đúng luôn xoay quanh GCS làm nguồn bền:
- Import từ GCS: trước training, nạp dataset từ bucket vào Parallelstore (Parallelstore có cơ chế import/export GCS tích hợp). Một lần nạp, nhiều epoch đọc với throughput parallel filesystem.
- Training đọc/ghi Parallelstore: worker đọc dataset và ghi checkpoint trung gian vào Parallelstore — tốc độ cực cao, metadata IOPS đáp ứng hàng triệu file.
- Export về GCS: checkpoint/model quan trọng được đẩy ngược về GCS định kỳ và khi xong — đây là dữ liệu bền thật.
- Teardown: sau training run, Parallelstore instance có thể được giải phóng (tiết kiệm chi phí) vì dữ liệu thật đã ở GCS.
Pattern này biến Parallelstore thành một "cache hiệu năng cao có vòng đời job", không phải kho lưu trữ. Đây là cách duy nhất an toàn để dùng nó cho dữ liệu quan trọng, vì mô hình độ bền ~2 tháng MTTDL không cho phép coi nó là nguồn duy nhất.
Real-world scenario: training LLM trên 256 GPU
Một job training mô hình ngôn ngữ lớn, 256 GPU đọc dataset 30TB gồm hàng chục triệu shard nhỏ:
- Bottleneck: với GCS FUSE, metadata operations (mở hàng triệu shard) và throughput aggregate không theo kịp 256 worker — GPU idle chờ data. Với Filestore, một instance NFS không cấp đủ aggregate throughput cho 256 client.
- Giải pháp: Parallelstore — nạp 30TB từ GCS một lần, 256 worker đọc song song với metadata IOPS và throughput đủ giữ GPU bận. Checkpoint ghi vào Parallelstore rồi export GCS định kỳ.
- Độ bền: dataset gốc và checkpoint cuối luôn ở GCS; Parallelstore chỉ là layer tốc độ. Nếu instance Parallelstore mất dữ liệu, re-import từ GCS.
- Chi phí: Parallelstore chỉ tồn tại trong thời gian training run; giải phóng sau khi xong.
Đây là use case mà parallel filesystem thật sự xứng đáng — metadata IOPS và aggregate throughput là bottleneck đo được, quy mô đủ lớn để chi phí Parallelstore được biện minh bởi GPU utilization tăng. Với một job nhỏ vài GPU, GCS FUSE + cache sẽ là lựa chọn đúng và rẻ hơn nhiều.
Common mistakes / anti-patterns
Coi Parallelstore là kho lưu trữ bền. MTTDL ~2 tháng nghĩa là sẽ mất dữ liệu. Hệ quả: mất dataset/checkpoint nếu không có bản GCS. Phòng tránh: GCS luôn là nguồn chân lý; Parallelstore chỉ là cache job-scoped.
Mặc định parallel filesystem cho mọi AI/ML. Chi phí cao cho workload không thật sự bị bottleneck metadata/throughput. Phòng tránh: chỉ dùng khi đã đo được bottleneck; mặc định GCS FUSE + cache.
Quên export checkpoint về GCS. Job dài, instance mất dữ liệu, mất toàn bộ tiến độ. Phòng tránh: export GCS định kỳ, coi Parallelstore như ephemeral.
Bỏ qua ràng buộc capacity/zone/ARM. Provision fail hoặc không khớp node. Phòng tránh: kiểm tra dải 12.000–100.000 GiB, zone, kiến trúc node trước khi thiết kế.
Dùng Parallelstore cho workload file lớn tuần tự đơn giản. Lãng phí năng lực metadata IOPS không cần. Phòng tránh: file lớn tuần tự → GCS FUSE/Hyperdisk Throughput rẻ hơn; Parallelstore cho file nhỏ/random read quy mô lớn.
Official references
- Parallelstore for GKE — kiến trúc DAOS, mô hình temporary, CSI, access modes, ràng buộc.
- Parallelstore overview — hiệu năng, erasure coding, tích hợp GCS.
- GKE storage overview — định vị Managed Lustre và file storage cho AI/ML.
- Managed Lustre for GKE — parallel filesystem HPC managed.
- Cloud Storage FUSE CSI driver — lựa chọn đối chiếu cho dataset đọc.