Federacja by Simplivity – część III

W poprzedniej części opisałem kroki niezbędne do uruchomienia poszczególnych systemów. Teraz możemy wygodnie rozsiąść się w fotelu i zdalnie kontynuować instalację. Zanim do tego przejdziemy, przyjrzyjmy się schematowi całego rozwiązania.

Najważniejszą kwestią jest, że dyskami znajdującymi się z przodu serwera nie zarządza host ESXi tylko OVC. Wspomniany appliance komunikuje się z innymi i dba o spójność przechowywanych danych z innymi systemami w Federacji, oraz udostępnia dane z dysków jako jeden wspólny dla wszystkich członków zasób NFS.

Uruchomienie Federacji

Krok 1.

Na przygotowanym, w poprzedniej części artykułu, serwerze vCenter instalujemy arbitra – agenta SimpliVity, mającego rozstrzygać, które OVC utraciło łączność z resztą środowiska. Kolejnym niesłychanie ważnym elementem jest instalacja vSphere Extension plugin na stacji, z której będziemy zarządzać środowiskiem za pomocą windows’owego klienta vSphere.

Rysunek 1 Architektura Federacji SimpliVity

Jest to bardzo krytyczny krok, gdyż bez jego instalacji nie możemy zarządzać Federacją. W sytuacji, gdy w firmie pojawi się nowy administrator VMware i nie będzie świadomy potrzeby instalacji wspomnianego rozszerzenia na swojej stacji – rozwiązanie mu w żaden sposób tego nie podpowie. Brakujące rozszerzenie nie pojawia się na liście wtyczek do instalacji/aktywacji.

Krok 2.

Na serwerze vCenter zakładamy użytkownika windows svtuser, następnie dodajemy go do nowej roli w vCenter, której nadajemy następujące uprawnienia:

• Create Alarm (Alarm.Create).
• Disable alarm action (Alarm.DisableActions).
• Modify Alarm (Alarm.Edit).
• Set alarm Status (Alarm.SetStatus).
• Remove alarm (Alarm.Delete).
• Register Extension (Extension.Register).
• Update Extension (Extension.Update).
• Unregister Extension (Extension.Unregister).
• Global – health (Global.Health).
• Global – log event (Global.LogEvent).
• Global – manage custom attributes (Global.ManageCustomFields).
• Global – set custom attribute (Global.SetCustomAttribute).
• Global – diagnostics (Global.Diagnostics).
• Host CIM – CIM- interaction (Host.Cim.CimInteraction).
• Create task (Task.Create).
• Update task (Task.Update).
• vApp – Assign a Vapp (VApp.Assign VApp).
• vApp – Unregister (VApp.Unregister).
• vApp – Application configuration (vApp.vApp application configuration).
• Virtual machine – Configuration – Configure ManagedBy (Virtual machine.Config.managedBy).
• Virtual machine – Configuration – Settings (Virtual machine.Config.settings).
• Virtual machine – State – Remove Snapshot (Virtual machine.State.RemoveSnapshot).
• Virtual machine – State – Create Snapshot (Virtual machine.State.CreateSnapshot).

Krok 3.

Podłączamy hosty OmniCube do vCenter. W tym momencie podłączone Omnicube’y wyglądają jak zwykłe hosty ESXi z datastore’m umiejscowionym na tylnych dyskach serwera o rozmiarze poniżej 300GB. Na tych datastore’ach umieścimy maszyny OVC.

Krok 4.

Konfigurujemy switche wirtualne. Switch vSwitch0 powinien być już prawidłowo skonfigurowany przy okazji konfiguracji hosta ESXi (w poprzedniej części artykułu). Tworzymy vSwitch1, dodajemy do niego interfejsy vmnic0 oraz vmnic1 (10GbE). Dodajemy WMkernel Port o nazwie Storage i aktywujemy na nim vMotion, konfigurujemy adresację IP. Dodajemy jeszcze grupę dla sieci danych oraz federacji. Ważne jest, aby zmienić dla vswitch’a MTU na 9000.

Rysunek 2 Konfiguracja sieci dla hosta ESXi

Krok 5.

Rozpoczynamy przygotowania do uruchomiania wspomnianych maszyn, w tym celu uruchamiamy kreator Pre-deployment Wizard:

Wybieramy utworzenie nowego pliku odpowiedzi – zamierzamy uruchomić dwa hosty zatem powstaną dwa pliki.

Wybieramy rodzaj sieci – w naszym przypadku połączenie bezpośrednie, oraz dwa hosty.

Podajemy adresy dla pierwszego hosta ESXi oraz pierwszego OVC.

Definiujemy konfigurację IP dla ESXi oraz OVC dla sieci danych oraz federacyjnej

W kolejnych dwóch krokach definiujemy adresy dla drugiego ESXi i OVC

W ostatnim kroku weryfikowane są wprowadzone dane. Po pomyślnym zakończeniu testów tworzone są pliki odpowiedzi.

Kreator nie jest pozbawiony wad

• przycisk Dalej znajduje się w prawym dolnym roku okna, podczas gdy Wstecz jest w lewym górnym. Dodatkowo oba przyciski mają całkowicie inną szatę graficzną. Osobie zapoznającej się z rozwiązaniem w pierwszej chwili może się wydawać, że opcji powrotu po prostu nie ma.
• dla każdego OmniCube trzeba wpisać wszystkie adresy, co w przypadku dwóch nie jest problemem – jakże nurzące i błędogenne może to być w przypadku budowania federacji składającej się już z kilkunastu węzłów

Krok 6

Konfigurujemy hosty ESXi, aby pobierały czas z tych samych serwerów NTP, które zdefiniowaliśmy w kreatorze w kroku 5.

Krok 7

Jeśli samodzielnie reinstalowaliśmy hosta ESXi, musimy zainstalować na obu hostach maszyny OVC z szablonu OVT. Bardzo ważne jest, aby maszyny nazwały się SimpliVity-xxxx, gdzie xxxx są cyframi, np. SimpliVity-1111 oraz Simplivity-2222.

Rysunek 3 Wdrażanie nowej maszyny OVC na hoście

Przechodzimy do hosta do zakładki Simplivity, uruchamiany kreator wciskając Next.

Rysunek 4 Kreator uruchomienia OVC

Wskazujemy jeden z plików odpowiedzi utworzony w kroku 5

Następuje weryfikacja konfiguracji.

Wprowadzamy hasło roota do hasta ESXi, definiujemy hasło awaryjnego dostępu oraz nazwę firmy.

Wprowadzamy dane użytkownika svtuser utworzonego w kroku 2

Wybieramy z listy sieć zarządzającą…

sieć danych oraz federacyjną

Wyświetlany jest ekran podsumowania

Ostatecznie następuje proces uruchomienia OVC i utworzenie nowej federacji.

Powtarzamy wszystkie czynności dla OVC na drugim hoście ESXi

Krok 8

Zostaje już tylko utworzyć pierwszy wspólny dla wszystkich hostów datastore.

Klikamy prawym klawiszem myszki na Datacenter i wybieramy utworzenie Datestore’a

Określamy nazwę dla datastore’a. Każdy datastore musi mieć przypisaną politykę backupu. Jako że jeszcze żadnej nie mamy, uruchamiany kreator.

Określamy nazwę dla polityki

Rozpoczynamy definiowanie jej reguł

Określamy z jaką czestotliwością ma być wykonywany backup wszystkich maszyn na danym datastore.

Po zatwierdzeniu reguł, możemy ostatecznie utworzyć pierwszy datastore.

Po utworzeniu współdzielonego, wysoko dostępnego datestore’a, możemy tworzyć maszyny wirtualne.

Podsumowanie

Chociaż utworzenie Federacji nie jest trudne, mimo wszystko jest czasochłonne i wymaga skupienia, aby nie popełnić błędu. Szczególnie niewygodne jest definiowanie plików odpowiedzi dla maszyn wirtualnych oraz konieczność wdrażania kolejnych OVC po jednej. Jednak po pewnym czasie zaczyna się to robić sprawnie i nie nastręcza to już trudności. Wiemy natomiast, że w niedługim czasie SimpliVity udostępni znacznie uproszczoną wersję kreatora, która będzie bardzo pomocna we wdrażaniu federacji składających się z większej ilości węzłów. Rozwiązanie SimpliVity ma na celu uproszczenie zarządzania infrastrukturą, cieszy zatem wiadomość, że jest to proces ciągły.