Ein hardwarebasierter Fibre-Channel-Protokollanalysator (wie z. B. die SierraFC-Serie von LeCroy) erfasst übertragene Informationen von der physikalischen Schicht des Fibre-Channel-Netzwerks. Der Analysator befindet sich physisch im Netzwerk (im Gegensatz zu einer Software-Reassemblierungsschicht wie viele Ethernet-Analysatoren). Gut konzipierte Fibre-Channel-Analysatoren können erfasste Daten vom „nativen“ Übertragungszustand auf unterster Ebene bis hin zu den eingebetteten Protokollen der oberen Schicht überwachen und anzeigen, die für die Speicherindustrie typischerweise auf SCSI basieren.

Um das DC-Gleichgewicht und die Signalsperre für die differentiellen Empfänger aufrechtzuerhalten, wird der Fibre-Channel-Verkehr als codierte Werte, sogenannte „Symbole“, übertragen. In Fibre Channel werden zwei Codierungsschemata verwendet. Bei Datenraten bis zu 8G wird jedes 8-Bit-Byte in 10-Bit-Symbole codiert; Bei 16G-Datenraten wird jeder 64-Bit-Datenblock (8 Bytes) in ein 66-Bit-Symbol codiert, um den Overhead zu reduzieren. Ein richtig gestalteter FC-Analysator erfasst den nativen Datenverkehr und kann die tatsächlichen 10b- oder 66b-Symbole sowie die decodierten Schichten auf höherer Ebene anzeigen. Eine ausführlichere Erörterung der Probleme beim Design von Analysatoren zur Erfassung der Datenübertragung im nativen Zustand vor der Dekodierung finden Sie im Artikel „Taking Full Advantage of 8b/10b Encoding in your USB 3.0 Designs“ in der EE Times vom 9. Januar 2012 unter http://i.cmpnet.com/audiencedevelopment/newsletters/-EmbeddedNL.html.

Entgegen der landläufigen Meinung sind Fibre-Channel-Netzwerkgeräte, HBAs, Switches und Speichersubsysteme nicht in der Lage, die meisten SAN-Verhaltensmuster zu überwachen. Außerdem werden Verwaltungstools, die Daten von diesen Geräten sammeln, aus einer Reihe von Gründen nicht unbedingt auf Probleme aufmerksam gemacht, die auf der physikalischen Fibre-Channel-, Framing- oder SCSI-Oberschicht auftreten. Sie können einige Informationen aus der SAN-Umgebung sammeln oder abfragen, können aber wenig tun, um die Fehlerbedingung zu lokalisieren oder neu zu erstellen.

Fibre-Channel-Geräte verbringen den größten Teil ihrer Zeit mit der Verteilung und Verarbeitung eingehender und ausgehender Datenströme. Wenn Geräte unter maximaler Belastung stehen, was am häufigsten zu Problemen führt, sind die für die Fehlerberichterstattung verfügbaren Geräteressourcen typischerweise minimal und für eine genaue Fehlerverfolgung häufig unzureichend. Außerdem bieten Fibre-Channel-Hostbusadapter (HBAs) nicht die Möglichkeit, Netzwerk-Rohdaten zu "schnüffeln", wie dies bei vielen Ethernet-Netzwerkadaptern möglich ist.

Es gibt eine Reihe allgemeiner SAN-Probleme, die sowohl in bereitgestellten Systemen als auch in Vorproduktionsumgebungen auftreten. Zu den häufigsten Problemen, die nur mit einem guten Fibre-Channel-Analysator sichtbar sind, gehören Kreditmangel, unerkannte physische Fehler, E/A-Splitting des Dateisystems und Bursting von Geräten.

Kredithunger

Fibre Channel behält eine strenge Flusskontrolle zwischen Geräten bei, indem Credits verwendet werden. Jedes von einem Gerät empfangene Guthaben erlaubt diesem Gerät, einen Frame zu übertragen. Im FC-Protokoll muss beim Senden eines Frames ein R_RDY zurückgesendet werden. Auf diese Weise werden Kredite während eines Datenaustauschs erhöht und verringert. Wenn ein Gerät kein Guthaben zur Verfügung hat, kann es nicht senden. In diesem Fall kann die SAN-Leistung erheblich leiden. Dies wird allgemein als Engpasserkennung oder Geräte mit hoher Latenz/langsamem Abfluss bezeichnet.

Geräten gehen aus einer Reihe von Gründen die Credits aus, darunter Fabric-Überlastung und die Unfähigkeit eines Geräts, Frames mit Fibre-Channel-Geschwindigkeit zu empfangen und zu verarbeiten. Es gibt eine Reihe von Faktoren, die dies beeinflussen, darunter:

  • Die Anzahl der verfügbaren Credits
    Geräte haben in der Regel eine feste Anzahl an Credits. Viele Geräte haben acht Credits, während einige 64 oder mehr haben. Geräte reservieren typischerweise die Hälfte ihrer verfügbaren Credit-Puffer für die Frame-Übertragung, während die andere Hälfte als Credits ausgegeben wird. Das bedeutet, dass die meisten Geräte auf dem Markt nur vier Credits für einen bestimmten Austausch zur Verfügung haben.
  • Fähigkeiten der Geräte, Daten schnell zu verarbeiten
    Ein Gerät muss in der Lage sein, eingehende Daten mit der gleichen Rate abzuladen, mit der es sie empfängt, oder ihm gehen die Credits aus. Dies kann zu einem Dominoeffekt führen: Wenn einem Gerät das Guthaben ausgeht, muss jedes Gerät, das versucht, Daten dorthin zu übertragen, warten, bis wieder Guthaben verfügbar ist. Damit gehen auch den anderen die Credits aus. Dies ist ein typisches Engpass-Szenario.
  • Link-Round-Trip-Verzögerungen
    Die Umlaufverzögerung wird nicht nur durch die Kabellänge beeinflusst, sondern auch durch die Anzahl der an einer Schleife beteiligten Geräte. Jedes Gerät auf einer Verbindung fügt ungefähr 0.5 Mikrosekunden Verzögerung hinzu. Dies entspricht dem Hinzufügen von 100 m Kabel zum Link pro Gerät. Dies mag nicht nach viel erscheinen, aber 2-KB-Lesevorgänge in einer Arbitrated Loop (typisch für Datenbankanwendungen) können um mehr als 18 % pro 100 m Kabelverzögerung beeinträchtigt werden.
  • Datenverlust in Kreditsituationen
    Das Ausmaß der Datenverschlechterung aufgrund von Kreditmangelsituationen variiert je nach E/A-Größe. Kleine E/A-Operationen (512 Byte bis 4 KB) sind im Allgemeinen stärker von Kreditmangel betroffen als größere, da die durchschnittliche Rahmengröße kleiner ist und mehr Kredite erforderlich sind, um einen konstanten Datenfluss aufrechtzuerhalten.

Es gibt viele Faktoren, die zur Kreditverknappung beitragen. Einige davon können durch die richtige Berücksichtigung von Leistungsfaktoren beim anfänglichen Design des SAN vermieden werden; Es ist jedoch oft eine gute Idee, die Daten zu analysieren, um die Theorie mit der Realität zu vergleichen.

Unerkannte physikalische Fehler

Unentdeckte physische Fehler können durch eine Reihe von Faktoren verursacht werden, darunter schlechte Kabelbiegungen, Abschlussprobleme, ausfallende Laser und fehlerhafte Kabel, die auf Benutzerebene möglicherweise nicht sichtbar sind.

Nehmen Sie zum Beispiel das 62.5-Mikron-Kabel für FDDI oder ATM, das viele Einrichtungen in ihrer Infrastruktur installiert haben. Fibre-Channel-Multimode-Laser sind für 50-Mikron-Kabel ausgelegt, funktionieren aber auch mit 62.5-Mikron-Kabeln, solange die Entfernung weniger als etwa 200 Meter beträgt. Längere Kabelwege verursachen intermittierende Fehler, Codeverletzungen und andere Netzwerkprobleme. Da Fibre-Channel-Analysatoren das tatsächliche Netzwerk anzeigen, können sie eine entscheidende Komponente bei der Fehlerbehebung dieser Art von Fehlern sein.

Wie bei den anderen „versteckten Verhaltensweisen“ werden physische Fehler von Geräten und Verwaltungstools oft nicht erkannt. Fibre Channel ist in einer Reihe von Standards definiert, die bis auf die Ebene der geordneten Menge vollständig redundant sind. In Kombination mit den Wiederherstellungsmethoden für SCSI können viele Framing-Fehler automatisch wiederhergestellt und auf den niedrigsten physikalischen Schichten erneut versucht werden, ohne dass sie den Verwaltungstools gemeldet werden. Darüber hinaus können Geräte viele Fehler auf Verbindungsebene automatisch verwerfen und ersetzen, z. B. Codeverletzungen, die im SAN nicht gemeldet werden.

Fibre Channel bietet viele Möglichkeiten, wie sich Geräte von Fehlersituationen erholen können. Existierende SAN-Verwaltungstools suchen traditionell nach Link-Resets und CRC-Fehlern als Indikatoren für Probleme, aber diese Tools versuchen nicht, nach Fehlerbehebungsmechanismen auf Protokollebene im Datenverkehr zu suchen.

Geräte sind auch nicht in der Lage, Fehler zu sehen, die sie aufgrund eines fehlerhaften SFP oder Kabels übertragen haben; dies überlässt es dem fehlerempfangenden Gerät, sie zu melden.

Wenn Fehler an das Betriebssystem und/oder Dateisystem gemeldet werden, können sie dazu führen, dass das SCSI-Subsystem "gedrosselt" wird, um nur eine ausstehende E/A gleichzeitig (pro Gerät) zuzulassen. Da die meisten Unternehmensserver für die Speicherleistung stark auf überlappende I/Os angewiesen sind, kann dies den Durchsatz auf einen Crawl reduzieren. Bei den meisten Betriebssystemen besteht die einzige Wiederherstellung dafür darin, den Server neu zu starten.

Als Beispiel für das Herbeiführen von Kreditmangel zu Testzwecken können Sie die Anwendung LeCroy InFusion („Jammer“) verwenden, die sowohl auf dem SierraFC M8-4 als auch auf dem SierraFC M164 verfügbar ist. Auf der folgenden Seite wird ein Screenshot gezeigt, um das einfache Szenario zu veranschaulichen, mit dem ein R_Rdy entfernt wird. Es könnte ein komplexeres Szenario erstellt werden, das mehrere R_Rdys entfernt und einen Kreditmangelzustand für Ihre spezifische Umgebung simuliert.