Kiến Trúc Nội Tại & Các Loại Persistent Disk
Tại sao phải hiểu cơ chế bên trong
Phần lớn performance bottleneck với Persistent Disk xuất phát từ một hiểu lầm căn bản: nhiều engineers vẫn nghĩ PD hoạt động giống ổ cứng gắn trực tiếp vào máy. Thực tế, Persistent Disk là network block device — mọi I/O operation đều phải đi qua mạng đến Colossus, hệ thống file phân tán của Google. Điều này có hàng loạt implication quan trọng về latency, durability, và performance characteristics mà không thể hiểu đúng nếu dùng mental model "local disk".
Mô hình kiến trúc bên trong
Persistent Disk như network block device
Khi một VM thực hiện write operation vào Persistent Disk, data không được ghi trực tiếp vào bất kỳ physical disk nào gắn liền với host server của VM đó. Thay vào đó, toàn bộ I/O đi qua đường sau:
VM (Guest OS)
│ block I/O request
▼
Persistent Disk Driver (trong VM)
│ mã hóa data tại VM
▼
Virtualization Layer (Hypervisor / KVM)
│ forward qua mạng
▼
Google Network (Jupiter Fabric)
│ routing đến storage cluster
▼
Colossus (Google Distributed File System)
│ phân phối data ra nhiều physical locations
▼
Physical Storage (SSDs / HDDs trong datacenter)Điều quan trọng cần nhận ra: Persistent Disk driver trong VM thực hiện mã hóa data trước khi data rời khỏi VM. Data đi qua mạng ở dạng đã mã hóa, Colossus nhận data đã mã hóa và persist nó. Không có điểm nào trong pipeline mà unencrypted data tồn tại ngoài guest VM.
Colossus: Backend lưu trữ thực sự
Colossus là successor của Google File System (GFS), hoạt động như một distributed storage layer ở phía dưới Persistent Disk. Theo Google Cloud documentation, mỗi byte của Persistent Disk được lưu ở ba hoặc nhiều hơn ba vị trí vật lý, phân tán qua các separate fault domains trong cùng một Compute Engine zone.
"Fault domain" ở đây không phải là khái niệm phần mềm — đây là physical isolation: different power circuits, different network switches, different cooling zones. Việc phân tán data qua các fault domain này là lý do Persistent Disk đạt được durability 99.999% đến 99.9999% tùy loại.
Continuous monitoring chạy liên tục trên toàn bộ storage devices: khi một device bắt đầu có dấu hiệu lỗi (predicted failure), Colossus drain và re-replicate data trước khi failure xảy ra. Khi một device fail bất ngờ, re-replication xảy ra trong vài phút, không phải vài giờ.
Checksums và data integrity
Mọi I/O operation — cả read lẫn write — đều được tính checksum. Điều này bảo vệ khỏi silent data corruption: tình huống hardware trả về data bị sai mà không báo lỗi. Colossus verify checksum ở mỗi hop trong pipeline, đảm bảo "what you read is exactly what you wrote".
Đây là điểm khác biệt với nhiều locally-attached storage solutions — không có checksumming end-to-end, silent corruption có thể tồn tại trong nhiều tháng trước khi bị phát hiện.
Separation of compute và storage
Một implication quan trọng của kiến trúc network storage là Persistent Disk tồn tại độc lập với VM lifecycle. Disk không bị xóa khi VM bị xóa (trừ khi cấu hình ngược lại). Disk có thể được detach khỏi một VM và attach vào VM khác trong vài giây. Disk data tồn tại ngay cả khi không có VM nào đang attach.
Điều này trái ngược hoàn toàn với Local SSD — Local SSD thực sự gắn vào physical host và data bị mất khi VM bị terminate hoặc host bị maintenance.
I/O path và write latency
Vì mọi I/O đều đi qua mạng, write latency của Persistent Disk (thường 1–2ms cho SSD types) cao hơn đáng kể so với Local SSD NVMe (~100μs). Tuy nhiên, đây là sự đánh đổi đã được thiết kế có chủ đích: durability và availability quan trọng hơn latency tuyệt đối cho phần lớn production workloads.
Theo Google Cloud documentation, write operations của PD bị giới hạn bởi network egress cap của VM — đây là lý do write throughput bị ceiling bởi VM type, không chỉ bởi disk type.
Bốn loại Persistent Disk
pd-standard (Standard Persistent Disk)
pd-standard là loại duy nhất trong dòng PD sử dụng HDD-backed storage. Đây không có nghĩa là physical hard drive được gắn trực tiếp vào VM — data vẫn đi qua Colossus — nhưng physical medium tại lớp storage là magnetic disk.
Đặc tính kỹ thuật:
- Read IOPS: 0.75 IOPS/GiB, tối đa 7,500 IOPS/instance
- Write IOPS: 1.5 IOPS/GiB, tối đa 15,000 IOPS/instance
- Read throughput: 0.12 MiB/s/GiB, tối đa 1,200 MiB/s/instance
- Write throughput: tối đa 400 MiB/s/instance
- Durability: better than 99.99%
Khi nào dùng pd-standard: Sequential read/write workloads với large block sizes — backup storage, cold data archives, batch processing. HDD không phù hợp cho random I/O vì seek time cao, nhưng throughput tốt cho sequential access pattern.
Khi nào không dùng: Database, application workload cần low-latency random I/O. IOPS cap thấp (7,500 read IOPS) là hard ceiling ngay cả với disk dung lượng lớn.
pd-balanced (Balanced Persistent Disk)
pd-balanced là loại SSD-backed được thiết kế như lựa chọn mặc định cho phần lớn workloads — cân bằng giữa cost, performance, và availability. Đây là type mà GKE Autopilot sử dụng cho boot disk của managed nodes.
Đặc tính kỹ thuật:
- Read/Write IOPS: 6 IOPS/GiB mỗi chiều, tối đa 80,000 IOPS/instance
- Throughput: 0.28 MiB/s/GiB, tối đa 1,200 MiB/s/instance
- Baseline guarantee: 3,000 IOPS và 140 MiB/s per instance bất kể disk size
- Durability: better than 99.999%
Điểm quan trọng là baseline guarantee — ngay cả disk 10 GiB cũng được guarantee tối thiểu 3,000 IOPS. Đây là "burstable baseline" concept: disk nhỏ không bị giảm xuống gần 0 IOPS chỉ vì dung lượng thấp.
So sánh pd-balanced vs pd-ssd: Với disk lớn (>160 GiB), pd-ssd có IOPS/GiB cao hơn 5x (30 vs 6). Với disk nhỏ (<500 GiB), sự khác biệt thực tế nhỏ hơn vì baseline guarantee. Chi phí pd-ssd cao hơn đáng kể.
pd-ssd (SSD Persistent Disk)
pd-ssd cung cấp IOPS/GiB cao hơn pd-balanced 5 lần — phù hợp cho OLTP databases, analytics workloads cần high random read throughput.
Đặc tính kỹ thuật:
- Read/Write IOPS: 30 IOPS/GiB mỗi chiều, tối đa 100,000 IOPS/instance
- Throughput: 0.48 MiB/s/GiB, tối đa 1,200 MiB/s/instance
- Baseline guarantee: 6,000 IOPS và 240 MiB/s per instance
- Durability: better than 99.999%
Tại sao read và write IOPS limit bằng nhau cho pd-ssd? Không giống pd-standard (read cap = write cap / 2), SSD có write amplification thấp hơn HDD và cân đối tốt hơn giữa read/write. Cả hai đều chia sẻ cùng maximum 100,000 IOPS per instance.
Scaling formula cho pd-ssd:
Để đạt 30,000 IOPS cần ít nhất: 30,000 / 30 = 1,000 GiB disk.
Nhưng đây là per-disk limit — nếu attach nhiều disk pd-ssd vào cùng một VM, IOPS cộng dồn và bị giới hạn bởi VM-level cap (xem Chương 02).
pd-extreme (Extreme Persistent Disk)
pd-extreme là loại PD duy nhất có provisioned IOPS model trong dòng Persistent Disk. Thay vì performance tăng theo dung lượng, user chỉ định số IOPS muốn và Google cấp phát capacity tương ứng.
Đặc tính kỹ thuật:
- IOPS: 2.5 IOPS/GiB (default), có thể provision lên đến 120,000 Read IOPS và 120,000 Write IOPS/instance
- Read throughput: 4,000 MiB/s (yêu cầu N2 instance với ≥64 vCPUs)
- Write throughput: 3,000 MiB/s (cùng điều kiện)
- Durability: better than 99.9999%
Lưu ý quan trọng: throughput limit 4,000/3,000 MiB/s chỉ đạt được với N2 instance có ít nhất 64 vCPUs. Với machine type nhỏ hơn, VM-level cap sẽ thấp hơn.
pd-extreme vs Hyperdisk Extreme: pd-extreme là bước quá độ, vẫn trong dòng PD với API và semantics quen thuộc. Hyperdisk Extreme là thế hệ mới hơn với cao hơn về IOPS ceiling (350,000) và flexible provisioning đầy đủ. Đối với workloads mới triển khai, Hyperdisk Extreme nên được ưu tiên nếu machine type hỗ trợ.
So sánh durability và design trade-offs
| Loại | Backend | IOPS/GiB | Max IOPS | Durability |
|---|---|---|---|---|
| pd-standard | HDD | 0.75–1.5 | 7,500–15,000 | >99.99% |
| pd-balanced | SSD | 6 | 80,000 | >99.999% |
| pd-ssd | SSD | 30 | 100,000 | >99.999% |
| pd-extreme | SSD | 2.5 (provision) | 120,000 | >99.9999% |
Tại sao pd-extreme có durability 99.9999% (6 nines) trong khi pd-ssd chỉ 99.999% (5 nines)? pd-extreme sử dụng stronger replication model ở tầng Colossus — nhiều replicas hơn và stricter consistency requirements. Điều này làm tăng write latency một chút nhưng đổi lấy độ bền cao nhất trong dòng PD.
Persistent Disk không phải block device truyền thống: implications thực tế
Vì Persistent Disk là network storage, một số assumptions đúng với local disk không đúng với PD:
1. Queue depth ảnh hưởng mạnh đến throughput
Khác với NVMe local SSD có internal parallelism rất cao, Persistent Disk cần I/O queue depth cao để đạt maximum throughput. Với queue depth thấp (ví dụ: 1–4), application chỉ đạt được một phần nhỏ maximum IOPS vì mỗi request phải chờ network round-trip.
Để đạt maximum IOPS trên pd-ssd, queue depth thường cần từ 32 đến 256 tùy workload. Database engines như PostgreSQL hoặc MySQL cần được tune max_connections và I/O subsystem để saturate disk properly.
2. Performance không degraded khi disk gần đầy
Với HDD truyền thống, fragmentation và seek time tăng khi disk đầy. Với PD, đây không phải vấn đề — Colossus quản lý physical allocation hoàn toàn, và performance không bị ảnh hưởng bởi utilization percentage.
3. Detach và reattach nhanh
Vì data không thực sự nằm trên server của VM, việc detach disk khỏi một VM và attach vào VM khác chỉ mất vài giây (thường dưới 30 giây). Đây là cơ sở cho nhiều HA patterns — failover bằng cách reattach disk thay vì phải restore từ backup.
4. Throughput bị cap bởi network egress
Write throughput thực tế bị limited bởi network egress capacity của VM, không chỉ bởi disk spec. Với n1-standard-4 (4 vCPUs), maximum egress khoảng 4 Gbps (~500 MiB/s). Ngay cả pd-ssd với limit 1,200 MiB/s write throughput cũng không đạt được trên VM nhỏ này.
Anti-pattern: sizing disk chỉ theo capacity
Sai lầm phổ biến nhất là provision PD với capacity vừa đủ cho data, bỏ qua performance implications. Ví dụ:
Một database PostgreSQL cần 10,000 IOPS. Engineer provision pd-ssd 200 GiB (vì data ~150 GiB).
Thực tế: 200 GiB × 30 IOPS/GiB = 6,000 IOPS — không đủ.
Để đạt 10,000 IOPS với pd-ssd cần ít nhất: 10,000 / 30 ≈ 334 GiB.
Giải pháp đúng: size theo performance requirement, không theo capacity requirement. Nếu cần IOPS cao hơn capacity lớn, đây là lúc cân nhắc Hyperdisk với provisioned IOPS model.