Von: Dirk Pelzer, Christoph Lange
Obwohl der "kleinste" Brocade-Switch in 2-GBit/s-Technik nur über acht Fibre-Channel-Anschlüsse verfügt, bietet er nahezu alle Funktionen der größeren Modelle und fügt sich so nahtlos in die Produktlinie des Herstellers ein. Dabei ist er laut Angaben von Brocade vollständig kompatibel zur existierenden 1-GBit/s-Technik. Das einzige wichtige Ausstattungsmerkmal, auf das der Systemverwalter beim "Silkworm 3200" verzichten muss, ist ein redundantes Netzteil, wie es beispielsweise der Silkworm 3800 mit 16 Ports bietet. Dafür liegt der 3200 für Fibre-Channel-Verhältnisse in einem preislich durchaus attraktiven Bereich.
Die Anschlüsse des Silkworm 3200 sind entsprechend dem Stand der Technik im Small-Form-Factor-Pluggable-Design (SFP) ausgeführt, das gegenüber dem klassischen Gigabit-Interface-Connector (GBIC) wesentlich höhere Portdichten ermöglicht. Bei den SFP-Modulen unterstützt der Switch sowohl Kupfer- (HSSDC-2), als auch optische Single-Mode- und Multi-Mode-Technologie.
Neben der Anhebung des Durchsatzes auf 2 GBit/s hat Brocade auch den Funktionsumfang der für das Switching verwendeten ASICs (Application Specific Integrated Circuit) erheblich erweitert. Wie bei den Vorgängermodellen in 1-GBit/s-Technologie "bedient" auch beim Silkworm 3200 ein ASIC vier Fibre-Channel-Ports. Ein zentraler Speicher mit kleinen Buffern soll dabei auch das Routing kleinerer Frames bei geringen Latenzzeiten ermöglichen. Hier unterscheidet sich Brocade von den Designs anderer Anbieter, die vielfach auf Crossbar-Technologie setzen und nach Angaben von Brocade geringe Latenzen nur bei voller Framelänge erreichen.
Neu ist, dass die Brocade-ASICs der aktuellen Generation aufgrund verbesserter Rechenleistung in der Lage sind, die weitergeleiteten Datenpakte bis zu einem gewissen Grad in Echtzeit zu analysieren und wichtige Informationen aus dem Header des Fibre-Channel-Protokolls zu extrahieren. Diese als "Frame Filtering" bezeichnete Technologie gestattet die Einführung vieler neuer Funktionen.
So ist es nun zum Beispiel möglich, ein Hard-Zoning auf Basis des Worldwide Name (WWN) der an den Switch angeschlossenen Fibre-Channel-Host-Bus-Adapter (HBA) durchzuführen. Bei früheren Modellen konnte Hard-Zoning lediglich auf Basis der Portnummern des Switches realisiert werden. Das hatte zu Folge, dass eine Umkonfiguration der Zone notwendig wurde, wenn ein Fibre-Channel-Gerät an einen anderen Port angeschlossen werden sollte. Durch den Einsatz der Frame-Filtering-Technologie "wandert" die Zone bei einem Umstecken eines Gerätes an einen anderen Port automatisch mit. Da viele Systemverwalter aber eine Konfiguration bevorzugen, bei der eine eindeutige Zuordnung zwischen Port und Zone gewährleistet ist, kommt dieser Neuerung eine nicht ganz so große Bedeutung zu, wie die Marketingstrategen glauben lassen möchten. Für künftige Switch-Generationen dürfte sich diese Einschätzung jedoch ändern, da Brocade mithilfe des Frame-Filterings auch Quality-of-Service-Funktionen auf Applikationsebene ermöglichen will.
Effektiver Lastenausgleich
Wesentlich interessanter als die Erweiterung der Zoning-Funktionalität ist die Einführung des ISL-Trunkings (Inter Switch Link; siehe auch Kasten ISL-Trunking). Hierbei erlaubt der Einsatz der Frame-Filtering-Technik bei Verwendung von mehr als einem ISL eine wesentlich bessere Lastverteilung als bisher. Während es bei klassischen Verbindungen zweier Switches über zwei oder mehr ISLs dazu kommen kann, dass ein ISL vollkommen überlastet ist, während die übrigen noch Kapazitäten zur Verfügung haben, sorgt das ISL-Trunking für eine ausgeglichene Lastverteilung. Nachteil ist jedoch, dass es eine aufpreispflichtige optionale Komponente darstellt und zudem die Länge der Verbindungskabel auf 400 Meter begrenzt ist.
Tiefe Einblicke
Ebenfalls sehr interessant ist die neue "Advanced-Performance-Monitoring"-Funktion des Silkworm 3200. Auch diese nutzt das Frame-Filtering und gewährt tiefe Einblicke in die Leistungsdaten des Switches. So ist beispielsweise für jeden Port ersichtlich, wie viele SCSIWrite- beziehungsweise -Read-Befehle ausgeführt wurden. Die damit gewonnenen Informationen eignen sich sehr gut für Tuningmaßnahmen und Aussagen über die Auslastung einzelner Ressour-cen in einer Fabric. Darüber hinaus lassen sich hiermit auch Daten zur Verifizierung von Service Level Agreements und Abrechnungszwecken ermitteln. Dazu ist allerdings der Zugriff auf das Brocade API (Application Programming Interface) notwendig, wie es von verschiedenen SAN-Management-Anbietern, wie zum Beispiel von Veritas mit "SAN Point Control" oder von Prisa Networks, genutzt wird.
Zukunftspläne
Brocade arbeitet bereits daran, seine Switches in zwei weiteren wichtigen Bereichen um zusätzliche Funktionen zu erweitern. Im kommenden Jahr soll der so genannte "V-Switch" auf den Markt kommen, der eine Virtualisierung von Speicherressourcen direkt im Switch ermöglicht. Er umfasst neue Software sowie spezielle ASICs und soll die Virtualisierung in Wire Speed durchführen. Etwa ein Jahr darauf will Brocade eine neue Gerätegeneration zur Serienreife bringen, die sämtliche Protokollarten transportieren kann, also neben Fibre Channel beispielsweise auch iSCSI, FCIP, iFCP oder Gigabit- Ethernet. Dabei übersetzt die Backplane alle Arten von Protokollen und transportiert sie zwischen den jeweiligen Ports hin und her. Diese Produktlinie soll bereits auf der nächsten FC-Generation basieren, die Übertragungsgeschwindigkeiten von bis zu 10 GBit/s erreicht.
Komfortable Konfiguration
Für den NetworkWorld-Test stellte Brocade zwei Silkworm-3200-Switches mit allen optionalen Softwarekomponenten zur Verfügung. Bevor wir daran gingen, die Perfor-mancemessungen durchzuführen, erforschten wir zunächst die wichtigsten Werkzeuge, um die Switches zu konfigurieren und zu administrieren. Dabei hat der Systemverwalter die Qual der Wahl zwischen einer Java-gestützten grafischen Benutzeroberfläche (GUI) namens "Web Tools" und einer Kommandozeilenumgebung, auf die per Telnet zugegriffen werden kann. Beide Umgebungen bieten sehr viele Möglichkeiten, wobei uns, von Ausnahmen abgesehen, die Kommandozeilenumgebung besser gefallen hat als die GUI, da viele Aufgaben einfach schneller durchführbar sind. Für die Einrichtung von Zonen hingegen eignet sich die GUI ausgezeichnet, da sie sehr viel übersichtlicher ist als die Kommandozeile. Auch zur Auswertung von Performancedaten oder zur Konfiguration von "Fabric Watch", das den Systemverwalter bei der Überschreitung von Schwellwerten alarmiert, leistet die GUI hervorragende Hilfestellung. Sehr gut gefallen hat uns zudem die Möglichkeit, eine Konfigurationsdatei zu exportieren, diese mit einem Editor zu modifizieren und dann auf einem anderen Switch zu importieren. Dies erleichtert die Wiederherstellung beim Totalausfall eines Switches erheblich. Auch der erweiterte Funktionsumfang der Performanceanalyse, der durch Frame-Filtering ermöglicht wird, hinterließ einen sehr guten Eindruck. Einblicke bis auf die Ebene des SCSI-Protokolls sind normalerweise nur durch den Einsatz teurer Analyzer oder über Raid-Controller einiger weniger Storage-Hersteller möglich. Eine tiefer gehende Analyse bei Problemen im SAN wird so erleichtert. Auch die Tests, bei denen sich der Switch nach einer Änderung an der Belegung eines Ports neu konfigurieren musste, meisterte der Silkworm 3200 ohne Probleme. Insbesondere das Port-Trunking ist kinderleicht einzustellen - genügt es doch, einfach zwei oder mehr ISL am selben ASIC der beteiligten Switches anzuschließen. Das Trunking wird dann in Sekundenschnelle automatisch aktiviert.
Im Labortest
Um die Grenzen des Silkworm 3200 auszuloten, führten wir einige Lasttests mit dem Lastgenerator und Analyzer "Smartbits SMB-6000B" der Firma Spirent Communications durch. Für den Test standen uns acht FBC-3602A-Testmodule mit je 2 Ports, also insgesamt bis zu16 Ports zur Lasterzeugung zur Verfügung. Wir testeten vier unterschiedliche Szenarien, zwei davon als Baseline-Tests und zwei weitere als die eigentlichen Lasttests. Bei den Baseline-Tests interessierten uns die Messwerte zwischen zwei Ports, wobei der Switch nicht an die Belastungsgrenze gebracht wurde. Beim ersten Baseline-Test wurden zwei Anschlüsse des SMB-6000 mit zwei Ports eines einzelnen Silkworm 3200 verbunden. Für den zweiten Baseline-Test kamen zwei Switches zum Einsatz, die über einen einzelnen Inter Switch Link miteinander gekoppelt waren. Zusätzlich fand je ein Port der beiden Switches Anschluss an den SMB-6000B. Für beide Konfigurationen ermittelten wir anschließend die Kennzahlen für den maximalen Durchsatz, wobei etwaige Frameverluste aufgezeichnet wurden. Die Messung erfolgte einmal bei der maximalen Fibre-Channel-Framelänge von 2148 Byte sowie bei einer Länge von 64 Byte. Die Framelänge von 64 Byte wurde gewählt, um die Leistungsfähigkeit der Switch-Engine zu verifizieren. Kürzere Frames simulieren zudem einen in Storage Area Networks häufig anzutreffenden transaktionsbasierten Netzwerkverkehr. Aufgrund der kürzeren Framelänge können zudem sehr viel mehr Frames pro Zeiteinheit generiert werden, was die Switch-Engine sehr stark belastet. Die Ergebnisse der Durchsatzmessungen für die beiden Tests sind in den Tabellen 1 und 2 ersichtlich. Der Datendurchsatz von 210,15 MByte/s und 154,55 MByte/s bei einer Framelänge von 2148 Byte beziehungsweise 64 Byte entspricht ziemlich exakt dem theoretischen Maximum. Verluste von Frames traten bei den Baseline-Tests erwartungsgemäß nicht auf.
Grenzwertermittlung
Beim nächsten Testdurchlauf erfolgte die eigentliche Lastmessung. Auch hier verwendeten wir wiederum zwei Szenarien bestehend aus einem Einzel-Switch und einem per redundantem ISL verbundenen Switch-Paar. Beim Einzel-Switch-Test wurden alle acht Ports eines Silkworm 3200 mit acht Anschlüssen des SMB-6000B verbunden. Anschließend konfigurierten wir den Lastgenerator so, dass er bidirektionalen Datenverkehr zwischen allen acht Ports in einer voll vermaschten Konfiguration des Bro-cade-Switches erzeugte. Dieser Test überprüfte die Leistungsfähigkeit der Switch-Engine und zeigte auf, ob es zu Engpässen beim Transfer der Frames zwischen den beiden ASICs des Silkworm kam.
Beim nächsten Test koppelten wir wieder zwei Silkworm-Switches miteinander. Anders als beim Baseline-Test verwendeten wir diesmal jedoch einen doppelt ausgelegten ISL; zwischen den beiden Switches waren also zwei 2-GBit/s-Verbindungen geschaltet. Pro ASIC wurde zunächst jeweils ein ISL konfiguriert, um zu vermeiden, dass der Switch das Port-Trunking benutzt. Anschließend verbanden wir jeweils fünf Ports jedes Silkworm mit dem Smartbits-Analyzer. Wir wählten eine ungerade Anzahl von Test-Ports, um die Wahrscheinlichkeit zu erhöhen, dass eine ISL-Verbindung höher belastet wurde als die andere. Um die Belastung über die ISLs zu maximieren, wurde der Smartbits so konfiguriert, dass er den Datenverkehr paarweise zwischen den Ports der beiden Switches übertrug. Das heißt Port 0 des ersten Switches kommunizierte mit Port 0 des zweiten Switches und so weiter. Außerdem stellten wir bidirektionalen Datenverkehr ein. Alle Tests wurden wie zuvor mit einer Framelänge von 64 und 2148 Bytes durchgeführt. Ebenso wurden maximaler Durchsatz und Frameverluste ermittelt. Um die Einflüsse des Port-Trunkings zu ermitteln, wiederholten wir den letzten Test, konfigurierten jedoch diesmal die beiden ISL so, dass sie an demselben ASIC angeschlossen waren und eine Trunk-Gruppe bilden konnten.
Die beiden Lasttests, die mehrere Ports nutzten, offenbarten die ers-ten Limitationen des Silkworm 3200. So blieben beispielsweise beim Test eines einzelnen Switches in voll vermaschter Konfiguration die erzielten Durchsätze hinter den Erwartungen zurück. Wie aus Tabelle 3 ersichtlich, lieferte der Silkworm 3200 bei einer Framelänge von 2148 Byte zwar noch eine aggregierte Bandbreite von respektab-len 1672,4 MByte, brach aber bei 64-Byte-Frames auf 817,77 MByte/s ein. Aufgrund des Baseline-Tests hätten wir uns bei den 64-Byte Frames einen Durchsatz von mehr als 1000 MByte/s (theoretisch 1236,4 MByte/s) erwartet. Frames gingen jedoch keine verloren. Somit ist sichergestellt, dass der Switch auch im Grenzbereich unter der von 64-Byte-Frames hervorgerufenen extremen Last noch zuverlässig arbeitet. Nach Rücksprache mit Brocade erhielten wir die Antwort, dass der von uns gemessene Performance-Einbruch deutlich größer sei als erwartet. Eine genaue Erklärung der Ursache konnte der Hersteller bis zum Redaktionsschluss nicht mehr liefern. Allerdings dürfte bei einem Entry-Level-Switch dieses Testszenario einer länger andauernden 100-Prozent-Belastung mit 64-Byte-Frames in der Praxis so gut wie nie vorkommen.
Interessant fiel auch der Vergleich der Durchsätze bei Verwendung zweier Standard-ISL-Verbindungen gegenüber einer Trunking-Gruppe, bestehend aus zwei Ports je Switch, aus (siehe Tabellen 4 und 5). Die Durchsätze lagen bei einer Framelänge von 2148 Byte noch nahezu gleichauf. Unter Volllast kam es beim Port-Trunking jedoch zu geringfügigen Verlusten von Frames. Die absolute Zahl von 52343 erscheint zwar auf den ersten Blick recht hoch, betrug jedoch weniger als 0,5 Prozent der Gesamtanzahl von Frames. Bei Verwendung von 64-Byte-Frames schließlich konnten die Standard-ISL gegenüber den beiden Trunk-Ports sogar einen leichten Vorsprung herausarbeiten. Da wir ein genau gegenteiliges Ergebnis erwartet hätten, wiederholten wir den Test, kamen aber wieder zu identischen Resultaten.
Um zu verifizieren, dass der Switch die Last beim Trunking auch tatsächlich gleichmäßig verteilte, konfigurierten wir den Smartbits so, dass er ein deutlich asymmetrisches Lastmuster erzeugte. Wenn das Trunking funktioniert, müsste der Switch die Frames trotzdem gleichmäßig auf die beiden Inter-Switch-Links verteilen. Anhand der Port-Statistiken der Silkworms konnten wir uns davon überzeugen, dass dies auch tatsächlich der Fall war. Anschließend verifizierten wir in gleicher Weise, dass bei einer Standard-ISL-Konfiguration eine asymmetrische Last auch immer asymmetrisch über die beiden ISL verteilt wurde. Demzufolge konnten wir sicher sein, keinen Fehler bei der Konfiguration der Switches gemacht zu haben. Andererseits schien das Trunking so wie spezifiziert zu arbeiten. Erneut kontaktierten wir den Hersteller und informierten ihn über das Ergebnis. Brocade bestätigte unsere Messergebnisse und erklärte, dass möglicherweise ein Programmierfehler in der Firmware des Switches zu den Resultaten geführt haben könnte. Uns wurde mitgeteilt, dass offensichtlich einige Ports unter Volllast eine höhere Priorität bekommen als andere, was ein Grund für die von uns ermittelten Resultate sein könnte. Brocade sicherte zu, das Problem weiter zu untersuchen und den Fehler gegebenenfalls zu bereinigen. Da alle 2-GBit/s-Switches von Brocade mit identischer Firmware arbeiten, betrifft der Fehler nicht nur den von uns untersuchten Silkworm 3200, sondern auch die übrigen Familienmitglieder. Ob und inwieweit sich das Prob-lem in der Praxis auswirkt, hängt aber sicherlich stark von den auftretenden Lastprofilen ab. Fest steht jedoch, dass sich das Trunking tendenziell dazu eignet, die Anzahl der Inter Switch Links zu reduzieren, da die Wahrscheinlichkeit der Überlastung eines einzelnen ISL wesentlich geringer ist. Ob diese Funktion allerdings für einen Entry-Level-Switch Sinn macht, sei dahingestellt. In der Regel dürften eher größere Switches davon profitieren, die wiederum an einen Core-Switch (Director) angeschlossen sind, vorausgesetzt das Trunking funktioniert wie versprochen.
Fazit
Der Silkworm 3200 präsentierte sich in unserem Test in den Kategorien Ausstattung und Bedienung ohne Fehl und Tadel. Lediglich das fehlende redundante Netzteil trübte die ansonsten hervorragende Ausstattung. Im Bereich der Performance traten jedoch leichte Probleme auf, wenn der Switch in Grenzbereichen arbeiten musste und gezielt in die Sättigung gefahren wurde. Unter Alltagsbedingungen, wie sie in der Regel bei Entry-Level-SANs auftreten, dürfte der Silkworm 3200 vollkommen problemfrei arbeiten, wobei er weitgehend lineare Datendurchsätze zu liefern vermag.
Zur Person
DIPL.-ING DIRK PELZER
arbeitet als freier Consultant und Journalist in München. Er ist NetworkWorld-Testpartner und betreibt das Storage-Labor der NetworkWorld. Zudem beschäftigt er sich mit Speichernetzen und Hochverfügbarkeit.
Testergebnisse und Daten
Silkworm 3200
Hersteller:
Brocade
www.brocade.com
Preis: ab 5599 Dollar (Basisausstattung ohne optionale Komponenten)
Technische Daten:
Fibre-Channel-Ports: 8 Small Form Factor Pluggable (SFP),2 GBit/s
Unterstützte Port-Typen: F, FL, E und TL (Translative Mode)
Netzwerk: 10/100 Base-T
Management: Telnet, SNMP (Fibre Alliance MIB), "Brocade Web Tools", kompatibel zu Management-Frameworks von Veritas, Tivoli, CA et cetera
Hop Count: 7
Besonderheiten: ISL-Trunking (optional), Frame-Filtering, Perfomance-Monitoring (optional), Autosensing, Zoning für WWN in Hardware, Quickloop für Private Devices (HBAs), Translative Mode für private Arbitrated-Loop Targets (Storage), "Fabric Watch" für proaktives Management (optional), "Fabric Access API", Rückwärtskompatibilität zur 1-GBit/s-Technik
Einbauhöhe: 1 Höheneinheit
Testergebnis:
+ Sehr guter Funktionsumfang
+ Praxistaugliche Leistungsdaten
+ Hervorragende Bedienung
- Kein redundantes Netzteil vorhanden