Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


25.10.2019

Skalowalna infrastruktura

Red Hat OpenStack Platform 15
25.10.2019

Cienki klient 2.0

Windows Virtual Desktop
25.10.2019

Nowy sprzęt Microsoftu

Rodzina Surface się powiększa
24.10.2019

Serwery ARM

Oracle stawia na Ampere Computing
24.10.2019

Wszechstronny i elegancki

Dell XPS 15
10.10.2019

CYBERSEC EXPO - największe w...

Bezpieczeństwo cyfrowe nie jest problemem dotyczącym jedynie działów IT. Obecnie stanowi...
30.09.2019

Nowości w wirtualizacji

VMware World 2019
30.09.2019

Bezpieczeństwo mobile-first

Android 10

Konfiguracja wirtualizacji w małych środowiskach

Data publikacji: 26-09-2019 Autor: Marek Sokół
Rys. 1. Nowy interfejs...

Zarządzanie małym środowiskiem w ekonomicznej wersji licencyjnej wydaje się proste. Często faktycznie takie jest, ale pod warunkiem że administrator ma praktyczne doświadczenie w zarządzaniu takim środowiskiem. Prawidłowa konfiguracja klastra ułatwi rozwiązywanie problemów, które mogą nastąpić w czasie jego eksploatacji.

 

VM ware vSphere jest dojrzałą i rozbudowaną technologią, ale większości polskich firm musi wystarczyć licencja Essentials Plus, gdyż poziom licencyjny, pozwalający na dodanie czwartego hosta, wymaga znacznej dopłaty. Ta nie zawsze znajdzie swoje uzasadnienie biznesowe, zwłaszcza że nie jest to koszt jednorazowy – rosną również koszty utrzymania licencji. Dodanie kolejnego hosta ESXi do klastra vSphere pociągnie także za sobą dalsze koszty przy licencjonowaniu fizycznych procesorów lub serwerów: dość wspomnieć różne warianty licencji na Windowsa czy bazy danych (np. Oracle). W rezultacie wiele firm decyduje się na wybór klastra w jednym z niższych modeli licencyjnych.

> CZY RZECZYWIŚCIE TYLKO TRZY HOSTY WYSTARCZĄ?

W ramach licencji vSphere Essentials Plus mamy do dyspozycji jeden serwer vCenter oraz trzy hosty, po dwa procesory każdy. Technicznie możliwe jest jednak zakupienie kolejnej paczki licencyjnej i instalacja nowego klastra. Gdy rozbudowa środowiska jest uzasadniona, a utworzenie osobnego klastra – ze wszystkimi tego konsekwencjami – zaakceptowane, przystępujemy do przygotowań. Niezbędne są przegląd środowiska i zaplanowanie rozbudowy w taki sposób, aby uprościć zarządzanie oraz ewentualne zmiany w przyszłości. Warto poświęcić temu więcej czasu, gdyż znajomość architektury rozwiązania jest w całym procesie kluczowa. Gdy na łamach „IT Professional” (09/2017, s. 69 i 10/2017, s. 54) omawialiśmy instalację klastra z wykorzystaniem vSphere 6.5, niedostępna była przygotowana w C# natywna wersja klienta do zarządzania środowiskiem, a wersja oparta na HTML5 ciągle nie posiadała wszystkich funkcji. Obecnie, instalując wersję 6.7u3, dowiemy się, że klient bazujący na Flash nie jest już podstawową konsolą do zarządzania, został zastąpiony przez wersję HTML-ową. Kolejne zmiany nastąpiły w elemencie PSC (Platform Service Controller). We wcześniejszej wersji dla większych środowisk wykorzystujących Linked Mode wymagana była instalacja PSC jako osobnego serwera. W vSphere 6.7 wrócono do jednoserwerowej architektury dla każdej wielkości środowiska, poprzednia jest natomiast wycofywana.

Dla środowiska VMware jest bardzo ważne, aby posiadać serwery DNS ze wszystkimi wymaganymi wpisami oraz spójne i dostępne serwery czasu. W przypadku braku wysoko dostępnych serwerów DNS warto rozważyć utworzenie wpisów tylko dla serwerów vCenter, hosty ESXi można połączyć po adresach IP. Taka konfiguracja uniezależni środowiska od problemów z DNS, dzięki czemu vCenter zawsze będzie w stanie komunikować się z hostami. Ewentualne problemy dotkną tylko Linked Mode oraz administratora, który będzie chciał zalogować się do vCenter. Wówczas, w ramach obejścia w celu wymaganej rekonfiguracji środowiska, można szybko utworzyć odpowiedni wpis w pliku hosts na stacji administratora. W przypadku podłączenia serwerów ESXi poprzez nazwy domenowe obejście problemu będzie wymagać ponownego podłączenia hostów do vCenter poprzez adresy IP. Alternatywą jest naprawa serwerów DNS.

Drugą zewnętrzną usługą wymagającą uwagi jest NTP. Środowisko vSphere wymaga, aby na wszystkich hostach ESXi oraz serwerach vCenter był ten sam czas. Jednorazowe jego ustawienie nie stanowi rozwiązania, wymagane jest jego ciągłe weryfikowanie i korygowanie. Uchybienia w tym aspekcie mogą prowadzić do problemów na wszystkich warstwach zarządzania, zaczynając od braku możliwości analizy chronologii zdarzeń w środowisku, poprzez problemy z Linked Mode, a kończąc na niekontrolowanych zmianach czasu w maszynach wirtualnych, gdy te będą go synchronizować z hostem. W procesie rozwoju środowiska i dodawania do niego kolejnych modułów (np. vSAN) spójność czasu w środowisku będzie coraz ważniejsza. Podczas konfiguracji hostów najlepiej jest skonfigurować synchronizację czasu ze źródłem NTP, przy czym każdy host wymaga indywidualnej konfiguracji. Konfiguracji synchronizacji czasu dla vCenter dokonać można w interfejsie zarządzania vCenter https://<adres–vCenter>:5480.

> DOSTĘP PODCZAS AWARII

W procesie dodawania hosta do klastra za pośrednictwem interfejsu HTML5 także nastąpiły zmiany. Można dodać już kilka hostów jednocześnie, a jeżeli wszystkie mają zdefiniowane to samo hasło, to wybierając odpowiednią opcję, nie musimy podawać danych logowania wielokrotnie. Kreator nie zapyta jednak, jaką licencję przydzielić do hosta – wyboru należy dokonać w osobnym kroku, o którym administrator musi pamiętać. Nowy kreator nie zapyta też o konfigurację Lockdown mode, co stanowi zaletę – nie są już eksponowane opcje, których niewłaściwe skonfigurowanie spowodowałoby utratę kontroli nad hostem. Może to nastąpić, gdy z dowolnego powodu hostem nie da się zarządzać z poziomu vCenter. W takich sytuacjach do dyspozycji pozostają interfejsy DCUI lub SSH. Jeżeli Lockdown mode je odetnie, to odzyskanie kontroli nad hostem może się okazać niemożliwe, a pracujące maszyny wirtualne będę musiały zostać zrestartowane i przeniesione na zdrowy host mechanizmem HA. Zawczasu włączony dostęp poprzez SSH także może bardzo ułatwić przywracanie usług. Z tego powodu warto mieć włączoną obsługę SSH zarówno na ESXi, jak i vCenter. Włączenie dostępu na hoście wywoła ostrzegawczy komunikat w interfejsie vCenter, który można wyłączyć, jeżeli nie chcemy go wciąż oglądać.

Dla ułatwienia dostępu skryptowego czy transferu poprzez np. SCP, warto również aktywować na hoście ESXi Shell, a na vCenter Bash Shell. W tym miejscu wygoda stoi w opozycji do bezpieczeństwa. W małych środowiskach nie powinno stanowić problemu zalogowanie się w pierwszej kolejności do interfejsu IPMI, włączenie SSH, a następnie zalogowanie się za jego pośrednictwem do serwera. Oczywiście każdy administrator powinien indywidualnie przeanalizować zalety i zagrożenia takiej konfiguracji. Jeśli infrastruktura sieciowa obsługująca hosty składa się z dwóch fizycznych przełączników sieciowych, to standardowe przełączniki w hostach powinny wykorzystywać Teaming and fail­over. Jeśli został on dobrze skonfigurowany, to pozwoli w przypadku awarii jednego z przełączników zachować ciągły dostęp zarówno do hosta, jak i maszyn wirtualnych. Przełączniki fizyczne obsługujące VLAN-y pozwolą zaprojektować odpowiednią separację ruchu w środowisku. Dobrą praktyką jest utrzymywanie interfejsów zarządzania serwerami ESXi i IPMI w oddzielnych VLAN-ach. Dzięki temu ruch do zarządzania środowiskiem nie miesza się z ruchem produkcyjnym, a w razie potrzeby można łatwiej skonfigurować filtrowanie ruchu na zaporach sieciowych, jeżeli takie występują w środowisku. W przypadku wdrożenia filtrowania ruchu należy pamiętać, że brama domyślna dla interfejsów zarządzania jest monitorowana za pomocą ICMP. Dzieje się tak w celu wykrywania problemów sieciowych, które może poskutkować uruchomieniem mechanizmu HA. Należy uważać, aby nie odfiltrować tego ruchu. W małych środowiskach do zarządzania adresami IP wystarczy arkusz kalkulacyjny. Brak choćby takiej dokumentacji bardzo szybko doprowadzi do bałaganu i konfliktów adresów IP spowodowanych przez losowe ich przydzielanie. Ponadto w przypadku łączenia hostów ESXi z adresami IP (zamiast nazwami z DNS), wygodniej stosować kolejne lub bliskie siebie adresy. Bez planowania i ustalania rezerw na wypadek nowych instalacji trudno będzie uzyskać taki stan. Jedną z podstawowych cech vSphere jest vMotion – funkcja pozwalająca przenosić pracujące maszyny wirtualne pomiędzy hostami. Tutaj także wymagane są adresy IP w odizolowanej nieroutowalnej podsieci. Konieczne jest również skuteczne planowanie. Warto rozważyć ułatwienie w postaci przydzielenia podobnych adresów IP, jak np. 192.168.15.x/24 dla zarządzania hostem, a 192.168.16.x/24 dla vMotion. Taka konwencja ułatwi konfigurację, jak i ewentualne rozwiązywanie problemów. Inne usługi sieciowe konfigurowane na hostach także najlepiej umieszczać w osobnych VLAN-ach z przygotowanym systemem przydzielania adresów IP. Ostatnią rzeczą wartą konfiguracji w vCenter jest kopia bezpieczeństwa. Możliwe jest skonfigurowanie automatycznego, cyklicznego wykonywania backupu za pośrednictwem jednego z następujących protokołów: FTP, SCP, HTTP, NFS lub SMB. Jeśli wszystko zawiedzie i będziemy zmuszeni zainstalować nowe vCenter, wskazanie kopii danych, dzięki którym vCenter zostanie przywrócone, pozwoli oszczędzić sporo ręcznej konfiguracji.

 

> KONFIGURACJA KLASTRA

Przejdźmy do konfiguracji sieci wirtualnej, przy czym standardowy przełącznik wymaga indywidualnej konfiguracji na każdym hoście. W małych środowiskach nie jest problemem przeklikanie konfiguracji, ale ponownie należy zwrócić szczególną uwagę, aby konfiguracja była taka sama na wszystkich hostach. Warto również dołożyć starań, aby zachowane zostały nazewnictwo i numeracja przełączników wirtualnych, grup portów oraz interfejsów vmkernel. Zaniechania zemszczą się przy pierwszej awarii, wymagającej szybkiego wprowadzenia zmian, a nawet podczas trywialnej weryfikacji, czy ruch vMotion jest aktywowany na właściwych interfejsach.

 

[...]

 

Autor jest administratorem systemów IT. Zajmuje się infrastrukturą sieciowo-serwerową, pamięciami masowymi oraz wirtualizacją. Posiada tytuły VCP, MCP oraz CCNA. 

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"