Là chạy vĩnh viễn trong ảnh chụp nhanh VMWare có hại cho hiệu suất?

Tôi hiểu rằng VMWare KB cau mày khi các ảnh chụp nhanh chạy chủ yếu do hai điều (theo tôi)

Lấy hàng tấn ảnh chụp nhanh có thể lấp đầy kho dữ liệu. Ảnh chụp đơn giản là các tập tin delta. Giả sử bạn có VMDK 50 Gig, gần đầy và bạn chụp nhanh. Trong ảnh chụp nhanh của bạn, bạn lật từng bit một. Tệp delta của bạn cũng sẽ có dung lượng khoảng 50 GB. Ảnh chụp lại, lật các bit, một tệp delta 50 Gig khác. Những thứ này có thể vượt khỏi tầm kiểm soát nhanh chóng.
Cam kết ảnh chụp nhanh mang rủi ro. Khi hợp nhất các ảnh chụp nhanh, bạn đang viết các thay đổi delta cho VMDK ban đầu. Điều này làm mất thời gian và có nguy cơ rằng nếu có điều gì đó xảy ra, bạn chỉ cần lấy VMDK của mình.

Những cảnh báo của họ dường như có ý nghĩa logic.

Với điều đó đã được nói, nó có phải là xấu khi chạy máy của tôi vĩnh viễn khỏi một VMDK chụp nhanh? Tôi muốn làm cho cây của tôi như sau:

Căn cứ
- Snap1
  - Chụp 2
  - Bạn đang ở đây

Snap 1 và 2 sẽ được thực hiện ngay sau khi cài đặt và cung cấp hệ thống cơ sở. Đây là những máy tôi dự định làm mới thường xuyên vì vậy tôi chỉ đơn giản là làm cho cây của tôi trông như sau:

Căn cứ
- Snap1
  - Bạn đang ở đây
  - Chụp 2

Xóa Snap2 và tạo lại Snap2.

Tôi không thể thấy làm thế nào điều này có thể có bất kỳ tác động nào vì những lý do sau:

Vì tôi chỉ cần cài đặt một hình ảnh cơ bản và lấy đồng bằng của tôi ngay lập tức sau khi không có cách nào tôi có thể lấp đầy kho lưu trữ dữ liệu. Giả sử hình ảnh cơ sở của tôi chỉ là 10 GB (trên đĩa được cung cấp mỏng 50 GB), ngay cả khi đồng bằng của tôi bị lật từng bit, tổng mức sử dụng tối đa của tôi có thể là 60 GB (VMDK cơ sở 10 GB bị khóa + 50 GB delta tệp VMDK chụp nhanh). Điều này giả định rằng tôi không tạo thêm bất kỳ ảnh chụp nhanh nào.
Vì trường hợp sử dụng của tôi không yêu cầu hợp nhất các ảnh chụp nhanh, tôi không gặp rủi ro khi hợp nhất các vùng đồng bằng của mình. Khi tôi quay trở lại Snap1 và xóa Snap2, tất cả các delta nằm trong Snap2 chỉ đơn giản là bị xóa.
Tải lưu trữ hoàn toàn giống nhau, vì vậy tôi sẽ nhận được cùng một IOPS. Tôi hiểu rằng một số tệp (chủ yếu là tệp hệ thống) sẽ tồn tại trên VMDK ban đầu và các tệp khác (mọi thứ sau cơ sở) sẽ nằm trong vùng đồng bằng nhưng tôi không thấy ESXI sẽ quan tâm như thế nào. Tất cả các tệp nằm trên cùng một kho dữ liệu vật lý, do đó hiệu suất phải tương đương với việc tham chiếu mọi thứ trong VMDK ban đầu mà không có ảnh chụp nhanh.

Có suy nghĩ gì không? ESXI 5.5 với kho lưu trữ dữ liệu là DAS của RAID.

Tôi không có giấy phép vCenter nên việc tạo khuôn mẫu và nhân bản là không cần thiết.

KẾT QUẢ KIỂM TRA

Tôi đã vào đầu ngày hôm nay để chạy một số thử nghiệm. Đây là kết quả. Có một hình phạt hiệu suất nhưng tôi không chắc tại sao.

Trước khi chụp:

Sau khi chụp nhanh: Sau khi tạo hình

— VM_Storage_Inception
nguồn

Không chắc chắn - theo thời gian, các ảnh chụp nhanh sẽ phân kỳ ngày càng nhiều. Cuối cùng, chúng sẽ là bản sao khác nhau. Sau khi bạn không dự trữ nhiều đĩa bằng cách chụp nhanh chúng, hãy chuyển đổi ảnh chụp nhanh thành một ổ đĩa hoàn toàn riêng biệt. Làm sao? Thông thường, tôi sử dụng dd từ máy ảo thứ ba, nhưng chủ yếu tôi gần như bị đóng đinh ở đây vì những ý kiến dị giáo như vậy. :-) Nhưng: nó sẽ hoạt động , và sẽ có hiệu quả .

— peterh nói rằng phục hồi Monica

@PeterHorvath - Đó là thứ tôi thích nghe. Giải pháp thông minh, hacky, hiệu quả, xương trần. Nếu bạn không phiền, bạn có thể viết cho tôi những gì bạn làm trong pastebin hay gì không? Bạn có DD VMDK và chụp nhanh cùng nhau không?

— VM_Storage_Inception

Nếu tôi cần phải làm điều đó thường xuyên hơn, tôi đã làm nó với một kịch bản. Nhưng nó không phải là trường hợp, và trong hầu hết các trường hợp tôi không sử dụng ngay cả snapshpts, vì chúng chậm.

— peterh nói rằng phục hồi Monica

Câu trả lời:

Vâng, có ý nghĩa hiệu suất cho ảnh chụp nhanh trong thời gian dài. Thậm chí còn có ý nghĩa lớn hơn để hợp nhất các VMDK delta trở lại tệp đĩa gốc. Điều này có thể gây ra sự không phản hồi trong hệ điều hành VM của bạn hoặc hành vi không mong muốn khác.

VMware có chức năng tạo khuôn mẫu và nhân bản được tích hợp trong vCenter. Bạn cần giấy phép vSphere Essentials $ 600 để kích hoạt tính năng này.

Bạn có thể tạo một VM theo sở thích của mình, sau đó sao chép nó vào một mẫu. Mẫu đó sau đó có thể được sử dụng để tạo các máy ảo mới từ hình ảnh "Golden Master".

nhập mô tả hình ảnh ở đây

Điều này cho phép bạn có "trạng thái sạch" nhưng cũng tạo các máy ảo lâu dài hoặc vĩnh viễn từ hình ảnh chính đó. Không có ảnh chụp nhanh cần thiết.

— ewwhite
nguồn

Thật thú vị, tôi sẽ xem xét điều đó và xem nó hoạt động như thế nào. Thật không may, tôi không có giấy phép vCenter và thà không có org org của tôi trong số $ 600 nếu không có ý nghĩa về hiệu suất đối với các ảnh chụp nhanh được sử dụng theo cách tôi mô tả. Ngoài ra, việc tạo khuôn mẫu và nhân bản dường như không khác gì lấy một OVA và triển khai lại nó. Xóa các ảnh chụp nhanh có vẻ nhanh hơn rất nhiều và tôi không thể thấy một cách hợp lý làm thế nào sẽ có ý nghĩa về hiệu suất ngay cả khi đó không phải là "Phương pháp chính thức được VMWare phê duyệt".

— VM_Storage_Inception

Để trả lời chỉnh sửa của bạn, bạn có thể chỉ cho tôi một bài viết hoặc giải thích ý nghĩa hiệu suất sẽ là gì không? Tôi không thể thấy làm thế nào sẽ có bất kỳ giả sử tôi sử dụng chúng như tôi mô tả. Ngoài ra, tôi sẽ không bao giờ hợp nhất các ảnh chụp nhanh trở lại VMDK ban đầu.

— VM_Storage_Inception 4/12/14

Tôi đoán tôi đang cố gắng hiểu lý do tại sao bạn khăng khăng thiết kế xung quanh một tính năng có nghĩa là được sử dụng để truy cập ngắn hạn.

— ewwhite

@VM_Storage_Inception - có vẻ như bạn đang muốn một người đàn ông nghèo tiếp cận với Trình quản lý sản phẩm không còn tồn tại của VMWare.

— TheCleaner

Đôi khi, mua giải pháp phù hợp có ý nghĩa. Bạn đã dành nhiều nỗ lực và thời gian tìm hiểu về cách giải quyết hơn là chỉ trả tiền cho giấy phép vSphere Essentials ($ 600), sẽ cung cấp cho bạn tùy chọn nhân bản / mẫu được hỗ trợ.

— ewwhite

Câu trả lời của ewwhite là chính xác, nhưng chỉ cần mở rộng thêm một chút hoặc hình phạt hiệu suất, hãy xem xét kịch bản sau đây:

Bạn tạo một VM. Một lần đọc ảo từ vmdk lấy một đĩa vật lý có cùng kích thước. Khá đơn giản.

Bây giờ hãy tưởng tượng bạn chụp ảnh VM. Bây giờ, đối với mỗi lần đọc ảo, bạn sẽ phải chịu 2 lần đọc vật lý, một từ cơ sở vmdk và một từ delta vmdk, vì bạn cần thông tin từ cả hai để có trạng thái hiện tại. Bây giờ bạn đang ở hai lần đĩa vật lý đọc.

Đối với hai ảnh chụp nhanh, bạn đang thực hiện ba lần đọc, v.v. Nếu bạn có nhiều ảnh chụp nhanh, bạn có thể thấy đây có thể là một hình phạt hiệu suất khá đáng kể. Nó không nhất thiết phải chuyển thành hiệu suất kém hơn n lần (do bộ nhớ đệm, các phần chưa được thay đổi, v.v.), nhưng đó không phải là một thực tiễn tốt.

— tfrederick74656
nguồn

Tôi gần như chắc chắn các ảnh chụp nhanh sử dụng bảng "khối nào trong tệp nào". Vì vậy, đọc một khối duy nhất sẽ chỉ dẫn đến một khối đọc từ tệp thích hợp. Tất nhiên, việc đọc một số khối có thể dẫn đến việc truy cập vào một số tệp, điều đó có nghĩa là bị phạt khi di chuyển đầu đĩa nếu bạn không chạy từ SSD, nhưng tổng số lượt truy cập khối đĩa không nên thay đổi.

— Guntram Blohm hỗ trợ Monica

Theo cách tôi hiểu, ảnh chụp nhanh chỉ lưu trữ các thay đổi từ đĩa gốc. Nếu bạn lưu trữ tệp A, sau đó chụp ảnh nhanh, sau đó thay đổi tệp A một lần nữa, chỉ những thay đổi đối với tệp đó được ghi vào ảnh chụp nhanh. Vì vậy, bạn cần đọc cả VMDK gốc và ảnh chụp nhanh để có được toàn bộ tệp. Mặt khác, mỗi ảnh chụp nhanh chỉ đơn giản là một bản sao đầy đủ của đĩa gốc mà chúng không có.

— tfrederick74656

điều đó có thể đúng, nhưng tổng số khối bạn cần đọc vẫn giữ nguyên (ví dụ 10 khối từ ảnh chụp nhanh và 100 từ đĩa cơ sở). Đầu tiên ESXi kiểm tra các ảnh chụp nhanh hiện có cho các khối cần thiết cho đến khi nó kết thúc tại ảnh chụp nhanh chính xác (hoặc đĩa cơ sở). Có thể có một hình phạt nhỏ vì hệ thống có thể sẽ bỏ qua phần chụp nhanh đó hoàn toàn khi không có ảnh chụp nhanh. Ngoài ra, một tệp ảnh chụp nhanh đang chạy có thể sẽ bị phân mảnh nghiêm trọng.

— Dirk Trilsbeek

Một hệ thống chụp nhanh đĩa ảo mà N đọc cho N snapshot sẽ là triển khai rất ngu ngốc. Tôi nghi ngờ đó là cách nó được thực hiện trong VMWare. Một tối ưu hóa đơn giản có thể được thực hiện bằng cách chỉ cần tạo một tệp chỉ mục lưu trữ trong đó đĩa chứa từng khối của ổ đĩa được mô phỏng. Giả sử bạn có một đĩa ảo 512GB với kích thước khối là 4kB, bạn chỉ cần một chỉ số 64 MB để xác định trong thời gian không đổi, trong đó có tới 16 tệp đĩa ảo chứa một khối.

— Nói dối Ryan

Dựa trên các câu trả lời trong serverfault.com/questions/430138 tôi phải không đồng ý. Tôi đã luôn nghĩ về ảnh chụp nhanh là kết quả của số học nhị phân, không chỉ là một bộ sưu tập dữ liệu mới. Vì vậy, nếu bạn có các bit 01010101 trong VMDK cơ sở của mình, bạn đã chụp nhanh, sau đó thay đổi các bit đó thành 10101010, delta của bạn sẽ chứa 11111111 (chỉ ra rằng mọi bit trong tệp gốc đã thay đổi, KHÔNG phải giá trị mới của 10101010). Theo như tôi đồng ý với nhận xét trên, VMDK được cho là các tệp thô. Chỉ mục sẽ được lưu trữ ở đâu? Tôi chưa bao giờ thấy điều này được đề cập trong bất kỳ quán rượu công nghệ VMWare nào.

— tfrederick74656

Ảnh chụp nhanh VMware ESX có nghĩa là để sử dụng ngắn hạn.

Sử dụng lâu và IO nặng có thể gây ra đóng băng VM. Nếu bạn gặp trường hợp khi viết IO lớn hơn / nhanh hơn so với hợp nhất ảnh chụp nhanh, ESX sẽ đóng băng VM để bảo vệ dữ liệu. Với các ảnh chụp nhanh thời gian bị phân mảnh và ESX thực hiện hợp nhất nội bộ, bạn có thể trải nghiệm đóng băng định kỳ.

Bạn có thể thực hiện VM templating thủ công thông qua ssh. Sao chép thư mục VM chứa vmdk, vmx, v.v. vào một thư mục mới. Trong tệp vmx của VM mới được sao chép, thay đổi địa chỉ UID và MAC.

VMware có sản phẩm, Linked Clone, đó là điều tương tự bạn đang cố gắng thực hiện. Và họ nói rằng nó có vấn đề hiệu suất tiềm năng. Trong thực tế, bạn sẽ làm lại máy ảo sau một thời gian. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

— dario
nguồn