Zbr's days.
June
Sun Mon Tue Wed Thu Fri Sat
         
30
2007
Months
Jun

About TODO Blog RSS Old blog Projects Gallery Notes

Sat, 30 Jun 2007

Wine cellar.


My cellar only contains bottle of Martini now - yesterday the last bottle of black vodka was completed.
And I was told (even suggested/recommended/asked) to drink it not with usual company, but with completely different people.
Doubts rarely visit me, but right now they have came.
Thinking...

/life :: Link / Comments (0)


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)