Multipathing for RSIO sets 3 objectives: shorten transmission time, scaling throughput, and increase availability. Multipathing is an essential part of the RSIO, comes out of the box, and therefore works over any interface cards. Administrator only have to enable the interfaces to be used by RSIO, multipath is self-configuring. Besides the protocol is designed in such a way, that more than one RSIO Server may be used at the same time. Due to this feature bandwidth may increase, arbitrarily.

The RSIO-Protocol has some quite interesting availability characteristics. For example, it may be configured in a way that replacing the only network switch, to change to direct wiring or the like, is possible. While replacing the switch your application will not run into IO errors. In suitable configurations, RSIO clients also survive the reboot of the RSIO server or the failover to another RSIO server without any IO errors.
A long lasting RSIO-Server failure, will - depending on the active application - definitely lead to problems, the protocol may also be configured to generate a timeout.
Despite the aforementioned recovery features, a redundant RSIO-Server layout is strongly recommended for sophisticated requirements. The Pre-Configured packages come with all required components to build a active/active Failover Cluster. Within the next months, we expect to release the possibility for parallel operation of RSIO Servers with implicit Protocol-Failover.

Pre-Configured packages are meant to bundle proven standard components at a reasonable price. The presented Packages may be upgraded by RSIO-Server and Storage (RAID) any time. So that cross site setups for e.g. Disaster Recovery are feasible. Scaling is an explicit feature of the cluster aware RSIO stack.
Please contact us for further details.

OSL currently develops and tests on Solaris and Linux. As shown on tour, in conjunction with virtualization techniques like KVM or XEN, Windows based systems (and others) may also benefit from Block IO over Ethernet.

No. RSIO works on all IP-capable interfaces, even on 100MBit-Ethernet. For most use cases conventional 1GBit Interfaces provide both, a sufficient performance and a reasonable cost/performance ratio. Superior Network Infrastructure (10GbE) is also supported, and offers more performance benefits. RSIO is designed to be quite independant of the underlying transport layer (TCP/UDP-IP). In the future support for other transport techniques is feasible.

RSIO benefits enormously from the cluster features and the storage virtualisation of OSL Storage Cluster. Consequently the focus of development is to bring the RSIO-Clients to a maximum of features and performance, which is currently only possible with a RSIO-Server on Solaris (sparc or x86).
Reduced to the RSIO features only (considerably more than iSCSI offers), OSL is able to provide a Linux-Server - project based - on short notice. Based on this infrastructure, Linux-Cluster with OSL Storage Cluster ACO can be feasible.
Please contact us for further details.

OSL sets up comercial support for Solaris, SLES (SuSE Linux Enterprise) and RHEL (Redhat Linux Enterprise). Separatley from support contracts, the software is also provided for OpenSuSE, Ubuntu, Debian and others. For these platforms it is necessary to point out that Linux does not provide stable Kernel interfaces. For professional usage, a adequate maintenance concept is highly recommended, unless your are confident to program the IO stack yourself.

Yes, you may try the RSIO-Server in conjunction with OSL Storage Cluster (Base required) on your hardware. Currently a recent copy of OSL Storage Cluster 4.0 (pilot version) is required. With agreement you may evaluate the software for at least 3 months or longer where required.

People currently not running OSL Storage Cluster (on Solaris), get access to RSIO on suitable hardware at a considerably reduced rate.
Users, trying to set up a storage network (maybe FC free) or require storage for new projects may benefit from this offer.
Once more we like to point at the enormous cost reduction for a RSIO infrastructure.

As a matter of principle it just as unnecessary as BSD KnowHow is required to configure a RAID-System. For some administrative tasks however, it is of advantage to know how to login to a Unix-System and how to use a terminal.

We are trying to get an approval by, repectively an agreement with VMWare. As soon this is done, porting will be started. Besides support for KVM and XEN provide a guaranteed future and are very convincing for their cost/performance ratio. In conjunction with OSL Storage Cluster, there is also a very attractive management framework available. Moreover the RSIO-Server may also (if required) be used to provide iSCSI targets.

Yes. But currently only for Windows Systems inside a virtual machine, hosted by a natively supported platform (Solaris, Linux). The hosting platforms are configured as RSIO-Clients providing storage volumes for the Windows-VMs. OSL currently views KVM to have the most promising future prospects.
Native Windows support is currently not offered. However for not supported platforms the Pre-Configure Packages may provide iSCSI Targets.

Currently not. For Unix-purist a open, compatible design and a Graphical Interface are mutually exclusive, because of their possibly harmful interaction. Because of our target user group, the data center administrator, we focused so far on a clear and precise Commane Line Interface (CLI). Which was supplemented by a curses based administration tool, aimed at the less experienced user, but still with low bandwith requirements.
Preliminary considerations and analysis for a prospective graphical Interface, presumably browser based, have begun.

OSL's KnowHow and that of its partners add to another perfectly. Therefore migration may be supported. Moreover OSL Storage Cluster 4.0 in conjunction with RSIO also supports mixed Cluster consisting of Linux and Solaris-Clients . This way the very best of both worlds can be achieved with a consistent storage administration!

RSIO permits high throughput and scales with the number of network interfaces. A 1GBit-Ethernet infrastructure is for most application sufficient including OLTP applications (databases, SAP). Please note that with using XDM backup concepts may be realised, avoiding any additional data traffic over your LAN. This also reliefs considerably the IO load of the Server.
Only for very high performance requirements and very short latency, Fibre Channel or better Infiniband are to be prefered. Please note 10GBit-Ethernet may as well reduce latency considerably, depending on chosen media type.

RSIO can be used on any (configurable) Network Interfaces and may share its bandwith with other protocols. On the lines of a SAN infrastructure in is considered good practice to set up a dedicated Storage LAN, reducing safety implications and remains reasonable. RSIO is currently implemented on top of TCP(IP) and therefore can be routed.

As a matter of principle it can be done. However this is work in progress. Since access of RSIO Clients can be tied to a single RSIO-Server, the implementation of host based mirroring in combination with Shared Device Access appears feasible.
Please contact us, if you are considering detailed projects along theses lines.