Dążenie do maksymalnej, blisko stuprocentowej dostępności aplikacji wymaga ogromnych nakładów na specjalizowany sprzęt. Zbliżone rezultaty - z przestojami rzędu minut w skali roku - można osiągnąć przy zastosowaniu standardowych komponentów sprzętowych i technologii klastrowej.

Hewlett-Packard

Hewlett-Packard oferuje działającą na poziomie systemu operacyjnego technologię klastrową MC/Serviceguard. Rozwiązanie to pozwala na tworzenie wysoko dostępnych klastrów typu failover, składających się maksymalnie z 16 węzłów, pracujących pod kontrolą systemu HP-UX w wersjach: 10.20, 11.0, 11i, 11.11i oraz 11.20 (dla platformy sprzętowej IA-64). Firma zapowiada, że w ciągu kilku najbliższych miesięcy oprogramowanie MC/Serviceguard zostanie zmo-dyfikowane w taki sposób, aby umożliwiać budowę klastrów składających się z 32 węzłów. Ostatnio Hewlett-Packard przeniósł swoje oprogramowanie klastrowe na Linuxa, jednak w ograniczonym zakresie. Wersja ta wspiera jedynie dystrybucję Red Hat i skaluje się "tylko" do 4 węzłów. Serwery pracujące w klastrze mogą różnić się pod względem konfiguracji sprzętowej, np. liczby proce- sorów czy ilości pamięci RAM, powinny jednak mieć tę samą wersję systemu ope- racyjnego.

Na każdym serwerze, wchodzącym w skład klastra, uruchamiany jest agent systemu MC/Serviceguard. Wykrywanie nieprawidłowości jest realizowane poprzez nieustanną wymianę komunikatów między agentami za pośrednictwem dedykowanego interfejsu sieciowego, co popularnie zwane jest heartbeat. HP zaleca, aby na potrzeby konfiguracji klastrowej każdy z serwerów wyposażyć w co najmniej 3 interfejsy sieciowe - jeden na potrzeby komunikacji heartbeat, jeden do obsługi komunikacji z siecią i jeden zapasowy.

Jeżeli jeden z węzłów nie odpowie w zadanym czasie na komunikat heartbeat, pozostałe serwery starają się upewnić, czy rzeczywiście uległ on awarii. W tym celu żądają od "podejrzanego" przesłania szczegółowych danych z logu systemowego i poddają je analizie według reguł określonych przez administratora. Jeżeli serwer wciąż nie odpowiada lub nadesłane dane szczegółowe przekraczają przyjęte wartości dopuszczalne, zostaje on przez pozostałe węzły uznany za niedostępny i rozpoczyna się procedura tworzenia nowego klastra - z pominięciem uszkodzonego węzła.

Wraz z oprogramowaniem klastrowym HP dostarcza konsolę administracyjną, pozwalającą modyfikować konfigurację klastra bez potrzeby wyłączania aplikacji - w tym dynamicznie dodawać lub odłączać węzły. Za pomocą konsoli można ustawiać częstotliwość wzajemnego "odpytywania" serwerów (przedział od kilku milisekund do kilku sekund), a także zakres i sposób interpretacji przesyłanych komunikatów. Możliwe jest także zaplanowanie scenariusza działań na wypadek awarii. Niedostępna aplikacja może być uruchamiana na serwerze wskazanym przez administratora lub też system sam wybiera dla niej najmniej obciążony węzeł, aby po przeniesieniu oprogramowania serwerowego na inny serwer fizyczny nie trzeba było rekonfigurować aplikacji klienckich. Rozwiązanie HP posługuje się wirtualnymi numerami IP, które są przypisywane nie serwerom, lecz aplikacjom.

Oprogramowanie MC/Serviceguard sprawdza się nie tylko w wielowęzłowych farmach - może być użyteczne również w przypadku typowej instalacji ze stosunkowo mocnym serwerem głównym i mniej wydajnym serwerem zapasowym. W razie awarii lub planowanego wyłączenia serwera głównego aplikacja zostanie przeniesiona na serwer mniej wydajny, a po usunięciu usterek automatycznie przeniesiona na serwer główny.

Hewlett-Packard przygotował także spec-jalizowane wersje oprogramowania klastrowego. MC/Serviceguard for Oracle Parallel Server służy do budowy klastrów bazodanowych Oracle na platformie HP-UX. W tym przypadku klaster może składać się z maksymalnie 2 węzłów, co wynika z ograniczeń po stronie mechanizmu Oracle Parallel Server (obecnie Real Application Cluster), działa- jącego w wyższej warstwie. Istnieje także specjalizowana wersja MC/Serviceguard dla aplikacji MQ Server, zarządzającej kolejkami w systemie SAP R/3, zwana Somer Sault. Jest to jedyne tego typu rozwiązanie. Za jego pomocą kolejki R/3 można replikować na maksymalnie 4 serwery.