DE112019006684T5

DE112019006684T5 - Kurzzeitige lease-zuweisung für die verringerung von netzwerk-adressenkonflikten bei dhcp-ausfallsicherungs-bereitstellungen

Info

Publication number: DE112019006684T5
Application number: DE112019006684.6T
Authority: DE
Inventors: Isaac Theogaraj; Venkatesan Marichetty
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2019-01-17
Filing date: 2019-01-17
Publication date: 2021-11-18
Also published as: CN112889305B; CN112889305A; WO2020149847A1; US20210400015A1

Abstract

Es werden Systeme und Verfahren bereitgestellt zur Überwachung eines Verbindungszustands zwischen einem primären DHCP-Server und einem sekundären DHCP-Server, Bestimmen, dass innerhalb eines ersten Zeitrahmens keine Verbindung zwischen dem primären DHCP-Server und dem sekundären DHCP-Server hergestellt wurde, und Herstellen eines Partner-Ausgefallen-Betriebszustands auf einem oder mehreren von dem primären DHCP-Server und sekundären DHCP-Server, und, während eines hergestellten Partner-Ausgefallen-Betriebszustands, Ausgeben/Zuweisen von kurzzeitigen Netzwerkadressen-Leases von einem von dem primären DHCP-Server oder sekundären DHCP-Server. Kurzzeitige Netzwerk-Leases der vorliegenden Offenbarung können eine Dauer zwischen 1 Sekunde und 5 Minuten haben.

Description

Beschreibung des Standes der Technik
Das dynamische Host-Konfigurationsprotokoll (DHCP) ist ein Client-Server-Netzwerkprotokoll, das es ausgewiesenen Servern ermöglicht, Netzwerkadressen (z. B. IP-Adressen) aus einem Pool von Netzwerkadressen, die dem gegebenen Netzwerk zugeordnet sind, an Clients zu verleasen. Um sicherzustellen, dass DHCP-Leases innerhalb eines Netzwerks auch dann ausgegeben werden können, wenn ein DHCP-Server ausfällt, wurde ein DHCP-Ausfallsicherungs-Mechanismus entwickelt, der es zwei DHCP-Servern - einem primären Server und einem sekundären Server (jeweils ein „Peer“, zusammen „Peers“) - ermöglicht, denselben Adresspool zu verwalten, und sich letztendlich die Last der Zuweisung von Leases für diesen Pool zu teilen, und sich gegenseitig bei Netzwerkausfällen zu sichern. Da Peer-DHCP-Server aus demselben Pool von Netzwerkadressen schöpfen, versuchen sie, sich untereinander zu koordinieren, damit kein Konflikt innerhalb des Netzwerks erzeugt wird, indem dieselbe Netzwerkadresse an zwei unterschiedliche DHCP-Clients ausgeben wird. Herkömmliche Systeme sind darin nicht effektiv.
Figurenliste
Die vorliegende Offenbarung wird gemäß einer oder mehreren verschiedenen Ausführungsformen detailliert unter Bezugnahme auf die folgenden Figuren beschrieben. Die Figuren dienen nur zur Veranschaulichung und zeigen lediglich typische oder beispielhafte Ausführungsformen

1 stellt eine beispielhafte Architektur eines Systems dar, das mit einer intelligenten Lease-Zuweisung konfiguriert ist, gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung.
2 stellt verschiedene Elemente einer beispielhaften Orchestrierungs-Engine gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung dar.
3 ist ein Betriebsflussdiagramm, das ein beispielhaftes Verfahren detailliert beschreibt, das gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung implementiert werden kann.
4 ist ein Betriebsflussdiagramm, das ein anderes beispielhaftes Verfahren detailliert beschreibt, das gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung implementiert werden kann.
5 stellt ein Blockdiagramm eines beispielhaften Computersystems dar, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können.

Die Figuren erheben keinen Anspruch auf Vollständigkeit und beschränken die vorliegende Offenbarung nicht auf die präzise offenbarte Form.
Ausführliche Beschreibung
Um hochverfügbares DHCP-Leasing zu ermöglichen und gleichzeitig Netzwerkadressenkonflikte zu verringern - in Szenarien, in denen die Kommunikation zwischen DHCP-Server-Peers geschwächt werden könnte - führt die Technologie der vorliegenden Offenbarung intelligente Lease-Zuweisungsmechanismen und Verfahren zur Bereitstellung derselben ein. In einigen Ausführungsformen stellen die Systeme und Verfahren der vorliegenden Offenbarung eine Orchestrierungs-Engine bereit, die Bedingungen und eine Konnektivität zwischen DHCP-Server-Peers identifiziert, einen Zustandszeitgeber in Bezug auf einzelne DHCP-Peers initiiert (die Zustandszeitgeber sind dazu ausgelegt, einen bestimmten ersten Zeitrahmen zu takten), dann einen Zustand einzelner DHCP-Server-Peers basierend auf innerhalb des ersten Zeitrahmens auftretenden Änderungen der Bedingungen und/oder des Konnektivitätszustands bestimmt, und basierend auf dem Zustand einen Operationsmodus für einzelne DHCP-Peers herstellt. Eine beispielhafte Architektur ist in Bezug auf 1 gezeigt und beschrieben. Bevor die 1 detailliert diskutiert wird, wird jedoch eine kurze Diskussion über DHCP gegeben.
DHCP ist ein Client-Server-Netzwerkprotokoll, das es ausgewiesenen Servern ermöglicht, Netzwerkadressen (z. B. IP-Adressen) aus einem Pool von Netzwerkadressen an Clients, die dem gegebenen Netzwerk zugeordnet sind, zu verleasen (zu verleihen). Die DHCP-Server weisen temporäre oder permanente Netzwerkadressen (z. B. IP-Adressen) an DHCP-Clients zu. Der grundliegende Mechanismus für die Zuweisung dieser Netzwerkadressen ist recht einfach: Ein DHCP-Client fordert die Verwendung einer Netzwerkadresse an (in einigen Fällen für einen spezifizierten Zeitraum), ein DHCP-Server (oder eine Sammlung von DHCP-Servern) bedient die Anforderung durch Identifizieren einer verfügbaren Netzwerkadresse, und bietet dem DHCP-Client an, die Netzwerkadresse für eine feste Lease-Periode zuzuweisen. Wie hierin verwendet, wird der Zeitraum, für den einem DHCP-Client eine Netzwerkadresse zugewiesen wird, als ein „Lease“ bezeichnet.
Genauer gesagt sendet ein DHCP-Client eine Erkennungsnachricht aus (z. B. sendet er eine DHCPDISCOVER-Nachricht in dem lokalen physischen Subnetz des DHCP-Clients auf), die es verfügbaren DHCP-Servern signalisiert, dass der DHCP-Client eine Initialisierung versucht und mit einer Netzwerkadresse und/oder anderen Konfigurationsparametern versehen werden muss. Einer oder mehrere Relay-Agenten (z. B. BOOTP-Relay-Agenten) können die Weitergabe der Erkennungsnachricht an einen oder mehrere von der Sammlung ausgewiesener DHCP-Server erleichtern. Einer oder mehrere der DHCP-Server können mit einer Angebotsnachricht antworten, die eine verfügbare Netzwerkadresse und/oder andere Konfigurationsparameter aufweisen (z. B. mit einer DHCPOFFER-Nachricht, die eine der verfügbaren Netzwerkadressen aus dem Pool, die Ablaufzeit für das DHCP-Client-Lease, usw. aufweist). Der DHCP-Server kann die Angebotsnachricht (z. B. eine DHCPOFFER-Nachricht) unter Verwendung des Relay-Agenten (z. B. des BOOTP-Relay-Agenten) an den DHCP-Client senden. Im Allgemeinen können DHCP-Server beim Zuweisen einer neuen Adresse prüfen, ob die angebotene Netzwerkadresse nicht bereits verwendet wird (z. B. kann der Server die angebotene Adresse mit einer ICMP-Echo-Anforderung prüfen).
Ein DHCP-Client kann eine oder mehrere solcher Angebotsnachrichten (z. B. eine DHCPOFFER-Nachricht) von einem oder mehreren DHCP-Servern empfangen, oder er empfängt möglicherweise keine solche Nachrichte, wenn keine DHCP-Server verfügbar sind, um Netzwerkadressen zu verleasen. Der DHCP-Client kann wählen, oder muss auf eine oder mehrere antwortende Angebotsnachrichten von DHCP-Servern warten. In einigen Fällen kann der DHCP-Client einen DHCP-Server unter vielen auswählen, von denen eine Netzwerkadresse und/oder Konfigurationsparameter empfangen werden sollen, die in einigen Implementierungen auf den in den Angebotsnachrichten angebotenen Konfigurationsparametern basieren können. In anderen Fällen können die DHCP-Serverressourcen eingeschränkter sein, so dass der DHCP-Client das erste Netzwerkadressenangebot, das er erhält, annimmt, häufig nachdem er für einen gewissen Zeitraum gewartet hat. In Fällen, in denen der DCHP-Client für einen bestimmten Zeitraum keine Angebotsnachricht empfängt, kann die ursprüngliche Erkennungsnachricht des DHCP-Clients möglicherweise eine Zeitbegrenzung auslösen (oder anderweitig verstreichen), und der DHCP-Client muss die Erkennungsnachricht möglicherweise erneut übertragen. In jedem Fall sendet der DHCP-Client, nachdem er ein akzeptables Angebot empfangen hat, eine Anforderungsnachricht (z. B. eine DHCPREQUEST-Nachricht) aus, die eine Anforderung zum Empfangen der Netzwerkadresse und/oder anderer Konfigurationsparameter umfasst, die von einem der DHCP-Server angeboten werden. Solche Anforderungsnachrichten weisen eine Angabe des bestimmten DHCP-Servers auf, dessen Angebot der DHCP-Client annehmen möchte. In einigen Fällen kann die Anforderungsnachricht des DHCP-Clients andere Optionen für die gewünschten Konfigurationswerte angeben. Wieder werden die zwischen den DHCP-Servern und DHCP-Clients übertragenen Nachrichten über einen oder mehrere Relay-Agenten (z. B. DHCP/BOOTP-Relay-Agenten) ausgeführt.
DHCP-Server empfangen Anforderungsnachrichten von DHCP-Clients (z. B. empfangen sie die DHCPREQUEST-Sendungen von den anfordernden DHCP-Clients). Diejenigen DHCP-Server, die nicht durch die Anforderungsnachricht ausgewählt wurden, können die Anforderungsnachricht als Benachrichtigung dafür verwenden, dass der DHCP-Client das Angebot des DHCP-Servers, wie es in der Angebotsnachricht des DHCP-Servers detailliert beschrieben wird, abgelehnt hat. Der in der Anforderungsnachricht ausgewählte DHCP-Server speichert jedoch die Bindung für den DHCP-Client und antwortet dem anfordernden DHCP-Client mit einer Bereitstellungsnachricht (z. B. einer DHCPACK-Nachricht), die die Netzwerkadresse und/oder andere Konfigurationsparameter aufweist. Idealerweise sollten die Netzwerkadresse und/oder andere Konfigurationsparameter in der Bereitstellungsnachricht keinen Konflikt mit anderen Bereitstellungsnachrichten, die von dem DHCP-Server selbst (oder von einem Peer) angeboten werden, erzeugen, oder nicht bezüglich der Netzwerkadresse und/oder anderen Konfigurationsparametern inkonsistent sein, die bereits detailliert in der früheren Angebotsnachricht, auf die der DHCP-Client antwortet, beschrieben wurden.
Der DHCP-Client empfängt die Bereitstellungsnachricht mit der Netzwerkadresse und/oder anderen Konfigurationsparametern und übernimmt diese. An diesem Punkt wird der DHCP-Client konfiguriert. In einigen Fällen kann der DHCP-Client vor der Übernahme der Netzwerkadresse und/oder anderer Konfigurationsparameter eine Prüfung der Netzwerkadresse und/oder anderer Konfigurationsparameter (z. B. ARP für die zugewiesene Netzwerkadresse) durchführen, und kann die Dauer des in der Bereitstellungsnachricht spezifizierten Leases bestimmen. Wenn der DHCP-Client beispielsweise feststellt, dass die Netzwerkadresse bereits verwendet wird, kann der DHCP-Client eine Ablehnungsnachricht (z. B. eine DHCPDECLINE-Nachricht) an den Server senden und den Konfigurationsprozess neu starten.
Für den Fall, dass der DHCP-Client als Antwort auf seine Anforderungsnachricht weder eine Bereitstellungsnachricht noch eine Rückrufnachricht (z. B. eine DHCPNAK-Nachricht) empfängt, die angibt, dass der DCHP-Server die angebotenen Parameter nicht bereitstellen kann, kann der DHCP-Client eine Zeitbegrenzung auslösen und die Anforderungsnachricht (z. B. die DHCPREQUEST-Nachricht) erneut übertragen. Der DHCP-Client kann die Anforderungsnachricht mehrmals erneut übertragen, um die Wahrscheinlichkeit zu erhöhen, den DHCP-Server zu kontaktieren. Beispielsweise kann ein DHCP-Client seine Nachricht viermal mit einer Gesamtverzögerung von 60 Sekunden erneut übertragen, bevor die Initialisierungsoperation neu gestartet wird. Wenn der DHCP-Client nach Verwendung einer Neuübertragungsroutine weder eine Bereitstellungsnachricht noch eine Rückrufnachricht empfängt, kehrt der DHCP-Client in einen Initialisierungsstatus zurück und startet den Initialisierungsprozess erneut. Leider bewirkten diese Neuübertragungsschleife und Neuinitialisierung häufig, dass der DHCP-Client (und der Benutzer dieses DHCP-Clients) für eine unerwünschte oder nicht tolerierbar lange Zeit warten muss, wobei der Benutzer, der versucht, eine Verbindung herzustellen, letztendlich aufgibt.
In einem Versuch, solche unerwünschten Wartezeiten zu vermeiden, und ein DHCP-Leasing und eine Konfiguration für anfordernde DHCP-Clients hochverfügbar zu machen, kann ein DHCP-Ausfallsicherungs-Protokoll implementiert werden, so dass DHCP-Clients auch dann bedient werden können, wenn ein DHCP-Server ausfällt. Insbesondere kann ein DHCP-Ausfallsicherungs-Mechanismus implementiert werden, so dass zwei DHCP-Server - ein primärer Server und ein sekundärer Server (jeweils ein „Peer“, und zusammen „Peers“) - zusammenarbeiten können, um denselben Adresspool zu verwalten, und letztendlich die Last der Zuweisung von Leases für diesen Pool zu teilen und sich gegenseitig bei Netzwerkausfällen zu sichern. Da diese Peer-DHCP-Server aus demselben Pool von Netzwerkadressen schöpfen (d. h., denselben Bereich von Netzwerkadressen verwenden), versuchen Peer-DHCP-Server, sich untereinander zu koordinieren, damit kein Konflikt innerhalb des Netzwerks erzeugt wird, indem dieselbe Netzwerkadresse an zwei oder mehr unterschiedliche DHCP-Clients ausgegeben wird.
Trotzdem gibt es viele reale Szenarien, in denen herkömmliche DHCP-Ausfallsicherungs-Mechanismen Peer-DHCP-Serveroperationen nicht effektiv verwalten, um Clients im Netzwerk effizient zu bedienen, so dass sowohl das DHCP-Adressen-Leasing hochverfügbar ist (z. B. wenig bis gar keine Wartezeit), während Netzwerkadressenkonflikte (z. B. doppelte Netzwerkadressen, die in demselben Zeitrahmen an unterschiedliche Clients im Netzwerk verleast werden) immer noch vermieden werden.
Ein solches Szenario kann auftreten, wenn einer der Peer-DHCP-Server vor dem anderen bereitgestellt wird, oder einer der Peer-DHCP-Server anderweitig ausfällt - d. h., nicht verfügbar ist, um DHCP-Leases selbst auszugeben. In diesem Szenario erfordern aktuelle Systeme häufig, dass ein Systemadministrator eingreift und den ersten DHCP-Server (d. h. den aktiven Peer) manuell darüber benachrichtigt, dass der zweite DHCP-Server (d. h. der inaktive Peer) ausgefallen ist, und dass der erste DHCP-Server Leases aus dem gesamten Adressbereich des Pools ausgeben sollte. Darüber hinaus hat der erste DHCP-Server möglicherweise nicht alle Adressen vollständig im Blick, die von dem zweiten DHCP-Server ausgegeben wurden, bevor er ausfiel (z. B. die zuletzt ausgegebenen Adressen, die noch verleast sind), und kann daher mit der Ausgabe von Adressen beginnen, die in Konflikt mit Adressen stehen, die zuvor von dem zweiten DHCP-Server ausgegeben wurden, aber dem ersten DHCP-Server nicht bekannt sind.
Ein anderes solches Szenario kann auftreten, wenn beide DHCP-Server-Peers gleichzeitig (oder nahezu gleichzeitig) von einer zentralen Steuerung (z. B. der Aruba Cloud Provisioning Platform) bereitgestellt werden, und zeitweise beginnen, Netzwerkadressen aus demselben Pool ausgeben, ohne zu wissen, welche Adressen der andere Peer ausgibt. Ähnlich wie in dem ersten beispielhaften Szenario können der erste und der zweite DHCP-Server-Peer zeitweise dieselben Adressen an unterschiedliche Clients ausgeben.
Nun unter Bezugnahme auf die Figuren, stellt 1 eine beispielhafte Systemarchitektur dar, die eine intelligente Lease-Zuweisung gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt. Wie gezeigt wird, können DHCP-Clients 110 über Zugangspunkte 120 (z. B. Campus-AP und/oder Instant-AP-basierte Bereitstellungen) kommunizieren, um Nachrichten über den Netzwerk-Switch 130 an DHCP-Server 140 weiterzuleiten und zu empfangen. DHCP-Server 141, 142 kommunizieren mit den Internetdienstanbietern 150 (z. B. ISP 151, ISP 152), durch die die DHCP-Clients versuchen, eine Verbindung herzustellen, um über das Internet zu kommunizieren. In der gezeigten beispielhaften Architektur können zwei DHCP-Server 141, 142 gemäß einem DHCP-Ausfallsicherungs-Protokoll arbeiten, das durch eine Orchestrierungs-Engine 145 verbessert wurde. Die DHCP-Server können über einen Switch 130 (z. B. dem Schicht-2-Switch 131) verbunden sein, und können jeweils eine Kopie der Netzwerkadressen innerhalb des ausgewiesenen Bereichs von Netzwerkadressen (d. h. des Pools), aus denen die DHCP-Server Leases ausgeben können, und eine Angabe bekannter Lease-Zustände solcher Netzwerkadressen vorhalten. Der Adresspool kann in den Adresspool-Repositorys 143, 144 verwaltet werden.
Die Verbindungen zwischen Elementen, die in 1 gezeigt sind, kann drahtgebunden oder drahtlos sein und jedes für das gegebene Netzwerk gewünschte Kommunikationsprotokoll nutzen. Darüber hinaus können, obwohl dies nicht explizit in 1 gezeigt wird, DHCP-Server-Peers von einer bestimmten Plattform bereitgestellt werden, die von einem Netzwerkdienstanbieter bereitgestellt wird. Beispielsweise können die DHCP-Server-Peers zunächst über eine Verbindung mit der Aruba Cloud Provisioning Platform bereitgestellt werden, die von dem Hewlett Packard Enterprise Unternehmen Aruba angeboten wird. In einigen Beispielen kann sich der primäre DHCP-Server-Peer zunächst über eine DSL-basierte Uplink-Verbindung mit einer solchen Plattform verbinden. Dann kann sich der sekundäre Server-Peer über eine virtuelle Verbindung mit der Plattform verbinden (z. B. über den Uplink des ersten Controllers, wobei MLPS für denselben konfiguriert ist). Darüber hinaus kann in einigen beispielhaften Umgebungen ein primärer DHCP-Server-Peer einen Gateway-Peer umfassen, auf dem annähernd die Hälfte der Client-Anforderungen endet, und ein sekundärer DHCP-Server-Peer kann ein Gateway-Peer sein, auf dem annähernd die andere die Hälfte der Client-Anforderungen endet.
Unter idealen Bedingungen arbeiten beide DHCP-Server 141, 142 in einem Aktiv-Aktiv-Modell, wobei jeder in einem Zweig eines Netzwerks die Netzwerkadressen und/oder andere Konfigurationsparameter ersucht, aktiv DHCP-Clients zu bedienen. Das heißt, sowohl der primäre DHCP-Server 141 als auch der sekundäre DHCP-Server 142 arbeiten zusammen, um Netzwerkadressen-Leases an mehrere DHCP-Clients aus demselben Adresspool gemäß einer Koordinierung zu vergeben, die eine hohe Verfügbarkeit und eine geringe Konfliktwahrscheinlichkeit erreicht. Insbesondere kommunizieren die DHCP-Server-Peers 141, 142 unter idealen Bedingungen Lease-Zustandsaktualisierungen untereinander, so dass die Adresspool-Repositorys 143, 144 zwischen den DHCP-Servern konsistent sind, um Konflikte zu vermeiden. Unter nichtidealen Bedingungen bieten die DHCP-Server-Peers möglicherweise keine so hohe Verfügbarkeit und können Netzwerkadressen ausgeben, die untereinander in Konflikt stehen. Unter nichtidealen Bedingungen wird eine solche Kommunikation verhindert und gibt Anlass zu potenziellen Konflikten. Zu den nichtidealen Bedingungen gehören Szenarien, in denen beide DHCP-Server-Peers nicht ordnungsgemäß zusammenarbeiten, z. B. in Szenarien, in denen einer der DHCP-Server-Peers ausfällt, während der andere in Betrieb ist, in Szenarien, in denen beide DHCP-Server-Peers gleichzeitig den Betrieb initiieren und eine Zeit lang in einer abgeschotteten Art und Weise arbeiten. Die Orchestrierungs-Engine 145 erhöht die Verfügbarkeit und Genauigkeit von Netzwerkadressen-Leases unter nichtidealen Bedingungen, so dass die Lease-Verfügbarkeit hoch bleiben kann, während gleichzeitig eine Verringerung der Netzwerkadressenkonflikte bewirkt wird. Obwohl die Orchestrierungs-Engine 145 als eine einzige Einheit in der Kommunikation mit beiden DHCP-Server-Peers gezeigt ist, versteht es sich, dass im Rahmen der vorliegenden Offenbarung Variationen implementiert werden können. Beispielsweise kann jeder DHCP-Server-Peer mit seiner eigenen Orchestrierungs-Engine 145 ausgestattet sein.
2 stellt verschiedene Elemente einer beispielhaften Orchestrierungs-Engine gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung dar. Wie gezeigt wird, kann die Orchestrierungs-Engine 145 eine Zustandserkennungskomponente 146, einen Zustandszeitgeber 147, und eine Betriebszustands-Erweiterungskomponente 148 aufweisen. Konsistent mit 1 ist die Orchestrierungs-Engine 145 so dargestellt, dass sie mit beiden DHCP-Server-Peers 141 und 142 in Kommunikation steht. Jedoch versteht es sich, wie in Bezug auf 1 bemerkt wird, dass im Rahmen der vorliegenden Offenbarung Variationen, wie beispielsweise Ausführungsformen, implementiert werden können, bei denen jeder DHCP-Server-Peer seine eigene Orchestrierungs-Engine 145 umfassen kann.
Die Konnektivitäts-Erkennungs-Komponente 146 ist dazu ausgelegt, einen oder mehrere Betriebszustände und einen Konnektivitätszustand unter DHCP-Server-Peers zu identifizieren. Die Operationsbedingung eines DHCP-Server-Peers bezieht sich darauf, ob der Peer aktiv oder inaktiv ist, d. h., ob der Peer im Netzwerk aktiv ist, so dass er Anfragen/Anforderungen von DHCP-Clients empfangen kann und für solche DHCP-Clients Netzwerkadressen-Leases anbieten/ausgeben kann, oder nicht. Ein Konnektivitätszustand eines DHCP-Peers bezieht sich darauf, ob der Peer die Kommunikation mit den anderen DHCP-Peers, mit denen er einen Adresspool gemeinsam nutzen soll, ordnungsgemäß hergestellt hat oder nicht. Wenn ein DHCP-Server-Peer aktiv ist, aber nicht die erforderlichen Kommunikationsverbindungen mit dem anderen DHCP-Server-Peer hergestellt hat (entweder weil der andere DHCP-Server-Peer inaktiv ist oder die Verbindung zwischen beiden noch nicht hergestellt wurde), kann man sagen, dass sich der DHCP-Server-Peer in einem abgeschotteten Betriebszustand befindet. Wenn ein DHCP-Server-Peer sowohl aktiv ist als auch eine Kommunikation mit dem anderen DHCP-Server-Peer, der ebenfalls aktiv ist, hergestellt hat, kann gesagt werden, dass sich beide DHCP-Server-Peers in einem kohärenten Betriebszustand befinden. Schließlich kann, wenn ein DHCP-Server-Peer nicht in dem Netzwerk einsatzbereit ist, so dass er keine Anfragen/Anforderungen von DHCP-Clients empfangen und Netzwerkadressen-Leases für solche DHCP-Clients anbieten/ausgeben kann, einfach gesagt werden, das sich der DHCP-Server-Peer in einem inaktiven Zustand befindet. Die Konnektivitäts-Erkennungs-Komponente 146 kann dazu ausgelegt sein, kontinuierlich oder periodisch innerhalb eines vordefinierten Zeitrahmens zu arbeiten, der von einem Zustandszeitgeber, wie etwa dem Zustandszeitgeber 147, getaktet wird.
Der Zustandszeitgeber 147 ist dazu ausgelegt, eine Zeitzählung bereitzustellen. In einigen Ausführungsformen zählt der Zustandszeitgeber 147 für ein vordefiniertes Zeitintervall herunter, und beginnt einen solchen Countdown, wenn er ausgelöst wird. Der Zustandszeitgeber 147 kann so ausgelegt sein, dass er bei jedem für die gegebene Anwendung gewünschten Ereignis ausgelöst wird. In einigen Ausführungsformen ist der Zustandszeitgeber 147 so ausgelegt, dass er ausgelöst wird, wenn ein DHCP-Server einen aktiven Zustand erreicht. In einigen Ausführungsformen ist der Zustandszeitgeber 147 so ausgelegt, dass er ausgelöst wird, wenn ein DHCP-Server Strom empfängt. In einigen Ausführungsformen ist der Zustandszeitgeber 147 so ausgelegt, dass er bei einem Hochfahren des DHCP-Servers ausgelöst wird. In einigen Ausführungsformen ist der Zustandszeitgeber 147 so ausgelegt, dass er bei einem Initiieren von Verbindungserkennungsoperationen des DHCP-Servers ausgelöst wird (d. h., wenn der DHCP-Server beginnt, nach einer Verbindung mit seinem Peer zu suchen und diese herzustellen). Einmal ausgelöst, zählt der Zustandszeitgeber 147 für ein vorbestimmtes Zeitintervall herunter, und nach Ablauf des Zeitintervalls kann der Zustandszeitgeber 147 eine Angabe bereitstellen, dass das Zeitintervall verstrichen ist oder auf andere Weise abgelaufen ist. Das vordefinierte Zeitintervall kann (z. B. von einem Netzwerkadministrator) auf einen beliebigen gewünschten Zeitpunkt eingestellt werden. In einigen Ausführungsformen kann das vordefinierte Zeitintervall etwa auf zwischen 3 bis 240 Sekunden eingestellt werden, wie es für ein gegebenes Netzwerk gewünscht wird. Unter anderen Zeitintervallen innerhalb des vorstehenden Bereichs haben experimentelle Ergebnisse gezeigt, dass das Einstellen des vordefinierten Zeitintervalls auf etwa 60 Sekunden ein wünschenswertes Gleichgewicht zwischen hoher Verfügbarkeit einer DHCP-Lease-Zuteilung und geringem Konflikt unter nichtidealen Bedingungen bei der Implementierung der hier offenbarten Technologie erreicht.
Die Betriebszustands-Erweiterungskomponente 149 bestimmt, ob während des vordefinierten Zeitintervalls der DHCP-Server-Peer den kohärenten Betriebszustand mit seinem Peer erreicht hat (d. h., sie bestimmt, ob der DHCP-Server-Peer sowohl aktiv ist als auch eine Kommunikationsverbindung mit den anderen DHCP-Server-Peers, mit denen eine Verbindung hergestellt werden soll und die ebenfalls als aktiv bestimmt wurden, hergestellt hat oder nicht).
Wenn bestimmt wird, dass zwei oder mehr DHCP-Server-Peers in einem kohärenten Betriebszustand arbeiten, so dass sie bei einem Verteilen von DHCP-Netzwerkadressen-Leases an DHCP-Clients (z. B. Zweigstellen-Hosts) koordinieren können, kann die Betriebszustands-Erweiterungskomponente 149 eine Erweiterungsoperation bewirken, die eine Lastausgleichsoperation umfasst, die zum Verteilen eingehender Erkennungs-/Anforderungsnachrichten unter den DHCP-Clients gemäß einer Lastausgleichsregel ausgelegt ist. In einigen Ausführungsformen erreicht die Lastausgleichsregel eine gleichmäßige (oder nahezu gleichmäßige) Verteilung der Anzahl von Erkennungs-/Anforderungsnachrichten, die von jedem DHCP-Client bedient werden. In anderen Ausführungsformen verteilt die Lastausgleichsregel Erkennungs-/Anforderungsnachrichten auf die jeweiligen Rechenkapazitäten der DHCP-Server (in Echtzeit, oder wie spezifiziert) und/oder bekannte Ressourcen. Wenn beispielsweise die DHCP-Lease-Verarbeitungskapazität eines primären DHCP-Server-Peers (in einem gegebenen Zeitrahmen) 20% höher ist als die des sekundären DHCP-Server-Peers, wird die Operation ausgeführt, wenn bestimmt wird, dass sich die Peers in einem kohärenten Betriebszustand befinden. Die Betriebszustands-Erweiterungskomponente 149 kann eingehende Erkennungs-/Anforderungsnachrichten von DHCP-Clients so verteilen, dass 20% mehr von dem primären DHCP-Server-Peer als von dem sekundären DHCP-Server-Peer verarbeitet werden. Die Betriebszustands-Erweiterungskomponente 149 kann dazu ausgelegt sein, eine Lastausgleichsoperation zu bewirken, um die Lease-Behandlung durch jeweilige DHCP-Server-Peers gemäß der Technologie der vorliegenden Offenbarung zu erweitern.
Wenn bestimmt wird, dass ein DHCP-Server-Peer während des vordefinierten Zeitintervalls keinen kohärenten Betriebszustand erreicht hat und stattdessen in einem abgeschotteten Betriebszustand arbeitet (so dass er den anderen DHCP-Server-Peer beim Verteilen von DHCP-Netzwerkadressen-Leases an DHCP-Clients noch nicht koordinieren kann), kann die Betriebszustands-Erweiterungskomponente 149 dann einen Erweiterungsbetrieb bewirken, der einen Partner-Ausgefallen-Betrieb umfasst, der dazu gestaltet ist, den abgeschotteten DHCP-Server-Peer in einen „Partner-Ausgefallen“-Zustand zu versetzen, in dem er dann auf kurzzeitiger Basis mit der Ausgabe von Netzwerkadressen-Leases aus dem Adresspool-Repository beginnen kann. Das heißt, der DHCP-Server-Peer, der in dem Status „Partner ausgefallen“ arbeitet, kann bis zum Erreichen eines kohärenten Betriebszustands mit seinem Peer mit der Ausgabe kurzzeitiger Leases beginnen (zwischen 1 Sekunde und 5 Minuten, wie von einem Netzwerkadministrator festgelegt), damit das Netzwerk Netzwerkadressen-Anforderungen von DHCP-Clients mit hoher Verfügbarkeit verarbeiten kann, aber auch die Wahrscheinlichkeit und die Konsequenz eines Leases einer Netzwerkadresse, die im Konflikt zu einer Netzwerkadresse steht, die von dem anderen DHCP-Server-Peer geleast wurde, mit dem keine Verbindung hergestellt wurde, verringert. Die Ergebnisse haben gezeigt, dass durch die Ausgabe von kurzzeitigen Leases von etwa 10 Sekunden mit der vorliegenden Technologie ein Netzwerkadressen-Leasingumgebung erreicht wird, die vollständig (oder nahezu vollständig) konfliktfrei ist, und für DHCP-Clients, die neue Netzwerkadressen benötigen, in hohem Maße zur Verfügung steht.
Wie im Stand der Technik bekannt ist, werden Standard-DHCP-Leases für Zeiträume von 12 Stunden oder länger ausgegeben. Wenn beispielsweise zwei abgeschottete DHCP-Server für einen solchen Zeitrahmen dieselbe Netzwerkadresse an zwei verschiedene DHCP-Clients ausgeben, sind die Konsequenzen, die mit diesem Konflikt verbundenen sind, von langer Dauer. Jedoch können mit den Orchestrierungsmerkmalen der vorliegenden Offenbarung DHCP-Server-Peers weiterhin begrenzte Netzwerkadressen-Leases vergeben, während sie nicht untereinander verbunden sind (oder wenn ein DHCP-Server-Peer nicht verfügbar ist), wodurch eine hohe Verfügbarkeit aufrechterhalten wird, während Konflikte und Konfliktauswirkungen verringert werden. Mit der Technologie der vorliegenden Offenbarung stellt jedoch die Ausgabe von kurzzeitigen Leases von 5 Minuten oder kürzer in nichtidealen Szenarien (z. B., wenn zwei DHCP-Server-Peers in abgeschotteten Betriebszuständen arbeiten) sicher, dass im schlimmsten Fall ein Netzwerkadressenkonflikt nur zwischen 1 Sekunde und 5 Minuten dauern kann.
Obwohl Netzwerkadressenkonflikte ein langandauerndes Problem in DHCP und anderen internetbasierten Kommunikationsumgebungen sind, haben Fachleute solche Konflikte traditionell als den notwendigen Preis wahrgenommen, der für Clients zu zahlen ist im Austausch für die Bereitstellung von DHCP-Leases- z. B. Bereitstellung einer sofortigen Zuweisung von Leases als Antwort auf Client-Anforderungen trotz des drohenden Risikos widersprüchlicher Netzwerkadressen. Fachleute hätten nicht daran gedacht, die hier offenbarte Orchestrierungstechnologie basierend auf das DHCP-Protokoll aufzubauen, da das Anbieten kurzzeitiger Leases zur Erleichterung einer solchen Orchestrierung für Endbenutzer als nicht sehr nützlich angesehen worden wäre, und dies dem Netzwerk eine zu große Rechenlast auferlegen würde, um wiederholte kurzzeitige Leases auszugeben, um die Kommunikationserfahrung eines DHCP-Clients praktisch nahtlos zu machen. Das heißt, in Situationen, in denen DCHP-Clients beispielsweise eine IP-Adresse anfordern, beabsichtigen sie im Allgemeinen länger als 5 Minuten, und mit Sicherheit länger als 10 Sekunden, an der Internetkommunikation teilzunehmen. Somit hätte der Durchschnittsfachmann nicht daran gedacht, die Orchestrierungstechnologien der vorliegenden Offenbarung zu implementieren, da sie den Rechenaufwand für die DHCP-Server und DHCP-Clients im Netzwerk erhöhen könnten.
Jedoch demonstrieren die beobachteten Ergebnisse, dass die hier vorgestellten Orchestrierungsmerkmale tatsächlich in praktischen Umgebungen, in denen nichtideale Szenarien auftreten, unterstützt werden können. Beispielsweise kann die vorliegende Technologie in Netzwerkumgebungen implementiert werden, in denen beispielsweise zwei oder mehr Aruba 70XX- und/oder Aruba 72XX-Controller als Gateway-Peers eingesetzt werden, die einen oder mehrere Zweige eines Netzwerks (z. B. ein SD-WAN) bedienen. Solche Controller mit hoher Kapazität können als DHCP-Server arbeiten, die DHCP-Ausfallsicherungs-Protokolle implementieren, die durch die Orchestrierungsmerkmale der vorliegenden Offenbarung verbessert wurden.
Unter Bezugnahme auf 2 kann zusätzlich zu den zuvor erwähnten kurzzeitigen Leasingmerkmalen die Betriebszustands-Erweiterungskomponente 149 dazu ausgelegt sein, eine aktive Synchronisation zwischen den Adresspool-Repositorys zu bewirken, die an jedem DHCP-Server-Peer gespeichert sind. Bei der aktiven Synchronisierung wird eine Synchronisierungsoperation entweder (i) periodisch gemäß einem vordefinierten Intervall oder (ii) nach Bestimmung, dass ein DHCP-Server-Peer eine Synchronisierungsgarantiebedingung erreicht hat, ausgeführt. Eine Synchronisationsgarantiebedingung kann jede von einem Netzwerkadministrator festgelegte Bedingung aufweisen. Anhand einiger nicht einschränkender Beispiele kann eine Synchronisationsgarantiebedingung erfüllt sein, wenn ein DHCP-Server-Peer eine vorgegebene Anzahl von Leases ausgibt (z. B. fünf Netzwerkadressen-Leases, 10 Netzwerkadressen-Leases, usw.), eine vorgegebene Anzahl von zuvor durch den angegebenen DHCP-Server-Peer zugeteilten Leases abgelaufen ist oder anderweitig zur Wiederverwendung verfügbar ist, bei einem DHCP-Server-Peer Probleme auftreten, die auf einen bevorstehenden Ausfall oder eine Verringerung der Verarbeitungskapazität hinweisen, ein DHCP-Server-Peer eine vorbestimmte Anzahl von Angeboten abgegeben hat, die für länger als ein vorbestimmter Zeitraum noch ausstehen, usw. Einer der DHCP-Server-Peers (z. B. der primäre oder sekundäre DHCP-Server-Peer) kann eine aktive Synchronisationsoperation initiieren.
Durch einen Betrieb der Orchestrierungs-Engine, wie hierin vermerkt (z. B. die Nutzung eindeutiger, kurzzeitiger Lease-Zuweisungsroutinen während „Partner-Ausgefallen“-Zuständen, und/oder Bereitstellen einer aktiven Synchronisation zwischen DHCP-Server-Peers, usw.), kann die Technologie der vorliegenden Offenbarung dazu beitragen, ein Verhungern von Zweig-DHCP-Clients beim Erhalten einer gültigen DHCPbasierten Netzwerkadresse (z. B. IP-Adressen) zu vermeiden, und gleichzeitig das Auftreten und die Konsequenzen von Konflikten zu verringern.
3 stellt eine beispielhafte Rechenkomponente 300 zum Orchestrieren von DHCP-Lease-Zuteilungen gemäß Ausführungsformen der vorliegenden Offenbarung dar. Die Rechenkomponente 300 kann ganz oder teilweise in einem DHCP-Peer, in der Orchestrierungs-Engine 145, oder in einem anderen Element des Systems 100 ausgeführt sein. Die Rechenkomponente 300 kann einen Hardwareprozessor 301 und ein maschinenlesbares Speichermedium 302 aufweisen. Die Rechenkomponente 300 kann beispielsweise ein Servercomputer, ein Controller, oder eine andere ähnliche Rechenkomponente, die dazu in der Lage ist, Daten zu verarbeiten, sein. Der Hardwareprozessor 301 kann eine oder mehrere Zentraleinheiten (CPUs), Mikroprozessoren auf Halbleiterbasis und/oder andere Hardwarevorrichtungen sein, die zum Wiederherstellen und Ausführen von Anweisungen geeignet sind, die auf einem maschinenlesbaren Speichermedium 302 gespeichert sind. Der Hardwareprozessor 301 kann Anweisungen abrufen, decodieren und ausführen, wie beispielsweise Anweisungen zum Bewirken von 303 bis 310, um DHCP-Leases gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung zu orchestrieren (z. B., um kurzzeitige Leases in Szenarien auszugeben, in denen eine Verringerung eines Auftretens und einer Konsequenz von DHCP-Leasingkonflikten gewünscht wird).
Ein maschinenlesbares Speichermedium, wie etwa das maschinenlesbare Speichermedium 302, kann eine beliebige elektronische, magnetische, optische oder andere physikalische Speichervorrichtung, die ausführbare Anweisungen aufweist oder speichert, sein. So kann das maschinenlesbare Speichermedium 302 beispielsweise ein Direktzugriffsspeicher (RAM), ein nichtflüchtiger RAM (NVRAM), ein elektrisch löschbarer programmierbarer Nur-Lese-Speicher (EEPROM), eine Speichervorrichtung, eine optische Platte, und dergleichen sein. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 302 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ keine sich transitorisch verbreitenden Signale umfasst. Wie nachstehend detailliert beschrieben, kann das maschinenlesbare Speichermedium 302 mit ausführbaren Anweisungen, beispielsweise den Anweisungen 303 bis 310, codiert werden, um ein DHCP-Leasing gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung zu orchestrieren (z. B., um kurzzeitige Leases auszugeben in Szenarien, in denen eine Verringerung eines Auftretens und einer Konsequenz von DHCP-Lease-Konflikten gewünscht wird).
Die Rechenkomponente 300 kann in einem oder mehreren DHCP-Server-Peers 141, 142 verkörpert sein oder diese verkörpern, (1), oder kann in einem anderen Element des Systems 100 verkörpert sein oder dieses verkörpern (1), das sich von einem DHCP-Server-Peer unterscheidet, der jedoch mit einem oder mehreren solcher DHCP-Server-Peers in Kommunikation steht, um die Funktionalität des Orchestrators 145 zu bewirken. Beispielsweise kann, wie in 3 gezeigt wird, der Hardwareprozessor 301 eine Anweisung 303 ausführen, um einen Verbindungszustand zwischen Server-Peers (z. B. zwischen einem bestimmten primären DHCP-Server und einem bestimmten sekundären DHCP-Server) zu überwachen. Ferner kann der Hardwareprozessor 301 die Anweisung 304 ausführen, um zu bestimmen, ob die erforderlichen Kommunikationsverbindungen zwischen Server-Peers innerhalb eines ersten Zeitrahmens (z. B. eines von einem eingebetteten Zeitgeber vorgegebenen Zeitrahmens) hergestellt wurden.
Wenn, entsprechend der Anweisung 304, Operationen des Hardwareprozessors 301 basierend auf der Überwachung bestimmen, dass eine Verbindung zwischen Server-Peers (z. B. einem primären DHCP-Server und einem sekundären DHCP-Server) innerhalb eines ersten Zeitrahmens hergestellt wurde, kann der Hardwareprozessor 301 die Anweisung 306 ausführen, um es den Server-Peers zu ermöglichen, gemäß einem kohärenten Betriebszustand zu arbeiten (z. B. um Leases mit Standarddauer gemäß dem regulären Betrieb auszugeben).
Wenn andererseits, entsprechend der Operation 304, Operationen des Hardwareprozessors 301 bestimmen, dass eine Verbindung zwischen Server-Peers (z. B. einem primären DHCP-Server und einem sekundären DHCP-Server) nicht innerhalb eines ersten Zeitrahmens hergestellt wurde, kann der Hardwareprozessor 301 die Anweisung 308 ausführen, um basierend auf der Bestimmung einen Partner-Ausgefallen-Betriebszustand bei einem oder mehreren der Server-Peers herzustellen (z. B. bei einem oder mehreren von dem primären DHCP-Server und dem sekundären DHCP-Server). In einigen Ausführungsformen kann der Partner-Ausgefallen-Betriebszustand nur bei den Server-Peers hergestellt werden, die als aktiv bestimmt werden (d. h., die in der Lage sind, Leases auszugeben).
Der Hardwareprozessor 301 kann die Anweisung 310 ausführen, um als Reaktion auf eine Client-Anforderung (z. B. eine DHCP-Client-Anforderung) und während eines hergestellten Partner-Ausgefallen-Betriebszustands ein kurzzeitiges Netzwerkadressen-Lease von einem der Server-Peers auszugeben (z. B. von einem der primären DHCP-Server oder sekundären DHCP-Server), bei denen das kurzzeitige Netzwerkadressen-Lease ein Netzwerkadressen-Lease mit einer Dauer zwischen 1 Sekunde und 5 Minuten ist.
4 ist ein Betriebsflussdiagramm, das ein anderes beispielhaftes Verfahren beschreibt, das auf das in Bezug in 3 beschriebenen Verfahren aufbaut, und das gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung implementiert werden kann.
Insbesondere stellt 4 eine beispielhafte Rechenkomponente 400 zum Orchestrieren von DHCP-Lease-Zuteilungen dar, gemäß Ausführungsformen der vorliegenden Offenbarung. Die Rechenkomponente 400 kann ganz oder teilweise in einem DHCP-Peer, in der Orchestrierungs-Engine 145, oder in einem anderen Element des Systems 100 ausgeführt sein. Die Rechenkomponente 400 kann einen Hardwareprozessor 401 und ein maschinenlesbares Speichermedium 402 aufweisen. Die Rechenkomponente 400 kann beispielsweise ein Servercomputer, ein Controller, oder eine andere ähnliche Rechenkomponente, die Daten verarbeiten kann, sein. Der Hardwareprozessor 401 kann eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen sein, die zum Wiederherstellen und Ausführen von Anweisungen, die auf einem maschinenlesbaren Speichermedium 402 gespeichert sind, geeignet sind. Der Hardwareprozessor 401 kann Anweisungen abrufen, decodieren und ausführen, wie beispielsweise Anweisungen zum Durchführen von 403 bis 412, um ein DHCP-Leasing gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung zu orchestrieren (z. B. kurzzeitige Leases in Szenarien auszugeben, in denen eine Verringerung eines Auftretens und einer Konsequenz von DHCP-Lease-Konflikten gewünscht wird).
Ein maschinenlesbares Speichermedium, wie beispielsweise ein maschinenlesbares Speichermedium 402, kann eine beliebige elektronische, magnetische, optische oder andere physikalische Speichervorrichtung sein, die ausführbare Anweisungen aufweist oder speichert. So kann das maschinenlesbare Speichermedium 402 beispielsweise ein Direktzugriffsspeicher (RAM), ein nichtflüchtiger RAM (NVRAM), ein elektrisch löschbarer programmierbarer Nur-Lese-Speicher (EEPROM), eine Speichervorrichtung, eine optische Platte, und dergleichen sein. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 402 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ keine sich transitorisch verbreitenden Signale umfasst. Wie nachstehend detailliert beschrieben wird, kann das maschinenlesbare Speichermedium 402 mit ausführbaren Anweisungen, beispielsweise den Anweisungen 403 bis 412, codiert sein, um das DHCP-Leasing gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung zu orchestrieren (z. B., um kurzzeitige Leases auszugeben in Szenarien, in denen eine Verringerung eines Auftretens und einer Konsequenz von DHCP-Lease-Konflikten gewünscht wird).
Ähnlich wie die Komponente 300 (3) kann die Rechenkomponente 400 einen oder mehrere DHCP-Server-Peers 141, 142 (1) verkörpern, oder in diesen verkörpert sein, oder kann in einem anderen Element des Systems 100 verkörpert sein, oder dieses verkörpern (1), das sich von einem der beiden DHCP-Server-Peers unterscheidet, das jedoch mit einem oder mehreren dieser DHCP-Server-Peers in Kommunikation steht, um die Funktionalität des Orchestrators 145 zu bewirken. Beispielsweise kann, wie in 4 gezeigt wird, der Hardwareprozessor 401 die Anweisung 403 ausführen, um einen Verbindungszustand zwischen Server-Peers (z. B. zwischen einem ausgewiesenen primären DHCP-Server und einem ausgewiesenen sekundären DHCP-Server) zu überwachen. Der Hardwareprozessor 401 kann die Anweisung 404 ausführen, um zu bestimmen, ob die erforderlichen Kommunikationsverbindungen zwischen Server-Peers innerhalb eines ersten Zeitrahmens (z. B. eines Zeitrahmens, der durch einem eingebetteten Zeitgeber vorgegeben wird) hergestellt wurden.
Wenn, entsprechend der Anweisung 404, Operationen des Hardwareprozessors 401 basierend auf der Überwachung bestimmen, dass eine Verbindung zwischen Server-Peers (z. B. einem primären DHCP-Server und einem sekundären DHCP-Server) innerhalb eines ersten Zeitrahmens hergestellt wurde, kann der Hardwareprozessor 401 kann die Anweisung 406 ausführen, um es den Server-Peers zu ermöglichen, gemäß einem kohärenten Betriebszustand zu arbeiten.
Wenn andererseits, entsprechend der Anweisung 404, Operationen des Hardwareprozessors 401 bestimmen, dass eine Verbindung zwischen Server-Peers (z. B. einem primären DHCP-Server und einem sekundären DHCP-Server) nicht innerhalb eines ersten Zeitrahmens hergestellt wurde, kann der Hardwareprozessor 401 die Anweisung 408 ausführen, um basierend auf der Bestimmung einen Partner-Ausgefallen-Betriebszustand bei einem oder mehreren der Server-Peers (z. B. bei einem oder mehreren von dem primären DHCP-Server und dem sekundären DHCP-Server) herzustellen. In einigen Ausführungsformen kann der Partner-Ausgefallen-Betriebszustand nur bei den Server-Peers, die als aktiv bestimmt wurden (d. h., in der Lage sind, Leases auszugeben), hergestellt werden.
Der Hardwareprozessor 401 kann die Anweisung 410 ausführen, um als Antwort auf eine Client-Anforderung (z. B. eine DHCP-Client-Anforderung) und während eines hergestellten Partner-Ausgefallen-Betriebszustands ein kurzzeitiges Netzwerkadressen-Leasing von einem der Server-Peers auszugeben (z. B. von einem von dem primären DHCP-Server oder sekundären DHCP-Server), bei denen das kurzzeitige Netzwerkadressen-Leasing ein Netzwerkadressen-Leasing mit einer Dauer zwischen 1 Sekunde und 5 Minuten ist.
Der Hardwareprozessor 401 kann die Anweisung 412 ausführen, um den Verbindungszustand zwischen Server-Peers weiter zu überwachen, und zu bestimmen, ob eine Verbindung zwischen den Server-Peers zu irgendeinem Zeitpunkt nach Ablauf des ersten Zeitrahmens wiederhergestellt oder auf andere Weise hergestellt wurde. Beispielsweise bestimmen, entsprechend der Anweisung 412, die Operationen des Hardwareprozessors 401 basierend auf der Überwachung, dass eine Verbindung zwischen einem primären DHCP-Server und einem sekundären DHCP-Server zu einem Zeitpunkt nach Ablauf eines ersten Zeitrahmens hergestellt wurde.
Wenn gemäß der Anweisung 412 Operationen des Hardwareprozessors 401 bestimmen, dass eine Verbindung zwischen Server-Peers (z. B. einem primären DHCP-Server und einem sekundären DHCP-Server) zu irgendeinem Zeitpunkt nach Ablauf des ersten Zeitrahmens wiederhergestellt oder auf andere Weise hergestellt wurde, können Operationen des Hardwareprozessors 401 einen kohärenten Betriebszustand bei den DHCP-Server-Peers herstellen (z. B. können Operationen des Hardware-Prozessors 401 die Anweisung 406 zurückgeben und ausführen, und den Server-Peers erlauben, gemäß einem kohärenten Betriebszustand zu arbeiten).
Wenn andererseits, entsprechend der Anweisung 412, Operationen des Hardwareprozessors 401 bestimmen, dass eine Verbindung zwischen Server-Peers (z. B. einem primären DHCP-Server und einem sekundären DHCP-Server) immer noch nicht hergestellt wurde, können Operationen des Hardware-Prozessors 401 die bei der Anweisung 408 hergestellten Partner-Ausgefallen-Betriebszustände beibehalten, und weiterhin konsistente Anweisungen 410 für kurzzeitige Leases ausgeben. Die Anweisung 412 kann kontinuierlich oder in ausgewiesenen Intervallen, wie in einem gegebenen Netzwerk gewünscht (wie durch einen Netzwerkadministrator bestimmt und konfiguriert werden kann), ausgeführt werden.
Obwohl sich die vorstehenden Offenbarungen auf Beispiele beziehen, bei denen die vorliegende Technologie zusätzlich zu DHCP-Netzwerkprotokollen und Ausfallsicherungs-Routinen in bestimmten Architekturumgebungen eingesetzt wird, sollte verstanden werden, dass die Technologie der vorliegenden Offenbarung in einer beliebigen Art von Netzwerk implementiert werden kann, das eine beliebige Art von Netzwerkadressen-Ausgabeprotokoll in einer beliebigen Topologie verwendet, in der zwei oder mehr Peer-Server dazu gestaltet sind, sich untereinander zu koordinieren, um zeitlich begrenzte Netzwerkadressen-Leases auszugeben. Es versteht sich ferner, dass die hierin offenbarte Orchestrierungstechnologie alternative oder zusätzlich zu aktuellen DHCP-Protokollfunktionen (einschließlich aktueller DHCP-Ausfallsicherungs-Protokolle) implementiert werden kann. Das heißt, die hierin offenbarte Orchestrierungstechnologie kann als Hülle oder auf andere Weise als Ergänzung zu bereits vorhandenen DHCP-Implementierungen implementiert werden. Daher ist in vielen Implementierungen der vorliegenden Technologie keine explizite Client-Konfiguration erforderlich, und die Orchestrierungstechnologie kann im Hintergrund des Netzwerks arbeiten, so dass DHCP-Clients für ihre Funktionalität und Merkmale blind sind.
5 zeigt ein Blockdiagramm eines beispielhaften Computersystems 500, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können. Das Computersystem 500 weist einen Bus 502 oder einen anderen Kommunikationsmechanismus zum Kommunizieren von Informationen auf, wobei einer oder mehrere Hardwareprozessoren 504 mit dem Bus 502 gekoppelt sind, um Informationen zu verarbeiten. Ein Hardwareprozessor (Hardwareprozessoren) 504 können beispielsweise einer oder mehrere Allzweck-Mikroprozessoren sein.
Das Computersystem 500 weist auch einen Hauptspeicher 506 auf, wie etwa einen Direktzugriffsspeicher (RAM), einen Cache und/oder andere dynamische Speichervorrichtungen, die mit dem Bus 502 gekoppelt sind, um Informationen und Anweisungen zu speichern, die von dem Prozessor 504 ausgeführt werden sollen. Der Hauptspeicher 506 kann auch zum Speichern temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Anweisungen, die vom Prozessor 504 ausgeführt werden sollen, verwendet werden. Wenn solche Anweisungen in Speichermedien, auf die der Prozessor 504 zugreifen kann, gespeichert werden, machen sie das Computersystem 500 zu einer Spezialmaschine, die dazu angepasst ist, die in den Anweisungen spezifizierten Operationen durchzuführen.
Das Computersystem 500 weist ferner einen Nur-Lese-Speicher (ROM) 508 oder eine andere statische Speichervorrichtung auf, die mit dem Bus 502 gekoppelt ist, um statische Informationen und Anweisungen für den Prozessor 504 zu speichern. Eine Speichervorrichtung 510, wie etwa eine Magnetplatte, eine optische Platte, oder ein USB-Stick (Flash-Laufwerk) usw., wird bereitgestellt und an den Bus 502 gekoppelt, um Informationen und Anweisungen zu speichern.
Im Allgemeinen kann sich das Wort „Komponente“, „Engine“, „System“, „Datenbank“, „Datenspeicher“ und dergleichen, wie hierin verwendet, auf Logik beziehen, die in Hardware oder Firmware enthalten ist, oder auf eine Sammlung von Softwareanweisungen, die möglicherweise Ein- und Ausstiegspunkte aufweisen und in einer Programmiersprache, wie beispielsweise Java, C oder C++, geschrieben sind. Eine Softwarekomponente kann kompiliert sein und mit einem ausführbaren Programm verknüpft sein, in einer dynamischen Linkbibliothek installiert, oder in einer interpretierten Programmiersprache, wie beispielsweise BASIC, Perl oder Python, geschrieben sein. Es versteht sich, dass Softwarekomponenten von anderen Komponenten oder von sich selbst aufgerufen werden können, und/oder als Reaktion auf erkannte Ereignisse oder Interrupts aufgerufen werden können. Softwarekomponenten, die für zur Ausführung auf Rechenvorrichtungen ausgelegt sind, können auf einem computerlesbaren Medium, wie etwa einer CD, einer digitalen Videodisk, einem Flash-Laufwerk, einer Magnetplatte oder einem anderen materiellen Medium, oder als digitaler Download bereitgestellt werden (und können ursprünglich in einem komprimierten oder installierbaren Format gespeichert sein, das vor der Ausführung installiert, dekomprimiert oder entschlüsselt werden muss). Ein solcher Softwarecode kann teilweise oder vollständig auf einer Speichervorrichtung der ausführenden Rechenvorrichtung zur Ausführung durch die Rechenvorrichtung gespeichert werden. Softwareanweisungen können in Firmware, wie etwa einem EPROM, eingebettet sein. Es versteht sich ferner, dass Hardwarekomponenten aus verbundenen Logikeinheiten, wie etwa Gates und Flip-Flops, bestehen können und/oder aus programmierbaren Einheiten, wie etwa programmierbaren Gate-Arrays oder Prozessoren, bestehen können.
Das Computersystem 500 kann die hierin beschriebenen Techniken unter Verwendung einer kundenspezifischen festverdrahteten Logik, eines oder mehrerer ASICs oder FPGAs, einer Firmware und/oder einer Programmlogik implementieren, die in Kombination mit dem Computersystem bewirkt oder programmiert, dass das Computersystem 500 ein Spezialzweckmaschine ist. Gemäß einer Ausführungsform werden die hierin enthaltenen Techniken von dem Computersystem 500 als Reaktion darauf ausgeführt, dass der oder die Prozessoren 504 eine oder mehrere Sequenzen einer oder mehrerer in dem Hauptspeicher 506 enthaltener Anweisungen ausführen. Solche Anweisungen können aus einem anderen Speichermedium, wie beispielsweise der Speichervorrichtung 510, in den Hauptspeicher 506 eingelesen werden. Die Ausführung der in dem Hauptspeicher 506 enthaltenen Anweisungssequenzen bewirkt, dass die Prozessoren 504 die hier beschriebenen Prozessschritte ausführen. In alternativen Ausführungsformen können festverdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden.
Der Begriff „nicht-transitorische Medien“ und ähnliche Begriffe, wie sie hierin verwendet werden, beziehen sich auf alle Medien, die Daten und/oder Anweisungen speichern, die bewirken, dass eine Maschine auf eine bestimmte Weise arbeitet. Solche nicht-transitorischen Medien können nichtflüchtige Medien und/oder flüchtige Medien umfassen. Nichtflüchtige Medien weisen beispielsweise optische oder magnetische Platten, wie etwa die Speichervorrichtung 510, auf. Flüchtige Medien weisen einen dynamischen Speicher, wie etwa den Hauptspeicher 506, auf. Übliche Formen von nicht-transitorischen Medien weisen beispielsweise eine Diskette, eine flexible Platte, eine Festplatte, ein Solid-State-Laufwerk, ein Magnetband oder ein anderes magnetisches Datenspeichermedium, eine CD-ROM, ein anderes optisches Datenspeichermedium, ein beliebiges physikalisches Medium mit Lochmustern, ein RAM, ein PROM und ein EPROM, ein FLASH-EPROM, NVRAM, einen beliebigen anderen Speicherchip oder eine beliebige andere Kassette, sowie vernetzte Versionen davon auf.
Nicht-transitorische Medien unterscheiden sich von Übertragungsmedien, können jedoch in Verbindung damit verwendet werden. Übertragungsmedien sind an der Übertragung von Informationen zwischen nicht-transitorischen Medien beteiligt. Beispielsweise weisen Übertragungsmedien Koaxialkabel, Kupferdraht und Glasfaser, einschließlich der Drähte, die den Bus 502 umfassen, auf. Übertragungsmedien können auch die Form von akustischen oder Lichtwellen annehmen, wie etwa die, welche während einer Funkwellen- und Infrarotdatenkommunikation generiert werden.
Das Computersystem 500 weist auch eine Kommunikationsschnittstelle 518 auf, die mit dem Bus 502 gekoppelt ist. Die Netzwerkschnittstelle 518 stellt eine Zweiwege-Datenkommunikationskopplung mit einer oder mehreren Netzwerkverbindungen bereit, die mit einem oder mehreren lokalen Netzwerken verbunden sind. Beispielsweise kann die Kommunikationsschnittstelle 518 eine ISDN- (Integrated Services Digital Network) Karte, ein Kabelmodem, ein Satellitenmodem, oder ein Modem, um eine Datenkommunikationsverbindung zu einem entsprechenden Typ einer Telefonleitung bereitzustellen, sein. Als ein anderes Beispiel kann die Netzwerkschnittstelle 518 eine LAN- (Local Area Network) Karte sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN bereitzustellen (oder eine WAN-Komponente zur Kommunikation mit einem WAN). Drahtlose Verbindungen können ebenfalls implementiert werden. In einer solchen Implementierung sendet und empfängt die Netzwerkschnittstelle 518 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme tragen, die verschiedene Arten von Informationen darstellen.
Eine Netzwerkverbindung stellt typischerweise über eines oder mehrere Netzwerke eine Datenkommunikation zu anderen Datenvorrichtungen bereit. Beispielsweise kann eine Netzwerkverbindung eine Verbindung über ein lokales Netzwerk zu einem Host-Computer oder zu Datenvorrichtungen bereitstellen, die von einem Internetdienstanbieter (ISP) betrieben werden. Der ISP wiederum stellt Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetz bereit, das heute allgemein als „Internet“ bezeichnet wird. Das lokale Netzwerk und das Internet verwenden beide elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen. Die Signale durch die verschiedenen Netzwerke und die Signale auf der Netzwerkverbindung und über die Kommunikationsschnittstelle 518, die die digitalen Daten zum und vom Computersystem 500 übertragen, sind beispielhafte Formen von Übertragungsmedien.
Das Computersystem 500 kann Nachrichten senden und Daten, einschließlich Programmcode, durch das Netzwerk, die Netzwerkverbindung und die Kommunikationsschnittstelle 518 empfangen. In dem Internetbeispiel kann ein Server einen angeforderten Code für ein Anwendungsprogramm über das Internet, den ISP, das lokale Netzwerk und die Kommunikationsschnittstelle 518 übertragen.
Der empfangene Code kann von dem Prozessor 504 ausgeführt werden, wenn er empfangen wird, und/oder in der Speichervorrichtung 510 oder einem anderen nichtflüchtigen Speicher zur späteren Ausführung gespeichert werden.
Alle von den in den vorhergehenden Abschnitten beschriebenen Prozessen, Verfahren und Algorithmen kann in Codekomponenten, die von einem oder mehreren Computersystemen oder Computerprozessoren ausgeführt werden, die Computerhardware umfassen, verkörpert sein, und vollständig oder teilweise durch diese automatisiert sein. Das eine oder die mehreren Computersysteme oder Computerprozessoren können auch dazu betrieben werden, die Leistung der relevanten Operationen einer „Cloud-Computing“-Umgebung oder als „Software as a Service“ (SaaS) zu unterstützen. Die Prozesse und Algorithmen können teilweise oder vollständig in anwendungsspezifischen Schaltungen implementiert sein. Die verschiedenen oben beschriebenen Merkmale und Verfahren können unabhängig voneinander verwendet werden, oder auf verschiedene Weise kombiniert werden. Unterschiedliche Kombinationen und Unterkombinationen sollen in den Geltungsbereich dieser Offenbarung fallen, und bestimmte Verfahren oder Prozessblöcke können in einigen Implementierungen weggelassen werden. Die hier beschriebenen Verfahren und Prozesse sind auch nicht auf eine bestimmte Reihenfolge beschränkt, und die dazugehörigen Blöcke oder Zustände können in anderen geeigneten Reihenfolgen ausgeführt werden, oder können parallel oder auf eine andere Weise ausgeführt werden. Blöcke oder Zustände können zu den offenbarten beispielhaften Ausführungsformen hinzugefügt oder daraus entfernt werden. Die Leistung bestimmter von den Operationen oder den Prozessen kann auf Computersysteme oder Computerprozessoren verteilt werden, die sich nicht nur auf einem einzelnen Computer befinden, sondern auf mehreren Computern bereitgestellt werden können.
Wie hierin verwendet, kann der Begriff „oder“ entweder in einem inklusiven oder einem exklusiven Sinne ausgelegt werden. Darüber hinaus darf die Beschreibung von Ressourcen, Operationen oder Strukturen im Singular nicht so gelesen werden, dass der Plural auszuschließen ist. Bedingte Sprache, wie unter anderem „kann“, „könnte“, „könnte“ oder „kann“, sollte, sofern ausdrücklich nichts anderes angegeben wird oder im verwendeten Kontext anderweitig verstanden wird, im Allgemeinen vermitteln, dass bestimmte Ausführungsformen bestimmte Merkmale, Elemente und/oder Schritte aufweisen, während andere Ausführungsformen diese nicht aufweisen.
Begriffe und Ausdrücke, die in diesem Dokument verwendet werden, und Variationen davon, sollten, sofern ausdrücklich nichts anderes angegeben wird, als offen und nicht als einschränkend ausgelegt werden. Adjektive, wie etwa „herkömmlich“, „traditionell“, „normal“, „standardmäßig", „bekannt“, und Begriffe mit ähnlicher Bedeutung, sollten nicht so ausgelegt werden, dass sie den beschriebenen Gegenstand auf einen gegebenen Zeitraum beschränken, oder auf einen Gegenstand, der zu einer gegebenen Zeit verfügbar ist, sondern sollten so gelesen werden, dass herkömmliche, traditionelle, normale oder standardmäßige Technologien umfasst sein können, die jetzt oder zu irgendeinem Zeitpunkt in der Zukunft verfügbar oder bekannt sein können. Das Vorhandensein von verbreiternden Wörtern und Phrasen, wie etwa „einem oder mehreren“, „zumindest“, „aber nicht beschränkt auf“, oder ähnlichen Phrasen in einigen Fällen bedeutet nicht, dass in Fällen, in denen solche verbreiternden Sätze fehlen können, der engere Fall beabsichtigt oder erforderlich ist.

Claims

Verfahren, umfassend: Überwachen eines Verbindungszustands zwischen einem primären DHCP-Server und einem sekundären DHCP-Server; Bestimmen, basierend auf der Überwachung, dass innerhalb eines ersten Zeitrahmens keine Verbindung zwischen dem primären DHCP-Server und dem sekundären DHCP-Server hergestellt wurde; Herstellen, basierend auf der Bestimmung, eines Partner-Ausgefallen-Betriebszustands auf einem oder mehreren von dem primären DHCP-Server und sekundären DHCP-Server; und Ausgeben, als Reaktion auf eine DHCP-Client-Anforderung und während eines hergestellten Partner-Ausgefallen-Betriebszustands, eines kurzzeitigen Netzwerkadressen-Leases von einem von dem primären DHCP-Server oder sekundären DHCP-Server, wobei das kurzzeitige Netzwerkadressen-Lease ein Netzwerkadressen-Lease mit einer Dauer zwischen 1 Sekunde und 5 Minuten ist.
Verfahren nach Anspruch 1, ferner umfassend: Bestimmen, basierend auf der Überwachung, dass eine Verbindung zwischen dem primären DHCP-Server und dem sekundären DHCP-Server zu einem Zeitpunkt nach Ablauf eines ersten Zeitrahmens hergestellt wurde; und Herstellen, nachdem festgestellt wurde, dass eine Verbindung zwischen dem primären DHCP-Server und dem sekundären DHCP-Server hergestellt wurde, eines kohärenten Betriebszustands auf jedem von dem primären DHCP-Server und sekundären DHCP-Server.
Verfahren nach Anspruch 1, wobei das Herstellen eines Partner-Ausgefallen-Betriebszustands an einem oder mehreren von dem primären DHCP-Server und sekundären DHCP-Server umfasst: Bestimmen eines Aktivitätszustands des primären DHCP-Servers und eines Aktivitätszustands des sekundären DHCP-Servers; und Herstellen eines Partner-Ausgefallen-Betriebszustands auf jedem DHCP-Server, der als aktiv bestimmt wurde.
Verfahren nach Anspruch 1, wobei der erste Zeitrahmen durch einen Zustandszeitgeber getaktet wird, nachdem er durch das Auftreten eines Auslöseereignisses ausgelöst wurde.
Verfahren nach Anspruch 1, wobei der erste Zeitrahmen zwischen 30 Sekunden und 120 Sekunden liegt.
Verfahren nach Anspruch 1, wobei der erste Zeitrahmen zwischen 50 Sekunden und 70 Sekunden liegt.
Verfahren nach Anspruch 1, wobei der erste Zeitrahmen 60 Sekunden beträgt.
Verfahren nach Anspruch 1, wobei die Dauer des kurzzeitigen Netzwerkadressen-Leases 5 Minuten beträgt.
Verfahren nach Anspruch 1, wobei die Dauer der kurzzeitigen Netzwerkadressen-Leases 10 Sekunden beträgt.
System, umfassend: ein Computersystem mit einem oder mehreren Prozessoren, die programmiert sind zum: Überwachen eines Verbindungszustands zwischen einem primären DHCP-Server und einem sekundären DHCP-Server; Bestimmen, basierend auf der Überwachung, dass innerhalb eines ersten Zeitrahmens keine Verbindung zwischen dem primären DHCP-Server und dem sekundären DHCP-Server hergestellt wurde; Herstellen, basierend auf der Bestimmung, eines Partner-Ausgefallen-Betriebszustands auf einem oder mehreren von dem primären DHCP-Server und sekundären DHCP-Server; und Zuweisen, während eines hergestellten Partner-Ausgefallen-Betriebszustands, eines kurzzeitigen Netzwerkadressen-Leases von einem von dem primären DHCP-Server oder sekundären DHCP-Server, wobei das kurzzeitige Netzwerkadressen-Lease ein Netzwerkadressen-Lease mit einer Dauer zwischen 1 Sekunde und 5 Minuten ist.
System nach Anspruch 10, wobei der eine oder die mehreren Prozessoren ferner programmiert sind zum: Bestimmen, basierend auf der Überwachung, dass zu einem Zeitpunkt nach Ablauf eines ersten Zeitrahmens eine Verbindung zwischen dem primären DHCP-Server und sekundären DHCP-Server hergestellt wurde; und Herstellen, nach einer Bestimmung, dass eine Verbindung zwischen dem primären DHCP-Server und dem sekundären DHCP-Server hergestellt wurde, eines kohärenten Betriebszustands an jedem von dem primären DHCP-Server und sekundären DHCP-Server.
System nach Anspruch 10, wobei das Herstellen eines Partner-Ausgefallen-Betriebszustands an einem oder mehreren von dem primären DHCP-Server und sekundären DHCP-Server umfasst: Bestimmen eines Aktivitätszustands des primären DHCP-Servers und eines Aktivitätszustands des sekundären DHCP-Servers; und Herstellen eines Partner-Ausgefallen-Betriebszustands auf jedem DHCP-Server, der als aktiv bestimmt wurde.
System nach Anspruch 10, wobei der erste Zeitrahmen durch einen Zustandszeitgeber getaktet wird, nachdem er durch das Auftreten eines Auslöseereignisses ausgelöst wurde.
System nach Anspruch 10, wobei der erste Zeitrahmen zwischen 30 Sekunden und 120 Sekunden liegt.
System nach Anspruch 10, wobei der erste Zeitrahmen zwischen 50 Sekunden und 70 Sekunden liegt.
System nach Anspruch 10, wobei der erste Zeitrahmen 60 Sekunden beträgt.
System nach Anspruch 10, wobei die Dauer des kurzzeitigen Netzwerkadressen-Leases 5 Minuten beträgt.
System nach Anspruch 10, wobei die Dauer der kurzzeitigen Netzwerkadressen-Leases 10 Sekunden beträgt.
Computerlesbares Speichermedium, das Anweisungen umfasst, die bei Ausführung auf einem Computersystem das Computersystem veranlassen zum: Überwachen eines Verbindungszustands zwischen einem primären DHCP-Server und einem sekundären DHCP-Server; Bestimmen, basierend auf der Überwachung, dass innerhalb eines ersten Zeitrahmens keine Verbindung zwischen dem primären DHCP-Server und dem sekundären DHCP-Server hergestellt wurde; Herstellen, basierend auf der Bestimmung, eines Partner-Ausgefallen-Betriebszustands auf einem oder mehreren von dem primären DHCP-Server und sekundären DHCP-Server; und Zuweisen, als Reaktion auf eine DHCP-Client-Anforderung und während eines hergestellten Partner-Ausgefallen-Betriebszustands, von mehreren kurzzeitigen Netzwerkadressen-Leases zu mehreren anfordernden DHCP-Clients, wobei die mehreren kurzzeitigen Netzwerkadressen-Leases von gleicher Dauer sind, wobei die Dauer zwischen 1 Sekunde und 5 Minuten liegt.
Computerlesbares Speichermedium nach Anspruch 19, wobei das Herstellen eines Partner-Ausgefallen-Betriebszustands auf einem oder mehreren von dem primären DHCP-Server und sekundären DHCP-Server umfasst: Bestimmen eines Aktivitätszustands des primären DHCP-Servers und eines Aktivitätszustands des sekundären DHCP-Servers; und Herstellen eines Partner-Ausgefallen-Betriebszustands auf jedem DHCP-Server, der als aktiv bestimmt wurde.