Wdrażając wirtualizacje każda organizacja musi podjąć szereg kluczowych decyzji, które będą następnie afektowały skalowalność, wydajności i bezpieczeństwo wprowadzonego rozwiązania. Pośród tych decyzji jedną z najistotniejszych jest architektura zastosowanego storage-u. Jeżeli wybierając sposób przechowywania danych popełnimy nawet małe błędy może się okazać, że nie osiągniemy celów i zysków założonych we wdrażanym projekcie.
Wirtualizacji jest obecnie na tyle powszechnym rozwiązaniem, iż praktycznie każda osoba związana w dowolny sposób z IT przynajmniej oględnie kojarzy ten termin i ogólnie wie z czym jest powiązany. Znaczna część firm choć obecnie (około 8-10 lat istnienia powszechnych technologii wirtualizacyjnych) jeszcze nie większość, całkowicie lub częściowo wirtualizację wdrożyła. Dodatkowo, coraz więcej organizacji napotykając problem rosnących kosztów implementacji i utrzymania środowisk informatycznych przy jednoczesnym znaczącym wzroście ich krytyczności poważnie zaczyna myśleć o jej implementacji jako remedium przynajmniej na część powstałych problemów i potrzeb.
Niestety, środowiska wirtualne (dowolnego producenta) ze względu na swoją szczególną koncepcję działania są bardzo podatne na błędy projektowe. Mam tu na myśli fakt, iż jeżeli na etapie projektowania infrastruktury wirtualnej nie podejmiemy pewnych założeń, nie przygotujemy niektórych rozwiązań czy też co gorsza przygotujemy je źle, funkcjonowanie naszej infrastruktury może znacząco odbiegać od oczekiwań i zamiast rozwiązywać istniejące problemy, przysparzać nowych.
Kluczowe aspekty
Takimi kluczowymi miejscami są np. zastosowana architektura sieciowa i jej konfiguracja oraz co w wielu przypadkach ważniejsze (znacznie bardziej odczuwalne) zastosowany typ storage-u oraz jego wydajność konfiguracja.
Obecnie produkowane serwery są niezwykle wydajne a ich ceny spadają z dnia na dzień (między innymi dlatego tak bardzo rozwinęła się wirtualizacji). Zastosowane w serwera podzespoły ich parametry (przyjmując oczywiście jakieś rozsądne minimum) nie mają tak istotnego wpływu na funkcjonowanie naszych maszyn wirtualnych oraz samej infrastruktury. Większość bowiem dostępnych obecnie procesorów nadaje się do wirtualizacji, pamięci RAM można w miarę potrzeb oddawać a w przypadku osiągnięcia pojemności (liczby maszyn) jednego serwera można dodać kolejny.
W klasycznej architekturze fizycznej dyski twarde dostępne w serwerze fizycznym były przeznaczone pod jeden system operacyjny i usługi na nim uruchomione (wykorzystywane zewnętrze macierze dyskowe ale dotyczyło to raczej dużych systemów lub takich o dużym zapotrzebowaniu na pojemność danych). W związku z tym ich wydajność w większości sytuacji była wystarczająca. W przypadku wirtualizacji sprawa wygląda zgoła odmiennie. Umieszczone na serwerze maszyny wirtualne są przechowywane na jakiś dyskach twardych i stale konkurują od zasoby tzn. stale (tym więcej im bardziej są obciążone) dokonują operacji odczytu i zapisu danych z dysków na których są przechowywane. Na wspólnej grupie dysków mamy więc w przypadku wirtualizacji wiele konkurujących ze sobą serwerów logicznych. Brak szybkiego wykonania operacji zapisu czy odczytu przez któryś z serwerów logicznych skutkuje w takiej sytuacji znaczącym obniżeniem szybkości jego funkcjonowania (nawet w sytuacji dużej dostępności pozostałych zasobów tj. CPU czy RAM-u). Dlatego właśnie storege jest w kontekście wirtualizacji tak niezwykle istotny.
Operacje input/output
Kluczowym jest tu nie tyle sama prędkość transmisji danych między dyskiem a serwerem (choć przy dużych instalacjach też jest istotna) lecz właśnie czas potrzebny na dokonanie operacji zapisu lub odczytu danych. Czas taki mierzony jest w milisekundach a operacje zapisu i odczytu są powszechnie znanym parametrem opisywanych jako IO (input/output). Parametr ten jest pochodną wielu czynników lecz jedną z najważniejszych jego determinant jest prędkość obrotowa talerzy wykorzystywanych dysków twardych. Zależność tak wynika czysto z mechaniki działania dysku twardego, który za pomocą specjalnej głowicy zapisuje/odczytuje dane na obracających się talerzach magnetycznych. Im większa prędkość obrotu talerzy tym szybciej głowica może przejść z jednego punktu talerza do innego a tym samym wykonać więcej operacji zapisu i odczytu w jednostce czasu (posiada tym samym wyższy parametr I/O). Oczywiście wartość I/O nie zależy tylko od tego ale dla uproszczenia można przyjąć że tak jest.
Rodzaje dysków
Na rynku mamy dostępne obecnie dyski klasy Enterprise o prędkościach obrotowych 7200, 10k, 15k. W ramach dysków 7200 mamy zarówno takie z interfejsem SATA jak i SAS (to też te o najwyższych pojemnościach do 4 TB) natomiast dyski 10k i 15k są już tylko dyskami z interfejsem SAS. Mamy również dyski SSD (lecz jak dotąd mają one małe powierzchnie i krótką żywotność). Z punktu widzenia I/O najlepsze są dyski SAS 15k, lecz niestety posiadają one najniższe pojemności (600GB) i znaczną cenę.
Multiplikacja I/O
W przypadku wirtualizacji pojedynczy dysk prawie w żądnym środowisku produkcyjnym nie będzie posiadał wystarczającej wydajności. Dlatego też aby zwiększyć dostępne I/O powierzchnie stosuje się łączenie dysków w grupy z wykorzystaniem RAID. W ramach grupy RAID uzyskujemy w zależności od rodzaju grupy (typu RAID) ilość I/O będącą max. prawie sumą I/O wszystkich dysków (RAID 0) lub jej ułamkiem (inne grupy RAID np. 5 czy 6).
RAID a bezpieczeństwo
Wykorzystanie RAID oprócz zwiększenia wydajności, dodatkowo pozwala częściowo poradzić sobie z innym palącym problemem związanym ze stora gem dal wirtualizacji tj. bezpieczeństwem danych. W przypadku pojedynczego nie zwirtualizowanego serwera awaria jego dysku (całkowita) nawet powodująca utratę danych powoduje w najgorszym razie niedostępność (do czasu przywrócenia z kopii zapasowej) jednego systemu. W przypadku natomiast wirtualizacji gdzie wiele maszyn logicznych (a tym samym wiele systemów merytorycznych) przechowywane jest na wspólnej przestrzeni dyskowej awaria dysku powoduje niedostępność wszystkich maszyn na nim przechowywanych. Dlatego więc wykorzystując grupy dysków połączone w macierz RAID musimy znaleźć taki jego tryb alby pogodzić zarówno wymogi wydajnościowe jak i niezbędne standardy bezpieczeństwa.
Tryby RAID
Najpopularniejszymi trybami RAID są obecnie:
RAID 0 – tzw. Stripe składa się z min 2 dysków gdzie dane rozrzucone są podczas zapisu na “n” dysków fizycznych. W taki sposób otrzymujemy prawie n-krotną szybkość zapisu i odczytu. Rawa ID 0 jest zdecydowanie najlepszym rozwiązaniem w kontekście wydajności niestety nie zapewnia żadnych mechanizmów bezpieczeństwa, awaria pojedynczego dysku powoduje niedostępność grupy i utratę danych.
RAID 1 – tzw. Mirror składa się z dwóch dysków gdzie dane podczas zapisu są duplikowane na oba dyski. Daje bardzo wysokie bezpieczeństwo gdyż awaria jednego dysku nie powoduje niedostępności i utraty danych jednocześnie nie daje żadnego wzrostu wydajności przy zapisie i istotny wzrost przy odczytach (odczyt z dwóch dysków jednocześnie).
RAID 5 - składa się z minimum trzech dysków. Za pomocą specjalnego algorytmu z danych na dyskach tworzone są bity parzystości i zapisywane są na ww. dyskach. W Przypadku awarii jednego z dysków ze stworzonych bitów parzystości można odzyskać dane. RAID 5 daje wzrost wydajności na poziome części sumy I/O wszystkich dysków w grupie.
RAID 6 – jest tym samym czym RAID 5 z tym że bity parzystości zapisywane są na osobnych wydzielonych dyskach. Dlatego RAID 6 wymaga min 4 dysków a wzrost wydajności jest analogiczny jak w przypadku RAID 5 czyli równy ułamkowi sumy I/O dysków tworzących grupę (bez dysków na parzystość). RAID 6 zapewni odporności na jednoczesną awarię dwóch dysków.
RAID 10 – tzw. Stripe Mirror-ów tj. mając min. 4 dyski dzielimy ja na dwie grupy. W ramach każdej robimy mirror (co zapewnia bezpieczeństwo) a ztak zbudowanych grup robimy stripe (co zapewnia wydajność). RAID 10 jest najlepszym rozwiązaniem lecz też najdroższym gdyż marnowana (na mirror) jest połowa pojemności wszystkich dysków.
Nowoczesne macierze dyskowe oprócz łączenia dysków w grupy RAID pozwalają jeszcze (np. EMC VNX) na tworzenie puli dysków (składających się z dowolnej liczny dysków twardych) w ramach której oprogramowanie macierzy tworzy n (bazując na własnych algorytmach wykorzystujących najlepsze praktyki) grup RAID wybranego poziomu i podczas zapisu dystrybuuje dane pomiędzy istniejące grupy.
Tak stworzona pula znacząco zwiększa bezpieczeństwo danych pozwalając na awarie większej liczby dysków niż wynika to z właściwości pojedynczej grupy RAID w danym trybie, jednocześnie poprzez zwielokrotnienie liczby dysków (poza ograniczenia trybów RAID) oferuje znacznie większą liczbą dostępnych I/O (dane zapisywane i odczytywane są jednocześnie z wielu grup RAID).
Dostępne protokoły
Innym oprócz ilości dysków oraz ich szybkości bardzo istotnym aspektem wpływającym na bezpieczeństwo oraz wydajności naszej infrastruktury w zakresie storage jest zastosowany protokół dostępu.
Protokół determinował będzie przede wszystkim takie parametry jak prędkość transmisji danych pomiędzy serwerami oraz dostępne mechanizmy bezpieczeństwa. Jeśli chodzi o mechanizmy bezpieczeństwa kluczowym jest tu tzw. wielo-ścieszkowość tudzież redundancja. Wiemy już, że miejsce gdzie składowane są nasze dane jest niezmiernie istotne i problem z jego funkcjonowaniem afektuje wszystkie umieszczone na nim maszyny logiczne. Jeżeli bowiem nasze serwery fizyczne strąca komunikacje z macierzą dyskową cała infrastruktura przestanie być dostępna. Dlatego niezbędnym jest zapewnienie aby transmisja danych mogła odbywać się co najmniej dwoma niezależnymi od siebie drogami. Realizujemy to różnie w zależności od wybranego protokołu transmisji.
Jeśli chodzi o same protokoły to mamy do wyboru:
Fiber Channel – specjalny protokół realizujący transmisje w oparciu o osobne medium w tym wypadku miedziane lub optyczne i z wykorzystaniem specjalnych kart w serwerach (HBA), urządzeń pośredniczących w transmisji (przełączników FC, choć nie w każdej architekturze, więcej nt. w moim art. dot. FC w jednym z wcześniejszych numerów) oraz odpowiedniej macierzy obsługującej FC. W zależności od wykorzystanych urządzeń najczęściej mamy do wyboru prędkości transmisji 4,8,10,12 Gb/s. W zakresie zapewnienienia redundancji protokół FC wykorzystuje mechanizm zwany Multi Path I/O (MPIO). Aby wykorzystać MPIO niezbędne jest posiadanie w serwerze minimum dwóch portów FC (najlepiej dwóch niezależnych kart), każda port powinien być podłączony do niezależnego przełącznika FC. Natomiast od strony macierzy niezbędne są również minimum dwa porty, podłączone analogicznie od dwóch niezależnych przełączników. Serwer (Hypervisor) wykrywa, że dana macierz (LUN) dostępna jest dwoma ścieżkami i w zależności czy macierz pracuje w trybie Active-Passive, Active-Active czy ALUA odpowiednie albo transmituje dane obiema ścieżkami, traktuje druga jak zapasową w razie niedostępności pierwszej lub też transmituje obiema per LUN (ALUA).
iSCSI – protokół który powstał aby zastąpić FC w taki sposób, ze zamiast transmitować komendy SCSI specjalnym protokołem jak FC enkapsulowane są one w ramki Ethernet. Dostępne prędkości zależne są od wykorzystanej infrastruktury sieciowej tj. mamy 1Gb/s, 10Gb/s czy nawet 40Gb/s (lecz jest to raczej nie spotykane. Jeśli chodzi o bezpieczeństwo iSCSI podobnie jak FC wykorzystuje MPIO. Jego działanie jest analogiczne z tym że adresacja w ramach iSCSI wykorzystuje IP a nie WWN jak FC dlatego po stronie serwera konfigurujemy adresy IP portów macierzy a serwer tak samo jak w FC musi posiadać minimum dwa niezależne porty (każdy z adresem IP najlepiej w innej podsieci).
NFS – jest to stary protokół współdzielenia plików i folderów wykorzystywany natywnie w systemach operacyjnych Linux. NFS przez wiele lat funkcjonowania udowodnił swoją wydajność i stabilność. W wielu rozwiązaniach zdaje się on nawet oferować większe wydajności niż iSCSI (choć zależy to od konkretnej konfiguracji). Niestety NFS stworzony jako protokół dla serwerów plików nie posiada żadnych natywnych mechanizmów wielościeżkowości. Aby więc zapewnić redundancję w warstwie sieciowej niezbędne jest skorzystanie z zewnętrznych rozwiązań. Najczęściej, stosuje się agregację interfejsów zarówno po stronie Hypervisora jak i macierzy z wykorzystaniem LACP, łaczenia przełączników w stosy oraz mechanizmów tzw. Cross stack EtherChannel (w nomenklaturze Cisco) czy FlexFabric (w HP).
Architektura
Kolejnym ważnym aspektem przy wyborze storage-u jest architektura którą wybierzemy dla naszej infrastruktury. Najpowszechniejszym stosowanym obecne rozwiązaniem jest architektura zcentralizowana wykorzystująca centralna macierz dyskową. Przy zastosowaniu odpowiedniej macierzy tj. takiej która posiada dwa niezależne kontrolery oraz redundancję wszystkich kluczowych komponentów jak przyłącza dysków, zasilacze, wentylatory, karty sieciowe etc. oraz pozawala na dostatecznie wysokie skalowanie (tj. dodawanie kolejnych półek dyskowych) jesteśmy w stanie osiągnąć znaczne odpowiednie wydajności oraz poziom bezpieczeństwa. Jednakże należy pamiętać o dwóch aspektach. Przede wszystkim tego typu macierze gwarantujące pełne bezpieczeństwo nie są rozwiązaniami tanimi, zwłaszcza jeśli mają obsłużyć one duże środowiska i skalować się do np. kilkuset dysków twardych. Po drugie nawet najbezpieczniejsza macierz nie zapewni nam ochrony przez zdarzeniami katastroficznymi, dlatego aby zapewnić najwyższy stopień ciągłości działania należałoby zastosować druga macierz umieszczoną w oddzielonej geograficznie lokalizacji na którą najlepiej w czasie rzeczywistym replikowane są wszystkie dane z macierzy podstawowej. Należy też zadbać albo o odpowiednie procedury przełączania w wyniku awarii, ręczne lub w środowiskach wysokiej krytyczności automatyczne z wykorzystaniem np. mechanizmów (urządzeń wirtualizacji storage-u).
W organizacjach posiadających środowiska małe i średnie wielkości ww. rozwiązania są często nie akceptowalne w punktu widzenia budżetu. Coraz więcej pojawia się projektów wprowadzających zamiast architektury centralnej tzw. architekturę rozproszoną. W ramach takiego rozwiązania dane rozproszone są na wielu nie zależnych macierzach (serwerach). Logicznie taka konstrukcja przypomina grupę RAID tylko że realizowaną w oparciu o dyski w wielu serwerach.
W efekcie otrzymujemy zarówno bezpieczeństwo (dyski w pojedynczych serwerach są zgrupowane w RAID oraz dodatkowo dane rozrzucone są na wielu serwerach np. w formie RAID 0 co znacznie zwiększa wydajności, RAID 1 co zwiększa bezpieczeństwo czy RAID 10 co zwiększa obie wartości). Systemy storage-u o charakterze rozproszonym mają wiele różnych konstrukcji. Jednym z możliwych rozwiązań jest rozrzucenie danych w taki sposób że na każdym serwerze członku grupy znajdują się dane produkcyjne oraz kopia danych z innego członka grupy. Z każdego serwera dane produkcyjne udostępniane są jako target iSCSI czy wolumin NFS a wszystkie serwery w grupie tworzą klaster. Tego typu rozwiązaniem jest stworzony przez Vmware Virtual Strage Appliance (VSA).
Vmware Virtual Storage Appliance
Ideą VSA było zapewnienie wydajnego i wysoko dostępnego współdzielonego storage-u firmą z sektora SMB dla których koszty centralnej macierzy klasy Enterprise są zaporowe. VSA jest dostępne w cenie jednego z najpopularniejszych pakietów licencyjnych VMware tj. Essentials Plus (poza pakietem od wersji 5.1.3 można go nabyć jako vCenter Add-on lub standalone w cenie około 5k$ za instancję). Kluczowym aspektem VSA jest fakt że do utworzenia storage-u wykorzystujemy nasze produkcyjne serwery fizyczne (Hypervisory) oraz znajdujące się w nich dyski twarde. Musimy tylko zadbać o odpowiednią ilość dostępnego dodatkowego RAM gdyż VSA wymaga go minimum 6GB a rekomendowane jest nawet 24GB. Produkt dostarczany jest jak virtual appliacne (OVA) który instalujemy na każdym z naszych hostów fizycznych (min. dwóch, max. trzech).
Z technicznego punktu widzenia konstrukcja VSA jest następująca. Applaiance są maszynami wirtualnymi za zainstalowanym systemem operacyjnym Suse Linux Enterprise. W serwerach fizycznych na których umieszczony jest VSA (członkowie klastra) umieszczany jest on na znajdujących się w nich dyskach lokalnych dodanych jako Datstore. W celu zapewnienia najwyższego bezpieczeństwa i wydajności dyski lokalne muszą być połączone w macierz RAID 5, 6 lub 10 oraz być tego samego typu tj. prędkości, kontrolera oraz pojemności. Podczas instalacji VSA przestrzeń dostępna na Datastorze dzielona jest na dwie równe części jedną na dane produkcyjne drugą na replikę danych produkcyjnych z drugiego członka klastra. Analogiczna proces odbywa się na wszystkich członkach klastra. Jeśli nasza konfiguracja składa się z trzech hostów wynikowo mamy Host1 z Volume1 i kopią Volume3 z Host3, Host 2 z Volume2 i kopią Volume1 z Host1 oraz Host3 z Volume3 i kopią Volume2 z Host2. Woluminy produkcyjne wystawiane są jako punkty montowania NFS do Hypervisorów. Wszyscy członkowie klastra połączeni są w klaster HA tj. posiadają swoje sieciowe adresy IP oraz adresy wirtualne właściwe dla klastra oraz wymieniają pakiety Heartbeat. Dodatkowo wszystkie dane zapisywane na woluminach produkcyjnych są w czasie rzeczywistym replikowane na drugi host (replikę) za pomocą mechanizmu DRDB. W przypadku awarii jednego z członków klastra odpalany zostaje dostęp do jego repliki na drugim hoście a dane są cały czas dostępne.
W przypadku klastra z dwóch Hypervisorów sytuacja jest analogiczna z tym że VSA wymaga do poprawnego funkcjonowania klastra minimum dwóch aktywnych hostów niezbędne jest zainstalowanie dodatkowej usługi (np. na vCenter lub na zewnętrznej maszynie fizycznej lub wirtualnej) VSA Service która udaje członka klastra, uczestniczy w procesie elekcji etc.
Trudny wybór
Ze względu na swoją kluczowości wybór storage-u jest zawsze bardzo trudny i powinien być poprzedzony szczegółowymi analizami zarówno w zakresie kosztowym, jak i wydajności i bezpieczeństwa. Obecnie najpopularniejsze są rozwiązania centralne i będą królować jeszcze przez długi czas ale wydaje się ze w mniejszych środowiskach VSA zwłaszcza jeśli posiada się odpowiednie licencje może być bardzo skutecznym i optymalnym rozwiązaniem.
