Översikt över DHCP-failover

MED DHCP-redundans kan två Microsoft DHCP-servrar dela tillgänglighetsinformation, vilket säkerställer hög tillgänglighet genom att replikera IP-adresslån och -inställningar mellan en primär server och dess redundanspartner.

All omfångsinformation delas mellan de två DHCP-servrarna, inklusive aktiva leasingar. Detta gör att båda DHCP-servern kan ta ansvar för DHCP-klienter om den andra servern blir otillgänglig.

Den här artikeln ger en översikt av DHCP-failover.

Introduktion till DHCP-failover

Med DHCP-redundans replikeras DHCPv4-omfång från en primär DHCP-server till en DHCP-partnerserver, vilket möjliggör redundans och belastningsutjämning av DHCP-tjänster. DHCP-servrar som delar ett DHCP-omfång som är aktiverat för redundans kallas redundanspartners. Microsofts implementering av DHCP-redundans baseras på utkastet till IETF (Internet Engineering Task Force).

När två DHCP-servrar har konfigurerats för failover delar de omfångsinformation, inklusive alla aktiva leasingar. Detta gör det möjligt för båda DHCP-servrarna att tillhandahålla lån till samma undernät för belastningsutjämning eller redundans. Omfångsinställningar replikeras när du först konfigurerar DHCP-redundans och kan replikeras igen senare om konfigurationsändringar görs.

Följande bild visar hur komponenter och inställningar för ett DHCP-omfång som är aktiverat för redundans delas mellan två DHCP-servrar.

De omfång och inställningar som används med DHCP-servrar som har konfigurerats för DHCP-redundans delas med hjälp av ett nytt objekt som kallas DHCP-redundansrelation. Det finns flera konfigurationsalternativ med DHCP-redundans. Du kan konfigurera redundans för alla omfång som finns på en DHCP-server, eller bara i vissa omfång. Du kan också enkelt använda samma DHCP-redundansinställningar för många omfång genom att lägga till dem i samma redundansrelation. En redundansrelation är alltid mellan endast två DHCP-servrar. En server kan dock ha många redundansrelationer och varje redundansrelation kan vara med en annan DHCP-server.

DHCP-failover-specifikationer

Följande specifikationer gäller för DHCP-redundans.

DHCP-omfång:

• Du kan inte konfigurera DHCP-redundans på ett DHCP-omfång så att fler än två DHCP-servrar ingår.

• DHCP-redundans stöder endast DHCPv4-omfång. DHCPv6-omfång kan inte vara redundansaktiverade.

• Om parametrar för ett redundansaktiverat omfång ändras måste dessa inställningar replikeras manuellt till PARTNER DHCP-servern.

• Replikering av omfångsinställningar kan initieras från antingen DHCP-servern till dess redundanspartnerserver eller omvänt.

DHCP-klient/server:

• DHCP-klienter måste kunna kommunicera med båda DHCP-redundanspartnerservrarna, antingen direkt eller med hjälp av ett DHCP-relä.

• När DHCP-redundans är aktiverat kan ett DHCP-klientlån förnyas av en annan server än den som ursprungligen utfärdade det.

• Två separata, synkroniserade klientlåndatabaser underhålls oberoende av varje DHCP-redundanspartnerserver.

• DHCP-servrar som konfigurerats som redundanspartner kan finnas i olika undernät, men detta krävs inte.

• Klustrad DHCP stöds tillsammans med DHCP-failover. För ändamål av felförbättring betraktas ett DHCP-kluster som en enda DHCP-server.

• DHCP-redundans kan konfigureras och inställningarna kan ändras utan att du behöver pausa, stoppa eller starta om DHCP Server-tjänsten.

DHCP-redundanspartner:

• DHCP-redundanspartner måste båda köra minst Windows Server 2016.

• Två DHCP-servrar som konfigurerats som redundanspartner försöker underhålla en beständig TCP/IP-anslutning.

• DHCP-servrar som konfigurerats som redundanspartner är båda medvetna om statusen för DHCP-tjänsten på den andra servern och informeras om eventuella ändringar i den statusen med minimal fördröjning.

• Om två DHCP-servrar som konfigurerats som redundanspartner inte kan kommunicera, vidtas försiktighetsåtgärder för att undvika att samma IP-adresslån utfärdas till två olika DHCP-klienter.

• Om en DHCP-server blir otillgänglig innan den kan synkronisera all DHCP-klientinformation med sin redundanspartner, vidtas försiktighetsåtgärder för att säkerställa DHCP-lånekontinuitet för DHCP-klienter.

• Två separata, synkroniserade klientlåndatabaser underhålls oberoende av varje DHCP-redundanspartnerserver.

Du kan konfigurera DHCP-redundans med Serverhanteraren eller Windows PowerShell. Information om hur du använder Windows PowerShell finns i DHCP Server-cmdletar i Windows PowerShell. Anvisningar för hur du konfigurerar DHCP i Serverhanteraren finns i den här stegvisa guiden.

DHCP-redundans och IPv6

DHCP-redundans stöds inte för IPv6-omfång (Internet Protocol version 6). Nätverkskort som använder IPv6 bestämmer vanligtvis sin egen IPv6-adress med hjälp av stateless IP-autokonfiguration. I det här läget levererar DHCP-servern endast DHCP-alternativkonfigurationen och servern har ingen information om lånetillstånd. En distribution med hög tillgänglighet för tillståndslös DHCPv6 är möjlig genom att konfigurera två servrar med identisk alternativkonfiguration. Även i en tillståndskänslig DHCPv6-distribution körs omfången inte under hög adressanvändning, vilket gör uppdelat omfång till en livskraftig lösning för hög drifttillgänglighet.

DHCP-failoverlägen

Två DHCP-redundanslägen är tillgängliga att använda när du skapar en DHCP-redundansrelation:

• Hot standby-läge: Det här läget ger redundans för DHCP-tjänster.

• Belastningsutjämningsläge: Det här läget allokerar DHCP-klientlån mellan två servrar.

Du kan växla mellan läget för frekvent vänteläge och lastbalans om du vill, men du kan bara använda ett läge i taget med ett enda DHCP-omfång. Du kan också använda båda lägena på samma DHCP-server om du konfigurerar flera redundansrelationer. Anpassa distributionen baserat på nätverkets fysiska arkitektur.

Beredskapsläge

I läget för frekvent vänteläge fungerar två servrar i en redundansrelation där en aktiv server ansvarar för att leasa IP-adresser och konfigurationsinformation till alla klienter i ett omfång eller undernät. Partnerservern tar på sig en standby-roll, med ansvar för att utfärda lån till DHCP-klienter endast om den aktiva servern blir otillgänglig. Läget för varm reservdrift är idealiskt för scenarier där failover-partnern endast är avsedd att användas tillfälligt när den aktiva servern är otillgänglig.

En server är aktiv eller i standby-läge i kontexten för en failover-relation. En server som har rollen aktiv för en viss relation kan till exempel vara en väntelägesserver för en annan relation. Som standard är den server som används för att skapa redundansrelationen den aktiva servern, men detta krävs inte.

När du väljer frekvent vänteläge måste du också konfigurera procentandelen IP-adresser på den aktiva servern som är reserverade för användning på väntelägesservern om den aktiva servern inte svarar. Som standard är den här reservprocenten 5%.

Reservprocenten används för nya DHCP-lån. Om en DHCP-klient försöker förnya ett DHCP-lån med väntelägesservern som inte kan kontakta den aktiva servern förnyas samma IP-adress som tidigare tilldelades DHCP-klienten. I det här fallet beviljas ett tillfälligt hyresavtal för den maximala varaktigheten för kundens ledtid (MCLT), inte den fullständiga hyrestiden.

Om väntelägesservern utfärdar alla sina tillgängliga reservprocentlån till nya DHCP-klienter innan MCLT upphör att gälla, vägrar den att utfärda nya DHCP-lån och fortsätter att förnya befintliga lån. När MCLT upphör att gälla får väntelägesservern använda hela den tillgängliga IP-adresspoolen för nya DHCP-lån. Om servern fortfarande är i kommunikationsavbrottstillstånd använder den inte hela det tillgängliga IP-adressutrymmet för nya DHCP-leasar.

I läget för frekvent vänteläge fungerar en central office- eller datacenterserver vanligtvis som en reservserver i vänteläge. Den här servern tillhandahåller redundans för en lokal DHCP-server på en fjärrplats, som direkt hanterar DHCP-klienterna. I sådana distributioner ska väntelägesservern endast betjäna klienter om den lokala DHCP-servern blir otillgänglig.

Belastningsutjämningsläge

Belastningsutjämningsläget är standardläget för distribution. I det här läget hanterar två DHCP-servrar samtidigt IP-adresser och alternativ till klienter i ett visst undernät. DHCP-klientbegäranden lastbalanseras och delas mellan de två DHCP-servrarna. Standardförhållandet för belastningsutjämning mellan de två servrarna är 50:50, men detta kan anpassas till valfritt förhållande från 0% till 100%.

Belastningsutjämningsmekanismen definieras i RFC 3074, där en hash beräknas från MAC-adressen som finns i varje DHCP-klientbegäran. Ett intervall med hash-värden (kallas även hash-bucketen) tilldelas till varje DHCP-server baserat på de belastningsutjämningsprocent som har konfigurerats. Servrar avgör om de är avsedda att svara på klienten baserat på deras tilldelade hash-bucket.

När en DHCP-server förlorar kontakten med sin redundanspartner i belastningsutjämningsläge börjar den bevilja lån till alla DHCP-klienter. Om den får en begäran om förnyelse av lån från en DHCP-klient som har tilldelats sin redundanspartner förnyas tillfälligt samma IP-adresslån under MCLT:s varaktighet. Om den tar emot en begäran från en klient som inte tidigare tilldelats ett lån beviljar den ett nytt lån från sin kostnadsfria IP-adresspool tills den är slut och börjar sedan använda den kostnadsfria IP-adresspoolen för redundanspartnern. Om DHCP-servern hamnar i ett partnerfelstillstånd väntar den under MCLT-perioden och tar sedan på sig ansvaret för 100% av IP-adresspoolen.

Belastningsutjämningsläget passar bäst för distributioner där båda servrarna i en redundansrelation finns på samma fysiska plats. Båda servrarna svarar på DHCP-klientbegäranden baserat på det belastningsfördelningsförhållande som konfigurerats av administratören.

DHCP-failover och Windows-failoverklustring

DHCP-failover stöds med DHCP-kluster i följande konfigurationer:

• En enskild DHCP-server kan ha en failover-relation med ett DHCP-failover-kluster.

• Ett DHCP-redundanskluster kan ha en redundansrelation med ett annat DHCP-redundanskluster.

I båda fallen måste du konfigurera DHCP-redundans för att använda klustrets namn eller IP-adress, inte namnet eller IP-adressen för en klusternod. Om en enskild klusternod har konfigurerats som redundanspartner, går den primära servern in i ett kommunikationsavbrutet tillstånd om DHCP Server-tjänsten flyttas till en annan nod i klustret.

DHCP-failover och dynamiska DNS-uppdateringar

Om DHCP-servrar har konfigurerats för att utföra dynamiska DNS-uppdateringar för klientdatorns räkning måste båda DHCP-servrarna i en DHCP-redundansrelation använda samma DNS-autentiseringsuppgifter för att uppdatera DNS-poster. Om redundanspartnern försöker använda olika autentiseringsuppgifter för att uppdatera DNS-resursposter misslyckas den här uppdateringen.

Följande steg beskriver hur dynamiska DNS-uppdateringar kan misslyckas när en klientdator använder en annan DHCP-server:

1. En Windows DHCP-server utför en dynamisk uppdatering för en DHCP-klients räkning.

2. DHCP-servern skapar klientens DNS-namn och blir ägare till det namnet.

3. Nu kan bara SJÄLVA DHCP-servern uppdatera DNS-posterna för klientens namn.

4. Den ursprungliga servern misslyckas och en andra DHCP-server för säkerhetskopiering är online. Nu kan den andra servern inte uppdatera klientnamnet eftersom det inte är namnets ägare.

Se även DNS-postägarskap och DnsUpdateProxy-gruppen för en diskussion om det här scenariot.

Distributionsöverväganden

Tänk på följande innan du använder DHCP-failover:

Tidssynkronisering

För att DHCP-redundansen ska fungera korrekt måste tiden hållas synkroniserad mellan de två servrarna i en redundansrelation. Tidssynkronisering kan upprätthållas genom distribution av NTP (Network Time Protocol) eller någon annan alternativ mekanism. När konfigurationsguiden för redundans körs jämförs den aktuella tiden på de servrar som konfigureras för redundans. Om tidsskillnaden mellan servrarna är större än en minut stoppas redundanskonfigurationsprocessen med ett kritiskt fel och begär att tiden på servrarna ska synkroniseras.

Varje meddelande om redundansprotokoll innehåller ett tidsfält som fylls i med UTC (Coordinated Universal Time) när källservern överförde meddelandet. För varje meddelande kontrollerar den mottagande servern tidsskillnaden mellan tidsstämpelfältet i paketet och tiden på den mottagande servern. Om den här tidsskillnaden visar sig vara större än en minut loggar den mottagande servern en kritisk händelse som anger att de två servrarna inte är tidssynkronisering.

Principbaserad tilldelning

Windows Server innehåller en principbaserad ip-adresstilldelningsfunktion som gör att en Windows DHCP-administratör kan gruppera DHCP-klienterna efter ett specifikt attribut för klienten, till exempel leverantörsklass, användarklass, klientidentifierare eller MAC-adress. Administratörer grupperar klienterna baserat på dessa attribut och kan tilldela parametrar som IP-adress, standardgateway, DNS-server och andra DHCP-alternativ till en specifik gruppering av klienter. På så sätt kan administratören utöva större kontroll över de konfigurationsparametrar som levereras till slutvärdar. Den här funktionen introducerar begreppet flera IP-adressintervall inom ett enda omfång. För att hantera detta sker distributionen av DHCP-redundansadresser i belastningsdelningsläge per IP-adressintervall.

Windows-brandväggen

DHCP-redundans använder TCP-port 647 för att lyssna efter redundansmeddelanden mellan två redundanspartnerservrar. För att den här trafiken ska tillåtas av Windows-brandväggen läggs följande regler för inkommande och utgående brandvägg till och du installerar DHCP Server-rollen:

• Microsoft-Windows-DHCP-Failover-TCP-In

• Microsoft-Windows-DHCP-Failover-TCP-Out

Reläagenter

Inledande DHCPDISCOVER-meddelanden sänds av DHCP-klienter i det undernät som de tillhör. Eftersom routrar vanligtvis inte vidarebefordrar sändningstrafik krävs en mekanism för att göra det möjligt för DHCP-klienter att kommunicera med DHCP-servrar om DHCP-servern inte finns i samma undernät. Reläagenter (tillhandahålls vanligtvis på en router) är utformade för att utföra den här funktionen, vidarebefordra DHCP- och BOOTP-meddelanden mellan klienter och servrar i olika undernät. Relay-agenter konfigureras ofta med på en nätverksenhet, eller så kan du konfigurera DHCP Relay på en Windows Server med fjärråtkomstrollen installerad. Mer information finns i Distribuera DHCP Relay-agenten.

Om DHCP-reläet har konfigurerats på en nätverksenhet kan du läsa leverantörens dokumentation för mer information. Kommandot helper-address används ofta för att konfigurera DHCP Relay på en nätverksenhet, till exempel: ip helper-address 10.0.1.1.

När du distribuerar DHCP-redundans kanske en enda DHCP-reläadress inte räcker, eftersom DHCP-klienter alltid måste kunna kommunicera med både den primära DHCP-servern och redundanspartnerservern. Om båda DHCP-servrarna finns i ett annat undernät än DHCP-klienter krävs minst två DHCP-reläagenter. Exempel: ip helper-address 10.0.1.1, ip helper-address 10.0.1.2.

I det här exemplet finns båda DHCP-servrarna i samma undernät (10.0.1.0/24). Den primära DHCP-serverns IP-adress är 10.0.1.1 och 10.0.1.2 är IP-adressen för redundanspartnerservern. Om båda DHCP-servrarna finns i samma undernät kan du även konfigurera undernätets sändningsadress (t.ex. 10.0.1.255) som ett enda DHCP-relä. Det går inte att använda en undernätssändningsadress som ett enda DHCP-relä om DHCP-servrar finns i separata undernät.

Duplicerade reläagenter

Virtual Router Redundancy Protocol (VRRP) är ett annat redundansprotokoll som används för att aktivera redundans på nätverksenheter. Ett exempel på VRRP inkluderar HSRP (Hot Standby Router Protocol), som är en Cisco-upphovsrättsskyddad VRRP. Om VRRP/HSRP har konfigurerats på en nätverksenhet som också har konfigurerats med ett eller flera DHCP-reläer kan det leda till att dubbletter av DHCP-relämeddelanden skickas till samma DHCP-redundansserver.

Om en enskild DHCP-server som är konfigurerad för DHCP-failover tar emot duplicerade leasingförfrågningar kan detta orsaka inkonsekventa hyrtider för klienter, och klienter kan hyra IP-adresser som tillhör andra klienter. Läs leverantörsdokumentationen för att avgöra om routerredundansprotokollet kräver en specifik konfiguration för att stödja DHCP-relä. Cisco tillhandahåller till exempel DHCP Relay-stöd för HSRP-protokollet med hjälp av virtuella routergrupper.