Czy stałe działanie w migawce VMWare ma zły wpływ na wydajność?

Rozumiem, że KB VMWare marszczy brwi po długotrwałych migawkach, głównie z powodu dwóch rzeczy (moim zdaniem)

Wykonywanie mnóstwa migawek może zapełnić magazyn danych. Migawki to po prostu pliki delta. Załóżmy, że masz 50 Gig VMDK, prawie pełny, i robisz migawkę. W migawce odwracasz każdy bit. Twój plik delta będzie miał około 50 GB. Zrób migawkę, odwróć bity, kolejny plik delta 50 Gig. Mogą szybko wymknąć się spod kontroli.
Przeprowadzanie dużych migawek niesie ze sobą ryzyko. Podczas konsolidacji migawek zapisujesz zmiany delty w oryginalnym VMDK. To wymaga czasu i niesie ryzyko, że jeśli coś się stanie, właśnie nuknąłeś swój VMDK.

Ich ostrzeżenia wydają się mieć logiczny sens.

Biorąc to pod uwagę, czy z natury źle jest uruchomić moją maszynę na stałe z migawki VMDK? Chcę, aby moje drzewo było następujące:

Baza
- Snap1
  - Snap 2
  - Jesteś tutaj

Snap 1 i 2 zostaną pobrane natychmiast po zainstalowaniu i udostępnieniu systemu podstawowego. Są to maszyny, które planuję często odświeżać, dzięki czemu moje drzewo będzie wyglądać następująco:

Baza
- Snap1
  - Jesteś tutaj
  - Snap 2

Usuń Snap2 i ponownie utwórz Snap2.

Nie widzę, jak mogłoby to mieć jakiekolwiek implikacje z następujących powodów:

Ponieważ po prostu zainstalowałem obraz podstawowy i zabrałem swoje delty natychmiast po tym, jak nie ma możliwości, żebym mógł zapełnić magazyn danych. Zakładając, że mój podstawowy obraz ma tylko 10 GB (na dysku o pojemności 50 GB), nawet jeśli moja delta przerzuciła każdy bit, maksymalne moje całkowite użycie może wynosić 60 GB (10 GB podstawowego VMDK, który jest zablokowany + 50 GB delta w plik VMDK migawki). Zakłada się, że nie tworzę żadnych dalszych migawek.
Ponieważ mój przypadek użycia nie wymaga konsolidacji migawek, nie ryzykuję błędów podczas konsolidacji moich delt. Kiedy wracam do Snap1 i usuwam Snap2, cała delta, która znajdowała się w Snap2, po prostu zostaje usunięta.
Obciążenie pamięci jest dokładnie takie samo, więc powinienem dostawać takie same IOPS. Rozumiem, że niektóre pliki (głównie pliki systemowe) będą istniały na oryginalnym VMDK, a inne (wszystko po bazie) będą znajdować się w delcie, ale nie rozumiem, jak ESXI by to obchodziło. Wszystkie pliki znajdują się w tym samym fizycznym magazynie danych, więc wydajność powinna odpowiadać odwoływaniu się do wszystkiego w oryginalnym VMDK bez migawek.

jakieś pomysły? ESXI 5.5 z magazynem danych RAID'd DAS.

Nie mam licencji vCenter, więc szablony i klonowanie nie są dostępne.

WYNIKI TESTU

Przyszedłem dziś wcześnie, by przeprowadzić testy. Oto wyniki. Występuje kara wydajnościowa, ale nie jestem pewien, dlaczego.

Przed migawką:

Po wykonaniu migawki: Po shapshotowaniu

— VM_Storage_Inception
źródło

Nie jestem pewien - z biegiem czasu migawki będą się coraz bardziej różnić. Wreszcie będą to zasadniczo różne kopie. Po tym, jak nie oszczędzasz dużo dysku, wykonując migawkę, przekonwertuj migawkę na całkowicie oddzielny wolumin. W jaki sposób? Zwykle używam dd z trzeciej maszyny wirtualnej, ale przeważnie jestem tu prawie ukrzyżowany za takie heretyckie opinie, jak to. :-) Ale: zadziała i będzie skuteczny .

— peterh - Przywróć Monikę

@PeterHorvath - to rzeczy, które uwielbiam słyszeć. Inteligentne, zuchwałe, skuteczne rozwiązania bez systemu operacyjnego. Jeśli nie masz nic przeciwko, możesz napisać mi o tym, co robisz w pastebin czy coś takiego? Czy dodajesz VMDK i migawkę razem?

— VM_Storage_Inception

Gdybym musiał to robić częściej, robiłem to za pomocą skryptu. Ale tak nie jest iw większości przypadków nie używam nawet snapshptów, ponieważ są one powolne.

— peterh - Przywróć Monikę

Odpowiedzi:

Tak, długotrwałe migawki mają wpływ na wydajność. Istnieją jeszcze większe implikacje dla konsolidacji delta VMDK z powrotem do oryginalnego pliku na dysku. Może to powodować brak reakcji w systemie operacyjnym maszyny wirtualnej lub inne niepożądane zachowanie.

VMware ma wbudowane funkcje szablonów i klonowania w vCenter. Aby to umożliwić, potrzebujesz licencji vSphere Essentials na 600 USD.

Możesz utworzyć maszynę wirtualną według własnego gustu, a następnie sklonować ją do szablonu. Tego szablonu można następnie użyć do wygenerowania nowych maszyn wirtualnych z obrazu „Golden Master”.

wprowadź opis zdjęcia tutaj

Pozwala to na uzyskanie „czystego stanu”, ale także tworzenie długotrwałych lub stałych maszyn wirtualnych z tego obrazu głównego. Nie są potrzebne migawki.

— ewwhite
źródło

Interesujące, przyjrzę się temu i zobaczę, jak to działa. Niestety nie mam licencji vCenter i wolałbym, aby moja organizacja nie wydała 600 $, jeśli nie ma to wpływu na wydajność migawek używanych w opisany przeze mnie sposób. Także tworzenie szablonów i klonowanie nie różni się niczym od wzięcia OVA i ponownego jej wdrożenia. Usuwanie migawek wydaje się dużo szybsze i logicznie nie widzę konsekwencji dla wydajności, nawet jeśli nie jest to „oficjalna metoda zatwierdzona przez VMWare”.

— VM_Storage_Inception

Aby odpowiedzieć na Twoją edycję, czy możesz wskazać mi artykuł lub wyjaśnić, jakie będą konsekwencje dla wydajności? Nie rozumiem, jak można by założyć, że użyję ich tak, jak to opisuję. Nigdy też nie konsolidowałbym migawek z powrotem do oryginalnego VMDK.

— VM_Storage_Inception

Chyba próbuję zrozumieć, dlaczego nalegasz na zaprojektowanie funkcji, która ma być używana do krótkotrwałego dostępu.

— ewwhite

@VM_Storage_Inception - brzmi prawie tak, jakbyś chciał podejść biednego człowieka do nieistniejącego produktu VMWare Lab Manager.

— TheCleaner

Czasami zakup odpowiedniego rozwiązania ma sens. Poświęciłeś więcej wysiłku i roboczogodzin na zapytanie o obejście, niż tylko płacenie za licencję vSphere Essentials (600 USD), co dałoby obsługiwaną opcję szablonu / klonowania.

— ewwhite

Odpowiedź ewwhite jest poprawna, ale aby rozszerzyć nieco lub zmniejszyć wydajność, rozważ następujący scenariusz:

Tworzysz maszynę wirtualną. Wirtualny odczyt z vmdk zajmuje jeden fizyczny odczyt dysku o tym samym rozmiarze. Dość bezpośredni.

Teraz wyobraź sobie, że robisz migawkę maszyny wirtualnej. Teraz, dla każdego wirtualnego odczytu, musisz ponieść 2 fizyczne odczyty, jeden z podstawowego vmdk i jeden z delta vmdk, ponieważ potrzebujesz informacji z obu, aby uzyskać bieżący stan. Jesteś teraz dwa razy większy niż fizyczny odczyt dysku.

W przypadku dwóch migawek wykonujesz trzykrotne odczyty i tak dalej. Jeśli masz dużo migawek, możesz zobaczyć, jak może to być dość znacząca kara wydajności. Niekoniecznie przekłada się to na n-krotnie gorszą wydajność (z powodu buforowania, sekcji, które nie zostały zmienione itp.), Ale nie jest to dobra praktyka.

— tfrederick74656
źródło

Jestem prawie pewien, że migawki używają tabeli „który blok jest w którym pliku”. Tak więc odczytanie jednego bloku spowoduje odczytanie tylko jednego bloku z odpowiedniego pliku. Oczywiście odczyt kilku bloków może spowodować dostęp do kilku plików, co oznacza karę za przesunięcie głowic dysku, jeśli nie korzystasz z dysku SSD, ale całkowita liczba dostępów do bloków dysku nie powinna się zmienić.

— Guntram Blohm obsługuje Monikę

W moim rozumieniu migawki przechowują tylko zmiany z oryginalnego dysku. Jeśli przechowujesz plik A, następnie wykonaj migawkę, a następnie ponownie zmień plik A, tylko zmiany w tym pliku są zapisywane w migawce. Dlatego musisz przeczytać zarówno oryginalny VMDK, jak i migawkę, aby uzyskać cały plik. W przeciwnym razie każda migawka byłaby po prostu pełną kopią oryginalnego dysku, którą nie są.

— tfrederick74656

może to być poprawne, ale całkowita liczba bloków, które musisz odczytać, pozostaje taka sama (np. 10 bloków z migawki i 100 z dysku podstawowego). ESXi najpierw sprawdza istniejące migawki pod kątem potrzebnych bloków, dopóki nie skończy się na prawidłowej migawce (lub dysku podstawowym). Może wystąpić drobna kara, ponieważ system prawdopodobnie całkowicie pominie tę część przejścia migawki, gdy w ogóle nie ma migawki. Ponadto długo działający plik migawki prawdopodobnie ucierpi z powodu poważnej fragmentacji.

— Dirk Trilsbeek,

System wirtualnej migawki dysku, który wykonuje N odczytów dla N migawki, byłby bardzo głupią implementacją. Wątpię, jak to jest zaimplementowane w VMWare. Prostych optymalizacji można dokonać, po prostu tworząc plik indeksu, w którym przechowywany jest plik dyskowy każdego bloku emulowanego dysku. Załóżmy, że masz dysk wirtualny 512 GB o rozmiarze bloku 4 kB, potrzebujesz jedynie 64 MB indeksu, aby w stałym czasie określić, który z 16 plików dysku wirtualnego zawiera blok.

— Lie Ryan,

Na podstawie odpowiedzi na serverfault.com/questions/430138 muszę się nie zgodzić. Zawsze myślałem o migawkach jako wynikach arytmetyki binarnej, a nie tylko kolekcji nowych danych. Więc jeśli masz bity 01010101 w swoim podstawowym VMDK, robisz migawkę, a następnie zmieniasz te bity na 10101010, twoja delta zawiera 11111111 (wskazując, że każdy bit w oryginalnym pliku się zmienił, a NIE nowa wartość 10101010). O ile zgadzam się z powyższym komentarzem, VMDK są podobno nieprzetworzonymi plikami. Gdzie byłby przechowywany indeks? Nigdy nie widziałem tego w żadnym pubie technologicznym VMWare.

— tfrederick74656,

Migawki VMware ESX są przeznaczone do krótkotrwałego użytkowania.

Długie użytkowanie i ciężkie operacje we / wy mogą powodować zawieszanie się maszyn wirtualnych. Jeśli masz przypadek, gdy zapis IO jest większy / szybszy niż konsolidacja migawki, ESX zamrozi maszynę wirtualną w celu ochrony danych. Migawki czasowe ulegają fragmentacji, a ESX dokonuje wewnętrznej konsolidacji, co powoduje okresowe zawieszanie się.

Możesz wykonywać szablony VM ręcznie przez ssh. Skopiuj folder VM zawierający vmdk, vmx itp. Do nowego folderu. W pliku vmx nowo skopiowanej maszyny wirtualnej zmień UID i adres MAC.

VMware ma produkt, Linked Clone, który jest tym samym, co próbujesz zrobić. Mówią, że ma to potencjalne problemy z wydajnością. W praktyce po pewnym czasie będziesz remasterować maszyny wirtualne. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

— Dario
źródło