In today's hectic world time is money and so is information. This is especially
true nowadays with customer data from e-business and the huge amount of
logistic and scientific data which may be worth their weight in gold. The
amount of data is increasing sharply. The average storage capacity you get for
your money is skyrocketing. Storage of several hundred GBytes is achievable for
everyone. One might argue that today's storage capacity is just following the
trends and there is enough cheap storage to meet the increasing demand.
Unfortunately, the total cost of ownership is also increasing sharply with the
amount of the maintained data. In a typical company there are several file
servers which provide the necessary storage capacity and there are many tape
libraries for archiving the contents. If the storage need grows the company can
purchase a new hard disk or a new server. To have a reliable system there is
usually replication between the dedicated servers. The disk drives are
organized in raid arrays, typically RAID 1+0 or RAID 5 [Che94]. This solution
is not scalable enough for today's internet scale applications where there can
be huge fluctuations in demand. Failsafe behavior versus effective storage
capacity ratio is not optimal because of mirroring. Management is the other
weak point of this system. That was why the Storage Area Network was designed.
In a typical SAN there are several storage arrays that are connected via a
dedicated network. The storage arrays typically contain some ten to sixty hard
disks. To protect the data from hard disk failure these disks are organized
into RAID 0, 1, 5 arrays. Protection from more two or more hard disk failures
is very costly because of mirroring. In larger systems it is vital to protect
the data against storage array failure; hence the storage arrays are duplicated
and connected by SAN switches. The servers are connected to this network via
their fiber channel interfaces and provide a 2 GBit/s transfer capability. The
scaling of this system is achieved by adding new hard disks to arrays, or
moving the partition boundaries. The price of SAN components is high compared
to typical network components and servers, and the storage usage failure
toleration ratio is not so optimal.
We would like to present a much better and cheaper solution to this problem. A
typical PC now has huge computing and storage capacity. It is not unusual to
find more than 100 GBytes of storage capacity, over 500 MBytes of RAM and two
GHz or more CPU clock frequency in a desktop PC. It seems that these parameters
are constantly increasing. A typical installation of an operating system and
the software required does not consume more than ten to fifteen GBytes. The
rest of the storage space is unused. A typical medium-sized company has more
than 20 PCs. A university or research lab usually has more than two hundred
PCs. In this case the storage capacity that is wasted may be several TBytes in
size. So it would great if we could utilize this untapped storage capacity. In
order to solve the above-mentioned problem we decided to design and implement
LanStore with the following design assumptions:
· It is highly distributed without central server functionality.
· It has low server load. We would like to
utilize the storage capacity of desktop machines; these machines are used when
our software runs in background.
· It is optimized for LAN. The use of multicast and a special UDP based
protocol is acceptable.
· It has effective network usage. We designed and implemented a simplified
UDP-based flow control protocol.
· It is self organizing and self tuning. We used a multicast-based vote
solution to implement the so-called 'Group Intelligence'.
· There is a highly changeable environment. The desktop machines are restarted
frequently compared to dedicated servers.
· It is a file-based solution. For effective caching we chose file-based
storage instead of a block-based one. [Kis92]
· It has campus, research laboratory-type file system usage. Also, file write
collisions are rare. [Kis92] · It has an optimal storage consumption failure
survival ratio. As a first approach we selected Reed-Solomon encoding for data
For more details, download the