Nie da się ukryć, że wirtualizacja serwerów jest bardzo udaną technologią, która zmieniła sposób wdrażania systemów IT w centrach danych. Dzięki wirtualizacji to, co w przeszłości zajmowało tygodnie lub miesiące, teraz można zrobić w przeciągu kilku godzin, a nawet minut.
Wdrożenie wirtualizacji ma też swoje konsekwencje, a mianowicie wymaga zastosowania wydajnej sieciowej pamięci masowej o dużej pojemności. Następstwem tego jest wzrost złożoności zarządzania sieciowymi pamięciami masowymi dla wirtualizacji.
Dlaczego obecnie mamy tak duże zapotrzebowanie na pamięci masowe? Co jest przyczyną tego, że tak dużo organizacji ma problem z prawidłowym doborem i konfiguracją pamięci masowych dla środowisk wirtualnych?
Udostępnianie przestrzeni dyskowej dla wirtualnych serwerów
Przestrzeń dyskowa dla serwerów wirtualnych może być udostępniona na poziomie bloków przy pomocy technologii Fibre Channel lub iSCSI, albo na poziomie plików wykorzystując protokoły SMB lub NFS.
W przypadku udostępniania na poziomie bloków, przestrzeń dyskowa prezentowana jako LUN. Przykładowo LUN na platformie VMware vSphere widoczny jest jako datastore, który jest sformatowany przez system plików VMFS. W przypadku rozwiązania Microsoft Hyper-V LUN po sformatowaniu jest widoczny jako dysk. W obu przypadkach na tym samym dysku lub datastore przechowuje się wiele maszyn wirtualnych, przy czym należy pamiętać, że zarówno pojemność datastore jak i dysku może być skalowalna do obsługi kilku terabajtów.
Jeżeli chodzi o udostępniania przestrzeni dyskowej na poziomie plików to w przypadku, VMware vSphere wspierany jest tylko protokół NFS, a w przypadku Hyper-V preferowany jest SMB.
Większość problemów jakie spotykamy w środowisku wirtualnym z pamięciami masowymi jest konsekwencją złej konfiguracji udostępnionej przestrzeni dyskowej. Poniżej lista głównych powodów, które generują problemy:
Fragmentacja
Wszystkie maszyny wirtualne w obrębie tego samego datastore otrzymują ten sam poziom wydajności oraz ten sam poziom odporności na ewentualne awarie macierzy dyskowej. Ponieważ ten efekt nie zawsze jest pożądany, dlatego zaleca się utworzenie kilku niezależnych datastore, każdy posiadający inną charakterystykę wydajności. Przykładowo najwydajniejszy datastore, może być dedykowany dla maszyn produkcyjnych, kolejny mniej wydajny dla systemów testowych, a następny do przechowywania backupów.
LUN
Jak już prędzej pisaliśmy LUN udostępnia przestrzeń dyskową pamięci masowej na poziomie bloków. Jeden datastore może składać się z jednego lub kilku LUN-ów. LUN jest najmniejszą jednostką składową dla funkcji bezpieczeństwa oferowanych przez systemy do wirtualizacji tj. replikacja czy failover (przełączanie awaryjne). W rezultacie, jeżeli wykorzystujemy już narzędzia do zabezpieczenia danych dostarczane przez pamięć masową, to warto się zastanowić, czy dana maszyna wirtualna jest na tyle ważna, aby dla LUN-a, na którym się znajduje, dodatkowo uruchamiać funkcje bezpieczeństwa dostarczane przez VMware czy Hyper-V. Jednocześnie warto pamiętać, że dobrą praktyką jest gdy jeden LUN odpowiada jednemu datastore, gdyż znacznie zmniejszy to problem z fragmentacją.
Alokacja przestrzeni dla maszyny wirtualnej
Przestrzeń dyskowa dla maszyny wirtualnej może być przydzielana na dwa sposoby, może być alokowana z góry, w momencie utworzenia maszyny wirtualnej lub dynamicznie po tym jak utworzyliśmy maszynę wirtualną. Alokacja całej przestrzeni w momencie utworzenia maszyny wirtualnej potencjalnie zapewnia lepsze osiągi, wynika to z tego, że hypervisor nie musi przechodzić przez proces przetwarzania zapytań o rezerwację bloków danych wysyłanych przez maszyny wirtualna, które w sposób dynamiczny chcą alokować przestrzeń dyskową. Jednakże, w wielu przypadkach, maszyny wirtualne są tworzone z szablonów, które mają skonfigurowane tzw. startową wielkość woluminów odpowiednią dla wszystkich zainstalowanych aplikacji. Niestety nigdy nie wiemy, czy przydzielona przestrzeń zostanie w pełni wykorzystana przez daną maszynę wirtualną i dlatego nieuchronnie prowadzi to do marnowania dostępnej przestrzeni dyskowej.
Wady thin provisioning
Thin provisioning to funkcjonalność dostępna zarówno z poziomu macierzy dyskowej jak i oprogramowania do wirtualizacji, jej zadaniem jest dynamiczna alokacja przestrzeni dyskowej w momencie, gdy jest takie zapotrzebowanie. Cały czas trwają dyskusje, czy thin provisioning powinien być uruchomiony jednocześnie na obu poziomach tj. sprzętowym (macierz dyskowa) i programowym (hypervisor), czy też nie. Naszym zdaniem jest to dopuszczalne, ale należy pamiętać, że z czasem datastore, na którym uruchomiliśmy thin provisioning zostaną przekształcone w ekwiwalent thick provisioning do momentu, aż nie zostanie uruchomiony proces odzyskiwania wolnego miejsca.
VM sprawl
Kolejnym problemem w środowiskach wirtualnych z dużą ilością pamięci jest VM sprawl lub rozprzestrzenianie maszyn wirtualnych, które są wykorzystywane rzadko lub wcale. Wirtualizacja pozwala na szybkie wdrożenie aplikacji produkcyjnej lub testowej, ale taka łatwość tworzenia nowych maszyn wirtualnych często wymyka się z pod kontroli. W przyszłości może to spowodować tworzenie tzw. osieroconych maszyn wirtualnych, które nie są podłączone do inwentarzu hypervisora i istnieją tylko na dysku.
VM sprawl pokazuje, że musimy mieć odpowiednie narzędzia, które przyporządkują dane na dyskach do maszyn wirtualnych skonfigurowanych przez oprogramowanie do wirtualizacji. W dużych środowiskach, bardzo często zdarza się, że maszyna wirtualna została skasowana z panelu zarządzającego hypervisora, bez usunięcia danych z dysku – często jest to robione celowo. Jeżeli te maszyny nie zostaną usunięte lub ponownie podłączone do oprogramowania zarządzającego maszynami wirtualnymi to istnieje duże prawdopodobieństwo, że kiedykolwiek te dane zostaną skasowane.
Macierz dyskowa – Efektywne zarządzanie w środowisku wirtualnym
Jak radzić sobie z powyżej opisanymi problemami?
Poniżej kilka przykładów do rozważenia:
Zaimplementuj dobrą politykę thin-provisioning
Jeżeli masz taką możliwość to wszystkie wirtualne maszyny powinny być alokowane na pamięci masowej z włączoną funkcją thin-provisioning. Jednak skuteczna strategia thin-provisioning oznacza więcej niż tylko skonfigurowanie tej funkcji na poziomie VM i pamięci masowej.
Thin provisioning musi być także uruchomiony na poziomie VM i hypervisora. Wszystko po to, aby zwrócić niewykorzystywane dane do macierzy dyskowej.
Na poziomie maszyny wirtualnej wykorzystuje się narzędzie SDelete, jego zadaniem jest zapisywanie zer binarnych w wolne miejsce systemu plików maszyny wirtualnej. Na poziomie hypervisora VMware uruchamia się funkcję VAAI Thin Provisioning Block Space Reclamation (znaną jako Unmap), która umożliwia administratorowi zwolnienie miejsca na dyskach wykorzystując komendę vmkfstools. Niestety nie ma kompromisu co do częstotliwości wykonywania tych komend w stosunku do częstotliwości odzyskiwania ich na poziomie macierzy dyskowej, dlatego też w każdym środowisku będzie to wyglądało inaczej.
Datastore bazujące na plikowym udostępnieniu przestrzeni są zazwyczaj bardziej skuteczne w oddawaniu wolnego miejsca do macierzy. W momencie, gdy usuwane są całe wirtualne maszyny lub dane w obrębie danej maszyny wirtualnej, to automatycznie zwolnione jest miejsce, które od razu jest gotowe do wykorzystania do innych celów. To jest jedna z zalet datastore bazującego na plikowym udostępnieniu przestrzeni dyskowej, w stosunku do blokowego udostępniania.
Wykorzystuj funkcje, które natywnie są obsługiwane przez macierz dyskową
Wiele macierzy dyskowych obsługuje funkcję „zero block reclaim”, która umożliwia bezpośrednio z poziomu macierzy odzyskiwać wyzerowane bloki danych. Macierze dyskowe firmy QNAP potrafią wykonywać ten proces w locie w czasie rzeczywistym, podczas gdy macierze innych producentów potrafią to zrobić tylko zgodnie z ustalonym przez administratora harmonogramem.
Datastore w systemie VMware może być formatowany przy pomocy format eager-zeroed, który w momencie tworzenia wirtualnej maszyny zapisuje jej przestrzeń dyskową zerami. Macierz dyskowa natychmiast ignoruje bloki zapisane zerami i nie żąda zwrotu nieużywanych bloków, co umożliwia skonfigurowanie fault tolerance, lub daje możliwość alokowania w momencie tworzenia VM większej przestrzeni dyskowej niż aktualnie jest ona potrzebna. Platforma Hyper-V posiada kilka problemów związanych z prawidłowym działaniem thin provisioning, ale ogólne zasady, tj. SDelete działają tam bez problemu.
Dobrą praktyką jest zakup macierzy, która posiadają oficjalne certyfikaty VAAI od VMWare lub ODX od Hyper-V, tak jak to jest w przypadku macierzy QNAP. Korzystając z takiej macierzy w środowisku wirtualnym będziemy mieli zdecydowanie mniej problemów z wydajnością i zarządzaniem naszym środowiskiem wirtualnym.
Używaj najnowszej wersji systemu plików
W przypadku platformy VMware vSphere system plików VMFS, który bazuje na blokowym udostępnianiu przestrzeni cały czas jest udoskonalany, dlatego co chwilę wydawane są nowe wersje vSphere. Wiele organizacji wgrywają nową wersję vSphere, ale zapominają o zaznaczeniu opcji re-formatowania datastore, sprawia to, że mimo iż będziemy korzystać z nowego vSphera to i tak system plików VMFS będzie w starszej wersji. Ta praktyka może prowadzić do nieefektywności w porównaniu z wykorzystaniem najnowszych formatów VMFS. W naszych polskich realiach, często związane jest to z tym, że nie każda firma, ma wykupiony najwyższy pakiet VMware, który znacznie upraszcza migrację system plików podczas pracy. Jednak organizacje, które mają VMware z opcją vMotion, oraz thin provisioning powinny zmieniać system plików VMFS na nowszy, przy każdej aktualizacji vSphere.
Zarządzanie VM sprawl
Wydaj się to być oczywiste, ale okazuje się, że nie dla każdego. Dobrą praktyką jest wdrożenie polityki, która automatycznie przeniesie maszynę wirtualną, która nie była używana przez minimum trzy miesiące na macierz dyskową zbudowaną z tanich dysków SATA. W środowisku testowym dobrą praktyką jest archiwizowanie testowych maszyn wirtualnych po zakończonych testach, aż do momentu kiedy pojawi się nowa wersja aplikacji, którą musimy przetestować.
Oprogramowanie do backupu CommVault Simpana umożliwia przeniesienie maszyn wirtualnych na wolniejsze dyski, jednocześnie nie tracąc powiązania z hypervisorem, dzięki czemu przeniesione maszyny wirtualne nadal znajdują się w wykazie hypervisora.
Dobrą praktyką, jest zaopatrzenie się w macierz dyskową, która posiada certyfikat kompatybilności z oprogramowaniem CommVault tak jak jest to w przypadku macierzy dyskowych firmy Qnap.
Wdrożenie skutecznych narzędzi
Istnieją narzędzia, które mogą zidentyfikować i zlokalizować osierocone maszyny wirtualne. Alternatywnie, proces ten można osiągnąć za pomocą skryptów, które dopasują spis hypervisora do listy plików maszyn wirtualnych na macierzy dyskowej. Regularne wykonywanie tego procesu umożliwi szybkie wychwycenie osieroconych maszyn wirtualnych, co umożliwi ponowne podłączenie jej do hypervisora lub po prostu skasowanie w celu odzyskania miejsca na dyskach.
Podsumowując warto spędzić trochę czasu na zrozumieniu procesów, które mają miejsce w środowisku wirtualnym. Dzięki temu zarządzanie pamięciami masowymi i ich konfiguracją pod kontem pracy w środowisku wirtualnym będzie prostsze. Dodatkowym atutem będzie, gdy zaopatrzymy się w macierze firmy QNAP, które zostały zaprojektowane do pracy w środowiskach wirtualnych. Warto wspomnieć, że w cenie tych macierzy otrzymuje się darmowe wsparcie techniczne w języku polskim, więc nawet jeżeli okaże się, że ten artykuł nie był pomocny, to zawsze można skorzystać z pomocy specjalistów firmy QNAP.