-
HINTERGRUND
-
Einige Informationstechnologieabteilungen in Unternehmen haben damit begonnen, ihre Computerinfrastruktur so weit wie möglich durch Software zu definieren. Typischerweise stützt sich diese softwaredefinierte Infrastruktur manchmal auf eine hyperkonvergente Infrastruktur (HCl), bei der verschiedene Funktionskomponenten in ein einziges Gerät integriert sind. Ein Aspekt einer HCl besteht darin, dass Hardwarekomponenten in softwaredefinierte und logisch isolierte Repräsentationen von Datenverarbeitung, Speicherung und Netzwerken für eine Computer-Hardware-Infrastruktur virtualisiert werden können. HCl und die Virtualisierung von Hardwareressourcen können eine flexible Zuweisung von Computerressourcen ermöglichen. So können beispielsweise Konfigurationsänderungen an der Infrastruktur vorgenommen werden, und die zugrundeliegende Hardware passt sich einfach an eine neue, durch Software implementierte Konfiguration an. HCl kann von einigen Unternehmen auch dazu verwendet werden, einen virtualisierten Computer zu implementieren, indem die Spezifikation der Fähigkeiten des Computers vollständig in Software definiert wird. Jeder virtualisierte Computer (z. B. durch Software definiert) kann dann einen Teil eines oder mehrerer physischer Computer (z. B. die zugrunde liegende Hardware) nutzen. Ein anerkanntes Ergebnis der Virtualisierung ist, dass physische Rechen-, Speicher- und Netzwerkkapazitäten innerhalb einer Organisation effizienter genutzt werden können.
-
NVM Express (NVMe) ist ein Datenübertragungsprotokoll, das typischerweise für die Kommunikation mit Solid-State-Laufwerken (SSDs) über einen Peripheral Component Interconnect Express (PCle) Kommunikationsbus verwendet wird. Es gibt viele verschiedene Arten von Datentransportprotokollen, die für unterschiedliche Zwecke in Computersystemen verwendet werden. Jedes Transportprotokoll kann unterschiedliche Eigenschaften in Bezug auf Geschwindigkeit und Leistung aufweisen, weshalb jedes Protokoll für unterschiedliche Zwecke geeignet sein kann. NVMe ist ein Beispiel für ein Datenprotokoll, das für die Hochgeschwindigkeitsdatenübertragung zwischen einem Host-Computersystem und einem SSD verwendet werden kann. NVMe wird in der Regel in Computern verwendet, die hochleistungsfähige Lese- und Schreibvorgänge auf einem SSD wünschen. Die Verwendung eines NVMe-basierten Speichers, der hochleistungsfähige Lese- und Schreibvorgänge innerhalb einer softwaredefinierten Infrastruktur unter weiterer Verwendung von HCI-Hardware unterstützt, kann eine nützliche und anpassbare Konfiguration für Infrastrukturnetzwerke darstellen.
-
Im Jahr 2014 wurde eine Spezifikation für den Betrieb von NVMe über Fabrics (NVMe-oF) gestartet. Ein Ziel dieser Spezifikation war die Erweiterung von NVMe auf Fabrics wie Ethernet, Fibre Channel und InfiniBand oder jede andere geeignete Storage-Fabric-Technologie. Der Zugriff auf SSD-Laufwerke über Netzwerk-Fabrics via NVMe-oF kann eine Skalierung der softwaredefinierten Speicherkapazität (z. B. Teile einer größeren Hardware-Speicherkapazität) für den Zugriff ermöglichen. Diese Skalierung für den Zugriff kann: a) den Zugriff auf eine große Anzahl von NVMe-Geräten ermöglichen; und b) die physische Entfernung zwischen Geräten (z. B. innerhalb eines Rechenzentrums) vergrößern. Die Skalierung kann zunehmende Entfernungen umfassen, über die NVMe-Speichergeräte von einem anderen Computergerät abgerufen werden. Speicherprotokolle sind in der Regel verlustfreie Protokolle, da die Ziele der Speicherung in der Natur der Sache liegen. Wenn ein für die Speicherung verwendetes Protokoll verlustbehaftet ist (verlustbehaftet ist das Gegenteil von verlustfrei), wird die ordnungsgemäße Speicherung von Daten wahrscheinlich eine inakzeptable Langsamkeit aufweisen (z. B. aufgrund von Wiederholungsversuchen bei der Paketübertragung) oder, was noch schlimmer ist, eine Beschädigung (z. B. Datenungenauigkeiten) aufweisen und daher in einer realen Computerumgebung nicht verwendbar sein. Der NVMe-oF-Verkehr auf der Netzwerkstruktur ist daher verlustfrei implementiert. NVMe-oF-Netzwerkpakete können in einem Netzwerk zusammen mit anderem Verkehr übertragen werden. Daher kann der NVMe-oF-Verkehr auf zwischengeschalteten Geräten (z. B. Netzwerk-Switches, die die Netzwerkstruktur zwischen Host-Gerät und Speichergerät bereitstellen) auf demselben physikalischen Transportmedium (z. B. optisches oder elektronisches Kabel) wie andere Datentypen übertragen werden.
-
Figurenliste
-
Die vorliegende Offenbarung wird durch die folgende detaillierte Beschreibung besser verständlich, wenn sie zusammen mit den beigefügten Abbildungen gelesen wird. Es wird betont, dass die verschiedenen Merkmale gemäß der üblichen Praxis in der Industrie nicht maßstabsgetreu gezeichnet sind. Vielmehr können die Abmessungen oder Positionen von Funktionsmerkmalen aufgrund von Design, Sicherheit, Leistung oder anderen im Bereich der Computersysteme bekannten Faktoren verschoben oder kombiniert werden. Darüber hinaus kann die Reihenfolge der Verarbeitung für einige Funktionen sowohl intern als auch im Verhältnis zueinander geändert werden. Das heißt, einige Funktionen können nicht mit serieller Verarbeitung implementiert werden und daher können die Funktionen in einer anderen Reihenfolge als dargestellt oder möglicherweise parallel zueinander ausgeführt werden. Für eine detaillierte Beschreibung verschiedener Beispiele wird nun auf die beigefügten Zeichnungen verwiesen, in denen:
- 1 ist ein funktionales Blockdiagramm, das ein Beispiel für ein Netzwerkinfrastrukturgerät, wie z. B. einen Switch/Router, gemäß einer oder mehrerer offengelegter Implementierungen darstellt;
- 2A ist ein funktionales Blockdiagramm, das ein Beispiel für einen hochverfügbaren Switch gemäß einer oder mehrerer offengelegter Implementierungen darstellt;
- 2B ist ein funktionales Blockdiagramm, das ein Beispiel für einen hochverfügbaren Switch darstellt, der eine SSD enthält, die in den hochverfügbaren Switch als Beispiel für einen erweiterten speicherfähigen Switch integriert ist, gemäß einer oder mehreren offengelegten Implementierungen;
- 3A ist ein Blockdiagramm, das ein Beispiel für die Weiterleitung von Netzwerkpaketen unter Verwendung eines zwischengeschalteten Netzwerkinfrastrukturgeräts (oder einer Komponente eines Geräts) gemäß einer oder mehrerer offengelegter Implementierungen darstellt;
- 3B ist ein Blockdiagramm, das ein Beispiel für einen internen Warteschlangen-Routing-Mechanismus darstellt, der von einem zwischengeschalteten Netzinfrastrukturgerät (oder einer Komponente eines Geräts) gemäß einer oder mehreren offengelegten Implementierungen verwendet werden kann;
- 4 ist ein Blockdiagramm, das eine Beispielansicht auf hoher Ebene von Aktionen darstellt, die bei der Implementierung der automatischen NVMe-oF-Netzwerkpaketerkennung, Priorisierung und Weiterleitung gemäß einer oder mehrerer offengelegter Implementierungen durchgeführt werden können;
- 5 ist ein beispielhaftes Prozessflussdiagramm, das ein beispielhaftes Verfahren zur automatischen Identifizierung und Weiterleitung von NVMe-oF-Netzwerkpaketen gemäß einer oder mehrerer offengelegter Implementierungen darstellt;
- 6 ist ein Beispiel für ein Computergerät mit einem Hardware-Prozessor und zugänglichen maschinenlesbaren Anweisungen, die auf einem maschinenlesbaren Medium gespeichert sind, das verwendet werden kann, um das Beispielverfahren von 5 gemäß einer oder mehreren offengelegten Implementierungen zu implementieren;
- 7 stellt eine Computernetzwerkinfrastruktur dar, die verwendet werden kann, um die gesamte oder einen Teil der offengelegten automatischen NVMe-oF-Netzwerkpaketerfassung und -weiterleitung für ein Netzwerkgerät gemäß einer oder mehrerer offengelegter Implementierungen zu implementieren; und
- 8 zeigt ein Computerverarbeitungsgerät, das zur Implementierung der Funktionen, Module, Verarbeitungsplattformen, Ausführungsplattformen, Kommunikationsgeräte und anderer Methoden und Prozesse dieser Offenbarung verwendet werden kann.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Illustrative Beispiele für den unten beanspruchten Gegenstand werden nun offengelegt. Im Interesse der Klarheit werden nicht alle Merkmale einer tatsächlichen Implementierung für jede Beispielimplementierung in dieser Spezifikation beschrieben. Es wird deutlich, dass bei der Entwicklung eines solchen konkreten Beispiels zahlreiche implementierungsspezifische Entscheidungen getroffen werden können, um die spezifischen Ziele des Entwicklers zu erreichen, wie z. B. die Einhaltung systembezogener und geschäftsbezogener Beschränkungen, die von einer Implementierung zur anderen variieren werden. Darüber hinaus wird anerkannt, dass ein solcher Entwicklungsaufwand, auch wenn er komplex und zeitaufwendig ist, für Fachleute, die über die Vorteile dieser Offenbarung verfügen, ein Routineunternehmen ist.
-
Ein Computernetz kann aus vielen Geräten bestehen, die untereinander kommunizieren können. Zur Unterstützung dieser Kommunikation kann auch eine Vielzahl von Netzwerkinfrastrukturgeräten wie Switches und Router an das Netz angeschlossen sein. Netzwerkinfrastrukturgeräte können die Netzwerkkommunikation unterstützen, indem sie Netzwerkpakete abfangen und umleiten, um die Kommunikation zwischen den Geräten praktisch nahtlos zu gestalten. Diese Netzwerkinfrastrukturgeräte können komplexe Aufgaben übernehmen, um die nahtlose Kommunikation zwischen den Geräten zu ermöglichen. Einige Netzwerkinfrastrukturgeräte können beispielsweise Netzwerkpakete für eine kurze Zeit im Speicher ablegen. Diese vorübergehende Speicherung von Netzwerkpaketen kann notwendig sein, wenn beispielsweise der Sender der Netzwerkpakete die Pakete schneller sendet, als der Empfänger der Netzwerkpakete die Pakete empfangen kann. Andere Implementierungen können eine Überbelegung oder Überzuteilung von Netzwerkbandbreite verwenden, um eine mögliche Überlastung im Wesentlichen zu beseitigen. So kann beispielsweise einem Datenkommunikationsfluss, bei dem eine Spitzenauslastung von 1 MB/s erwartet wird, eine Bandbreite von 5 MB/s zugewiesen werden. Eine kumulative Wirkung von Überzuteilung und Überbelegung kann im Hinblick auf die „verschwendete“ Bandbreite als ineffizient angesehen werden.
-
Netzwerkinfrastrukturgeräte können mehrere Techniken für die vorübergehende Speicherung von Netzwerkpaketen zur weiteren Verarbeitung verwenden. Eine gängige Technik ist die Verwendung des Konzepts einer Warteschlange zur Speicherung von Netzwerkpaketen. Eine Warteschlange kann es ermöglichen, Netzwerkpakete in der Reihenfolge ihres Eintreffens zu speichern und zu übertragen, indem eine einfache FIFO-Reihenfolge (first-in, first-out) eingehalten wird. Das Netzwerkinfrastrukturgerät kann über eine begrenzte Speicherkapazität für Netzwerkpakete verfügen und einige Netzwerkpakete verwerfen, die nicht vor Ablauf einer angemessenen Zeitspanne an den Empfänger übermittelt werden können (so genannte „dropping packets“). Viele Netzwerkprotokolle sind resistent gegenüber verlorenen Netzwerkpaketen und können den Absender einfach auffordern, verlorene Netzwerkpakete erneut zu übertragen.
-
Einige Netzwerkprotokolle können jedoch als „verlustfreie“ Protokolle betrachtet werden, die mit Paketverlusten nicht gut umgehen können. Das heißt, verlustfreie Protokolle sind nicht dafür ausgelegt, verworfene Pakete zu berücksichtigen, zum Teil, weil diese Protokolle erwarten, dass alle Pakete in der richtigen Reihenfolge ankommen. Protokolle, die für Schnittstellen zu Speichergeräten (z. B. SSDs) verwendet werden, sind in der Regel verlustfreie Protokolle. NVMe kann ein Protokoll sein, das für verlustfreie Protokollimplementierungen in Frage kommt, und wird in der Regel mit einem zugrunde liegenden verlustfreien Transport implementiert. In Fällen, in denen verlustfreie Protokolle verwendet werden, kann das Netzwerkinfrastrukturgerät so konfiguriert werden, dass es den Netzwerkverkehr auf eine Weise verarbeitet, die sicherstellt, dass alle Pakete erfolgreich zugestellt werden, indem das Konzept einer verlustfreien Warteschlange verwendet wird. Eine verlustfreie Warteschlange kann wie jede andere Warteschlange der gleichen FIFO-Reihenfolge für die Zustellung von Netzwerkpaketen folgen wie eine normale Warteschlange. Eine verlustfreie Warteschlange darf jedoch Netzwerkpakete nicht verwerfen, bevor sie an einen Empfänger zugestellt wurden. In einigen Implementierungen kann der Sender angewiesen werden, die Übertragung von Paketen an eine überlastete Warteschlange zu verlangsamen oder zu stoppen (z. B. für eine gewisse Zeit, bis die Übertragungen mit voller Geschwindigkeit wieder aufgenommen werden können). Die Netzinfrastruktureinrichtung, die nur über eine begrenzte Menge an Speicherplatz zum Speichern von Netzwerkpaketen verfügt, kann den Absender anweisen, eine kurze Pause einzulegen, bis die verlustfreie Warteschlange in der Lage ist, einige der gespeicherten Netzwerkpakete zu verarbeiten und zu löschen.
-
Der NVMe-oF-Verkehr auf der Netzwerkstruktur ist verlustfrei implementiert, da Lese- und Schreibvorgänge, die nicht verlustfrei sind, wahrscheinlich zu einer Verlangsamung der Übertragung oder sogar zu Datenbeschädigungen führen. Ein Benutzer eines beliebigen Computers kann verstehen, dass das Lesen und Schreiben von Daten auf einem Computerlaufwerk oder einem anderen Speichergerät zu einer erfolgreichen Verarbeitung aller Lese- und Schreibvorgänge führen sollte. Ein Student würde beispielsweise kaum akzeptieren, dass die Übertragung einer Kopie seiner Hausarbeit sehr lange dauert oder, noch schlimmer, dass in seiner Hausarbeit Seiten oder Aktualisierungen fehlen, wenn Vorgänge zum Speichern der Daten auf einem Speichergerät verworfen werden, weil Schreibvorgänge als optional angesehen werden.
-
NVMe-oF-Netzwerkpakete zur Durchführung von Lese- und Schreibvorgängen können an Netzwerkinfrastrukturgeräte wie Netzwerk-Switches oder Router weitergeleitet werden, die in der Lage sind, den NVMe-oF-Verkehr ohne Verlust von NVMe-oF-Netzwerkpaketen zu verarbeiten. Netzwerkinfrastrukturgeräte können verlustfreie Port-Warteschlangen mit Methoden wie dem Priority Flow Control (RFC) Standard 802.1 Qbb unterstützen. Die Verwendung verlustfreier Warteschlangen in einem Netzwerkgerät kann kompliziert sein, da ein einzelnes Netzwerkgerät sowohl verlustfreie als auch verlustbehaftete Protokolle gleichzeitig verarbeiten kann. Um dieser Komplikation und anderen Problemen zu begegnen, stellen die offengelegten Techniken eine Verbesserung der Funktionsweise von Computergeräten dar, wobei beispielsweise ein Netzwerk-Switch NVMe-oF-Netzwerkpakete von Nicht-NVMe-oF-Netzwerkpaketen trennen und eine höhere Verarbeitungsstufe (z. B. höhere Priorität und verlustfrei) für NVMe-oF-Pakete im Vergleich zu Nicht-NVMe-oF-Paketen bereitstellen kann. Nicht-NVMe-oF-Netzwerkpakete können im Gegensatz zu NVMe-oF-Netzwerkpaketen Netzwerkdatenströme bilden, die widerstandsfähiger gegenüber Netzwerkpaketverlusten sind und daher keine verlustfreie Warteschlange verwenden. Eine verlustfreie Warteschlange ist in diesem Zusammenhang ein temporärer Speicherort, an dem Netzwerkpakete gespeichert werden können, bis sie an einen Empfänger übertragen werden und die Übertragung bestätigt wird. Eine verlustfreie Warteschlange kann mehr Rechenleistung oder Speicherressourcen für den Betrieb in einem Netzinfrastrukturgerät nutzen, das über eine begrenzte Menge an Rechen- und Speicherressourcen verfügen kann. Die Verwendung einer verlustfreien Warteschlange für alle Netzwerkpakete in einem Netzwerkinfrastrukturgerät, das möglicherweise nur über begrenzte Rechenressourcen verfügt, kann nicht praktikabel sein.
-
Einige Verfahren zur Trennung von NVMe-oF-Netzwerkpaketen von Nicht-NVMe-oF-Netzwerkpaketen können von einer Netzwerkinfrastrukturvorrichtung implementiert werden, die so konfiguriert ist, dass NVMe-oF-Netzwerkpakete verlustfrei verarbeitet werden können. Eine Methode zur Trennung von NVMe-oF-Netzwerkpaketen von Nicht-NVMe-oF-Netzwerkpaketen kann darin bestehen, die Netzwerkinfrastruktureinrichtung so zu konfigurieren, dass Netzwerkpakete, die von bestimmten Internetprotokoll (IP)-Adressen stammen, als NVMe-oF-Pakete erkannt werden (auch wenn sie in Wirklichkeit nicht NVMe-oF sind). Netzwerkpakete von einer IP-Adresse, die als Quelle von NVMe-oF-Netzwerkpaketen definiert ist, können dann an verlustfreie Warteschlangen weitergeleitet werden, während Nicht-NVMe-oF-Netzwerkpakete (von anderen IP-Adressen) an andere Warteschlangen weitergeleitet werden können, die keine verlustfreie Behandlung benötigen. Wenn neue Quellen von NVMe-oF-Netzwerkpaketen zum Netzwerk hinzugefügt oder bestehende Quellen von NVMe-oF-Netzwerkpaketen entfernt werden, kann das Netzwerkinfrastrukturgerät aktualisiert werden (möglicherweise eine manuelle Aktualisierung), um (auf der Grundlage der IP-Adressdefinition) Netzwerkpakete zu erkennen, die von der neuen oder aktualisierten IP-Adresse stammen. Bei einem groß angelegten Einsatz von NVMe-Geräten, auf die über NVMe-oF über eine Netzwerkstruktur zugegriffen werden soll, kann es unerwünscht sein, dass die Konfiguration eines Netzwerkinfrastrukturgeräts als Reaktion auf Netzwerkänderungen ständig aktualisiert werden muss. Darüber hinaus können einige Pakete, die nicht NVMe-oF sind, der übergeordneten Verarbeitung unterzogen werden, auch wenn sie eigentlich keine NVMe-oF-Protokollpakete sind. Das heißt, dass Definitionen von Konfigurationen, die nur auf IP-Adressen basieren, möglicherweise nicht zu einer genauen Identifizierung von Netzwerkpaketprotokollen führen.
-
Diese Offenlegung beschreibt eine Verbesserung gegenüber den zuvor bereitgestellten Methoden, die von IP-Adressen und entsprechenden häufigen (manchmal manuellen) Konfigurationsänderungen des Netzwerkinfrastrukturgeräts abhängig sein können. Gemäß den offengelegten Implementierungen können NVMe-oF-Netzwerkpakete automatisch von Nicht-NVMe-oF-Netzwerkpaketen durch ein Netzwerkinfrastrukturgerät unterschieden werden, das Schlüsselteile von NVMe-oF-Netzwerkpaketen erkennen kann, die in Nicht-NVMe-oF-Netzwerkpaketen nicht vorhanden sind. Diese Schlüsselteile können als eine „Signatur“ eines NVMe-oF-Pakets betrachtet werden. Die Fähigkeit, Netzwerkpakete als NVMe-oF-Netzwerkpakete zu erkennen, kann die ständige Neukonfiguration von Netzwerkinfrastrukturgeräten reduzieren oder überflüssig machen, wenn sich die Anzahl der mit der Netzwerkstruktur verbundenen NVMe-Geräte ändert. Darüber hinaus kann das Netzwerkinfrastrukturgerät in derselben oder in einer zusätzlichen offengelegten Implementierung so konfiguriert sein, dass es automatisch identifizierte NVMe-oF-Netzwerkpakete an eine oder mehrere verlustfreie Warteschlangen weiterleitet, zusätzlich zur automatischen Erkennung von NVMe-oF-Netzwerkpaketen anhand ihrer Signatur. Wie oben erwähnt, kann es verschiedene zugrunde liegende Formate der Datenübertragung für NVMe geben, wobei die anerkannte Abkürzung für NVMe over PCie „NVMe/PCIe“ lautet. NVMe over Fabrics” wird, wenn es agnostisch in Bezug auf den Transport verwendet wird, mit „NVMe-oF“ abgekürzt. NVMe über Remote Direct Memory Access (RDMA) wird mit „NVMe/RDMA“ abgekürzt. NVMe über Fibre Channel wird mit „NVMe/FC“ abgekürzt, und NVMe über Transport Control Protocol (TCP) wird mit „NVMe/TCP“ abgekürzt. „Da andere Protokolle mit NVMe in Verbindung gebracht werden, ist zu erwarten, dass weitere Abkürzungen definiert werden können. Angesichts der Vorteile dieser Offenlegung sind die Techniken dieser Offenlegung auf bestehende und künftige Implementierungen von Transporten anwendbar, die in ähnlicher Weise wie die Beispiele dieser Offenlegung verwendet werden können, was für den Fachmann offensichtlich ist.
-
Routing-Regeln eines Netzwerkinfrastrukturgeräts (z. B. Switch/Router) können in Ternary Content Addressable Memory (TCAM)-Tabellen gespeichert werden, um eine schnelle Auflösung der Routing-Regeln für NVMe-oF-Netzwerkpakete zu ermöglichen. TCAM kann als spezialisierter Hochleistungsspeicher bezeichnet werden, der von Netzwerkinfrastrukturgeräten zur schnellen Auflösung von Routing-Regeln verwendet werden kann.
-
In einigen Implementierungen kann das offengelegte Netzwerkinfrastrukturgerät so programmiert sein, dass sie die verlustfreie Warteschlange bis zu einem bestimmten Schwellenwert füllen lässt, bevor sie Anweisungen an die Absender von NVMe-oF-Netzwerkpaketen sendet, mit denen diese aufgefordert werden, die Übertragungen vorübergehend zu unterbrechen. Wenn dann die verlustfreie Warteschlange durch die Netzinfrastruktureinrichtung geleert wird, die NVMe-oF-Pakete an das vorgesehene Ziel sendet, kann die Netzinfrastruktureinrichtung einen Befehl an die zuvor pausierenden Absender ausgeben und sie auffordern, das Senden von Netzwerkpaketen wieder aufzunehmen. Der Vorgang des Anhaltens und Wiederaufnehmens kann implementiert werden, um zu verhindern, dass sich die verlustfreie Warteschlange füllt und die Netzwerkinfrastruktureinrichtung gezwungen ist, NVMe-oF-Netzwerkpakete zu verwerfen, weil nicht genügend Speicher für die Speicherung von Netzwerkpaketen zur Verfügung steht. Bei Implementierungen, die Pausen- und Fortsetzungsoperationen verwenden, können unterschiedliche konfigurierbare Schwellenwerte verwendet werden, um festzulegen, wann einer der beiden Befehle „Pause“ oder „Fortsetzen“ ausgegeben werden soll.
-
Wie oben kurz erwähnt, können einige offengelegte Implementierungen NVMe-oF-Netzwerkpakete automatisch identifizieren, zumindest teilweise, indem die Eigenschaften aller Netzwerkpakete untersucht werden. Sobald die Netzwerkpakete für die Inspektion erhalten wurden, können sie analysiert werden, um Informationen (z. B. eine Signatur, wie weiter unten beschrieben) zu identifizieren, die für NVMe-oF-Netzwerkpakete einzigartig sein können. Beispielsweise können Netzwerkpakete, die das Protokoll Remote Direct Memory Access (RDMA) over Converged Ethernet (allgemein als RoCE-Protokoll bekannt) verwenden, dadurch identifiziert werden, dass der EtherType-Wert im Paket eine zugewiesene hexadezimale Zahl gleich „0x8915“ hat. Der EtherType ist in diesem Zusammenhang ein Zwei-Oktett-Feld in einem Ethernet-Paket, das das im Paket eingekapselte Protokoll angibt. In einem ähnlichen Beispiel können Netzwerkpakete des RoCE-Protokolls Version 2 als in User Datagram Protocol (UDP)-Paketen mit einem Zielport 4791 oder 4420 (wie von der Internet Assigned Number Authority (IANA) zugewiesen) eingekapselt identifiziert werden.
-
Es gibt viele mögliche aktuelle und zukünftige Protokolle, die zur Bildung von NVMe-oF-Netzwerkpaketen verwendet werden können. Als weiteres Beispiel kann die Identifizierung von NVMe-oF-Netzwerkpaketen, die das Internet Wide-Area RDMA-Protokoll (iWARP) verwenden, durch die Identifizierung von TCP-Netzwerkpaketen (Transmission Control Protocol) mit einem Zielport 4420 erfolgen. In ähnlicher Weise kann das Protokoll, das NVMe über TCP verwendet, mit anderen TCP-Netzwerkpaketen (z. B. Kontrollpaketen) mit Merkmalen verknüpft werden, die bei der Identifizierung des NVMe-oF-Netzwerkverkehrs helfen können. Die identifizierende Einzigartigkeit eines jeden Protokolls kann genutzt werden, um NVMe-oF-Netzwerkpakete für die automatische Weiterleitung an verlustfreie Warteschlangen automatisch zu identifizieren. Einige der vorgestellten Implementierungen können eine erweiterbare „regelbasierte“ Signatur als Technik zur Identifizierung von NVMe-oF-Netzwerkpaketen verwenden. So würde in diesen Beispielimplementierungen eine Aktualisierung der Regeln die Erkennung zusätzlicher (und möglicherweise zukünftiger) Signaturen ermöglichen, die mit NVMe-oF-Netzwerkpaketen verbunden sind. In einigen offengelegten Implementierungen beziehen sich die Beispiele auf bestimmte Adressen und Portnummern, es kann jedoch jede Art von Signatur zur Identifizierung einer Art von NVMe-oF-Protokoll verwendet werden, und diese Signaturen können als Regeln für verschiedene Implementierungen definiert werden.
-
In ist ein Netzwerkinfrastrukturgerät 100, wie z. B. ein Switch/Router 105, in einem Blockdiagramm dargestellt. Im Allgemeinen verfügt ein Router über zwei Arten von Netzwerkelementkomponenten, die auf separaten Ebenen organisiert sind, die als Steuerebene 110 und Datenebene 115 dargestellt sind. Darüber hinaus kann ein typischer Switch/Router 105 Verarbeitungsressourcen und einen lokalen Datenspeicher 120 umfassen. Je nach den Fähigkeiten eines bestimmten Switch/Router 105 können verschiedene Arten von Verarbeitungsressourcen und lokalem Speicher (für die interne Nutzung des Geräts) vorhanden sein. Im Allgemeinen umfassen Switch/Router 105-Implementierungen mit höherer Kapazität umfangreiche Verarbeitungsressourcen und Speicher, während einfachere Geräte (z. B. mit geringer Kapazität) weniger interne Ressourcen enthalten. Lokaler Speicher für die interne Gerätenutzung ist nicht zu verwechseln mit ansteckbaren oder integrierten Speichergeräten (z. B. SSDs) für die Netzwerknutzung, wie in dieser Offenlegung beschrieben.
-
Die Steuerebene 110, z. B. in einem Router, kann verwendet werden, um Routing-Tabellen (oder eine einzige umfassende Routing-Tabelle) zu pflegen, die auflisten, welche Route zur Weiterleitung eines Datenpakets verwendet werden soll und über welche physische Schnittstellenverbindung (z. B. die Ausgangsports 160 bis 169). Die Steuerebene 110 kann diese Funktion unter Verwendung interner vorkonfigurierter Richtlinien, so genannter statischer Routen, oder durch dynamisches Lernen von Routen mithilfe eines Routing-Protokolls ausführen. Statische und dynamische Routen können in einer oder mehreren Routing-Tabellen gespeichert werden. Die Logik der Steuerungsebene kann dann unwesentliche Direktiven aus der Tabelle entfernen und eine Weiterleitungsinformationsbasis (FIB) erstellen, die von der Datenebene 115 verwendet wird.
-
Ein Router kann auch eine Weiterleitungsebene (z. B. Teil der Datenebene 115) verwenden, die verschiedene Weiterleitungspfade für Informationen von verschiedenen Ports oder verschiedenen Zieladressen enthält (z. B. Weiterleitungspfad A 116 oder Weiterleitungspfad Z 117). Im Allgemeinen leitet der Router Datenpakete zwischen eingehenden (z. B. Ports 150 - 159) und ausgehenden Schnittstellenverbindungen (z. B. Ports 160 - 159) weiter. Der Router leitet Datenpakete an den richtigen Netzwerktyp weiter, indem er Informationen verwendet, die im Paketkopf enthalten sind und mit Einträgen in der FIB übereinstimmen, die von der Steuerungsebene 110 bereitgestellt werden. Ports sind in der Regel bidirektional und werden in diesem Beispiel entweder als „Eingang“ oder „Ausgang“ dargestellt, um den Fluss einer Nachricht durch einen Routing-Pfad zu veranschaulichen. In einigen Netzwerkimplementierungen kann ein Router (z. B. Switch/Router 105) Schnittstellen für verschiedene Arten von Physical-Layer-Verbindungen haben, wie z. B. Kupferkabel, Glasfaserkabel oder drahtlose Übertragung. Ein einziger Router kann auch verschiedene Übertragungsstandards der Netzwerkschicht unterstützen. Jede Netzwerkschnittstelle kann dazu verwendet werden, Datenpakete von einem Übertragungssystem zu einem anderen weiterzuleiten. Router können auch verwendet werden, um zwei oder mehr logische Gruppen von Computergeräten, so genannte Subnetze, zu verbinden, die jeweils ein anderes Netzwerkpräfix haben.
-
Der ebenfalls in 1 dargestellte bidirektionale Pfeil 107 zeigt an, dass die Steuerebene 110 und die Datenebene 115 koordiniert arbeiten können, um die Gesamtfähigkeiten des Switch/Router 105 zu erreichen. In ähnlicher Weise zeigt der bidirektionale Pfeil 125 an, dass Verarbeitungs- und lokale Datenspeicherressourcen 120 eine Schnittstelle mit der Steuerebene 110 bilden können, um Verarbeitungs- und Speicherunterstützung für die der Steuerebene 110 zugewiesenen Fähigkeiten bereitzustellen. Der bidirektionale Pfeil 130 zeigt an, dass die Verarbeitungs- und lokalen Datenspeicherressourcen 120 bei Bedarf auch mit der Datenebene 115 verbunden werden können.
-
Die in 1 dargestellte Steuerebene 110 umfasst mehrere Beispiel-Funktionssteuerblöcke. Zusätzliche Steuerblöcke sind je nach den Fähigkeiten einer bestimmten Implementierung eines Switch/Router 105 möglich. Block 111 zeigt an, dass die Steuerebene 110 über zugehörige Build-Informationen bezüglich einer Softwareversion des Steuercodes verfügen kann, der derzeit auf dem Switch/Router 105 ausgeführt wird. Darüber hinaus kann diese Softwareversion Konfigurationseinstellungen enthalten, die bestimmen, wie der Switch/Router 105 und der zugehörige Steuercode verschiedene Funktionen ausführen.
-
Es sind viele verschiedene Konfigurationseinstellungen sowohl für die Software als auch für das Gerät selbst möglich, und eine Beschreibung der einzelnen Einstellungen würde den Rahmen dieser Offenlegung sprengen. Die offengelegte automatische Erkennung und Weiterleitung von NVMe-oF-Netzwerkpaketen kann jedoch in einer oder mehreren funktionalen Komponenten der Netzwerkinfrastrukturvorrichtung 105 implementiert werden. Die Regeln zur Identifizierung von NVMe-oF-Netzwerkpaketen und die Verarbeitungslogik zur Durchführung der automatischen Identifizierung können in diese eine oder mehrere funktionale Komponenten integriert werden. In einigen Implementierungen, wie in den dargestellt, kann ein Netzwerkinfrastrukturgerät 100 (z. B. Switch/Router 105 oder HA-Switch 200A und 200B) aus mehreren Geräten in verschiedenen HA-Konfigurationen zusammengesetzt sein. Ein oder mehrere Geräte in Switch/Router 105 können so konfiguriert sein, dass sie die automatische Erkennung und Weiterleitung von NVMe-oF-Netzwerkpaketen implementieren.
-
In Fortsetzung von 1 zeigt Block 111 an, dass verschiedene Arten von Routing-Informationen und Konnektivitätsinformationen dem Switch/Router 105 (als Beispiel für das Netzwerkinfrastrukturgerät 100) und der Steuerungsebene 110 bekannt sein können. Block 112 zeigt an, dass ein Informationsspeicher von der Steuerebene 110 aus zugänglich sein kann und gegebenenfalls Weiterleitungstabellen oder NAT-Informationen enthält. Block 113 zeigt an, dass die Steuerebene 110 auch über Weiterleitungsentscheidungen und andere Verarbeitungsinformationen informiert sein kann. Obwohl diese logischen Fähigkeiten in 1 innerhalb der Steuerebene 110 dargestellt sind, können sie auch außerhalb der Steuerebene 110 implementiert werden, sind aber für diese zugänglich.
-
In 2A ist ein Beispiel für einen hochverfügbaren Switch 205A im Blockdiagramm 200A dargestellt. Der Hochverfügbarkeits-Switch 205A ist mit zwei Steuergeräten dargestellt. Controller 1 (210) wird als „aktiver“ Controller und Controller 2 (215) als „Standby“-Controller bezeichnet. Wie im Folgenden näher erläutert, kann ein Hochverfügbarkeits-Switch, wie der Hochverfügbarkeits-Switch 205, eine beliebige Anzahl von Controllern haben, in der Regel jedoch mindestens zwei. In einigen Konfigurationen arbeiten die Controller als Primär-/Backup-Paar mit einem dedizierten aktiven Controller und einem dedizierten Standby-Controller. In einer Primär-/Backup-Konfiguration führt der primäre Controller alle Netzwerkfunktionen aus, und der Standby-Controller wartet, wie der Name schon sagt, darauf, der aktive Controller zu werden, wenn ein Failover-Zustand erreicht wird. Failover kann automatisch oder manuell erfolgen und für verschiedene Komponenten innerhalb eines übergeordneten HA-Geräts implementiert werden - Im Allgemeinen bezieht sich Failover auf einer konzeptionell hohen Ebene auf den Rollentausch zwischen der aktiven und der Standby-Komponente, so dass die Standby-Komponente zur aktiven und die aktive Komponente (manchmal nach einem Neustart oder Austausch) zur Standby-Komponente wird. Im Kontext von SSD-Geräten, die in einen Netzwerk-Switch integriert sind, kann ein SSD als primäres in einem redundanten Paar von SSDs fungieren, die mit Datenschreibvorgängen auf dem neuesten Stand gehalten werden, so dass das Backup des redundanten Paares automatisch übernehmen kann (z. B. ist das Backup ein Hot-Standby), wenn (aus einer beliebigen Anzahl von Gründen) das primäre SSD nicht verfügbar ist.
-
Der Hochverfügbarkeits-Switch 2Q5Aa!so umfasst eine Vielzahl von Kommunikationskarten (z. B. Kartensteckplatz 1 (221), Kartensteckplatz 2 (222), Kartensteckplatz 3 (223) und Kartensteckplatz N (225)), die jeweils eine Vielzahl von Kommunikationsanschlüssen aufweisen können, die zur Unterstützung der Netzwerkkommunikation konfiguriert sind. Ein Kartensteckplatz, wie z. B. Kartensteckplatz 1 (221), kann auch als „Leitungskarte“ bezeichnet werden und eine Vielzahl von bidirektionalen Kommunikationsanschlüssen (sowie einen Verwaltungsanschluss (nicht dargestellt)) haben. Card Slot 1 (221) ist mit Port 1-1 (241) und Port 1-2 (242) dargestellt und kann eine „Karte“ darstellen, die in einen Slot (z. B. Kommunikationsbusanschluss) einer Backplane (z. B. Kommunikationsbus) des hochverfügbaren Switches 205A eingesteckt wird. Andere Verbindungen und Verbindungsarten sind ebenfalls möglich (z. B. Kabelverbindung, NVMe-Gerät). Außerdem ist in 2A Kartensteckplatz 2 (222) mit Anschluss 2-1 (243) und Anschluss 2-2 (244) dargestellt; Kartensteckplatz 3 (223) ist mit den Anschlüssen 3-1 (245), 3-2 (246) und Anschluss 3-N (247) dargestellt; und Kartensteckplatz N (225) ist mit Anschluss X (248) und Anschluss Y (249) dargestellt.
-
Zur Unterstützung der Kommunikation zwischen einem Controller (z. B. einem aktiven und/oder einem Standby-Controller) in einem Switch und mit diesem Switch verbundenen Client-Geräten kann eine Reihe von Kommunikations-Client-Anwendungen auf einem bestimmten Switch ausgeführt werden. Client-Anwendungen, die auf einem Switch ausgeführt werden, können sowohl bei der Kommunikation mit den angeschlossenen Clients als auch bei der Konfiguration der Hardware auf dem Switch (z. B. Ports einer Linecard) helfen-In einigen Fällen werden Client-Anwendungen als „Listener“ bezeichnet, da sie teilweise auf eine Kommunikation oder einen Befehl „lauschen“ und dann verarbeiten, was sie empfangen. Für den Hochverfügbarkeits-Switch 205A ist eine beispielhafte Client-Anwendung der Client 1 (230-1), der die Kommunikation vom aktiven oder vom Standby-Controller mit den über den Kartensteckplatz 1 (221) angeschlossenen Geräten unterstützt. In einigen Beispielimplementierungen kann ein Listener so konfiguriert sein, dass er NVMe-oF-Netzwerkpakete automatisch erkennt und weiterleitet. Andere Implementierungen, bei denen die automatische Identifizierung durch Hardwarekomponenten oder andere Softwarekomponenten erfolgt, sind ebenfalls möglich.
-
Ein zweites Beispiel für eine Client-Anwendung in 2A ist Client 2 (230-2), der die Kommunikation von einem der beiden Steuergeräte zu Kartensteckplatz 2 (222) und Kartensteckplatz 3 (223) unterstützt. Client Z (230-Z) schließlich unterstützt die Kommunikation von beiden Steuerungen mit Kartensteckplatz N (225). Gestrichelte Linien im Blockdiagramm 200 vom Standby-Steuergerät 2 zu Client-Anwendungen zeigen an, dass das Standby-Steuergerät über eine Client-Anwendung mit einem Kommunikationskartensteckplatz kommunizieren kann, aber aufgrund seines Standby-Status möglicherweise keine wichtigen Daten überträgt. Die durchgezogenen Linien im Blockdiagramm 200 von der aktiven Steuereinheit 1 zu den Client-Anwendungen zeigen einen aktiven Status an, in dem wahrscheinlich mehr Kommunikation stattfindet. Es ist auch zu beachten, dass ein einzelner Client so konfiguriert sein kann, dass er mehr als einen (oder sogar einen Teil eines) Kommunikationskartensteckplatz (Leitungskarte) unterstützt, wie in der Abbildung mit Client 2 (230-2) dargestellt, der sowohl Kartensteckplatz 2 (222) als auch Kartensteckplatz 3 (223) gleichzeitig unterstützt. Obergrenzen für die Anzahl der von einem Client unterstützten Kartensteckplätze können eine Implementierungsentscheidung sein, die auf den Leistungsmerkmalen oder anderen Faktoren des Switches und seiner internen Konstruktion beruht.
-
Unter Bezugnahme auf 2B zeigt das Blockdiagramm 200B den HA-Switch 205B als eine Variante des oben beschriebenen HA-Switch 205A. Wie dargestellt, integriert HA-Switch 205B im Bereich 255 (durch einen gestrichelten Kasten umrissen) mehrere SSD-Komponenten, die verwendet werden können, um Netzwerkspeicher für Remote-Geräte bereitzustellen. Wie dargestellt, können SSD-Geräte anstelle von Kommunikationsanschlüssen für HA-Switch 205B verwendet werden. Insbesondere sind in Kommunikationskartensteckplatz 2 (252) SSD 2-1 (250-1) und SSD 2-2 (250-2) integriert. Um eine HA-Konfiguration zu erreichen, können je nach Implementierungsspezifikationen SSD 2-1 (250-1) und SSD 2-2 (250-2) als redundantes Paar von Speichergeräten gepaart oder unabhängig voneinander implementiert werden. Da sich sowohl SSD 2-1 (250-1) als auch SSD 2-2 (250-2) auf Kartensteckplatz 2 (252) befinden, kann es wünschenswert sein, ein redundantes Paar bereitzustellen, bei dem sich sowohl das primäre als auch das Backup eines redundanten Paares nicht auf derselben Linecard befinden. Insbesondere kann ein SSD zur Redundanz mit einem SSD auf einer anderen Linecard gepaart werden. Jede der beiden Implementierungen ist möglich. Ein möglicher Vorteil von Ein- und Ausgängen (oder Redundanzpaaren) auf derselben Line-Card wäre, dass die Kommunikation zwischen Geräten auf derselben Line-Card kein Chassis-Fabric durchqueren müsste (d. h. die Kommunikation zwischen den Geräten würde lokal auf der Line-Card-Fabric erfolgen). Natürlich können verschiedene Implementierungskriterien berücksichtigt werden, um eine optimale Implementierung für eine bestimmte Anwendungslösung zu finden. Darüber hinaus ist es möglich, dass eine einzelne Linecard eine Kombination aus integrierten SSD-Komponenten und Kommunikationsanschlüssen aufweist.
-
Wie auch im Beispiel HA-Switch 205B dargestellt, kann eine Linecard mit einer beliebigen Anzahl von integrierten SSD-Komponenten kommunizieren. Insbesondere zeigt Bereich 255, dass SSD 3-1, SSD 3-2 und SSD 3-N (alle mit der Elementreferenznummer 251 referenziert) in den Kartensteckplatz 3 (253) integriert (oder mit ihm verbunden) sein können. In diesem Beispiel kann sich der Client 2 (230-2) anpassen, um mit Linecards mit integrierten SSD-Komponenten zu kommunizieren, und andere Datenverarbeitungsgeräte (z. B. außerhalb des Bereichs 255) haben möglicherweise keine Kenntnis von den detaillierten Implementierungen im Bereich 255. Das heißt, die offengelegte Implementierung der in den HA-Switch 205B integrierten SSD-Komponenten kann für externe Geräte und andere Komponenten des HA-Switch 205B transparent sein. Obwohl Client 2 (230-2) im Blockdiagramm 200B als potenzielles Software-(oder Firmware-) Modul dargestellt ist, ist es möglich, die Funktionalität von Client 2 (230-2) vollständig (oder zumindest teilweise) innerhalb der Hardware-Logik (d. h. der siliziumbasierten Logik) von HA-Switch 205B zu implementieren. Ein Fachmann, der mit den Vorteilen dieser Offenlegung vertraut ist, wird erkennen, dass viele verschiedene Implementierungen von Software-, Firmware- und Hardware-Logik verwendet werden können, um die offengelegten Techniken der automatischen Erkennung, Weiterleitung und Priorisierung von NVMe-Paketen mit einer höheren Verarbeitungspriorität in Bezug auf Pakete anderer Protokolle zu erreichen, um verlustfreie Kommunikationsflüsse für netzwerkgebundene Speichergeräte (insbesondere NVMe-oF-Geräte) zu erreichen.
-
In 3A ist ein Beispiel für die Weiterleitung von Netzwerkpaketen 300A bei Verwendung eines Netzwerk-Switches/Routers wie dem Switch/Router 105 von 1 dargestellt. Wie oben erwähnt, können Netzwerkpakete für mehrere Protokolle gleichzeitig auf demselben physikalischen Medium (oder der Datentransportschicht im Falle von drahtlosen Netzwerken) einer Netzwerkkommunikationsverbindung übertragen werden. Dementsprechend können Netzwerkpakete mehrerer Protokolle gleichzeitig an einem oder mehreren Ports eines Netzwerk-Switches/Routers (z. B. Netzwerk-Switch/Router 105) empfangen werden. Zum Beispiel können Nicht-NVMe-oF-Netzwerkpakete 305 in Verbindung mit mehreren NVMe-oF-Protokollen wie RoCE V2 310, IWARP 315 oder einem anderen NVMe-oF-Protokoll 320 empfangen werden. Gemäß den offengelegten Implementierungen können Netzwerkpakete vom Netzwerk-Switch/Router empfangen und an die oben erwähnten internen Teilsysteme weitergeleitet werden. Beispielsweise können Weiterleitungsentscheidungs- und Steuerebenenverarbeitung 113, bei denen Erkennungstechniken auf der Grundlage der oben erwähnten Paketanalyse (z. B. regelbasierte Signaturanalyse) ausgeführt werden, um NVMe-oF-Netzwerkpakete von Nicht-NVMe-oF-Netzwerkpaketen zu unterscheiden. Die identifizierten Netzwerkpakete können dann an einen oder mehrere spezifische Routingpfade in der Datenebene 115 weitergeleitet werden. In einigen Beispielimplementierungen kann die Weiterleitungsentscheidungs- und Steuerebenenverarbeitung 113 so konfiguriert sein, dass Nicht-NVMe-oF-Netzwerkpakete an die verlustbehaftete Weiterleitungsebene 316 weitergeleitet werden, die so konfiguriert ist, dass sie Netzwerkpakete für Protokolle weiterleitet, die gegenüber Verlusten resistent sein können. Die Konfiguration kann alternativ NVMe-oF-Netzwerkpakete an die verlustfreie Weiterleitungsebene 317 weiterleiten, die so konfiguriert ist, dass sie niemals Netzwerkpakete verliert (z. B. niemals ein Paket verwirft), wie es für NVMe-oF-Protokolle erwünscht sein kann.
-
Um alle Netzwerkpakete zu verarbeiten, die am Beispiel des Netzwerkinfrastrukturgeräts 100 (z. B. Switch/Router 105) empfangen werden, kann die verlustbehaftete Weiterleitungsebene 316 parallel zur verlustfreien Weiterleitungsebene 317 arbeiten, um empfangene Netzwerkpakete an eine Vielzahl von Netzwerkpaketkonsumenten (z. B. Nicht-NVMe-oF-Netzwerkpaketkonsumenten 325 und NVMe-oF-Netzwerkpaketkonsumenten 330) zu liefern. So kann verlustbehaftete Kommunikation an Nicht-NVMe-oF-Paketkonsumenten 325 zugestellt werden, während verlustfreie Kommunikation an NVMe-oF-Paketkonsumenten 330 zugestellt werden kann (möglicherweise mit höherer Priorität im Vergleich zu Nicht-NVMe-oF-Netzwerkpaketen).
-
In 3B ist ein beispielhaftes Blockdiagramm dargestellt, das einen beispielhaften internen Warteschlangen-Routing-Mechanismus 300B zeigt, der von einem Netzinfrastrukturgerät 100 (siehe 1) verwendet werden kann. In diesem Beispiel kann das Konzept des Knotens als logisches Teilsystem eines Netzinfrastrukturgeräts oder als logischer Verarbeitungsblock betrachtet werden, der intern oder extern in einem Netzinfrastrukturgerät implementiert ist. In diesem Beispiel kann eine Vielzahl von Quellknoten 335 Netzwerkpakete in einer Vielzahl von Warteschlangen empfangen, die im Quellknoten 335 enthalten sind. Jede Warteschlange im Quellknoten 335 kann mit einer Ratensteuerungslogik (RC) 385 gekoppelt sein. Jeder Quellknoten 335 kann über den Fabric Load Balancer (FLB) 390 mit mehreren Fabric-Knoten 340 verbunden sein.
-
Verbindungen von Quellknoten 335 zu mehreren Fabric-Knoten 340 bilden eine Vielzahl von alternativen Pfaden 355, auf denen Netzwerkpakete zu Fabric-Knoten 340 gesendet werden können. Die Fabric-Knoten 340 können auch über mehrere interne Warteschlangen verfügen, die von den Quellknoten 335 gesendete Netzwerkpakete empfangen. Die Fabric-Knoten 340 können auch über einen Lastausgleichsmechanismus 395 verfügen, der empfangene Pakete an interne Warteschlangen des Fabric-Knotens 340 weiterleitet. Die Fabric-Knoten 340 können mit den Zielknoten über einen Verbindungsmechanismus, wie z. B. den Bus 365, verbunden sein. Bei den Zielknoten kann es sich um eine Vielzahl von Knoten handeln, wie z. B. Zielportknoten 345 und Ziel-NVMe-Knoten 350. Der Kürze halber werden in diesem Beispiel nur zwei Typen von Zielknoten dargestellt, aber es sind viele Arten von Knoten möglich, die mit den Fabric-Knoten 340 verbunden werden können.
-
In einer Beispielimplementierung können Fabric-Knoten 340 so konfiguriert werden, dass sie Netzwerkpakete an Zielknoten auf der Grundlage der Art des zu übermittelnden Netzwerkpakets zustellen. So können beispielsweise Nicht-NVMe-oF-Pakete an einen oder mehrere Zielportknoten 345 zugestellt werden. Der Zielportknoten 345 kann das Netzwerkpaket an eine oder mehrere interne Warteschlangen 370 liefern. Die internen Warteschlangen 370 können weiter unterteilt werden, z. B. auf der Grundlage der Verarbeitungspriorität des Netzwerkpakets. In einem anderen Beispiel können die Fabric-Knoten 340 NVMe-oF-Netzwerkpakete an die NVMe-Zielknoten 350 liefern. Der NVMe-Zielknoten 350 kann über ein oder mehrere Warteschlangenpaare 375 verfügen, wie die Übermittlungswarteschlange (in der Netzwerkpakete zur Verarbeitung an das Gerät übermittelt werden) und eine Abschlusswarteschlange (in der Antworten auf verarbeitete Netzwerkpakete an ein Ziel im Netzwerk gesendet werden). Im Zusammenhang mit einer SSD-Schnittstelle stehen die Übermittlungswarteschlangen für Lese- und Schreibvorgänge und die Abschlusswarteschlangen für die Datenübertragung als Reaktion auf diese Befehle.
-
Jeder Zielknoten (345, 350) kann außerdem eine Stauabrechnungsfunktion 380 für die Ausgangswarteschlange enthalten. Die Egress Queue Congestion Accounting-Funktion 380 kann in Software, Firmware oder Hardware-Logik implementiert sein und kann zur Überwachung der Kapazität des Knotens zur Annahme neuer Netzwerkpakete verwendet werden. Gemäß offengelegten Implementierungen kann die Stauabrechnungsfunktion 380 für ausgehende Warteschlangen mit einer oder mehreren Ratensteuerungslogiken 385 des Quellknotens 335 gekoppelt sein (dargestellt mit Linie 365). In einer Beispielimplementierung kann die Abrechnung der Ausgangswarteschlange 380 verwendet werden, um den Paketfluss auf der Grundlage eines Knotens zu steuern, der die Kapazität für die Verarbeitung neuer Netzwerkpakete erreicht oder nahezu erreicht hat. Der Kürze halber wird im Diagramm nur eine derartige Kopplung mit der Leitung 365 dargestellt, doch können bei tatsächlichen Implementierungen alle Instanzen der Stauabrechnung für Ausgangswarteschlangen 380 mit allen Instanzen der Ratensteuerungslogik 385 in allen Quellknoten 335 gekoppelt werden.
-
Die Stauabrechnung für die Ausgangswarteschlange 380 kann, wenn sie mit der Ratensteuerungslogik 385 gekoppelt ist, die direkte Rückkopplungssteuerung 360 verwenden, um eine Rückkopplungsschleife zwischen den Quellknoten 335 und den Zielknoten 345, 350 zu bilden, um zu verhindern, dass Netzwerkpakete Ressourcen in den Fabric-Knoten 340 verbrauchen, wenn ein Zielknoten 345, 350 möglicherweise nicht die Kapazität hat, mehr Netzwerkpakete zu verarbeiten. Wenn der Quellknoten 335 darüber informiert wird, dass er die Eingangsrate von Netzwerkpaketen steuern soll, kann er zusätzliche empfangene Netzwerkpakete auf der Grundlage der Art des empfangenen Pakets verarbeiten. Wenn ein Quellknoten 335 beispielsweise ein NVMe-oF-Netzwerkpaket empfängt, nachdem er angewiesen wurde, die Rate zu kontrollieren, kann das Netzwerkinfrastrukturgerät den Absender informieren, das Senden von Netzwerkpaketen vorübergehend einzustellen. Ein anderes Beispiel: Wenn ein Quellknoten 335 ein Nicht-NVMe-oF-Netzwerkpaket empfängt, nachdem er angewiesen wurde, die Rate zu kontrollieren, kann der Quellknoten das Paket verwerfen. Andere Implementierungen der tatsächlichen Paketbehandlung auf der Grundlage von Überlastungen sind ebenfalls möglich.
-
In 4 zeigt ein Blockdiagramm eine High-Level-Beispielansicht eines Kontrollflusses 400, der für die automatische Erkennung und Weiterleitung von NVMe-oF-Netzwerkpaketen implementiert werden kann. Wie oben unter Bezugnahme auf 3A erläutert und in 4 wiederholt, können Nicht-NVMe-oF-Netzwerkpakete 305 in Kombination mit NVMe-oF-Netzwerkpaketen 310, 315 und 320 gleichzeitig von einem Netzwerkinfrastrukturgerät (nicht dargestellt) empfangen werden. Nach dem Empfang kann eine Klassifizierungsphase 410 zur automatischen Identifizierung einer Protokollsignatur implementiert werden, um beispielsweise eine oder mehrere Klassifizierungstechniken als Teil der Klassifizierungsphase 410 zu initiieren. im Allgemeinen! Dieses Beispiel zeigt, dass die Klassifizierungsphase 410 Netzwerkpakete verarbeitet, um den Typ des Netzwerkpakets zu identifizieren (z. B. um zu bestimmen, wie die Priorisierung und Weiterleitung auf der Grundlage der Art der Paketverarbeitungsanforderungen erfolgen soll). Normaler Netzwerkverkehr (hier im Allgemeinen als „Nicht-MVMe-oF-Netzwerkpakete“ klassifiziert) kann durch eine Warteschlangenphase an Warteschlangen mit niedriger Priorität 420 weitergeleitet werden. Netzwerkpakete, die als NVMe-oF-Netzwerkpakete klassifiziert sind, können an Warteschlangen für die dedizierte Speicherung weitergeleitet werden und können eine Prioritätsflusskontrolle (RFC) verwenden, wie durch Warteschlangen höherer Priorität 430 dargestellt. In den Warteschlangen 430 mit höherer Priorität können die NVMe-oF-Pakete so behandelt werden, dass die Pakete garantiert an das vorgesehene Ziel zugestellt werden (z. B. als verlustfreies Protokoll behandelt).
-
In 5 ist ein Prozessflussdiagramm dargestellt, das ein Beispiel für die Logik darstellt, die zur automatischen Identifizierung und Weiterleitung von NVMe-oF-Netzwerkpaketen angewandt wird (Verfahren 500). Das Beispielverfahren 500 beginnt in Block 510, wo ein Netzwerkpaket beliebigen Typs empfangen wird. Im weiteren Verlauf von Block 520 kann eine Vielzahl von Erkennungstechniken verwendet werden, um zu prüfen, ob der Typ des Netzwerkpakets einem NVMe-oF-Protokoll entspricht. Zum Beispiel können Netzwerkpakete analysiert werden, um festzustellen, ob sie auf der Grundlage einer Signatur des Inhalts oder der Attribute des Netzwerkpakets identifiziert werden können. Wenn das Netzwerkpaket als ein Netzwerkpaket für ein NVMe-oF-Protokoll identifiziert wird, wird der YES-Prong des Diamant-Entscheidungsblocks bis zum Block 560 weitergeführt, um die Entscheidung 530 zu treffen. In Block 560 wird das NVMe-oF-Netzwerkpaket zu einer verlustfreien Warteschlange hinzugefügt. Im weiteren Verlauf des Blocks 570 wird überprüft, ob das zuvor der Warteschlange hinzugefügte NVMe-oF-Netzwerkpaket an das vorgesehene Ziel des NVMe-oF-Netzwerkpakets zugestellt wurde, bevor es zum Block 580 weitergeht, wo das Netzwerkpaket aus der Warteschlange entfernt wird.
-
Zurück zu Entscheidung 530: Wenn das Netzwerkpaket nicht als NVMe-oF-Netzwerkpaket erkannt wird (der NEIN-Teil der Entscheidung 520), wird der Fluss zu Block 540 fortgesetzt. In Block 540 wird das Netzwerkpaket zu einer Warteschlange hinzugefügt, die je nach der für den Typ des Netzwerkpakets konfigurierten Behandlung mit oder ohne Verlust verarbeitet werden kann. Weiter zu Block 550 werden ein oder mehrere Versuche unternommen, das Netzwerkpaket zuzustellen. Jeder der ein oder mehreren Versuche kann der für den Typ des Netzwerkpakets konfigurierten Behandlung folgen. Wenn die Behandlung als verlustfrei konfiguriert ist, kann der Versuch, das Paket zuzustellen, das Warten auf eine Zustellungsbestätigung beinhalten. Wenn die Behandlung nicht als verlustfrei konfiguriert ist, kann der Zustellversuch abgebrochen werden (z. B. mit dem Ergebnis eines verworfenen Pakets). Nach der angemessenen Behandlung der Zustellung des Netzwerkpakets (z. B. Verarbeitung einer konfigurierbaren Anzahl von Wiederholungsversuchen oder Warten einer konfigurierbaren Zeitspanne) wird der Fluss zum Block 580 fortgesetzt, wo das Netzwerkpaket aus der Warteschlange entfernt wird.
-
6 zeigt ein Beispiel für ein Computergerät 600 mit einem Hardwareprozessor 601 und zugänglichen maschinenlesbaren Anweisungen, die auf einem maschinenlesbaren Medium und/oder einer Hardwarelogik 602 gespeichert sind, die verwendet werden können, um ein automatisches NVMe-oF-Netzwerk-Paket-Routing gemäß einer oder mehrerer offengelegter Beispielimplementierungen durchzuführen. 6 zeigt eine Rechenvorrichtung 600, die so konfiguriert ist, dass sie den Ablauf des Verfahrens 500 als Beispiel ausführt. Die Rechnervorrichtung 600 kann jedoch auch so konfiguriert sein, dass sie den Ablauf anderer in dieser Offenlegung beschriebener Methoden, Techniken, Funktionen oder Prozesse durchführt. In diesem Beispiel von 6 enthält das maschinenlesbare Speichermedium 602 Anweisungen, die den Hardware-Prozessor 601 veranlassen, die oben unter Bezugnahme auf 5 beschriebenen Blöcke 510-580 auszuführen. In anderen Beispielen sind jedoch unterschiedliche Implementierungen des Verfahrens 500 möglich, einschließlich Hardware-Schaltkreisen, die auf einem Chip konfiguriert sind, um das gesamte Verfahren 500 oder Teile davon in Verbindung mit einer Gesamtimplementierung offengelegter Techniken zu implementieren, um ein integriertes SSD innerhalb einer Netzwerkinfrastrukturvorrichtung bereitzustellen und Netzwerkpakete automatisch zu trennen und weiterzuleiten, basierend auf einer Protokollsignatur, die basierend auf einer Netzwerkpaketanalyse identifiziert wurde (z. B. z. B. Netzwerkpaketsignatur, die unter Verwendung einer ruies-basierten Implementierung identifiziert wird), kann in diesen Beispielen der Hardwareprozessor 601 Teil der Hardwareschaltung sein, z. B. auf Silikon aufgebaut (z. B. ASIC usw.), anstatt eine zentrale Verarbeitungseinheit zu sein.
-
Ein maschinenlesbares Speichermedium, wie z. B. 602 in 6, kann sowohl flüchtige als auch nichtflüchtige, entfernbare und nicht entfernbare Medien umfassen und kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Befehle, Datenstrukturen, Programmmodule oder andere Daten enthält oder speichert, auf die ein Prozessor zugreifen kann, z. B. Firmware, löschbarer programmierbarer Festwertspeicher (EPROM), Direktzugriffsspeicher (RAM), nichtflüchtiger Direktzugriffsspeicher (NVRAM), optische Platte, Solid-State-Laufwerk (SSD), Flash-Speicherchips und dergleichen. Das maschinenlesbare Speichermedium kann ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ keine transitorischen Übertragungssignale einschließt.
-
7 stellt eine Computernetzwerkinfrastruktur 700 dar, die verwendet werden kann, um die gesamte oder einen Teil der offengelegten automatischen NVMe-oF-Netzwerkpaketerkennung und -weiterleitungstechnik gemäß einer oder mehreren offengelegten Ausführungsformen zu implementieren. Die Netzwerkinfrastruktur 700 umfasst eine Reihe von Netzwerken, in denen die Ausführungsformen der vorliegenden Offenbarung betrieben werden können. Die Netzwerkinfrastruktur 700 umfasst ein Kundennetzwerk 702, ein Netzwerk 708, ein zellulares Netzwerk 703 und ein Cloud-Service-Provider-Netzwerk 710. In einer Ausführungsform kann das Kundennetzwerk 702 ein lokales privates Netzwerk sein, wie z. B. ein lokales Netzwerk (LAN), das eine Vielzahl von Netzwerkgeräten enthält, die Switches, Server und Router umfassen, aber nicht darauf beschränkt sind.
-
Jedes dieser Netzwerke kann drahtgebundene oder drahtlose programmierbare Geräte enthalten und mit einer beliebigen Anzahl von Netzwerkprotokollen (z. B. TCP/IP) und Verbindungstechnologien (z. B. WiFi® -Netzwerke oder Bluetooth®) arbeiten. In einer anderen Ausführungsform stellt das Kundennetzwerk 702 ein Unternehmensnetzwerk dar, das ein oder mehrere lokale Netzwerke (LANs), virtuelle Netzwerke, Datenzentren und/oder andere entfernte Netzwerke (z. B. 708, 710) umfassen oder mit diesen kommunikativ verbunden sein kann. Im Zusammenhang mit der vorliegenden Offenlegung kann das Kundennetzwerk 702 einen oder mehrere hochverfügbare Switches oder Netzwerkgeräte umfassen, die Methoden und Techniken wie die oben beschriebenen verwenden.
-
Wie in 7 gezeigt, kann das Kundennetzwerk 702 mit einem oder mehreren Client-Geräten 704A-E verbunden sein und den Client-Geräten 704A-E erlauben, miteinander und/oder mit dem Cloud-Service-Provider-Netzwerk 710 über das Netzwerk 708 (z. B. Internet) zu kommunizieren. Bei den Client-Geräten 704A-E kann es sich um Computersysteme wie Desktop-Computer 704B, Tablet-Computer 704C, Mobiltelefon 704D, Laptop-Computer (als drahtlos dargestellt) 704E und/oder andere Arten von Computersystemen handeln, die allgemein als Client-Gerät 704A dargestellt sind.
-
Die Netzwerkinfrastruktur 700 kann auch andere Arten von Geräten umfassen, die allgemein als Internet der Dinge (loT) bezeichnet werden (z. B. LOT-Gerät 705), die so konfiguriert sein können, dass sie Informationen über ein Netzwerk senden und empfangen, um auf Cloud-Computing-Dienste zuzugreifen oder mit einer entfernten Webbrowser-Anwendung zu interagieren (z. B. um Konfigurationsinformationen zu empfangen).
-
7 zeigt auch, dass das Kundennetzwerk 702 lokale Rechenressourcen 706A-C enthält, die einen Server, einen Zugangspunkt, einen Router oder ein anderes Gerät umfassen können, das so konfiguriert ist, dass es lokale Rechenressourcen bereitstellt und/oder die Kommunikation zwischen Netzwerken und Geräten erleichtert. Bei den lokalen Rechenressourcen 706A-C kann es sich beispielsweise um ein oder mehrere physische lokale Hardwaregeräte handeln, wie die oben beschriebenen HA-Switches (z. B. ein NVMe-Routing-Switch). Lokale Rechenressourcen 706A-C können auch die Kommunikation zwischen anderen externen Anwendungen, Datenquellen (z. B. 707A und 707B) und Diensten sowie dem Kundennetzwerk 702 erleichtern.
-
Die Netzinfrastruktur 700 umfasst auch das zellulare Netz 703 zur Verwendung mit mobilen Kommunikationsgeräten. Mobile zelluläre Netzwerke unterstützen Mobiltelefone und viele andere Arten von mobilen Geräten wie Laptops usw. Die mobilen Geräte in der Netzinfrastruktur 700 sind als Mobiltelefon 704D, Laptop 704E und Tablet-Computer 704C dargestellt. Ein mobiles Gerät wie das Mobiltelefon 704D kann mit einem oder mehreren Netzwerken von Mobilfunkanbietern interagieren, während sich das mobile Gerät bewegt, wobei es typischerweise mit einer Vielzahl von Mobilfunkmasten 720, 730 und 740 interagiert, um eine Verbindung mit dem zellularen Netzwerk 703 herzustellen.
-
7 zeigt, dass das Kundennetzwerk 702 mit einem Netzwerk 708 verbunden ist. Das Netzwerk 708 kann ein oder mehrere heute verfügbare Computernetzwerke umfassen, wie andere LANs, Weitverkehrsnetze (WAN), das Internet und/oder andere entfernte Netzwerke, um Daten zwischen den Kundengeräten 704A-D und dem Cloud-Service-Provider-Netzwerk 710 zu übertragen. Jedes der Computernetzwerke innerhalb des Netzwerks 708 kann verdrahtete und/oder drahtlose programmierbare Geräte enthalten, die in der elektrischen und/oder optischen Domäne arbeiten.
-
In 7 ist das Cloud-Service-Provider-Netzwerk 710 als ein entferntes Netzwerk (z. B. ein Cloud-Netzwerk) dargestellt, das mit den Client-Geräten 704A-E über das Kundennetzwerk 702 und das Netzwerk 708 kommunizieren kann. Das Cloud-Service-Provider-Netzwerk 710 fungiert als Plattform, die den Client-Geräten 704A-E und/oder dem Kundennetzwerk 702 zusätzliche Rechenressourcen zur Verfügung stellt. In einer Ausführungsform umfasst das Cloud-Service-Provider-Netzwerk 710 ein oder mehrere Rechenzentren 712 mit einer oder mehreren Serverinstanzen 714. Das Cloud-Service-Provider-Netzwerk 710 kann auch einen oder mehrere Frames oder Cluster (und Clustergruppen) enthalten, die eine skalierbare Rechenressource darstellen, die von den Techniken dieser Offenlegung profitieren kann. Außerdem erreichen Cloud-Service-Provider in der Regel eine nahezu perfekte Verfügbarkeit und können die offengelegten Techniken, Methoden und Systeme nutzen, um dieses Serviceniveau zu erreichen.
-
8 zeigt eine Rechenvorrichtung 800, die verwendet werden kann, um die Funktionen, Module, Verarbeitungsplattformen, Ausführungsplattformen, Kommunikationsvorrichtungen und andere Methoden und Prozesse dieser Offenbarung zu implementieren oder mit ihnen verwendet zu werden. Die in 8 dargestellte Rechenvorrichtung 800 könnte beispielsweise ein Client-Gerät oder ein physisches Server-Gerät darstellen und je nach Abstraktionsgrad der Rechenvorrichtung entweder Hardware oder virtuelle(n) Prozessor(en) enthalten. In einigen Fällen (ohne Abstraktion) beziehen sich die Rechenvorrichtung 800 und ihre Elemente, wie in 8 dargestellt, jeweils auf physische Hardware. Alternativ könnten in einigen Fällen ein, mehrere oder alle Elemente unter Verwendung von Emulatoren oder virtuellen Maschinen als Abstraktionsebenen implementiert werden. In jedem Fall kann die Rechenvorrichtung 800 auf ihrer niedrigsten Ebene auf physischer Hardware implementiert werden, unabhängig davon, wie viele Abstraktionsebenen von der physischen Hardware entfernt sind.
-
Wie ebenfalls in 8 gezeigt, kann das Computergerät 800 ein oder mehrere Eingabegeräte 830, wie z. B. eine Tastatur, eine Maus, ein Touchpad oder eine Sensorauslesung (z. B. einen biometrischen Scanner) und ein oder mehrere Ausgabegeräte 815, wie z. B. Displays, Lautsprecher für Audio oder Drucker, umfassen. Einige Geräte können auch als Eingabe-/Ausgabegeräte konfiguriert sein (z. B. eine Netzwerkschnittstelle oder ein Touchscreen-Display).
-
Das Computergerät 800 kann auch Kommunikationsschnittstellen 825 enthalten, wie z. B. eine Netzwerkkommunikationseinheit, die eine verdrahtete Kommunikationskomponente und/oder eine drahtlose Kommunikationskomponente enthalten kann, die mit dem Prozessor 805 kommunikativ gekoppelt sein kann. Die Netzwerkkommunikationseinheit kann eine Vielzahl von proprietären oder standardisierten Netzwerkprotokollen verwenden, wie Ethernet, TCP/IP, um nur einige von vielen Protokollen zu nennen, um die Kommunikation zwischen Geräten zu ermöglichen. Netzwerkkommunikationseinheiten können auch einen oder mehrere Transceiver umfassen, die Ethernet, Powerline-Kommunikation (PLC), WiFi, zellulare und/oder andere Kommunikationsmethoden nutzen.
-
Wie in 8 dargestellt, enthält die Rechenvorrichtung 800 ein Verarbeitungselement wie den Prozessor 805, der einen oder mehrere Hardware-Prozessoren enthält, wobei jeder Hardware-Prozessor einen oder mehrere Prozessorkerne haben kann. In einer Ausführungsform kann der Prozessor 805 mindestens einen gemeinsam genutzten Cache enthalten, der Daten (z. B. Berechnungsanweisungen) speichert, die von einer oder mehreren anderen Komponenten des Prozessors 805 verwendet werden. Bei dem gemeinsamen Cache kann es sich beispielsweise um lokal zwischengespeicherte Daten handeln, die in einem Speicher für einen schnelleren Zugriff durch Komponenten der Verarbeitungselemente, aus denen der Prozessor 805 besteht, gespeichert sind. In einer oder mehreren Ausführungsformen kann der gemeinsam genutzte Cache einen oder mehrere Mid-Level-Caches, wie z. B. Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Ebenen, einen Last-Level-Cache (LLC) oder Kombinationen davon umfassen. Beispiele für Prozessoren sind u. a. eine zentrale Verarbeitungseinheit (CPU), ein Mikroprozessor. Obwohl in 8 nicht dargestellt, können die Verarbeitungselemente, aus denen der Prozessor 805 besteht, auch eine oder mehrere andere Arten von Hardwareverarbeitungskomponenten umfassen, wie z. B. Grafikverarbeitungseinheiten (GPU), anwendungsspezifische integrierte Schaltungen (ASICs), feldprogrammierbare Gate-Arrays (FPGAs) und/oder digitale Signalprozessoren (DSPs).
-
8 illustriert, dass der Speicher 810 operativ und kommunikativ mit dem Prozessor 805 verbunden sein kann. Der Speicher 810 kann ein nicht-übertragbares Medium sein, das zum Speichern verschiedener Datentypen konfiguriert ist. Zum Beispiel kann der Speicher 810 eine oder mehrere Speichervorrichtungen 820 enthalten, die eine nichtflüchtige Speichervorrichtung und/oder einen flüchtigen Speicher umfassen. Ein flüchtiger Speicher, wie z. B. ein Direktzugriffsspeicher (RAM), kann jede geeignete nicht permanente Speichereinrichtung sein. Die nichtflüchtigen Speichervorrichtungen 820 können ein oder mehrere Festplattenlaufwerke, optische Laufwerke, Solid-State-Laufwerke (SSDs), Tap-Laufwerke, Flash-Speicher, Festwertspeicher (ROM) und/oder jede andere Art von Speicher umfassen, die dafür ausgelegt sind, Daten nach einem Stromausfall oder einem Abschaltvorgang für eine gewisse Zeit aufzubewahren. In bestimmten Fällen können die nichtflüchtigen Speicher 820 zur Speicherung von Überlaufdaten verwendet werden, wenn das zugewiesene RAM nicht ausreicht, um alle Arbeitsdaten zu speichern. Die nichtflüchtigen Speichervorrichtungen 820 können auch zum Speichern von Programmen verwendet werden, die in den RAM geladen werden, wenn solche Programme zur Ausführung ausgewählt werden.
-
Gewöhnliche Fachleute wissen, dass Softwareprogramme in einer Vielzahl von Computersprachen für eine Vielzahl von Softwareplattformen und/oder Betriebssystemen entwickelt, kodiert und kompiliert werden können und anschließend vom Prozessor 805 geladen und ausgeführt werden. In einer Ausführungsform kann der Kompilierungsprozess des Softwareprogramms den in einer Programmiersprache geschriebenen Programmcode in eine andere Computersprache umwandeln, so dass der Prozessor 805 in der Lage ist, den Programmiercode auszuführen. Zum Beispiel kann der Kompilierungsprozess des Softwareprogramms ein ausführbares Programm erzeugen, das kodierte Anweisungen (z. B. Maschinencode-Anweisungen) für den Prozessor 805 bereitstellt, um spezifische, nicht-generische, bestimmte Rechenfunktionen auszuführen.
-
Nach dem Kompilierungsprozess können die kodierten Anweisungen dann als computerausführbare Anweisungen oder Prozessschritte in den Prozessor 805 von der Speichervorrichtung 820, aus dem Speicher 810 und/oder eingebettet in den Prozessor 805 (z. B. über einen Cache oder On-Board-ROM) geladen werden. Der Prozessor 805 kann so konfiguriert sein, dass er die gespeicherten Anweisungen oder Prozessschritte ausführt, um Anweisungen oder Prozessschritte auszuführen, die das Computergerät in eine nicht-generische, besondere, speziell programmierte Maschine oder Vorrichtung verwandeln. Auf gespeicherte Daten, z. B. Daten, die in einem Speichergerät 820 gespeichert sind, kann der Prozessor 805 während der Ausführung von computerausführbaren Anweisungen oder Prozessschritten zugreifen, um eine oder mehrere Komponenten innerhalb des Computergeräts 800 zu instruieren.
-
Eine Benutzerschnittstelle (z. B. Ausgabegeräte 815 und Eingabegeräte 830) kann ein Display, ein positionelles Eingabegerät (wie eine Maus, ein Touchpad, ein Touchscreen oder ähnliches), eine Tastatur oder andere Formen von Benutzereingabe- und Ausgabegeräten umfassen. Die Komponenten der Benutzerschnittstelle können mit dem Prozessor 805 kommunikativ verbunden sein. Handelt es sich bei dem Ausgabegerät um ein Display oder umfasst es ein solches, so kann das Display auf verschiedene Weise implementiert werden, z. B. durch ein Flüssigkristalldisplay (LCD) oder eine Kathodenstrahlröhre (CRT) oder eine Leuchtdiodenanzeige (LED), wie z. B. eine OLED-Anzeige (Organic Light Emitting Diode). Gewöhnliche Fachleute wissen, dass die Rechenvorrichtung 800 weitere, in der Technik wohlbekannte Komponenten umfassen kann, wie z. B. Sensoren, Stromquellen und/oder Analog-Digital-Wandler, die in 8 nicht explizit dargestellt sind.
-
In dieser Beschreibung und den Ansprüchen werden bestimmte Begriffe verwendet, die sich auf bestimmte Systemkomponenten beziehen. Wie der Fachmann weiß, können sich verschiedene Parteien auf eine Komponente mit unterschiedlichen Namen beziehen. In diesem Dokument wird nicht beabsichtigt, zwischen Komponenten zu unterscheiden, die sich zwar im Namen, nicht aber in der Funktion unterscheiden. In dieser Offenbarung und in den Ansprüchen werden die Begriffe „einschließlich“ und „umfassend“ in einer offenen Weise verwendet und sollten daher so interpretiert werden, dass sie „einschließlich, aber nicht beschränkt auf” bedeuten. Wenn also ein erstes Gerät mit einem zweiten Gerät gekoppelt wird, kann diese Verbindung durch eine direkte Verbindung oder durch eine indirekte Verbindung über andere Geräte und Verbindungen erfolgen. Die Formulierung „basiert auf“ soll bedeuten „basiert zumindest teilweise auf“. „Wenn also X auf Y basiert, kann X eine Funktion von Y und einer beliebigen Anzahl anderer Faktoren sein.
-
Die obige Erörterung dient der Veranschaulichung der Grundsätze und verschiedenen Ausführungsformen der vorliegenden Offenbarung. Zahlreiche Variationen und Modifikationen werden für den Fachmann offensichtlich, sobald die obige Offenbarung vollständig verstanden ist. Es ist beabsichtigt, dass die folgenden Ansprüche so ausgelegt werden, dass sie alle derartigen Variationen und Modifikationen einschließen.
