Nutanix – instalacja

Poprzednia część cyklu opowiadała o samej firmie Nutanix jak i architekturę jej rozwiązania.  Dziś nieco praktyczniej, bo Dzięki uprzejmości firmy S4E, polskiego dystrybutora Nutanix, miałem okazję przetestować rozwiązanie w praktyce. Egzemplarz, który otrzymałem w swoje ręce to NX-3050. Jest on przedstawicielem serii o dużej gęstości, gdzie w obudowie 2U może znajdować się do czterech serwerów (testowany sprzęt składał się z trzech serwerów). Niestety testowałem model, którego sprzedaż zakończyła się w lutym 2016 roku oraz została już wyznaczona data zakończenia jego wsparcia (EOL).

Pozostawia to pewien niedosyt szczególnie, że napotkałem problem, który ponoć już nie występuje w nowszych wersjach (szczegóły wkrótce).

Rysunek 1 Zdjęcie testowanego modelu po zdjęciu osłony. W ramach jednej obudowy mogą się znajdować cztery serwery – w testowanej konfiguracji było trzy. Każdy serwer ma swoją grupę dysków twardych oraz diody sygnalizujące jego stan.

Konfiguracja sprzętowa i połączenia

Z powodu braków sprzętowych (ilość dostępnych interfejsów 10GbE na przełączniku), testowe środowiska nie odzwierciedla konfiguracji, która powinna być zastosowana w środowisku produkcyjnym (rysunek 2). Jako, że sieć na potrzeby ruchu klastra nie może być odseparowana od ruchu zarządzającego, wysoka dostępność sieci zapewniona została połączeniami 1GbE.

Rysunek 2 Poglądowa konfiguracja zastosowanych połączeń, wykorzystane do wizualizacji przełączniki nie reprezentują zastosowanych w laboratorium. Testowane rozwiązanie składało się z trzech serwerów – co jest ujęte na rysunku.

Wysoka gęstość upakowania serwerów wymaga mniej miejsca w szafie rack, niestety pociąga to za sobą dużą ilość kabli, które trzeba ergonomicznie ułożyć. W konfiguracji czterech serwerów w bloku, przy pełnym okablowaniu, jednostka 2U posiadałaby następujące połączenia

• 2 połączenie zasilające
• 8 połączeń 10GbE
• 12 połączeń 1 GbE
• 4 połączenia VGA
• 4 połączenia USB (klawiatura, mysz)

Daje to, aż trzydzieści kabli które należy odpowiednio rozmieścić, w szczególności należy zadbać aby nie zakłócały przepływu ciepłego powietrza, które przez ten obszar jest wypychane z serwerów. Kolejną niestandardową trudnością przy późniejszym utrzymaniu takiej infrastruktury jest zapewnienie możliwości wyjęcia jednego z serwerów bez zakłócenia pracy pozostałych – serwery wysuwają się do tyłu. Kto próbował wymienić element, który wysuwa się w tą stronę, dbając o to aby nie rozłączyć innych – wie, że zadanie może być karkołomne. Przód obudowy jest w całości wypełniony dyskami twardymi. Prawdopodobnie taka konstrukcja wynika z tego, że częściej wymagana będzie wymiana pojedynczych dysków twardych niż serwerów w bloku.

Rysunek 3 Widok pojedynczego serwera wyjętego z bloku.

Konfiguracja sprzętowa pojedynczego serwera wygląda następująco:

• 2x Intel Xenon E5-2670
• 2x SSD 400GB
• 4x HDD 1TB 7200 RPM
• 128 GB RAM
• 2x 10GbE SFP+
• 2x 1GbE RJ45

Instalacja ręczna

Po skonfigurowaniu wszystkich fizycznych połączeń można przejść do instalacji klastra. Dostępne są metody automatyczne oraz ręczna. Wszelkie metody automatyczne bardzo skracają czas i są oczekiwane przez konsumentów, jednak w sytuacji gdy automat zawodzi dobrze jest umieć przeprowadzić proces ręcznie. Tak też się stało podczas testu, procedura automatyczna początkowo nie chciała zadziałać, a dostępność środowiska była z góry ograniczona. Nie mogąc pozwolić na stratę bezcennego czasu pozwalającego na przetestowanie kolejnych funkcjonalności, rozpoczęto ręczną procedurę instalacji. Pierwszą serię kroków należy powtórzyć dla każdego serwera, aby ostatecznie utworzyć klaster łączący wszystkie serwery.

Kroki do wykonania na pojedynczym serwerze.

1. Uruchamiamy serwer i wchodzimy do ustawień BIOS, gdzie konfigurujemy interfejs IPMI, pozwalający konfigurować serwer przez sieć.
2. Łączymy się z serwerem za pomocą interfejsu IPMI i rozpoczynamy instalację wirtualizatora (w testowanym środowisku był to ESXi 5.5). Istotne jest nadanie, określonego w dokumentacji, hasła dla użytkownika root. Samego hosta ESXi należy zainstalować na dedykowanej pamięci flash (rysunek 4). Dostępne w procesie instalacji inne dyski twarde będą przekazane w zarządzanie maszynie wirtualnej CVM (opisanej w poprzednim artykule). W ramach instalacji hosta należy jeszcze odpowiednio skonfigurować adresy IP dla zarządzania serwerem ESXi.
3. Instalacja CVM, to bardzo ciekawy etap, gdyż nie następuje tu typowy proces wdrażania maszyny wirtualnej z szablonu. Ponownie startujemy serwer z obrazu instalacyjnego, lecz tym razem jest to instalator maszyny CVM (rysunek 5). W wyniku tego procesu uzyskujemy host ESXi z jedną maszyną wirtualną. Interesujący jest fakt, że analizując konfigurację urządzeń tej maszyny wirtualnej, trudno jest określić, gdzie konkretnie znajdują się jej pliki (z dokumentacji wiemy, że w znajdują się one na dysku SSD, który jest przecież podłączony do tej maszyny w trybie pass-through). W pamięci flash, gdzie jest zainstalowany ESXi znajdują się tylko niezbędne informacje do jej uruchomienia i załadowania reszty danych z dysku SSD.

Rysunek 4 W procesie instalacji hosta ESXi ważny jest właściwy wybór dysku

Rysunek 5 Ekran konfiguracyjny z procesu instalacji CVM

Kroki do wykonania niezbędne dla uruchomienia klastra.

1. Logujemy się do konsoli jednej z CVM (konsola VMware lub przez SSH)
2. Tworzymy klaster poleceniem cluster –s <IP_CVM1> <IP_CVM2> <IP_CVM3> create
3. Nadajemy klastrowi nazwę: ncli cluster edit-params new-name=<NOWA-NAZWA> (rysunek 6)
4. Konfigurujemy strefę czasową: ncli cluster set-timezone timezone=Europe/Warsaw

Rysunek 6 Proces konfiguracji, ręcznie utworzonego klastra.

Instalacja automatyczna

Po zakończeniu testów, gdy skasowanie całej konfiguracji nie było już problemem, ponowiony został proces automatycznej instalacji klastra.

W dużym uproszczeniu możliwe są dwie metody automatyczne

• Na komputerze administratora uruchamiamy maszynę wirtualną na której uruchamiany jest cały proces
• Na komputerze administratora uruchamiamy aplet Java, który będzie odpowiedzialny za cały proces

Omawiany instalator nazwany jest Fundation, istotne jest aby komputer administratora miał włączoną obsługę IPv6. W celu uniknięcia ewentualnych problemów, należy umieścić w jednym segmencie sieci następujące elementy:

• Komputer administratora
• Interfejsy IPMI
• Interfejsy 10GbE

Proces automatycznej instalacji składa się z następujących kroków:

1. Uruchomienie apletu Fundation Launcher, który wyświetli listę wykrytych węzłów. Wskazujemy serwery do instalacji. Następnie kroki wykonujemy z interfejsu www za pomocą przeglądarki

2. Potwierdzamy wykryte węzły
3. Definiujemy parametry klastra: nazwa, serwer NTP, DNS, maska i brama sieciowa dla serwerów i maszyn CVM, ilość pamięci RAM dla maszyn CVM
4. Definiujemy parametry unikalne dla hostów oraz maszyn CVM: nazwa hosta, adres IP, adres IP CVM, adres interfejsu IPMI, po weryfikacji konfiguracje możemy przejść do następnego kroku
5. Wskazujemy obraz instalacyjny maszyn CVM oraz hostów ESXi

6. Rozpoczyna się instalacja systemu na wszystkich węzłach w klastrze, a w ostatnim kroku zostaje utworzony klaster.

Podsumowanie

Fizyczna instalacja rozwiązania nie jest trudna, lecz uwagi wymaga sam proces prowadzenia okablowania, ze względu na ilość fizycznych połączeń do wykonania jak i zapewnienia sprawnej możliwości wymiany pojedynczych serwerów. Automatyczna instalacja oprogramowania na serwerach jest prosta, eliminuje potencjalne błędy które można popełnić robiąc to ręcznie oraz co najważniejsze skraca czas wdrożenia.