|
|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Sat, 30 Jun 2007
Distributed storage niche.
After drunk a bit of vodka with Grange
we discussed niche of my distributed storage.
Briefly saying (what it will be), this storage is a block device, which connects several disks
over the net. It will allow to implement different redundancy mechanisms to have self-healing
abilities in case of died underlying storages.
That is it.
Now what are the competitors.
- First and the simplest one is network block device. It allows to remotely
connect a storage, but one device can handle only one remote peer, so to implement
a storage one needs to group peers connected via network block deivices using for example LVM.
Device mapper on top of network block devices allows to use existing redundancy mechanisms like
software RAID. This looks simple and good, but there are some problems: one device per remote node,
essentially this does not allow to scale to really big storages, since number of devices is limited;
static configuration (local node can not determine size of the remote storage, that data is provided
before startup during configuration and can not be changed after device was started); needs special
userspace process on behalf of which all transactions are performed; network block device uses excessive
acknowledge protocol, which creates a huge overhead in case of flood of requests; global locking.
- High-end SCSI storage with hardware redundancy. This one is limited by the price - two unit server
can only contain about 14 disks, its price is already too high, if servers can be connected via
special interconnect, it increases its price even more, so for petabyte (just an example) storage
price will be about the same as number of bytes. Hardware RAIDs are complex to work with,
especially when disks start dying. There are no hardware RAIDs with more than RAID6 redundancy,
which is just two dead disks per array. RAID6 price is too high. More common RAID5 controllers
only allow to have one dead disks per array.
- High-end storages with different interconnects (like iSCSI), which actually can be cheaper,
but still requires LVM/Device mapper/whatever to build a single storage on top of them. Does not scale
to really huge volumes because of the price just like usual storage systems.
So, essentially distributed storage just allows to have huge volume storage using
existing network infrastructure without any special expensive components as long
as with additional high-performance low-latency interconnects, but providing
set of features existing systems do not have or its setup is not simple and high perfomance.
Approach I use is quite different from the most known and widely used Lustre
storage by Cluster Filesystem Inc (where I was asked to work some time ago :) (there
are number of very similar designs over there, which I was pointed privately couple of times).
One of the differencies is the fact, that distributed storage does not require
any special API to work with it, it looks just like usual huge storage connected locally
to the node.
I was told, that I will not be able to complete such task, that there is no need in it,
that there are better varians and so on, but frankly I do not care - I like the process,
so there are no problems for me.
/devel/dst :: Link / Comments (0)
Please solve this captcha to be allowed to post (need to reload in a minute): 11 * 72
|