Skip to content

Local SSD & Ephemeral Storage — Tốc Độ Đổi Lấy Độ Bền

Vì sao đây là chương nguy hiểm nhất về dữ liệu

Local SSD là storage nhanh nhất có trên GKE — NVMe physical gắn trực tiếp vào node, không qua network stack, latency thấp nhất và throughput cao nhất. Cũng chính vì vậy nó là storage nguy hiểm nhất: nó không bền. Mọi vụ mất dữ liệu im lặng nghiêm trọng nhất mà các đội vận hành GKE gặp đều có chung một gốc — ai đó coi Local SSD (hoặc emptyDir) là persistent storage.

Quy luật phải khắc cốt ghi tâm trước khi đọc bất cứ gì khác trong file này: dữ liệu trên Local SSD không tồn tại qua node recreation. Node bị auto-repair, node upgrade, Spot preemption, hay scale-down — node bị thay thế bằng node mới và toàn bộ Local SSD bị xóa sạch (GKE storage overview). Không có cảnh báo, không có recovery. Local SSD là scratch space cao cấp, không phải kho dữ liệu.

File này dạy cách dùng Local SSD và ephemeral storage đúng — khai thác tốc độ của chúng ở những chỗ mất dữ liệu là chấp nhận được, và tuyệt đối không đặt vào chúng thứ không thể tái tạo.

Phổ ephemeral: từ emptyDir tới Local SSD raw block

"Ephemeral storage" trên GKE là một phổ, từ tiện-nhưng-chậm tới nhanh-nhưng-thô:

emptyDir trên ephemeral storage của node

emptyDir mặc định nằm trên ephemeral storage của node — thường là boot disk, hoặc Local SSD nếu node pool được cấu hình ephemeral-storage-local-ssd. Nó được tạo rỗng khi Pod gán vào node, tồn tại suốt đời Pod, xóa khi Pod bị xóa. Đây là cách đơn giản nhất để có scratch space; không cần PV/PVC, không cần CSI. Dung lượng bị tính vào ephemeral-storage request/limit của Pod, và Pod có thể bị evict nếu vượt limit (node-pressure eviction, Chương 8).

emptyDir medium Memory (tmpfs)

Đặt emptyDir.medium: Memory chuyển backing sang tmpfs (RAM) — nhanh nhất tuyệt đối, nhưng tính vào memory limit của Pod và biến mất khi Pod restart. Dùng cho buffer cực nóng cần tốc độ RAM, ví dụ vùng làm việc tạm của xử lý stream. Cẩn trọng: ghi nhiều vào tmpfs có thể đẩy Pod vượt memory limit → OOM kill.

Local SSD: NVMe physical

Local SSD là một hoặc nhiều ổ NVMe vật lý gắn trực tiếp vào VM của node (GKE storage overview). Khác emptyDir trên boot disk ở chỗ nó là phần cứng riêng, dung lượng lớn (hàng trăm GB tới nhiều TB), throughput và IOPS vượt xa PD. Nhưng cùng đặc tính ephemeral: gắn với node cụ thể, không migrate, mất khi node thay.

Local SSD dùng được theo hai cách trên GKE:

  • Backing cho ephemeral storage / emptyDir: cấu hình node pool với --ephemeral-storage-local-ssd count=N, sau đó emptyDir và ephemeral storage của Pod tự dùng Local SSD — trong suốt với workload, chỉ cần xin emptyDir.
  • Raw block local PersistentVolume: expose Local SSD như local PV để workload tự quản lý (format, RAID...). Phức tạp hơn, dùng khi cần kiểm soát thấp tầng hoặc gộp nhiều NVMe thành một volume lớn.
bash
# Node pool với Local SSD làm backing cho ephemeral storage
gcloud container node-pools create ssd-pool \
  --cluster=my-cluster \
  --ephemeral-storage-local-ssd count=2 \
  --machine-type=n2-standard-16
yaml
# Pod dùng emptyDir — tự nằm trên Local SSD nếu node pool cấu hình như trên
apiVersion: v1
kind: Pod
metadata:
  name: cache-worker
spec:
  containers:
  - name: app
    image: my-app
    volumeMounts:
    - name: scratch
      mountPath: /scratch
  volumes:
  - name: scratch
    emptyDir: {}

Mô hình vòng đời: chính xác khi nào dữ liệu mất

Hiểu chính xác các sự kiện làm mất Local SSD là điều kiện để dùng nó an toàn. Dữ liệu mất khi node bị thay thế hoặc Pod bị xóa:

Sự kiệnLocal SSD mất?Ghi chú
Container restart (cùng Pod, cùng node)Không (với emptyDir đĩa) / Có (tmpfs)emptyDir survive container restart
Pod bị xóa / reschedule sang node khácEphemeral gắn vòng đời Pod
Node auto-repairNode thay mới hoàn toàn
Node upgrade (surge/blue-green)Node cũ bị drain rồi xóa
Spot/Preemptible preemptionNode bị thu hồi
Cluster Autoscaler scale-downNode bị xóa
Node reboot (giữ nguyên VM)TùyLocal SSD thường mất khi VM stop/start

Bảng này là lý do Local SSD không bao giờ được dùng cho: database primary data, message queue chưa ack, file người dùng upload, hay bất kỳ state nào là nguồn chân lý. Tất cả những sự kiện trên là bình thường, thường xuyên trong vận hành GKE — node upgrade xảy ra hàng tuần, Spot preemption hàng giờ. Một workload đặt dữ liệu quan trọng trên Local SSD không phải "có rủi ro mất dữ liệu" mà là "chắc chắn sẽ mất, chỉ là khi nào".

Use case đúng: nơi tốc độ Local SSD tỏa sáng

Local SSD đúng khi dữ liệu tái tạo được và tốc độ là tối quan trọng:

  • Cache nóng trước một backing store bền. Ví dụ database đọc với cache layer trên Local SSD; mất cache thì warm lại từ nguồn bền, không mất dữ liệu thật. Đây là use case kinh điển — Local SSD làm layer cache giữa compute và Cloud Storage/PD (GKE storage overview).

  • Scratch space cho AI/ML training. Shuffle buffer, checkpoint tạm giữa các step, dữ liệu trung gian của data pipeline. Checkpoint quan trọng vẫn phải đẩy ngược về GCS định kỳ; Local SSD chỉ giữ trạng thái làm việc.

  • Cache dataset cho Cloud Storage FUSE. File cache của GCS FUSE (file 7) đặt trên Local SSD để đọc lặp lại nhanh mà không tải lại từ GCS — dữ liệu gốc vẫn an toàn trên bucket.

  • Real-time analytics, tính toán ephemeral. Dữ liệu sống ngắn, kết quả được ghi ra nơi bền; quá trình tính trung gian hưởng tốc độ NVMe.

  • Local cache của database phân tán có replication riêng. Một số database (ví dụ kiểu Cassandra với replication factor ≥3) có thể chấp nhận node mất dữ liệu vì các replica khác giữ bản sao — nhưng đây là quyết định kiến trúc tinh tế, chỉ làm khi hiểu rõ mô hình nhất quán của database đó và chấp nhận chi phí rebuild node.

Mẫu chung của mọi use case đúng: nguồn chân lý nằm ở nơi khác (bền), Local SSD chỉ giữ bản sao/dữ liệu trung gian tăng tốc.

Anti-pattern chết người và vì sao chúng xảy ra

  • Đặt database primary trên Local SSD vì "PD chậm quá". Nguyên nhân gốc: áp lực hiệu năng khiến kỹ sư chọn tốc độ mà quên độ bền. Hệ quả ở scale: lần node upgrade tiếp theo (chắc chắn xảy ra) là mất sạch database. Phòng tránh: nếu PD chậm, chuyển sang Hyperdisk Extreme/Balanced (file 4) — block storage bền với IOPS cao — chứ không phải Local SSD.

  • Dùng emptyDir cho upload của người dùng "tạm" rồi quên đẩy đi. Nguyên nhân: "tạm" trở thành "vĩnh viễn" qua quên lãng. Hệ quả: mất file người dùng khi Pod reschedule. Phòng tránh: upload phải ghi thẳng vào GCS/PD; emptyDir chỉ cho xử lý trong-quá-trình.

  • Spot node + Local SSD cho stateful. Nguyên nhân: muốn vừa rẻ (Spot) vừa nhanh (Local SSD). Hệ quả: Spot preemption thu hồi node bất cứ lúc nào → mất dữ liệu thường xuyên. Phòng tránh: Spot chỉ cho workload chịu được mất node và mất ephemeral data đồng thời (batch idempotent, stateless).

  • Không đặt ephemeral-storage request/limit. Nguyên nhân: bỏ qua resource model cho ephemeral. Hệ quả: Pod ghi đầy ephemeral storage của node → node-pressure eviction hàng loạt, ảnh hưởng cả Pod khác trên node. Phòng tránh: luôn đặt ephemeral-storage request/limit cho Pod ghi nhiều scratch (Chương 8).

  • RAID Local SSD rồi coi như bền. Nguyên nhân: nhầm "không mất khi một disk lỗi" với "không mất khi node thay". RAID bảo vệ disk failure, không bảo vệ node recreation. Hệ quả: vẫn mất khi node bị thay. Phòng tránh: RAID Local SSD tăng dung lượng/tốc độ, không tăng độ bền qua vòng đời node.

Hiệu năng và capacity design

Local SSD trên GKE đi theo bội số dung lượng cố định mỗi NVMe, gắn vào node lúc tạo (không thêm/bớt động). Khi thiết kế node pool dùng Local SSD:

  • Số lượng NVMe quyết định tổng dung lượng và throughput — nhiều NVMe gộp lại (RAID0 hoặc LVM stripe) cho throughput cộng dồn.
  • Machine type phải hỗ trợ số Local SSD mong muốn; không phải mọi machine type cho phép gắn Local SSD, và có giới hạn số lượng theo dòng máy.
  • Tỷ lệ Local SSD : compute nên khớp workload — quá nhiều NVMe trên node ít CPU là lãng phí; quá ít là bottleneck I/O.

Vì Local SSD gắn cứng lúc tạo node, thay đổi cấu hình nghĩa là tạo node pool mới rồi migrate workload — không resize được như PVC. Điều này phải tính vào capacity planning từ đầu (Chương 6).

Autopilot và Local SSD

Trên GKE Autopilot, mô hình khác: bạn không quản lý node trực tiếp, nên Local SSD được expose qua ephemeral storage hoặc các compute class chuyên dụng (ví dụ class Accelerator/Performance) thay vì cấu hình node pool thủ công. Một số machine cao cấp (ví dụ A2 Ultra với A100) hỗ trợ Local SSD trên Autopilot (GKE storage overview). Nguyên tắc ephemeral và quy luật mất-khi-node-thay vẫn y nguyên; chỉ cách provisioning khác.

Real-world scenario: AI/ML training pipeline dùng Local SSD đúng cách

Một training job đọc dataset TB-scale, qua nhiều epoch:

  1. Dataset gốc trên Cloud Storage (nguồn chân lý, bền).
  2. GCS FUSE file cache trên Local SSD: epoch đầu tải từ GCS qua FUSE, cache lên Local SSD; các epoch sau đọc thẳng từ Local SSD — nhanh gấp nhiều lần, dữ liệu gốc vẫn an toàn trên GCS (file 7).
  3. Shuffle buffer và dữ liệu trung gian trên emptyDir Local SSD — tốc độ NVMe, mất là chấp nhận (tái tạo từ dataset).
  4. Checkpoint định kỳ ghi ngược về GCS — nếu node bị preempt giữa chừng, job resume từ checkpoint GCS gần nhất, không mất tiến độ quá một interval.

Kết quả: hưởng trọn tốc độ Local SSD ở các tầng tái tạo được, trong khi mọi state quan trọng (dataset, checkpoint) đều bền trên GCS. Nếu node Spot bị preempt — sự kiện thường xuyên — job chỉ mất công việc kể từ checkpoint cuối, không mất dữ liệu. Đây là mẫu thiết kế chuẩn: Local SSD cho tốc độ, object/block storage cho độ bền, ranh giới rõ ràng giữa hai.

Common mistakes / anti-patterns

Tổng hợp lại các sai lầm cốt lõi (đã phân tích chi tiết ở trên):

  • Coi Local SSD/emptyDir là persistent → mất dữ liệu khi node recreate. Quy luật: bền thì phải PV/PVC.
  • Spot + Local SSD cho stateful → mất dữ liệu thường xuyên do preemption.
  • Quên ephemeral-storage limit → node-pressure eviction lan rộng.
  • RAID rồi tưởng bền → vẫn mất khi node thay.
  • Dùng tmpfs (medium: Memory) ghi nhiều → đẩy Pod vượt memory limit, OOM.

Official references