Skalierbare Schaltzentrale

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.