Porozmawiajmy o snapshotach


Witajcie!
Ten wpis kierowany jest bardziej do osób zarządzających infrastrukturą wirtualizacyjną ale może też przydać się developerom trzymającym swoje środowiska testowe w obrębie produktu VMWare. Przede wszystkim jednak ma na celu rzucić trochę światła na konsumpcje przestrzeni dyskowej “placu” przez najbardziej poręczne narzędzie backupowe jakim jest snapshot. Z tym że od razu na wstępie zaznaczę. Snapshot to nie jest backup – architektura rozwiązania nie jest idealna ani wolna od błędów stąd nie poleca się zbytnio opierać DR (disaster recovery) właśnie na tym rozwiązaniu.

Przyrost danych

Zacznijmy od rzeczy najważniejszej – czyli tego ile snapshot zajmuje miejsca.

Dysk Bazowy

Snapshot1

Najpierw słowo wyjaśnienia, później zaprezentuje na przykładzie.
W momencie w którym tworzymy snapshot VMWare tworzy nowy wirtualny dysk, na którym będą zapisywane wszystkie operacje w obrębie danej maszyny, które wydarzą się po utworzeniu snapshota. Każdy kolejny snapshot to nowy dysk, gwarantuje to, że “wcześniejsza kopia” naszej maszyny nie będzie narażona na uszkodzenie. Snapshot to tylko incremental więc proszę pamiętać, że nie może żyć własnym życiem i zawsze musi odnosić się do swojego dysku bazowego ‘baseline-u’.
Pora na przykłady
Weźmy sobie maszynę z dyskiem typu thick (gruby dysk, który alokuje całą przestrzeń od razu po utworzeniu maszyny). Jak widać poniżej mamy tylko baseline 100GB i swap, który utworzył się w trakcie działania maszyny 8GB.

VMWare snapshot

Teraz utwórzmy snapshot

VMWare snapshot

Jak widać sam snapshot nie zajmuje wiele. W końcu zawiera tylko informację gdzie ma się odwołać i że od tej pory to on jest podstawowym dyskiem naszej maszyny.

Naróbmy hałasu

Na maszynę wrzucę teraz pliki o wielkości ~10GB
Dochodzimy do pierwszej sytuacji stykowej, którą będziemy rozwijać. Tak jak mówiłem wcześniej maszyna miała przydzielone 100 GB placu. Podczas wrzucania plików maszyna doszła do swojego limitu po ~6 GB

VMWare snapshot error

Nie będziemy tego korygować, lećmy z naszą analizą dalej.

4

Jak widać na powyższym obrazku nasza maszyna na datastore zajmuje już nie 100 a 106GB – czyli proporcjonalnie więcej do rozmiaru wrzuconych plików. Pomimo tego, że Windows zablokował całą operacje kiedy doszedł do limitu baseline-u.
Teraz nadszedł czas na konsolidacje i usunięcie naszego snapshotu

5

Jak widać baseline wchłonął snapshot i maszyna znowu zajmuje 100GB. Jednak aby maszyna była w stanie wykonać konsolidację potrzebuje dodatkowej przestrzeni, w której bez usuwania starych snapów będzie mogła stworzyć nowy snapshot zawierający wszystkie migawki (snapshoty) przypisane do maszyny, następnie dopiero wstrzyknąć je do baseline-u.

Dlaczego taka sytuacja jest niebezpieczna?

Wyobraź sobie, że twój serwer jest prężnie działającą bazą danych na którą co chwilę trafia mnóstwo nowych danych lub akurat przygotowujesz dane pod analizę i za pomocą web scrapera lub api tworzysz bazę, która będzie rosła nawet do 1TB podczas gdy ty będziesz spał. Administrator stwierdził, że żeby maszyna była bardziej wydajna da jej thick volumen o pojemności 4TB tak żeby miejsce na pewno się nie skończyło. Po instalacji i konfiguracji tworzy snapshota, żeby testy nie uszkodziły bazy ani OSa lub ma w weekend do przeprowadzenia upgrade więc tworzy sobie dla bezpieczeństwa snapshot aby szybko się cofnąć jeśli coś pójdzie nie tak. Od poniedziałku startuje produkcja, nagle po 2 dniach użytkownicy zaczynają dzwonić, że nie mogą zalogować się na swoje firmowe konto. Próbujesz dostać się na vCenter ale nie ma szans. Twój kontroler domeny już leży. VMWare zamroził wszystkie procesy swoich maszyn wirtualnych bo twoje thin volumeny nie mają już gdzie rosnąć.

Oczywiście aby uniknąć błędów wynikających z przepełnionego storage wystarczy dobrze zaprojektować system i być świadomym takich sytuacji. Aby skutecznie ograniczyć zbyt duży rozrost można też zastosować Thin Volumen

Baseline

Snapshot

Thin Volumen

Dla potwierdzenia powyższej tezy weźmy pod lupę volumen cienki. Thin volumen w przeciwieństwie do Thicka zabiera tyle miejsca ze storage ile faktycznie zajmują pliki na nim zlokalizowane. System oczywiście widzi całość przyznanego mu miejsca.

thin_5

Podczas gdy na storage

Snapshot_thin_vmware

Więc lecimy z taką samą procedurą. Najpierw tworzymy snapa.

Snapshot_thin_vmware

Wrzucamy pliki, dla porządku te same ~6GB

Snapshot_thin_vmware

Widać, że snapshot nam przyrasta jednak Thin volumen stoi w miejscu. Konsolidujemy i usuwamy snapshot.

Snapshot_thin_vmware

Baseline wchłonął snapshot i zwiększył swój rozmiar, co prawda o mniej niż 6GB ale to za sprawą deduplikacji.

Baseline

Snapshot

Jak widać Thin volumen jest więc bezpieczniejszą opcją. Bardziej dla zapominalskich. Problem zaczyna się jednak kiedy stwierdzimy, że na macierzy jest jeszcze dużo wolnego miejsca więc dorzucimy tam jeszcze parę maszyn. Te zaczynają rosnąć, system twierdzi, że ma jeszcze miejsce ale niestety datastore jest już przepełniony bo inna maszyna zabrała plac naszej wirtualce.

Podsumowanie

Jak widać należy uważnie planować swój system pod kątem przestrzeni dyskowej. Należy również pamiętać, że snapshoty nie są robione tylko ręcznie. Wszystkie wiodące software backupowe używają snapshotów jako podstawy do robienia swoich backupów. Zła konfiguracja oprogramowania do backupu też potrafi namieszać z naszym placem.

Do tego wszystkiego należy pamiętać, że istnieją jeszcze “snapshoty macierzowe” co dodatkowo potrafi obciążyć dyski ale to już temat na kolejny wpis.