Na każdym z węzłów klastra Veritas umieszcza komponent, którego rolą jest ciągłe śledzenie zachowań pozostałych węzłów klastra. Fir- ma dostarcza oprogramowanie administracyjne, umożliwiające szczegółowe określenie częstotliwości wymiany komunikatów heartbeat, zakresu sprawdzanych parametrów oraz warunków rozpoczęcia procedury fail over. Podczas konfiguracji klastra należy oznaczyć moc przetwarzania każdego węzła oraz określić, ile zasobów systemowych będą zużywać konkretne aplikacje. Ponadto dla każdej aplikacji administrator musi podać preferowane serwery zastępcze oraz reguły ewentualnego powrotu aplikacji do serwera macierzystego. Możliwy jest także scenariusz, w którym na podstawie wszystkich parametrów łącznie oprogramowanie klastrowe samo zadecyduje, który serwer powinien przejąć unieruchomione zasoby.

W przypadku małej liczby węzłów komunikacja w trybie heartbeat jest realizowana za pomocą protokołu IP. Gdy liczba węzłów przekracza 4, Veritas zaleca użycie samodzielnie opracowanych, wydajnych siecio-wo protokołów LLT (Low Latency Transport) i GAB. Pierwsza przerwa w komunikacji z reguły nie powo- duje reakcji systemu. Jeżeli serwer nadal nie odpowiada, pozostałe serwery wysyłają do niego żądanie podania istotnych parametrów pracy, które mogłyby okazać się pomocne w stwierdzeniu, co tak naprawdę się z nim dzieje. Jeżeli serwer wciąż nie odpowiada za pośrednictwem ustalonego kanału komunikacji, serwery aktywne próbują wymusić reakcję w sposób pośredni, resetując jego dostęp do magistrali SCSI. Jeżeli serwer nie zgłosi w określonym czasie żądania rezerwacji kanału SCSI, pozostałe przyjmują, że uległ on awarii i rozpoczynają procedurę odbudowy klastra bez jego udziału. W tym celu wyznaczają spośród siebie "arbitra", którego zadaniem jest odcięcie "zawieszonego" ser- wera od wszystkich przypisanych mu zasobów, sformowanie nowego klastra oraz odbudowa wyłączonych zasobów.

Microsoft

Klastry pojawiły się po raz pierwszy w ofercie Microsoftu wraz z premierą Windows NT 4.0 Enterprise Edition. Już wtedy firma zadecydowała, że swoje rozwiązania będzie budować w architekturze shared nothing. Oznacza to, że węzły wchodzące w skład klastra nie współdzielą zasobów w rozumieniu jednoczesnego dostępu do nich - każdy serwer działa w pełni samodzielnie. Podejście to zostało utrzymane także w Microsoft Cluster Services w systemie Windows 2000 Advanced Server, pozwalającym budować klastry dwuwęzłowe, oraz Windows 2000 Datacenter Server, za pomocą którego możliwe jest tworzenie instalacji składających się z maksymalnie 4 serwerów.

Jedynym obszarem wspólnym dla wszystkich węzłów klastra tworzo-nego za pomocą Microsoft Cluster Services jest tzw. dysk quorum - wydzielony na wspólnej macierzy dyskowej dysk logiczny, na którym jest przechowywana główna baza konfiguracyjna klastra, pliki log oprogramowania klastrowego oraz procedury fail over. Dysk quorum jest także podstawowym zasobem klastra w momencie wystąpienia awarii jednego z węzłów. Prawo do rozpoczęcia procedury formowania nowego klastra ma bowiem tylko jeden serwer - ten, który pierwszy zdoła przejąć kontrolę nad dyskiem quorum. Pozostałe serwery mają prawo pozostać w klastrze tylko wtedy gdy są w stanie komunikować się z węzłem kontrolującym dysk quorum. Taka konstrukcja jest od dawna obecna w rozwiązaniach większości producentów rozwiązań klastrowych. Ma ona na celu zapobieganie sytuacji, w której po awarii jednego węzła formowałyby się dwa lub większa liczba oddzielnych klastrów, próbujących jednocześnie uruchamiać te same zasoby, co prowadziłoby do chaosu i długotrwałej niedostępności serwisów.

Usługi Microsoft Cluster Services wyposażono w dwa mechanizmy wykrywania awarii. Pierwszy z nich to heartbeat, czyli komunikaty wymieniane przez komponenty klastrowe na wszystkich węzłach. Jeżeli serwer nie odpowie na wywołanie typu heartbeat, Log Manager automatycznie zapisuje zmiany w jego lokalnej bazie konfiguracyjnej do centralnej bazy na dysku quorum. Dzięki temu podczas odtwarzania zasobów nowy serwer będzie mieć dostęp do najbardziej aktualnych danych. Drugi mechanizm ma charakter hierarchiczny i służy do wykrywania awarii na poziomie zasobów. Jego sercem jest Resource Manager - menedżer zasobów, który każdemu zasobowi przydziela oddzielny proces kontrolny - Resource Monitor. Jego zadaniem jest sprawdzanie - z określoną przez administratora częstotliwością - stanu zasobu i raportowanie wszelkich zmian do Resource Managera. Stamtąd dane trafiają do Fail Over Managera - komponentu, który porównuje zaistniałe zdarzenia z listą zdarzeń określonych przez administratora jako wystarczające do wszczęcia procedury fail over. Jeżeli oprogramowanie uzna, że awaria rzeczywiś-cie zaistniała, usługa jest wyłączana i włączana ponownie. Jeżeli kilkakrotne próby nie dadzą pozytywnych rezultatów, serwer udostępniający tę usługę jest wykluczany z klastra, po czym następuje odbudowa klastra z jego pominięciem i odbudowa jego usług na innym serwerze.