Kilka przykładów konfiguracji wraz z komentarzem

Najprostsza konfiguracja w której określono jedynie nazwę komputera pełniącego rolę wezła głównego (node1.mojklaster.org i adres IP klastra. Maska podsieci i adres rozgłoszeniowy jest domyślny. Klaster nie udostępnia żadnych usług.

W powyższym przykładzie nie jest określna nazwa interfejsu, któremu zostanie przypisany wirtualny adres klastra. Nie jest to problemem w przypadku maszyn z pojedynczą kartą sieciową. Wybór interfejsu sieciowego w systemie z wieloma kartami, dokonywany jest na podstawie tablicy routingu. Heartbeat stara się znaleźć najkrótszą ścieżkę do adresu, który przejmuje. Dla większości systemów jest to pierwsza pozycja w tabeli.

Podobnie jak poprzednio, ale klaster już serwuje wysoko dostępną usługę WWW:

Nazwa usługi podana na końcu linii jest w zasadzie niczym innym jak nazwą skryptu uruchamiającego serwer http. heartbeat w poszukiwaniu tego skryptu sprawdza kolejno ścieżki: /etc/ha.d/resource.d i /etc/rc.d/init.d. Z punktu widzanie heartbeat'a bez znaczenia jest co dany skrypt robi, istotne jest jedynie aby poprawne były wywołania: scriptname start i scriptname stop, wykonywane odpowiednio podczas startu i zatrzymaywania usługi. Jeżeli chcemy przekazać do skryptu argumenty należy je podać po jego nazwie oddzielające :: np.

Przykład bardziej złożony: klaster jest dostępny pod trzema adresami i udostępnia dwie usługi.

Pełnia precyzji w definiowaniu interfejsu sieciowego: adres, maska podsieci, interfejs sieciowy i adres rozgłoszeniowy.

Wykorzystanie współdzielonego zasobu dyskowego. Dysk SCSI reprezentowany przez urządzenie /dev/sda1 będzie widoczny w katalogu /data1, zapisany jest w systemie plików ext2.

W momencie awarii węzła głównego, skrypt Filesystem (dostarczany wraz z pakietem heartbeat, znajduje się w katalogu /etc/ha.d/resource.d) uruchomiony przez demona na węźle zapasowym zamontuje urządzanie /dev/sda1 w katalogu /data1. Niestety korzystanie z dzielonego zasobu wiąże się z ryzykiem, że nie do końca ,,martwy'' węzeł główny zachowa sobie dostęp do dzielonego zasobu. O rozwiązaniu tego problemu traktuje rozdział 1.4.