DE102021103080B4

DE102021103080B4 - Data center troubleshooting-mechanismus

Info

Publication number: DE102021103080B4
Application number: DE102021103080.3A
Authority: DE
Inventors: Anuradha Bose
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-02-19
Filing date: 2021-02-10
Publication date: 2024-05-08
Anticipated expiration: 2041-02-11
Also published as: US20210258238A1; CN113285822A; CN113285822B; DE102021103080A1; US11336552B2

Abstract

Ein System zur Erleichterung der Fehlerbehebung bei einer Hardware-Vorrichtung in einer Netzwerk-Schaltstruktur, umfassend:einen Prozessor; undein nicht-transitorisches maschinenlesbares Medium, das Befehle speichert, die, wenn sie ausgeführt werden, den Prozessor veranlassen, einen Fabric Manager auszuführen, um:eine Nachricht von einem Hardwaregerät empfangen, die anzeigt, dass ein Problem am Gerät erkannt wurde;eine Fehlerbehebung durchführen, um das Problem am Hardware-Gerät zu ermitteln, einschließlich:Erfassen von Snapshot-Diagnoseinformationen umfassend zumindest Details hinsichtlich einer Konfiguration einer Downlink-Schnittstelle und einem Virtual Local Area Network, VLAN, an einem Port, die direkt durch die Hardware-Vorrichtung empfangen werden, durch Zugriff eines Gerätes auf den Port das mit der Hardware-Vorrichtung über den Port verbunden ist, um einen Betriebsstatus einer Schnittstelle zu bestimmen, die mit einem Port des Hardwaregeräts und mit dem Port gekoppelten Geräten verbunden ist;Vergleichen der Snapshot-Diagnoseinformationen mit den Konfigurationsinformationen der Hardware-Vorrichtung, um einen Unterschied zwischen den Snapshot-Diagnoseinformationen und den Konfigurationsinformationen zu bestimmen, wobei die Konfigurationsinformationen Informationen über eine Abbildung von Verbindungen zu der Hardware-Vorrichtung umfassen; undDurchführen eines Ping-Tests zwischen dem Hardware-Gerät und Geräten, die mit dem Port gekoppelt sind; undeinen Bericht mit den Ergebnissen der Fehlerbehebung erstellen.

Description

HINTERGRUND
Rechenzentren bieten einen Pool von Ressourcen (z. B. Rechenleistung, Speicher, Netzwerk usw.), die über ein Kommunikationsnetzwerk miteinander verbunden sind. In modernen Netzwerkarchitekturen für Rechenzentren dient eine Netzwerk-Switching-Fabric typischerweise als Kernkomponente, die die Konnektivität zwischen den Netzwerkressourcen bereitstellt und die Optimierung der Server-zu-Server-Verbindung (z. B. Ost-West) im Rechenzentrum erleichtert. Solche Switching Fabrics können mit einer softwaredefinierten Transport Fabric implementiert werden, die ein Netzwerk von Ressourcen und Hosts über eine Vielzahl von Top of Rack Network (TOR) Fabric Switches miteinander verbindet.
Dokument US 2018 / 0 176 101 A1 beschreibt ein Netzwerkzugriffsgerät zur Fehlerbehebung von Netzwerkkonnektivitätsproblemen auf einem direkt verbundenen Clientgerät. Dabei erstellt der Client eine Support-Anfrage und das Netzwerkzugriffsgerät kann als Reaktion automatisch Diagnoseinformationen zum Client-Gerät sammeln.
Dokument US 10 797 792 B1 beschreibt ein Verfahren, wobei Informationen von optischen Modulen mit Informationen von Netzwerk-Switches kombiniert werden, um Probleme entlang eines Netzwerkkommunikationspfads zu erkennen und zu lokalisieren. Daraufhin werden Abhilfemaßnahmen automatisch ermittelt und ergriffen.
Die Erfindung wird durch den Hauptanspruch und die nebengeordneten Patentansprüche definiert. Weitere Ausführungsformen der Erfindung werden durch die abhängigen Patentansprüche wiedergegeben.
KURZBESCHREIBUNG DER ZEICHNUNGEN
In den folgenden Zeichnungen werden gleiche Referenznummern verwendet, um auf gleiche Elemente zu verweisen. Obwohl in den folgenden Figuren verschiedene Beispiele dargestellt sind, sind eine oder mehrere Implementierungen nicht auf die in den Figuren dargestellten Beispiele beschränkt.

1 zeigt eine Ausführungsform eines Systems, das ein Rechenzentrum verwendet.
2 ist ein Blockdiagramm, das eine Ausführungsform einer Netzwerk-Switching-Fabric zeigt.
3 ist ein Blockdiagramm, das eine Ausführungsform eines Fabric Managers zeigt.
4 ist ein Blockdiagramm, das eine Ausführungsform eines Fehlersuchmanagers zeigt.
5 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zur Fehlerbehebung bei einem Hardware-Gerät zeigt.
6 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zur Durchführung einer Fehlerbehebung darstellt.

DETAILLIERTE BESCHREIBUNG
Die Verbindung von Netzwerkressourcen über eine Switching-Fabric wird mithilfe von Infrastrukturverkabelung realisiert, um eine physische Verbindung von Hardwaregeräten (z. B. Server, Speicher und Switches) für die Workload-Bereitstellung eines Rechenzentrums bereitzustellen. Daher ist es für einen Fabric-Manager eines Rechenzentrums wichtig, zu erkennen, ob ein Port an einem Infrastrukturgerät (z. B. Switch, Server, Speicher usw.) ordnungsgemäß funktioniert (z. B. Datenverkehr durchlässt), sowie ein Problem zu diagnostizieren, wenn festgestellt wird, warum der Port nicht ordnungsgemäß funktioniert. Zusätzlich ist es wichtig, dass der Fabric-Manager feststellt, wie das Problem zu beheben ist. Konventionelle Fabric-Management-Systeme können erkennen, ob ein Port kommuniziert oder nicht. Solche Systeme sind jedoch nicht in der Lage, das Problem automatisch zu diagnostizieren oder zu beheben, selbst wenn dies möglich wäre. Daher muss ein Systemadministrator (oder Bediener) manuell eine Reihe von Befehlen auf verschiedenen Geräten ausführen, um die Ursache eines Problems an einem Hardwaregerät zu verstehen.
In Ausführungsformen wird ein Mechanismus bereitgestellt, der die automatische Fehlerbehebung bei Problemen innerhalb einer Switching-Fabric erleichtert. In solchen Ausführungsformen wird eine Nachricht von einem Hardwaregerät innerhalb der Fabric empfangen, die anzeigt, dass ein Problem erkannt wurde, und es werden eine oder mehrere Fehlerbehebungen durchgeführt, um das Problem am Hardwaregerät zu bestimmen. In weiteren Ausführungsformen wird ein Bericht erzeugt, der die Ergebnisse der Fehlerbehebungen enthält.
In der folgenden Beschreibung werden zu Erklärungszwecken zahlreiche spezifische Details aufgeführt, um ein umfassendes Verständnis der vorliegenden Erfindung zu ermöglichen. Dem Fachmann wird jedoch klar sein, dass die vorliegende Erfindung auch ohne einige dieser spezifischen Details ausgeführt werden kann. In anderen Fällen sind bekannte Strukturen und Vorrichtungen in Blockdiagrammform dargestellt, um die zugrundeliegenden Prinzipien der vorliegenden Erfindung nicht zu verdecken.
In diesem Dokument können Begriffe wie „Logik“, „Komponente“, „Modul“, „Engine“, „Modell“ und dergleichen austauschbar verwendet werden und umfassen beispielsweise Software, Hardware und/oder eine beliebige Kombination aus Software und Hardware, wie z. B. Firmware. Darüber hinaus ist die Verwendung einer bestimmten Marke, eines bestimmten Worts, Begriffs, Satzes, Namens und/oder Akronyms nicht so zu verstehen, dass Ausführungsformen auf Software oder Geräte beschränkt sind, die diese Bezeichnung in Produkten oder in Literatur außerhalb dieses Dokuments tragen.
In 1 ist eine Ausführungsform eines Rechenzentrums 100 dargestellt. Wie in 1 dargestellt, umfasst das Rechenzentrum 100 ein oder mehrere Rechengeräte 101, die Servercomputer sein können, die als Host für das Rechenzentrum 100 dienen. In Ausführungsformen kann die Rechenvorrichtung 101 (ohne Einschränkung) Servercomputer (z. B. Cloud-Server-Computer usw.), Desktop-Computer, clusterbasierte Computer, Set-Top-Boxen (z. B. internetbasierte Kabelfernseh-Set-Top-Boxen usw.) usw. umfassen. Das Computergerät 101 enthält ein Betriebssystem („OS“) 106, das als Schnittstelle zwischen einer oder mehreren Hardware-/physikalischen Ressourcen des Computergeräts 101 und einem oder mehreren Client-Geräten (nicht dargestellt) dient. Das Computergerät 101 umfasst ferner Prozessor(en) 102, Speicher 104, Eingabe-/Ausgabequellen 108, wie z. B. Touchscreens, Touchpanels, Touchpads, virtuelle oder reguläre Tastaturen, virtuelle oder reguläre Mäuse usw.
In einer Ausführungsform umfasst das Computergerät 101 einen Servercomputer, der außerdem mit einer oder mehreren Datenbanken oder Speicherplätzen kommunizieren kann, die sich lokal oder entfernt über ein oder mehrere Netzwerke (z. B. Cloud-Netzwerk, Internet, Proximity-Netzwerk, Intranet, Internet der Dinge („IoT“), Cloud of Things („CoT“) usw.) befinden können. Das Computergerät 101 kann über ein oder mehrere Netzwerke mit einer beliebigen Anzahl und Art von anderen Computergeräten in Verbindung stehen.
Gemäß einer Ausführungsform implementiert das Computergerät 101 eine Virtualisierungsinfrastruktur 110, um die Virtualisierung einer Vielzahl von Host-Ressourcen (oder Virtualisierungshosts) im Rechenzentrum 100 bereitzustellen. In einer Ausführungsform wird die Virtualisierungsinfrastruktur 110 über eine virtualisierte Rechenzentrumsplattform (einschließlich z. B. eines Hypervisors) implementiert, wie z. B. VMware vSphere oder eine Linux-Kernel-basierte virtuelle Maschine. Andere Ausführungsformen können jedoch andere Arten von virtualisierten Rechenzentrumsplattformen implementieren. Das Computergerät 101 ermöglicht auch den Betrieb einer Netzwerk-Switching-Fabric. In einer Ausführungsform ist die Netzwerk-Switching-Fabric eine softwaredefinierte Transport-Fabric, die Konnektivität zwischen den Host-Ressourcen innerhalb der Virtualisierungsinfrastruktur 110 bereitstellt.
2 ist ein Blockdiagramm, das eine Ausführungsform einer Netzwerk-Switching-Fabric (oder Fabric) 200 zeigt. Wie in 2 dargestellt, umfasst die Fabric 200 eine Vielzahl von Top-of-Rack-Switches 250 (z. B. 250A und 250B), die mit virtualisierten Hosts 230 innerhalb der Virtualisierungsinfrastruktur 110 gekoppelt sind. Bei den TOR-Switches 250 handelt es sich um Netzwerk-Switches, die Operationen, einschließlich Layer-2- und Layer-3-Frame- und Paketweiterleitung und Überbrückung des Rechenzentrums 100, verarbeiten.
In einer Ausführungsform kann ein Virtualisierungshost 230 Switching-Ressourcen bereitstellen. In einer solchen Ausführungsform kann ein TOR-Switch 250 über eine oder mehrere virtuelle Netzwerkschnittstellenkarten (VNICs) 234 mit einem oder mehreren virtuellen Switches gekoppelt sein. Zum Beispiel kann der TOR-Switch 250A über VNICs 234A innerhalb des Hosts 230A mit virtuellen Switches 231 gekoppelt sein. In einer solchen Ausführungsform können ein TOR-Switch 250 und ein Switch-Virtualisierungs-Host 230A eine Vielzahl von physischen Switching-Ports enthalten.
In einer weiteren Ausführungsform kann jeder Switch-Port mit einem benachbarten Gerät gekoppelt sein (z. B. Switch-Port-Nachbarn). Ein TOR-Switch 250 kann auch mit einem oder mehreren Servern innerhalb eines Hosts 230 über VNICs 234 gekoppelt sein. Zum Beispiel kann der TOR-Switch 250B über VNICs 234B mit virtuellen Servern 233 innerhalb des Hosts 230B gekoppelt sein. In einer Ausführungsform können ein oder mehrere virtuelle Server (oder Recheneinheiten) 232 auf Host 230B mit virtuellen Switches 231 auf Host 230A gekoppelt sein. Somit können ein oder mehrere physische Geräte am Host 230B Switch-Port-Nachbarn mit Switch-Ports am Host 230A sein.
Zurück zu 1: Ein Fabric-Manager 140 ist in der Recheneinheit enthalten, um das Fabric 200 zu verwalten. 3 ist ein Blockdiagramm, das eine Ausführungsform des Fabric-Managers 140 zeigt. Wie in 3 gezeigt, umfasst der Fabric-Manager 140 eine Schnittstelle 310, die für die Kommunikation mit der Virtualisierungsinfrastruktur 110 bezüglich der Virtualisierungshosts 230 konfiguriert ist. In einer Ausführungsform ist die Schnittstelle 310 als Representational State Transfer (REST)-Anwendungsprogrammschnittstelle (API) für den Fabric-Manager 140 implementiert. Der Fabric-Manager 140 umfasst auch einen Topologie-Manager 330 zur Verwaltung der Topologie der Netzwerk-Switching-Fabric 200.
Gemäß einer Ausführungsform führt der Topologiemanager 330 eine Topologieanalyse der Switching Fabric 200 durch. In einer solchen Ausführungsform verwaltet der Topologie-Manager 330 Konfigurationsinformationen für die Fabric 200, die eine Abbildung der Geräteverbindungen innerhalb der Fabric 200 darstellen. Die Konfigurationsinformationen können beispielsweise Informationen zu allen physischen Verbindungen zwischen Virtualisierungshosts 230 sowie den in 2 gezeigten TOR-Switches 250 enthalten. In einer weiteren Ausführungsform werden die Konfigurationsinformationen jedes Mal erzeugt, wenn eine neue Verbindung in der Fabric 200 bereitgestellt wird, und in der Datenbank 360 gespeichert.
Der Topologiemanager 330 umfasst einen Fehlerbehebungsmanager 334, der implementiert ist, um einen oder mehrere Fehlerbehebungen durchzuführen, um ein Problem zu erkennen, das sich auf den Gesundheitszustand der Switching Fabric 200 auswirken kann, sowie einen Berichtsgenerator 336, der einen Bericht mit den Ergebnissen der Fehlerbehebungsanalyse erstellt. Beispielsweise kann der Fehlerbehebungsmanager 334 eine Nachricht von einem Switch empfangen, die anzeigt, dass ein Problem mit den Portzählern am Switch vorliegt oder dass ein Verbindungsstatus ausgefallen ist. Als Reaktion darauf führt der Fehlerbehebungs-Manager 334 eine Analyse der Switch-Port-Verbindungen durch, um festzustellen, ob ein Problem vorliegt und welche Art von Problem vorliegt, wenn festgestellt wird, dass ein Problem vorliegt.
4 ist ein Blockdiagramm, das eine Ausführungsform des Fehlerbehebungsmanagers 334 veranschaulicht, einschließlich eines Alarmgenerators 410, einer Statuserfassungs-Engine 420 und eines Statusrechners 430. Der Alarmgenerator 410 erzeugt und sendet einen Alarm, wenn ein Problem vom Topologiemanager 330 erkannt wird. Wie oben beschrieben, kann ein Problem durch den Empfang einer Switch-Meldung erkannt werden, die anzeigt, dass ein Verbindungsproblem vorliegt. In einer Ausführungsform wird der Alarm an eine Benutzerschnittstelle 350 im Fabric Manager 140 übertragen, um einen Rechenzentrumsadministrator (oder -betreiber) zu alarmieren.
Sobald die Warnung generiert wurde, analysiert die Statuserfassungs-Engine 420 einen oder mehrere Switch-Ports, die mit dem erkannten Problem verbunden sind, und erfasst Diagnosedaten (oder Snapshot-Diagnoseinformationen), die mit dem Hardware-Port und einem oder mehreren Switch-Port-Nachbargeräten verbunden sind, die mit dem Hardware-Gerät über den Port verbunden sind. Gemäß einer Ausführungsform umfassen die vom Hardware-Port erfassten Snapshot-Diagnoseinformationen Details bezüglich einer Downlink-Schnittstelle und eines auf dem Port konfigurierten VLANs, die direkt vom Hardware-Gerät empfangen werden. In einer solchen Ausführungsform werden die Snapshot-Diagnoseinformationen durch Ausführen von hardwarespezifischen Befehlszeilenschnittstellen (CLIs) erfasst, die Details zum Verbindungsstatus des Ports, zum Aktivierungs-/Deaktivierungsstatus sowie zu allen anderen Codes liefern, die mit der jeweiligen Schnittstelle verbunden sind. Für Link-Aggregation-Group (LAG)-Schnittstellen werden Informationen zu den zugehörigen Lagged-Ports, den zugehörigen Schnittstellen und dem Up- oder Down-Status bereitgestellt.
In einer weiteren Ausführungsform werden die Snapshot-Diagnoseinformationen durch Ermitteln des Switchport-Nachbarn (z. B. des Servers) erfasst, der mit der Hardware-Port-Konfiguration verbunden ist. In einer solchen Ausführungsform werden diese Informationen aus der Datenbank 360 abgerufen und umfassen das Betriebssystem, die Firmware-Version, Details zum Energiestatus usw. Sobald diese Informationen abgerufen sind, greift die Statuserfassungs-Engine 420 über eine dem Switchport-Nachbarn zugeordnete Fernverwaltungskonsole auf den Switchport-Nachbarn zu (meldet sich z. B. an) und erfasst eine Ethernet-Schnittstelle für das zugeordnete VLAN über eine MAC-Adresse (Media Access Control). In einer Ausführungsform wird die MAC-Adresse des Switchport-Nachbarn aus der Datenbank 360 abgerufen. In anderen Ausführungsformen wird die MAC-Adresse des Switchport-Nachbarn jedoch aus MAC-Tabellen abgerufen, die in einem TOR-Switch 250 gespeichert sind.

Nach der Anmeldung beim Switchport-Nachbarn sammelt die Statuserfassungs-Engine 420 den Betriebsstatus der Schnittstelle (z. B. „up“ oder „down“). In einer Ausführungsform zeigt der Betriebsstatus an, ob Netzwerkverkehr zwischen einem Geräteport und einem Switchport-Nachbarn übertragen wird (z. B. Verkehr funktioniert oder funktioniert nicht). Wenn festgestellt wird, dass der Betriebsstatus der Schnittstelle „down“ ist, sendet die Statuserfassungs-Engine 420 einen Befehl, um den Status zu erhöhen (z. B. „activate“), um den Status zu beheben. Wenn der Status jedoch weiterhin als „down“ angezeigt wird, werden die Daten anschließend in den Bericht aufgenommen. Tabelle 1 enthält eine Ausführungsform von Statusinformationen, die in einen Bericht aufgenommen werden können. Tabelle 1

Fehlerbedingung	Unterbedingung	Hinweis	Aktion
Verkehr funktioniert nicht	Konfigurationsproblem, vlan ist nicht auf dem Switch bereitgestellt	Sammeln Sie Diagnosedaten aus der Fabric Manager-Datenbank und stellen Sie fest, dass die vlan-Konfiguration vorhanden ist.	Senden Sie die Aufgabe erneut, um diese VLAN-Konfiguration auf den Switch zu übertragen.
	Downlink-Schnittstelle am Switch ausgefallen	Sammeln Sie die Daten wie oben beschrieben vom Switch und dem Server	Dem Anwender präsentieren
Der Datenverkehr funktioniert, aber der Alert-Manager zeigt den Alarm an. (Problem mit Alert Reporting)	Prüfen Sie, ob die Downlink-Schnittstelle am Switch aktiv ist. Wenn ja, führen Sie den Ping-Test durch. Wenn der Ping-Test erfolgreich ist, berechnen Sie den Status des Ports (Up oder Down) neu.	Sollte in der Lage sein, den Gesundheitsstatus der Verbindung neu zu berechnen. Die Schalterkonfiguration muss nicht berührt werden.	Fabric Manager berechnet den PortStatus neu und der Alarm-Manager ergreift die Maßnahme, um falsche Alarme zu löschen.

In einer weiteren Ausführungsform ruft die Statuserfassungs-Engine 420 die mit der Switch-Hardware verbundenen Konfigurationsinformationen aus der Datenbank 360 ab. In dieser Ausführungsform vergleicht der Statusrechner 430 die aktuellen Snapshot-Diagnoseinformationen mit den abgerufenen Konfigurationsinformationen, um einen Unterschied zwischen den Snapshot-Diagnoseinformationen und den Konfigurationsinformationen zu ermitteln.
In einer weiteren Ausführungsform führt die Statuserfassungs-Engine 420 einen Ping-Test zwischen dem Server und dem Switch durch. In einer solchen Ausführungsform wird der Ping-Test durchgeführt, wenn der Server eingeschaltet ist und eine Downlink-Schnittstelle auf dem Server aktiv ist. Zu diesem Zeitpunkt besteht das Ziel des Ping-Tests darin, zu überprüfen, ob der Anschluss den Netzwerkverkehr durchlässt oder ob das Problem mit der Statusmeldung vom Switch oder von der Verwaltungssoftware selbst stammt.
In einer weiteren Ausführungsform kann der Ping-Test zwischen einer Downlink-Schnittstelle auf dem Server und einem TOR-Switch 250 oder einem mit dem TOR-Switch 250 verbundenen Server durchgeführt werden. Da die Ethernet-Schnittstelle aus den Diagnosedaten bekannt ist, kann z. B. die Internetprotokoll (IP)-Adresse der Ethernet-Netzwerkschnittstelle auf dem Server ermittelt werden (z. B. über Betriebssystembefehle/-tools). In ähnlicher Weise können CLI-Befehle auf einem TOR-Switch 250 ausgeführt werden, um Details über die TOR-Switch-Konfiguration für die zugehörige Port-Schnittstelle abzurufen, was die IP-Adresse der Uplink-Schnittstelle auf dem TOR-Switch 250 für dasselbe VLAN liefert.
Anschließend kann ein Ping-Befehl zwischen der IP-Adresse der Server-Schnittstelle und der IP-Adresse der Schnittstelle am TOR-Switch 250 ausgeführt werden. Wenn festgestellt wird, dass der Ping-Test erfolgreich war, werden die Downlink-Schnittstelleninformationen und die TOR-Konfiguration in den Snapshot-Diagnoseinformationen gemeldet und der Fabric Manager 140 wird automatisch mit den aktualisierten Portstatus benachrichtigt, um den Hardwarestatus genau zu melden. Anschließend löscht der Alarmgenerator 410 den Alarm und der Erfolg wird im Bericht gekennzeichnet. Wenn festgestellt wird, dass der Ping-Test fehlschlägt (z. B. die beiden IPs können sich nicht gegenseitig anpingen), wird der Fehler in den Bericht aufgenommen, damit manuell eingegriffen werden kann, um Probleme mit der manuellen Konfiguration zu korrigieren.
Wenn die Fehlerbehebung abgeschlossen ist, erstellt der Berichtsgenerator 336 (3) einen Bericht über die Ergebnisse der Fehlerbehebung. In einer Ausführungsform überträgt der Berichtsgenerator 336 den Bericht an die Benutzeroberfläche 350. In dieser Ausführungsform kann der Bericht die Snapshot-Diagnoseinformationen (z. B. Port-Verbindungsstatus, Stromversorgungsstatus usw.) und/oder alle ermittelten Unterschiede zwischen den Snapshot-Diagnoseinformationen und den Konfigurationsinformationen für den Switch enthalten. In anderen Ausführungsformen kann der Bericht als Textdatei oder Tabelle generiert werden. In einer weiteren Ausführungsform kann der Berichtsgenerator 336 eine VLAN- und Lag-Konfiguration für einen Anschluss melden und wenn diese nicht übereinstimmen.
In einer solchen Ausführungsform kann die VLAN-Konfiguration automatisch neu bereitgestellt werden, um das erkannte Problem zu beheben. Die automatische Neuverteilung erfolgt durch das Übermitteln einer Konfigurationsaufgabe oder eines Befehls, um die VLAN-Konfiguration mit den Port-Informationen an den Hardware-Switch zu übertragen. In einer weiteren Ausführungsform kann der Erfolg gekennzeichnet werden, sobald das ursprüngliche Problem behoben ist.
5 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zur Fehlerbehebung bei einem Hardware-Gerät innerhalb einer Netzwerk-Switching-Fabric veranschaulicht. Im Verarbeitungsblock 510 wird eine Nachricht von einem Hardwaregerät (z. B. einem Switch) empfangen. Wie oben erwähnt, kann die Nachricht anzeigen, dass ein Problem an einem oder mehreren Ports des Hardwaregeräts erkannt wurde. Im Verarbeitungsblock 520 wird eine Fehlerbehebung durchgeführt. 6 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zur Durchführung einer Fehlerbehebung zeigt.
Im Verarbeitungsblock 610 wird beim Empfang der Nachricht vom Gerät ein Alarm erzeugt und zur Anzeige auf einer Benutzeroberfläche übertragen. Im Verarbeitungsblock 620 werden Snapshot-Diagnoseinformationen, die dem Gerät zugeordnet sind, erfasst. Wie oben beschrieben, enthalten die Snapshot-Informationen Informationen, die mit einem Hardware-Switchport verbunden sind, sowie Informationen, die mit Geräten verbunden sind, die mit diesem Switchport verbunden sind. Im Verarbeitungsblock 630 werden die Konfigurationsinformationen für das Hardware-Gerät abgerufen. Im Verarbeitungsblock 640 werden die Snapshot-Diagnoseinformationen und die Konfigurationsinformationen verglichen, um festzustellen, ob es einen Unterschied gibt. In einer Ausführungsform zeigt ein Unterschied zwischen den Snapshot-Diagnoseinformationen und den Konfigurationsinformationen an, dass eine Änderung am Switch-Port stattgefunden hat.
Zurück zu 5: Nach Abschluss der Fehlerbehebung wird im Verarbeitungsblock 560 ein Bericht erstellt. Wie oben beschrieben, enthält der Bericht die Diagnoseinformationen und/oder alle festgestellten Unterschiede zwischen den Ergebnissen der Snapshot-Diagnoseinformationen und den Konfigurationsinformationen. Im Verarbeitungsblock 570 wird der Bericht an die Benutzeroberfläche übertragen.
Ausführungsformen können als eine beliebige oder eine Kombination aus einem oder mehreren Mikrochips oder integrierten Schaltkreisen, die über eine Hauptplatine miteinander verbunden sind, festverdrahteter Logik, in einem Speichergerät gespeicherter und von einem Mikroprozessor ausgeführter Software, Firmware, einem anwendungsspezifischen integrierten Schaltkreis (ASIC) und/oder einem feldprogrammierbaren Gate-Array (FPGA) implementiert werden. Der Begriff „Logik“ kann z. B. Software oder Hardware und/oder Kombinationen aus Software und Hardware umfassen.
Ausführungsformen können z. B. als Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Befehlen enthalten kann, die bei Ausführung durch eine oder mehrere Maschinen, wie z. B. einen Computer, ein Computernetzwerk oder andere elektronische Geräte, dazu führen können, dass die eine oder die mehreren Maschinen Vorgänge in Übereinstimmung mit den hier beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann Disketten, optische Platten, CD-ROMs (Compact Disc-Read Only Memories) und magnetooptische Platten, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Speicher oder andere Arten von Medien/Maschinen-lesbaren Medien umfassen, die zum Speichern von maschinenausführbaren Befehlen geeignet sind, ist aber nicht darauf beschränkt.
Darüber hinaus können Ausführungsformen als Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) zu einem anfordernden Computer (z. B. einem Client) mittels eines oder mehrerer Datensignale, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium verkörpert und/oder durch diese moduliert sind, über eine Kommunikationsverbindung (z. B. ein Modem und/oder eine Netzwerkverbindung) übertragen werden kann.
Die Zeichnungen und die vorangegangene Beschreibung geben Beispiele für Ausführungsformen. Der Fachmann wird verstehen, dass eines oder mehrere der beschriebenen Elemente durchaus zu einem einzigen Funktionselement kombiniert werden können. Alternativ dazu können bestimmte Elemente in mehrere Funktionselemente aufgeteilt werden. Elemente aus einer Ausführungsform können einer anderen Ausführungsform hinzugefügt werden. Die Reihenfolge der hier beschriebenen Prozesse kann beispielsweise geändert werden und ist nicht auf die hier beschriebene Weise beschränkt. Darüber hinaus müssen die Aktionen in einem Flussdiagramm nicht in der gezeigten Reihenfolge ausgeführt werden; auch müssen nicht unbedingt alle Handlungen ausgeführt werden. Auch können diejenigen Handlungen, die nicht von anderen Handlungen abhängig sind, parallel zu den anderen Handlungen ausgeführt werden. Der Umfang der Ausführungsformen ist durch diese spezifischen Beispiele keineswegs begrenzt. Zahlreiche Variationen, ob explizit in der Spezifikation angegeben oder nicht, wie z. B. Unterschiede in der Struktur, den Abmessungen und der Verwendung von Material, sind möglich. Der Umfang der Ausführungsformen ist mindestens so breit, wie er durch die folgenden Ansprüche gegeben ist.

Claims

Ein System zur Erleichterung der Fehlerbehebung bei einer Hardware-Vorrichtung in einer Netzwerk-Schaltstruktur, umfassend: einen Prozessor; und ein nicht-transitorisches maschinenlesbares Medium, das Befehle speichert, die, wenn sie ausgeführt werden, den Prozessor veranlassen, einen Fabric Manager auszuführen, um: eine Nachricht von einem Hardwaregerät empfangen, die anzeigt, dass ein Problem am Gerät erkannt wurde; eine Fehlerbehebung durchführen, um das Problem am Hardware-Gerät zu ermitteln, einschließlich: Erfassen von Snapshot-Diagnoseinformationen umfassend zumindest Details hinsichtlich einer Konfiguration einer Downlink-Schnittstelle und einem Virtual Local Area Network, VLAN, an einem Port, die direkt durch die Hardware-Vorrichtung empfangen werden, durch Zugriff eines Gerätes auf den Port das mit der Hardware-Vorrichtung über den Port verbunden ist, um einen Betriebsstatus einer Schnittstelle zu bestimmen, die mit einem Port des Hardwaregeräts und mit dem Port gekoppelten Geräten verbunden ist; Vergleichen der Snapshot-Diagnoseinformationen mit den Konfigurationsinformationen der Hardware-Vorrichtung, um einen Unterschied zwischen den Snapshot-Diagnoseinformationen und den Konfigurationsinformationen zu bestimmen, wobei die Konfigurationsinformationen Informationen über eine Abbildung von Verbindungen zu der Hardware-Vorrichtung umfassen; und Durchführen eines Ping-Tests zwischen dem Hardware-Gerät und Geräten, die mit dem Port gekoppelt sind; und einen Bericht mit den Ergebnissen der Fehlerbehebung erstellen.
System nach Anspruch 1, wobei die Diagnoseinformationen durch Ausführen einer Befehlszeilenschnittstelle an der Hardware-Vorrichtung erfasst werden, um einen Status des Ports zu erhalten.
System nach Anspruch 2, wobei die Diagnoseinformationen durch Bestimmen eines dem Port zugeordneten Switchport-Nachbarn und Zugreifen auf den Switchport-Nachbarn zum Erfassen einer Schnittstelle erfasst werden.
System nach Anspruch 3, wobei die Fehlerbehebung ferner das Bestimmen eines Status der Schnittstelle vom Switchport-Nachbarn umfasst.
System nach Anspruch 4, wobei die Fehlerbehebung ferner das Senden eines Befehls zum Aktivieren des Status der Schnittstelle umfasst, wenn festgestellt wird, dass die Statusschnittstelle ausgefallen ist.
System nach Anspruch 5, wobei die Fehlerbehebung ferner das Erzeugen einer Warnung umfasst, um anzuzeigen, dass das Problem an der Hardwarevorrichtung erkannt wurde.
System nach Anspruch 6, wobei die Anweisungen, wenn sie ausgeführt werden, den Prozessor veranlassen, den Bericht weiter zu übertragen.
System nach Anspruch 1, wobei das Durchführen der Fehlerbehebung ferner das Abrufen von Konfigurationsinformationen umfasst, die mit dem Hardwaregerät verbunden sind.
System nach Anspruch 8, wobei der Ping-Test durchgeführt wird, um zu bestimmen, ob der Port Netzwerkverkehr weiterleitet.
Ein Verfahren zur Erleichterung der Fehlerbehebung bei einer Hardware-Vorrichtung in einer Netzwerk-Schaltstruktur, das Folgendes umfasst: Empfang einer Nachricht von einem Hardware-Gerät, die anzeigt, dass ein Problem an dem Gerät erkannt wurde; Durchführen einer Fehlerbehebung, um das Problem an der Hardwarevorrichtung zu bestimmen, einschließlich: Erfassen von Snapshot-Diagnoseinformationen umfassend zumindest Details hinsichtlich einer Konfiguration einer Downlink-Schnittstelle und einem Virtual Local Area Network, VLAN, an einem Port, die direkt durch die Hardware-Vorrichtung empfangen werden, durch Zugriff eines Gerätes auf den Port das mit der Hardware-Vorrichtung über den Port verbunden ist, um einen Betriebsstatus einer Schnittstelle zu bestimmen, die mit einem Port des Hardwaregeräts und mit dem Port gekoppelten Geräten verbunden ist; Vergleichen der Snapshot-Diagnoseinformationen mit den Konfigurationsinformationen der Hardware-Vorrichtung, um einen Unterschied zwischen den Snapshot-Diagnoseinformationen und den Konfigurationsinformationen zu bestimmen, wobei die Konfigurationsinformationen Informationen über eine Abbildung von Verbindungen zu der Hardware-Vorrichtung umfassen; und Durchführen eines Ping-Tests zwischen dem Hardware-Gerät und Geräten, die mit dem Port gekoppelt sind; und Erzeugen eines Berichts mit den Ergebnissen der Fehlerbehebung.
Verfahren nach Anspruch 10, wobei die Diagnoseinformationen durch Ausführen einer Befehlszeilenschnittstelle an der Hardware-Vorrichtung erfasst werden, um einen Status des Ports zu erhalten.
Verfahren nach Anspruch 11, wobei das Erfassen der Diagnoseinformationen das Bestimmen eines dem Port zugeordneten Switchport-Nachbarn und den Zugriff auf den Switchport-Nachbarn zum Erfassen einer Schnittstelle umfasst.
Verfahren nach Anspruch 12, wobei die Fehlerbehebung ferner das Bestimmen eines Status der Schnittstelle vom Switchport-Nachbarn umfasst.
Verfahren nach Anspruch 13, wobei die Fehlerbehebung ferner das Übertragen eines Befehls zum Aktivieren des Status der Schnittstelle umfasst, wenn festgestellt wird, dass die Statusschnittstelle ausgefallen ist.
Verfahren nach Anspruch 14, wobei die Fehlerbehebung ferner das Erzeugen eines Alarms umfasst, um anzuzeigen, dass das Problem an der Hardwarevorrichtung erkannt wurde.
Ein nicht-transitorisches, maschinenlesbares Medium, das Befehle speichert, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen: eine Nachricht von einem Hardwaregerät empfangen, die anzeigt, dass ein Problem am Gerät erkannt wurde; eine Fehlerbehebung durchführen, um das Problem am Hardware-Gerät zu ermitteln, einschließlich: Erfassen von Snapshot-Diagnoseinformationen umfassend zumindest Details hinsichtlich einer Konfiguration einer Downlink-Schnittstelle und einem Virtual Local Area Network, VLAN, an einem Port, die direkt durch die Hardware-Vorrichtung empfangen werden, durch Zugriff eines Gerätes auf den Port das mit der Hardware-Vorrichtung über den Port verbunden ist, um einen Betriebsstatus einer Schnittstelle zu bestimmen, die mit einem Port des Hardwaregeräts und mit dem Port gekoppelten Geräten verbunden ist; Vergleichen der Snapshot-Diagnoseinformationen mit den Konfigurationsinformationen der Hardware-Vorrichtung, um einen Unterschied zwischen den Snapshot-Diagnoseinformationen und den Konfigurationsinformationen zu bestimmen, wobei die Konfigurationsinformationen Informationen über eine Abbildung von Verbindungen zu der Hardware-Vorrichtung umfassen; und Durchführen eines Ping-Tests zwischen dem Hardware-Gerät und Geräten, die mit dem Port gekoppelt sind; und einen Bericht mit den Ergebnissen der Fehlerbehebung erstellen.
Nicht-transitorisches maschinenlesbares Medium nach Anspruch 16, wobei die Diagnoseinformationen durch Ausführen einer Befehlszeilenschnittstelle an der Hardwarevorrichtung zum Empfangen eines Status des Ports erfasst werden.
Nicht-transitorisches maschinenlesbares Medium nach Anspruch 17, wobei die Diagnoseinformationen durch Bestimmen eines dem Port zugeordneten Switchport-Nachbarn und Zugreifen auf den Switchport-Nachbarn zum Erfassen einer Schnittstelle erfasst werden.
Nicht-transitorisches maschinenlesbares Medium nach Anspruch 18, wobei die Fehlerbehebung ferner das Bestimmen eines Status der Schnittstelle vom Switchport-Nachbarn umfasst.
Nicht-transitorisches maschinenlesbares Medium nach Anspruch 19, wobei die Fehlerbehebung ferner das Übertragen eines Befehls zum Aktivieren des Status der Schnittstelle umfasst, wenn festgestellt wird, dass die Statusschnittstelle ausgefallen ist.