Kiến trúc Filestore & Service Tiers

Tại sao quan trọng trong production

Vấn đề cốt lõi mà Filestore giải quyết không phải là "lưu trữ file" — điều đó Cloud Storage đã làm được — mà là shared POSIX filesystem access: nhiều compute instance cùng mount một filesystem, cùng thấy thay đổi của nhau theo thời gian thực, với semantics đầy đủ của filesystem (rename atomic, hard link, directory structure, file lock).

Điều này không thể đạt được với object storage (Cloud Storage) do object storage không có POSIX filesystem semantics. Nó cũng không thể đạt được với block storage (Persistent Disk) vì ReadWriteMany chỉ hỗ trợ đọc, không hỗ trợ multi-writer concurrent write an toàn.

Trong production, Filestore xuất hiện tự nhiên ở các workload sau:

• Shared content repository: Web servers cluster cùng đọc static assets từ một NFS share
• ML/AI pipeline: Training data chia sẻ giữa nhiều worker pod mà không cần copy
• Media processing: Render farm với nhiều node đọc raw footage và ghi output
• Legacy app migration: On-premise app vốn dùng NFS, cần lift-and-shift lên cloud

Hiểu Filestore ở mức kiến trúc là quan trọng vì chọn sai tier → IO bottleneck không thể giải quyết sau khi deploy.

Internal model — Filestore vận hành như thế nào

NFS Server Model

Filestore là managed NFS server — không phải distributed filesystem. Điểm này quan trọng và thường bị hiểu sai.

Khi bạn tạo một Filestore instance, Google provision một (hoặc nhiều, tùy tier) máy chủ NFS chuyên dụng với phần cứng storage tương ứng tier bạn chọn. Instance này có:

• Một địa chỉ IP riêng (private IP trong VPC của bạn)
• Một hoặc nhiều file share (export path), mặc định là /vol1
• Phần cứng storage: SSD hoặc HDD, tùy tier
• Network interface kết nối vào VPC của bạn

Client (VM hoặc pod) mount share này qua NFS protocol:

mount -t nfs -o vers=3 10.x.x.x:/vol1 /mnt/filestore
# hoặc NFSv4.1 (chỉ Zonal, Regional, Enterprise)
mount -t nfs -o vers=4.1 10.x.x.x:/vol1 /mnt/filestore

Tất cả IO đi qua network từ client đến NFS server — đây là bản chất của NFS. Không có dữ liệu nào được cache phía client theo mặc định (NFS có coherent caching nhưng với VFS cache, không phải persistent cache).

Data Path trong Filestore

Khi một client ghi dữ liệu, path đầy đủ là:

Application write()
    │
    ▼
Kernel VFS layer (client)
    │
    ▼
NFS client module (kernel)
    │ NFS RPC over TCP
    ▼
Network (VPC internal)
    │
    ▼
Filestore NFS Server
    │
    ▼
Storage backend (SSD/HDD)
    │
    ▼
ACK trả về client

Latency end-to-end bao gồm:

1. Network latency từ client đến Filestore instance (thường 0.1–1ms trong cùng zone)
2. NFS server processing (parse RPC, lookup inode, schedule write)
3. Storage write latency (SSD: ~0.1ms, HDD: 5–15ms)

Điều này giải thích tại sao Filestore không thể đạt latency bằng local SSD dù dùng tier SSD — network round-trip là không tránh khỏi.

NFSv3 vs NFSv4.1

Filestore hỗ trợ cả NFSv3 và NFSv4.1, nhưng có sự khác biệt quan trọng về bảo mật và tính năng:

Khía cạnh	NFSv3	NFSv4.1
Authentication	IP-based (export rules)	Kerberos (GSSAPI)
Encryption in-transit	Không	Có (với Kerberos)
File locking	NLM (riêng biệt)	Tích hợp trong protocol
Performance	Thường tốt hơn	Overhead từ security
Availability	Tất cả tier	Zonal, Regional, Enterprise

NFSv3 dùng cơ chế kiểm soát truy cập dựa trên IP: Filestore instance có export rules cho phép IP range nào được mount. Đây là bảo mật thô sơ — bất kỳ VM nào trong IP range đều có thể mount.

NFSv4.1 thêm Kerberos-based authentication và mã hóa in-transit (krb5, krb5i, krb5p). Tuy nhiên, setup Kerberos trong GKE environment phức tạp và thường chỉ cần thiết cho compliance requirements nghiêm ngặt.

Trong phần lớn production deployment, NFSv3 với VPC-level isolation (Private Google Access, VPC Service Controls) là đủ.

Instance Lifecycle và Resource Model

Một Filestore instance là một tài nguyên trong một VPC cụ thể:

• Nằm trong một zone (Zonal/Basic tier) hoặc được phân tán across zones (Regional tier)
• Có một private IP trong VPC — client kết nối qua IP này
• Không expose ra Internet — phải ở trong cùng VPC hoặc connected VPC (VPN/Interconnect)
• Dung lượng được provision trước (không auto-scale như Cloud Storage)

Quan trọng: capacity và performance được provision cùng nhau. Muốn tăng performance, phần lớn trường hợp bạn phải tăng capacity. Đây là fundamental constraint của mô hình NFS server (giải thích chi tiết ở phần Performance model).

Performance model — Cơ chế và giới hạn

Tại sao performance gắn với capacity

Trong Filestore, performance (IOPS và throughput) scale tuyến tính với capacity đối với các tier cũ (Basic HDD/SSD). Điều này không phải ngẫu nhiên — đây là reflection của kiến trúc phần cứng bên dưới.

Một NFS server với 10TB SSD về cơ bản có nhiều ổ SSD hơn (hoặc phần cứng NVMe lớn hơn) so với instance 1TB. Nhiều ổ SSD → nhiều channel I/O song song → IOPS cao hơn. Google expose điều này thông qua pricing model: bạn trả theo GiB được provision, và performance là derived metric.

Với các tier mới (Zonal, Regional), Google giới thiệu Custom Performance — cho phép tách biệt capacity và performance trong một range nhất định. Tuy nhiên, bạn vẫn phải chọn IOPS/TiB trong một range, không hoàn toàn độc lập.

Basic Tiers (Legacy) — Performance cố định

Basic HDD:

• Capacity: 1 TiB đến 63.9 TiB
• Throughput: 80–100 MiB/s (cố định theo tier)
• IOPS: ~600 read / 600 write (đây là tier thấp nhất)
• Latency: 5–15ms (HDD characteristic)
• Use case: File sharing, software development, không nhạy cảm với latency

Basic SSD:

• Capacity: 2.5 TiB đến 63.9 TiB
• Throughput: ~480 MiB/s
• IOPS: ~25,000 read / 25,000 write
• Latency: 0.2–1ms
• Use case: Workloads cần SSD latency nhưng không cần HA

Basic tier là legacy — Google vẫn hỗ trợ nhưng không phát triển thêm tính năng. Đặc biệt: không có snapshot support cho Basic HDD/SSD, chỉ có backup.

Zonal Tier — Performance linh hoạt

Zonal tier thay thế Basic SSD với model performance mới: configurable IOPS per TiB.

Capacity ranges và performance:

Nhỏ (1 TiB đến 9.75 TiB, tăng theo bước 256 GiB):

• IOPS range: 4,000 đến 17,000 IOPS/TiB (bạn chọn trong range này)
• Throughput: scale theo capacity, ví dụ 10 TiB @ 3,000 IOPS/TiB → ~705 MiB/s read

Lớn (10 TiB đến 100 TiB, tăng theo bước 2.5 TiB):

• IOPS range: 3,000 đến 7,500 IOPS/TiB
• Throughput cao hơn tuyệt đối nhờ capacity lớn

Ví dụ tính toán concrete:

Nếu bạn provision 10 TiB Zonal với 3,000 IOPS/TiB:

• Read IOPS: 30,000
• Write IOPS: 9,000 (write IOPS thường ~30% của read IOPS)
• Read throughput: ~705 MiB/s aggregate
• Write throughput: ~240 MiB/s aggregate

Nếu chọn 17,000 IOPS/TiB ở 10,239 GiB (max của range nhỏ):

• Read IOPS: ~170,000
• Write IOPS: ~51,000

Single-client cap: Dù aggregate performance cao, một single client bị giới hạn ở khoảng 450 MiB/s read và 260 MiB/s write — đây là giới hạn của NFS client stack và network, không phải Filestore. Để tận dụng full aggregate performance, cần ít nhất 4 client VM song song.

Đối với single-client workload cần throughput cao, dùng mount option nconnect:

# Với instance 1–9.75 TiB
mount -o nconnect=2 10.x.x.x:/vol1 /mnt/filestore
# Với instance 10+ TiB
mount -o nconnect=7 10.x.x.x:/vol1 /mnt/filestore

nconnect cho phép kernel NFS client dùng nhiều TCP connection song song đến cùng một NFS server, phá vỡ limitation của single-connection throughput.

Regional Tier — HA với performance tương đương

Regional tier có performance model tương tự Zonal nhưng với tradeoff: instance được replicate across zones nên có thêm write latency do synchronous replication.

Performance per TiB cho Regional (100 GiB đến 9.75 TiB):

• Read throughput: 120 MiB/s per TiB
• Write throughput: 100 MiB/s per TiB
• Read IOPS: 12,000 per TiB
• Write IOPS: 4,000 per TiB

Có một non-obvious performance cliff ở ranh giới 9.75 TiB / 10 TiB: một instance 9.75 TiB có read performance tốt hơn instance 10 TiB vì chúng thuộc hai capacity range khác nhau với performance characteristics khác nhau. Đây là artifact của cách Google map capacity sang hardware configuration, không phải lỗi.

Các Service Tier — Khi nào dùng gì

Basic HDD (Legacy)

Đặc điểm:

• Zonal (single zone, no HA)
• HDD backend → latency cao (5–15ms per op)
• Throughput và IOPS thấp nhất
• Không có snapshot support
• Backup support: có

Dùng khi: File sharing không nhạy cảm với latency (shared log storage, software artifact repository không cần high throughput, migration staging area). Không dùng cho production workload.

Basic SSD (Legacy)

Đặc điểm:

• Zonal (single zone, no HA)
• SSD backend → latency thấp hơn (~0.2ms)
• Performance cao hơn HDD nhưng fixed (không configurable)
• Không có snapshot support
• Backup support: có

Dùng khi: Dev/test environments cần SSD performance nhưng không cần HA. Trong production, nên chuyển sang Zonal tier thay thế.

Zonal Tier

Đặc điểm:

• Zonal (single zone, no HA)
• SSD backend với NVMe-based hardware
• Performance hoàn toàn configurable (4,000–17,000 IOPS/TiB)
• NFSv3 và NFSv4.1 support
• Snapshot và backup support
• Replication sang zone khác (asynchronous, cho DR)
• CMEK support

Dùng khi: HPC workloads, ML training (nhiều GPU worker đọc dataset), media rendering, batch processing. Đây là tier phù hợp khi cần performance cao nhất và có thể chấp nhận single-zone availability.

Quan trọng: Zonal tier không có automatic failover. Nếu zone down → instance không accessible cho đến khi zone phục hồi.

Regional Tier

Đặc điểm:

• Multi-zone HA (data replicated across 3 zones trong region)
• Transparent failover khi một zone fail
• Performance tương đương Zonal (slightly lower write IOPS do replication overhead)
• NFSv3 và NFSv4.1 support
• Snapshot, backup, replication support
• CMEK support

Dùng khi: Production application cần shared filesystem với HA requirements. Web server clusters, application servers cần shared session storage, any workload mà downtime không thể chấp nhận được.

Constraint quan trọng: Regional tier không compatible với Filestore Multishares và GKE CSI driver (tính đến thời điểm viết tài liệu này). Xem Chương Regional HA để hiểu chi tiết về HA mechanism.

Enterprise / Multishares for GKE

Đặc điểm:

• Regional HA (tương tự Regional tier)
• Một instance có thể chứa tối đa 80 shares
• Mỗi share map to một PV trong GKE
• Minimum share size: 10 GiB (so với 100 GiB của tier khác)
• Capacity dynamic scaling qua CSI driver
• Không support snapshot

Dùng khi: GKE environments với nhiều microservices nhỏ cần shared storage. Thay vì tạo 50 Filestore instances riêng lẻ cho 50 services, dùng một Multishares instance với 50 shares.

Xem chi tiết ở CSI & Multishares.

Constraints và Trade-offs

Constraint 1: Capacity phải provision trước

Filestore không auto-scale như Cloud Storage. Bạn phải provision dung lượng trước và trả phí ngay cả khi không dùng hết. Resize có thể thực hiện được nhưng:

• Chỉ tăng, không giảm (trừ một số điều kiện nhất định với tier mới)
• Thay đổi capacity tạm thời ảnh hưởng performance (instance đang resize)

Đây là fundamental difference với Cloud Storage và cần được tính vào capacity planning.

Constraint 2: Single-instance bottleneck

Một Filestore instance về bản chất là một NFS server. Dù Google scale hardware tốt, giới hạn của single server vẫn tồn tại. Với workload cực kỳ write-intensive, multiple writers có thể tranh chấp lock ở NFS server level.

Giải pháp thường là partition workload: mỗi set of workers dùng instance riêng, hoặc dùng sharded directory structure trên cùng instance.

Constraint 3: NFS semantics vs POSIX semantics

NFS là "close-to-open consistency" — không phải strong POSIX consistency. Cụ thể:

• Sau khi close file, client khác sẽ thấy data mới khi mở lại (close-to-open)
• Trong khi file đang open, một client khác có thể không thấy ngay changes của client đầu tiên (trừ khi flush/sync)

Điều này gây vấn đề với các database engine dùng NFS (SQLite, một số embedded DB) vì chúng assume strict POSIX locking. Không run database trực tiếp trên Filestore NFS.

Constraint 4: Network dependency

Vì tất cả IO đi qua network, latency spikes trong VPC ảnh hưởng trực tiếp đến Filestore performance. Đặt Filestore instance trong cùng zone với client để minimize latency. Cross-zone NFS mount hoạt động được nhưng latency cao hơn đáng kể.

Failure mode: Stale NFS mounts

Khi Filestore instance restart (maintenance, failover, zone incident), NFS clients giữ stale mount. Các NFS operations tiếp theo sẽ hang hoặc return ESTALE errors. Kernel NFS client có timeout (thường soft vs hard mount option quyết định behavior này):

# soft mount: return error sau timeout (có thể mất data)
mount -o soft,timeo=150 ...

# hard mount: retry mãi (ứng dụng sẽ hang cho đến khi server khôi phục)
mount -o hard,intr ...

Với Regional tier có transparent failover, thường dùng hard mount vì instance sẽ tự khôi phục sau vài phút. Với Zonal tier (không có failover), soft mount tốt hơn để ứng dụng fail fast thay vì hang.

References

• Filestore Overview
• About Service Tiers
• Filestore Performance
• Regional Service Tier
• NFS mount options