DE102021103080B4 - Data center troubleshooting-mechanismus - Google Patents

Data center troubleshooting-mechanismus Download PDF

Info

Publication number
DE102021103080B4
DE102021103080B4 DE102021103080.3A DE102021103080A DE102021103080B4 DE 102021103080 B4 DE102021103080 B4 DE 102021103080B4 DE 102021103080 A DE102021103080 A DE 102021103080A DE 102021103080 B4 DE102021103080 B4 DE 102021103080B4
Authority
DE
Germany
Prior art keywords
hardware device
port
troubleshooting
interface
status
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102021103080.3A
Other languages
English (en)
Other versions
DE102021103080A1 (de
Inventor
Anuradha Bose
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102021103080A1 publication Critical patent/DE102021103080A1/de
Application granted granted Critical
Publication of DE102021103080B4 publication Critical patent/DE102021103080B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45508Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
    • G06F9/45512Command shells
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0876Aspects of the degree of configuration automation
    • H04L41/0883Semiautomatic configuration, e.g. proposals from system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/06Generation of reports
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/06Generation of reports
    • H04L43/065Generation of reports related to network devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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 (20)

  1. 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.
  2. 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.
  3. 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.
  4. System nach Anspruch 3, wobei die Fehlerbehebung ferner das Bestimmen eines Status der Schnittstelle vom Switchport-Nachbarn umfasst.
  5. 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.
  6. System nach Anspruch 5, wobei die Fehlerbehebung ferner das Erzeugen einer Warnung umfasst, um anzuzeigen, dass das Problem an der Hardwarevorrichtung erkannt wurde.
  7. System nach Anspruch 6, wobei die Anweisungen, wenn sie ausgeführt werden, den Prozessor veranlassen, den Bericht weiter zu übertragen.
  8. System nach Anspruch 1, wobei das Durchführen der Fehlerbehebung ferner das Abrufen von Konfigurationsinformationen umfasst, die mit dem Hardwaregerät verbunden sind.
  9. System nach Anspruch 8, wobei der Ping-Test durchgeführt wird, um zu bestimmen, ob der Port Netzwerkverkehr weiterleitet.
  10. 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.
  11. 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.
  12. 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.
  13. Verfahren nach Anspruch 12, wobei die Fehlerbehebung ferner das Bestimmen eines Status der Schnittstelle vom Switchport-Nachbarn umfasst.
  14. 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.
  15. Verfahren nach Anspruch 14, wobei die Fehlerbehebung ferner das Erzeugen eines Alarms umfasst, um anzuzeigen, dass das Problem an der Hardwarevorrichtung erkannt wurde.
  16. 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.
  17. 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.
  18. 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.
  19. Nicht-transitorisches maschinenlesbares Medium nach Anspruch 18, wobei die Fehlerbehebung ferner das Bestimmen eines Status der Schnittstelle vom Switchport-Nachbarn umfasst.
  20. 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.
DE102021103080.3A 2020-02-19 2021-02-10 Data center troubleshooting-mechanismus Active DE102021103080B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/795,309 2020-02-19
US16/795,309 US11336552B2 (en) 2020-02-19 2020-02-19 Data center troubleshooting mechanism

Publications (2)

Publication Number Publication Date
DE102021103080A1 DE102021103080A1 (de) 2021-08-19
DE102021103080B4 true DE102021103080B4 (de) 2024-05-08

Family

ID=77061031

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021103080.3A Active DE102021103080B4 (de) 2020-02-19 2021-02-10 Data center troubleshooting-mechanismus

Country Status (3)

Country Link
US (1) US11336552B2 (de)
CN (1) CN113285822B (de)
DE (1) DE102021103080B4 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111585845B (zh) * 2020-05-15 2021-08-31 苏州浪潮智能科技有限公司 一种网卡节点性能的检测方法、装置、设备及可读介质
US20220078086A1 (en) * 2020-09-04 2022-03-10 Dell Products, L.P. Systems and methods for datacenter capacity planning
US20220393942A1 (en) * 2021-04-26 2022-12-08 NetBrain Technologies, Inc. Network intent management and automation
CN114244700B (zh) * 2021-12-17 2024-03-22 中国工商银行股份有限公司 端口处理方法及装置、电子设备和计算机可读存储介质
US11729063B1 (en) 2022-01-20 2023-08-15 Nvidia Corporation Visually guided topology wiring
US11582297B1 (en) * 2022-01-20 2023-02-14 Nvidia Corporation Mechanism to identify link down reasons

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180176101A1 (en) 2016-12-20 2018-06-21 Brocade Communications Systems, Inc. Network access device for facilitating the troubleshooting of network connectivity problems
US10797792B1 (en) 2018-12-12 2020-10-06 Amazon Technologies, Inc. Distributed network diagnostics

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7284165B2 (en) 2004-06-15 2007-10-16 International Business Machines Corporation Computer generated documentation including diagram of computer system
US8040835B2 (en) * 2006-02-17 2011-10-18 Cisco Technology, Inc. Troubleshooting link and protocol in a wireless network
US8107381B2 (en) 2007-11-27 2012-01-31 At&T Intellectual Property I, Lp Method of performing ethernet gateway switch trouble diagnostics
US7903569B2 (en) * 2008-11-25 2011-03-08 At&T Intellectual Property I, L.P. Diagnosing network problems in an IPV6 dual stack network
JP5836042B2 (ja) 2011-10-04 2015-12-24 株式会社日立製作所 管理サーバプログラム
WO2014094821A1 (en) 2012-12-17 2014-06-26 Abb Technology Ag Method for automatically deploying a network-device configuration
US9350632B2 (en) * 2013-09-23 2016-05-24 Intel Corporation Detection and handling of virtual network appliance failures
US9467330B2 (en) * 2013-10-14 2016-10-11 Hewlett Packard Enterprise Development Lp Diagnosing connectivity in a network
US10489232B1 (en) * 2015-09-29 2019-11-26 Amazon Technologies, Inc. Data center diagnostic information
US10225149B2 (en) * 2015-12-15 2019-03-05 Nicira, Inc. Method and tool for diagnosing logical networks
US10833951B2 (en) * 2018-11-06 2020-11-10 Telefonaktiebolaget Lm Ericsson (Publ) System and method for providing intelligent diagnostic support for cloud-based infrastructure

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180176101A1 (en) 2016-12-20 2018-06-21 Brocade Communications Systems, Inc. Network access device for facilitating the troubleshooting of network connectivity problems
US10797792B1 (en) 2018-12-12 2020-10-06 Amazon Technologies, Inc. Distributed network diagnostics

Also Published As

Publication number Publication date
CN113285822A (zh) 2021-08-20
US20210258238A1 (en) 2021-08-19
US11336552B2 (en) 2022-05-17
CN113285822B (zh) 2022-12-27
DE102021103080A1 (de) 2021-08-19

Similar Documents

Publication Publication Date Title
DE102021103080B4 (de) Data center troubleshooting-mechanismus
DE102012210914B4 (de) Switch-Fabric-Management
DE112011101705B4 (de) Migrieren virtueller Maschinen zwischen vernetzten Servern nach Erkennung der Verschlechterung der Funktion der Netzwerkverbindung
DE10124514A1 (de) Fehlertolerante, gemeinsam genutzte Systemressource mit einem Hochverfügbarkeitskommunikationen bereitstellenden Kommunikationsdurchgang
DE10124482B4 (de) Fehlertolerante Systemressource mit niedriger Latenzzeit, mit übergeordneter Protokollierung von Systemressourcentransaktionen und serverübergreifend gespiegelter Protokollierung von übergeordneten Systemressourcentransaktionen
DE112011100822B4 (de) Aufrechterhalten der Durchlässigkeit eines Datenübertragungspfades in einem Datenspeichernetzwerk
DE10014448B4 (de) Speicherverwaltungssystem
DE112013002014B4 (de) Bereitstellen von anwendungsgestützter Überwachung und Wiederherstellung für einen Hypervisor eines HA-Clusters
DE60024260T2 (de) Eingrenzung von netzwerkfehlern
DE102012210582B4 (de) Verringern der Auswirkung des Ausfalls einer Vermittlungsstelle in einem Schaltnetzwerk mittels Schaltkarten
DE102014108249A1 (de) Realisieren erweiterter Fehlerbehandlung für einen gemeinsam genutzten Adapter in einem virtualisierten System
DE10393571T5 (de) Verfahren und System zum Validieren logischer End-to-End-Zugriffspfade in Storage Area Netzwerken
DE112019000143T5 (de) Versionierungsvalidierung für die datenübertragung zwischen heterogenen datenspeichern
DE112011102443T5 (de) Server-Verwaltung unter Verwendung eines Baseboard Management Controllers zum Aufbau eines Drahtlosnetzwerks
DE112012001753T5 (de) Anmeldesequenz für eine Fibre-Channel-Weiterleiterstruktur
DE102021109231A1 (de) Bedienungssystem installation mechanismus
DE10220886A1 (de) Datenspeichersysteme mit verbesserten Netzwerkschnittstellen
DE102014114108A1 (de) Prozessleitsysteme und -verfahren
DE112013006634T5 (de) Computersystem und Computersystemsteuerverfahren
DE102021107655A1 (de) Protokollverwaltung für ein mehrknotendatenverarbeitungssystem
DE102022126239A1 (de) Fernverwaltung eines switch-stacks
CN105224441A (zh) 虚拟机信息采集装置、方法及虚拟机信息维护方法和系统
DE102020101084A1 (de) Verbesserte sicherheit für mehrknoten-rechenplattform
US20160203159A1 (en) Generating Snapshot of an Integration Environment to Facilitate Replication of the Environment
AT512665B1 (de) Verfahren und Apparat zur Bildung von Software Fault Containment Units in einem verteilten Echtzeitsystem

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000

R012 Request for examination validly filed
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TEX., US

R016 Response to examination communication
R018 Grant decision by examination section/examining division