DHCP Failover je poměrně nová technologie, která se poprvé objevila v rámci operačního systému Windows Server 2012. Tato technologie jak její název napovídá, řeší vysokou dostupnost tak kritické služby jakou je služba DHCP. Před příchodem Windows Server 2012, bylo možné řešit vysokou dostupnost pouze pomocí Failover Clusteru. Nicméně s tímto řešením byly vždy spjaté vyšší náklady, protože podmínkou je sdílený diskový prostor, kde je umístěna databáze DHCP serveru. Ovšem navíc v tom případě také platí, že aktivní je vždy pouze jedna role DHCP serveru. Druhá role se použije jen v případě, že první role je nedostupná. Tyto nedostatky vyřešil právě DHCP Failover. DHCP Failove je pak schopen fungovat ve dvou „režimech“. A to DHCP Failover – „Load sharing mode“ a DHCP Failover – „Hot Standby mode“ V tomto článku probereme fungování v praxi DHCP Failover a to v režimu „Hot Standby mode“ V tomto režimu pracuje DHCP Failover tak, že jeden DHCP server funguje v roli „Active“ a druhý v roli „Standby“. DHCP server v roli „Active“ pak přiděluje IP adresy DHCP klientům a vykonává i jiné funkce, jako je např. potvrzování stávajících zápůjček IP adres (Ack), nebo např. odmítnutí zápůjček IP adres (Nack) apod. Přičemž platí, že pouze role „Active“, může DHCP klientům přidělovat IP adresy z rozsahu volných IP adres. DHCP role „Standby“ může přidělovat IP adresy pouze ze své procentuální rezervy (Addresses reserved for standby server - obvykle 5%) a to jen v případě, pokud ztratí kontakt se svým DHCP partnerem (Active role). Pak zápůjčky, resp. délka zápůjček odpovídá hodnotě definované v parametruMaximum Client Lead Time. To platí do doby, než uběhne interval definovaný v parametruState Switchover Interval. Tento mechanismus je pak popsán dále v textu. V případě normálního stavu, kdy oba DHCP servery fungují, pak také platí, že DHCP server v roli „Standby“ může provádět pro stávající IP adresy např. potvrzování zápůjček IP adres (Ack), nebo např. odmítnutí zápůjčky IP adresy (Nack) apod. Je to možné proto, že údaje o zápůjčkách (dynamic leases) jsou replikovány mezi oběma DHCP servery. Proto každý DHCP server má přehled o již zapůjčených IP adresách a o volných IP adresách, které je možné zapůjčit. Což je logicky podmínkou pro úspěšně fungování DHCP Failoveru. A to aniž by docházelo k přidělování duplicitních IP adres a tím pádem ke konfliktu IP adres. POZOR! Informace o vytvořených rezervacích nejsou automaticky replikovány a je nutné po vytvoření rezervací replikaci vynutit přes správcovskou konzoli DHCP serveru, nebo v případě Windows Server 2012 R2, lze replikaci vynutit pomocí PowerShellu. Tyto replikace jsou pak jednostranné a provedou přemazání konfigurace na druhém DHCP serveru. Tedy praxe je pak taková, že změny konfigurace a vytváření rezervací provádějte pouze na jednom DHCP serveru (nejlépe Active roli) a tyto změny pak replikujte na druhý DHCP server.

Scénář selhání DHCP serveru v roli Active Pokud nedojde během určité doby (State Switchover Interval – obvykle 60 minut) k obnovení komunikace mezi oběma DHCP servery, převezeme DHCP server v roli „Standby“ - “vládu” nad všemi DHCP rozsahy (scopes) a rovněž na sebe „převezme“ roli „Active“. Tedy pak přiděluje IP adresy DHCP klientům (tedy ne jen z 5% rezervy) a vykonává i jiné funkce, jako je např. potvrzování stávajících zápůjček IP adres (Ack), nebo např. odmítnutí zápůjček IP adres (Nack) apod. Podmínkou samozřejmě je, aby tato volba byla povolena. Tak jak je vidět na obrázku, v případě, že došlo k selhání komunikace mezi oběma DHCP servery, např. z toho důvodu, že DHCP server v roli „Active“ přestal fungovat, je možné ručně vynutit „přepnutí Active role“ na stále fungující DHCP server s rolí „Standby“. A to pomocí tlačítka „Change to partner down“. Tato volba je užitečná v případě, že jste si jisti, že původní DHCP server s rolí „Active“ nemůže být v dohledné době zprovozněn, anebo v případě, že nechcete čekat, než k tomu dojde automaticky po uběhnutí času definovaného v rámci volby „State Switchover Interval“ (jen pokud je nastaveno!). Na doplnění, volba „Enable Message Authentication“, plus nastavení určitého hesla způsobí, že informace replikované mezi oběma DHCP partnery budou zabezpečený pomocí Secure Hash Algorithm 2 (SHA-2). Chování DHCP klientů za normálních podmínek Chování DHCP klientů se může zdát po nasazení DHCP Failover poněkud podivné. Především pak co se délky zápůjčky týká. V případě, že poprvé získá DHCP klient IP adresu od DHCP serveru v roli „Active“, je to pouze na dobu definovanou v parametruMaximum Client Lead Time (dále jen MCLT), což je obvykle 1 hodina. Pokud klient posléze požádá o obnovení IP adresy (v polovině doby pronájmu – tedy MCLT/2 – obvykle 30 minut), pak teprve poté mu DHCP server přidělí IP adresu s dobou pronájmu definovanou v rámci nastavení rozsahu (scope). Tedy například, pokud máte na DHCP rozsahu nastaveno, že klienti dostanou IP adresu zapůjčenu na dobu 8 dní, pak v první fází dojde k zapůjčení IP adresy na dobu maximálně 1 hodiny a obvykle po 30 minutách, kdy si klient požádá o prodloužení doby pronájmu IP adresy, je mu IP adresa přidělena na dobu maximálně 8 dnů. Resp. klient opět požádá o prodloužení doby pronájmu po 4 dnech. Tak jak je to definováno dle standardů obsažených v RFC. Toto chování si lze prakticky vyzkoušet. Pokud na DHCP klientovy v příkazové řádce provedete příkazipconfig /release a následněipconfig /renew, dostanete přidělenu IP adresu pouze na dobu odpovídajícíMCLT. Jakmile znovu provedete příkazipconfig /renew, tak podruhé dostanete přidělenu IP adresu na dobu definovanou v rámci nastavení DHCP rozsahu. Proč se tak děje? Protože DHCP servery potřebují čas na to, aby mezi sebou úspěšně provedly replikaci informací o zápůjčkách IP adres. Pro fungování DHCP Failover je kritické, aby oba DHCP servery měly přehled o všech zápůjčkách IP adres.

• RFC 2131, Dynamic Host Configuration Protocol

  • RFC 2132, DHCP Options and BOOTP Vendor Extensions
  • RFC 3046, DHCP Relay Agent Information Option
  • RFC 3942, Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
  • RFC 4242, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
  • RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
  • RFC 4436, Detecting Network Attachment in IPv4 (DNAv4)

  S pozdravem Jakub Heinz| Senior IT Consultant KPCS CZ, s.r.o. | http://www.kpcs.cz | http://www.exchange4u.cz