DE102013209372B4

DE102013209372B4 - Ein für die Aggregation virtueller Ethernet-Ports (VEPA) geeignetes mandantenfähiges Overlay-Netzwerk

Info

Publication number: DE102013209372B4
Application number: DE102013209372.1A
Authority: DE
Inventors: Amitabha Biswas; Uday S. Nagaraj
Original assignee: International Business Machines Corp
Current assignee: Kyndryl Inc
Priority date: 2012-06-05
Filing date: 2013-05-22
Publication date: 2016-06-30
Anticipated expiration: 2033-05-23
Also published as: DE102013209372A1; US20130322446A1; US8908691B2

Abstract

System, aufweisend: einen Hostserver, der einen virtuellen Switch bereitstellt, wobei der virtuelle Switch aufweist: Logik, die zum Empfangen eines Pakets von einer ersten virtuellen Maschine (VM) auf dem Hostserver eingerichtet ist; Logik, die eingerichtet ist, festzustellen, dass es sich bei einem Ziel des Paketes um eine dem Hostserver gemeinsame zweite VM handelt; Logik, die zum Kapseln des Pakets mit einem Tunnel-Header eingerichtet ist, um ein Overlay-Paket zu bilden; Logik, die eingerichtet ist, das Overlay-Paket über einen Tunnel an ein physisches Netzwerkelement zu senden, um daran Inspizierungsdienste durchführen zu lassen; Logik, die zum Empfangen des Overlay-Pakets vom physischen Netzwerkelement eingerichtet ist; Logik, die zum Entkapseln des Overlay-Pakets eingerichtet ist, um ein bearbeitetes Paket zu erhalten; und Logik, die zum Weiterleiten des bearbeiteten Pakets an die zweite VM eingerichtet ist, wobei der Tunnel-Header mandantenspezifische Informationen aufweist.

Description

HINTERGRUND
Die vorliegende Erfindung betrifft die Rechenzentrumsinfrastruktur, und genauer betrifft diese Erfindung das Ermöglichen der Aggregation virtueller Ethernet-Ports (Virtual Ethernet Port Aggregation (VEPA)) in einem mandantenfähigen (multitenant) Overlay-Netzwerk.
VEPA stellt einen Mechanismus dar, der das Prüfen und Ermöglichen von Datenverkehr (Zugriffssteuerung) zwischen virtuellen Maschinen (VMs) von die VMs beherbergenden Servern auf physische Netzwerkelemente verlagert, wie beispielsweise Switches, Router usw., mit denen die Server verbunden sind.
In einer Overlay-Netzwerkumgebung wird von VMs stammender Datenverkehr in einem getunnelten Paket gekapselt. Aufgrund dieser Beschränkung sind physische Netzwerkelemente im Overlay-Netzwerk unter Umständen nicht in der Lage, Client-definierte Weiterleitungsregeln auf Datenverkehr einer VM anzuwenden, da die für die Prüfung auf ordnungsgemäßen Zustand benötigten Daten nicht an Standardversätzen des vollständigen getunnelten Pakets verfügbar sind.
Es ist zu beachten, dass sich bei VEPA ein Sender und ein Empfänger von Datenverkehr auf demselben Server befinden, jedoch unterschiedliche Kennzeichnungsdaten besitzen, wie beispielsweise unterschiedliche Media Access Control(MAC)-Adressen, Internetprotokoll(IP)-Adressen usw. Daher geben für einen Tunnel-Header die Quellen- und Zielangaben denselben Server wieder. Die Tunnel-Header weisen jedoch Mandanteninformationen auf, mittels derer Vorgänge der Zugriffssteuerung durchgeführt werden. Darüber hinaus können die Tunnel-Header über ein IP-Datagramm als ein Benutzer-Datagramm-Protokoll (User Datagram Protocol (UDP)) aufgebaut sein.
Physische Netzwerkelemente besitzen heute nicht die Fähigkeit, die Tunnel-Header zu entfernen und dabei mandantenspezifische Informationen beizubehalten, Zugriffssteuerungsvorgänge am nativen Datenverkehr der virtuellen Maschine durchzuführen, den Tunnel-Header wieder anzubringen (und dabei bestimmte Zieladressinformationen zu modifizieren) und dann das Paket zum Ursprungsserver zurückzusenden. Physische Netzwerkelemente verfügen jedoch über sehr hochentwickelte Zugriffsteuerungsmechanismen, die zum Durchführen von Operationen der tiefgreifenden Paketinspizierung mit höheren Geschwindigkeiten verfügbar sind, als dies auf Servern möglich wäre. Dementsprechend wäre es vorteilhaft, über eine Lösung zu verfügen, bei der getunnelten Paketen in einer Overlay-Netzwerkumgebung VEPA bereitgestellt wird.
In der Veröffentlichung „VLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”, Mahalingam, M. u. a., Network Working Group, August 2011, 1–20, wird eine Netzwerkinfrastruktur für ein virtuelles Layer-2 Overlay-Netzwerks über einem Layer-3 Netzwerk beschrieben
KURZDARSTELLUNG
In einer Ausführungsform enthält ein System einen Hostserver, der einen virtuellen Switch bereitstellt, der virtuelle Switch enthaltend Logik, die zum Empfangen eines Pakets von einer ersten virtuellen Maschine (VM) auf einem Hostserver eingerichtet ist, Logik, die eingerichtet ist, festzustellen, dass es sich bei einem Ziel des Pakets um eine dem Hostserver gemeinsame zweite VM handelt, Logik, die zum Kapseln des Pakets mit einem Tunnel-Header eingerichtet ist, um ein Overlay-Paket zu bilden, Logik, die zum Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement eingerichtet ist, um daran Inspizierungsdienste durchführen zu lassen, Logik, die zum Empfangen des Overlay-Paketes vom physischen Netzwerkelement eingerichtet ist, Logik die zum Entkapseln des Overlay-Pakets eingerichtet ist, um ein bearbeitetes Paket zu erhalten, und Logik, die zum Weiterleiten des bearbeiteten Pakets an die zweite VM eingerichtet ist, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
In einer weiteren Ausführungsform beinhaltet ein Verfahren zum Ermöglichen von VEPA in einem Overlay-Netzwerk ein Empfangen eines Pakets von einer ersten VM auf einem Hostserver, Feststellen, dass es sich bei einem Ziel des Pakets um eine dem Hostserver gemeinsame zweite VM handelt, Kapseln des Pakets mit einem Tunnel-Header, um ein Overlay-Paket zu bilden, Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement, um daran Inspizierungsdienste durchführen zu lassen, Empfangen des Overlay-Paketes vom physischen Netzwerkelement, Entkapseln des Overlay-Pakets, um ein bearbeitetes Paket zu erhalten, und Weiterleiten des bearbeiteten Pakets an die zweite VM, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
In noch einer weiteren Ausführungsform enthält ein Computerprogrammprodukt zum Ermöglichen von VEPA in einem Overlay-Netzwerk ein computerlesbares Speichermedium mit darauf ausgebildetem computerlesbarem Programmcode, der computerlesbare Programmcode enthaltend computerlesbaren Programmcode, der für ein Empfangen eines Pakets von einer ersten VM auf einem Hostserver konfiguriert ist, computerlesbaren Programmcode, der konfiguriert ist, festzustellen, dass es sich bei einem Ziel des Pakets um eine dem Hostserver gemeinsame zweite VM handelt, computerlesbaren Programmcode, der für ein Kapseln des Pakets mit einem Tunnel-Header konfiguriert ist, um ein Overlay-Paket zu bilden, computerlesbaren Programmcode, der für ein Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement konfiguriert ist, um daran Inspizierungsdienste durchführen zu lassen, computerlesbaren Programmcode, der für ein Empfangen des Overlay-Paketes vom physischen Netzwerkelement konfiguriert ist, computerlesbaren Programmcode, der für ein Entkapseln des Overlay-Pakets konfiguriert ist, um ein bearbeitetes Paket zu erhalten, und computerlesbaren Programmcode, der für ein Weiterleiten des bearbeiteten Pakets an die zweite VM konfiguiert ist, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
Gemäß einer weiteren Ausführungsform enthält ein System Logik, die zum Empfangen eines Overlay-Pakets von einem virtuellen Switch über einen Tunnel eingerichtet ist, Logik, die zum Entkapseln des Overlay-Pakets durch Entfernen eines Tunnel-Headers eingerichtet ist, um ein inneres Paket zu erhalten, Logik, die zum Ermitteln einer Quelle und eines Ziels des inneren Pakets eingerichtet ist, Logik, die zum Durchführen von Inspizierungsdiensten am inneren Paket auf der Grundlage von im Overlay-Paket enthaltenen mandantenspezifischen Informationen eingerichtet ist, Logik, die eingerichtet ist, zu ermitteln, ob das innere Paket an das Ziel zu senden ist, Logik, die eingerichtet ist, im Falle, dass das Ermitteln ergibt, das innere Paket an das Ziel zu senden, das innere Paket wieder in den Tunnel-Header zu kapseln, um das Overlay-Paket zu bilden, und das Overlay-Paket über den Tunnel an den virtuellen Switch zu senden, und Logik, die eingerichtet ist, im Falle, dass das Ermitteln ergibt, das Paket nicht an das Ziel zu senden, das Paket fallen zu lassen, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
Weitere Aspekte und Ausführungsformen der vorliegenden Erfindung werden anhand der folgenden detaillierten Beschreibung ersichtlich, die in Verbindung mit den Zeichnungen in beispielhafter Weise die Grundgedanken der Erfindung veranschaulichen.
KURZBESCHREIBUNG DER MEHREREN ZEICHNUNGSANSICHTEN
1 veranschaulicht eine Netzwerkarchitektur gemäß einer Ausführungsform.
2 zeigt eine stellvertretende Hardwareumgebung gemäß einer Ausführungsform, die den Servern und/oder Clients von 1 zugeordnet sein kann.
3 zeigt ein vereinfachtes Schaubild eines virtualisierten Rechenzentrums gemäß einer Ausführungsform.
4 zeigt einen Teil einer Overlay-Netzwerkumgebung gemäß einer Ausführungsform.
5A zeigt eine Paketkapselung gemäß einer Ausführungsform.
5B zeigt einen Informationsaustausch für die Paketkapselung gemäß einer Ausführungsform.
6 zeigt einen Ablaufplan eines Verfahrens gemäß einer Ausführungsform.
7 zeigt einen Ablaufplan eines Verfahrens gemäß einer Ausführungsform.
DETAILLIERTE BESCHREIBUNG
Die folgende Beschreibung erfolgt zum Zwecke des Veranschaulichens der allgemeinen Grundgedanken der vorliegenden Erfindung und ist nicht als die hierin beanspruchten erfindungsgemäßen Konzepte einschränkend gedacht. Weiterhin können bestimmte hierin beschriebene Merkmale in Kombination mit anderen beschriebenen Merkmalen in jeder der vielfältigen möglichen Kombinationen und Permutationen verwendet werden.
Sofern hierin nicht spezifisch anderweitig festgelegt, werden alle Begriffe in ihrer breitest möglichen Interpretation vorgelegt, was sowohl durch die Beschreibung implizierte als auch durch den Fachmann verstandene und/oder in Wörterbüchern, Abhandlungen usw. festgelegte Bedeutungen einschließt.
Es ist zudem zu beachten, dass die Singularformen „ein”, „eine” und „der”, „die”, „das” sowie deren Deklinationen, wie sie in der Beschreibung und den angehängten Ansprüchen verwendet werden, Pluralbezeichnungen mit einschließen, sofern nichts Anderweitiges angegeben ist.
In einem Ansatz wird die Aggregation virtueller Ethernet-Ports (VEPA) in einem Overlay-Netzwerk ermöglicht, um die Fähigkeit der Netzwerkelemente vorteilhaft zu nutzen, Zugriffssteuerungsvorgänge an Overlay-Netzwerk-Datenverkehr in Verbindung mit bestimmten Informationen aus den Tunnel-Headern bereitstellen zu können. Die nativen Fähigkeiten von Prozessoren, wie beispielsweise anwendungsspezifische integrierte Schaltungen (application specific integrated circuits (ASICs)) in den physischen Netzwerkelementen, können dann eingesetzt werden, um einen höheren Durchsatz und eine höher entwickelte Paketinspizierung bereitzustellen als dies allein mithilfe des Servers möglich ist.
In einer allgemeinen Ausführungsform enthält ein System einen Hostserver, der einen virtuellen Switch bereitstellt, der virtuelle Switch enthaltend Logik, die zum Empfangen eines Pakets von einer ersten virtuellen Maschine (VM) auf einem Hostserver eingerichtet ist, Logik, die eingerichtet ist, festzustellen, dass es sich bei einem Ziel des Pakets um eine dem Hostserver gemeinsame zweite VM handelt, Logik, die zum Kapseln des Pakets mit einem Tunnel-Header eingerichtet ist, um ein Overlay-Paket zu bilden, Logik, die zum Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement eingerichtet ist, um daran Inspizierungsdienste durchführen zu lassen, Logik, die zum Empfangen des Overlay-Paketes vom physischen Netzwerkelement eingerichtet ist, Logik die zum Entkapseln des Overlay-Pakets eingerichtet ist, um ein bearbeitetes Paket zu erhalten, und Logik, die zum Weiterleiten des bearbeiteten Pakets an die zweite VM eingerichtet ist, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
In einer weiteren allgemeinen Ausführungsform beinhaltet ein Verfahren zum Ermöglichen von VEPA in einem Overlay-Netzwerk ein Empfangen eines Pakets von einer ersten VM auf einem Hostserver, Feststellen, dass es sich bei einem Ziel des Pakets um eine dem Hostserver gemeinsame zweite VM handelt, Kapseln des Pakets mit einem Tunnel-Header, um ein Overlay-Paket zu bilden, Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement, um daran Inspizierungsdienste durchführen zu lassen, Empfangen des Oveilay-Paketes vom physischen Netzwerkelement, Entkapseln des Overlay-Pakets, um ein bearbeitetes Paket zu erhalten, und Weiterleiten des bearbeiteten Pakets an die zweite VM, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
In noch einer weiteren allgemeinen Ausführungsform enthält ein Computerprogrammprodukt zum Ermöglichen von VEPA in einem Overlay-Netzwerk ein computerlesbares Speichermedium mit darauf ausgebildetem computerlesbarem Programmcode, der computerlesbare Programmcode enthaltend computerlesbaren Programmcode, der für ein Empfangen eines Pakets von einer ersten VM auf einem Hostserver konfiguriert ist, computerlesbaren Programmcode, der konfiguriert ist, festzustellen, dass es sich bei einem Ziel des Pakets um eine dem Hostserver gemeinsame zweite VM handelt, computerlesbaren Programmcode, der für ein Kapseln des Pakets mit einem Tunnel-Header konfiguriert ist, um ein Overlay-Paket zu bilden, computerlesbaren Programmcode, der für ein Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement konfiguriert ist, um daran Inspizierungsdienste durchführen zu lassen, computerlesbaren Programmcode, der für ein Empfangen des Overlay-Pakets vom physischen Netzwerkelement konfiguriert ist, computerlesbaren Programmcode, der für ein Entkapseln des Overlay-Pakets konfiguriert ist, um ein bearbeitetes Paket zu erhalten, und computerlesbaren Programmcode, der für ein Weiterleiten des bearbeiteten Pakets an die zweite VM konfiguriert ist, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
Gemäß einer weiteren allgemeinen Ausführungsform enthält ein System Logik, die zum Empfangen eines Overlay-Pakets von einem virtuellen Switch über einen Tunnel eingerichtet ist, Logik, die zum Entkapseln des Overlay-Pakets durch Entfernen eines Tunnel-Headers eingerichtet ist, um ein inneres Paket zu erhalten, Logik, die zum Ermitteln einer Quelle und eines Ziels des inneren Pakets eingerichtet ist, Logik, die zum Durchführen von Inspizierungsdiensten am inneren Paket auf der Grundlage von im Overlay-Paket enthaltenen mandantenspezifisehen Informationen eingerichtet ist, Logik, die eingerichtet ist, zu ermitteln, ob das innere Paket an das Ziel zu senden ist, Logik, die eingerichtet ist, im Falle, dass das Ermitteln ergibt, das innere Paket an das Ziel zu senden, das innere Paket wieder in den Tunnel-Header zu kapseln, um das Overlay-Paket zu bilden und das Overlay-Paket über den Tunnel an den virtuellen Switch zu senden, und Logik, die eingerichtet ist, im Falle, dass das Ermitteln ergibt, das Paket nicht an das Ziel zu senden, das Paket fallen zu lassen, wobei der Tunnel-Header mandantenspezifische Informationen enthält.
Wie für den Fachmann ersichtlich ist, können Aspekte der vorliegenden Erfindung als System, Verfahren, oder Computerprogrammprodukt ausgebildet werden. Dementsprechend können Aspekte der vorliegenden Erfindung in Form einer vollständigen Hardwareausführungsform, einer vollständigen Softwareausführungsform (darunter Firmware, residente Software, Mikrocode usw.) oder in einer Ausführungsform ausgebildet werden, die Software- und Hardwareaspekte kombiniert, was hierin sämtlich allgemein als „Logik”, „Schaltung”, „Modul” oder „System” bezeichnet sein kann. Weiterhin können Aspekte der vorliegenden Erfindung in Form eines Computerprogrammprodukts ausgebildet werden, das in einem oder mehreren computerlesbaren Medien mit darauf enthaltenem computerlesbarem Programmcode enthalten sein kann.
Jede beliebige Kombination aus einem oder mehreren computerlesbaren Medien kann verwendet werden. Bei dem computerlesbaren Medium kann es sich um ein computerlesbares Signalmedium oder ein nichtflüchtiges computerlesbares Speichermedium handeln. Bei einem nichtflüchtigen computerlesbaren Speichermedium kann es sich zum Beispiel, ohne darauf beschränkt zu sein, um ein System, eine Vorrichtung oder eine Einheit elektronischer, magnetischer, optischer, elektromagnetischer, Infrarot oder Halbleiter verwendender Art sowie jede beliebige geeignete Kombination des Vorgenannten handeln. Zu spezielleren Beispielen für das nichtflüchtige computerlesbare Speichermedium gehört Folgendes (nicht erschöpfende Liste): eine transportable Computerdiskette, eine Festplatte, ein Speicher mit wahlfreiem Zugriff (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein transportabler Nur-Lese-Compact-Disk-Speicher (CD-ROM), ein Nur-Lese-Blu-Ray-Disk-Speicher (BD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder eine beliebige geeignete Kombination des Vorgenannten. Im Kontext dieses Dokuments kann es sich bei einem nichtflüchtigen computerlesbaren Speichermedium um jedes gegenständliche Medium handeln, das in der Lage ist, ein Programm oder eine Anwendung zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Ausführung von Anweisungen beinhalten oder speichern kann.
Zu einem computerlesbaren Signalmedium kann ein verbreitetes Datensignal mit darin zum Beispiel im Basisband oder als Teil einer Trägerwelle ausgebildetem computerlesbarem Programmcode zählen. Solch ein verbreitetes Signal kann in jeder beliebigen einer Vielfalt von Formen ausgebildet werden, einschließlich, ohne auf diese beschränkt zu sein, elektromagnetische, optische oder jede geeignete Kombination davon. Bei einem computerlesbaren Signalmedium kann es sich um jedes computerlesbare Medium handeln, das kein nichtflüchtiges computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Ausführung von Anweisungen übertragen, verbreiten oder transportieren kann, wie beispielsweise eine elektrische Verbindung mit einer oder mehreren Leitungen, ein Lichtwellenleiter usw.
Der in einem computerlesbaren Medium enthaltene Programmcode kann mittels eines beliebigen geeigneten Mediums, einschließlich, ohne auf diese beschränkt zu sein, kabellose, kabelgebundene, Lichtwellenleiterkabel, Hochfrequenz (HF) usw., oder einer beliebigen geeigneten Kombination des Vorgenannten übertragen werden.
Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorlegenden Erfindung kann in jeder Kombination einer oder mehrerer Programmiersprachen, darunter eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder Ähnliches und herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C” oder ähnliche Programmiersprachen, geschrieben sein. Der Programmcode kann 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 vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Szenario kann der entfernt angeordnete Computer oder Server mit dem Computer des Benutzers über jede beliebige Art von Netzwerk, darunter ein lokales Netzwerk (local area network (LAN)), ein Speicherbereichsnetzwerk (storage area network SAN)) und/oder ein Weitverkehrsnetzwerk (wide area network (WAN)), jedes beliebige virtuelle Netzwerk verbunden sein, oder es kann eine Verbindung zu einem externen Computer zum Beispiel mittels eines Internetdienstanbieters (Internet Service Provider (ISP)) über das Internet, hergestellt werden.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Abbildungen von Ablaufplänen und/oder Blockschaubildern von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß den vielfältigen Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Abbildungen von Ablaufplänen und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Abbildungen von Ablaufplänen und/oder den Blockschaubildern durch Computerprogrammanweisungen realisiert werden kann.
Diese Computerprogrammanweisungen können einem Prozessor eines universellen Computers, eines zweckbestimmten Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine so zu erzeugen, dass die Anweisungen, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel zum Realisieren der im Block oder in den Blöcken des Ablaufplans und/oder Blockschaubildes angegebenen Funktionen/Handlungen erzeugen.
Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anleiten kann, auf eine bestimmte Weise zu funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel einschließlich Anweisungen erzeugen, welche die im Block oder in den Blöcken des Ablaufplans und/oder des Blockschaubildes angegebene Funktion/Handlung ausführen.
Die Computerprogrammanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um eine Reihe von auf dem Computer, der anderen programmierbaren Vorrichtung oder den anderen Einheiten auszuführenden Operationsschritten hervorzurufen, um einen auf dem Computer realisierten Prozess so zu erzeugen, dass die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführten Anweisungen Prozesse zum Realisieren der im Block oder in den Blöcken des Ablaufplans und/oder Blockschaubildes angegebenen Funktionen/Handlungen bereitstellen.
1 veranschaulicht eine Netzwerkarchitektur 100 gemäß einer Ausführungsform. Wie in 1 gezeigt, werden eine Vielzahl entfernt angeordneter Netzwerke 102 einschließlich eines ersten entfernt angeordneten Netzwerks 104 und eines zweiten entfernt angeordneten Netzwerks 106 bereitgestellt. Ein Gateway 101 kann zwischen den entfernt angeordneten Netzwerken 102 und einem nahen Netzwerk 108 angeschlossen werden. Im Kontext der vorliegenden Netzwerkarchitektur 100, können die Netzwerke 104, 106 in jeder beliebigen Form vorliegen, einschließlich, ohne auf diese beschränkt zu sein, ein LAN, ein VLAN, ein WAN wie beispielsweise das Internet, ein öffentliches Telefonnetz (public switched telephone network (PSTN)), ein internes Telefonnetz usw.
In Verwendung dient das Gateway 101 als Eintrittspunkt von den entfernt angeordneten Netzwerken 102 in das nahe Netzwerk 108. Insofern kann das Gateway 101 als ein Router fungieren, der in der Lage ist, ein gegebenes Datenpaket zu leiten, das bei dem Gateway 101 ankommt, sowie als ein Switch fungieren, der für ein gegebenes Datenpaket einen tatsächlichen Pfad in das und aus dem Gateway 101 heraus bereitstellt.
Weiterhin enthalten ist mindestens ein mit dem nahen Netzwerk 108 verbundener Datenserver 114, auf den von den entfernt angeordneten Netzwerken 102 über das Gateway 101 zugegriffen werden kann. Es ist zu beachten, dass zu dem oder den Datenservern 114 jeder beliebige Typ von Computereinheit/Groupware zählen kann. Mit jedem Datenserver 114 verbunden ist eine Vielzahl von Benutzereinheiten 116. Zu solchen Benutzereinheiten 116 kann ein Arbeitsplatzcomputer, ein Laptopcomputer, ein Handheldcomputer, ein Drucker und/oder jeder beliebige andere Typ Logik enthaltende Hardware zählen. Es ist zu beachten, dass eine Benutzereinheit 111 in manchen Ausführungsformen auch direkt mit jedem der Netzwerke verbunden sein kann.
Eine Peripherieeinheit 120 oder eine Reihe von Peripherieeinheiten 120, z. B. Faxgeräte, Drucker, Scanner, Festplattenlaufwerke, Netzwerk- oder lokale Speichereinheiten oder -systeme usw., kann mit einem oder mehreren der Netzwerke 104, 106, 108 verbunden sein. Es ist zu beachten, dass Datenbanken und/oder zusätzliche Komponenten mit jedem oder integriert in jeden mit den Netzwerken 104, 106, 108 verbundenen Typ von Netzwerkelementen verwendet werden können. Im Kontext der vorliegenden Beschreibung kann sich ein Netzwerkelement auf jede beliebige Komponente eines Netzwerks beziehen.
Gemäß manchen Ansätzen können hierin beschriebene Verfahren und Systeme mit und/oder auf virtuellen Systemen und/oder Systemen realisiert werden, die ein oder mehrere Systeme emulieren, wie beispielsweise einem UNIX System, das eine IBM z/OS Umgebung emuliert, einem UNIX System, das eine MICROSOFT WINDOWS Umgebung virtuell beherbergt, einem MICROSOFT WINDOWS System, das eine IBM z/OS Umgebung emuliert usw. Diese Virtualisierung und/oder Emulation kann in manchen Ausführungsformen durch die Verwendung von VMWARE Software verbessert werden.
In weiteren Ansätzen können ein oder mehrere Netzwerke 104, 106, 108 für ein Cluster von Systemen stehen, das gemeinhin als „Cloud” bezeichnet wird. Beim Cloud-Computing werden jedem System in der Cloud in einer Anforderungsbeziehung (on-demand relationship) gemeinsam genutzte Ressourcen bereitgestellt, wie beispielsweise Verarbeitungsleistung, Peripherieeinheiten, Software, Daten, Server usw., wobei der Zugriff und die Verteilung von Diensten zwischen vielen Computersystemen ermöglicht wird. Cloud-Computing geht üblicherweise mit einer Internetverbindung zwischen den in der Cloud operierenden Systemen einher, andere im Stand der Technik bekannte Techniken des Verbindens der Systeme können jedoch ebenfalls verwendet werden.
2 zeigt gemäß einer Ausführungsform eine stellvertretende Hardwareumgebung, die einer Benutzereinheit 116 und/oder einem Server 114 von 1 zugeordnet ist. 2 veranschaulicht gemäß mehrerer Ausführungsformen eine typische Hardwarekonfiguration einer Workstation mit einer Zentraleinheit (central processing unit (CPU)) 210, wie beispielsweise einem Mikroprozessor, und einer Anzahl weiterer Einheiten, die über einen oder mehrere Busse 212 verbunden sind, die unterschiedlichen Typs sein können, wie beispielsweise einen lokalen Bus, einen parallelen Bus, einen seriellen Bus usw.
Die in 2 gezeigte Workstation enthält einen Speicher mit wahlfreiem Zugriff (RAM) 214, einen Nur-Lese-Speicher (ROM) 216, einen E/A-Adapter 218 zum Verbinden von Peripherieeinheiten wie beispielsweise Plattenspeichereinheiten 220 mit dem einen oder den mehreren Bussen 212, einen Benutzerschnittstellenadapter 222 zum Verbinden einer Tastatur 224, einer Maus 226, eines Lautsprechers 228, eines Mikrofons 232 und/oder anderer Benutzerschnittstelleneinheiten, wie beispielsweise eines berührungsempfindlichen Bildschirms, einer Digitalkamera (nicht gezeigt) usw., mit dem einen oder den mehreren Bussen 212, einen Datenübertragungsadapter 234 zum Verbinden der Workstation mit einem Datenübertragungsnetzwerk 235 (z. B. einem Datenverarbeitungsnetzwerk) und einen Anzeigeadapter 236 zum Verbinden des einen oder der mehreren Busse 212 mit einer Anzeigeeinheit 238.
Auf der Workstation kann sich ein darauf residentes Betriebssystem, wie beispielsweise das MICROSOFT WINDOWS Betriebssystem (BS), ein MAC BS, ein UNIX BS usw., befinden. Es ist ersichtlich, dass eine bevorzugte Ausführungsform auch auf anderen Plattformen und Betriebssystemen als den erwähnten realisiert werden kann. Eine bevorzugte Ausführungsform kann unter Verwendung der Sprache JAVA, XML, C und/oder C++ oder anderer Programmiersprachen zusammen mit einer objektorientierten Programmierverfahrensweise geschrieben sein. Die objektorientierte Programmierung (Object oriented programming (OOP)), die beim Entwickeln komplexer Anwendungen zunehmend Verwendung gefunden hat, kann verwendet werden.
Unter Bezugnahme auf 3 wird nun eine Konzeptansicht eines Overlay-Netzwerkes 300 gemäß einer Ausführungsform gezeigt. Um Netzwerkdienste anders als durch einfaches Bereitstellen eines Strukturpfades (Konnektivität) zwischen Einheiten zu virtualisieren, können Dienste auf Paketen ausgeführt werden, wenn sie sich durch das Gateway 314 bewegen, welches das Routing und Weiterleiten für Pakete bereitstellt, die sich zwischen dem oder den nicht-virtuellen Netzwerken 312 und dem Virtuellen Netzwerk A 304 und dem Virtuellen Netzwerk B 306 bewegen. Das eine oder die mehreren virtuellen Netzwerke 304, 306 existieren innerhalb einer physischen (realen) Netzwerkinfrastruktur 302. Wie dem Fachmann bekannt ist, kann die Netzwerkinfrastruktur 302 beliebige Komponenten, Hardware, Software und/oder Funktionalität beinhalten die typischerweise einer Netzwerkinfrastruktur zugeordnet ist oder in dieser verwendet wird, einschließlich, ohne auf diese beschränkt zu sein, Switches, Anschlüsse, Leitungen, Schaltungen, Kabel, Server, Hosts, Speichermedien, Betriebssysteme, Anwendungen, Ports, E/A, usw. Diese Netzwerkinfrastruktur 302 unterstützt mindestens ein nicht-virtuelles Netzwerk 312, bei dem es sich um ein Bestandsnetzwerk handeln kann.
Jedes virtuelle Netzwerk 304, 306 kann jede beliebige Anzahl virtueller Maschinen (VMs) 308, 310 verwenden. In einer Ausführungsform enthält das Virtuelle Netzwerk A 304 eine oder mehrere VMs 308, und das Virtuelle Netzwerk B 306 enthält eine oder mehrere VMs 310. Wie in 3 gezeigt, werden die VMs 308, 310 nicht durch die virtuellen Netzwerke 304, 306 gemeinsam genutzt, sondern sind stattdessen zu jedem gegebenen Zeitpunkt ausschließlich in nur einem einzigen virtuellen Netzwerk 304, 306 enthalten.
Gemäß einer Ausführungsform kann das Overlay-Netzwerk 300 eine oder mehrere skalierbare Strukturkomponenten (scalable fabric components (SFCs)) mit Zellen-Switch-Domänen enthalten, die mit einer oder mehreren verteilten Leitungskarten (distributed line cards (DLCs)) verbunden sind.
Durch eine Architektur mit „flachem Switch” kann die Vielzahl von VMs Daten einfach und effizient durch die Architektur verschieben. Es ist für VMs allgemein sehr schwierig, Daten über Schichten der Ebene 3, zwischen einem Teilnetz zu einem anderen Teilnetz, einem Internetprotokoll(IP)-Teilnetz zu einem IP-Teilnetz usw. zu verschieben. Wenn die Architektur jedoch einem großen flachen Switch in einer sehr großen Domäne der Schicht 2 gleicht, werden die VMs bei Ihrem Versuch unterstützt, Daten über die Architektur zu verschieben.
Unter Bezugnahme auf 4 wird nun ein Teil einer Overlay-Netzwerkumgebung 400 gemäß einer Ausführungsform gezeigt, um zu erklären, wie VEPA in einer Overlay-Netzwerkumgebung 400 ermöglicht werden kann. In dieser Overlay-Netzwerkumgebung 400 sind ein physischer Switch 402, ein virtueller Switch 410 auf einem Hostserver 404 und zwei VMs (ein Quellen-VM 406 und eine Ziel-VM 408) gezeigt. Der virtuelle Switch 410 befindet sich innerhalb eines Hypervisor 420, der sich auf dem Hostserver 404 befindet. Natürlich kann das Overlay-Netzwerk 400 mehr Komponenten, Beziehungen, Funktionalität und/oder Komplexität aufweisen als in 4 gezeigt, wie für den Fachmann verständlich ist.
Wie gezeigt, tritt Datenverkehr 412 (der ein ursprüngliches Paket aufweist) von einer beliebigen Quellen-VM 406 in einen virtuellen Switch 410 ein, der sich auf einem Hostserver 404 befindet. Obwohl hierin nur ein einziges Paket beschrieben wird, kann jeder hierin beschriebene Datenverkehr mehrere Pakete jedes im Stand der Technik bekannten Typs umfassen, wie beispielsweise IP-Pakete, Overlay-Pakete usw.
Dieser Datenverkehr 412 ist für die Ziel-VM 408 bestimmt, wenn jedoch VEPA in der Overlay-Netzwerkumgebung 400 ermöglicht ist, wird er durch den virtuellen Switch 410 anstatt zur Ziel-VM 408 durch das physische Netzwerkelement 402 hindurch geleitet. Dadurch wird es dem physischen Netzwerkelement 402 ermöglicht, bestimmte Prüfungen auf ordnungsgemäßen Zustand, Inspizierungsdienste usw. am Datenverkehr 412 durchzuführen, anstatt sich zum Durchführen dieser Funktionen auf den virtuellen Switch 410 zu verlassen. Üblicherweise ist das physische Netzwerkelement 402 besser ausgerüstet, diese Funktionalität schneller und effizienter durchzuführen als der virtuelle Switch 410.
Der virtuelle Switch 410 kapselt das von der Quellen-VM 406 empfangene ursprüngliche Paket in einen Tunnel und fügt in bestimmten Feldern im Tunnel-Header mandantenspezifische Informationen hinzu, wie in Hinblick auf 5A bis 5B detaillierter beschrieben wird. Unter erneuter Bezugnahme auf 4 wird dieses getunnelte Paket dann aus einer physischen Netzwerkschnittstelle des Hostservers 404 heraus und an das physische Netzwerkelement 402, wie beispielsweise einen Switch, Router, ein Gateway usw., weitergeleitet. Da VEPA in der Overlay-Netzwerkumgebung 400 ermöglicht ist, sind die Quellen und das Ziel des getunnelten Pakets dieselben, da die Adresse die des Hostservers 404 ist; gemäß hierin beschriebenen Ausführungsformen können durch das physische Netzwerkelement 402, mit dem der Hostserver 404 verbunden ist, an dem von der Quellen-VM 406 empfangenen Datenverkehr 412 eine Prüfung auf ordnungsgemäßen Zustand und/oder andere Dienste durchgeführt werden.
Dementsprechend trennt Eintrittslogik des physischen Netzwerkelements 402 bei Eintreten des Datenverkehrs 418 (der ein das ursprüngliche Paket kapselndes Overlay-Paket aufweist) vom Hostserver 404 in das physische Netzwerkelement 402 die Tunnel-Header vom Overlay-Paket, wobei tunnelspezifische Informationen und Informationen zum Serverstandort beibehalten werden, wie in 5A bis 5B detaillierter beschrieben wird.
Unter erneuter Bezugnahme auf 4 wird das durch die Quellen-VM 406 gesendete ursprüngliche Paket zusammen mit den die Mandantenfunktionalität der VM festlegenden Informationen an Paketinspizierungslogik des physischen Netzwerkelements 402 weitergeleitet. Diese Komponente des physischen Netzwerkelements 402 ist in vielfältigen Ausführungsformen eingerichtet, die mandantenspezifischen Informationen zusammen mit verschiedenen Feldern im ursprünglichen Paket zu verwenden, um unter anderen möglichen Diensten eine Paketinspizierung und/oder Tests auf ordnungsgemäßen Zustand durchzuführen.
Nachdem das ursprüngliche Paket durch Überprüfen als sicher für das durch die Quellen-VM 406 beabsichtigte Senden an die Ziel-VM 408 eingestuft wurde, wird das ursprüngliche Paket wieder in einen Tunnel gekapselt, und die Tunnel-Header werden dann im physischen Netzwerkelement 402 wieder mit den Mandanteninformationen und den Zielinformationen versehen. Dieser Datenverkehr 416 wird dann (einschließlich des getunnelten Pakets) zurück zum Hostserver 404 weitergeleitet, um durch den virtuellen Switch 410 empfangen zu werden. Wenn das getunnelte Paket durch den virtuellen Switch 410 empfangen wird, entfernt der virtuelle Switch 410 unter der Annahme, dass die Tunnel-Header genügend mandanten- und zielspezifische Informationen enthalten, die Tunnel-Header und leitet das entkapselte Paket als Datenverkehr 414 an die Ziel-VM 408 weiter. Dementsprechend verlässt der für die Ziel-VM 408 bestimmte Datenverkehr 414 den virtuellen Switch 410, nachdem er darin empfangen wurde und Tunnel-Header und zugehörige Informationen aus dem ursprünglichen Paket entkapselt wurden.
Auf diese Weise kann Mandantenfähigkeit in der Overlay-Netzwerkumgebung 400 unterstützt werden, während VEPA in der Umgebung noch ermöglicht ist. Dies ermöglicht es ASICs oder anderen Hardwareelementen im physischen Netzwerkelement 402, Dienste, eine Anwendung von Zugriffssteuerungslisten (access control lists (ACLs)) oder eine beliebige andere gewünschte Funktionalität an einem von einer VM zu einer anderen VM innerhalb des Overlay-Netzwerks gesendeten Paket durchzuführen.
Unter Bezugnahme auf 5A wird nun eine Paketkapselung 500 gemäß einer Ausführungsform gezeigt. Die Paketkapselung 500 enthält äußere und innere Teile, wobei es sich bei dem inneren Paket um das ursprüngliche Paket handelt (ein von der Quellen-VM erzeugtes und von dieser kommend empfangenes Ethernet-Paket 502) und sich die äußeren Header auf die Overlay-Kapselung beziehen. Wie gezeigt, weist der Tunnel(Overlay)-Header 514 einen äußeren Media Access Control(MAC)-Header 506, einen äußeren IP-Header 508 und einen äußeren User-Datagram-Protokol(UDP))-Header 510 sowie mandantenspezifische Informationen 512 auf. Die äußere zyklische Redundanzprüfung (cyclic redundancy check (CRC)) 504 kann, wie im Stand der Technik bekannt, hinzugefügt werden.
Bei dieser Kapselung 500 können dem Tunnel(Overlay)-Header 514 mandantenspezifische Informationen 512 hinzugefügt werden, und manche mandantenspezifische Informationen können auch im äußeren UDP-Header 510 hinzugefügt werden, wenn es durch die verwendete spezielle Overlay-Netzwerkumgebung ermöglicht wird. In einer Ausführungsform kann ein Virtual eXtensible Local Area Network (VXLAN) oder eine modifizierte Version eines VXLAN verwendet werden. Natürlich können eine beliebige andere Overlay-Netzwerktechnologie, ein beliebiges anderes Protokoll und/oder beliebige andere Einheiten, wie sie im Stand der Technik bekannt sind, verwendet werden.
Wie in 5A bis 5B gezeigt, kann ein Paketinspizierungsblock 514 oder ein Modul des physischen Netzwerkelements 402 Informationen von einem empfangenen Overlay-Paket, wie beispielsweise mandantenspezifische Informationen 516 vom äußeren UDP-Header 510, mandantenspezifische Informationen 512 und bestimmte Felder 518 aus dem Ethernet-Paket 502 der Quellen-VM usw. empfangen. Diese Informationen können durch den Paketinspizierungsblock 514 verwendet werden, um zu ermitteln, wie auf den Empfang des Overlay-Pakets zu reagieren ist.
Wenn bei einem Ansatz der Inspizierungsblock 514 feststellt, dass das Paket zum Weiterleiten an sein beabsichtigtes Ziel (die Ziel-VM) akzeptabel ist, werden die Tunnel-Header wieder angebracht 522 und das gekapselte Paket zum Empfang durch den virtuellen Switch (und nachfolgendes Weiterleiten an die Ziel-VM) an den Hostserver weitergeleitet 524.
Wenn gemäß einem anderen Ansatz der Inspizierungsblock 514 feststellt, dass das Paket nicht zum Weiterleiten an sein beabsichtigtes Ziel (die Ziel-VM) akzeptabel ist, wird das Paket fallengelassen 520.
Bei einem Ansatz kann das innere Paket analysiert werden, um einen oder mehrere am inneren Paket durchzuführende Dienste zu bestimmen. Zum Beispiel muss in einer Ausführungsform, bei der bestimmte Dienste nur an einem Teilsatz von Netzwerkdatenverkehr (wie beispielsweise nur für einen speziellen Mandanten, nur für ein spezielles Ziel, nur für eine spezielle Quelle usw.) durchgeführt werden, elf Paket, das diese Dienste erfordert, als diese Dienste erfordernd identifiziert werden, um den interessierenden Dienst zu erhalten. Dementsprechend erfordert in einer Ausführungsform zumindest ein Teil der Ermittlung, ob das Paket an das Ziel weitergeleitet werden sollte, eine Ermittlung, ob und welche Dienste durchzuführen sind.
Neben anderen Möglichkeiten zählen gemäß verschiedener Ausführungsformen zu Diensten, die an einem Paket durchgeführt werden können, ohne darauf beschränkt zu sein, Firewall-Dienste, Dienste eines Systems zur Verhinderung von Eingriffen (intrusion prevention system (IPS)), Dienste eines Systems zur Erkennung von Eingriffen (intrusion detection system (IDS)), IPS/IDS-Dienste, Dienste zum Serverlastausgleich, Dienste der LAN-Optimierung, VPN-Dienste, Dienste der Videooptimierung, Dienste der Netzwerkadressübersetzung (network address translation (NAT)), Verschlüsselungsdienste, Entschlüsselungsdienste, eine Anwendung von Zugriffssteuerungslisten (access control lists (ACLs)), usw., wie dem Fachmann bekannt ist.
In einer Ausführungsform kann ein Tunnel-Header (wie beispielsweise ein VXLAN-Rahmen-Format) wie folgt aussehen:
Dieses Rahmenformat kann verwendet werden, um zu ermitteln, ob ein Paket in einer Anzahl verschiedener Weisen auf ein inneres Paket hin inspiziert werden sollte. Bei einer dieser Weisen kann der Zielport (Dest Port) ermittelt werden. Beim vorstehend als ein Beispiel gezeigten Rahmenformat handelt es sich beim Zielport um einen VXLAN-Port, was anzeigt, dass das Paket einen Tunnel-Header aufweist. Dementsprechend kann dieses Paket entkapselt werden, um zu ermitteln, was das innere Paket enthält, und dann zu ermitteln, ob Dienste am inneren Paket durchgeführt werden sollten. Natürlich können andere Arten des Ermittelns, ob Dienste an einem inneren Paket durchgeführt werden sollten und ob ein Paket ein inneres Paket aufweist, verwendet werden, wie dem Fachmann bekannt und hierin beschrieben ist.
Unter Bezugnahme auf 6 wird nun ein Ablaufplan eines Verfahrens 600 gemäß einer Ausführungsform gezeigt. Das Verfahren 600 kann gemäß der vorliegenden Erfindung in vielfältigen Ausführungsformen unter anderem in jeder der in 1 bis 5 abgebildeten Umgebungen durchgeführt werden. Wie der Fachmann beim Lesen der vorliegenden Beschreibungen erkennt, kann das Verfahren 600 natürlich mehr oder weniger Vorgänge als die speziell in 6 beschriebenen beinhalten,
Jeder der Schritte des Verfahrens 600 kann durch jede geeignete Komponente der Betriebsumgebung durchgeführt werden. Zum Beispiel kann das Verfahren 600 in einer Ausführungsform ganz oder teilweise durch ein physisches Netzwerkelement (wie beispielsweise einen Switch, einen Router, ein Gateway usw.), einen Prozessor (wie beispielsweise eine CPU, einen ASIC, ein FPGA usw.) in vielfältigen Ansätzen durchgeführt werden.
Wie in 6 gezeigt, kann das Verfahren 600 mit einem Vorgang 602 beginnen, bei dem ein Overlay-Paket über einen Tunnel von einem virtuellen Switch auf einem Hostserver empfangen wird.
In Vorgang 604 wird das Overlay-Paket entkapselt, um ein inneres Paket und mandantenspezifische Informationen zu erhalten. Damit die Entkapselung stattfinden kann, muss es sich bei dem Paket natürlich zuerst um ein Overlay-Paket handeln, und daher kann festgestellt werden, dass es sich um ein Overlay-Paket handelt. Dies wird durch Ermitteln eines Zielports des äußeren UDP-Headers erreicht. Wenn es sich bei dem Zielport um einen virtuellen LAN-Port, wie beispielsweise einen VXLAN-Port handelt, kann davon ausgegangen werden, dass das Paket einen Tunnel-Header enthält.
Das innere Paket kann von jedem beliebigen im Stand der Technik bekannten Typ sein, wie beispielsweise E/A-Pakete (z. B. Fibre-Channel-over-Ethernet(FCoE)-Pakete), Steuerpakete, IP-Pakete, Sprachpakete usw.
In Vorgang 606 werden eine Quelle und ein Ziel des inneren Pakets ermittelt. Diese Informationen können verwendet werden, um zu ermitteln, ob es angemessen ist, das Paket zu seinem beabsichtigten Ziel weiterzuleiten, sowie zu ermitteln, welche Dienste gegebenenfalls am inneren Paket durchzuführen sind.
In Vorgang 608 werden Inspizierungsdienste am inneren Paket durchgeführt, wie anhand der in den Headern des Overlay-Pakets enthaltenen mandantenspezifischen Informationen, dem Ziel, der Quelle und jeder beliebigen anderen, im inneren Paket oder den Tunnel-Headern enthaltenen nützlichen Information ermittelt wurde.
In Vorgang 610 wird ermittelt, ob das innere Paket an sein beabsichtigtes Ziel weitergeleitet werden sollte. Wenn das Paket zum Beispiel von Mandant A gesendet wird und für Mandant B bestimmt ist und keine gemeinsame Nutzung unter diesen Mandanten stattfindet, sollte das Paket nicht weitergeleitet werden. Wenn in einem anderen Beispiel das Ziel einen Mandanten mit der Quelle teilt, kann das Paket an sein Ziel gesendet werden. Natürlich kann es viele andere mögliche Szenarien geben, und die hierin beschriebenen Ausführungsformen sind nicht als nur auf mandantenspezifische Weiterleitungsentscheidungen beschränkt gedacht.
Falls in Vorgang 610 ermittelt wird, das innere Paket an das Ziel weiterzuleiten, wird das innere Paket in Vorgang 614 wieder in ein Overlay-Paket gekapselt, bei dem es sich um dasselbe Overlay-Paket handeln kann, in dem das innere Paket empfangen wurde. Dann wird in Vorgang 616 das Overlay-Paket an den virtuellen Switch auf dem Hostserver weitergeleitet, um voraussichtlich an sein beabsichtigtes Ziel weitergeleitet zu werden.
Gemäß mancher weiterer Ausführungsformen können die mandantenspezifischen Informationen eine virtuelle Netzwerkkennung (virtual network identifier (VNID)) enthalten, zumindest ein Teil der mandantenspezifischen Informationen kann in einem UDP-Header enthalten sein, zumindest ein Teil der mandantenspezifischen Informationen kann in einem Rahmen des Tunnel-Headers enthalten sein, der gestaltet ist, die mandantenspezifischen Informationen zu speichern, und/oder das Overlay-Netzwerk kann VXLAN entsprechen.
Das Verfahren 600 kann in vielfältigen Ausführungsformen, die alle oder einige der in 6 beschriebenen Vorgänge enthalten, in Computerprogrammprodukten, anderen Verfahren, Logik und/oder Systemen durchgeführt werden.
Gemäß einer solchen Ausführungsform kann ein System Logik enthalten, die zum Empfangen eines Overlay-Pakets von einem virtuellen Switch über einen Tunnel eingerichtet ist, Logik, die zum Entkapseln des Overlay-Pakets durch Entfernen eines Tunnel-Headers eingerichtet ist, um ein inneres Paket zu erhalten, Logik, die zum Ermitteln einer Quelle und eines Ziels des inneren Pakets eingerichtet ist, Logik, die zum Durchführen von Inspizierungsdiensten am inneren Paket auf der Grundlage von im Overlay-Paket enthaltenen mandantenspezifischen Informationen eingerichtet ist, Logik, die eingerichtet ist, zu ermitteln, ob das innere Paket an das Ziel zu senden ist, Logik, die eingerichtet ist, im Falle, dass das Ermitteln ergibt, das innere Paket an das Ziel zu senden, das innere Paket wieder in den Tunnel-Header zu kapseln, um ein Overlay-Paket zu bilden und das Overlay-Paket über den Tunnel an den virtuellen Switch zu senden, und Logik, die eingerichtet ist, das Paket im Falle, dass das Ermitteln ergibt, das Paket nicht an das Ziel zu senden, fallen zu lassen. Der Tunnel-Header kann mandantenspezifische Informationen enthalten.
Unter Bezugnahme auf 7 ist nun ein Ablaufplan eines Verfahrens 700 gemäß einer Ausführungsform gezeigt. Das Verfahren 700 kann gemäß der vorliegenden Erfindung in vielfältigen Ausführungsformen unter anderem in jeder der in 1 bis 5 abgebildeten Umgebungen durchgeführt werden. Wie der Fachmann beim Lesen der vorliegenden Beschreibungen erkennt, kann das Verfahren 700 natürlich mehr oder weniger Operationen als die speziell in 7 beschriebenen beinhalten,
Jeder der Schritte des Verfahrens 700 kann durch jede geeignete Komponente der Betriebsumgebung durchgeführt werden. Zum Beispiel kann das Verfahren 700 in einer Ausführungsform ganz oder teilweise durch einen virtuellen Switch auf einem Hostserver, einen Prozessor (wie beispielsweise eine CPU, einen ASIC, ein FPGA usw.) in vielfältigen Ansätzen durchgeführt werden.
Wie in 7 gezeigt, kann das Verfahren 700 mit einem Vorgang 702 beginnen, bei dem ein Overlay-Paket über einen Tunnel von einer ersten VM auf einem Hostserver empfangen wird. In einem Ansatz wird das Paket durch einen virtuellen Switch auf dem Hostserver empfangen.
Das Paket kann von jedem beliebigen im Stand der Technik bekannten Typ sein, wie beispielsweise E/A-Pakete (z. B. Fibre-Channel-over-Ethernet(FCoE)-Pakete), Steuerpakete, IP-Pakete, Sprachpakete usw.
In Vorgang 704 wird festgestellt, dass sich ein Ziel des Pakets auf einer dem Hostserver gemeinsamen zweiten VM befindet, z. B. kann es an die zweite VM weitergeleitet werden, ohne an beliebige physische Netzwerkelemente gesendet zu werden.
In einem optionalen Vorgang 706 wird festgestellt, dass Inspizierungsdienste am Paket durchzuführen sind, beispielsweise aufgrund einer Zieladresse, eines Pakettyps, einer Paketgröße oder eines beliebigen anderen im Stand der Technik bekannten Kriteriums. In diesem Fall kann festgestellt werden, dass VEPA verwendet werden sollte, um diese Dienste durch ein physisches Netzwerkelement durchführen zu lassen.
In Vorgang 708 wird das Paket in einem Ansatz mit einem Tunnel-Header gekapselt, um ein Overlay-Paket zu bilden, wie in 5A bis 5B detaillierter beschrieben.
In Vorgang 710 wird das Overlay-Paket über einen Tunnel an das physische Netzwerkelement gesendet, um daran Inspizierungsdienste durchführen zu lassen. Welche Dienste durchzuführen sind, kann festgelegt sein, oder das physische Netzwerkelement kann diese Entscheidung treffen.
Voraussichtlich führt das physische Netzwerkelement Inspizierungsdienste am inneren Paket durch, was aufgrund der in den Headern des Overlay-Pakets enthaltenen mandantenspezifischen Informationen, des Ziels, der Quelle und jeder beliebigen anderen nützlichen, im Paket oder dem Tunnel-Header enthaltenen Information ermittelt wird.
In Vorgang 712 wird das Overlay-Paket vom physischen Netzwerkelement zurückerhalten und entkapselt, um in Vorgang 714 ein bearbeitetes Paket zu erhalten. Dann wird das bearbeitet Paket in Vorgang 716 an die zweite VM weitergeleitet.
Das Verfahren 700 kann in vielfältigen Ausführungsformen, die alle oder einige der in 7 beschriebenen Vorgänge enthalten, in Computerprogrammprodukten, anderen Verfahren, Logik und/oder Systemen durchgeführt werden.
In einer solchen Ausführungsform weist ein Computerprogrammprodukt zum Ermöglichen von VEPA in einem Overlay-Netzwerk ein computerlesbares Speichermedium mit darauf ausgebildetem computerlesbarem Programmcode auf. Der computerlesbare Programmcode weist computerlesbaren Programmcode auf, der für ein Empfangen eines Pakets von einer ersten VM auf einem Hostserver konfiguriert ist, computerlesbaren Programmcode, der konfiguriert ist, festzustellen, dass es sich bei einem Ziel des Pakets um eine dem Hostserver gemeinsame zweite VM handelt, computerlesbaren Programmcode, der für ein Kapseln des Pakets mit einem Tunnel-Header konfiguriert ist, um ein Overlay-Paket zu bilden, computerlesbaren Programmcode, der für ein Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement konfiguriert ist, um daran Inspizierungsdienste durchführen zu lassen, computerlesbaren Programmcode, der für ein Empfangen des Overlay-Paketes vom physischen Netzwerkelement konfiguriert ist, computerlesbaren Programmcode, der für ein Entkapseln des Overlay-Pakets konfiguriert ist, um ein bearbeitetes Paket zu erhalten, und computerlesbaren Programmcode, der für ein Weiterleiten des bearbeiteten Pakets an die zweite VM konfiguriert ist, wobei der Tunnel-Header mandantenspezifische Informationen aufweist.
In manchen weiteren Ausführungsformen, können die mandantenspezifischen Informationen eine VNID oder andere geeignete, den Mandanten kennzeichnende Informationen enthalten, zumindest ein Teil der mandantenspezifischen Informationen ist in einem UDP-Header enthalten, zumindest ein Teil der mandantenspezifischen Informationen ist in einem Rahmen des Tunnel-Headers enthalten, der gestaltet ist, die mandantenspezifischen Informationen zu speichern, und/oder das Overlay-Netzwerk entspricht VXLAN.
Während vorstehend verschiedene Ausführungsformen beschrieben wurden, versteht es sich, dass sie in lediglich beispielhafter und nicht einschränkender Weise vorgelegt wurden. Somit sollten die Breite und der Umfang einer Ausführungsform der vorliegenden Erfindung nicht durch irgendwelche der vorstehend beschriebenen beispielhaften Ausführungsformen eingeschränkt, sondern nur gemäß den nachfolgenden Ansprüchen und deren Äquivalente definiert sein.

Claims

System, aufweisend: einen Hostserver, der einen virtuellen Switch bereitstellt, wobei der virtuelle Switch aufweist: Logik, die zum Empfangen eines Pakets von einer ersten virtuellen Maschine (VM) auf dem Hostserver eingerichtet ist; Logik, die eingerichtet ist, festzustellen, dass es sich bei einem Ziel des Paketes um eine dem Hostserver gemeinsame zweite VM handelt; Logik, die zum Kapseln des Pakets mit einem Tunnel-Header eingerichtet ist, um ein Overlay-Paket zu bilden; Logik, die eingerichtet ist, das Overlay-Paket über einen Tunnel an ein physisches Netzwerkelement zu senden, um daran Inspizierungsdienste durchführen zu lassen; Logik, die zum Empfangen des Overlay-Pakets vom physischen Netzwerkelement eingerichtet ist; Logik, die zum Entkapseln des Overlay-Pakets eingerichtet ist, um ein bearbeitetes Paket zu erhalten; und Logik, die zum Weiterleiten des bearbeiteten Pakets an die zweite VM eingerichtet ist, wobei der Tunnel-Header mandantenspezifische Informationen aufweist.
System wie in Anspruch 1 ausgeführt, weiterhin aufweisend ein physisches Netzwerkelement, wobei das physische Netzwerkelement aufweist: Logik, die zum Empfangen des Overlay-Pakets durch das physische Netzwerkelement eingerichtet ist; Logik, die zum Entkapseln des Overlay-Pakets eingerichtet ist, um das Paket zu erhalten; und Logik die zum Ermitteln einer Quelle und eines Ziels des Pakets eingerichtet ist; Logik die eingerichtet ist, Inspizierungsdienste am Paket auf der Grundlage der im Overlay-Paket enthaltenen mandantenspezifischen Informationen durchzuführen; Logik die eingerichtet ist, zu ermitteln, ob das Paket an das Ziel zu senden ist; Logik, die eingerichtet ist, das Paket im Falle, dass die Ermittlung ergibt, das Paket an das Ziel zu senden, wieder in den Tunnel-Header einzukapseln, um das Overlay-Paket zu bilden und das Overlay-Paket über den Tunnel an den virtuellen Switch auf dem Hostserver zu senden; und Logik die eingerichtet ist, das Paket im Falle, dass die Ermittlung ergibt, das Paket nicht an das Ziel zu senden, fallenzulassen.
System wie in Anspruch 1 ausgeführt, wobei die mandantenspezifischen Informationen eine virtuelle Netzwerkkennung (virtual network identifier (VNID)) enthalten.
System wie in Anspruch 1 ausgeführt, wobei zumindest ein Teil der mandantenspezifischen Informationen in einem Benutzer-Datagramm-Protokoll(user datagram protocol (UDP))-Header enthalten ist.
System wie in Anspruch 1 ausgeführt, wobei zumindest ein Teil der mandantenspezifischen Informationen in einem Rahmen des Tunnel-Headers enthalten ist, der gestaltet ist, die mandantenspezifischen Informationen zu speichern.
System wie in Anspruch 1 ausgeführt, wobei das Overlay-Netzwerk dem Virtual eXtensible Local Area Network (VXLAN) entspricht.
Verfahren zum Ermöglichen der Aggregation virtueller Ethernet-Ports (Virtual Ethernet Port Aggregation (VEPA)) in einem Overlay-Netzwerk, wobei das Verfahren aufweist: Empfangen eines Pakets von einer ersten virtuellen Maschine (VM) auf einem Hostserver; Feststellen, dass es sich bei einem Ziel des Paketes um eine dem Hostserver gemeinsame zweite VM handelt; Kapseln des Pakets mit einem Tunnel-Header, um ein Overlay-Paket zu bilden; Senden des Overlay-Pakets über einen Tunnel an ein physisches Netzwerkelement, um daran Inspizierungsdienste durchführen zu lassen; Empfangen des Overlay-Pakets vom physischen Netzwerkelement; Entkapseln des Overlay-Pakets, um ein bearbeitetes Paket zu erhalten; und Weiterleiten des bearbeiteten Pakets an die zweite VM, wobei der Tunnel-Header mandantenspezifische Informationen aufweist.
Computerprogrammprodukt zum Ermöglichen der Aggregation virtueller Ethernet-Ports (Virtual Ethernet Port Aggregation (VEPA)) in einem Overlay-Netzwerk, wobei das Computerprogrammprodukt ein computerlesbares Speichermedium mit darauf ausgebildetem computerlesbarem Programmcode aufweist, wobei der computerlesbare Programmcode aufweist: computerlesbaren Programmcode, der für ein Empfangen eines Pakets von einer ersten virtuellen Maschine (VM) auf einem Hostserver konfiguriert ist; computerlesbaren Programmcode, der konfiguriert ist, festzustellen, dass es sich bei einem Ziel des Paketes um eine dem Hostserver gemeinsame zweite VM handelt; computerlesbaren Programmcode, der für ein Kapseln des Pakets mit einem Tunnel-Header konfiguriert ist, um ein Onerlay-Paket zu bilden; computerlesbaren Programmcode, der konfiguriert ist, das Overlay-Paket über einen Tunnel an ein physisches Netzwerkelement zu senden, um daran Inspizierungsdienste durchführen zu lassen; computerlesbaren Programmcode, der für ein Empfangen des Overlay-Pakets vom physischen Netzwerkelement konfiguriert ist; computerlesbaren Programmcode, der für ein Entkapseln des Overlay-Pakets konfiguriert ist, um ein bearbeitetes Paket zu erhalten; und computerlesbaren Programmcode, der für ein Weiterleiten des bearbeiteten Pakets an die zweite VM konfiguriert ist; wobei der Tunnel-Header mandantenspezifische Informationen aufweist.
System, aufweisend: Logik, die zum Empfangen eines Overlay-Pakets von einem virtuellen Switch über einen Tunnel eingerichtet ist; Logik, die zum Entkapseln des Overlay-Pakets durch Entfernen eines Tunnel-Headers eingerichtet ist, um ein inneres Paket zu erhalten; Logik die zum Ermitteln einer Quelle und eines Ziels des inneren Pakets eingerichtet ist; Logik die eingerichtet ist, Inspizierungsdienste am inneren Paket auf der Grundlage von im Overlay-Paket enthaltenen mandantenspezifischen Informationen durchzuführen; Logik die eingerichtet ist, zu ermitteln, ob das innere Paket an das Ziel zu senden ist; Logik, die eingerichtet ist, das innere Paket im Falle, dass die Ermittlung ergibt, das innere Paket an das Ziel zu senden, wieder in den Tunnel-Header einzukapseln, um das Overlay-Paket zu bilden, und das Overlay-Paket über den Tunnel an den virtuellen Switch zu senden; und Logik die eingerichtet ist, das Paket im Falle, dass die Ermittlung ergibt, das Paket nicht an das Ziel zu senden, fallenzulassen, wobei der Tunnel-Header mandantenspezifische Informationen aufweist.