You’re spot on. I question the scalability of Isilon because of the parity RAID overhead. Google optimizes for cheap CPU cycles and they don’t do any parity RAID. Who do you think is smarter?

YottaYotta used Infiniband, which is a technology I like. I don’t know what the state of Infiniband management software is these days, but I’ve heard it isn’t in the same league with ethernet.

I do applaud Isilon for virtualizing the block pool, which enables minimizing storage management, the major cost of SANs today. They aren’t going after the 15% of structured data – they want the 85% of unstructured data that no one has time to manage. Revolutionary? No. Lucrative? Could be. Sounds like a plan to me.

Cheers,

Roibn

You say “There is a lot to like in the Isilon architecture, starting with their fundamental abandonment of the volume or LUN construct in favor of the storage pool”.

A simple NFS server running under Linux can be protected via an internal DP Raid file system (DP). This eliminates the need for an external RAID … but is slow, for various good technical reasons…. some of it is the generation of XOR.
It is a ‘low cost’ solution.

Isilon seems to be using ‘commodity motherboard’ hardware, running a specialized file system…. and hence the opportunity to eliminate the need for multiple mapping layers associated with the traditional RAID firmware … not really a new architecture.

While this may deliver some marginal performance benefits, the protection is still based on computationally intensive RAID5/6 algorithms…. which probably now reside on the central processor…. which is already very busy supporting NFS, TCP/IP etc. It remains to be seen how fast all this is under ‘writes’.

InfiniBand switch is not a new concept. Ethernet is too slow in clustered architectures. I am surprised that they started with Ethernet.
Very little choice here… IB or 10Gbit Ethernet …. both expensive.

Lets not forget that there is only *one * manufacturer of IB chips. IB Host adapters & switches are not cheap… but come with drivers, etc …. easier integration job.

Striping across multiple enclosures does not add to the performance until the existing data is moved to the new enclosure. Re-striping is very time-consuming and may be prone to failure… no immediate scaling in performance to the existing users, plus the extra management…. forever !.

Reported use of large ‘chunk’. size…
Small writes will produce a ‘storm’ over the IB switch i.e. RAID algorithms trying to cope with partial writes.…. this is why they need IB .

Performance is probably reasonable under sequential ‘read only’ traffic… but so what? It is very limited by the 1 Gbit Ethernet Host connection … plus the overhead of the protocol stack. Extra host connections require additional enclosures… more cost and re-striping.

The next step here… can only be to 10 Gbit Ethernet… more cost.

Remains to be seen how ’revolutionary’ all this is.