StorageStorage

Part of the Cloud knowledge base — GCP deep dive. Complements DevOps Roadmap.

Tổng quan

Storage trên Google Cloud chia thành ba dạng lớn, và chọn sai dạng là một sai lầm phổ biến và tốn kém:

Dạng	Dịch vụ	Mô hình truy cập	Tương đương AWS
Object storage	Cloud Storage (GCS)	HTTP API, key → blob	S3
Block storage	Persistent Disk, Hyperdisk, Local SSD	Gắn vào VM như một disk	EBS / instance store
File storage	Filestore	NFS mount	EFS / FSx

Quy tắc kinh nghiệm: dùng object storage cho các blob phi cấu trúc (hình ảnh, backup, file data-lake, static asset); dùng block storage cho disk boot/data của VM và I/O ngẫu nhiên độ trễ thấp; dùng file storage khi nhiều VM cần một filesystem POSIX dùng chung.

Trang này tập trung vào Cloud Storage (được dùng nhiều nhất) và các lựa chọn block/file, cộng với mô hình chi phí egress khiến nhiều team bất ngờ.

Kiến thức nền tảng

Cloud Storage (GCS)

Cloud Storage lưu các object bất biến bên trong các bucket. Một bucket có tên duy nhất toàn cầu, một location, một storage class mặc định, và cấu hình IAM/policy. Object được địa chỉ hóa dưới dạng gs://bucket-name/path/to/object.

Các loại location:

Loại	Dự phòng	Dùng khi
Region (vd us-central1)	Nhiều zone trong một region	Độ trễ thấp nhất tới compute cùng vị trí, data residency
Dual-region (vd nam4)	Hai region cụ thể	HA + cặp địa lý xác định
Multi-region (vd US, EU)	Trải rộng một vùng địa lý lớn	Tính sẵn sàng cao nhất, đọc toàn cầu

Storage classes đánh đổi giá lưu trữ thấp hơn lấy chi phí truy cập (retrieval) cao hơn và thời lượng lưu trữ tối thiểu:

Class	Thời lượng lưu tối thiểu	Dùng điển hình	Chi phí retrieval
Standard	không	Dữ liệu nóng, truy cập thường xuyên, website tĩnh	không
Nearline	30 ngày	Truy cập < 1 lần/tháng (backup)	thấp
Coldline	90 ngày	Truy cập < 1 lần/quý (DR)	trung bình
Archive	365 ngày	Truy cập < 1 lần/năm (compliance, lưu trữ sâu)	cao nhất

Mọi class có cùng throughput, độ trễ, và API — khác biệt thuần túy nằm ở mô hình giá. Xóa hoặc ghi đè một object trước thời lượng tối thiểu của nó sẽ chịu phí xóa sớm (early-deletion).

Các thao tác cơ bản với CLI gcloud storage (kế thừa hiện đại của gsutil):

# Tạo một bucket regional với uniform bucket-level access
gcloud storage buckets create gs://my-app-assets \
  --location=us-central1 \
  --default-storage-class=STANDARD \
  --uniform-bucket-level-access

# Upload / download / list
gcloud storage cp ./photo.jpg gs://my-app-assets/photos/
gcloud storage cp gs://my-app-assets/photos/photo.jpg ./
gcloud storage ls gs://my-app-assets/photos/

# Đồng bộ một thư mục local với bucket (giống rsync)
gcloud storage rsync ./build gs://my-app-assets/site --recursive

Object versioning

Object versioning giữ lại các phiên bản không hiện hành (noncurrent) khi một object bị ghi đè hoặc xóa, bảo vệ khỏi mất mát vô tình và ransomware. Kết hợp với lifecycle rule để hết hạn các phiên bản cũ.

gcloud storage buckets update gs://my-app-assets --versioning

Quản lý vòng đời (lifecycle)

Lifecycle rules tự động chuyển object sang class lạnh hơn hoặc xóa chúng dựa trên tuổi, trạng thái phiên bản, hoặc class. Định nghĩa bằng JSON và áp dụng cho một bucket:

{
  "rule": [
    {
      "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
      "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
    },
    {
      "action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
      "condition": {"age": 90, "matchesStorageClass": ["NEARLINE"]}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"age": 365}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"numNewerVersions": 3, "isLive": false}
    }
  ]
}

gcloud storage buckets update gs://my-app-assets \
  --lifecycle-file=lifecycle.json

Policy này phân tầng Standard → Nearline sau 30 ngày, Nearline → Coldline sau 90 ngày, xóa object quá 365 ngày, và giữ tối đa 3 phiên bản noncurrent. Autoclass là một lựa chọn không phải bận tâm, tự động di chuyển object giữa các class dựa trên pattern truy cập.

Kiểm soát truy cập: IAM vs ACL

Hai cách để cấp quyền, và bạn nên chọn một cách có chủ đích:

Cơ chế	Mức chi tiết	Khuyến nghị
IAM (Uniform bucket-level access)	Role mức bucket	Ưu tiên — nhất quán, audit được, hoạt động với org policy
ACL (fine-grained)	Cấp quyền theo từng object	Legacy; chỉ khi bạn thực sự cần quyền theo từng object

Bật Uniform bucket-level access vô hiệu hóa ACL theo object và biến IAM thành nguồn sự thật duy nhất — mặc định được khuyến nghị. Các role phổ biến: roles/storage.objectViewer, roles/storage.objectAdmin, roles/storage.admin.

Signed URLs

Một signed URL cấp quyền truy cập có giới hạn thời gian tới một object cụ thể mà không yêu cầu người gọi có quyền IAM — lý tưởng để cho phép người dùng cuối upload hoặc download trực tiếp:

# Tạo một URL có hiệu lực 15 phút để GET một object
gcloud storage sign-url gs://my-app-assets/reports/q3.pdf \
  --duration=15m \
  --private-key-file=key.json

Dùng signed URL kiểu PUT để cho phép trình duyệt upload trực tiếp lên GCS, giữ các file lớn tránh xa server ứng dụng của bạn.

Hosting website tĩnh

Cloud Storage có thể phục vụ một site tĩnh trực tiếp. Trỏ một bucket đặt tên theo domain của bạn tới trang index/error, rồi đặt trước nó một external HTTPS load balancer + Cloud CDN để có TLS và custom domain:

gcloud storage buckets update gs://www.example.com \
  --web-main-page-index=index.html \
  --web-error-page=404.html

Persistent Disk & Hyperdisk (block storage)

Persistent Disk (PD) là block storage gắn qua mạng cho Compute Engine và GKE. Nó tồn tại qua stop/restart của instance và có thể resize khi đang chạy.

Loại	Nền tảng	Dùng khi
pd-standard	HDD	I/O tuần tự, khối lượng lớn giá rẻ, dữ liệu lạnh
pd-balanced	SSD	Mặc định general-purpose, $/IOPS tốt
pd-ssd	SSD	Nhạy cảm độ trễ, database IOPS cao
pd-extreme	SSD	IOPS cao nhất, provision IOPS riêng

Hyperdisk là thế hệ mới hơn tách rời capacity, throughput, và IOPS để bạn tinh chỉnh từng cái độc lập — rẻ hơn và linh hoạt hơn cho các workload đòi hỏi cao (hyperdisk-balanced, hyperdisk-throughput, hyperdisk-extreme).

Regional persistent disk sao chép đồng bộ qua hai zone cho HA của các workload stateful. Snapshot là bản sao lưu incremental, differential của một disk, lưu trong Cloud Storage và dùng được qua các zone/region:

# Tạo một snapshot
gcloud compute disks snapshot my-data-disk \
  --snapshot-names=my-data-snap-$(date +%Y%m%d) \
  --zone=us-central1-a

# Tự động hóa với một snapshot schedule (resource policy)
gcloud compute resource-policies create snapshot-schedule daily-backup \
  --region=us-central1 \
  --max-retention-days=14 \
  --daily-schedule --start-time=03:00
gcloud compute disks add-resource-policies my-data-disk \
  --resource-policies=daily-backup --zone=us-central1-a

Local SSD

Local SSD được gắn vật lý vào host, cho IOPS cao nhất/độ trễ thấp nhất — nhưng dữ liệu là ephemeral và bị mất khi stop/terminate/live-migration. Chỉ dùng cho không gian tạm (scratch), cache, hoặc các database scale-out sao chép chịu được mất node.

Filestore (file storage)

Filestore là NFS được quản lý cho các workload cần một filesystem POSIX dùng chung qua nhiều VM hoặc GKE pod (media CMS, HPC scratch, ứng dụng lift-and-shift kỳ vọng một mount). Các tier trải từ Basic tới Zonal, Regional, và Enterprise (hiệu năng và tính sẵn sàng cao hơn).

Khái niệm chính

Chọn một dịch vụ storage

1. ?Blob phi cấu trúc, backup, data-lake, static asset, truy cập qua HTTP?
   Có

   Cloud Storagechọn class theo tần suất truy cập; thêm lifecycle rule
2. ?Một disk cho một VM (boot hoặc data), I/O ngẫu nhiên độ trễ thấp?
   Có

   Persistent Disk / HyperdiskPD regional cho HA; snapshot cho backup
3. ?IOPS cao nhất có thể và chịu được mất dữ liệu khi stop?
   Có

   Local SSD
4. ?Nhiều VM / pod cần một filesystem POSIX dùng chung (NFS)?
   Có

   Filestore

Chi phí truyền dữ liệu & egress

Giá lưu trữ chỉ là một phần hóa đơn — network egress thường chiếm phần lớn:

• Ingress (upload) miễn phí. Lưu trữ dữ liệu tốn giá theo GB của class.
• Egress ra internet tính phí theo GB và thay đổi theo đích và network tier. Đây là con số khiến các team bất ngờ khi phục vụ media lớn trực tiếp từ GCS.
• Egress trong cùng region (vd GCS → một VM cùng region) thường miễn phí; egress cross-region và cross-continent có tính phí.
• Phí retrieval áp dụng thêm trên egress cho Nearline/Coldline/Archive khi bạn đọc dữ liệu.
• Đặt Cloud CDN trước nội dung public để cache tại edge, giảm egress từ origin và cải thiện độ trễ.

Với các migration lớn một lần hoặc liên tục, dùng Storage Transfer Service (từ S3, Azure, HTTP, hoặc on-prem) hoặc Transfer Appliance cho truyền offline quy mô petabyte.

Mã hóa

Mọi dữ liệu được mã hóa at rest theo mặc định với key do Google quản lý. Để kiểm soát bạn có thể dùng CMEK (Customer-Managed Encryption Keys qua Cloud KMS) hoặc CSEK (key do khách hàng cung cấp). CMEK là lựa chọn thông thường cho compliance.

Best Practices

1. Khớp storage class với tần suất truy cập và tự động hóa việc chuyển tầng. Lý do: dùng Standard cho dữ liệu nóng gây lãng phí tiền cho các object hiếm khi đọc; lifecycle rule (hoặc Autoclass) tự động chuyển dữ liệu lạnh sang Nearline/Coldline/Archive để tiết kiệm lớn.

2. Bật Uniform bucket-level access (IAM, không phải ACL). Lý do: một mô hình quyền duy nhất, audit được, hoạt động với org policy; ACL theo object dễ sai và khó suy luận.

3. Bật Object Versioning cho các bucket giữ state quan trọng. Lý do: bảo vệ khỏi ghi đè/xóa vô tình và ransomware; kết hợp với lifecycle rule để giới hạn phình phiên bản.

4. Dùng signed URL cho upload/download trực tiếp của người dùng. Lý do: giữ các lần truyền lớn tránh xa server ứng dụng và tránh cấp quyền IAM rộng, trong khi vẫn có giới hạn thời gian.

5. Đặt Cloud CDN trước nội dung public/tĩnh. Lý do: cache tại edge, giảm mạnh chi phí egress từ origin và cải thiện độ trễ toàn cầu.

6. Đặt bucket cùng vị trí với compute đọc nó. Lý do: truy cập cùng region nhanh và miễn phí egress; đọc cross-region thêm độ trễ và phí mạng.

7. Đặt lifecycle rule để xóa các multipart upload dở dang và phiên bản cũ. Lý do: các upload bị bỏ dở và phiên bản noncurrent không giới hạn âm thầm tích lũy chi phí.

8. Ưu tiên pd-balanced làm disk mặc định, chỉ nâng cấp khi bị giới hạn IOPS. Lý do: giá/hiệu năng tốt cho hầu hết workload; để dành pd-ssd/Hyperdisk-extreme cho các database quan trọng về độ trễ.

9. Dùng Hyperdisk khi cần tinh chỉnh IOPS/throughput độc lập. Lý do: tách rời capacity khỏi hiệu năng tránh phải over-provision một disk lớn chỉ để có IOPS.

10. Lên lịch snapshot disk tự động, incremental kèm retention. Lý do: snapshot rẻ, incremental, và cross-region — một primitive backup/DR đáng tin; policy retention ngăn tăng trưởng không giới hạn.

11. Không bao giờ lưu dữ liệu bền vững trên Local SSD. Lý do: nó ephemeral và bị mất khi stop/migration; chỉ dùng cho scratch, cache, hoặc dữ liệu đã sao chép.

12. Dùng regional Persistent Disk cho các workload stateful cần HA. Lý do: sao chép đồng bộ cross-zone cho phép một VM/pod stateful phục hồi ở zone khác mà không mất dữ liệu.

13. Bật CMEK cho dữ liệu bị quản chế hoặc nhạy cảm. Lý do: cho bạn quyền xoay vòng key, thu hồi, và kiểm soát audit vượt qua mã hóa do Google quản lý mặc định.

14. Áp dụng nguyên tắc đặc quyền tối thiểu trên bucket. Lý do: cấp objectViewer/objectAdmin giới hạn ở các bucket cụ thể thay vì storage.admin toàn project; một credential rò rỉ khi đó bị kiềm chế.

15. Bật Bucket Lock / retention policy cho các archive tuân thủ. Lý do: tính bất biến kiểu WORM ngăn xóa trước một khoảng retention — bắt buộc cho nhiều use case audit và legal-hold.

16. Mô hình hóa egress trước khi phục vụ media lớn từ GCS. Lý do: egress internet và phí retrieval có thể vượt xa chi phí lưu trữ; ước lượng chúng (và cân nhắc CDN) trước khi ra mắt để tránh sốc hóa đơn.

Tài liệu tham khảo

• Cloud Storage documentation
• Storage classes
• Object lifecycle management
• Autoclass
• Object versioning
• Uniform bucket-level access
• Signed URLs
• Host a static website
• Persistent Disk
• Hyperdisk
• Disk snapshots
• Filestore documentation
• Cloud Storage pricing (storage + network)
• Storage Transfer Service

# Create a regional bucket with uniform bucket-level access
gcloud storage buckets create gs://my-app-assets \
  --location=us-central1 \
  --default-storage-class=STANDARD \
  --uniform-bucket-level-access

# Upload / download / list
gcloud storage cp ./photo.jpg gs://my-app-assets/photos/
gcloud storage cp gs://my-app-assets/photos/photo.jpg ./
gcloud storage ls gs://my-app-assets/photos/

# Sync a local directory to a bucket (like rsync)
gcloud storage rsync ./build gs://my-app-assets/site --recursive

gcloud storage buckets update gs://my-app-assets --versioning

{
  "rule": [
    {
      "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
      "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
    },
    {
      "action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
      "condition": {"age": 90, "matchesStorageClass": ["NEARLINE"]}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"age": 365}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"numNewerVersions": 3, "isLive": false}
    }
  ]
}

gcloud storage buckets update gs://my-app-assets \
  --lifecycle-file=lifecycle.json

# Generate a URL valid for 15 minutes to GET an object
gcloud storage sign-url gs://my-app-assets/reports/q3.pdf \
  --duration=15m \
  --private-key-file=key.json

gcloud storage buckets update gs://www.example.com \
  --web-main-page-index=index.html \
  --web-error-page=404.html

# Create a snapshot
gcloud compute disks snapshot my-data-disk \
  --snapshot-names=my-data-snap-$(date +%Y%m%d) \
  --zone=us-central1-a

# Automate with a snapshot schedule (resource policy)
gcloud compute resource-policies create snapshot-schedule daily-backup \
  --region=us-central1 \
  --max-retention-days=14 \
  --daily-schedule --start-time=03:00
gcloud compute disks add-resource-policies my-data-disk \
  --resource-policies=daily-backup --zone=us-central1-a