Von: Dirk Pelzer
Auf den ersten Blick wirkt die Ausstattungsliste des jüngsten McData-Sprösslings eher spartanisch. Der "Sphereon 4500" braucht sich vor der Konkurrenz aber nicht zu verstecken. Eines der interessantesten Merkmale ist die Hot-CAT-Funktion. Sie soll es ermöglichen, Firmware-Upgrades im laufenden Betrieb durchzuführen, ohne den Datenverkehr zu beeinflussen. Eine derartige Funktion war bislang den wesentlich teureren Fibre-Channel-Switches der Director-Klasse vorbehalten.
Für eine hohe Verfügbarkeit sorgen zudem redundante Netzteile und Lüfter, die im laufenden Betrieb austauschbar sind. Letzteres gilt auch für die Konnektoren zum Anschluss der Fibre-Channel-Komponenten, die als SFP (Small Form Factor Pluggable) ausgeführt sind. Die Ports lassen sich als universelle G-Ports oder als vorkonfigurierter E- beziehungsweise F-Port betreiben. Darüber hinaus kommt der Sphereon 4500 mit Loop-Devices zurecht und kann sowohl mit L- als auch mit NL-Ports Verbindung aufnehmen.
Der Switch wächst mit
Die Flexibilität bei den Ports ist damit aber noch nicht erschöpft. So bietet McData Unternehmen die Möglichkeit, zunächst eine mit acht Ports konfigurierte budgetschonende Version des Sphereon 4500 zu erwerben und anschließend bei Bedarf in Schritten von je acht Ports zu erweitern. Mit jedem Upgrade erhält der Systemverwalter die passende Anzahl SFPs und die erforderlichen Lizenzschlüssel zur Port-Freischaltung.
Gespart hat McData jedoch beim Pufferspeicher für die Ports. So bieten nur die ersten vier Ports ausreichend Pufferspeicher, um bei einer Übertragungsrate von 2 GBit/s eine Distanz von zehn Kilometern zu überbrücken. Die übrigen Ports schaffen aufgrund des geringeren Pufferspeichers nur höchstens fünf Kilometer. Für die angepeilte Zielgruppe der kleinen und mittleren Unternehmen, die keine Datenspiegelung über größere Distanzen durchführen möchten, mag das ausreichend sein. Wer jedoch heute schon weiß, dass der Switch künftig für Verbindungen über mehr als zehn Kilometer herangezogen werden soll, sollte besser ein anderes Gerät wählen, denn der für größere Distanzen erforderliche Pufferspeicher lässt sich nicht erweitern.
Für das Management verfügt der Sphereon 4500 über eine Weboberfläche und ein Command Line Interface (CLI). Die Web-gestützte Software "SAN Pilot" ist in der Lage, bis zu sechs McData-Switches in einer Fabric zu verwalten. Wer über mehr Switches verfügt, sollte auf den optionalen, aber aufpreispflichtigen "EFC-Manager" von McData umsteigen. Dieser bietet zudem noch weitere Funktionalitäten, zum Beispiel CallHome. Für eine umfassende SAN-Management-Lösung, die nicht nur FC-Switches von McData, sondern auch die anderer Hersteller sowie zusätzliche Fibre-Channel-Komponenten verwaltet, bietet McData den "SAN Navigator" an.
An Management-Standards unterstützt der Sphereon 4500 SNMP (Simple Network Management Protocol) mit Fibre Alliance MIB (Management Information Base), Fibre Channel Fabric Element (FC-FE) MIB und MIB-II für TCP/IP. Darüber hi-naus beherrscht der Sphereon 4500 alle gängigen Fibre-Channel-Standards, wie zum Beispiel FC-PH (auch Version 2 und 3), FC-GS-2 und FC-SW-2. Dies umfasst auch Support für die Fabric-Dienste Simple Name Server (SNS), Management Server, Zoning und Broadcast.
Switch im Testlabor
Für unseren Test stellte McData zwei komplett ausgestattete Sphereon 4500 zur Verfügung. Wir unterzogen die Geräte zunächst einem Praxis- und Handling-Test. Mit von der Partie war unter anderem ein FC-Raid-Storage von Nstor mit insgesamt acht Festplatten, wovon jeweils vier in einem Raid-0-Verbund zusammengefasst waren, um hohe Durchsätze erzielen zu können. Der Zugriff erfolgte von einem "Dell-Poweredge"Server aus, der unter Windows-2000 Server lief und mit einem Host-Bus-Adapter "6460 FCE 2 GBit/s" von JNI ausgerüstet war. Für weiter gehende Lasttests kam zudem ein Fibre-Channel-Analyzer "SmartBits 6000B" der Firma Spirent Communications zum Einsatz, der mit acht 1-/2-GBit/s-Fibre-Channel-Ports bestückt war.
Mithilfe unseres Raid-Systems stellten wir zunächst fest, wie viel Datendurchsatz sich über einen einzelnen Sphereon 4500 erzielen lässt. Dazu schlossen wir den Poweredge-Server und den Nstor-Speicher an einen Switch an. Bevor wir mit dem Test beginnen konnten, mussten wir noch einige Switch-Parameter einstellen, damit sich beide FC-Geräte korrekt am Sphereon anmelden. Dabei zeigte sich, dass die SAN-Pilot-Software zwar einerseits recht übersichtlich, andererseits aber auch teilweise umständlich zu bedienen war. Wir mussten häufig zwischen den unterschiedlichen Menüs hin- und herwechseln, um die erforderlichen Einstellungen durchzuführen.
Nachdem diese erste Hürde umschifft war, konnten wir mit- hilfe des Storage-Benchmark-Tools "Intel I/O-Meter" einen Datendurchsatz von knapp 89 MByte/s erzielen. Dabei verwendeten wir ausschließlich sequenzielle Lesezugriffe mit einer Größe von 5 MByte. Anschließend verbanden wir den zweiten Sphereon 4500 über zwei Inter-Switch-Links (ISL) mit dem ersten Switch. Außerdem schlossen wir den Poweredge-Server an einem Switch und den Nstor-Speicher am anderen Switch an, um festzustellen, ob sich der Ausfall eines ISL negativ auf den Datenverkehr auswirkt. Dazu kopierten wir mehrere große Dateien auf den SAN-Speicher und unterbrachen während der Übertragung den jeweils aktiven ISL. Nach etwa 30 Sekunden hatten sich die beiden Switches so umkonfiguriert, dass sie die Daten über den verbliebenen ISL übertrugen. Der Windows-Explorer, über den wir den Kopiervorgang angestoßen hatten, schien daran keinen Anstoß zu nehmen und setzte die Kopieraktion fort. Trotzdem sind die von uns gemessenen 30 Sekunden relativ hoch, da nicht alle Anwendungen auf einen derart langen Timeout so kulant reagieren. McData stellte diesen Test nach und kam zu deutlich kürzeren Zeiten.
Im nächsten Schritt untersuchten wir, ob sich Änderungen an der Fabric-Konfiguration auf den Datenverkehr zwischen unserem Server und dem Storage-System auswirken. Dazu verbanden wir beide Switches nur über einen einzelnen ISL und schlossen Server und Storage an einen der beiden Sphereons an. Dann kopierten wir wieder per Explorer mehrere große Dateien auf den SAN-Speicher. Währenddessen entfernten wir mehrfach die ISL-Verbindung und schlossen sie wieder an. Dabei stellten wir fest, dass die Datenübertragung zu keinem Zeitpunkt unterbrochen war.
Mischbetrieb möglich
Im darauf folgenden Testabschnitt musste einer der beiden McData-Probanden zeigen, ob er sich auch mit unserem Testlabor-Switch, einem "Silkworm 3200" von Brocade, versteht. Mithilfe einer auf Anfrage von McData erhältlichen Anleitung waren wir in der Lage, die Interoperabilität zwischen den beiden Geräten innerhalb von zehn Minuten herzustellen. Allerdings sind dabei einige Punkte zu beachten und es gibt funktionelle Einschränkungen.
Grundvoraussetzung für die Zusammenarbeit der beiden Systeme ist, dass der McData-Switch im Modus "Open Fabric 1.0" und der Silkworm im "Interoperability"-Modus (Interopmode=1) betrieben wird. Außerdem muss der Sphereon als "Principal Switch" konfiguriert sein. Damit der Brocade entsprechend als "Subordinate Switch" agieren kann, ist es erforderlich, dessen Domain-ID auf einen höheren Wert als die des McData-Produkts zu setzen. Hierbei ist zudem zu beachten, dass McData und Brocade unterschiedliche Nummerierungs-Schemata für die Domain-ID verwenden. So entspricht die Domain-ID 1 von McData der Domain-ID 97 von Brocade und so weiter. Wir konfigurierten deshalb auf dem McData die Domain-ID 1 und auf dem Brocade-Switch die Domain-ID 98. Nach einigen Eingaben in den jeweiligen grafischen und kommandozeilenorientierten Benutzerumgebungen gelang es uns, die beiden Switches über einen E-Port miteinander zu verbinden. Anschließend mussten wir noch eine Zone einrichten, damit das Storage-System, das am McData-Switch angeschlossen war, vom Poweredge-Server aus, der am Brocade-Switch hing, gesehen werden konnte.
Über Intel I/O-Meter vergewisserten wir uns dann, dass der Datendurchsatz sich nicht von dem zuvor gemessenen Wert von 89 MByte/s unterschied. McData empfiehlt übrigens den Einsatz des Sanavigator für die Konfiguration der Zonen. Dessen aktuelle Version 3.5 versagte aber in unserer Umgebung den Dienst. Wir waren aber auch mit der SAN-Pilot-Software in der Lage, unsere Zonen zu konfigurieren, nicht jedoch mit den Web-Tools von Brocade. Für das Zoning gilt zudem die Einschränkung, dass nur Soft-Zoning über World Wide Names (WWN) unterstützt wird. Hard-Zoning per Domain-ID und Portnummer klappt laut McData in diesem Umfeld nicht.
Wir wiederholten auch in dieser gemischten Konfiguration den Test der Fabric-Rekonfiguration, wobei wir einmal beide FC-Geräte an den Brocade und das andere Mal beide an den McData-Switch anschlossen. Das Entfernen und Wiederhinzufügen des ISL hatte in keinem Fall negative Auswirkungen auf die Datenübertragungen.
Für den Abschluss unserer Funktionstests wollten wir wissen, ob sich die Firmware eines Sphereon-Switches tatsächlich im laufenden Betrieb aktualisieren lässt, ohne dass dies einen Einfluss auf die Datentransfers hat, die in dieser Zeit über den Switch abgewickelt werden. Dazu schlossen wir unseren Speicher und den Server an einen der beiden Sphereons an, initiierten anschließend einen größeren Datentransfer auf eines der beiden Raid-Volumes im SAN und führten dann per SAN-Pilot-Software ein Upgrade des Microcodes durch. Einige spannende Minuten vergingen, bis der Switch meldete, dass er die neue Firmware erfolgreich aktualisiert und geladen hatte. Während der ganzen Zeit wurde der Datentransfer munter fortgesetzt, ohne dass eine Unterbrechung zu erkennen war.
Hohe Last gerecht verteilt
Bei den Handling-Tests fiel uns auf, dass den Sphereon-Switches in der Basisversion die Möglichkeit fehlt, ein effizientes Monitoring durchzuführen. Die im Lieferumfang enthaltene SAN-Pilot-Software war nicht in der Lage, umfangreichere Statistiken oder grafische Auswertungen zu liefern. Auch das CLI bietet hier nur sehr wenig. Zudem ist das Auswerten von Event-Logs mit SAN-Pilot nur schwer möglich. Die Logs sind zwar vorhanden, enthalten jedoch nur kryptische Hex-Codes. Die optionale EFC-Manager-Software soll laut McData in der Lage sein, sie zu entschlüsseln.
Bei den Lasttests, die wir mit dem SmartBits-Analyzer durchführten, setzten wir fünf Szenarien ein. In einem Many-to-One-Test simulierten wir sieben FC-Initiator und ein Target-System, was in der Praxis sieben Servern und einem Storage entspricht. Dabei generierten wir massiv Last und setzten so den Target-Port unter Überlast, um herauszufinden, ob der Switch die vorhandene Bandbreite gerecht auf alle sieben Initiator verteilt, oder einzelne bevorzugt (siehe Abbildung links).
Als Frame-Größe wählten wir für den ersten Durchgang 2148 Byte. Anschließend wiederholten wir diesen Test mit 64-Byte-Frames, die den Switch stärker belasten, weil durch die kleinere Paketgröße mehr Overhead entsteht. Bei einer Framegröße von 64 Byte verteilte der Sphereon die Last der einzelnen Initiator nahezu mustergültig auf den Target-Port. Kein einziger Port wurde übervorteilt oder benachteiligt. Das heißt, dass alle Server, die auf ein Storage-System schreiben wollen, gerecht behandelt werden.
Bei größeren Frames sah es dagegen anders aus. Hier bevorzugte der Sphereon-Switch einen einzelnen Port. Während sechs Initiator-Ports sich mit einer Bandbreite von zirka 28 MByte/s begnügen mussten, erhielt ein einzelner Initiator 35 MByte/s, also 25 Prozent mehr. McData bildete dieses Testszenario nach, konnte aber keine ungleiche Verteilung feststellen. Da in der Praxis eher von kleinen Framegrößen auszugehen ist, dürfte die von uns gemessene Asymmetrie nicht allzu sehr ins Gewicht fallen.
Im so genannten Backpressure-Test unterzogen wir die Fairnessalgorithmen eines einzelnen Switches einer weiteren genaueren Überprüfung. Dabei kommunizieren insgesamt acht Ports miteinander, wobei jeweils zwei Ports eine Eins-zu-Eins-Beziehung haben und der Datenfluss unidirektional gerichtet ist. Von einem der Quellports existiert aber noch eine Querverbindung zum Zielport eines anderen Quellports (siehe Abbildung Seite 31). Wenn der Fairnessalgorithmus des Switches tatsächlich "fair" arbeitet, müsste die Last des einen Ports, von dem zwei Verbindungen ausgehen, gleichmäßig auf die beiden Zielports verteilt werden. Auch diesen Test führten wir mit Framegrößen von 64 und 2148 Bytes durch. In beiden Fällen erzielte der Sphereon eine fast perfekte Lastaufteilung.
Lastverteilung über ISL
Als nächstes führten wir einen Loadbalancing-Test der Inter Switch Links durch (siehe Abbildung rechts). Dazu verbanden wir die beiden Sphereon-Switches über zwei ISL-Verbindungen und schlossen jeweils drei Ports je Switch an unseren SmartBits-Analyzer an. Anschließend konfigurierten wir den Analyzer so, dass drei Ports des einen Switches über die ISLs in einer Eins-zu-Eins-Beziehung bidirektional mit den drei Ports des anderen Switches kommunizierten. Ziel dieses Tests war es herauszufinden, wie der Switch die auftretende Last über die ISLs verteilt und ob aufgrund der Überlast eventuell gar Frames verloren gehen. Da die Sphereon-Switches auch Trunking unterstützen, führten wir den Test zwei Mal durch, wobei einmal Trunking deaktiviert war und beim zweiten Durchlauf aktiviert. Auch für diese Tests verwendeten wir 64-Byte- und 2148-Byte-Frames.
Dabei zeigten die Sphereon-Switches eine deutliche asymmetrische Lastverteilung über die beiden ISLs. Das galt sowohl mit aktiviertem Trunking als auch ohne. Offensichtlich führt McData das Trunking nicht auf Frame-Ebene durch, sondern pro Fibre-Channel-Verbindung. Auf diese Weise kann eine asymmetrische Last von drei Ports nicht symmetrisch über zwei Inter Switch Links verteilt werden. Das funktioniert nur, wenn beim Trunking die einzelnen Frames unabhängig von der Verbindung gleichmäßig über die ISLs verteilt werden, wie das beispielsweise Mitbewerber Brocade mit seinen Silkworm-Switches tut. Die McData-Variante des Trunkings arbeitet hingegen so, dass die internen Datenpfade je nach Auslastung der ISLs aktualisiert werden. Auf diese Weise routet der Switch hinzukommende Fibre-Channel-Verbindungen auf denjenigen ISL, der noch die meisten Kapazitäten frei hat, und nicht wie sonst üblich nach einem Round-Robin-Algorithmus. Letzterer kann sogar zu erheblich größeren asymmetrischen Lastverteilungen führen. Damit ist das Trunking von McData zwar sicherlich nicht die effizienteste Methode. Es lässt sich dafür im Prinzip über beliebig viele ISLs anwenden und ist zudem kompatibel zu Switches, die nicht über einen eigenen Trunking-Mechanismus verfügen.
Positiv festzuhalten ist zudem, dass auch in der Überlastsituation keine Frames verloren gingen, was beweist, dass die Flusskontrolle der Switches zuverlässig funktioniert. In der Praxis kann sich dieses Verhalten des Sphereon-Switches dahingehend auswirken, dass sich trotz aktiviertem Trunking ein ISL in einer Überlastsituation befindet, obwohl der zweite ISL noch reichlich Bandbreite zur Verfügung hat. Das würde sich jedoch nur bei solchen Anwendungen auswirken, bei denen verschiedene Systeme größere Datenmengen über einen längeren Zeitraum übertragen, etwa beim Video-Streaming. Bei vielen kurzen Transaktionen sollten sich die negativen Auswirkungen in Grenzen halten.
Um den maximalen Durchsatz eines Sphereon-Switches zu ermitteln, führten wir schließlich noch einen Full-Mesh-Test mit insgesamt acht Ports durch. Dabei schickt jeder Port jedem anderen Port FC-Frames, was den Switch unter extreme Last setzt. Unser SmartBits-Analyzer ermittelte automatisch den maximal erreichten Durchsatz. Dieser lag für 64-Byte-Frames bei knapp 780 MByte/s und für 2148-Byte-Frames bei knapp 1644 MByte/s. Damit hinkt der Sphereon etwas hinter den Werten von Switches zurück, die wir bereits früher getestet haben. Dafür lag die Latenzzeit des Sphereon 4500 mit Werten zwischen 0,8 und 1,5 Mikrosekunden in einem üblichen und unkritischen Bereich.
Fazit
Der Sphereon 4500 von McData leistete sich in unserem Test kaum Schwächen. Lediglich beim Trunking kann es in extremen Lastsituationen dazu kommen, dass der Datenfluss stärker als erwartet ausgebremst wird. Auch die mitgelieferte SAN-Pilot-Software könnte an der einen oder anderen Stelle etwas bedienerfreundlicher gestaltet werden. Minuspunkte gab es zudem für die etwas zu geringe Ausstattung mit Pufferspeicher, was aber nur die Unternehmen stören dürfte, die über eine Weitverkehrsanbindung für ihr SAN nachdenken. Ansonsten zeigt sich der Sphereon 4500 als gut ausgestattetes, praxistaugliches Gerät, mit dem Unternehmen relativ preiswert in die Fibre-Channel-Technologie einsteigen können, ohne sich durch eine zu geringe Anzahl von Ports die Zukunft zu verbauen. (cl)
Sphereon 4500
Hersteller
McData
www.mcdata.com
Preis: Basispreis mit acht aktiven FC-Ports 9959 Dollar; Flexport Expansion Kit (Shortwave) mit acht SFP und Aktivierungsschlüssel 6931 Dollar
Technische Daten
Fibre-Channel-Ports: bis zu 24 Small-Form-Factor-Pluggable (SFP), 2 GBit/s
Unterstützte Porttypen: E, F, FL, G
LAN-Verbindung: 10/100- Base-T
Management: Telnet, SNMP (Fibre Alliance MIB, Fabric Element MIB), SAN Pilot, EFC Manager, Sanavigator
Testergebnis
+ Gute Performance
+ Flexibel erweiterbar
+ Praxistauglicher Funktionsumfang
- Zu wenig Pufferspeicher für Weitverkehrsanbindung
- "SAN-Pilot"-Software teilweise umständlich zu bedienen