O rozwiązaniu vSAN słyszeliśmy nie raz, nie dwa. Technologia nie jest już nowa i coraz częściej spoglądamy na nią łaskawszym okiem. Technologię tę możemy wykorzystać przy wirtualizacji stacji roboczych (niekoniecznie mowa tutaj o VMware Horizon), baz danych Oracle, MS SQL, MySQL, MS Exchange, SAP’a, jak i również dla małych oddziałów naszej firmy. I tym ostatnim się przyjrzymy. W przypadku małych oddziałów tego sprzętu potrzebujemy jak najmniej. Każde kolejne urządzenie podwyższa koszty operacyjne danej placówki. Chcąc minimalizować koszty rezygnujemy z tego, czy innego sprzętu.
VMware vSAN złożony z dwóch serwerów jest odpowiedzią na tego typu zapotrzebowanie. Dwa serwery fizyczne o określonej konfiguracji (wrócę jeszcze do niej za chwilę), kilka dysków twardych i jakiś przełącznik, który nie musi być wykorzystany do połączenia serwerów w klaster vSAN. Przełączniki i tak posiadamy, choćby nawet ze względu na użytkowników, którym musimy zapewnić dostęp do Internetu czy sieci wewnętrznej firmy. Wracając do samej konfiguracji sprzętowej serwerów, to istnieją gotowe zestawy, które posiadają certyfikat vSAN. Dzięki temu mamy pewność, że dany sprzęt będzie działał poprawnie i z określoną wydajnością. Co w przypadku gdy chcemy zmienić konfigurację sprzętową serwera? Hmm… zmieniamy ją. Najważniejszym elementem jest kontroler dysków twardych. Musi on wspierać nie tylko samego hosta ESXi, ale też być na liście kompatybilności z vSAN’em. Resztę podzespołów możemy zmieniać niemal dowolnie, pamiętając o VMware HCL. Pamiętajmy jednak, że wkładając słabszy procesor, wolniejsze dyski twarde itp. narażamy się na zmniejszenie wydajności klastra. Oczywiście zastosowanie sprzętu niezgodnego z HCL wiąże się również z potencjalnym nieudzieleniem pomocy przez pomoc techniczną VMware ze względu na niekompatybilny sprzęt. Ale to już inna historia, o której chyba nie raz już słyszeliśmy. Klaster składający się z 2 nodów wspiera konfiguracje hybrydowe, jak i i all-flash. W praktyce posiadamy 2 serwery vSAN i Witness.
Ale moment, jaki Witness? Jak wiemy do tanga trzeba dwojga, a do vSAN’u trojga. Czyli 2 węzłowy klaster vSAN nie jest w rzeczywistości 2 węzłowym klastrem? Tak i nie, ponieważ Witness może być maszyną wirtualną uruchomioną w innym DC lub na osobnym serwerze w ramach naszego małego oddziału. Możemy również taką maszynę uruchomić u jakiegoś operatora lub gdziekolwiek tam, gdzie posiadamy hosty ESXi. Każdy węzeł jest w tym wypadku skonfigurowany jako vSAN Fault Domain, czyli dwa sprzętowe serwery przechowujące kopie danych i Witnesss (1+1+1). W tej i innych konfiguracjach występuje tylko jeden Witness.
Sam Witness wymaga połączenia do obu serwerów w celu dołączenia do klastra oraz wymiany z klastrem informacji. Ruch może odbywać się w ramach sieci L2 jak i L3. W drugim wypadku musimy skonfigurować statyczny routing. Sam ruch między serwerami vSAN powinien odbywać się za pomocą L2. Widzimy to na poniższym schemacie.
Żeby nie było tak różowo, opóźnienie między hostami a Witness nie może być wyższe niż 500ms w obie strony. Nie jest to mało, ale należy to wziąć pod uwagę gdy nasz oddział znajduje się gdzieś w Afryce. Jeżeli chodzi o samą przepustowość łącza, to wystarczy 18Mbps. Dla całej komunikacji wymagane jest to samo MTU. W innym przypadku vSAN Network Health Check „zaświeci” się nam na czerwono. W tym wypadku mamy dwie możliwości – albo korzystać z MTU 9000 przy czym musimy zwrócić uwagę na ograniczenia sieci WAN, lub wszędzie zastosować MTU 1500. Należy pamiętać również, że NAT jest niewspierany jeżeli chodzi o ruch vSAN’owy i Witness. Dochodzą jeszcze interfejsy jakie powinny mieć serwery przy połączeniu bezpośrednim. Mianowicie przy klastrze all-flash 10Gbps i szybsze, a klastrze hybrydowym można wykorzystać 1Gbps. Klaster 2nodowy jest odporny na awarie jednego z 3 site’ów. Sama awaria Witnessa nie ma wpływu na pracę maszyn wirtualnych. Można powiedzieć „NOT BAD NOT BAD”.
Teraz trochę informacji o możliwościach jakie mamy w przypadku konfiguracji interfejsów. Karty sieciowe vmk2 i vmk3 jak widzimy na schemacie poniżej są bezpośrednio połączone ze sobą między serwerami. Są wykorzystywane do vMotion oraz ruchu vSAN. Sprawa w tym przypadku jest stosunkowo prosta. Interfejsy Management połączone do przełącznika wykorzystywane są do komunikacji np. z vCenter. Dowolny port VMkernel, nieużywany dla ruchu vSAN, może być używany dla ruchu Witness. W bardziej uproszczonej konfiguracji interfejs VMkernel zarządzania (vmk0) może być oznaczony jako Witness Traffic. Użyty port VMkernel będzie wymagał łączności z interfejsem vSAN Tagged Traffic na urządzeniu vSAN Witness Appliance. Oczywiście aby oznaczyć interfejs jako Witness Traffic musimy zalogować się do hosta np. przez SSH i wykonać polecenie esxcli vsan network ip add -i vmk1 -T=witness. Aktualnie nie ma możliwości zmiany tego przez Web Client, ale zapewne kiedyś się pojawi. Interfejs VMkernel vmk0, który jest wykorzystywany do ruchu Management, może być również wykorzystywany do ruchu vSAN. W tej sytuacji ruch vSAN musi być odznaczony na karcie vmk1. Ostatnią istotną rzeczą jest to, aby vmk1 i vmk0 nie posiadały adresacji w tej samej podsieci.
Te wszystkie zabiegi umożliwiają oddzielenie ruchu dla sieci między hostami, a hostami i świadkiem. Dzięki temu konfiguracja sieci staje się bardziej elastyczna.
Klaster 2nodowy jest klastrem typu streach. Minimalna licencja do uruchomienia go to vSAN Standard. W każdej chwili, jeżeli zajdzie taka potrzeba możemy przekształcić klaster 2nodowy na klasyczny z 3 hostami i więcej. Oznacza to, że z „małego vSAN’a” możemy zrobić „dużego vSAN’a”. Jednak wymagane są kolejne licencje vSAN. Jeżeli również chcemy zachować funkcjonalność streach cluster musimy wczytać się w licencje vSAN Enterprise. W zależności od scenariusza można wykorzystać licencje ROBO (25VM) lub per CPU. Fajną sprawą jest również posiadanie możliwości uruchomienia vSAN’a gdy posiadamy już licencje Horizon Advnced. Oczywiście w tym wypadku również jeżeli chcemy posiadać funkcje streach cluster, wymagana jest licencja vSAN Enterprise. Nie musimy jej kupować osobno, wystarczy zakupić odpowiedni Horizon Add-On. Standardowo licencje Add-On dostępne są w paczkach 10 i 100szt, podobnie jak w przypadku licencji Horizon.
Słowem podsumowania – rozwiązanie może być przydatne dla kogoś kto ceni sobie minimalizm i prostotę zarządzania rozwiązaniem, a chce przetrzymywać dane u siebie. Benefitami w tym przypadku jest mała ilość sprzętu czy to sieciowego, czy macierzowego. Centralne zarządzanie, bo w końcu widzimy wszystko z poziomu vCenter i nawet przy najniższej licencji otrzymujemy vDS. Planując więc zakupy kolejnego przełącznika czy macierzy do małego oddziału naszej firmy, warto usiąść i zadać pytanie: Czy na pewno warto?
| Produkt | Kwota |
| Serwer 1xCPU AMD EPIC 16C, 256GB RAM, 3×1.8TB HDD, 400GB SSD WI, 2x1GbE, 4x10Gb SFP, 2x550W, 5lat gwarancji | 40 000 PLN netto |
| Licencja vSphere Standard per 1CPU + 3 lata wsparcia | 10 000 PLN netto |
| Licencja vSAN Standard per 1 CPU + 3 lata wsparcia | 16 000 PLN netto |
Kwoty znalezione na stronach producentów i przeliczone po średnim kursie. Zapewne możemy liczyć na spory rabat w tym wypadku. Przy takiej konfiguracji dyskowej osiągniemy około 3.2TB przestrzeni użytkowej.
„Artykuł został opublikowany na łamach bloga evoila Poland.”
