Skalierbare Schaltzentrale

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.