Użytkownicy biznesowi wymagają określonej dostępności usług, zazwyczaj mierzonej za pomocą procentowego udziału czasu, gdy można z niej skorzystać, do całego mierzonego czasu. Jeśli wymagana jest dostępność na poziomie 95%, oznacza to sumaryczny czas przerw zbliżony do 8h w ciągu tygodnia (czytaj - maksymalnie 8h na siedem dni pracy). Pojęcie dostępności usługi nie zawsze przekłada się bezpośrednio na czas pracy systemu operacyjnego i aplikacji (uptime). Na czas dostępności usługi wpływają wszystkie elementy odpowiedzialne za jej pracę, nie tylko serwery, systemy operacyjne i aplikacje, ale także infrastruktura sieciowa, składowanie danych, zasilanie, chłodzenie oraz systemy zapewniające bezpieczeństwo.

Należy przy tym rozróżnić pojęcie przerwy planowanej oraz awarii, czyli przerwy nieplanowanej. Niekiedy dana usługa pracuje okresowo, na przykład w określonych godzinach i tylko wtedy niezbędna jest jej niezawodność. Poza godzinami pracy dana usługa może nie działać w ogóle - przykładem mogą być urządzenia obsługujące linię produkcyjną cukrowni, pracującą jedynie podczas prowadzenia kampanii cukrowniczej. Podobne wymagania dotyczą pracy systemów kasowych w supermarketach - gdy kasy są nieczynne, taką usługę można wyłączyć, w celu konserwacji bez szkód dla biznesu. W takich przypadkach biznes zazwyczaj wymaga dostępności na określonym poziomie (na przykład 99,9%) w ustalonych godzinach pracy.

Od zasilaczy do klastra

Systemy składają się z wielu pojedynczych podzespołów, z których każdy może ulec awarii, unieruchamiając większą lub mniejszą część systemu. Dlatego do osiągnięcia wysokiej dostępności stosuje się rozwiązania, które zmniejszają prawdopodobieństwo awarii w przypadku uszkodzenia pojedynczego elementu. Rozwiązania takie, stosowane z powodzeniem w wielu konstrukcjach, zakładają eliminacje pojedynczego punktu awarii dzięki nadmiarowości. Klasycznym przykładem jest stosowanie nadmiarowych (N+1) zasilaczy w urządzeniach, interfejsów sieciowych oraz niezależnych kompletów urządzeń aktywnych.

Pomimo radykalnego zmniejszenia prawdopodobieństwa całkowitego zatrzymania pracy komputera, nadal może wystąpić przerwa w pracy, spowodowana awarią oprogramowania. Problem ten w praktyce rozwiązuje się za pomocą klastra - zestawu dwóch niezależnych systemów, które razem przetwarzają dane (klaster active-active) lub jeden z nich oczekuje na awarię drugiego, aby przejąć jego zadania (klaster active-passive). Rozwiązania takie obecne są w większości baz danych (Oracle, DB2, Microsoft SQL Server, PostgreSQL, MySQL), w wielu systemach operacyjnych (AIX, Solaris, HP-UX, Linux, Windows i inne, włącznie z OpenVMS), macierzach dyskowych oraz serwerach aplikacyjnych. Najważniejszy problem dotyczy jednak zgodności aplikacji. Nie każda aplikacja będzie poprawnie pracowała w środowisku klastrowym.

Jak napisać program, by działał w klastrze

Aby aplikacja prawidłowo pracowała w klastrze, musi być pod tym kątem zaprojektowana. W szczególności powinna:

- wykorzystywać współdzielony zasób storage, na przykład NAS lub SAN. Jeśli jedynym miejscem składowania danych jest relacyjna baza danych, należy wybrać technologię, która natywnie wspiera pracę w klastrze, najlepiej z równoważeniem obciążenia

- przechowywać jak najwięcej informacji o swoim stanie w nieulotnym, współdzielonym zasobie

- móc się ponownie uruchomić na innym węźle klastra przy wykorzystaniu ostatniego stanu zapisanego we współdzielonym zasobie

- posiadać narzędzia do łatwego uruchomienia, kontrolowanego zatrzymania, wymuszenia zatrzymania oraz uzyskania informacji o swojej pracy. Zazwyczaj przekłada się to na posiadanie narzędzia pracującego w trybie wiersza poleceń, umożliwiającego użycie skryptów

- przy tym aplikacja nie może niszczyć żadnych danych w razie załamania, wymuszonego wyłączenia lub restartu od zapisanego stanu.

Jak widać, są to dość ostre wymagania i spełnienie ich jest trudne, dlatego fakt eksploatacji danej aplikacji w środowisku klastrowym najlepiej uwzględniać na początkowych etapach projektowania.