W klastrze pracy awaryjnej można skonfigurować szereg różnych usług lub aplikacji w celu uzyskania wysokiej dostępności. Aby uzyskać listę usług lub aplikacji najczęściej konfigurowanych w celu uzyskania wysokiej dostępności, zobacz Konfigurowanie wysokiej dostępności usługi lub aplikacji.

Ten temat zawiera następujące sekcje:

Usługi lub aplikacje, które można uruchomić jako aplikację ogólną, skrypt rodzajowy lub usługę ogólną

W klastrach pracy awaryjnej za pomocą opcji Aplikacja ogólna, Skrypt rodzajowy i Usługa ogólna można konfigurować wysoką dostępność dla niektórych usług i aplikacji, które nie obsługują klastrów (nie zostały zaprojektowane do uruchamiania w klastrze, czyli nie są typu cluster-aware).

Aplikacja ogólna

W przypadku uruchomienia aplikacji jako aplikacji ogólnej oprogramowanie klastra uruchomi tę aplikację, a następnie będzie okresowo sprawdzać w systemie operacyjnym, czy aplikacja jest uruchomiona. Jeśli jest, zostanie przyjęte założenie, że aplikacja jest dostępna, i nie będzie ona ponownie uruchamiana ani przełączana w tryb pracy awaryjnej.

Warto zauważyć, że w porównaniu do aplikacji typu cluster-aware aplikacja ogólna ma mniej sposobów komunikowania swojego dokładnego stanu oprogramowaniu klastra. Jeśli aplikacja ogólna wejdzie w stan problematyczny, ale mimo wszystko pozostanie uruchomiona, oprogramowanie klastra nie ma sposobu na odkrycie tego i podjęcie działania (takiego jak ponowne uruchomienie aplikacji czy przełączenie jej w tryb pracy awaryjnej).

Przed uruchomieniem Kreatora wysokiej dostępności w celu skonfigurowania wysokiej dostępności dla aplikacji ogólnej należy się upewnić, że jest znana ścieżka aplikacji oraz nazwy wszelkich kluczy rejestru gałęzi HKEY_LOCAL _MACHINE wymaganych przez tę aplikację.

Skrypt rodzajowy

Można utworzyć skrypt uruchamiany w hoście skryptów systemu Windows, który monitoruje i kontroluje aplikację. Następnie można skonfigurować ten skrypt w klastrze jako skrypt rodzajowy. Skrypt udostępnia oprogramowaniu klastra informacje na temat bieżącego stanu aplikacji. W razie potrzeby oprogramowanie klastra ponownie uruchomi ten skrypt lub przełączy go w tryb pracy awaryjnej (co zarazem spowoduje ponowne uruchomienie aplikacji lub przełączenie jej w tryb pracy awaryjnej).

Po skonfigurowaniu skryptu rodzajowego w klastrze pracy awaryjnej możliwość precyzyjnego odpowiadania przez oprogramowanie tego klastra na stan aplikacji jest określona przez ten skrypt. Im precyzyjniej skrypt będzie udostępniał informacje o stanie aplikacji, tym precyzyjniej oprogramowanie klastra będzie mogło reagować na te informacje.

Przed uruchomieniem Kreatora wysokiej dostępności w celu skonfigurowania wysokiej dostępności dla skryptu rodzajowego należy się upewnić, że jest znana ścieżka skryptu.

Usługa ogólna

Oprogramowanie klastra uruchomi usługę, a następnie będzie okresowo sprawdzać w Kontrolerze usługi (funkcji systemu operacyjnego), czy usługa jest uruchomiona. Jeśli jest, zostanie przyjęte założenie, że usługa jest dostępna, i nie będzie ona ponownie uruchamiana ani przełączana w tryb pracy awaryjnej.

Warto zauważyć, że w porównaniu do usługi typu cluster-aware Usługa ogólna ma mniej sposobów komunikowania swojego dokładnego stanu oprogramowaniu klastra. Jeśli Usługa ogólna wejdzie w stan problematyczny, ale mimo wszystko jest uruchomiona, oprogramowanie klastra nie ma sposobu na odkrycie tego i podjęcie działania (takiego jak ponowne uruchomienie usługi czy przełączenie jej w tryb pracy awaryjnej).

Przed uruchomieniem Kreatora wysokiej dostępności w celu skonfigurowania wysokiej dostępności dla usługi ogólnej należy się upewnić, że jest znana nazwa usługi w takiej postaci, w jakiej jest wyświetlana w gałęzi rejestru HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.

Podstawowe wymagania dotyczące usługi lub aplikacji w środowisku klastra pracy awaryjnej

Aby usługa lub aplikacja była odpowiednia dla klastra pracy awaryjnej, musi mieć pewne cechy. Najistotniejsze cechy:

  • Usługa lub aplikacja powinna być stanowa. Innymi słowy, usługa lub aplikacja powinna mieć długotrwały stan w pamięci lub stany dużych, często aktualizowanych ilości danych. Przykładem jest aplikacja bazy danych. W przypadku aplikacji bezstanowej (takiej jak fronton serwera sieci Web) prawdopodobnie bardziej odpowiednia niż klaster pracy awaryjnej będzie funkcja równoważenia obciążenia sieciowego.

  • Usługa lub aplikacja powinna używać składnika klienta, który automatycznie ponawia próby po tymczasowych przerwach w łączności sieciowej. W przeciwnym przypadku, jeśli składnik serwera aplikacji zostanie przejęty awaryjnie z jednego serwera klastrowanego przez inny serwer, nieuchronna (lecz krótka) przerwa w łączności spowoduje, że klienci zostaną zatrzymani (nie będą ponawiać prób ani łączyć się ponownie).

  • Usługa lub aplikacja powinna mieć możliwość identyfikowania używanych przez siebie dysków. Dzięki temu usługa lub aplikacja będzie mogła komunikować się z dyskami w magazynie klastra i niezawodnie znajdować odpowiedni dysk nawet po rozpoczęciu pracy w trybie awaryjnym.

  • Usługa lub aplikacja powinna używać protokołów opartych na protokole IP. Przykłady takich protokołów to TCP, UDP, DCOM, nazwane potoki i RPC przez TCP/IP.

Dodatkowe informacje

Spis treści