Mô Hình Hiệu Năng Persistent Disk & Giới Hạn VM
Tại sao phần này quan trọng
Performance của Persistent Disk không phải một con số đơn giản. Nó là kết quả của hai giới hạn độc lập tương tác với nhau: giới hạn per-disk (tính theo dung lượng) và giới hạn per-VM (tính theo machine type và vCPUs). Application thực tế bị bottleneck bởi ceiling nào thấp hơn trong hai ceiling này. Nếu chỉ quan tâm đến một, bạn sẽ bị bất ngờ khi workload không đạt được performance kỳ vọng dù đã provision đủ disk.
Hai ceiling độc lập
Ceiling 1: Per-disk limit (tính theo GiB)
Mỗi GiB dung lượng của Persistent Disk đóng góp một lượng IOPS và throughput nhất định vào tổng performance budget. Công thức:
Max IOPS = Per-GiB rate × Tổng disk size (GiB) + Baseline
Max Throughput = Per-GiB rate × Tổng disk size (GiB) + BaselineCụ thể theo loại disk:
| Loại | IOPS/GiB (đọc) | IOPS/GiB (ghi) | Throughput/GiB | Baseline IOPS | Baseline Throughput |
|---|---|---|---|---|---|
| pd-standard | 0.75 | 1.5 | 0.12 MiB/s | — | — |
| pd-balanced | 6 | 6 | 0.28 MiB/s | 3,000 | 140 MiB/s |
| pd-ssd | 30 | 30 | 0.48 MiB/s | 6,000 | 240 MiB/s |
| pd-extreme | provisioned | provisioned | scaled | — | — |
Baseline đóng vai trò gì? pd-balanced và pd-ssd có baseline guarantee — ngay cả khi per-GiB × size < baseline, disk vẫn deliver ít nhất mức baseline. Điều này có nghĩa là disk 10 GiB pd-balanced vẫn đạt 3,000 IOPS (không chỉ 60 IOPS từ 10 × 6).
Ceiling 2: Per-instance (VM-level) limit
Không quan trọng disk lớn thế nào hay thuộc type gì — VM có hard ceiling riêng cho tổng IOPS và throughput của tất cả disk cộng lại mà nó có thể xử lý. Giới hạn này phụ thuộc vào machine family và số vCPUs.
Theo Persistent Disk performance documentation, các giới hạn per-instance điển hình:
| Loại disk | Max IOPS/instance | Max Read Throughput/instance | Max Write Throughput/instance |
|---|---|---|---|
| pd-standard | 7,500 read / 15,000 write | 1,200 MiB/s | 400 MiB/s |
| pd-balanced | 80,000 | 1,200 MiB/s | 1,200 MiB/s |
| pd-ssd | 100,000 | 1,200 MiB/s | 1,200 MiB/s |
| pd-extreme | 120,000 | 4,000 MiB/s* | 3,000 MiB/s* |
*Chỉ đạt được trên N2 instance với ≥64 vCPUs.
Quan trọng: Giới hạn per-instance là aggregate limit — tổng IOPS của tất cả các disk attach vào VM đó, không phải mỗi disk riêng lẻ.
Công thức tính performance thực tế
Google Cloud documentation cung cấp công thức chính thức:
Performance thực tế = min(
Baseline + Per-GiB rate × Tổng capacity,
Per-instance limit
)Ví dụ 1: Một disk pd-balanced 500 GiB trên VM n2-standard-8
- Per-disk limit: 3,000 + (6 × 500) = 6,000 IOPS
- Per-instance limit pd-balanced: 80,000 IOPS
- Kết quả: min(6,000, 80,000) = 6,000 IOPS
→ Bottleneck là disk size, không phải VM.
Ví dụ 2: Hai disk pd-balanced mỗi cái 2,000 GiB trên VM n2-standard-4
- Disk 1: 3,000 + (6 × 2,000) = 15,000 IOPS
- Disk 2: 3,000 + (6 × 2,000) = 15,000 IOPS
- Tổng per-disk: 30,000 IOPS
- Per-instance limit: 80,000 IOPS
- Kết quả: min(30,000, 80,000) = 30,000 IOPS aggregate
→ Bottleneck vẫn là disk size (mỗi disk chỉ có 15,000 IOPS), nhưng VM chưa bị giới hạn.
Ví dụ 3: Nhiều disk pd-ssd tổng 5,000 GiB
- Tổng per-disk: 6,000 + (30 × 5,000) = 156,000 IOPS
- Per-instance limit pd-ssd: 100,000 IOPS
- Kết quả: min(156,000, 100,000) = 100,000 IOPS
→ Bottleneck là VM-level cap. Thêm disk không tăng IOPS thêm được nữa.
Network egress: giới hạn thứ ba (thường bị bỏ qua)
Ngoài hai ceiling trên, write throughput còn bị giới hạn bởi network egress capacity của VM. Vì Persistent Disk là network storage, mọi write operation đều consume network bandwidth từ VM đến Colossus.
Với n1-standard-4 (4 vCPUs), network egress khoảng 4 Gbps (~500 MiB/s). Với pd-ssd write throughput limit là 1,200 MiB/s, VM với 4 vCPUs sẽ không bao giờ đạt 1,200 MiB/s write throughput, bất kể disk lớn thế nào.
Để saturate throughput limit của pd-ssd hoặc pd-balanced (1,200 MiB/s), cần machine type đủ lớn với network egress > 1,200 MiB/s × 8 bits = ~9.6 Gbps.
Quy tắc thực tế: provision VM đủ vCPU để đảm bảo network egress > disk write throughput target.
I/O queue depth và thực tế đạt max IOPS
Một yếu tố ít được document nhưng quan trọng trong production: để đạt maximum IOPS, application phải submit đủ outstanding I/O requests song song. Với network latency ~1ms, để đạt 100,000 IOPS, cần khoảng:
Queue depth cần thiết ≈ Target IOPS × Latency
= 100,000 × 0.001s
= 100 outstanding I/O requestsNếu application chỉ submit 8–16 requests tại một thời điểm, dù disk và VM đủ capacity, throughput thực tế sẽ thấp hơn nhiều lần.
Đây là lý do tại sao:
- Database engines cần được tune về
max_parallel_workers,work_mem, I/O concurrency - fio benchmarks dùng
-iodepth=64hoặc cao hơn để đo max IOPS thực sự - Hệ thống filesystem có thể là bottleneck nếu không được tune cho high-concurrency I/O
Sizing hướng đến performance target
Thay vì "tôi có bao nhiêu data", câu hỏi đúng là "tôi cần bao nhiêu IOPS":
Bước 1: Xác định IOPS target
Đối với database:
- OLTP PostgreSQL/MySQL: thường 5,000–50,000 IOPS tùy workload
- Analytics/OLAP: thường throughput-bound hơn IOPS-bound
Cách đo IOPS thực tế của workload đang chạy:
# Đo IOPS của disk hiện tại
iostat -x 1 10 | grep -v loopBước 2: Tính disk size cần thiết
Disk size cần = max(IOPS target / IOPS per GiB, capacity cần thiết)Ví dụ, cần 20,000 IOPS với pd-ssd:
- Disk size cần (từ IOPS): 20,000 / 30 = 667 GiB
- Disk size cần (từ data): giả sử 200 GiB
- Chọn: 667 GiB (performance requirement larger)
Bước 3: Verify VM-level cap không bị vượt
Tổng IOPS của tất cả disks không được vượt per-instance limit. Nếu vượt, xem xét:
- Dùng Hyperdisk với VM-level limits cao hơn
- Scale up VM type (các machine types lớn hơn có higher per-instance limits)
- Phân tán workload qua nhiều VMs
Scaling performance với multiple disks
Attach nhiều Persistent Disk vào cùng một VM cộng dồn performance — miễn là không vượt VM-level ceiling. Đây là kỹ thuật phổ biến để đạt high IOPS mà không cần provision disk quá lớn:
Tổng IOPS (many disks) = Σ IOPS từng disk (không quá per-instance limit)Ví dụ: 4 disk pd-ssd 250 GiB mỗi cái vs 1 disk pd-ssd 1,000 GiB:
- 4 disk × 250 GiB: 4 × (6,000 + 30 × 250) = 4 × 13,500 = 54,000 IOPS aggregate
- 1 disk × 1,000 GiB: 6,000 + 30 × 1,000 = 36,000 IOPS
→ Nhiều disk nhỏ hơn = IOPS cao hơn vì mỗi disk có baseline riêng (6,000 IOPS/disk).
Tuy nhiên, nhiều disks phức tạp hơn về mặt quản lý. Trong production, thường dùng Logical Volume Manager (LVM) hoặc RAID software để gộp nhiều disks thành một logical volume.
Failure mode: VM-level cap bị hit ngầm
Kịch bản phổ biến trong production: team database tăng dung lượng disk để tăng IOPS. Ban đầu có hiệu quả. Sau đó đến một thời điểm, tăng thêm disk không cải thiện IOPS nữa — không có error, không có alert, chỉ đơn giản là IOPS không tăng.
Nguyên nhân: VM-level cap đã bị hit. Mọi disk thêm vào sau điểm này đều đóng góp dung lượng nhưng không đóng góp thêm IOPS do VM aggregate limit.
Cách chẩn đoán: xem xét google_compute_instance_disk_read_ops_count metric trong Cloud Monitoring, so sánh với theoretical maximum của VM type. Nếu gần sát ceiling → cần scale up VM hoặc chuyển sang Hyperdisk.