Some extensions are on the wishlist for the future:
- Data mirroring across an arbitrary point-to-point high speed IP
network. This allows for transparent data replication across arbitrary
distances (could lead to interesting financial experiences,
though). Thus, site disaster recovery would be possible. The key to
this is a pseudo device driver sitting on top of the normal disk
partitions and talking to its counterpart(s) on remote
nodes. Applications and filesystems will sit on the pseudo device
instead directly on the disk block device. The pseudo device driver
will trap all read and write attempts, satisfying reads locally and
writes remotely and locally. A more detailed concept to this will be
developed later but for those interested in thinking ahead this is
pretty much how IBM's High Availability Geographic Cluster (HAGEO)
works.
As opposed to HAGEO, though, there will be
encryption layer, e.g. via IPSEC or SKIP.
- Development or implementation of a clustering API against which
applications can be linked and by means of which applications can
control the cluster in certain ways. Clustering API's that already
exist are IBM's Phoenix (currently designed to handle up to 2048
nodes) or Microsoft's Wolfpack for Windows NT.
- Concurrent disk access which means all nodes participating have
read and write access to the disks. This will not be possible for
filesystems as long as there is no intelligent and efficient locking
mechanism. The only commercial application that currently makes use of
this feature is Oracle Parallel Server. I don't know whether the SCO
version of the Oracle database server (which runs with the iBCS2
emulator) supports concurrent access. If
not, disregard this bullet.
Concurrent Access involves
development of a distributed lock manager.
- Support "host-based" RAID boxes with special device drivers.