Stanąłem przed problemem skalastrowania systemów Windows Server 2003 R2 i Windows Server 2008R2 na vSphere. Problem nie wydaj się specjalnie skomplikowany, niby wszystko jest dobrze opisane w dokumentacji VMware’a oraz na wielu blogach w Internecie. Jednak diabeł tkwi w szczegółach a wszystkie opisy które znalazłem są raczej dosyć ogólne i konfiguracja wymaga sporej inwencji twórczej i poszukiwania co znowu poszło nie tak…

W tej części opiszę jak przygotować sobie środowisko VMware do klastrowania. Ja zdecydowałem się że sklastrowane VM będą na różnych hostach fizycznych, bo wtedy ma to jakiś większy sens :). Rozłożenie maszyn wirtualnych na maszynach fizycznych jest bardzo istotne w przypadku klastrowania Windows Server na vSphere. Trzeba odpowiedzieć sobie na początku całego przedsięwzięcia na to właśnie pytanie, bowiem fakt że maszyny będą na tych samych, lub różnych serwerach ESX determinuje dalszą konfigurację.

Tak więc podsumowując, składniki niezbędne do przygotowania naszego dania są następujące:

  • Jeden świeży klaster serwerów VMware oparty o vSphere
  • Trzy małe maszyny wirtualne oparte o Windows Server 2003 Enterprise (może być 2008)
  • Jedna średnio dojrzała macierz dyskowa

Pierwszym krokiem jest stworzenie maszyny wirtualnej. Będę to robić na przykładzie Windows Server 2003 R2, ale w przypadku 2008/2008 R2 jest w sumie podobnie, różnicę zaznaczę w tekście. Warto stworzyć sobie Template takiej maszyny bo tak naprawdę będziemy musieli ją jeszcze klika razy powielić. Przy konfiguracji schematu maszyny należy dograć specjalne pliki do sysprepa na serwerze vCenter. Robimy to zgodnie z instrukcją z jednego z moich poprzednich wpisów. W przypadku gdy tak jak ja pokusiliście się na mały hardcore z systemem Windows Server 2008R2 64bit to miejsce gdzie wrzuca się domyślenie sysprepy znajduje się w „C:\ProgramData\VMware\VMware VirtualCenter\sysprep”.

Podczas tworzenia maszyny wirtualnej naszego systemu bazowego należy wybrać w zakładce „Configuration” opcje „Typical”. Podczas wyboru Datastore należy zwrócić uwagę aby umiejscowić VM tak by była dostępna dla wszystkich serwerów ESX które są w klastrze. Następnie w kroku „Guest Operating System” wybrać Microsoft Windows, oraz w zakładce „Version” opcję „Microsoft Windows Server 2003, Enterprise Edition (32-bit)” (lub 2008). Dosyć istotnym krokiem jest zaznaczenie w kroku „Create a Disk” opcji „Support clustering features such as Fault Tolerance”. Dzięki tej opcji nasza maszyna będzie wspierać klastrowanie.

Następnie konwertujemy VM do Template i odstawiamy do lodówki, żeby się nam nie zepsuła 🙂

Teraz należy przygotować macierz. Sprawa dosyć prosta, zakładamy LUN’a, nazywamy go jakoś niewybrednie, np. QUORUM01 ;), następnie ustawiamy uprawnienia aby wszystkie ESX’y w klastrze były wstanie go dojrzeć. LUN nie musi być jakiś ogromny, myślę, że spokojnie wystarczy 1GB.

Ogarnięcie macierzy to sprawa dosyć prosta i bezproblemowa, tak wiec po pomyślnej konfiguracji należy sprawdzić co zobaczyły nasze ESX’y. Sprawdzamy to w zakładce „Configuration”, „Storage Adapters”. W przypadku gdy nie zobaczyły nic, co zresztą jest normalne, należy użyć opcji „Rescan…”

W przypadku gdy ESX nie wykryje naszego nowego LUN’a to znaczy że gdzieś na macierzy popełniliśmy błąd, np. nie przypisując hosta do LUN’a. Warto sprawdzić. Nie zakładamy partycji VMFS na tym Quorum, gdyż będzie on podawany sote bezpośrednio do maszyn wirtualnych. Operację „Rescan…” będziemy musieli wykonać na wszystkich hostach w klastrze.

Dobrze, tak wiec mamy skonfigurowaną macierz, oraz serwery ESX. Czas na maszyny wirtualne. Posłużymy się w tym kroku przygotowanym wcześniej i już nieco skruszałym szablonem maszyny z Windows Server 2003R2. Wykonujemy Deploy po trzykroć. Maszyny nazywamy Node0, Node1, Node2. Po zakończonym tworzeniu nowych maszyn wyłączamy je i zabieramy się za małą rekonfigurację sprzętu w każdej z VM. Warto w tym miejscu nadmienić, że podczas konfiguracji klastra opartego o mechanizmy Windows należy pilnować by przed finalnym „OK.” nie dopuścić do tego by dwie maszyny działały w tym samym czasie. Generalnie chodzi o dostęp do dysku Quorum, przed finalną konfiguracją klastra po prostu może się coś się z nim popieprzyć… nigdy co prawda nie zdążyło mi się to. Jednak święte „Best Practice” Microsoftu tak każe wiec ja uniżony, szary admin, cóż mogę począć jak tylko się temu ślepo podporządkować.

Dość jednak tych dygresji, czas na konfigurację wirtualnego hardware. Dodamy teraz do VM dysk który ma być Quorum. Będziemy mapować RAW LUN’a, tak aby VM miała wrażenie że sama dobiera się do czystego Storage na macierzy. Zabieramy się więc za maszynę zwaną Node1 (Node0 będzie kontrolerem domeny wiec zostawiamy go jakiś czas w spokoju). Prawy przycisk myszy, „Edit Settings” w zakładce „Hardware”  klikamy w „Add…” i wybieramy Hard Disk.

W następnym kroku kreator prowadzi nas do karty „Select a Disk” tu wybieramy opcję ostatnią, mianowicie „Raw Device Mappings”. Dzięki temu damy naszej maszynie wirtualnej bezpośredni dostęp do sieći SAN i naszego RAW LUN’a.

W kolejnym kroku zobaczymy dostępne RAW LUN’y. W moim przypadku mam tylko jeden więc pozbawiony wyboru decyduje się właśnie na niego.

W kroku „Select Datastore” wybieramy „Store with Virtual Machine”. Można zdecydować się na trzymanie tego dysku na innym Datastore… tylko pytanie po co? 😉

Następnie w „Compatibility Mode” wybieramy „Physical” i przechodzimy dalej.

Czeka nas teraz najważniejszy krok mianowicie „Advanced Options” należy tu wybrać pierwszy wolny Virtual Device Node z innego kontrolera niż zerowy, czyli np. SCSI (1:0). Numer VDN należy zapamiętać, gdyż później w konfiguracji kolejnych nodów klastra będzie on istotny.

Kolejnym krokiem jest podsumowanie, które oczywiście akceptujemy tworząc w ten sposób nowy kontroler SCSI, oraz dysk twardy. Pozostała nam jeszcze jedna rzecz, mianowicie w właściwościach nowopowstałego kontrolera SCSI musimy zmienić typ „SCSI Bus Sharing” z „None” na „Phisical”. Krok ten pozwoli nam na współdzielenie tego zmapowanego RAW LUN’a pomiędzy dwoma, lub więcej maszynami wirtualnymi rozsianymi na różnych hostach fizycznych. W opcjach kontrolera można również zmienić jego typ, ponieważ do konkretnej wersji systemu Windows Server jest odpowiednia wersja kontrolera, poniżej rozpiska:

  • LSI Logic Parallel dla Windows 2000 Server
  • LSI Logic Parallel dla Windows Server 2003
  • LSI Logic SAS dla Windows Server 2008

Przechodzimy teraz do serwera Node2. Procedura dodawania dysku Quorum jest podobna, ale prześledźmy ją od początku. Pierwszym naszym korkiem będzie również udanie się do właściwości maszyny wirtualnej, i dodanie dysku twardego, pierwsza różnica pojawia się w zakładce „Select a Disk”, wybieramy tu bowiem nie tak jak poprzednio „Raw Device Mappings” ale „Use an existing virtual disk”.

W kolejnym kroku musimy podać namiary na dysk który został zmapowany do serwera Node1, tak wiec klikamy „Browse…” i szukamy po naszyn Datasorach gdzie mamy maszynę wirtualną i dysk „Node1_1.vmdk”.

W kolejnej zakładce, wybieramy „Virtual Device Node”. Tak jak wspominałem wcześniej musi być ono identyczne z tym które mamy skonfigurowane dla serwera Node1. W moim przypadku jest to SCSI (1:0).

Po zakończeniu należy tak jak w przypadku serwera Node1 ustwaić w opcjach kontrolera typ „SCSI Bus Sharing” z „None” na „Phisical”.

Dodatkowo można dorzucić do maszyn wirtualnych po karcie sieciowej. Jest to kolejna rada wyjęta z „Best Practices” Microsoftu, tak wiec jak ktoś chce to niech się przejmuje… ja zrobiłem do testów na jednej i śmiga jak burza. Tak wiec do rozważenia.

To na razie tyle, przystawki do głównego dania wykonane w drugiej części będziemy konfigurować same Windows Server’y 2003/2008, gdyż od strony vSphere to już w zasadzie wszystko.

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.

Leave a Reply