Prawidłowo – funkcja failover w usłudze DHCP służy właśnie do skonfigurowania zapasowego serwera DHCP i zapewnienia wysokiej dostępności przydzielania adresów IP. W praktyce chodzi o to, żeby w sieci zawsze był przynajmniej jeden serwer zdolny do odpowiadania na żądania DHCPDISCOVER i DHCPREQUEST od klientów. Jeśli serwer główny ulegnie awarii, to drugi – partnerski – przejmuje jego rolę zgodnie z ustalonym wcześniej trybem pracy. Najczęściej stosuje się model load balance (obciążenie dzielone mniej więcej po równo) albo hot-standby (jeden serwer aktywny, drugi w gotowości). W systemach takich jak Windows Server konfiguracja failover polega na powiązaniu konkretnego zakresu (scope) z drugim serwerem DHCP, uzgodnieniu wspólnego stanu bazy dzierżaw (leases), ustawieniu czasu MCLT (Maximum Client Lead Time) i parametrów typu state switchover. Dzięki temu oba serwery mają zsynchronizowane informacje o tym, które adresy są już przydzielone, więc nie dochodzi do konfliktów IP. Z punktu widzenia dobrych praktyk sieciowych, w sieciach produkcyjnych – szczególnie w firmach, gdzie przerwa w działaniu sieci jest kosztowna – failover DHCP to praktycznie standard. Nie opiera się już na starym modelu split-scope (rozbijanie puli na dwie części ręcznie), tylko na mechanizmie opisanym w RFC 2131 i rozszerzeniach producentów, gdzie serwery regularnie wymieniają komunikaty o stanie dzierżaw. Moim zdaniem warto pamiętać, że failover nie tylko daje „zapasowy serwer”, ale też poprawia ciągłość działania przy konserwacjach, aktualizacjach i restartach – można spokojnie wyłączyć jeden serwer, a klienci dalej dostają adresy IP z drugiego, bez paniki w sieci.
W pytaniu chodzi konkretnie o mechanizm failover w usłudze DHCP, czyli o rozwiązanie wysokiej dostępności, a nie o zwykłe funkcje administracyjne serwera. Łatwo tu się pomylić, bo wiele osób kojarzy DHCP ogólnie z zarządzaniem adresami, filtrowaniem czy podglądem statystyk i wrzuca wszystko do jednego worka. Warto to sobie uporządkować. Filtrowanie adresów MAC to osobny moduł w serwerach DHCP. Pozwala definiować listy dozwolonych lub blokowanych klientów na podstawie ich adresu fizycznego karty sieciowej. To mechanizm bardziej z pogranicza prostego bezpieczeństwa i kontroli dostępu, ale nie ma nic wspólnego z redundancją czy przejmowaniem pracy serwera. Nawet jeśli MAC filtering jest konfigurowany na więcej niż jednym serwerze, to nadal nie jest to failover – to po prostu identyczna konfiguracja filtrów w kilku miejscach. Rezerwacje adresów IP to kolejny, odrębny temat. Dzięki nim można przypisać konkretny adres IP do określonego klienta (najczęściej właśnie po MAC), tak aby zawsze dostawał ten sam adres. To jest bardzo przydatne np. dla drukarek sieciowych, serwerów plików czy urządzeń IoT, ale celem jest przewidywalność adresacji, a nie zapewnienie ciągłości działania w razie awarii samego serwera DHCP. Nawet idealnie ustawione rezerwacje nie spowodują, że drugi serwer automatycznie przejmie obsługę, jeśli pierwszy padnie. Wyświetlanie statystyk serwera DHCP to typowa funkcja monitorująca. Administrator może sprawdzić, ile dzierżaw jest aktywnych, ile adresów zostało wolnych w danym zakresie, jakie są błędy, itp. To ważne z punktu widzenia diagnostyki i planowania pojemności puli adresów, ale nadal nie ma to charakteru mechanizmu HA. Typowy błąd myślowy polega na tym, że skoro coś „pomaga adminowi”, to ludzie uznają to za funkcję krytyczną jak failover – a to tylko narzędzie podglądowe. Sam failover DHCP polega na współpracy dwóch serwerów nad tą samą pulą adresów i wymianie informacji o dzierżawach, tak aby w razie awarii jednego klient dalej mógł pobierać lub odnawiać adres na drugim. Czyli jego sednem jest konfiguracja zapasowego serwera DHCP oraz mechanizmów synchronizacji, a nie filtrowanie, rezerwacje czy statystyki. Z mojego doświadczenia dobrze jest te pojęcia rozdzielać, bo w praktyce sieciowej mieszanie ich prowadzi do błędnych konfiguracji i złudnego poczucia bezpieczeństwa.