Cluster Generic Application/Service Role

Z poprzednich postów wiemy jak już utworzyć klaster Failover’owy oraz usługę File Services. Nie jest to jednak szczyt możliwości klastrów. Jednym z bardziej istatnych elementów jest możliwość uwtorzenia prawie dowolnej aplikacji wysokiego dostępu. Dziś właśnie skupimy się na skonfigurowaniu prostej aplikacji typu klient/serwer jak np. stary dobry LANChat w ramach naszego klastra. Wiem, że nie jest to może zbyt dobry przykład, ale z racji prostoty działania może choć trochę pozwoli zobrazować zasadę pracy aplikacji w ramach wysokiego dostępu.

1. Zanim rozpoczniemy utworzymy sobie znów dodatkowy dysk iSCSI i podłączymy go do naszych węzłów. Robimy to analogicznie jak w punktach 1 i 2 poprzedniego artykułu.

iscsicli qlogintarget iqn.1991-05.com.microsoft:core-mydiskapptarget-target
DiskPart
List Disk
Select Disk 3
Attributes Disk Clear Readonly
Online Disk
Convert MBR
Create Partition Primary
Select Partition 1
Format FS=NTFS Quick
Assign Letter=G
Exit
PS> Get-ClusterAvailableDisk
PS> Get-ClusterAvailableDisk | Add-ClusterDisk

2. Kopiujemy (lub instalujemy) naszą aplikację na dysku iSCSI taka by była ona zawsze dostępna dla obu węzłów. Jeżeli będziemy instalować aplikacje lokalnie na węzłach musimy zadbać, aby były one dostępne pod tą samą ścieżką inaczej w razie odcięcia jednego z węzłów klaster będzie miał problem z wystartowaniem aplikacji na drugim węźle.

3. Ostatnim zabiegiem jest dodanie aplikacji do naszego klastra.

Add-ClusterGenericApplicationRole -CommandLine G:\LANChatPro\LANChat.exe -Storage "Cluster Disk 3" -Name Chat -StaticAddress 10.10.1.13

Jak widzimy proces aplikacji działa tylko na węźle który w danym momencie jest właścicielem aplikacji.

Uwaga! Sama aplikacja jest uruchamiana w uprawnieniami Systemu, dlatego jeśli chodzi o samego LANChata konieczna jest drobna modyfikacja rejestrów, aby nie prosił o podanie konfiguracji dla nowego użytkownika. Konfigurację tą pominę, gdyż jest mało istotna w prezentacji możliwości klastra.

4. Czas na symulację – standarowo generujemy awarę poprzez odłanczenie kabla sieciowego od węzła, który jest obecnie właścicielem procesu aplikacji serwerowej.

I po kilku sekundach widzimy, iż na drugim węźle został uruchomiony nowy proces naszego serwera. Tak samo w aplikacji widzimy, iż na kilka sekund zamilkła by zaraz za chwilę znów odpowiedzieć.

Niestety jakby na to nie patrzeć jest to nowy proces, więc mimo, iż aplikacja jest dostępna w dość krótkim czasie po awarii, to jednak wszelkie niezapisane dane zostaną utracone. Inny problem to gdy aplikacje kliencie nie będą obsługiwały automatycznego wznowienia połączenia to konieczne będzie ręczne wymuszenie połączenia lub czasem nawet restart aplikacji klienckiej.

Bardzo podobnie jak przy aplikacjach wygląda proces tworzenie dowolnej usługi wysokiego dostępu.

Aby to przetestować usuwamy aplikację LANChat z zasobów grupy klastra.

Oraz tak na szybko preparujmy sobie, aby nasz LANChat pracował jako usługa na obu węzłach przy użyciu srvany.exe z pakietu Windows NT Resource Kit.

sc create LANChat binPath= "C:\Windows\System32\srvany.exe" displayName= LANChat
Reg Add HKLM\System\CurrentControlSet\Services\LANChat\Parameters /v Application /t REG_SZ /d G:\LANChatPro\LANChat.exe

I dodajemy naszą usługę jako usługę wysokiego dostępu.

PS> Add-ClusterGenericServiceRole -ServiceName LANChat -Storage "Cluster Disk 3" -StaticAddress 10.10.1.13

Jak widzimy czy to usługa czy aplikacja zasada działania jest wręcz identyczna.

Źródło:
http://technet.microsoft.com/en-us/library/ee461009.aspx

Advertisements

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s