DE112016001657T5

DE112016001657T5 - Multi-Tenant-Sensitiver DHCP-Mechanismus für Cloud-Netzwerke

Info

Publication number: DE112016001657T5
Application number: DE112016001657.3T
Authority: DE
Inventors: Liang Rong; Gang Tang; Zijin Tao; MingShuang Xian
Original assignee: International Business Machines Corp
Current assignee: Kyndryl Inc
Priority date: 2015-05-22
Filing date: 2016-05-20
Publication date: 2017-12-21
Also published as: WO2016188375A1; US20180077114A1; US11956207B2; US20190356630A1; GB201720489D0; US20160344687A1; JP6670025B2; US9887961B2; GB2555740B; US20230108856A1; US20210136031A1; CN107615716A; US10904206B2; GB2555740A; US10425381B2; JP2018519687A; CN107615716B; US11546293B2; GB2555740C

Abstract

Ein Ansatz beinhaltet ein Bereitstellen einer Multi-Tenancy-Unterstützung durch ein DHCP-Protokoll (Dynamic Host Configuration Protocol). Der Ansatz beinhaltet ein Empfangen eines DHCP-Pakets, ein Einfügen von Tenant-spezifischen Optionsdaten in das DHCP-Paket und ein Übertragen des DHCP-Pakets mit den Tenant-spezifischen Optionsdaten.

Description

TECHNISCHES GEBIET
Der technische Charakter der vorliegenden Erfindung bezieht sich im Allgemeinen auf einen DHCP-Mechanismus (Dynamic Host Configuration Protokol) für Cloud-Netzwerke und im Besonderen auf einen DHCP-Mechanismus für Multi-Tenant-Netzwerke in der Cloud.
HINTERGRUND
Multi-Tenant-Unterstützung ist eine grundlegende Anforderung für Cloud-Rechenzentrumsnetzwerke und erfordert Dienstisolierungen zwischen verschiedenen Tenants. Eine Art der Dienstisolierung ist eine Adressisolierung, die verschiedenen Tenants überlappende Adressen bereitstellt. Bei aktuellen Standards wie z. B. den IETF NVO3-Standards (Internet Engineering Task Force Network Virtualization Overlays) wird eine virtuelle Netzwerkkennung (Virtual Network Identifier, VNID) bereitgestellt, um die Trennung von virtuellen Netzwerken verschiedener Tenants in virtuelle Overlay-Netzwerke zu unterstützen. Adressierung und Host-Konfiguration können durch das DHCP-Protokoll erfolgen, das Hosts Konfigurationsparameter bereitstellt.
Das DHCP-Protokoll weist zwei Komponenten auf, ein Protokoll zum Bereitstellen Host-spezifischer Konfigurationsparameter von einem DHCP-Server an einen Host und einen Mechanismus zum Zuordnen von Netzwerkadressen zu Hosts. Das DHCP-Protokoll unterstützt lediglich eine Konfiguration in einem einzigen Adressraum. Aus diesem Grund kann jeder DHCP-Server nur mit Konfigurationsparametern eines einzigen Adressraums konfiguriert werden (d. h. das Protokoll kann keine überlappenden Adressräume unterstützen). Somit kann der Client des DHCP-Servers nur eine Adresse aus diesem einzigen Adressraum beziehen.
Um verschiedenen Tenants in Cloud-Rechenzentrumsnetzwerken überlappende Adressen bereitzustellen, müssen für jeden Tenant getrennte DHCP-Server eingerichtet werden. Dies wird in der Regel realisiert, indem ein eindeutiger DHCP-Server in einem getrennten LINUX-Namensraum eingerichtet wird (d. h. durch eine Virtualisierung auf der Ebene des Betriebssystems) oder indem mehrere DHCP-Server in verschiedenen Hosts ausgeführt werden. Bei diesen Realisierungen gibt es nur einen DHCP-Server für einen Tenant, und die Adressen, die verschiedenen Tenants bereitgestellt werden, können sich überlappen.
Allerdings ist das Konfigurieren von mehreren Linux-Namensräumen komplex und ressourcen-/rechenintensiv, da in der Regel nur eine physische Netzwerkschnittstellenkarte verwendet wird, um eine Verbindung mit dem Datennetzwerk herzustellen. Darüber hinaus erfordern mehrere Linux-Namensräume, dass mehrere virtuelle Netzwerkschnittstellen erzeugt und mit einer Ethernet-Bridge verbunden werden, um diese Namensräume zu bedienen, und dass mehrere DHCP-Serverinstanzen ausgeführt werden, von denen jeder nur einen einzigen Tenant oder sogar nur ein einziges Netzwerksegment bedient. Zudem mangelt es an Skalierbarkeit, wenn die Anzahl der Tenants in die Tausende geht. Des Weiteren unterstützen viele herkömmliche Betriebssysteme (z. B. WINDOWS SERVER und herkömmliche LINUX-Kernel vor 2.6.32.xx) keine LINUX-Namensräume.
Außerdem gibt es auch dann keine Interoperabilität zwischen Overlay-Netzwerken, wenn Overlay-Kapselungsprotokolle für eine Multi-Tenant-Unterstützung verwendet werden, wie beispielsweise VLAN (Virtual Local Area Network), VXLAN (Virtual Extensible Local Area Network), DOVE (Distributed Overlay Virtual Ethernet), NVGRE (Network Virtualization using Generic Routing Encapsulation), STT (Stateless Transport Tunneling), GENEVE (Generic Network Virtualization Encapsulation) usw. Aus diesem Grund stellen derartige Systeme nicht die Flexibilität bereit, die für eine Multi-Tenant-Unterstützung benötigt wird.
KURZDARSTELLUNG
Gemäß einem ersten Aspekt der Erfindung wird ein Verfahren bereitgestellt, das ein Empfangen eines DHCP-Pakets beinhaltet. Das Verfahren beinhaltet weiterhin ein Einfügen von Tenant-spezifischen Optionsdaten in das DHCP-Paket. Das Verfahren beinhaltet des Weiteren ein Übertragen des DHCP-Pakets mit den Tenant-spezifischen Optionsdaten.
Gemäß einem weiteren Aspekt der Erfindung wird ein Computerprogrammprodukt bereitgestellt, das ein computerlesbares Speichermedium mit in dem Speichermedium enthaltenen computernutzbarem Programmcode aufweist. Der Programmcode ist kein flüchtiges Signal per se, und die Programmbefehle sind durch eine Datenverarbeitungseinheit lesbar, um die Datenverarbeitungseinheit zum Durchführen eines Verfahrens zu veranlassen, das ein Empfangen eines DHCP-Pakets beinhaltet. Das Verfahren beinhaltet des Weiteren ein Feststellen, dass das DHCP-Paket Tenant-spezifische Optionsdaten aufweist. Das Verfahren beinhaltet des Weiteren ein Auswählen eines Adressraums auf Grundlage der Tenant-spezifischen Optionsdaten.
Gemäß einem weiteren Aspekt der Erfindung wird ein Computerprogramm bereitgestellt, das ein computerlesbares Speichermedium mit in dem Speichermedium enthaltenen computernutzbarem Programmcode aufweist. Der Programmcode ist kein flüchtiges Signal per se, und die Programmbefehle sind durch eine Datenverarbeitungseinheit lesbar, um die Datenverarbeitungseinheit zum Durchführen eines Verfahrens zu veranlassen, das ein Empfangen eines DHCP-Pakets beinhaltet, welches Tenant-spezifische Optionsdaten aufweist. Das Verfahren beinhaltet des Weiteren ein Lokalisieren eines Tenant-Adressraums auf Grundlage der Tenant-spezifischen Optionsdaten. Das Verfahren beinhaltet des Weiteren ein Erhalten einer virtuellen Netzwerkkennung von einem virtuellen Zugangspunkt (Virtual Access Point, VAP). Das Verfahren beinhaltet des Weiteren ein Erhalten einer Subnetzkonfiguration, die der erhaltenen virtuellen Netzwerkkennung entspricht. Das Verfahren beinhaltet des Weiteren ein Zuordnen einer Internetprotokoll-Adresse (IP-Adresse), die der erhaltenen Subnetzkonfiguration entspricht.
Gemäß einem weiteren Aspekt der Erfindung wird ein System bereitgestellt, das eine Zentraleinheit (CPU), einen computerlesbaren Arbeitsspeicher und ein computerlesbares Speichermedium beinhaltet. Zusätzlich beinhaltet das System einen oder mehrere Programmbefehle. Das System beinhaltet Programmbefehle, um Multi-Tenancy-Daten in ein DHCP-Paket einzufügen. Das System beinhaltet des Weiteren Programmbefehle, um das DHCP-Paket mit den Multi-Tenancy-Daten zu übertragen. Die Programmbefehle werden auf dem computerlesbaren Speichermedium gespeichert, um über den computerlesbaren Arbeitsspeicher durch die CPU ausgeführt zu werden.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Konfigurieren eines Datenrahmenformats für eine Tenant-spezifische DHCP-Option bereitgestellt, das ein Konfigurieren eines ersten Felds des Datenrahmenformats für eine Tenant-spezifische DHCP-Option beinhaltet, um einen Overlay-Protokolltyp anzugeben, der für die Tenant-Isolierung verwendet wird. Das Verfahren beinhaltet des Weiteren ein Konfigurieren eines zweiten Felds des Datenrahmenformats für eine Tenant-spezifische DHCP-Option, um einen Tenant eindeutig zu identifizieren. Das Verfahren beinhaltet des Weiteren ein Konfigurieren eines dritten Felds des Datenrahmenformats für eine Tenant-spezifische DHCP-Option, um ein virtuelles Netzwerk anzugeben.
Ausführungsformen der vorliegenden Erfindung stellen Systeme und Verfahren bereit, die technische Merkmale wie z. B. einen neuartigen DHCP-Mechanismus für Multi-Tenant-Netzwerke in der Cloud realisieren, der das Problem der Adressisolierung für verschiedene Tenants auf wirkungsvollere Art behebt als gegenwärtige Systeme. So sind bei Ausführungsformen des DHCP-Mechanismus zum Beispiel Tenant-spezifische Daten in einem DHCP-Paket enthalten, um einen Gültigkeitsbereich eines Adressraums anzugeben (Scoping). Der Vorteil der oben erwähnten technischen Lösung für Ausführungsformen des DHCP-Mechanismus besteht darin, dass sie abwärtskompatibel ist und keine nachteiligen Auswirkungen auf gegenwärtig realisierte Systeme für eine DHCP-Verarbeitung hat. Wenn die Tenant-spezifischen Daten nicht in dem DHCP-Paket bereitgestellt werden, kann außerdem die DHCP-Verarbeitung so erfolgen, wie dies bei gegenwärtigen Systemen der Fall ist. Verglichen mit einem Adressbereich in dem DHCP-Paket, der einen globalen Gültigkeitsbereich aufweist, ist gemäß den technischen Merkmalen von Ausführungsformen des DHCP-Mechanismus der Adressbereich des DHCP-Pakets zudem lokal für einen Tenant-Adressraum gültig, wenn die Tenant-spezifischen DHCP-Daten verwendet werden.
Bei Verwendung des DHCP-Mechanismus von Ausführungsformen der vorliegenden Erfindung kann zudem ein einziger DHCP-Server DHCP-Dienste auch dann für mehrere Tenants bereitstellen, wenn sich deren Adressbereich überlappt. Somit ist im Gegensatz zu gegenwärtigen Systemen keine Isolierung auf Betriebssystemebene (z. B. des LINUX-Namensraums) notwendig. Des Weiteren vereinfachen Ausführungsformen des DHCP-Mechanismus die Bereitstellung von DHCP-Diensten in Multi-Tenant-Rechenzentren in der Cloud. Die technischen Merkmale von Ausführungsformen des DHCP-Mechanismus beheben auch das Problem der Interoperabilität, wenn ein Rechenzentrumsnetzwerk heterogene virtuelle Umgebungen aufweist, die von verschiedenen Anbietern angeboten werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird in der folgenden ausführlichen Beschreibung mit Blick auf die erwähnte Mehrzahl von Zeichnungen beschrieben, wobei es sich um Beispiele für beispielhafte Ausführungsformen der vorliegenden Erfindung handelt, die den inhaltlichen Geltungsumfang nicht beschränken.
1 stellt einen Cloud-Datenverarbeitungsknoten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
2 stellt eine Cloud-Datenverarbeitungsumgebung gemäß Ausführungsformen der vorliegenden Erfindung dar.
3 stellt Abstraktionsmodellschichten gemäß Ausführungsformen der vorliegenden Erfindung dar.
4 stellt einen Cloud-Datenverarbeitungsknoten gemäß einer weiteren Ausführungsform der vorliegenden Erfindung dar.
5 ist ein Datenrahmenformat für eine Tenant-spezifische DHCP-Option gemäß Aspekten der vorliegenden Erfindung.
6 stellt einen beispielhaften Ablauf (Aktivitätenplan) einer DHCP-Paketverarbeitung gemäß Aspekten der vorliegenden Erfindung dar.
7 stellt einen beispielhaften Ablauf einer Adresszuordnungsverarbeitung gemäß Aspekten der vorliegenden Erfindung dar.
8 stellt einen beispielhaften Ablauf einer DHCP-Subnetzauswahl-Unterstützung gemäß Aspekten der vorliegenden Erfindung dar.
AUSFÜHRLICHE BESCHREIBUNG
Der technische Charakter der vorliegenden Erfindung bezieht sich im Allgemeinen auf einen DHCP-Mechanismus (Dynamic Host Configuration Protocol) für Cloud-Netzwerke und im Besonderen auf einen DHCP-Mechanismus für Multi-Tenant-Netzwerke in der Cloud. Genauer gesagt stellen Ausführungsformen der vorliegenden Erfindung Systeme und Verfahren bereit, die technische Merkmale wie z. B. einen neuartigen DHCP-Mechanismus für Multi-Tenant-Netzwerke in der Cloud realisieren, der das Problem der Adressisolierung für verschiedene Tenants auf wirkungsvollere Art behebt als gegenwärtige Systeme. So sind bei Ausführungsformen des DHCP-Mechanismus zum Beispiel Tenant-spezifische Daten in einem DHCP-Paket enthalten, um einen Gültigkeitsbereich eines Adressraums anzugeben (Scoping).
Der Vorteil der oben erwähnten technischen Lösung für Ausführungsformen des DHCP-Mechanismus besteht darin, dass sie abwärtskompatibel ist und keine nachteiligen Auswirkungen auf gegenwärtig realisierte Systeme für eine DHCP-Verarbeitung hat. Wenn die Tenant-spezifischen Daten nicht in dem DHCP-Paket bereitgestellt werden, kann außerdem die DHCP-Verarbeitung so erfolgen, wie dies bei gegenwärtigen Systemen der Fall ist. Verglichen mit einem Adressbereich in dem DHCP-Paket, der einen globalen Gültigkeitsbereich aufweist, ist gemäß den technischen Merkmalen von Ausführungsformen des DHCP-Mechanismus der Adressbereich des DHCP-Pakets zudem lokal für einen Tenant-Adressraum gültig, wenn die Tenant-spezifischen DHCP-Daten verwendet werden.
Bei Verwendung des DHCP-Mechanismus von Ausführungsformen der vorliegenden Erfindung kann zudem ein einziger DHCP-Server auch dann DHCP-Dienste für mehrere Tenants bereitstellen, wenn sich deren Adressbereiche miteinander überlappen. Somit ist im Gegensatz zu gegenwärtigen Systemen keine Isolierung auf Betriebssystemebene (z. B. des LINUX-Namensraums) notwendig. Des Weiteren vereinfachen Ausführungsformen des DHCP-Mechanismus die Bereitstellung von DHCP-Diensten in Multi-Tenant-Rechenzentren in der Cloud. Die technischen Merkmale von Ausführungsformen des DHCP-Mechanismus beheben auch das Problem der Interoperabilität, wenn ein Rechenzentrumsnetzwerk heterogene virtuelle Umgebungen aufweist, die von verschiedenen Anbietern angeboten werden.
Bei weiteren Ausführungsformen des DHCP-Mechanismus wird ein einziger DHCP-Server, der einen Adressierungsdienst bereitstellt, in einem Cloud-Rechenzentrum auf Grundlage von Overlay-Netzwerken für mehrere Tenants verwendet. Ausführungsformen des DHCP-Mechanismus tragen zur Lösung der folgenden technischen Probleme von DHCP-Systemen bei:

(i) Adressraumisolierung für verschiedene Tenants bei Vorhandensein eines DHCP-Relay-Agenten;
(ii) Adress-Subnetzauswahl für Tenants in virtuellen Netzwerken mit Hilfe einer NVA (Network Virtualization Authority); und
(iii) Allgemeine DHCP-Dienstbereitstellung für heterogene virtuelle Umgebungen, die ein herkömmliches physisches Infrastrukturnetzwerk und Overlay-Netzwerke mit unterschiedlichen Kapselungsprotokollen (VLAN, VXLAN, NVGRE, STT oder GENEVE) aufweisen.

Des Weiteren unterbrechen Ausführungsformen des DHCP-Mechanismus nicht gegenwärtige DHCP-Interaktionen zwischen Clients und einem Server wie z. B. DHCP DISCOVER, OFFER, REQUEST, ACKNOWLEDGMENT, RELEASE usw. Vielmehr funktionieren die DHCP-Interaktionen auch in Ausführungsformen des DHCP-Mechanismus der vorliegenden Erfindung.
Bei zusätzlichen technischen Merkmalen von Ausführungsformen des DHCP-Mechanismus zeigt die Tenant-spezifische Option einem DHCP-Server an, dass er eine IP-Adresse in einem zugehörigen Adressraum zuordnen soll, die für diesen Tenant spezifisch ist. Somit kann ein einziger DHCP-Server eine Mehrzahl von Tenants bedienen, und jeder Tenant kann seinen eigenen IP-Adresspool für eine Zuordnung aufweisen. Darüber hinaus ist jeder Pool eines Tenants vollständig unabhängig und kann sich mit einem weiteren Pool (d. h. mit demselben IP-Adresspool) eines anderen Tenants überlappen. Die Tenant-spezifische Option wird durch einen DHCP-Relay-Agenten einem DHCP-Header hinzugefügt.
Bei den technischen Lösungen der vorliegenden Erfindung weist die Tenant-spezifische Option die folgenden Felder auf:

(i) Option: muss einen eindeutigen Wert haben, der in bekannten DHCP-Systemen verwendet wird;
(ii) Länge: die Gesamtzahl der Bytes der verbleibenden Felder;
(iii) Transport-Agent: ein Codierwert, der den für die Tenant-Isolierung verwendeten Overlay-Protokolltyp angibt (z. B. VLAN, VXLAN, DOVE, NVGRE, STT usw.);
(iv) Tenant-ID: eine UUID (Universally Unique Identifier), die dazu verwendet wird, einen Tenant zu identifizieren; und
(v) virtuelles Netzwerk VNID: bezeichnet ein virtuelles Netzwerk, das eine Abstraktion eines L2-Segments oder einer Broadcast-Domäne ist. Ein Tenant kann mehrere virtuelle Netzwerke aufweisen.

Bei weiteren Ausführungsformen ist die Tenant-spezifische Option als eine Unteroption einer DHCP-Relay-Agenten-Datenoption (Option 82, RFC 3046) realisiert. Bei Ausführungsformen fügt die Realisierung der standardmäßigen Option 82 eine Unteroption hinzu, um die vorgeschlagene Tenant-spezifische Option zu enthalten. Die Tenant-spezifische Option wird durch den DHCP-Relay-Agenten dem DHCP-Header hinzugefügt, der in einem Netzvirtualisierungsrand (Network Virtualization Edge, NVE) ausgeführt wird. Da sich der NVE an einem Rand des Overlay-Netzwerks befindet, lässt sich der Codierwert eines Transport-Agenten in der Tenant-spezifischen Option auf einfache Weise erhalten. So kann die VNID zum Beispiel von einem VAP erhalten werden, mit dem der DHCP-Client verbunden ist.
Um bei Ausführungsformen des DHCP-Mechanismus eine Multi-Tenant-Unterstützung zu ermöglichen, unterstützt der DHCP-Server zwei Arten von Adressräumen: einen globalen Adressraum und einen Tenant-Adressraum. Der globale Adressraum ist mit einem bekannten DHCP-Mechanismus kompatibel, bei dem das DHCP-Paket keine Tenant-spezifische Option enthält. In dem globalen Adressraum eines gegenwärtigen DHCP-Mechanismus können sich die IP-Adressbereiche nicht überlappen; in der technischen Lösung unter Verwendung von Ausführungsformen des DHCP-Mechanismus hat dagegen jeder Tenant einen spezifischen Adresspool in dem Tenant-Adressraum, und der Adressbereich in dem DHCP-Mechanismus kann sich mit dem Adresspool eines anderen Tenants überlappen.
Wenn die Nachricht DHCP_DISCOVER nicht die Tenant-spezifische Option enthält, führt bei Ausführungsformen des DHCP-Mechanismus ein DHCP-Server eine bekannte DHCP-Verarbeitung durch. Wenn die Nachricht DHCP_DISCOVER hingegen die Tenant-spezifische Option enthält, wird die Tenant-spezifische Option dazu verwendet, den Tenant-Adressraum und den IP-Bereich zu lokalisieren. Der DHCP-Server lokalisiert den Adressraum, welcher der Tenant-ID in der Tenant-spezifischen Option entspricht. Wenn die Nachricht DHCP_DISCOVER eine Option für die Subnetzauswahl (Option 118) oder eine Unteroption für die Verbindungsauswahl (Unteroption 5 in Option 82) aufweist, ordnet der DHCP-Server eine Adresse aus diesem Subnetz zu. Wenn die Nachricht DHCP_DISCOVER hingegen keine Option für die Subnetzauswahl oder eine Unteroption für die Verbindungsauswahl aufweist, wird ein IP-Bereich einer VNID zugewiesen, und der DHCP-Server sucht den der VNID entsprechenden IP-Bereich in der Tenant-spezifischen Option. Ausführungsformen des DHCP-Mechanismus der vorliegenden Erfindung können des Weiteren einen DHCP-Server beinhalten, der ein Abgleichkriterium oder ACL-Regeln für die Tenant-spezifische Option in der Konfiguration verwendet, um den Tenant-Adressraum zu lokalisieren.
Bei Ausführungsformen des DHCP-Mechanismus der vorliegenden Erfindung kann ein Cloud-Dienstanbieter (Cloud Service Provider, CSP) verschiedene Overlay-Netzwerklösungen unterschiedlicher Hersteller nutzen, um ein Multi-Tenant-Rechenzentrum in der Cloud zu realisieren. Somit können Ausführungsformen des DHCP-Mechanismus verwendet werden, wenn die Netzwerkgröße zunimmt. In einem Beispiel kann der CSP über zwei Overlay-Netzwerke verfügen, und diese Overlay-Netzwerke können auf einem gemeinsamen physischen Netzwerk aufbauen. Ein Tenant kann virtuelle Maschinen (VMs) in beiden Overlay-Netzwerken aufweisen. Somit gibt es in Ausführungsformen des neuartigen DHCP-Mechanismus eine komfortable Möglichkeit, den DHCP-Server in dem physischen Netzwerk bereitzustellen, falls ein Tenant virtuelle Maschinen aufweist, die mehrere heterogene Overlay-Netzwerke überspannen. Das Transport-Agenten-Feld in einer Tenant-spezifischen Option dient zur Bereitstellung des DHCP-Servers.
Da der Gültigkeitsbereich einer VNID auf ein einziges Overlay-Netzwerk beschränkt ist, kann in solchen heterogenen Netzwerken der DHCP-Server bei Ausführungsformen des DHCP-Mechanismus den Transport-Agenten zusammen mit der VNID in der Tenant-spezifischen Option als Klassifizierungsfelder verwenden, um den IP-Bereich abzuleiten, aus dem IP-Adressen zugeordnet werden. Um einen IP-Adressverwaltungsdienst für heterogene virtuelle Overlay-Netzwerke mit einem einzigen DHCP-Server in einem Cloud-Rechenzentrum zu erhalten, kann somit als eine Dimension in den Klassifizierungskriterien ein Transport-Agent hinzugefügt werden, um den IP-Adressbereich in dem Tenant-Adressraum zu lokalisieren.
Obwohl diese Offenbarung eine ausführliche Beschreibung der Cloud-Datenverarbeitung beinhaltet, sollte vorab klar sein, dass die Realisierung der hier dargelegten Methoden nicht auf eine Cloud-Datenverarbeitungsumgebung beschränkt ist. Vielmehr können Ausführungsformen der vorliegenden Erfindung in Verbindung mit jeder anderen Art von Datenverarbeitungsumgebung nach dem derzeitigen oder künftigen Stand der Technik realisiert werden.
Eine Cloud-Datenverarbeitung ist ein Modell einer Dienstbereitstellung, um einen komfortablen, bedarfsgesteuerten Netzwerkzugriff auf einen gemeinsam genutzten Vorrat von konfigurierbaren Datenverarbeitungsressourcen (z. B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Arbeitsspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste) zu ermöglichen, die mit möglichst geringem Verwaltungsaufwand und möglichst wenig Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann z. B. mindestens fünf Merkmale, mindestens drei Dienstmodelle und mindestens vier Bereitstellungsmodelle beinhalten.
Die Merkmale lauten wie folgt:
Bedarfsgesteuerte Selbstbedienung: Ein Cloud-Verbraucher kann sich einseitig und automatisch nach Bedarf Datenverarbeitungsfähigkeiten wie z. B. Serverzeit und Netzwerkspeicher bereitstellen, ohne dass hierfür eine menschliche Interaktion mit dem Anbieter des Dienstes notwendig ist.
Breiter Netzwerkzugriff: Fähigkeiten werden über ein Netzwerk zur Verfügung gestellt und über Standardmechanismen zugeordnet, die eine Verwendung durch verschiedenartige Thin- oder Thick-Client-Plattformen ermöglichen (z. B. Mobiltelefone, Laptops und PDAs).
Ressourcenbündelung: Die Datenverarbeitungsressourcen des Anbieters sind gebündelt, um unter Verwendung eines Multi-Tenant-Modells mehreren Verbrauchern bereitzustehen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen bzw. neu zugewiesen werden. Standortunabhängigkeit ist insofern gegeben, als der Verbraucher im Allgemeinen den genauen Standort der bereitgestellten Ressourcen weder kontrolliert noch kennt, jedoch unter Umständen in der Lage ist, auf einer höheren Abstraktionsebene (z. B. Land, Bundesland oder Rechenzentrum) einen Standort festzulegen.
Flexible Anpassungsfähigkeit: Fähigkeiten lassen sich schnell und elastisch (in einigen Fällen automatisch) bereitstellen, um eine rasche Skalierung nach oben zu ermöglichen, sowie – für eine rasche Skalierung nach unten – schnell wieder freigegeben zu werden. Für den Verbraucher scheinen die zur Bereitstellung verfügbaren Fähigkeiten häufig unbegrenzt zu sein und können jederzeit in jeder beliebigen Menge erworben werden.
Dienstmessung: Cloud-Systeme kontrollieren und optimieren die Ressourcennutzung automatisch, indem sie in einer bestimmten, der Art des Dienstes angemessenen Abstraktionsschicht eine Messfunktion nutzen (z. B. Speicherung, Verarbeitung, Bandbreite und aktive Benutzerkonten). Die Ressourcennutzung kann überwacht, kontrolliert und protokolliert werden, wodurch sowohl für den Anbieter als auch für den Verbraucher des genutzten Dienstes Transparenz bereitgestellt wird.
Die Dienstmodelle lauten wie folgt:
Software as a Service (SaaS): Die dem Verbraucher bereitgestellte Fähigkeit besteht darin, die in einer Cloud-Infrastruktur ausgeführten Anwendungen des Anbieters zu verwenden. Der Zugriff auf die Anwendungen kann über eine Thin-Client-Schnittstelle wie z. B. einen Webbrowser von verschiedenen Client-Einheiten aus erfolgen (z. B. eine eMail-Nachricht auf Grundlage des Webs). Mit Ausnahme beschränkter benutzerspezifischer Einstellungen der Anwendungskonfiguration wird die darunterliegende Cloud-Infrastruktur wie Netzwerk, Server, Betriebssysteme, Speicher oder auch einzelne Anwendungsfunktionen vom Verbraucher weder verwaltet noch kontrolliert.
Platform as a Service (PaaS): Die dem Verbraucher bereitgestellte Fähigkeit besteht darin, vom Benutzer erzeugte oder erworbene Anwendungen, die anhand von vom Anbieter bereitgestellten Programmiersprachen und Werkzeugen erstellt wurden, in der Cloud-Infrastruktur bereitzustellen. Die darunterliegende Infrastruktur wie Netzwerke, Server, Betriebssysteme oder Speicher wird vom Verbraucher weder verwaltet noch kontrolliert, er hat jedoch die Kontrolle über die bereitgestellten Anwendungen und möglicherweise über Konfigurationen der Hosting-Umgebung für die Anwendungen.
Infrastructure as a Service (IaaS): Die dem Verbraucher bereitgestellte Fähigkeit besteht darin, Verarbeitung, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Verbraucher in der Lage ist, frei wählbare Software wie z. B. Betriebssysteme und Anwendungen bereitzustellen und auszuführen. Die darunterliegende Cloud-Infrastruktur wird vom Verbraucher weder verwaltet noch kontrolliert, er hat jedoch die Kontrolle über Systeme und Einheiten (z. B. Betriebssysteme, Speicher, bereitgestellte Anwendungen usw.) und möglicherweise eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z. B. Host-Firewalls).
Die Bereitstellungsmodelle lauten wie folgt:
Private Cloud: Die Cloud-Infrastruktur wird für lediglich eine Organisation betrieben. Sie kann von der Organisation selbst oder von einem Dritten verwaltet werden und sich an Ort und Stelle oder an einem anderen Ort befinden.
Gemeinschafts-Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezifische Gemeinschaft mit gemeinsamen Anliegen (z. B. Aufgabe, Sicherheitsanforderungen, Richtlinie und Einhaltung von Gesetzen und Richtlinien). Sie kann von den Organisationen selbst oder von einem Dritten verwaltet werden und sich an Ort und Stelle oder an einem anderen Ort befinden.
Öffentliche Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Branchengruppe bereitgestellt und ist Eigentum einer Organisation, die Cloud-Dienste verkauft.
Hybrid-Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren (privaten, Gemeinschafts- oder öffentlichen) Clouds, die eigenständige Einheiten bleiben, aber durch eine standardisierte oder herstellerspezifische Technologie miteinander verbunden sind, die eine Portierbarkeit von Daten und Anwendungen ermöglicht (z. B. das Cloud Bursting für den Lastausgleich zwischen Clouds).
Eine Cloud-Datenverarbeitungsumgebung ist dienstorientiert, wobei der Schwerpunkt auf Zustandslosigkeit, geringer Kopplung, Modularität und semantischer Kompatibilität liegt. Im Mittelpunkt einer Cloud-Datenverarbeitung steht eine Infrastruktur, die ein Netzwerk von miteinander verbundenen Knoten aufweist.
Mit Blick auf 1 wird eine schematische Darstellung eines Beispiels für einen Cloud-Datenverarbeitungsknoten gezeigt. Ein Cloud-Datenverarbeitungsknoten 10 ist lediglich ein Beispiel für einen geeigneten Cloud-Datenverarbeitungsknoten und nicht als eine wie auch immer geartete Beschränkung von Verwendungsumfang oder Funktionalität von Ausführungsformen der hier beschriebenen Erfindung gedacht. Unabhängig davon kann der Cloud-Datenverarbeitungsknoten 10 mit jeder hier dargelegten Funktionalität realisiert sein und/oder diese durchführen.
In dem Cloud-Datenverarbeitungsknoten 10 gibt es ein Computersystem/einen Server 12, das bzw. der mit zahlreichen anderen Universal- oder Spezialsystemumgebungen oder -konfigurationen betrieben werden kann. Beispiele bekannter Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die für eine Verwendung mit einem Computersystem/Server 12 geeignet sein könnten, sind, ohne darauf beschränkt zu sein, Personal-Computersysteme, Server-Computersysteme, Thin Clients, Thick Clients, Taschen- oder Laptop-Einheiten, Mehrprozessorsysteme, Systeme auf der Grundlage von Mikroprozessoren, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Mini-Computersysteme, Mainframe-Computersysteme sowie verteilte Cloud-Datenverarbeitungsumgebungen, die eines der obigen Systeme oder eine der Einheiten beinhalten, und dergleichen.
Das Computersystem/der Server 12 lässt sich im allgemeinen Zusammenhang von Befehlen beschreiben, die durch ein Computersystem ausführbar sind, wie z. B. Programmmodule, die von einem Computersystem ausgeführt werden. Allgemein können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. beinhalten, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen realisieren. Das Computersystem/der Server 12 kann in verteilten Cloud-Datenverarbeitungsumgebungen eingesetzt werden, wo Aufgaben von entfernt angeordneten Verarbeitungseinheiten durchgeführt werden, die über ein Datenübertragungsnetzwerk miteinander verbunden sind. In einer verteilten Cloud-Datenverarbeitungsumgebung können sich Programmmodule sowohl in lokalen als auch in entfernt angeordneten Computersystem-Speichermedien wie beispielsweise Arbeitsspeichereinheiten befinden.
Wie in 1 wird das Computersystem/der Server 12 in dem Cloud-Datenverarbeitungsknoten 10 als eine Universal-Datenverarbeitungseinheit gezeigt. Die Komponenten des Computersystems/Servers 12 können eine/n oder mehrere Prozessoren oder Verarbeitungseinheiten 16, einen Systemarbeitsspeicher 28 und einen Bus 18 beinhalten, der verschiedene Systemkomponenten wie z. B. den Systemarbeitsspeicher 28 mit dem Prozessor 16 verbindet, ohne jedoch darauf beschränkt zu sein.
Der Bus 18 steht für mindestens eine von mehreren Arten von Busstrukturen, z. B. ein Speicherbus oder eine Speichersteuereinheit, ein Peripheriebus, ein Accelerated Graphics Port (AGP) und ein Prozessor oder lokaler Bus, wobei eine beliebige aus einer Vielfalt von Busarchitekturen verwendet werden kann. Beispielhaft und nicht als Beschränkung zu verstehen, beinhalten derartige Architekturen den ISA-Bus (Industry Standard Architecture), den MCA-Bus (Micro Channel Architecture), den EISA-Bus (Enhanced ISA), den lokalen VESA-Bus (Video Electronics Standards Association) und den PCI-Bus (Peripheral Component Interconnects).
Das Computersystem/der Server 12 beinhaltet üblicherweise eine Vielfalt von Medien, die von einem Computersystem gelesen werden können. Derartige Medien können beliebige verfügbare Medien sein, auf die das Computersystem/der Server 12 zugreifen kann, und zu ihnen zählen sowohl flüchtige als auch nicht flüchtige, entfernbare und nicht entfernbare Medien.
Der Systemarbeitsspeicher 28 kann ein von einem Computersystem lesbares Medium in Form eines flüchtigen Arbeitsspeichers wie z. B. eines RAM 30 und/oder eines Caches 32 beinhalten. Das Computersystem/der Server 12 kann des Weiteren andere entfernbare/nicht entfernbare, flüchtige/nicht flüchtige Computersystem-Speichermedien beinhalten. Lediglich als Beispiel dienend, kann ein Speichersystem 34 zum Lesen von und Schreiben auf ein nicht entfernbares, nicht flüchtiges magnetisches Medium (das nicht abgebildet ist und das üblicherweise als ein Festplattenlaufwerk bezeichnet wird) bereitgestellt werden. Obwohl hier nicht abgebildet, können ein Magnetplattenlaufwerk zum Lesen von und Schreiben auf eine entfernbare, nicht flüchtige Magnetplatte (z. B. eine Diskette) sowie ein optisches Plattenlaufwerk zum Lesen von oder Schreiben auf eine entfernbare, nicht flüchtige optische Platte wie z. B. einen CD-ROM, einen DVD-ROM oder ein anderes optisches Medium bereitgestellt werden. In diesen Fällen kann jedes Laufwerk über eine oder mehrere Datenmedienschnittstellen mit dem Bus 18 verbunden sein. Wie weiter unten ausführlicher dargestellt und beschrieben, kann der Arbeitsspeicher 28 mindestens ein Programmprodukt mit einem Satz von (z. B. mindestens einem) Programmmodulen beinhalten, wobei diese so konfiguriert sind, dass sie die Funktionen von Ausführungsformen der Erfindung durchführen.
Ein Programm/Dienstprogramm 40 mit einem Satz von (mindestens einem) Programmmodulen 42 kann beispielsweise, und ohne als Beschränkung verstanden zu werden, in dem Arbeitsspeicher 28 gespeichert sein, ebenso wie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten. Jedes Betriebssystem, eines oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten oder eine Kombination hiervon können jeweils eine Realisierung einer Netzwerkumgebung beinhalten. [alternativ: Jedes der Betriebssysteme, das eine oder die mehreren Anwendungsprogramme, die anderen Programmmodule und die Programmdaten....]
Die Programmmodule 42 führen im Allgemeinen die Funktionen und/oder Verfahrensweisen von Ausführungsformen der hier beschriebenen Erfindung aus. So können zum Beispiel einige oder alle der Funktionen eines DHCP-Clients 80 als eines oder mehrere der Programmmodule 42 realisiert werden. Zusätzlich kann der DHCP-Client 80 als getrennte, zweckbestimmte Prozessoren oder als ein einziger oder mehrere Prozessoren realisiert werden, um die hier beschriebene Funktionalität bereitzustellen. Bei Ausführungsformen führt der DHCP-Client 80 einen oder mehrere der hier beschriebenen Prozesse durch.
Das Computersystem/der Server 12 kann zudem mit einer oder mehreren externen Einheiten 14 Daten austauschen, z. B. mit einer Tastatur, einer Zeigeeinheit, einer Anzeige 24 usw.; mit einer oder mehreren Einheiten, die einem Benutzer gestatten, mit dem Computersystem/Server 12 zu interagieren; und/oder mit beliebigen Einheiten (z. B. Netzwerkkarte, Modem usw.), die dem Computersystem/Server 12 ermöglichen, mit einer oder mehreren anderen Datenübertragungseinheiten Daten auszutauschen. Eine solche Datenübertragung kann über E/A-Schnittstellen 22 erfolgen. Des Weiteren kann das Computersystem/der Server 12 über einen Netzwerkadapter 20 mit einem oder mehreren Netzwerken Daten austauschen, z. B. mit einem lokales Netz (Local Area Network, LAN), einem Weitverkehrsnetz (Wide Area Network, WAN) und/oder einem öffentlichen Netz (z. B. dem Internet). Wie dargestellt, tauscht der Netzwerkadapter 20 über den Bus 18 Daten mit den anderen Komponenten des Computersystems/Servers 12 aus. Dabei sollte klar sein, dass – obwohl sie hier nicht abgebildet sind – auch andere Hardware- und/oder Softwarekomponenten in Verbindung mit dem Computersystem/Server 12 verwendet werden könnten. Beispiele hierfür sind, ohne darauf beschränkt zu sein, Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Plattenlaufwerksstapel, RAID-Systeme (Redundant Array of Inexpensive Disks oder Redundant Array of Independent Disks), Bandlaufwerke und Datenarchivierungsspeichersysteme usw.
Mit Blick auf 2 ist eine veranschaulichende Cloud-Datenverarbeitungsumgebung 50 dargestellt. Wie gezeigt, weist die Cloud-Datenverarbeitungsumgebung 50 einen oder mehrere Cloud-Datenverarbeitungsknoten 10 auf, mit denen lokale Datenverarbeitungseinheiten wie zum Beispiel ein persönlicher digitaler Assistent (Personal Digital Assistant, PDA) oder ein Mobiltelefon 54A, ein Desktop Computer 54, ein Laptop Computer 54C und/oder ein Automobil-Computersystem 54N Daten austauschen können. Die Knoten 10 können untereinander Daten austauschen. Sie können in einem oder mehreren Netzwerken, z. B. in privaten, Gemeinschafts-, öffentlichen oder Hybrid-Clouds, wie sie hier weiter oben beschrieben sind, oder in einer Kombination hiervon, physisch oder virtuell zusammengefasst sein (nicht abgebildet). Auf diese Weise kann die Cloud-Datenverarbeitungsumgebung 50 Infrastruktur, Plattformen und/oder Software als Dienste anbieten, für die ein Cloud-Verbraucher keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Dabei sollte klar sein, dass die in 2 gezeigten Arten von Datenverarbeitungseinheiten 54A bis N lediglich zur Veranschaulichung gedacht sind und dass die Datenverarbeitungsknoten 10 und die Cloud-Datenverarbeitungsumgebung 50 mit jeder Art von computergestützter Einheit über jede Art von Netzwerk und/oder netzwerkadressierbarer Verbindung (z. B. unter Verwendung eines Webbrowsers) Daten austauschen können.
Mit Blick auf 3 wird ein Satz von funktionsbezogenen Abstraktionsschichten gezeigt, der von der Cloud-Datenverarbeitungsumgebung 50 (2) bereitgestellt wird. Dabei sollte von Anfang an klar sein, dass die in 3 gezeigten Komponenten, Schichten und Funktionen lediglich zur Veranschaulichung gedacht und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie abgebildet, werden die folgenden Schichten und zugehörigen Funktionen bereitgestellt:
Eine Hardware- und Softwareschicht 60 enthält Hardware- und Softwarekomponenten. Zu Beispielen von Hardwarekomponenten zählen Großrechner 61; Server 62 auf Grundlage der RISC-Architektur (Reduced Instruction Set Computer); Server 63; Blade-Server 64; Speichereinheiten 65; Netzwerk und Netzwerkkomponenten 66. Bei manchen Ausführungsformen beinhalten Softwarekomponenten Software für Netzwerk-Anwendungsserver 67 und Datenbanksoftware 68.
Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, welche die folgenden Beispiele für virtuelle Einheiten zur Verfügung stellen kann: virtuelle Server 71; virtueller Speicher 72; virtuelle Netzwerke 73 die virtuelle private Netzwerke aufweisen; virtuelle Anwendungen und Betriebssysteme 74; sowie virtuelle Clients 75.
In einem Beispiel kann eine Verwaltungsschicht 80 die im Folgenden beschriebenen Funktionen bereitstellen. Eine Ressourcenbereitstellungsfunktion 81 stellt eine dynamische Beschaffung von Datenverarbeitungs- und anderen Ressourcen bereit, mit denen Aufgaben innerhalb der Cloud-Datenverarbeitungsumgebung durchgeführt werden. Messungs- und Preisermittlungsfunktionen 82 stellen eine Kostenerfassung bei der Nutzung von Ressourcen innerhalb der Cloud-Datenverarbeitungsumgebung sowie eine Fakturierung bzw. Abrechnung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware aufweisen. Eine Sicherheitsfunktion stellt eine Identitätsprüfung für Cloud-Verbraucher und -Aufgaben sowie einen Schutz für Daten und andere Ressourcen bereit. Eine Benutzerportalfunktion 83 stellt Verbrauchern und Systemadministratoren einen Zugriff auf die Cloud-Datenverarbeitungsumgebung bereit. Eine Dienstgüteverwaltungsfunktion 84 stellt eine Zuordnung und Verwaltung von Cloud-Datenverarbeitungsressourcen bereit, so dass erforderliche Dienstgütestufen erreicht werden. Eine Planungs- und Ausführungsfunktion 85 von Dienstgütevereinbarungen (Service Level Agreement, SLA) stellt eine Vorabfestlegung und Beschaffung von Cloud-Datenverarbeitungsressourcen bereit, für die gemäß einer SLA eine künftige Anforderung erwartet wird.
Eine Auslastungsschicht 90 stellt Beispiele einer Funktionalität bereit, für welche die Cloud-Datenverarbeitungsumgebung genutzt werden kann. Beispiele für Auslastungen und Funktionen, die von dieser Schicht bereitgestellt werden können, lauten: Zuordnung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von virtuellen Schulungen 93; Datenanalyseverarbeitung 94; Transaktionsverarbeitung 95; und hier beschriebene DHCP-Prozesse 96. Gemäß Aspekten der Erfindung dienen die DHCP-Prozesse 96 Auslastung/Funktion dazu, einen oder mehrere der hier beschriebenen Prozesse durchzuführen.
4 stellt einen Cloud-Datenverarbeitungsknoten gemäß einer weiteren Ausführungsform der vorliegenden Erfindung dar. Insbesondere stellt 4 einen weiteren Cloud-Datenverarbeitungsknoten dar, der denselben Cloud-Datenverarbeitungsknoten 10 aufweist wie 1. In 4 weist das Computersystem/der Server 12 zudem einen DHCP-Client 170, einen DHCP-Server 160 und einen DHCP-Relay-Agenten 180 auf bzw. tauscht mit diesen Daten aus, wie hier ausführlicher beschrieben wird.
Gemäß Aspekten der Erfindung können der DHCP-Client 170, der DHCP-Server 160 und der DHCP-Relay-Agent 180 als ein oder mehrere Programmcodes in Programmmodulen 42 realisiert werden, die als getrennte oder kombinierte Module im Arbeitsspeicher gespeichert werden. Zusätzlich können der DHCP-Client 170, der DHCP-Server 160 und der DHCP-Relay-Agent 180 als getrennte, zweckbestimmte Prozessoren oder als ein einziger oder mehrere Prozessoren realisiert werden, um die Funktion dieser Werkzeuge bereitzustellen. Die Verarbeitungseinheit 16 kann während der Ausführung des Computerprogrammcodes Daten aus einem Arbeitsspeicher, Speichersystem und/oder einer E/A-Schnittstelle 22 lesen und/oder dort hineinschreiben. Der Programmcode führt die Prozesse der Erfindung aus.
Der DHCP-Client 170 kann zum Beispiel so konfiguriert sein, dass er ein DHCP-Anforderungspaket über eine Cloud-Datenverarbeitungsumgebung 50 an einen DHCP-Server 160 sendet. Mit Bezug auf 2 kann die Cloud-Datenverarbeitungsumgebung 50 zum Beispiel das Internet, ein lokales Netz, ein Weitverkehrsnetz und/oder ein Funknetz sein. Als Reaktion auf den Empfang des DHCP-Anforderungspakets durch den DHCP-Server 160 ordnet der DHCP-Server 160 dem DHCP-Client 170 eine IP-Adresse zu. Bei Ausführungsformen des DHCP-Mechanismus kann der DHCP-Server 160 eine direkte Multi-Tenancy-Unterstützung des DHCP-Protokolls bereitstellen, indem er eine Tenant-spezifische DHCP-Option verwendet, um Tenant-Daten zu übermitteln. Im Gegensatz zu gegenwärtigen Systemen, die eine Virtualisierung des Betriebssystem benötigen (bei der z. B. jeder Tenant einen DHCP-Server aufweist, der in einem getrennten LINUX-Adressraum ausgeführt wird), kann der DHCP-Server 160 überlappende IP-Adressräume unterstützen. Tatsächlich bietet der DHCP-Server 160 gegenüber der bekannten Betriebssystemvirtualisierung für eine Multi-Tenancy-Unterstützung zahlreiche Vorteile und technische Lösungen wie z. B. die Adressierungsinteroperabilität zwischen verschiedenen Kapselungsprotokollen für die Multi-Tenant-Isolierung, die hohe (und z. B. weniger rechenintensive) Skalierbarkeit und die nahtlose Unterstützung der Adresszuordnungsanforderung im Rahmen des SDN-Ansatzes (Software Defined Networking). Darüber hinaus kann in 4 ein DHCP-Relay-Agent 180 als eine Vermittlereinheit verwendet werden, um über die Cloud-Datenverarbeitungsumgebung 50 zwischen dem DHCP-Client 170 und dem DHCP-Server 160 Nachrichten weiterzugeben. Dem Fachmann dürfte dabei klar sein, dass bei einer weiteren Ausführungsform der DHCP-Client 170 und der DHCP-Server 160 ohne Verwendung des DHCP-Relay-Agenten 180 direkt Daten miteinander austauschen können.
Die vorliegende Erfindung kann ein System, ein Verfahren und/oder ein Computerprogrammprodukt sein. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder -medien) mit darauf enthaltenen computerlesbaren Programmbefehlen beinhalten, um einen Prozessor zu veranlassen, Aspekte der vorliegenden Erfindung durchzuführen.
Das computerlesbare Speichermedium kann eine gegenständliche Einheit sein, die Befehle zur Verwendung durch eine Befehlsausführungseinheit beibehalten und speichern kann. Das computerlesbare Speichermedium kann zum Beispiel eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder eine beliebige geeignete Kombination der vorgenannten Einheiten sein, ohne jedoch darauf beschränkt zu sein. Eine nicht vollständige Liste konkreterer Beispiele des computerlesbaren Speichermediums beinhaltet Folgendes: eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren, programmierbaren Nur-Lese-Speicher (EPROM- oder Flash-Speicher), einen statischen Direktzugriffsspeicher (SRAM), einen tragbaren CD-ROM, eine DVD, einen Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie z. B. Lochkarten oder erhabene Strukturen in einer Rille mit darauf aufgezeichneten Befehlen sowie eine beliebige geeignete Kombination der vorgenannten Elemente. Bei einem computerlesbaren Speichermedium, wie es hier verwendet wird, ist nicht davon auszugehen, dass es sich per se um flüchtige Signale wie z. B. Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Hohlleiter oder ein anderes Übertragungsmedien ausbreiten (z. B. Lichtimpulse, die ein Lichtwellenleiterkabel durchlaufen), oder elektrische Signale, die über eine Leitung übertragen werden, handelt.
Hier beschriebene computerlesbare Programmbefehle können über ein Netzwerk wie beispielsweise das Internet, ein lokales Netzwerk (Local Area Network, LAN), ein Weitverkehrsnetzwerk (Wide Area Network, WAN) und/oder ein drahtloses Netzwerk von einem computerlesbaren Speichermedium auf entsprechende Datenverarbeitungs-/Verarbeitungs-Einheiten oder auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenleiter, eine drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungs-Einheit empfängt computerlesbare Programmbefehle von dem Netzwerk und leitet die computerlesbaren Programmbefehle zur Speicherung auf einem computerlesbaren Speichermedium innerhalb der betreffenden Datenverarbeitungs-/Verarbeitungs-Einheit weiter.
Bei computerlesbaren Programmbefehlen zum Durchführen von Operationen der vorliegenden Erfindung kann es sich um Assembler-Befehle, ISA-Befehle (Instruction-Set-Architecture), Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, Firmware-Befehle, einen Zustand festlegende Daten oder aber entweder um Quellcode oder um Objektcode handeln, der in einer beliebigen Kombination von einer oder mehreren Programmiersprachen wie z. B. einer objektorientierten Programmiersprache wie Smalltalk, C++ oder dergleichen, sowie in herkömmlichen prozeduralen Programmiersprachen wie z. B. der Programmiersprache „C” oder ähnlichen Programmiersprachen geschrieben ist. Die computerlesbaren Programmbefehle können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder aber vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Im letztgenannten Szenario kann der entfernt angeordnete Computer über eine beliebige Art von Netzwerk, unter anderem ein LAN oder ein WAN, mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann mit einem externen Computer (z. B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden. Bei manchen Ausführungsformen kann ein elektronischer Schaltkreis wie z. B. ein programmierbarer Logikschaltkreis, Field-Programmable-Gate-Arrays (FPGAs) oder Programmable-Logic-Arrays (PLAs) die computerlesbaren Programmbefehle ausführen, indem er Zustandsdaten der computerlesbaren Programmbefehle verwendet, um die elektronische Schaltung zu personalisieren und Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung werden hier unter Bezugnahme auf Darstellungen von Ablaufplänen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Dabei dürfte klar sein, dass jeder Block der Ablaufplan-Darstellungen und/oder Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplan-Darstellungen und/oder Blockschaubildern durch computerlesbare Programmbefehle realisiert werden kann/können.
Diese computerlesbaren Programmbefehle können einem Prozessor eines Universalcomputers, Spezialcomputers oder einer anderweitigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Befehle, die über den Prozessor des Computers oder der anderweitigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel erzeugen, mit dem die Funktionen/Handlungen realisiert werden können, die in dem Block bzw. den Blöcken des Ablaufplans und/oder des Blockschaubilds angegeben werden. Diese computerlesbaren Programmbefehle können auch auf einem computerlesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten anweisen kann, auf eine bestimmte Art und Weise zu funktionieren, so dass das computerlesbare Speichermedium mit darauf gespeicherten Befehlen einen Herstellungsartikel aufweist, der Befehle enthält, welche Aspekte der in dem Block bzw. den Blöcken des Ablaufplans und/oder des Blockschaubilds angegebenen Funktion/Handlung realisieren.
Die computerlesbaren Programmbefehle können zudem in einen Computer, eine anderweitige programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um zu veranlassen, dass eine Reihe von Funktionsschritten auf dem Computer, der anderweitigen programmierbaren Datenvorrichtung oder der anderen Einheit ausgeführt wird, so dass die Befehle, die auf dem Computer, der anderweitigen Datenverarbeitungsvorrichtung oder der anderen Einheit ausgeführt werden, die in dem Block bzw. den Blöcken des Ablaufplans und/oder des Blockschaubilds angegebenen Funktionen/Handlungen realisieren.
Die Ablaufpläne und die Blockschaubilder in den Figuren stellen die Architektur, Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung bereit. Somit kann jeder Block der Ablaufpläne oder Blockschaubilder ein Modul, Segment oder einen Teil von Befehlen darstellen, das/der einen oder mehrere ausführbare Befehle aufweist, mit denen sich die eine oder mehreren angegebenen logischen Funktionen realisieren lassen. Bei manchen alternativen Ausführungsformen können die in dem Block erwähnten Funktionen in einer anderen Reihenfolge als der in den Figuren genannten auftreten. So können zwei aufeinanderfolgend dargestellte Blöcke tatsächlich im Wesentlichen gleichzeitig stattfinden, oder die Blöcke können mitunter in umgekehrter Reihenfolge ausgeführt werden, wobei dies abhängig von der betreffenden Funktionalität ist. Zu erwähnen ist ebenfalls, dass jeder Block der Blockschaubilder und/oder der Ablaufplan-Darstellungen sowie Kombinationen von Blöcken in den Blockschaubildern und/oder Ablaufplan-Darstellungen durch Spezialsysteme auf Hardwaregrundlage, welche die angegebenen Funktionen oder Handlungen oder Kombinationen hiervon ausführen, oder durch Kombinationen von Spezial-Hardware- und Computerbefehlen realisiert bzw. durchgeführt werden kann/können.
5 ist ein Datenrahmenformat für eine Tenant-spezifische DHCP-Option gemäß Aspekten der vorliegenden Erfindung. Genauer gesagt stellt 5 ein Datenrahmenformat 100 für eine Tenant-spezifische DHCP-Option zum Übermitteln von Tenant-Daten dar. Das Datenrahmenformat 100 für eine Tenant-spezifische DHCP-Option beinhaltet eine Vielfalt von Feldern, z. B., ohne darauf beschränkt zu sein, für eine Option 110, eine Länge 120, einen Transport-Agenten 130, eine Tenant-ID 140 und eine virtuelle Netzwerk-ID 150. Die Option 110 ist ein eindeutiger Wert für die DHCP-Optionen. Die Länge 120 ist eine Gesamtzahl der Bytes der verbleibenden Felder. Der Transport-Agent 130 ist ein Codierwert, der dazu verwendet wird, den für die Tenant-Isolierung verwendeten Overlay-Protokolltyp anzugeben, z. B. VLAN, VXLAN, DOVE, NVGRE, STT usw. Die Tenant-ID 140 ist eine UUID, die dazu verwendet wird, einen Tenant anzugeben. Die virtuelle Netzwerk-ID 150 bezeichnet schließlich ein virtuelles Netzwerk, das eine Abstraktion eines L2-Segments oder einer Broadcast-Domäne ist.
Ein Tenant kann mit mehreren virtuellen Netzwerken verbunden sein. Das Datenrahmenformat 100 für eine Tenant-spezifische DHCP-Option zeigt einem DHCP-Server an, dass er diesem Tenant eine IP-Adresse in einem zugehörigen Adressraum zuordnen soll. Somit kann ein einziger DHCP-Server eine Mehrzahl von Tenants bedienen, und jeder Tenant kann seinen eigenen IP-Adresspool für eine Zuordnung aufweisen. Die Pools der verschiedenen Tenants sind völlig unabhängig voneinander und können sich überlappen. Das Datenrahmenformat 100 für eine Tenant-spezifische DHCP-Option kann durch einen DHCP-Relay-Agenten einem DHCP-Header hinzugefügt werden. Bei Ausführungsformen ist die Tenant-spezifische Option eine Unteroption der DHCP-Relay-Agenten-Datenoption (Option 82, RFC 3046). Somit fügt die Realisierung der Option 82 eine Unteroption hinzu, so dass sie das Datenrahmenformat 100 für eine Tenant-spezifische DHCP-Option enthält.
ABLAUFPLAN
Die 6 bis 8 zeigen beispielhafte Abläufe (oder Aktivitätenpläne) zum Durchführen von Aspekten der vorliegenden Erfindung. Die Schritte aus den 6 bis 8 können zum Beispiel in der Umgebung der 1 und 4 realisiert werden. Wie oben erwähnt, veranschaulicht bzw. veranschaulichen das/die Blockschaubild/er die Architektur, Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten, wie sie hier gemäß den verschiedenen Ausführungsformen der vorliegenden Erfindung bereits beschrieben wurden. Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Somit kann jeder Block der Ablaufpläne oder Blockschaubilder ein Modul, Segment oder einen Code-Teil darstellen, der ein oder mehrere ausführbare Befehle aufweist, mit denen sich die ein oder mehreren angegebenen logischen Funktionen realisieren lassen. Zu beachten ist ferner, dass bei manchen alternativen Ausführungsformen die in dem Block erwähnten Funktionen in einer anderen Reihenfolge als der in den Figuren genannten auftreten können. So können zwei aufeinanderfolgend dargestellte Blöcke tatsächlich im Wesentlichen gleichzeitig stattfinden, oder die Blöcke können mitunter in umgekehrter Reihenfolge ausgeführt werden, wobei dies abhängig von der betreffenden Funktionalität ist. Zu erwähnen ist ebenfalls, dass jeder Block der Blockschaubilder und/oder der Ablaufplan-Darstellungen sowie Kombinationen von Blöcken in den Blockschaubildern und/oder der Ablaufplan-Darstellungen durch Spezialsysteme auf der Grundlage von Hardware, welche die angegebenen Funktionen oder Handlungen oder Kombinationen hiervon ausführen, oder durch Kombinationen von Spezial-Hardware- und Computerbefehlen realisiert werden kann/können.
6 stellt einen beispielhaften Ablauf (Aktivitätenplan) einer DHCP-Paketverarbeitung gemäß Aspekten der vorliegenden Erfindung dar. Genauer gesagt zeigt 6 eine Tenant-spezifische Option, die dem DHCP-Header durch einen DHCP-Relay-Agent hinzugefügt wird. Da ein NVE ein Rand des Overlay-Netzwerks ist, lässt sich der Codierwert des Transport-Agenten in der Tenant-spezifischen Option auf einfache Weise erhalten. Eine VNID kann von einem VAP erhalten werden, mit dem der DHCP-Client verbunden ist. Der VAP ist ein logischer Verbindungspunkt in dem NVE, um eine Verbindung eines Tenants-Systems mit einem virtuellen Netzwerk herzustellen. VAPs können physische Ports oder virtuelle Ports sein, die durch logische Schnittstellenkennungen wie z. B. eine VLAN-ID oder eine interne vSwitch-Schnittstellen-ID identifiziert werden, die mit einer VM verbunden sind. Die Tenant-ID in der Tenant-spezifischen Option kann über die VNID erhalten werden, indem der lokale Cache oder eine entfernt angeordnete Datenbank in der NVA abgefragt werden, die aus der Abbildung zwischen VNID und Tenant-ID besteht.
Bei herkömmlichen DHCP-Relays wird für jedes bediente L2-Segment eine Gateway-IP-Schnittstelle benötigt, an der DHCP-Client-Pakete für das L2-Segment empfangen werden. Somit wird bei gegenwärtigen DHCP-Systemen beim Empfang einer DHCP-Nachricht von einem DHCP-Client die IP-Adresse der IP-Schnittstelle in das Feld GIADDR (Gateway IP Address) des DHCP-Pakets eingetragen, wenn es einen Inhalt von Null hat, und die DHCP-Nachricht wird an den DHCP-Server gesendet. Anders ausgedrückt wird die GIADDR durch den ersten DHCP-Relay-Agenten hinzugefügt. Der DHCP-Server verwendet die GIADDR, um dem DHCP-Client die IP-Adresse und andere Netzwerkparameter zuzuordnen. Der DHCP-Server sendet eine entsprechende DHCP-Relay-Nachricht an einen DHCP-Relay-Agenten, der durch die GIADDR identifiziert wird. Der DHCP-Relay-Agent ist so entworfen, dass er die DHCP-Antwortnachricht an die direkt verbundenen DHCP-Clients sendet, d. h. an die Clients in demselben L2-Segment wie die IP-Schnittstelle des DHCP-Relay-Agenten, der durch die GIADDR identifiziert wird.
Im Gegensatz dazu werden, wie in 6 gezeigt, DHCP-Clients in dem Overlay-Netzwerk ausgeführt, und die Overlay-Netzwerke der verschiedenen Tenants sind voneinander isoliert. Der DHCP-Server ist so entworfen, dass er alle DHCP-Clients in verschiedenen Tenant-Overlay-Netzwerken bedient. Der DHCP-Server und die DHCP-Relay-Agenten tauschen über das Underlay-Netzwerk Daten aus. Die durch den DHCP-Relay-Agenten hinzugefügte GIADDR ist eine Underlay-IP-Adresse des Relay-Agenten. Der DHCP-Server verwendet nicht die GIADDR, um dem DHCP-Client die IP-Adresse und andere Netzwerkparameter zuzuordnen. Vielmehr verwendet der DHCP-Server die Tenant-spezifische Option und andere Optionen, um dem DHCP-Client die IP-Adresse und andere Netzwerkparameter zuzuordnen. Der DHCP-Server sendet eine entsprechende DHCP-Anwortnachricht an einen DHCP-Relay-Agenten, der durch die GIADDR identifiziert wird. Der Relay-Agent verwendet die VNID in der Tenant-spezifischen Option, um dem DHCP-Client die DHCP-Antwortnachricht entsprechend zu übermitteln.
Genauer gesagt stellt 6 einen beispielhaften Ablaufplan oder Aktivitätenplan einer DHCP-Paketverarbeitung gemäß Aspekten der vorliegenden Erfindung dar. 5 enthält die folgenden Aktoren: einen DHCP-Client 210 (ein Beispiel für den mit Blick auf 4 beschriebenen DHCP-Client 170), einen DHCP-Relay-Agenten 220 (ein Beispiel für den mit Blick auf 4 beschriebenen DHCP-Relay-Agenten 180) und einen DHCP-Server 230 (ein Beispiel für den mit Blick auf 4 beschriebenen DHCP-Server 160).
In 6 sendet ein DHCP-Client 210 in Schritt 231 bei der DHCP-Paketverarbeitung eine Nachricht DHCP_DISCOVER an einen DHCP-Relay-Agenten 220. Danach sendet in Schritt 232 der DHCP-Relay-Agent 220 eine Nachricht DHCP_DISCOVER mit einer Tenant-spezifischen Option an den DHCP-Server 230. In Schritt 233 sendet daraufhin der DCHP-Server 230 eine Nachricht DHCP OFFER mit einer Tenant-spezifischen Option an den DHCP-Relay-Agenten 220. In Schritt 234 sendet der DHCP-Relay-Agent 220 eine Nachricht DHCP_OFFER an den DHCP-Client 210. Danach sendet in Schritt 235 der DHCP-Client 210 eine Nachricht DHCP REQUEST an den DHCP-Relay-Agenten 220. Der DHCP-Relay-Agent 220 sendet in Schritt 236 eine Nachricht DHCP_REQUEST mit einer Tenant-spezifischen Option an den DHCP-Server 230. In Schritt 237 sendet der DHCP-Server 230 eine Nachricht DHCP_ACK mit einer Tenant-spezifischen Option an den DHCP-Relay-Agenten 220. Schließlich sendet in Schritt 238 der DHCP-Relay-Agent 220 eine Nachricht DHCP_ACK an den DHCP-Client 210.
7 stellt einen beispielhaften Ablauf einer Adresszuordnungsverarbeitung gemäß Aspekten der vorliegenden Erfindung dar. Um in 7 in dem neuartigen DHCP-Mechanismus der dargestellten Ausführungsform eine Multi-Tenant-Unterstützung zu ermöglichen, unterstützt der DHCP-Server zwei Arten von Adressräumen: einen globalen Adressraum und einen Tenant-Adressraum. Der globale Adressraum ist mit gegenwärtigen DHCP-Methoden kompatibel, bei denen das DHCP-Paket keine Tenant-spezifische Option enthält. In dem globalen Adressraum von gegenwärtigen DHCP-Verfahren können sich die IP-Adressbereiche nicht überlappen; im Gegensatz dazu weist bei den technischen Lösungen des DHCP-Mechanismus der dargestellten Ausführungsform der vorliegenden Erfindung jeder Tenant einen spezifischen Adresspool in dem Tenant-Adressraum auf. Bei dem DHCP-Mechanismus der dargestellten Ausführungsform kann der Adressbereich den Adresspool verschiedener Tenants überlappen.
Wenn zum Beispiel bei dem in 7 gezeigten DHCP-Mechanismus die Nachricht DHCP_DISCOVER nicht die Tenant-spezifische Option enthält, führt der DHCP-Server eine bekannte DHCP-Verarbeitung durch. Wenn die Nachricht DHCP_DISCOVER hingegen die Tenant-spezifische Option enthält, wird die Tenant-spezifische Option dazu verwendet, den Tenant-Adressraum und den IP-Bereich zu lokalisieren. Der DHCP-Server lokalisiert den Adressraum, welcher der Tenant-ID in der Tenant-spezifischen Option entspricht. Wenn ebenfalls in 7 die Nachricht DHCP_DISCOVER eine Option für die Subnetzauswahl (Option 118) oder eine Unteroption für die Verbindungsauswahl (Unteroption 5 in Option 82) aufweist, ordnet der DHCP-Server eine Adresse aus diesem Subnetz zu. Wenn die Nachricht DHCP_DISCOVER hingegen keine Option für die Subnetzauswahl oder eine Unteroption für die Verbindungsauswahl aufweist, wird ein IP-Bereich einer VNID zugewiesen, und der DHCP-Server sucht den der VNID entsprechenden IP-Bereich in der Tenant-spezifischen Option. Des Weiteren kann der neuartige DHCP-Mechanismus der dargestellten Ausführungsform einen DHCP-Server beinhalten, der ein Abgleichkriterium oder ACL-Regeln in der Tenant-spezifischen Option der Konfiguration verwendet, um den Tenant-Adressraum zu lokalisieren.
Genauer gesagt empfängt in 7 ein DHCP-Server bei der Adresszuordnungsverarbeitung in Schritt 305 ein DHCP-Anforderungspaket. In Schritt 310 ermitteln die Prozesse und Systeme des DHCP-Servers, ob die DHCP-Anforderung (z. B. DHCP_DISCOVER) eine spezifische Option aufweist. Wenn die DHCP-Anforderung in Schritt 315 keine Tenant-spezifische Option aufweist (NEIN), verwendet der DHCP-Server einen globalen Adressraum. Danach führen in Schritt 320 der DHCP-Server und der DHCP-Client eine bekannte DHCP-Protokollverarbeitung durch, da keine Tenant-spezifische Option vorhanden ist.
Wenn alternativ hierzu in Schritt 310 die DHCP-Anforderung (z. B. DHCP_DISCOVER) eine Tenant-spezifische Option aufweist (JA), wählt in Schritt 325 der DHCP-Server gemäß dem Feld mit der Tenant-spezifischen Option einen Adressraum aus. Des Weiteren ermittelt der DHCP-Server in Schritt 330, ob in der DHCP-Anforderung entweder eine Option für die Verbindungsauswahl (Option 118) oder eine Option für die Subnetzauswahl (Option 82, Unteroption 5) vorhanden ist. Wenn keine Verbindung vorhanden ist (NEIN), ordnet der DHCP-Server in Schritt 345 eine Adresse für die VNID zu. Wenn alternativ hierzu in Schritt 330 die DHCP-Anforderung entweder eine Option für die Verbindungsauswahl (Option 118) oder eine Option für die Subnetzauswahl (Option 82, Unteroption 5) aufweist (JA), prüft der DHCP-Server in Schritt 335, ob in einem anfordernden Subnetz eine verfügbare Adresse vorhanden ist. Wenn in Schritt 335 in dem anfordernden Subnetz eine verfügbare Adresse vorhanden ist (JA), ordnet der DHCP-Server in Schritt 340 eine Adresse in dem Subnetz zu. Wenn in Schritt 335 in dem anfordernden Subnetz keine verfügbare Adresse vorhanden ist (NEIN), ordnet der DHCP-Server in Schritt 345 der VNID eine Adresse zu.
8 stellt einen beispielhaften Ablauf einer DHCP-Subnetzauswahl-Unterstützung gemäß Aspekten der vorliegenden Erfindung dar. In 8 sendet ein DHCP-Client 410 bei der DHCP-Subnetzauswahl-Unterstützung gemäß Aspekten der vorliegenden Erfindung in Schritt 441 eine Nachricht DHCP_DISCOVER an einen DHCP-Relay-Agenten 420. Wenn der DHCP-Relay-Agent 420 die Nachricht DHCP_DISCOVER empfängt, lokalisiert der DHCP-Relay-Agent 420 den Tenant-Adressraum gemäß der Tenant-ID in der Tenant-spezifischen Option und ordnet in dem beabsichtigten Subnetz eine IP-Adresse zu. Wie in 7 gezeigt, erhält der DHCP-Relay-Agent 420 seine VNID von einem zugehörigen VAP. In 8 sendet der DHCP-Relay-Agent 420 daraufhin in Schritt 442 eine Nachricht zur Abfrage des Subnetzes von VNIDx an eine NVA 440, um die Subnetzkonfiguration der VNID abzufragen. In Schritt 443 sendet der NVA 440 eine Antwort für das Subnetz von VNIDx an den DHCP-Relay-Agenten. Schließlich wird in Schritt 444 die Nachricht DHCP_DISCOVER mit der Tenant-spezifischen Option und der Option für die Subnetzauswahl 118 oder der Option 82 mit der Unteroption 5 an den DHCP-Server 430 gesendet.
In 8 werden eine Option für die DHCP-Subnetzauswahl (Option 118, RFC3011) und eine Verbindungsauswahl in der Relay-Agenten-Datenoption (Option 82, Unteroption 5, RFC3527) verwendet, um mit einem DHCP-Server in einem gewünschten Subnetz Daten auszutauschen, von dem die DHCP-Clients den Erhalt ihrer IP-Adresse erwarten. Somit kann der neuartige DHCP-Mechanismus der dargestellten Ausführungsform über einen NVA einfach auf diese Szenarien erweitert werden.
Wie in 8 gezeigt, kann ein NVA die Subnetzkonfiguration für jede VNID verwalten. Als Reaktion darauf, dass jedes einzelne Paket DHCP_DISCOVER von dem DHCP-Client 410 empfangen wird, erhält der DHCP-Relay-Agent 420 seine VNID von dem zugehörigen VAP. Danach sendet der DHCP-Relay-Agent 420 eine Anforderung an die NVA 440, um die Subnetzkonfiguration der VNID abzufragen. Die von der NVA 440 als Antwort zurückgegebene Subnetzkonfiguration wird daraufhin in die DHCP-Option 118 oder in die Option 82, Unteroption 5, eingetragen. Danach werden die Subnetzdaten zusammen mit der Tenant-spezifischen Option an den DHCP-Server 430 übertragen. Wenn der DHCP-Server 430 das Paket DHCP_DISCOVER empfängt, lokalisiert der DHCP-Server 430 den Tenant-Adressraum gemäß der Tenant-ID in der Tenant-spezifischen Option und ordnet eine IP-Adresse in dem beabsichtigten Subnetz zu, die in der DHCP-Option 118 oder in der Option 82, Unteroption 5, enthalten ist.
Bei Ausführungsformen können die hier beschriebenen Prozesse von einem Dienstanbieter wie z. B. einem Lösungsintegrator durchgeführt werden. In diesem Fall kann der Dienstanbieter eine Computerinfrastruktur erzeugen, verwalten, bereitstellen, unterstützen usw., welche die Prozessschritte der Erfindung für einen oder mehrere Kunden durchführt. Diese Kunden können z. B. alle Unternehmen sein, die Technologie nutzen. Der Dienstanbieter wiederum kann von dem/den Kunden eine Bezahlung im Rahmen einer Abonnement- und/oder Gebührenvereinbarung erhalten, und/oder er kann eine Bezahlung aus dem Verkauf von Werbeinhalten an einen oder mehrere Dritte/n erhalten.
Wie dem Fachmann nunmehr klar sein sollte, stellt der DHCP-Mechanismus in Ausführungsformen der vorliegenden Erfindung zahlreiche Vorteile gegenüber gegenwärtigen Systemen bereit. Zu diesen Vorteilen zählen, ohne darauf beschränkt zu sein, die Bereitstellung einer direkten Multi-Tenancy-Unterstützung durch das DHCP-Protokoll und der Verzicht auf die Notwendigkeit einer Virtualisierung des LINUX-Namensraums auf Ebene des Betriebssystems. Bei Ausführungsformen der vorliegenden Erfindung wird diese technische Lösung erreicht, indem eine Tenant-spezifische DHCP-Option für die Übermittlung von Tenant-Daten vorgesehen wird und indem ein Adresszuordnungsschema in einem DHCP-Server verbessert wird, um der IP-Adresszuordnung in dem Tenant-Adressraum Vorrang einzuräumen, wenn in dem DHCP-Paket eine Tenant-spezifische Option festgestellt wird.
Zudem können sowohl der DHCP-Client als auch der DHCP-Relay-Agent eine Tenant-spezifische Option hinzufügen. Darüber hinaus beheben Ausführungsformen ein Interoperabilitätsproblem zwischen verschiedenen Kapselungsprotokollen für die Multi-Tenant-Isolierung (z. B. VLAN, VXLAN, DOVE, NVGRE, STT usw.).
Darüber hinaus stellen Ausführungsformen des DHCP-Mechanismus eine hohe Skalierbarkeit bereit, wenn die Zahl der Tenants steigt. So erhöht zum Beispiel bei gegenwärtigen Systemen die Betriebssystemvirtualisierung zur Multi-Tenancy-Unterstützung den Rechenaufwand, da jede Instanz eines LINUX-Namensraums zusätzliche Ressourcen benötigt; bei Ausführungsformen des DHCP-Mechanismus der vorliegenden Erfindung wird der Rechenaufwand verglichen mit einer Virtualisierung auf Betriebssystemebene jedoch reduziert. Darüber hinaus wird bei Ausführungsformen des DHCP-Mechanismus eine SDN-Adresszuordnungsanforderung nahtlos unterstützt, da jeder DHCP-Client korrekte Adressen erhält, die zu seinem Tenant und seinem virtuellen Netzwerk gehören, mit dem er verbunden ist.
Als weitere vorteilhafte Lösung eines technischen Problems stellen die hier beschriebenen Systeme und Prozesse ein computerrealisiertes Verfahren für eine Multi-Tenancy-Unterstützung in einem Netzwerk mit einem DHCP-Protokoll bereit. In diesem Fall kann eine Computerinfrastruktur wie z. B. das in den 1 und 4 gezeigte System oder die in 2 gezeigte Cloud-Umgebung bereitgestellt werden, und ein oder mehrere Systeme zum Durchführen der Prozesse der Erfindung können erhalten (z. B. erzeugt, gekauft, genutzt, modifiziert usw.) und der Computerinfrastruktur bereitgestellt werden. Insofern kann die Bereitstellung eines Systems eine oder mehrere der folgenden Optionen aufweisen:

(i) Installieren von Programmcode auf einer Datenverarbeitungseinheit wie z. B. dem in 1 gezeigten Computersystem von einem computerlesbaren Medium;
(ii) Hinzufügen von einer oder mehreren Datenverarbeitungseinheiten zu der Computerinfrastruktur und insbesondere zu der Cloud-Umgebung; und
(iii) Einbinden und/oder Modifizieren eines oder mehrerer vorhandener Systeme der Computerinfrastruktur, damit die Computerinfrastruktur die Prozesse der Erfindung durchführen kann.

Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zum Zwecke der Veranschaulichung vorgelegt und sind nicht als vollständig oder auf die offenbarten Ausführungsformen beschränkt zu verstehen. Der Fachmann weiß, dass zahlreiche Änderungen und Abwandlungen möglich sind, ohne von Umfang und Geist der beschriebenen Ausführungsformen abzuweichen. Die hier verwendete Begrifflichkeit wurde gewählt, um die Grundsätze der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber marktgängigen Technologien bestmöglich zu erläutern bzw. anderen Fachleuten das Verständnis der hier offenbarten Ausführungsformen zu ermöglichen.

Claims

Verfahren, das in einer Computerinfrastruktur mit computerausführbarem Code realisiert ist, der physisch auf einem computerlesbaren Speichermedium mit Programmierbefehlen enthalten ist, und das konfiguriert ist zum: Empfangen eines DHCP-Pakets (Dynamic Host Configuration Protocol); Einfügen von Tenant-spezifischen Optionsdaten in das DHCP-Paket; und Übertragen des DHCP-Pakets mit den Tenant-spezifischen Optionsdaten.
Verfahren nach Anspruch 1, wobei die Tenant-spezifischen Optionsdaten mindestens ein Transport-Agenten-Feld, das dazu verwendet wird, einen Overlay-Protokolltyp anzugeben, der für eine Tenant-Isolierung verwendet wird, oder ein Tenant-ID-Feld aufweisen, das dazu verwendet wird, einen Tenant eindeutig zu identifizieren.
Verfahren nach Anspruch 2, wobei der Overlay-Protokolltyp einen der Protokolltypen VLAN (Virtual Local Area Network), VXLAN (Virtual Extensible Local Area Network), DOVE (Distributed Overlay Virtual Ethernet), NVGRE (Network Virtualization using Generic Routing Encapsulation), STT (Stateless Transport Tunneling) und GENEVE (Generic Network Virtualization Encapsulation) aufweist.
Verfahren nach Anspruch 2, wobei die Tenant-spezifischen Optionsdaten des Weiteren ein Feld mit einer virtuellen Netzwerk-ID aufweisen, das dazu verwendet wird, ein virtuelles Netzwerk anzugeben.
Verfahren nach Anspruch 1, wobei die Tenant-spezifischen Optionsdaten in einen DHCP-Header des DHCP-Pakets eingefügt werden.
Verfahren nach Anspruch 1, wobei das DHCP-Paket in einem DHCP-Relay-Agenten empfangen wird und die Tenant-spezifischen Optionsdaten in dem DHCP-Relay-Agenten in das DHCP-Paket eingefügt werden.
Verfahren nach Anspruch 6, wobei das DHCP-Paket mit den Tenant-spezifischen Optionsdaten von dem DHCP-Relay-Agenten an einen DHCP-Server übertragen wird.
Verfahren nach Anspruch 1, wobei die Tenant-spezifischen Optionsdaten in einem DHCP-Client in das DHCP-Paket eingefügt werden.
Verfahren nach Anspruch 1, wobei die Programmierbefehle des Weiteren so konfiguriert sind, dass sie eine Internetprotokoll-Adresse (IP-Adresse) an einen DHCP-Client übertragen, der einem Tenant-ID-Feld der Tenant-spezifischen Optionsdaten entspricht.
Verfahren nach Anspruch 9, wobei die an den DHCP-Client übertragene IP-Adresse dem Tenant-ID-Feld der Tenant-spezifischen Optionsdaten entspricht und sich mit einer IP-Adresse eines anderen, unabhängigen Tenants überlappt.
Computerprogrammprodukt, aufweisend ein computerlesbares Speichermedium mit darauf enthaltenen Programmbefehlen, wobei das computerlesbare Speichermedium kein flüchtiges Signal per se ist und wobei die Programmbefehle durch eine Datenverarbeitungseinheit lesbar sind, um die Datenverarbeitungseinheit zum Durchführen eines Verfahrens zu veranlassen, aufweisend: Empfangen eines DHCP-Pakets; Feststellen, dass das DHCP-Paket Tenant-spezifische Optionsdaten aufweist; und Auswählen eines Adressraums auf Grundlage der Tenant-spezifischen Optionsdaten.
Computerprogrammprodukt nach Anspruch 11, wobei der auf Grundlage der Tenant-spezifischen Optionsdaten ausgewählte Adressraum des Weiteren aufweist: Feststellen, dass das DHCP-Paket mit den Tenant-spezifischen Optionsdaten mindestens eine Unteroption für die Verbindungsauswahl oder eine Option für die Subnetzauswahl aufweist; Feststellen, dass eine Adresse in einem angeforderten Subnetz verfügbar ist, wenn festgestellt wird, dass das DHCP-Paket mindestens eine Unteroption für die Verbindungsauswahl oder eine Option für die Subnetzauswahl aufweist; und Zuordnen der Adresse in dem angeforderten Subnetz, wenn die Adresse in dem angeforderten Subnetz verfügbar ist.
Computerprogrammprodukt nach Anspruch 12, wobei der auf Grundlage der Tenant-spezifischen Optionsdaten ausgewählte Adressraum des Weiteren ein Zuordnen einer Adresse für eine virtuelle Netzwerkkennung als Reaktion auf eine Feststellung aufweist, dass das DHCP-Paket nicht mindestens die Unteroption für die Verbindungsauswahl oder die Option für die Teilnetzauswahl aufweist.
Computerprogrammprodukt nach Anspruch 12, wobei der auf Grundlage der Tenant-spezifischen Optionsdaten ausgewählte Adressraum des Weiteren ein Zuordnen einer Adresse für eine virtuelle Netzwerk-ID als Reaktion auf eine Feststellung aufweist, dass die Adresse in dem angeforderten Subnetz nicht verfügbar ist.
Computerprogrammprodukt nach Anspruch 11, wobei das Verfahren des Weiteren ein Zuordnen eines globalen Adressraums als Reaktion auf eine Feststellung aufweist, dass das empfangene DHCP-Paket nicht die Tenant-spezifischen Optionsdaten aufweist.
Computerprogrammprodukt, aufweisend ein computerlesbares Speichermedium mit darauf enthaltenen Programmbefehlen, wobei das computerlesbare Speichermedium kein flüchtiges Signal per se ist und wobei die Programmbefehle durch eine Datenverarbeitungseinheit lesbar sind, um die Datenverarbeitungseinheit zum Durchführen eines Verfahrens zu veranlassen, aufweisend: Empfangen eines DHCP-Pakets, das Tenant-spezifische Optionsdaten aufweist; Lokalisieren eines Tenant-Adressraums auf Grundlage der Tenant-spezifischen Optionsdaten; Erhalten einer virtuellen Netzwerk-ID von einem VAP (Virtual Access Point); Erhalten einer Subnetzkonfiguration, die der erhaltenen virtuellen Netzwerk-ID entspricht; und Zuordnen einer IP-Adresse, die der erhaltenen Subnetzkonfiguration entspricht.
Computerprogrammprodukt nach Anspruch 16, wobei die Subnetzkonfiguration entweder in einer Unteroption für die Verbindungsauswahl oder in einer Option für die Subnetzauswahl enthalten ist.
Computerprogrammprodukt nach Anspruch 16, wobei die Subnetzkonfiguration von einer NVA (Network Virtualization Authority) erhalten wird.
Computerprogrammprodukt nach Anspruch 16, wobei die IP-Adresse, die der erhaltenen Subnetzkonfiguration entspricht, durch einen DHCP-Server zugeordnet wird.
Computerprogrammprodukt nach Anspruch 16, wobei das DHCP-Paket, das die Tenant-spezifischen Optionsdaten aufweist, durch einen DHCP-Relay-Agenten empfangen wird.
System, aufweisend: eine CPU, einen computerlesbaren Arbeitsspeicher und ein computerlesbares Speichermedium; Programmbefehle, um Multi-Tenancy-Daten in ein DHCP-Paket einzufügen; und Programmbefehle, um das DHCP-Paket mit den Multi-Tenancy-Daten zu übertragen, wobei die Programmbefehle auf dem computerlesbaren Speichermedium gespeichert werden, um über den computerlesbaren Arbeitsspeicher durch die CPU ausgeführt zu werden.
Verfahren nach Anspruch 21, wobei die Multi-Tenancy-Daten mindestens ein Transport-Agenten-Feld, das dazu verwendet wird, einen Overlay-Protokolltyps anzugeben, der für eine Tenant-Isolierung verwendet wird, ein Tenant-ID-Feld, das dazu verwendet wird, einen Tenant eindeutig zu identifizieren, oder ein Feld mit einer virtuellen Netzwerk-ID aufweisen, das dazu verwendet wird, ein virtuelles Netzwerk anzugeben.
System nach Anspruch 21, wobei die Multi-Tenancy-Daten in einem DHCP-Client in das DHCP-Paket eingefügt werden.
Verfahren zum Konfigurieren eines Datenrahmenformats für eine Tenant-spezifische DHCP-Option, aufweisend: Konfigurieren eines ersten Felds des Datenrahmenformats für eine Tenant-spezifische DHCP-Option, um einen Overlay-Protokolltyp anzugeben, der für die Tenant-Isolierung verwendet wird; Konfigurieren eines zweiten Felds des Datenrahmenformats für eine Tenant-spezifische DHCP-Option, um einen Tenant eindeutig zu identifizieren; und Konfigurieren eines dritten Felds des Datenrahmenformats für eine Tenant-spezifische DHCP-Option, um ein virtuelles Netzwerk anzugeben.
Verfahren nach Anspruch 24, wobei das zweite Feld durch einen DHCP-Server verwendet wird, um eine lokale Gültigkeit eines Adressbereich für einen Adressraum des Tenants anzugeben.