Bài 13 — Block Storage — EBS, Persistent Disk

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa thuê một máy chủ ảo (VM) trên cloud để chạy website bán mỹ phẩm của công ty. Máy chạy được vài tuần, dữ liệu đơn hàng, hình ảnh sản phẩm, log truy cập cứ thế lớn dần. Rồi một buổi sáng bạn nhận ra ổ đĩa hệ thống đã đầy 95%, database bắt đầu báo lỗi "disk full", và bạn cần thêm dung lượng — ngay lập tức, không được để mất một byte dữ liệu nào. Câu hỏi đặt ra: làm sao gắn thêm một "ổ cứng" mới vào máy đang chạy, mở rộng nó khi cần, và quan trọng nhất là dữ liệu vẫn còn nguyên kể cả khi máy chủ bị xoá?

Câu trả lời chính là Block Storage — chủ đề của bài học hôm nay. Nếu ở Bài 12 bạn đã học về Object Storage (S3, Cloud Storage) dùng để lưu file qua API, thì Block Storage lại là một loại lưu trữ hoàn toàn khác về bản chất: nó hoạt động y hệt một ổ cứng vật lý cắm vào máy tính. Đây là nền tảng chạy hầu hết các database, các ứng dụng cần ghi/đọc nhanh, và là thứ mà mọi kỹ sư DevOps đều phải nắm vững vì nó liên quan trực tiếp đến hiệu năng, chi phí và độ an toàn dữ liệu.

Nắm chắc Block Storage giúp bạn tránh ba loại tai nạn phổ biến: mất dữ liệu khi xoá VM, hệ thống chậm rì vì chọn sai loại đĩa, và hoá đơn cloud phình to vì để đĩa "mồ côi" chạy hoài không dùng. Đây đều là những lỗi mà người mới hay mắc, và bài này sẽ trang bị cho bạn cách tư duy đúng.

Khái niệm cốt lõi

Block Storage là gì

Block Storage là dạng lưu trữ chia dữ liệu thành các block (khối) có kích thước cố định, mỗi block có địa chỉ riêng. Hệ điều hành đọc/ghi trực tiếp lên từng block giống như thao tác với một ổ cứng vật lý. Nói đơn giản: cloud provider cấp cho bạn một volume (khối lượng đĩa), bạn attach (gắn) nó vào VM, và trong máy nó hiện ra như một ổ đĩa trống. Bạn phải tự format nó thành một filesystem (ext4, XFS trên Linux, hoặc NTFS trên Windows) rồi mount vào một thư mục để bắt đầu sử dụng.

Điểm khác biệt cốt lõi so với Object Storage: với Object Storage bạn gọi API để "put/get" cả một file trọn vẹn. Với Block Storage, ứng dụng có thể sửa một phần nhỏ giữa file mà không cần ghi lại toàn bộ — cực kỳ quan trọng với database, nơi mỗi giao dịch chỉ cập nhật vài dòng.

Các nhà cung cấp và tên gọi

Mỗi cloud đặt tên sản phẩm Block Storage khác nhau, nhưng bản chất tương đương:

• AWS: EBS (Elastic Block Store) — volume gắn vào EC2 instance.
• Google Cloud: Persistent Disk (và dòng mới hiệu năng cao là Hyperdisk) — gắn vào Compute Engine VM.
• Azure: Managed Disk — gắn vào Azure VM.
• Cloud Việt Nam (Viettel IDC, FPT Cloud, VNG Cloud): thường gọi chung là Block Storage hoặc Cloud Volume, cung cấp qua console tương tự.

Các loại volume và hiệu năng

Không phải đĩa nào cũng như nhau. Cloud provider cho bạn chọn theo công nghệ nền và mức hiệu năng, và đây là nơi tiền bạc gặp kỹ thuật:

• SSD thông thường (AWS: gp3/gp2; GCP: pd-ssd/pd-balanced; Azure: Premium SSD): cân bằng giữa giá và tốc độ, phù hợp phần lớn ứng dụng.
• SSD hiệu năng cao / Provisioned IOPS (AWS: io2; GCP: Hyperdisk; Azure: Ultra Disk): cho database lớn cần độ trễ thấp và IOPS ổn định, giá cao hơn nhiều.
• HDD (AWS: st1/sc1): rẻ, dung lượng lớn, dùng cho dữ liệu ghi tuần tự như log, backup lạnh — không dùng cho database.

Ba chỉ số bạn cần nhớ khi đánh giá hiệu năng đĩa:

• IOPS: số thao tác đọc/ghi mỗi giây — quan trọng với workload nhiều truy vấn nhỏ như database giao dịch.
• Throughput (MB/s): lượng dữ liệu chuyển mỗi giây — quan trọng khi đọc/ghi file lớn.
• Latency (độ trễ): thời gian hoàn thành một thao tác — càng thấp càng tốt.

Với AWS gp3 chẳng hạn, bạn được mặc định 3.000 IOPS và 125 MB/s, và có thể trả thêm tiền để nâng lên tối đa 16.000 IOPS mà không cần tăng dung lượng — một cải tiến lớn so với gp2 cũ (nơi IOPS bị buộc chặt vào dung lượng, muốn nhiều IOPS phải mua đĩa to).

Đặc điểm quan trọng cần khắc cốt ghi tâm

• Một volume thường chỉ gắn vào một VM tại một thời điểm (chế độ read-write). Đây không phải là ổ chia sẻ cho nhiều máy như File Storage (bài sau).
• Vòng đời độc lập với VM: bạn có thể cấu hình để volume tồn tại kể cả khi VM bị xoá — đây là chìa khoá bảo vệ dữ liệu.
• Ràng buộc theo vùng (zone): một EBS volume ở ap-southeast-1a chỉ gắn được vào EC2 trong cùng zone đó, không thể gắn xuyên zone.
• Snapshot: bạn có thể chụp ảnh (snapshot) trạng thái đĩa tại một thời điểm và lưu vào Object Storage. Snapshot dùng để backup, nhân bản, hoặc chuyển đĩa sang zone/region khác.

Tình huống thực tế

Ví dụ 1 — Sàn thương mại điện tử mở rộng ổ database không downtime

Một công ty bán lẻ mỹ phẩm ở TP.HCM chạy một cụm MySQL trên EC2 với volume gp2 200 GB. Vào đợt sale 12/12, lượng đơn tăng vọt, log giao dịch và dữ liệu phình nhanh, đĩa chạm ngưỡng 92%. Đội DevOps không thể tắt máy để thay đĩa vì mỗi phút downtime là mất doanh thu.

Diễn giải: Họ dùng tính năng Elastic Volumes của EBS để tăng dung lượng từ 200 GB lên 500 GB ngay khi VM đang chạy, sau đó chạy lệnh growpart và resize2fs để filesystem nhận diện phần dung lượng mới — tất cả trong vòng vài phút, không downtime. Nhân dịp này họ cũng chuyển loại đĩa từ gp2 sang gp3 để được nhiều IOPS hơn với giá rẻ hơn khoảng 20%, và cấu hình thẳng 6.000 IOPS phục vụ đỉnh tải.

Bài học: Block Storage trên cloud là "co giãn" (elastic). Bạn không cần mua dư dung lượng ngay từ đầu; hãy bắt đầu vừa đủ và mở rộng khi cần. Nhưng nhớ: tăng dung lượng volume ở phía cloud xong vẫn phải resize filesystem bên trong OS thì mới thực sự dùng được.

Ví dụ 2 — Startup fintech mất dữ liệu vì "Delete on Termination"

Một startup fintech ở Hà Nội có kỹ sư mới dựng môi trường staging trên EC2. Khi dọn dẹp cuối tháng để tiết kiệm chi phí, anh này terminate (xoá) một loạt instance không dùng. Vấn đề: volume root chứa cả database PostgreSQL của staging được để mặc định cờ Delete on Termination = true. Xoá VM là mất luôn đĩa. Hai tuần dữ liệu test và cấu hình biến mất.

Diễn giải: May mắn là họ đã bật lịch snapshot tự động hằng ngày qua AWS Backup, nên khôi phục lại được từ snapshot của ngày hôm trước, chỉ mất khoảng nửa ngày dữ liệu. Sau sự cố, đội thiết lập quy tắc: mọi volume chứa dữ liệu quan trọng phải đặt DeleteOnTermination = false, và tách data volume ra khỏi root volume để terminate VM không đụng tới dữ liệu.

Bài học: Vòng đời của volume và VM là hai thứ khác nhau, và bạn phải chủ động kiểm soát nó. Đừng bao giờ tin vào mặc định. Snapshot định kỳ là "lưới an toàn" cuối cùng — hãy có nó trước khi cần đến.

Ví dụ 3 — Chọn sai loại đĩa khiến app chậm rì

Một công ty logistics ở Đông Nam Á chuyển hệ thống theo dõi đơn hàng lên GCP. Để tiết kiệm, họ chọn Persistent Disk loại pd-standard (nền HDD) cho database MongoDB. Ban đầu chạy ổn, nhưng khi số lượng truy vấn ngẫu nhiên tăng lên, ứng dụng phản hồi chậm hẳn, có lúc trang tra cứu mất 8–10 giây để tải.

Diễn giải: Nguyên nhân là HDD có IOPS thấp và latency cao, không hợp với database vốn thực hiện rất nhiều thao tác đọc/ghi ngẫu nhiên cỡ nhỏ. Đội chuyển sang pd-ssd, latency giảm mạnh và thời gian phản hồi trang về dưới 1 giây. Chi phí đĩa tăng nhưng không đáng kể so với giá trị của trải nghiệm người dùng.

Bài học: Loại đĩa quyết định hiệu năng nhiều hơn bạn tưởng. Database → luôn dùng SSD. HDD chỉ dành cho dữ liệu ghi tuần tự, ít truy cập như log lưu trữ hay backup.

Hướng dẫn từng bước

Dưới đây là quy trình chuẩn để tạo và sử dụng một Block Storage volume trên Linux (minh hoạ với AWS EBS, nhưng tư duy áp dụng chung cho mọi cloud):

• Tạo volume: Trong console (hoặc CLI aws ec2 create-volume), chọn dung lượng, loại đĩa (ví dụ gp3 100 GB), và đúng Availability Zone trùng với VM của bạn. Nếu khác zone sẽ không gắn được.

• Attach volume vào VM: Gắn volume vào instance, chỉ định device name (ví dụ /dev/xvdf). Sau bước này, trong máy Linux đĩa mới sẽ xuất hiện.

• Kiểm tra đĩa đã nhận: Chạy lsblk để thấy đĩa mới. Lưu ý nó chưa có filesystem — đây là đĩa trống hoàn toàn.

• Format thành filesystem: Chạy sudo mkfs -t ext4 /dev/xvdf (hoặc XFS nếu muốn). Bước này chỉ làm MỘT LẦN với đĩa mới; format lại đĩa đang có dữ liệu sẽ xoá sạch mọi thứ.

• Mount vào thư mục: Tạo điểm mount sudo mkdir /data, rồi sudo mount /dev/xvdf /data. Giờ bạn đã có thể ghi dữ liệu vào /data.

• Mount tự động khi khởi động lại: Thêm dòng vào /etc/fstab (nên dùng UUID của đĩa thay vì tên /dev/xvdf vì tên device có thể thay đổi). Nếu quên bước này, sau khi reboot đĩa sẽ không tự mount lại.

• Bật backup: Thiết lập snapshot định kỳ (AWS Backup / Data Lifecycle Manager, GCP snapshot schedule, Azure Backup) cho mọi volume quan trọng.

Khi cần mở rộng dung lượng sau này: tăng size volume ở console → chạy sudo growpart /dev/xvda 1 (nếu có phân vùng) → sudo resize2fs /dev/xvdf (với ext4) hoặc sudo xfs_growfs /data (với XFS). Kiểm tra bằng df -h.

Lỗi thường gặp & mẹo

• Quên resize filesystem sau khi tăng volume: Đây là lỗi kinh điển. Bạn tăng đĩa từ 100 GB lên 300 GB trên console nhưng df -h vẫn báo 100 GB. Phải chạy resize2fs/xfs_growfs bên trong OS thì mới dùng được phần mới.

• Format nhầm đĩa đang có dữ liệu: mkfs xoá sạch mọi thứ. Luôn kiểm tra kỹ tên device bằng lsblk trước khi format, và không bao giờ format đĩa đã mount.

• Không thêm vào /etc/fstab hoặc dùng sai UUID: Reboot xong đĩa biến mất khỏi thư mục, ứng dụng báo lỗi không tìm thấy dữ liệu. Luôn dùng UUID và thêm tuỳ chọn nofail để máy không bị treo khi boot nếu đĩa chưa sẵn sàng.

• Để đĩa "mồ côi" (orphaned/unattached): Khi xoá VM nhưng volume vẫn còn, nó tiếp tục tính tiền dù không dùng. Định kỳ rà soát volume ở trạng thái available (chưa gắn) và snapshot cũ để dọn dẹp — đây là nguồn lãng phí chi phí âm thầm rất lớn.

• Kỳ vọng gắn một volume vào nhiều VM cùng lúc: Block Storage tiêu chuẩn không làm được điều này để ghi đồng thời. Nếu cần chia sẻ giữa nhiều máy, hãy dùng File Storage (EFS, Filestore — sẽ học ở bài sau), không phải Block Storage.

• Mẹo tiết kiệm: Trên AWS, chuyển từ gp2 sang gp3 gần như luôn tiết kiệm được tiền với hiệu năng bằng hoặc tốt hơn. Đây là "quick win" nên làm ngay.

• Mẹo an toàn: Bật mã hoã (encryption at-rest) cho volume ngay khi tạo — nó gần như miễn phí và bảo vệ dữ liệu nếu ổ vật lý bị lộ. Snapshot của volume đã mã hoá cũng tự động được mã hoá.

Bài tập thực hành

• Thực hành attach & mount: Tạo một VM nhỏ (free-tier nếu có) trên AWS hoặc GCP. Tạo thêm một Block Storage volume 10 GB, gắn vào VM, rồi tự thực hiện đủ chuỗi lsblk → mkfs → mount → thêm vào /etc/fstab. Reboot máy và xác nhận đĩa vẫn được mount tự động.

• Thực hành mở rộng: Từ volume vừa tạo, tăng dung lượng lên 20 GB qua console. Ghi lại các lệnh bạn cần chạy trong OS để filesystem nhận đủ 20 GB, và kiểm chứng bằng df -h.

• Thực hành snapshot & khôi phục: Ghi một file test vào đĩa, tạo một snapshot, xoá file đó, rồi tạo volume mới từ snapshot và gắn vào máy. Xác nhận file test đã quay lại. Ghi lại thời gian mỗi bước.

• Bài tập tư duy chi phí: Giả sử bạn có 5 VM, mỗi máy cần đĩa dữ liệu 200 GB. Hãy so sánh chi phí ước tính giữa gp3 và io2 trên bảng giá AWS ở region ap-southeast-1 (Singapore), và giải thích trường hợp nào nên chọn loại nào.

Tóm tắt

Block Storage là loại lưu trữ hoạt động như một ổ cứng vật lý gắn vào VM: bạn tạo volume, attach vào máy, format thành filesystem (ext4/XFS/NTFS) và mount để dùng. Trên AWS nó là EBS, GCP là Persistent Disk, Azure là Managed Disk, và các cloud Việt Nam gọi chung là Block Storage/Cloud Volume. Đặc trưng quan trọng nhất: nó cho phép ghi/đọc ở mức block nên là nền tảng lý tưởng cho database và ứng dụng cần hiệu năng cao — khác hẳn Object Storage vốn thao tác trên cả file.

Ba điều cần khắc cốt: chọn đúng loại đĩa (SSD cho database, HDD cho log/backup) để không bị chậm; kiểm soát vòng đời volume độc lập với VM (tắt Delete on Termination, tách data volume) để không mất dữ liệu; và luôn có snapshot định kỳ làm lưới an toàn. Cuối cùng, đừng quên hai thao tác dễ bỏ sót: resize filesystem sau khi tăng volume, và cấu hình /etc/fstab để đĩa tự mount sau reboot. Nắm vững những nguyên tắc này, bạn đã có nền tảng vững chắc để vận hành hạ tầng lưu trữ trên cloud một cách an toàn và tiết kiệm.