Das Multipathing bei RSIO folgt vorrangig 3 Zielen: Verkürzung der Übertragungszeiten, Skalierung des Durchsatzes und Steigerung der Verfügbarkeit. Es ist implizit in der Software implementiert und funktioniert daher auch über unterschiedliche Modelle von Netzwerkkarten hinweg. Der Administrator muss lediglich die für RSIO zu nutzenden Interfaces angeben, im Weiteren ist der Multipath selbstkonfigurierend.
Daneben ist das Protokoll so designed, dass auch mehrere RSIO-Server parallel genutzt werden können, womit sich die nutzbare Bandbreite nahezu beliebig steigern lässt.

Das RSIO-Protokoll hat mehrere interessante Verfügbarkeitseigenschaften. Es kann beispielsweise so konfiguriert werden, dass Sie auch ohne redundante Auslegung der Infrastruktur den einzigen vorhandenen Switch austauschen, auf Direktverkabelung o.ä. wechseln können, ohne dass ihre Anwendung I/O-Fehler erfährt. So lässt sich mit einer geeigneten Konfiguration auch ein Reboot des Servers oder ein Failover des Servers auf andere Rechner ohne I/O-Fehler überstehen.
Ein dauerhafter Ausfall der Serverfunktion wird - abhängig von der jeweiligen Anwendung - natürlich zu Problemen führen, auch kann das Protokoll so konfiguriert werden, dass nach Ablauf einer bestimmten Zeit ein Timeout generiert wird.
Trotz der vorgenannten Recovery-Fähigkeiten empfiehlt sich also für höhere Ansprüche eine redundante Auslegung der Server. In den Vorzugskonfigurationen sind daher alle Komponenten zum Aufbau eines active/active-Failoverclusters enthalten. Voraussichtlich wird in den nächsten Monaten auch der Parallelbetrieb von Servern mit implizitem Protokoll-Failover durch RSIO freigegeben.

Die Vorzugskonfigurationen sollen bewährte Komponenten zu einem attraktiven Preis bereitstellen. Die vorgestellten Konfigurationen können jederzeit um weitere RSIO-Server und weitere RAID-Systeme erweitert werden. Damit sind auch standortübergreifende Konfigurationen z.B. für Disaster Recovery darstellbar. Die Skalierung ist explizites Designmerkmal des clusterfähigen I/O-Stacks. Für weitere Details sprechen Sie bitte mit uns.

OSL entwickelt und testet derzeit auf den Plattformen Solaris und Linux. Es kommen in Verbindung mit Virtualisierungstechnologien wie KVM oder XEN auch Windows-Systeme und weitere Plattformen in den Genuss des Block-I/O über Ethernet.

Nein. RSIO funktioniert heute prinzipiell auf allen IP-fähigen Schnittstellen, auch auf 100Mbit-Ethernet. Wegen des guten Preis-Leistungsverhältnisses erscheint für die meisten Anwendungsfälle eine konventionelle 1GBit-Infrastruktur als besonders attraktiv. Höherwertige Netzwerke sind natürlich auch verwendbar und bringen weitere Performancevorteile.
RSIO ist vom Design her nicht zwingend auf IP(TCP) angewiesen, so dass zukünftig eine Unterstützung weiterer Übertragungstechniken möglich ist.

RSIO kann enorm von der Integration mit den Clusterdiensten und der Speichervirtualisierung des OSL Storage Clusters profitieren. Im Mittelpunkt der Entwicklung steht also logischerweise das Maximum an Funktionalität und Performance, das im Moment nur mit dem RSIO-Server unter Solaris (Sparc oder x86) erreichbar ist.
Reduziert auf den Funktionsumfang von RSIO (das ist deutlich mehr, als mit iSCSI möglich ist), kann OSL den RSIO-Server projektbezogen kurzfristig auch für Linux zur Verfügung stellen. Auf dieser Infrastruktur wären dann auch Linux-Cluster mit der OSL Storage Cluster ACO möglich. Sprechen Sie uns bitte an, wenn Sie konkrete Vorhaben in dieser Richtung planen.

OSL setzt kommerzielle Support-Prozesse für die Plattformen Solaris, SLES und RHEL auf. Für weitere Linux-Plattformen kann der Support auf Anfrage etabliert werden.
Losgelöst von Supportverträgen wird die Software entsprechend den Möglichkeiten für weitere Plattformen wie z. B. OpenSuSE, Ubuntu oder Debian bereitgestellt. Es sei für diese Plattformen darauf hingewiesen, daß Linux u.a. keine stabilen Kernel-Interfaces hat. Für alle, die längerfristig eine Software professionell nutzen und nicht selbst im I/O-Stack programmieren wollen, ist daher ein geeignetes Maintenancekonzept unbedingt anzuraten.

Ja, Sie können den RSIO-Server in Verbindung mit dem OSL Storage Cluster (mind. Base) auf vorhandener Hardware nutzen. Zu beachten ist lediglich, dass dafür die aktuelle Pilotversion des Storage-Clusters 4.3 benötigt wird. Mit Abschluss einer Pilotvereinbarung können Sie die Software für 3 Monate (ggf. auch länger) kostenlos evaluieren.

Wer nicht bereits OSL Storage Cluster (unter Solaris) nutzt, erhält mit den Vorzugskonfigurationen zu einem deutlich niedrigerem Preis Zugriff auf die RSIO-Technologie in Verbindung mit geeigneter Hardware.
Gerade Anwender, die - vielleicht unter Verzicht auf FC - ein Speichernetzwerk aufbauen möchten oder im Rahmen eines neuen Projektes neue Kapazitäten benötigen, werden davon profitieren. Erlaubt sei hier noch einmal der Hinweis auf die enormen Kostensenkungen in der Infrastruktur.

Das ist prinzipiell genauso wenig erforderlich, wie Sie für andere Speichersysteme BSD-KnowHow benötigen. Für bestimmte administrative Aufgaben ist es natürlich von Vorteil, wenn man weiß, wie man sich an einem Unix-System anmeldet und sich in einem Terminal bewegt.

Wir bemühen uns um eine Genehmigung durch bzw. Vereinbarung mit VMWare. Sobald diese vorliegt, werden wir eine Portierung beginnen.
Daneben bietet die Unterstützung von KVM und XEN eine vom Preis-Leistungsverhältnis und von der Zukunftssicherheit her sehr überzeugende Alternative. In Verbindung mit dem OSL Storage Cluster gibt es auch ein attraktives Management-Framework. Das Einsatzspektrum der Storage-Server in den Vorzugskonfigurationen kann bei Bedarf außerdem durch iSCSI erweitert werden.

Ja. Allerdings im Moment nur, wenn Windows in einer virtuellen Maschine läuft, die durch eine nativ unterstützte Plattform gehostet wird (z.B. Linux oder Solaris). Diese Host-Plattform arbeitet dann als eigentlicher RSIO-Client und stellt die Volumes für die Windows-VM zur Verfügung. OSL betrachtet derzeit KVM als die zukunftsträchtigste Virtualisierungstechnologie.
Eine native Unterstützung von Windows mit RSIO wird derzeit nicht angeboten. Das Einsatzspektrum der Storage-Server in den Vorzugskonfigurationen kann jedoch durch iSCSI auch für diese Plattform erweitert werden.

Für OSL Storage Cluster gibt es eine webbasierte grafische Benutzeroberfläche (WebGUI).

Für RSIO hingegen gibt es derzeit keine. Für Unix-Puristen schließen sich ein offenes, kompatibles Design und grafische Oberflächen wegen nachteiliger Wechselwirkungen aus. Soweit wollen wir nicht gehen. Wegen unserer Zielgruppe RZ-Anwender stand aber bei uns bisher ein intuitives, übersichtliches CLI klar im Vordergrund. Damit soll ein weniger routinierter Systemverwalter unterstützt werden (bei niedrigen Bandbreitenanforderungen). Die Bedarfsanalysen und konzeptionellen Vorüberlegungen für ein zukünftiges grafisches Bediensystem, das vermutlich in einem Web-Browser lauffähig sein wird, haben begonnen.

Das Knowhow von OSL und ihren Partnern ergänzt sich für beide Plattformen in idealer Weise. Damit können Migrationen optimal unterstützt werden. OSL Storage Cluster 4.3 erlaubt in Verbindung mit RSIO auch mixed Cluster von Solaris- und Linux-Systemen, so dass das Beste aus beiden Welten - und obendrein mit einer einheitlichen Storage-Administration! - kombiniert werden kann.

RSIO erlaubt sehr hohe Durchsätze und skaliert mit der Anzahl der Netzports. Bereits ein Gigabit-Netzwerk reicht damit für die allermeisten Anwendungen einschl. OLTP-Systeme (Datenbanken, SAP) aus. Beachten Sie, dass durch die Verwendung von XDM Backup-Konzepte möglich sind, bei denen die Daten nicht mehr über das LAN laufen! Dies trägt zusätzlich zu einer deutlichen Entspannung im I/O des Servers, der RSIO nutzt, bei.
Nur bei höchsten Performanceanforderungen, die kürzeste Latenzzeiten erfordern, ist weiterhin Fibrechannel oder noch besser Infiniband der Vorzug zu geben. Beachten Sie auch, dass Sie mit einem 10GBit-Ethernet nochmals eine deutliche Verkürzung der Latenzzeiten erzielen können (abhängig vom Medientyp).

RSIO kann über beliebige (konfigurierbare) Netzwerkschnittstellen benutzt werden und teilt sich ggf. die Bandbreite mit weiteren Datenströmen. Analog zum SAN ist das Aufsetzen eines dedizierten Netzwerkes jedoch gute Praxis, kann Sicherheitsprobleme u. a. minimieren und bleibt eben dennoch preiswert. RSIO ist aktuell für TCP(IP) implementiert und damit routingfähig.

Prinzipiell ist das möglich. Besonderheiten sind in der Verbindung mit XDM (hostbasierte Spiegelung) zu beachten. An diesem Thema wird noch gearbeitet. Da aber die Zugriffe der RSIO-Clients auf einem einzelnen Host gebündelt werden können, erscheint hier selbst die Kombination von Shared Device Access und Spiegelung als umsetzbar. Bitte sprechen Sie uns an, wenn Sie über konkrete Projekte in diesem Umfeld nachdenken.