Instalacja i konfiguracja wysoko dostępnych rozwiązań w systemie Windows Server 2008 została uproszczona do tego stopnia, że cały proces mozna nazwać wręcz banalnie prostym.

Jednak pomimo ogromnych korzyści, jakie niewątpliwie niesie ze sobą implementacja tego typu rozwiązania, wiele osób jeszcze nie zdążyło lub też nie miało okazji się z nim zapoznać.

Okazuje się, że nadspodziewanie często głównym problemem powstrzymującym nas od testów, eksperymentów i zabawy z failover clustering, jest brak dostępu do urządzeń typu SAN i NAS. Właściwie nie ma w tym nic dziwnego, zwłaszcza biorąc pod uwagę ceny tych urządzeń.

Istnieją jednak inne sposoby na to, abyśmy mogli zapoznać się z klastrami tworzonymi na bazie systemów Windows.

Poniżej mała, klastrowa historyjka obrazkowa, która opisuje, jak w prosty sposób stworzyć środowisko testowe, na którym będziemy mogli zaznajomić się i, mówiąc nieco kolokwialnie, obstukać z klastrami.

Środowisko

Całe środowisko testowe składa się z trzech maszyn wirtualnych. Jednego kontrolera domeny (niezbędny element przy „failover clustering”) i dwóch serwerów członkowskich pełniących rolę węzłów (nodes) w naszym klastrze.

Aby zminimalizować liczbę potrzebnych maszyn, program pełniący rolę iSCSI Target zainstalujemy na kontrolerze domeny zamiast na dedykowanym serwerze/stacji.

Wszystkie maszyny wirtualne posiadają dwie karty sieciowe. Jedno połączenie (LAN), przeznaczone do komunikacji z klientami w sieci. Drugie (iSCSI), dedykowane do połączeń pomiędzy węzłami klastra i celem iSCSI.

Pierwszy serwer: kontroler domeny

 Funkcje: kontroler domeny (DC), iSCSI Target
Nazwa: LHDC1
Konfiguracja IP (Rys.1):
LAN:
IP:  192.168.10.1/24
DNS: 192.168.10.1
iSCSI:
IP:  10.1.1.1/8

Dodajemy rolę Active Directory Domain Services (AD DS) i uruchamiamy kreatora Active Directory, czyli po prostu tworzymy domenę. Możemy w tym celu skorzystać na przykład z Installing a New Windows Server 2008 Forest by Using the Windows Interface.

Instalujemy iSCSI Target Emulator (StarWind – wersja próbna).

W tym celu ściągamy wersję próbną (30 dni) programu StarWind iSCSI Target, czyli programowej implementacji celu iSCSI i uruchamiamy go na naszym kontrolerze domeny. StarWind w bardzo prosty i szybki sposób pozwoli nam na skorzystanie z zalet rozwiązania IP SAN, skutecznie eliminując potrzebę posiadania dedykowanego urządzenia.

Microsoft również udostępnia programowy iSCSI Target, jednak jego dostępność do celów testowych jest ograniczona (więcej informacji na ten temat można znaleźć w Microsoft iSCSI Software Target Q&A), dlatego w naszym środowisku skorzystamy z aplikacji StarWind.

Cała instalacja sprowadza się praktycznie do przeklikania kilku okien, bez konieczności wyboru jakichś tajemniczych opcji iSCSI, dlatego nie ma sensu jej tutaj szczegółowo opisywać.

Po uruchomieniu konsoli StarWind, do której skrót znajdziemy chociażby na pulpicie, możemy przystąpić do konfiguracji.

Klikamy prawym na localhost:3260 i z menu wybieramy Connect... (Rys. 2)

Wpisujemy nazwę użytkownika i hasło. W obu przypadkach będzie to „test”.

Ponownie klikamy prawym na localhost:3260, ale tym razem z opcji dostępnych w menu wybieramy Add Device (Rys. 3).

W oknie Device type selection upewniamy się, że zaznaczone jest Image File device (Rys. 4) i przechodzimy do następnego ekranu.

Zaznaczamy Create new image (Rys. 5) i klikamy Next.

W oknie ImageFile image parameters (Rys. 6) wybieramy lokalizację i nazwę pliku, oraz określamy jego wielkość.

Na potrzeby tego artykułu utworzymy dwa dyski na C:\. Disk1.img i Disk2.img o wielkości proponowanej przez program, czyli 256MB. Oczywiście nic nie stoi na przeszkodzie, aby dyski były mniejsze/większe. Zależy to od tego, co i jak chcemy testować.

W polu Specify new image name podajemy więc ścieżkę i nazwę pliku tworzącego pierwszy dysk: C:\Disk1.img.

Upewniamy się, że w dostępnych opcjach zaznaczone jest tylko Flat image file i klikamy Next (Rys. 6).

W następnym oknie, oprócz już wybranego Asyncronous mode (zapewne chodziło o „Asynchronous”), zaznaczamy dodatkowo Allow multiple concurrent iSCSI connections (clustering) i przechodzimy dalej (Rys. 7).

Akceptujemy standardowe ustawienia w pozostałych oknach i kończymy procedurę tworzenia nowego dysku.

Powtarzamy cały proces, tym razem tworząc Disk2.img.

Jest to również koniec konfiguracji naszego celu iSCSI. Główne okno StarWind powinno teraz wyglądać tak jak na Rys. 8.

Dodajemy regułę zapory na kontrolerze

Aby zminimalizować ilość serwerów w środowisku testowym, zainstalowaliśmy emulator iSCSI na kontrolerze domeny.

Jednak wiąże się to z koniecznością otwarcia dwóch dodatkowych portów dla ruchu przychodzącego. Chodzi o standardowy port na którym działa iSCSI, czyli TCP 3260 i port kanału kontrolnego StarWind, TCP 3261. Alternatywą jest całkowite wyłączenie zapory na DC, co, biorąc pod uwagę cel artykułu, byłoby całkowicie dopuszczalne.

Utworzenie nowej reguły nie zajmuje zbyt wiele czasu, więc opiszemy ten proces. Po co wyłączać zaporę, skoro nie jest to konieczne?

Uruchamiamy konsolę Windows Firewall with Advanced Security znajdującą się w Administrative Tools. Po kliknięciu na Inbound Rules zostanie wyświetlona lista reguł zapory (Rys. 9).

Z prawej strony konsoli klikamy na New Rule.

W pierwszym oknie kreatora New Inbound Rule Wizard, wybieramy typ reguły. Nasza będzie typu Port, a więc właśnie tę opcję zaznaczamy i przechodzimy dalej (Rys. 10).

W oknie Protocol and Ports wybieramy protokół TCP, a w polu Specific local ports wpisujemy interesujące nas porty rozdzielone przecinkiem „3260, 3261” (bez cudzysłowów). Klikamy Next (Rys. 11).

Następne okna kreatora konfigurujemy odpowiednio:
Action: Allow the connection.
Profile: Domain i Private. Możemy odznaczyć profil Public.
Name: StarWind iSCSI.
Kończymy tworzenie nowej reguły, klikając w Finish.

Możemy też posłużyć się programem netsh i utworzyć naszą regułę znacznie szybciej, wklejając poniższą linijkę w CMD.

netsh advfirewall firewall add rule name=”StarWind iSCSI” protocol=TCP dir=in localport=3260,3261 action=allow

To już właściwie wszystkie czynności jakie w naszym przykładzie musimy wykonać na kontrolerze domeny, potrzebne do utworzenia klastra.

Węzły (Nodes)

Instalujemy dwa serwery Windows Server 2008 Enterprise Edition. Będą to oczywiście węzły naszego klastra.

Dokonujemy podstawowych czynności konfiguracyjnych, takich jak zmiana nazwy komputera, konfiguracja protokołu TCP/IP dla obu kart, członkostwo w domenie. Podobnie jak w przypadku kontrolera domeny, tak i tutaj wykorzystamy i skonfigurujemy dwa połączenia sieciowe.

Jedno do komunikacji z „publicznym” LANem, a drugie zarezerwowane dla ruchu iSCSI. W środowisku produkcyjnym, takie połączenie powinno być odizolowane od innego ruchu sieciowego przy pomocy np. dedykowanego, jak najszybszego przełącznika sieciowego.

Konfiguracja połączeń sieciowych węzłów w naszym przykładzie będzie wyglądała następująco:

Nazwa: NODE01
LAN: 
IP: 192.168.10.2/24
Derfault Gateway: 192.168.10.1
DNS: 192.168.10.1
iSCSI: 
IP: 10.1.1.2/8

Nazwa: NODE02
LAN: 
IP: 192.168.10.3/24
Derfault Gateway: 192.168.10.1
DNS: 192.168.10.1
iSCSI:
IP:  10.1.1.3/8

Na obu serwerach, podaliśmy adres IP kontrolera domeny jako domyślną bramę. W naszym przypadku jest to zabieg czysto kosmetyczny, gdyż podczas późniejszego testowania konfiguracji, test odpowiedzialny za walidację konfiguracji IP, zgłosiłby jej brak i w rezultacie skończyłoby się to ostrzeżeniem, a my przecież tak bardzo lubimy zielony kolor w raportach.

Dodajemy oba serwery do wcześniej utworzonej domeny. Wszystkie węzły klastra powinny znajdować się w tej samej OU. Standardowo konta w domenie zostaną utworzone w kontenerze Computers, więc to zalecenie nie wymaga od nas wykonania żadnych dodatkowych czynności, o ile wcześniej, z jakichś powodów, nie rozdzieliliśmy obu kont.

Konfiguracja iSCSI Initiator

Do konfigurowania połączeń z wykorzystaniem iSCSI, w Windows Server 2008 służy program iSCSI Initiatior, do którego skrót znajdziemy w narzędziach administracyjnych. Start - Administrative Tools - iSCSI Initiator.

Zanim otrzymamy możliwość zapoznania się z jego zawartością, zostaniemy poinformowani o tym, że usługa Microsoft iSCSI nie jest uruchomiona i że jest ona niezbędna do poprawnego działania iSCSI (Rys. 12).

Klikając na Yes, zgadzamy się na włączenie usługi i jej automatyczny start podczas każdego następnego uruchomienia systemu.

Od razu zostanie nam przedstawiony kolejny komunikat z zapytaniem, czy chcemy odblokować wcześniej wspomnianą usługę i umożliwić jej komunikację z protokołem iSNS (Internet Storage Name Service). Protokół ten pozwala automatycznie wyszukiwać, zarządzać i konfigurować urządzenia iSCSI. Zgadzamy się, klikając na Yes (Rys. 13).

W iSCSI Initiator musimy odwiedzić minimum dwie zakładki. Są nimi Discovery i Targets. Na zakładce Discovery podajemy adres celu iSCSI. Będzie to adres IP kontrolera domeny, z połączenia sieciowego, które chcemy zarezerwować dla ruchu iSCSI, czyli w naszym przykładzie 10.1.1.1. Klikamy „Add Portal” i wpisujemy 10.1.1.1 (Rys. 14).

Następnie przechodzimy do zakładki Targets (Rys. 15).. Powinny być na niej widoczne dwa cele (Targets), czyli utworzone przez nas wcześniej dyski. W innym przypadku spróbujmy odświeżyć widok przy pomocy dostępnego przycisku Refresh.

Logujemy się do każdego z nich klikając na Log on.... W rezultacie otworzy się okno Log On to Target (Rys. 16). Zaznaczamy w nim opcję Automatically restore this connection when the computer starts.

Status naszych celów (dysków) powinien zmienić się z Inactive na Connected.

Powyższe czynności przeprowadzamy na wszystkich serwerach, które planujemy wykorzystać jako węzły w klastrze, a więc w tym konkretnym przypadku będą to NODE01 i NODE02.

Zarządzanie dyskami

Po pomyślnym podłączeniu się do dysków z poziomu iSCSI Initiatora, musimy je uaktywnić w systemie. Na serwerze NODE01 uruchamiamy Server Managera i przechodzimy do modułu Storage - Disk Management.

W oknie zarządzania dyskami powinny być widoczne oba dodane przez nas wcześniej dyski. Klikamy prawym przyciskiem na pierwszym z nich i z menu wybieramy Online (Rys. 17).

Następnie ponownie otwieramy menu, klikamy na Initialize Disk. Na koniec tworzymy na dysku wolumin NTFS, korzystając z kreatora i akceptując proponowane przez niego ustawienia (Rys. 18).

Te same czynności wykonujemy także dla drugiego dysku.

Na drugim serwerze (NODE02) przechodzimy do modułu Disk Management i, podobnie jak w przypadku konfiguracji NODE01, klikamy prawym przyciskiem na dyskach, z menu wybierając Online (Rys. 17).

Konfiguracja „Failover Clustering”

Do zarządzania klastrami w Windows Server 2008, służy konsola Failover Cluster Management. Uzyskamy do niej dostęp po dodaniu odpowiedniej funkcjonalności.

W tym celu, w konsoli Server Manager na obu węzłach, klikamy prawym na Features i z menu wybieramy Add Features. W dostępnej liście zaznaczamy Failover Clustering (Rys. 19), następnie Next i Install.

Na NODE01 uruchamiamy przystawkę zarządzania klastrami. Start - Administrative Tools - Failover Cluster Management.

Możemy z jej poziomu zarządzać usługą klastrowania. Dodawać i usuwać serwery (węzły), dyski, zmieniać konfigurację quorum, czy też określać które usługi i aplikacje będą dostępne na klastrze (Rys. 20).

Jednym z pierwszych kroków jakie powinniśmy tutaj wykonać, jest walidacja komponentów na których zainstalujemy nasz klaster. W tym celu został stworzony specjalny kreator, który uruchomimy klikając na Validate a Configuration... w środkowej części konsoli (Rys 20).

W kreatorze dodajemy dwa serwery: NODE01 i NODE02 (Rys. 21)

i wykonujemy wszystkie testy, czyli w oknie Testing Options zostawiamy zaznaczoną opcję Run all tests (recommended). W następnym oknie (Confirmation) możemy przejrzeć wybrane przez nas wcześniej opcje i klikając w Next, urchomić fazę testów (Rys. 22).

Jeżeli poprawnie wykonaliśmy poprzednie etapy, to po kilku minutach testy powinny zakończyć się pełnym sukcesem, a w oknie podsumowującym przeczytamy: „Testing has completed successfully and the configuration is suitable for clustering” (Rys.23).

A więc wszystkie testy zakończone powodzeniem, co oznacza, że nasz klaster będzie supportowany przez MS i że możemy oczekiwać jego bezproblemowej konfiguracji i działania. Klikając w View Report... obejrzymy Failover Cluster Validation Report, który zawiera dość pokaźną listę wszystkich wykonanych testów wraz z informacjami o tym, co konkretnie było testowane.

W przypadku gdy któreś testy zakończą się niepowodzeniem, nie musi to wcale oznaczać, że nasz klaster nie będzie działał. Jednak trzeba liczyć się z tym, że w przypadku późniejszych, potencjalnych problemów z klastrem, taka konfiguracja nie będzie się kwalifikowała do technicznego wsparcia.

My jednak działamy w środowisku nie dość że testowym, to jeszcze wirtualnym, a więc problem z brakiem wsparcia jest dla nas problemem czysto teoretycznym.

Oczywiście możemy przyjrzeć się bliżej testom zakończonym niepowodzeniem i dokonać odpowiednich poprawek w konfiguracji środowiska, w którym ma działać nasz klaster, a następnie ponownie przeprowadzić wszystkie testy.

Konfiguracja klastra

Testy za nami, czas na instalację klastra. Teraz przekonamy się jak maksymalnie uproszczony został sam proces jego tworzenia.

Zanim zaczniemy, jeszcze drobna uwaga. Aby utworzyć klaster w domenie, nie potrzebujemy praw członka grupy Domain Admins. Wystarczy, że będziemy posiadali prawa lokalnego administratora na każdym serwerze, który zechcemy dodać do naszego klastra i dodatkowo, prawo tworzenia kont komputerów w domenie.

Na serwerze NODE01, w konsoli Failover Cluster Management klikamy na Create Cluster…. W oknie Select Servers dodajemy serwery, które mają pełnić role węzłów (NODE01 i NODE02).

Po przejściu do następnego okna (Access Point for Administering the Cluster), wybieramy nazwę i adres IP klastra (Rys. 24).

To właściwie wszystkie informacje jakie musimy wprowadzić. Kliknięcie na Next w oknie Confirmation rozpocznie proces tworzenia klastra.

Po zakończeniu pracy kreatora możemy oczywiście przejrzeć raport w którym opisane są poszczególne czynności składające sie na proces instalacji klastra.

Przyjrzyjmy się teraz ponownie konsoli Failover Cluster Management, gdyż na tym etapie wzbogaciła się co nieco jej zawartość (Rys. 25).

Możemy już zarządzać węzłami, dyskami i sieciami w klastrze, jednak nie świadczy on tak naprawdę jeszcze żadnych usług w sieci.

Po wyświetleniu zawartości modułu Storage zauważymy, że pierwszy dysk pełni rolę „Witness Disk” w obecnie skonfigurowanym modelu Quorum, a drugi jest na liście dostępnych do wykorzystania zasobów.

Aby to całe klastrowanie (uważać na literówki ;-) ) miało sens, a wysoka dostępność przekładała się na wymierne korzyści, musimy skonfigurować jakąś usługę lub aplikację, która będzie potrafiła z tego skorzystać. Na przykład serwer plików.

W konsoli Failover Cluster Management, klikamy prawym na Services and Applications i z menu wybieramy Configure a Service or Application…

W kreatorze High Availability Wizard zaznaczamy File Server i klikamy Next (Rys. 26).

Określamy nazwę naszego serwera plików i adres IP (Rys 27).

W oknie Select Storage zaznaczamy jedyny dostępny dysk i klikamy Next, następnie pozwalamy kreatorowi skonfigurować wysoko dostępny serwer plików.

Pozostaje nam już tylko udostępnić zasoby użytkownikom.

W tym celu uruchamiamy konsolę Failover Cluster Management na NODE02 i klikając prawym na KlasterFS, z menu wybieramy Add a shared folder.

Klikamy Browse... i tworzymy nowy katalog (Rys. 28).

Następnie konfigurujemy kolejne okna kreatora według własnych potrzeb. Są to głównie prawa dostępu do udziału i prawa NTFS.

Ponieważ założyliśmy katalog o nazwie „Users”, do udostępnionych zasobów klastra dostaniemy się wpisując \\KlasterFS\Users.

Aby przetestować naszą konfigurację w boju, możemy np. otworzyć jakiś plik znajdujący się w katalogu Users, a następnie wyłączyć serwer NODE02. Kontrolę nad naszym KlasterFS powinien po kilku sekundach przejąć NODE01.

Cały opisany powyżej proces, zakładając, że serwery ze skonfigurowanymi interfejsami należą już do domeny, zajmuje niecałe 10 minut z czego lwia część, to opisany wcześniej test konfiguracji.

Na koniec pozostaje mi już tylko życzyć owocnej zabawy i udanych eksperymentów z klastrami w systemie Windows Server 2008.