Aktuelles Thema: RSIO - Erste Performancedaten

Was ist RSIO?

RSIO ist ein von OSL entwickeltes Protokoll, das applikationsbezogen virtualisierten Speicher und Clusterdienste über Netzwerk auf entfernten Clients anbieten kann. Anstoß der Entwicklung war der Wunsch, diesbezügliche Funktionen des OSL Storage Clusters auch auf Maschinen, die lediglich über LAN-Ports verfügen, bereitzustellen und damit zu niedrigen Preisen Funktionalitäten, Durchsätze und Verfügbarkeiten anbieten zu können, die bisher allein Fibre Channel vorbehalten waren.
Um Mißverständnissen von vornherein entgegenzutreten: Alles hat seine Grenzen und Fibre Channel bleibt in etlichen Fällen ohne Alternative. Immerhin hat OSL in diesem Bereich mit OSL Storage Cluster ein überzeugendes Gesamtpaket anzubieten und kann hinsichtlich Funktionalität, Verfügbarkeit und Bandbreite damit eine technologische Spitzenposition für sich beanspruchen. Aber: Auch über aktuelle LAN-Komponenten geht mehr als heute üblicherweise zu sehen ist.

Neben den vorgenannten gehobenen Anforderungen kann das RSIO-Protokoll aber auch generische I/O-Anwendungen bedienen. Es kann für zentralisierte und verteilte Speicherlösungen (Cloud Storage) gleichermaßen Anwendung finden.
Moderne Server- und CPU-Konzeptionen wurden im Design ebenso berücksichtigt, wie die Eigenschaften heutiger Standard-Netzwerkkomponenten und für die nächsten Jahre zu erwartende Entwicklungen auf diesem Gebiet. Programmiertechnisch setzt das Protokoll auf Sockets auf. Die heute verfügbare Technologiestudie nutzt TCP, eine Umsetzung mit UDP folgt. Durch die Definition eigener Frames ist das Protokoll prinzipiell auf verschiedenen Socket-Typen anwendbar und es können viele Zusatzfunktionen wie Checksummen, Verschlüsselung o. ä. implementiert werden.

Die aktuell durch OSL implementierte Umsetzung ist durch eine strikte Trennung von Treiber und Transportsystem gekennzeichnet. OSL sieht dies als Garanten für eine hohe Portabilität, für einfache Handhabung und die optimale Nutzung aktueller Multithreading-Technologien. Da Client- und Serverprozesse im Userspace laufen, wird der Kern zugleich optimal abgeschirmt.
Multipathing und Link-Aggregation (Trunking) werden implizit und unabhängig von anderen Treibern und Mechanismen zur Verfügung gestellt, was eine problemlose Nutzung mit verschiedensten Netzwerkkarten, Systemen, Switches etc. garantiert. Als besonders ausgeklügelt darf die Technologie zur Minimierung der Latenz- und Transportzeiten gelten, die im Transportsystem der OSL-Implementierung enthalten ist.

Lesen Sie auch das Hot Topic "Remote Storage über Standard-Netzwerktechnik" von der SNWE 2009.

Diese auf der SNWE gelegentlich gestellte Frage ist etwas unglücklich formuliert. Mit iSCSI gibt es eine Technologie, die seit mehr als 20 Jahren bewährte Standards weiterführt und auf einer Vielzahl von Plattformen zur Verfügung steht. Wenn es nur darum ginge, wäre RSIO in der Tat überflüssig. Aber RSIO setzt andere Schwerpunkte:

  • funktionelle Erweiterungen über reinen Block-I/O hinaus
  • Transport von Virtualisierungsfunktionen
  • Transport von Clusterfunktionen
  • Parallelisierbarkeit und Eignung für geclusterte Speichersysteme (Cloud)
  • Vereinfachungen in der Administration (Nomenklatur, Multipathing, Trunking)
  • Performanceverbesserungen
  • Eignung für breites Spektrum an Protokollen bzw. Technologien

Der Einsatz von RSIO ist also primär dadurch motiviert, daß man neben Block-I/O weitere Funktionalitäten benötigt. Auch Fragestellungen hinsichtlich administrativer Vereinfachungen oder Performance können zu RSIO führen.
Neben einem Maurerhammer hat zweifellos auch ein Schlosserhammer seine Berechtigung. Ebenso sind iSCSI und RSIO zwar beides Lösungen, die Block-I/O über IP ermöglichen, beide haben aber ihre spezifischen Anwendungsgebiete.

 

Erste Performancedaten

In der Vergangenheit ging es zunächst um eine erste Umsetzung auf TCP, um administrative Konzepte und Funktionalität. Und an dieser Stelle haben wir auch weiterhin viel vor. Spätestens seit der ersten praktischen Vorstellung auf den OSL Technologietagen 2009 drängte sich aber auch immer mehr die Performance-Frage in den Vordergrund. Die Arbeit der vergangenen drei Jahre an diesem Thema speiste zwar eine gewisse Zuversicht, aber Praxis und Theorie können durchaus zweierlei sein. Für zusätzliche Spannung sorgte der Umstand, daß die Kollegen von Sun Microsystems kürzlich die mit iSCSI mögliche Performance unter Nutzung von COMSTAR und Kernel Threads deutlich nach oben geschraubt hatten (Details).

Um eine gewisse Vergleichbarkeit herzustellen, haben wir ein ähnliches Testverfahren gewählt (Lesen mit 8k Blockung aus Cache/Memory des Servers), das für die Praxis wohl eher nicht relevant ist, aber auf der anderen Seite ein gutes Maß für die Performanceeigenschaften allein des Protokolls ist (Platten sind nicht involviert). Als Testsysteme mussten die portablen PCs bzw. Mini-Server herhalten, die für die Vorführungen auf der SNWE gedacht waren (Switch nicht eingezeichnet):

Testkonfiguration

PCs
4 x Fujitsu E7935
CPU: 1 x Intel Core 2 Duo E8400 3.0GHz

 

x86-Server
1 x Fujitsu TX200 S5
CPU: 2 x Intel Xeon E5520 Quad Core


Konfiguration
Mit diesem Hardwareaufbau haben wir zunächst die TX200 als RSIO-Server für 4 Clients genutzt. Anschließend haben wir mit dem auf der SNWE zu zeigenden Setup das Ganze mit den 4 E7935 als Server und der TX200 als Client angetestet.

 

Nachfolgend die Werte beim "plattenlosen" Lesen mit 8k Blockung im Vergleich:

ImplementierungClient-ThreadsUsed Cores (Server)IOPS
iSCSI (Solaris 10)1007,631.000
iSCSI (COMSTAR)10010,085.000
RSIO (Solaris 10)645,698.000
RSIO (Solaris 10)1286,3102.000

Ohne jegliches Tuning haben wir mit anderen Blockungen auf Anhieb Durchsätze von über 910 MByte/s auf dem Server erzielt. Ein einzelner Client hat bei analogen Schreibvorgängen mit 8k Blockung und 16 Threads immerhin 170 MByte/s erzielt, was 21.760 IOPS entspricht. Die CPU-Belastung auf dem Client liegt bei diesen Tests zwischen 30 und 50 Prozent.
Auch die umgekehrte Variante (4 PCs als Server, TX200 als Client) ergab beim Lesen auf diesem einzelnen Client Durchsätze von bis zu 810 MByte/s, wobei die TX200 dann voll ausgelastet, die PCs aber zu etwa 70 Prozent idle sind.

Zusammenfassung

Erste Messungen konnten die theoretisch zu erwartenden Vorteile von RSIO bei den Durchsätzen bestätigen. Erfreulich ist insbesondere der niedrige CPU-Bedarf sowohl auf dem Server als auch auf dem Client, was insbesondere für den Client der Schlüssel zu höheren Durchsätzen ist. Im Vergleich zu iSCSI werden höhere Durchsätze mit in etwa dem halben "Hardwareverbrauch" erzielt. Zugleich hat bei diesen ersten Tests Solaris einmal mehr eindrucksvoll seine Stärken (Skalierbarkeit, Multithreading, Netzwerk) unter Beweis gestellt.
Wir freuen uns auf die nächsten Ergebnisse und erste praktische Anwendungen!

Interessiert ?

Nach wie vor ist das Thema RSIO in einem sehr frühen Stadium. Wenn Sie Vorschläge, Ideen, Hinweise haben oder sich weiter mit dem Thema beschäftigen möchten, senden Sie bitte eine Mail mit dem Betreff "[RSIO]" an: info@osl-it.de
Wir halten Sie auf dem Laufenden bzw. nehmen Kontakt zu Ihnen auf!