My Awesome Project

Appearance

Filestore CSI — Shared NFS cho ReadWriteMany ​

Vì sao Filestore tồn tại: bài toán nhiều writer ​

Block storage (PD, Hyperdisk) giải tốt single-writer, nhưng đụng tường ngay khi cần nhiều Pod ghi đồng thời vào cùng một filesystem — vì filesystem cục bộ không cluster-aware sẽ corrupt (file 3). Filestore là câu trả lời được quản lý của GCP cho bài toán này: một NFS server được quản lý, cho ReadWriteMany thật sự, nơi nhiều node mount và ghi cùng lúc một cách an toàn vì có một server tập trung làm trọng tài (Filestore for GKE).

Điểm cần hiểu trước khi chọn Filestore: nó không phải block storage nhanh hơn — nó là một loại storage khác về bản chất. I/O đi qua network stack (NFS protocol over TCP), nên latency cao hơn block device cục bộ; bù lại, nó cho khả năng chia sẻ mà block không bao giờ làm an toàn được. Chọn Filestore là một quyết định kiến trúc ("tôi cần shared write"), không phải quyết định hiệu năng ("tôi cần nhanh hơn").

CSI driver filestore.csi.storage.gke.io là add-on managed, hỗ trợ dynamic provisioning từ GKE 1.27+ (Filestore for GKE).

Khi nào thật sự cần Filestore — và khi nào không ​

Trước khi đi vào tier, phải sàng lọc: bạn có thật sự cần RWX không? Đây là nơi nhiều team lãng phí tiền, vì Filestore đắt hơn PD đáng kể.

Cần Filestore khi:

  • Nhiều Pod ghi đồng thời vào cùng tập file (CMS, media processing, shared upload directory).
  • Workload legacy giả định một POSIX filesystem chia sẻ (lift-and-shift app cũ).
  • Pipeline nhiều bước, mỗi bước là một Pod, cùng đọc/ghi một thư mục làm việc.

Không cần Filestore (dùng cái khác rẻ hơn) khi:

  • Chỉ một Pod ghi → dùng PD/Hyperdisk (RWO), rẻ hơn nhiều.
  • Nhiều Pod chỉ đọc dữ liệu bất biến → dùng Cloud Storage FUSE (file 7) hoặc Hyperdisk ML ROX (file 4).
  • Cần throughput cực cao cho AI/ML → Parallelstore/Lustre (file 8) phù hợp hơn về metadata IOPS.

Sàng lọc này quan trọng vì "cần shared storage" thường thực ra là "nhiều reader" hoặc "object store là đủ" — và cả hai đều có lựa chọn rẻ hơn Filestore.

Service tiers: capacity, hiệu năng, HA ​

Filestore có nhiều tier, khác nhau về phương tiện (HDD/SSD), phạm vi failure domain (zonal/regional), capacity và hiệu năng. Chọn tier sai là nguồn lãng phí (tier quá cao) hoặc bottleneck (tier quá thấp) phổ biến nhất.

TierPhương tiệnFailure domainCapacity điển hìnhĐặc tính
BASIC_HDDHDDZonalTừ ~1 TiBRẻ nhất, throughput tuần tự ổn, IOPS thấp
BASIC_SSDSSDZonalTừ ~2.5 TiBIOPS/throughput cao hơn, latency thấp hơn
Zonal (Enterprise-class)SSDZonalDải rộng, scale theo capacityHiệu năng cao, scale-out
Enterprise / RegionalSSDRegional (multi-zone)Dải rộngHA qua nhiều zone, hiệu năng cao nhất

Hai trục quyết định khi chọn tier:

Trục failure domain. BASIC và Zonal tier sống trong một zone — mất zone là mất availability (dữ liệu có backup nhưng instance down). Tier Enterprise/Regional replicate qua nhiều zone trong region, survive zonal failure — bắt buộc cho shared storage critical cần HA. Nếu workload chịu được downtime khi zone lỗi (và restore từ backup), tier zonal rẻ hơn nhiều.

Trục hiệu năng-capacity. Với Filestore, hiệu năng thường scale theo capacity (giống PD) — instance lớn hơn cho throughput/IOPS cao hơn. Hệ quả: nếu cần hiệu năng cao nhưng dữ liệu ít, vẫn phải provision capacity lớn để đạt hiệu năng — một sự lãng phí mà Multishares (phần sau) và VolumeAttributesClass giúp giảm. Tier Enterprise/Zonal mới hỗ trợ scale hiệu năng động qua VolumeAttributesClass (Filestore for GKE) — tách phần nào hiệu năng khỏi capacity, tương tự tinh thần Hyperdisk.

yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-enterprise
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: enterprise          # regional, HA
  network: default
volumeBindingMode: Immediate   # Filestore không zonal-pinned như block
allowVolumeExpansion: true

Lưu ý volumeBindingMode: Filestore không bị "đóng đinh zone" như zonal block device theo cùng cách, nên Immediate thường chấp nhận được; nhưng với tier zonal vẫn nên cân nhắc topology để mount gần node. Đọc kỹ tài liệu tier cụ thể.

Multishares for GKE: gộp nhiều PVC nhỏ vào một instance ​

Filestore có một ràng buộc chi phí khó chịu: capacity tối thiểu mỗi instance khá lớn (ví dụ BASIC_HDD từ ~1 TiB). Nếu mỗi team/namespace cần một shared volume nhỏ (vài chục GB), tạo một instance riêng cho mỗi cái nghĩa là trả tiền cho hàng TB không dùng — cực kỳ lãng phí ở multi-tenant scale.

Multishares for GKE giải đúng bài này: một instance Filestore (Enterprise) duy nhất được chia thành nhiều share nhỏ, mỗi share là một PVC riêng (Filestore for GKE). Thay vì N instance lớn, bạn có một instance lớn phục vụ N PVC nhỏ — CSI driver quản lý việc cấp share động từ instance chung.

Lợi ích: chi phí giảm mạnh ở môi trường nhiều shared volume nhỏ (CI/CD workspace per-team, dev environment, multi-tenant SaaS với mỗi tenant một share nhỏ). Một "storage pool" view thống nhất qua nhiều share, sizing linh hoạt.

Trade-off phải quản: các share chia sẻ hiệu năng của instance chung — một share "ồn ào" (noisy neighbor) có thể ngốn throughput ảnh hưởng share khác. Cần monitor utilization instance và đặt giới hạn hợp lý số share mỗi instance. Multishares hợp cho nhiều volume nhỏ pattern không tương quan; không hợp khi một share cần đảm bảo hiệu năng riêng biệt.

yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-multishare
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: enterprise
  multishare: "true"
  max-volume-size: "128Gi"     # mỗi share tối đa
allowVolumeExpansion: true

Volume snapshots và backup ​

Filestore CSI hỗ trợ tạo CSI volume snapshot, được hiện thực thành Filestore backup ở tầng GCP (Filestore for GKE). Dùng để bảo vệ dữ liệu, restore về điểm thời gian, hoặc clone. Một lưu ý quan trọng về DR: Backup for GKE (file 9) KHÔNG backup volume Filestore — nó chỉ backup PD (Backup for GKE). Nghĩa là với Filestore, bạn phải tự thiết lập backup qua CSI snapshot / Filestore backup, không thể dựa vào Backup for GKE như với PD. Đây là một khoảng trống dễ bị bỏ sót khi lên kế hoạch DR cho cluster có cả PD lẫn Filestore.

NFS tradeoffs: latency, consistency, locking ​

Vì Filestore là network filesystem, nó mang theo các đặc tính của NFS mà block storage không có — phải hiểu để tránh bất ngờ:

  • Latency cao hơn block. Mỗi thao tác file đi qua TCP tới NFS server. Với workload nhiều thao tác metadata nhỏ (tạo/xóa hàng nghìn file nhỏ), latency cộng dồn lớn. Filestore tối ưu cho file vừa-lớn hơn là hàng triệu file tí hon — workload sau nên cân nhắc Parallelstore (metadata IOPS cao hơn, file 8).

  • Consistency model của NFS. NFS có close-to-open consistency: một client thấy thay đổi của client khác sau khi file được đóng và mở lại, không phải tức thì. Ứng dụng giả định strong consistency tức thì giữa các node có thể gặp dữ liệu stale. Đa số app ổn, nhưng cần biết khi debug "tại sao node B chưa thấy file node A vừa ghi".

  • File locking qua network. NFS hỗ trợ locking nhưng phức tạp và có thể là điểm tranh chấp ở scale; locking qua network chậm và dễ deadlock hơn locking cục bộ. Tránh thiết kế phụ thuộc nặng vào fine-grained file lock trên NFS.

  • Throughput chia sẻ. Tất cả client chia sẻ throughput của instance. Nhiều Pod đọc/ghi nặng cùng lúc bão hòa instance — cần provision capacity/tier đủ và monitor.

So sánh block-device CSI vs NFS CSI ở tầng kernel: với block, kernel mount một filesystem cục bộ (ext4/xfs) trên một thiết bị khối, I/O đi thẳng tới block layer — nhanh, nhưng single-node. Với NFS, kernel dùng NFS client gửi RPC qua network tới server — chậm hơn, nhưng multi-node. Đây là đánh đổi nền tảng: block = nhanh + độc quyền, file = chậm hơn + chia sẻ. Không có loại nào "tốt hơn"; chúng phục vụ access pattern khác nhau.

Real-world scenario: nền tảng CMS đa-tenant ​

Một SaaS quản lý nội dung, mỗi tenant có một thư mục media được nhiều Pod (web, worker xử lý ảnh, worker transcode video) cùng đọc/ghi:

  • Yêu cầu: RWX thật (nhiều Pod ghi cùng lúc), nhiều tenant nhỏ, cần HA.
  • Lựa chọn: Filestore Enterprise (regional, HA) với Multishares — mỗi tenant một share PVC nhỏ từ instance chung, thay vì một instance đắt đỏ per-tenant.
  • Backup: CSI snapshot định kỳ → Filestore backup (vì Backup for GKE không cover Filestore).
  • Giám sát: utilization instance để phát hiện noisy tenant, đặt max-volume-size hợp lý.

Nếu thay vào đó dùng PD per-tenant, không thể cho nhiều Pod ghi đồng thời; nếu dùng instance Filestore riêng per-tenant, chi phí nổ tung. Multishares là điểm cân bằng đúng cho pattern "nhiều shared volume nhỏ".

Common mistakes / anti-patterns ​

  • Dùng Filestore khi chỉ cần nhiều reader. Trả tiền RWX trong khi ROX (GCS FUSE/Hyperdisk ML) đủ và rẻ hơn. Phòng tránh: sàng lọc "ghi đồng thời thật không?" trước khi chọn Filestore.

  • Tier Enterprise/Regional cho mọi thứ. Chi phí HA regional cho workload không cần HA. Phòng tránh: chọn tier theo nhu cầu failure domain thật; zonal rẻ hơn nhiều khi chịu được downtime + restore.

  • Một instance Filestore per shared volume nhỏ. Lãng phí capacity tối thiểu lớn. Hệ quả ở scale: hóa đơn gấp nhiều lần. Phòng tránh: Multishares gộp nhiều share nhỏ vào instance chung.

  • Quên rằng Backup for GKE không cover Filestore. Tưởng đã có DR nhưng Filestore không được backup. Hệ quả: mất dữ liệu shared khi cần restore. Phòng tránh: thiết lập CSI snapshot/Filestore backup riêng cho Filestore.

  • Thiết kế phụ thuộc fine-grained NFS locking / strong consistency tức thì. Deadlock hoặc dữ liệu stale. Phòng tránh: hiểu close-to-open consistency của NFS; tránh lock nặng qua network.

  • Đặt workload hàng triệu file nhỏ trên Filestore. Latency metadata cộng dồn giết hiệu năng. Phòng tránh: Parallelstore cho workload metadata-IOPS cao (file 8).

Official references ​