Aktuelles Thema: RSIO - Neuheiten 2014

1. Überblick

Bereits 2010 wurde auf der SNWE in Frankfurt/Main RSIO zum ersten Mal öffentlich gezeigt. Inzwischen ist das Protokoll schon längst nicht mehr nur Technologiedemonstrator, sondern hat Eingang in die gesamte OSL-Produktfamilie gefunden. Im OSL Unified Virtualisation Environment ist es der Schlüssel für ein Unified Networking, d. h. die Abbildung des Block-I/Os mit überlegenen Eigenschaften im gleichen physischen Netz, das auch für das LAN genutzt wird.
Die Weiterentwicklung von OSL UVE gab auch den Anstoß zu einer neuen Entwicklung: Während der RSIO-Server bisher stets mit der OSL-Speichervirtualisierung verknüpft war, benötigte man nunmehr für redundante UVS-Cluster ohne externen FC-Storage/RAID-Systeme eine Möglichkeit, auch unvirtualisierte Block-Devices für entfernte Systeme bereitzustellen. Von Anfang an hieß es: RSIO ist nicht zwingend auf OSL Storage Cluster angewiesen. Nun lieferten die Entwickler den Beweis, und zwar in Gestalt des Simple RSIO Servers, der sowohl unter Solaris als auch unter Linux lauffähig ist.
Daneben hat sich OSL weiter mit dem Thema Performance beschäftigt und konnte die schon bisher beeindruckende Performance nochmals steigern.

Was ist das Besondere an RSIO?

  • Neues, von Grund auf netzwerkorientiertes Design - keine SCSI-(Bus)-Emulation
  • Eignung für Multi-Storage-Server und Multi-Storage-Client-Architekturen
  • Einfachste Administration: Weitestgehende Selbstkonfiguration, Explorer, Optimizer, Auto-Recovery
  • Herausragende Performance- und Verfügbarkeitseigenschaften einschl. Multipfad u. a. durch:
  • Spezielle Technologien für Reduzierung von Latenz- und Übertragungszeiten
  • Besondere Eignung für Verknüpfung mit Speichervirtualisierung
  • Erweiterungen über I/O hinaus, z. B. für die Integration mit der clusterfähigen OSL-Speichervirtualisierung
  • Im Storage-Cluster-Mode z. B. Storage-Allokation vom Client aus, LAN-free Backup u. v. m.
  • Hohe Portabilität und Cross-Platform-Capabilities des Protokolls

Einen umfassenderen Überblick erhalten Sie auf den RSIO-Technologieseiten.

2. Simple RSIO - eine einfache Lösung für einfache Aufgabenstellungen

2.1. Neben dem Client nun auch RSIO-Server in einer kostenlosen Variante erhältlich

Wie bereits im Überblick erwähnt: Ab voraussichtlich März wird der Simple RSIO Server allgemein verfügbar sein. Auf der Seite des Storage-Clients (in der SCSI-Welt entspricht dieser dem Initiator) ändert sich nichts. Neben dem durch einen Maintenancevertrag abgesicherten professionellen Einsatz wird es auch die Möglichkeit zum kostenlosen Einsatz im Rahmen einer Evaluierung oder von Kleinanwendungen unter einer besonderen OSL-Lizenz geben. Dazu später mehr.

2.2. Die Unterschiede zur Cluster-Edition des RSIO-Servers

Bisher gab es den RSIO-Server nur in der Cluster Edition, also in Verbindung mit dem OSL Storage Cluster. Damit erhält der RSIO-Client sämtliche Storage-Ressourcen bereits in virtualisierter Form - im RZ-Betrieb die komfortabelste Variante.

Das Bild illustriert die Vorzüge dieses Verfahrens. Die RSIO-Server bietet nicht nur einen globalen Storage-Pool über RAID-Systeme hinweg. Die OSL-Speichervirtualisierung erlaubt Live-Data-Migration, Datenspiegelung, LAN-/SAN-less Backup, Application Aware Storage, I/O-Bandbreitensteuerung u.v.m. Im Frontend wird diese virtualisierte Storage-Welt den Storage-Clients in einem globalen Namespace zur Verfügung gestellt - mit RSIO als Data Center Block-I/O über Ethernet. In dieser Konstellation kann RSIO seine Stärken im vollen Umfang ausspielen. So ist zum Beispiel der I/O-Zugriff wahlfrei über jeden Server möglich, natürlich inklusive transparenter Umschaltung und Failover, Gesamtdurchsätze lassen sich so ohne Verzicht auf Verfügbarkeit aggregieren. Server und Clients können stets als Cluster agieren und innerhalb des globalen Namensraums ist eine feingranulare Zugriffssteuerung möglich (ACLs). Die Clients haben sogar die Möglichkeit, durch Installation der OSL Storage Cluster-Software zu vollwertigen Clusternodes zu werden. Neben dem Clusterframework und HA-Funktionen ist vor allem die Möglichkeit interessant, auf alle Funktionen der Speichervirtualisierung zuzugreifen. Das bedeutet z. B. selbständige Speicherallokation, Datenspiegelung oder Live-Data-Migration - alles vom Host aus. Einfacher und schlanker geht es nicht!

Beim Simple RSIO-Server impliziert die Loslösung von der Speichervirtualisierung des OSL Storage Clusters das Fehlen eines globalen Namespace. Jeder RSIO-Server bietet einen oder mehrere diskrete Namensräume. Der Funktionsumfang reduziert sich damit auf den reinen I/O über Netzwerk - angesichts der einfachen Handhabung und der besonderen Fähigkeiten von RSIO aber immer noch Grund genug, sich nicht mit weniger zufrieden zu geben.

Es sind vor allem der ausgeklügelte Datentransport und Cross-Platform-Fähigkeiten, die den Simple RSIO Server interessant machen. Auch wenn I/O über Netzwerke immer zusätzliche Latenzen bedeutet (das gilt natürlich auch für FC, wo Latenzen als wohlbehütetes Geheimnis gelten) - SSDs als Pool in einem Speichernetz haben trotzdem den Vorteil eines gigantischen Performancegewinns bei mixed und random I/O, da die bei konventionellen Festplatten mechanisch bedingten Verzögerungen (Latency, Seek, Skew) entfallen. Und wer auf höchste Performance Wert legt, hat noch immer Optionen: 10GE, mehrere Pfade und/oder Infiniband.
Es ergibt also unbedingt Sinn, wenn z. B. ein Linux-Host ultraschnellen Speicher für andere Server, für VMs oder eben auch Solaris-Server zur Verfügung stellt. Apropos Solaris: Hier ergeben sich interessante neue Möglichkeiten, weswegen dazu noch ein gesonderter Abschnitt folgt. Ohne Anspruch auf Vollständigkeit ein paar mögliche Anwendungsszenarien:

  • Vorhandene Netzwerkinfrastruktur als Speichernetz nutzen
  • Einfacher Geräteserver - auch für Shared-Disk-Access
  • Ultraschnellen Storage (SSD) für mehrere Maschinen bereitstellen
  • Ungenutzte RAM-Kapazitäten mehrerer Maschinen "einsammeln" und als Disk nutzen (für Batch-Läufe u. a.)
  • USB3 mit hoher Performance auf Solaris-Systemen verfügbar machen
  • Schnell und einfach viele Geräte in LDOMs nutzen
  • ...

Zwischenstand:
Der Simple RSIO Server läßt sich losgelöst vom OSL-Clusterframework sowohl unter Solaris als auch Linux betreiben. Mehrere Instanzen und Namespaces auf einem Host sind möglich. Storage-Ressourcen des als RSIO-Server agierenden Hosts können entfernten Clients (auch shared) als Block-Devices bereitgestellt werden. Dabei spielt es eine untergeordnete Rolle, ob es sich um ganze Disks/LUNs, Partitionen, Files oder RAM handelt, ob die Storage-Ressourcen intern oder extern angeschlossen sind. Mechanismen für Multiserver-Konfigurationen und einen Global Namespace bringt der Simple RSIO Server nicht mit.

2.3. Beispielsitzungen

Alle nachfolgenden Beispiele wurden mit einem Simple RSIO Server unter Linux mit 2 1GE-LAN-Interfaces und Clients unter Solaris und Linux erzeugt. Die Bedienung ist identisch, lediglich die unterschiedlichen Devicekonzepte von SVR4 und Linux bedingen einige kleine Unterschiede.

2.3.1. Erste Schritte auf dem Simple RSIO Server (SRSRV)

Per Voreinstellung gibt der RSIO-Server zwar Auskunft über seine Existenz, nicht aber über die bereitgestellten Ressourcen. Ein Zugriff von Clients wird solange abgewiesen, wie diesen der Zugriff nicht explizit gestattet wird. Auf dem Beispielsystem war bereits ein Client "solaris" eingerichtet. Wir ergänzen die Konfiguration um einen weiteren Client, den wir plattformgemäß einfach "linux" nennen und der sich mit dem Schlüssel "susi" identifiziert:


 

server # srsadmin -c linux -k susi
node linux added with rs nodeid 2

server # srsadmin -qvv
  id node name        node key                            mode
-------------------------------------------------------------------------------
0001 solaris          sun                                 simple rsio client
0002 linux            susi                                simple rsio client

 


Sobald sich der neu eingerichtete Linux-Client verbunden hat, kann uns der Server darüber informieren. Wir sehen, dass der Linux-Client nur ein Interface hat:


 

server # srsadmin -lvvv
000 lsimple
    000 (id   1) solaris          Solaris    LP64   little endian  
    IP(TCP) 192.168.1.112/6060<->192.168.1.100/5051 connected  tx: ok rx: ok 
    IP(TCP) 192.168.2.112/6060<->192.168.2.100/5051 connected  tx: ok rx: ok 
    001 (id   2) linux            Linux 3.x  LP64   little endian  
    IP(TCP) 192.168.2.112/6060<->192.168.2.110/5000 connected  tx: ok rx: ok 

 


USB-Medien für den Fernzugriff bereitstellen
Neben der Administration des Zugriffs (entspricht in etwa LUN-Masking) muss dem Server nun noch mitgeteilt werden, welche Storage-Ressourcen für die Clients bereitgestellt werden sollen. In der RSIO-Terminologie sprechen wir von einem "Device Grant", daher der Schalter "-g". Wir stellen zunächst 2 USB3.0-Disks (sdb und sdc) einen über USB2.0 angeschlossenen Stick (sdd) zur Verfügung:


 

server #  srsadmin -g sdb /dev/sdb
access to rvol 'sdb' granted (size 1953525168b = 931g+)
server # srsadmin -g sdc /dev/sdc
access to rvol 'sdc' granted (size 1953525168b = 931g+)
server # srsadmin -g sdd /dev/sdd
access to rvol 'sdd' granted (size 15633408b = 7633m+)

 


Der Name für die Ressource (grant) ist übrigens frei wählbar. Wir haben keine weiteren Optionen mitgegeben und interessieren uns nun dafür, wie die Ressourcen bereitgestellt werden:


 

server # srsadmin -qah
sdb                 931g+
sdc                 931g+
sdd                7633m+

server # srsadmin -qavv
sdb                            1953525168 blocks
    s: /dev/sdb
    c: /dev/rs/rdsk/sdb
    b: /dev/rs/dsk/sdb
sdc                            1953525168 blocks
    s: /dev/sdc
    c: /dev/rs/rdsk/sdc
    b: /dev/rs/dsk/sdc
sdd                              15633408 blocks
    s: /dev/sdd
    c: /dev/rs/rdsk/sdd
    b: /dev/rs/dsk/sdd

 


In der ausführlichen Variante sehen wir neben dem Special Device (die Host-Repräsentation der bereitgestellten Ressource - s) auch die Konfigurationsempfehlungen des Servers an die Clients in Gestalt des Block-Devices (b) und Character-Devices (c).

 

Wenden wir uns nun der Einbindung dieser Ressourcen auf der Client-Seite zu.

2.3.2. Erste Schritte auf dem Simple RSIO Client

Die Einbindung der Ressourcen erfolgt auf Solaris und Linux mit dem gleichen Kommando, lediglich die Darstellung im VFS ist leicht unterschiedlich, da Linux für Disks (normalerweise) keine Character-Devices nutzt.

Solaris


 

solaris # rsconfig -a
WARNING (rsconfig): created missing relocation dir /dev/rs
WARNING (rsconfig): created missing relocation subdir /dev/rs/dsk
WARNING (rsconfig): created missing relocation subdir /dev/rs/rdsk
solaris # rsconfig -lvv
lsimple::sdb                               1953525168 blocks,   1 server(s)
    c: /dev/rs/rdsk/sdb
    b: /dev/rs/dsk/sdb

lsimple::sdc                               1953525168 blocks,   1 server(s)
    c: /dev/rs/rdsk/sdc
    b: /dev/rs/dsk/sdc

lsimple::sdd                                 15633408 blocks,   1 server(s)
    c: /dev/rs/rdsk/sdd
    b: /dev/rs/dsk/sdd

 


Linux


 

linux #  rsconfig -qvv
000 lsimple (123), mode: simple rsio client
    clt: linux (susi)
    srv: 000 srv1 (srvid 1)
         -  sdb             disk      1953525168 blocks, blocksize  512 bytes
            c: /dev/rs/rdsk/sdb
            b: /dev/rs/dsk/sdb
         -  sdc             disk      1953525168 blocks, blocksize  512 bytes
            c: /dev/rs/rdsk/sdc
            b: /dev/rs/dsk/sdc


linux # rsconfig -a
WARNING (rsconfig): created missing relocation dir /dev/rs
WARNING (rsconfig): created missing relocation subdir /dev/rs/dsk
WARNING (rsconfig): created missing relocation subdir /dev/rs/rdsk

linux # rsconfig -lvvv
lsimple::sdb                               1953525168 blocks,   1 server(s)
    c: -
    b: /dev/rs/dsk/sdb
       >[ 1] srv1

lsimple::sdc                               1953525168 blocks,   1 server(s)
    c: -
    b: /dev/rs/dsk/sdc
       >[ 1] srv1

lsimple::sdd                                 15633408 blocks,   1 server(s)
    c: -
    b: /dev/rs/dsk/sdd

 


Wir sehen, dass der Server schon ein Raw-Device anbieten kann, dieses aber unter Linux per Voreinstellung nicht genutzt wird. Desweiteren wird auch unter Linux ein separates Unterverzeichnis "/dev/rs/dsk" angelegt, so dass gedankenlos eingerichtete Grants (wie sdb) nicht zu Konflikten mit lokalen Platten des Clients führen.

 

2.3.3. Vom Solaris-Client aus einen SuSE-USB-Bootstick am Linux-Server beschreiben

 


 

solaris # dd if=openSUSE-12.3-DVD-x86_64.iso of=/dev/rs/dsk/sdd bs=128k
35792+0 records in
35792+0 records out

 


 

2.3.4. Vom Solaris-Client aus auf eine USB3.0-Disk am Linux-Server zugreifen

 


 

solaris # time dd if=/dev/rs/dsk/sdb of=/dev/null bs=64k count=4096
4096+0 records in
4096+0 records out
268435456 bytes (268 MB) copied, 2.46735 s, 109 MB/s

real    0m2.469s
user    0m0.000s
sys     0m0.148s

 


 

2.3.5. Ein File als Block-Device bereitstellen

 


 

server # dd if=/dev/zero of=/var/tmp/gigafile bs=1024k count=1024server # srsadmin -g gigafile /var/tmp/gigafile
access to rvol 'gigafile' granted (size 2097152b = 1024m)

 


Und weiter z. B. auf dem Linux-Client:


 

linux # rsconfig -alinux # rsconfig -lvvvv
...
lsimple::gigafile                             2097152 blocks,   1 server(s)
    c: -
    b: /dev/rs/dsk/gigafile
       >[ 1] srv1
            rep: 000 IP(TCP) 192.168.2.112/6060

linux # mkfs -t ext3  /dev/rs/dsk/gigafile
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376

Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

linux # mount  /dev/rs/dsk/gigafile /mntlinux # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb3              32G  4.4G   26G  15% /
devtmpfs              930M  312K  930M   1% /dev
tmpfs                 930M     0  930M   0% /dev/shm
/dev/sdb1             122M   35M   81M  31% /boot
/dev/sdb6              16G  173M   15G   2% /home
/dev/sdb7              16G  198M   15G   2% /tmp
/dev/sdb5              16G  2.9G   13G  20% /var
/dev/rs/dsk/gigafile 1008M   34M  924M   4% /mnt

 


 

2.3.6. Unter Linux ein FAT-FS erstellen und anschließend unter Solaris nutzen

 


 

linux # mkfs -t vfat  /dev/rs/dsk/gigafile
mkfs.vfat 2.11 (12 Mar 2005)
unable to get drive geometry, using default 255/63
linux # mount /dev/rs/dsk/gigafile /mntlinux # cd /mntlinux # echo "HALLO RSIO" > hallolinux # ls -altr
total 12
drwxr-xr-x 23 root root 4096 Feb  9 19:34 ..
-rwxr-xr-x  1 root root   11 Feb  9 19:39 hallo
drwxr-xr-x  2 root root 4096 Feb  9 19:39 .
linux # cd ..linux # umount /mnt

 


Weiter auf dem Solaris-Client:


 

solaris # mount -F pcfs  /dev/rs/dsk/gigafile /mntsolaris # cd /mntsolaris # ls
hallo
solaris # cat hallo
HALLO RSIO

 


 

Zusammenfassung
Die Geräte sind einfach zu erstellen, ganz gleich ob es sich um ganze Disks, Partitionen, RAM-Disks oder Files handelt. Sowohl Solaris als auch Linux können gleichermaßen auf die durch den Simple RSIO Server bereit- gestellten Devices zugreifen. Ein besonderer Pluspunkt für RSIO: Auch der Server selbst kann ohne weiteres auf die gleichen Geräte zugreifen (Beispiel USB-Bootstick). Dies ist von unschätzbarem Vorteil z. B. in Backup-Szenarien.

3. RSIO - Performance

Bereits bei seiner Vorstellung auf der SNWE im Jahre 2010 verblüffte RSIO mit seiner damals noch

Dies sollte jedoch nicht das Ende der Fahnenstange sein. Die aktuelle Entwicklungsversion beinhaltet bereits Verbesserungen, die speziell bei Mixed- und Read-Loads bei wenigen Threads die Performance nochmals deutlich steigert. So konnte z. B. die sequentielle Single-Thread-Read-Performance mit 128k Blockung über 2 1GE-Verbindungen von ursprünglich 78,5 MByte/s über 123,6 mit multithreaded Transport auf heute 197,0 MByte/s unter Nutzung des Twin-Buffer-Modes verbessert werden. Letzterer kann die Performance bei bestimmten Lastprofilen deutlich steigern, wird kontext-sensitiv zu- und abgeschaltet und verfälscht nicht die vom Client (Initiator) erzeugten I/O-Pattern. Damit bleiben Optimierungen auf dem RAID-System weiterhin sinnvoll und möglich.
Der in den obigen Beispielen dargestellte Zugriff von einem Solaris-System auf USB3.0-Geräte eines Linux-Systems liefert wirklich überzeugende Ergebnisse. Während die Platten nativ am Linux-Server im Lesen mit 128k Blockung 111 bzw. 114 MByte/s lieferten, konnte vom Solaris-Client aus über 2x1GE 110 MByte/s beim Zugriff auf eine Platte (single threaded) und 200 MByte/s beim parallelen lesenden Single-Thread-Zugriff auf beide Platten erzielt werden.
Mit 2-4 x 1GE-Interfaces kann RSIO mehr Daten transportieren, als die meisten Anwendungen erfordern, weitere Steigerungen sind bei der Verwendung von 10GE oder Infiniband möglich. Speziell mit der Performance und Anwendungsmöglichkeiten im Solaris-Umfeld befasst sich der folgende Abschnitt.

4. RSIO auf aktuellen Solaris/SPARC-Systemen

4.1. Überblick

Für den Anfang könnte man bereits zufrieden sein, dass mit RSIO unkompliziert und performant auf USB-Devices zugegriffen werden kann, und zwar nicht nur mit 20 oder 40 MByte/s, sondern gerne auch mit 100, 200 MByte/s oder mehr, wie die o. g. Beispiele belegen. Dies wird der eine oder andere Administrator vielleicht noch mit einem Lächeln abtun, denn ein schneller Server muss ja nicht unbedingt auch im USB-Bereich schnell sein.

Etwas spannender wird es bei der Standard-Ausstattung aktueller SPARC-Systeme auf der I/O-Seite. In der Regel sind 4x1GE an Bord. Das reicht für 440-460 MByte/s Gesamtdurchsatz - für viele Anwendungen genug. Wem also der Kaufmann auf den Zehen steht, der findet hier die preisgünstigste Möglichkeit zur Storage-Anbindung.

Noch spannender wird es bei der Nutzung von Oracle VM for Sparc (besser bekannt als LDOMs). Das wohl interessanteste Feature dieser Virtualisierungstechnik ist die Fähigkeit zur Live-Migration für SPARC-Solaris-Gäste. Voraussetzung dafür sind sogenannte Virtual Disk Services, die durch die Service-Domain bereitgestellt werden und natürlich externer Storage. In diesem Umfeld ist OSL zu Hause. Bei Verwendung von OSL Storage Cluster vereinfacht sich die Handhabung in diesem Umfeld radikal, aber auch allein mit (Simple) RSIO werden Sie deutlich mehr Spaß haben, wenn Sie vielleicht dutzende oder gar hunderte Geräte in der LDOM benötigen:

Die Verwendung von RSIO hat also eine Reihe von Vorteilen für den Administrator:

  • Die Kommandosequenz ist deutlich kürzer, die Konfiguration bei RSIO absolut einfach.
  • Die Suche nach Geräten und die Sorge um die eindeutige Identifikation entfallen.
  • RSIO arbeitet immer mit "sprechenden" Namen.
  • Multipath ist auch ohne komplexe Zusatzaufgaben integriert.
  • Der RSIO-Storage-Server kann direkt steuern, welches Gast-System den Zugriff erhält.
    Beachte: In der FC-Variante kann das LUN-Masking vom Storage-Server aus nur den Zugriff durch die Service-Domain beschränken ? welche Gast-Domain zugreift, bleibt verborgen bzw. liegt in der Kontrolle der Service-Domain.
  • Bei Verwendung des RSIO-Servers in der Cluster-Edition (OSL SC) schließt der Disk-Access-Manager Fehlerquellen aus.
  • Bei Verwendung der Cluster Edition und von OSL Storage Cluster auf dem RSIO-Client kann die Storage-Allokation aus der Gast-Domain heraus erfolgen.

Die Fähigkeiten zur Live-Migration bleiben natürlich erhalten.

4.2. LDOMS und LDCs

Neben der radikalen Vereinfachung gibt es aber noch spezifische Problemstellungen. So nutzt Solaris für die Kommunikation mit den Guest-Domains, insbesondere aber auch für alle Arten von Virtual Devices sogenannte Logical Domain Channels (LDCs). Die Zahl dieser LDCs is begrenzt, im günstigsten Fall auf 768, auf einigen Systemen sogar deutlich weniger und sie gehen in einer realen Konfiguration weg wie "geschnitten Brot". Hier genau kann OSL RSIO helfen, zum einen mit der Fähigkeit, eine Vielzahl von Geräten über eine begrenzte Zahl von Kanälen zu "tunneln" und andererseits mit der Möglichkeit, mehrere Kanäle simultan zum Transport zu benutzen. Die einfache Handhabung wie im o. g. Beispiel und die Fähigkeit zur Live-Migration bleiben natürlich erhalten. Das nachfolgende Bild illustriert den Unterschied mit Standard-Bordmitteln (links) und die Vereinfachung mit RSIO (rechts). Der transparente rote Balken markiert symbolisch die Zahl der benötigten LDCs.

Mit RSIO haben Sie also problemlos hunderte oder tausende Geräte in den Guest-Domains im Griff, LDC-Engpässe gehören der Vergangenheit an. Welche praktischen Konfigurationsszenarien sind also zu empfehlen?

4.3. Konfigurationsbeispiele

4.3.1. Fibre Channel extern - intern RSIO

Wer nicht zu radikal umdenken will, für den bleibt mit dieser Variante in der externen Infrastruktur alles beim Alten: Fibre Channel bis zum Host, aufwendige Storage-Konfiguration auf vielen Ebenen. Immerhin hilft aber RSIO, die interne (virtualisierte) Infrastruktur im Server sowie die Gerätekonfiguration für die Gäste zu vereinfachen, sowie etwaige LDC-Engpässe zu vermeiden.

4.3.2. Unified Networking - alles über Ethernet

Wer aller-, allerhöchste I/O-Performance braucht, wird auf virtualisierte Geräte (VDS) und Live-Migration verzichten müssen. Wer aber den Ingenieursgrundsatz "soviel wie nötig" befolgen kann, der wird hier neue Möglichkeiten entdecken. Die Verwendung von RSIO ermöglicht es, ganz auf FC zu verzichten und die Device-Server-Funktion (also das Pendant zum VDS) aus der Service-Domain hinaus in einen externen Server zu verlagern. Dieser kann preiswert und schnell sein.

Preiswert und schnell heißt z. B. ein x86-System mit 12 oder mehr internen SSD-Disk, ggf. zusätzlicher Anbindung von FC-Storage (RAID-Systemen). Hier bleiben keine Wünsche mehr offen: Hohe Performance, einfachstes Gerätehandling und bis in die Guest-Domain (bei Verwendung von OSL Storage Cluster ggf. sogar bis in die Zone hineinreichende) Zugriffssteuerung für ggf. sogar virtualisierten Storage.

4.4. RSIO und aktuelle Solaris/SPARC-Systeme - Performance

Dies ist ein weites Feld, und weil allgemein unpopulär haben wir auch keine Benchmarks durchgeführt. Um aber Anhaltspunkte für die Möglichkeiten zu liefern, haben wir ohne jegliches Tuning, d.h. mit Standard-Kernel und Netzwerkeinstellungen (d. h. auch ohne Jumbo-Frames, die für Standard-Anwendungen wiederum Nachteile bedeuten) einige Messungen durchgeführt. Schnell erreicht man die Streaming-Grenzen von LUNs aus realen RAID-Systemen. Daher haben wir wiederholte (cached) Reads von einem einzigen RSIO-Device zum einen über 2x8G FC und zum anderen über 2x10GE, jeweils mit einer unterschiedlichen Zahl von Netzwerkverbindungen in der internen V-Switch-basierten Infrastruktur einer Fujitsu M10-1 durchgeführt. Die Blockung betrug jeweils 128k.

Zu erkennen ist, dass im betrachteten Fall RSIO die Performance des VDS übertrifft. Lediglich bei nur einer Verbindung und einer größeren Zahl von Threads werden 600 MByte/s nicht erreicht. Alles in allem und angesichts der möglichen Vereinfachungen also viele gute Gründe, die für RSIO sprechen, sei es in der einfachen Variante oder in Verbindung mit der clusterfähigen Virtualisierung.

5. Ausblick und Kontakt

Die vorgestellten Funktionen sind allesamt verfügbar. Lediglich der Simple RSIO Server wird erst im März die allgemeine Freigabe erhalten, kann aber ab sofort im Rahmen einer Pilot-Vereinbarung genutzt werden.

Der Simple RSIO Server wird auch unter einer OSL-eigenen, gebührenfreien Lizenz zu haben sein. Er ist dann auf 4 Devices in einem Namespace beschränkt. Für den professionellen Einsatz empfiehlt sich der Abschluss eines Maintenancevertrages, bei dem dann keine besonderen Beschränkungen mehr gelten.

Den vollen Funktionsumfang inkl. aller Speichervirtualisierungs- und Clusterfunktionen bietet die im OSL Storage Cluster enthaltene Version des RSIO-Servers (Cluster Edition).

Schulung

Für Kurzentschlossene besteht noch bis zum 13. Februar die Anmeldung zum RSIO-Workshop am 17./18. Februar. Weitere Termine finden Sie hier.

Kontakt

Wir freuen uns über Kommentare, Ideen und Einsatzszenarien. Auch wenn Sie die Software testen möchten oder Beratung wünschen, nehmen Sie bitte einfach Kontakt mit uns auf: Alle Kontakdaten.