Tuyệt chiêu ‘trị’ lag I/O: Chuyển đổi VMware Thin sang Thick Provisioning – ITFROMZERO

Table of Contents

Câu chuyện thực tế: Khi máy ảo ‘thở dốc’ vì ổ cứng

Năm 2022, khi đang vận hành cụm 8 node ESXi cho một hệ thống ERP, mình từng gặp một ca khá oái oăm. Một con SQL Server bỗng dưng ‘lag’ điên cuồng, I/O latency vọt lên tận 50ms trong khi bình thường chỉ dưới 5ms. Kiểm tra kỹ thì thấy hệ thống lưu trữ (SAN) vẫn rảnh rang. Thủ phạm hóa ra lại nằm ở định dạng đĩa Thin Provisioning của máy ảo đó.

Vấn đề của đĩa Thin là nó chỉ chiếm dung lượng trên SAN khi có dữ liệu thực tế. Nghe thì có vẻ tiết kiệm nhưng thực chất lại rất tốn tài nguyên xử lý. Mỗi lần máy ảo cần ghi dữ liệu vào block mới, Hypervisor lại phải ‘hì hục’ đi tìm block trống, xóa dữ liệu cũ rồi mới cấp phát. Chính độ trễ metadata này đã ‘bóp nghẹt’ hiệu suất của những ứng dụng cần ghi dữ liệu liên tục.

Dưới đây là cách mình đã xử lý dứt điểm tình trạng này bằng cách chuyển đổi qua lại giữa các định dạng đĩa để tối ưu hiệu suất I/O.

So sánh nhanh 3 loại đĩa trong VMware

Để chọn đúng ‘thuốc’ cho bệnh, anh em cần nắm rõ đặc tính của từng loại:

Thin Provisioning: Tiết kiệm dung lượng nhất, dùng đến đâu trả tiền đến đó. Tuy nhiên, nó gây ra khoảng 5-10% CPU overhead do việc cấp phát động. Phù hợp làm máy Lab hoặc Web Server nhẹ.
Thick Provisioning Lazy Zeroed: Cấp đất sẵn nhưng chưa dọn dẹp. Nó chỉ thực hiện xóa (zero out) các block khi máy ảo ghi dữ liệu lần đầu. Hiệu suất ổn định hơn Thin một chút.
Thick Provisioning Eager Zeroed: Đây là lựa chọn số 1 cho Database. Nó cấp phát toàn bộ dung lượng và xóa sạch các block ngay từ đầu. Tuy tốn thời gian khởi tạo nhưng đổi lại hiệu suất I/O cực kỳ ổn định, không còn độ trễ cấp phát.

Chuyển từ Thin sang Thick (Bơm căng hiệu suất)

Khi thấy máy ảo có dấu hiệu ‘đuối’ I/O, anh em hãy cân nhắc chuyển sang Thick ngay. Có hai cách mình thường áp dụng tùy vào điều kiện hạ tầng.

Cách 1: Dùng tính năng Inflate (Đơn giản nhất)

Nếu ngại gõ lệnh, đây là cứu cánh cho anh em. Lưu ý nhỏ: Bạn bắt buộc phải tắt máy ảo mới có thể thực hiện được.

Mở vSphere Client, tìm máy ảo đang cần ‘cấp cứu’.
Truy cập Datastore Browser, tìm đến đúng thư mục chứa file máy ảo.
Click chuột phải vào file .vmdk (thường là file lớn nhất).
Chọn Inflate và đợi hệ thống chạy.

Sau khi hoàn tất, ổ đĩa sẽ tự động chuyển sang dạng Lazy Zeroed, giúp loại bỏ độ trễ do mở rộng dung lượng đĩa ảo.

Cách 2: Sử dụng lệnh vmkfstools (Chuyên sâu)

Mình thích cách này hơn vì nó cho phép chuyển thẳng lên Eager Zeroed để lấy hiệu suất tối đa. Đầu tiên, hãy bật SSH trên host ESXi và đăng nhập qua Putty hoặc Terminal.

Di chuyển vào thư mục chứa máy ảo:

cd /vmfs/volumes/DATASTORE_ID/VM_FOLDER/

Tiến hành clone đĩa cũ sang một định dạng mới:

# Convert sang Thick Eager Zeroed cực nhanh
vmkfstools -i original.vmdk -d eagerzeroedthick new_thick_disk.vmdk

Xong xuôi, anh em chỉ việc vào Edit Settings của máy ảo, xóa đĩa cũ và trỏ lại vào file new_thick_disk.vmdk là máy chạy mượt như lụa.

Chuyển từ Thick về Thin (Khi Storage kêu cứu)

Trong thực tế, đôi khi Storage báo đỏ (vượt ngưỡng 90%) và mình buộc phải thu hồi dung lượng từ những máy ảo ít quan trọng.

Storage vMotion: Giải pháp không gây gián đoạn

Nếu hệ thống có vCenter và bản quyền phù hợp, anh em có thể làm việc này mà không cần tắt máy. Thao tác cực kỳ ‘chill’:

Chuột phải vào máy ảo, chọn Migrate.
Chọn Change storage only.
Tại phần định dạng đĩa, hãy chọn Thin Provision.
Chọn Datastore khác (hoặc chính nó nếu có đủ chỗ trống tạm thời).

VMware sẽ tự động ‘vắt nước’ và chỉ giữ lại phần dung lượng thực sự chứa dữ liệu.

Kinh nghiệm ‘xương máu’ sau nhiều năm vận hành

Qua nhiều lần xử lý sự cố trên các cụm Cluster lớn, mình rút ra 3 bài học đắt giá:

Đừng để ‘vỡ trận’ vì Overprovisioning: Thin Provisioning rất dễ gây ảo giác. Bạn tạo 10 con máy ảo 500GB trên cái đĩa 1TB thấy vẫn ổn, nhưng khi chúng đồng loạt ghi dữ liệu, cả hệ thống sẽ ‘đứng hình’ ngay lập tức. Luôn đặt Alarm cảnh báo ở mức 85%.
Check kỹ backup: Thao tác với file .vmdk luôn tiềm ẩn rủi ro. Dù bạn tự tin đến đâu, hãy đảm bảo bản backup gần nhất vẫn đang hoạt động tốt.
Tránh giờ cao điểm: Việc tạo đĩa Eager Zeroed tốn rất nhiều I/O của Storage. Đừng dại dột làm việc này vào 9h sáng thứ Hai nếu không muốn nhận cả ‘rổ’ ticket than phiền từ người dùng.

Lời kết

Tối ưu hóa I/O không chỉ đơn thuần là mua thêm ổ cứng xịn. Đôi khi chỉ cần một thay đổi nhỏ từ Thin sang Thick Eager Zeroed là hệ thống đã có thể vận hành trơn tru hơn hẳn. Hy vọng những chia sẻ này giúp anh em tự tin hơn trong việc quản trị hạ tầng ảo hóa của mình.