Network Attached Storage :: To provide a NAS device which caters for most standard RAID-like configurations (distributed, replicated and striped storage models), within a natively scalable storage architecture (sporting multi-box, multi-rack, multi-site configurations) that presents common LAN file sharing protocols (including SMB/CIFS and NFS).
Project output includes example hardware component information with assembly instructional documentation, Linux firmware and operating documentation.
Description:
Saturn is an ambitious project with ambitious goals. It aims to be/have;
Distributed
Must be capable of concatenating multiple drives on either a single node or multiple nodes into a single contiguous storage capacity
Must be expansible such that adding another drive to an existing storage capacity must not require recreation of that storage capacity (destroying, creating, formatting)
Highly Available
Must be capable of replicating data between drives on either a single node or multiple nodes into a single highly available storage capacity
Must be capable of multiple replications to support the "two copies in the same rack, one copy in another" principle, and to address the Bathtub curve penalty seen with bulk drive purchases (http://en.wikipedia.org/wiki/Bathtub_curve) i.e. multi-drive/node failures
Should support high-latency asynchronous replication to enable multi-site deployments
No dependence on strict RAID implementations
Must not employ proprietary on-disk storage - Hardware RAID tends to employ proprietary on-disk storage and thus the volume or, indeed, any individual disk becomes unrecoverable when the RAID set is broken
Must enable good throughput on commodity equipment - Software RAID tends to bring about poor performance without accelerated hardware features
Recovery of replicated data should not be location specific
Should be able to recover a failed node at one site either at its home site or at any other site with that data (i.e. being able to transport an empty or out-of-sync node to another location for high speed data recovery is highly desirable)
No need for manual maintenance
All maintenance tasks should be exceptional and ideally limited to Moves, Adds and Changes
All sub-components that require routine maintenance should be automated where-ever practicable
No lost data
When configuring the NAS it should not be possible to lose or destroy data without asserting a conscious administrative decision to do so.
Ideally accessible from Linux and Windows
The presented storage capacity should be accessible from Linux and Windows
Client access should be delivered via native client interfaces (like SMB or NFS), though client-side agents are acceptable.
Saturn is undergoing constant development. The following key limitations should be noted;
The BOOTP/DHCP client capability is currently broken in libMidnightCode
Of the three Gluster storage modes (distribute, replicate, stripe) only distribute has been implemented in libMidnightCode
The web-based administration interface is read-only.
The Saturn Installation and Operations Manual (in the links below) is a guide to assist people with the assembly, configuration and operation of a Midnight Code Saturn storage appliance.
