[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] iSCSI GFS

> How much I/O do you actually need?

My concern is not so much what I need up front but the growth path should I 
start needing to add a lot of storage. LAMP services can sometimes grow very 
quickly, immediately need endless ongoing storage space for uploaded media and 
playback, not to mention the web services themselves. 

Like I mentioned, I've seen not being prepared for growth and it's not fun. I 
would hate to have to keep changing out technologies once things get going 
because I didn't choose a nice flexible solution up front. 

> creates virtual software RAID stripe over them. It then exports this
> back out via iSCSI. All the client nodes then connect to the single big
> iSCSI node that is the aggregator.

Do you know of any software which helps to keep track of all this? This is an 
interesting idea. I think I understand it and want to give it a try. I have 
various types of storage where this would be a good solution.

Let's see if I've got this right.

I need a machine which will become the aggregator, plenty of memory, 
multi-port Ethernet card and of course an FC HBA. 
FC storage will be attached to this machine. Then, iSCSI storage targets will 
also export to this machine. 
This machine will then use virtual RAID (which I've no idea about yet) and 
aggregate the storage as a volume or how many I need. Next I export this to 
the servers via iSCSI for their larger ongoing storage needs.

Now I can use say a small FC GFS target to share various files such as web 
pages and other web based shared files yet have the larger more easily 
expandable V-RAID for media and other such things.

This means that I also need to find an iSCSI target driver that doesn't take 
rocket science to figure out and is open source to keep things cheap while 
trying this out. 

> NFS can give considerably better performance than GFS under some
> circumstances. If you don't need POSIX compliant file locking, you may

As I've put all of this together, I've come to learn that I need GFS for the 
shared data but the rest, I don't need anything but standard storage. I'll 
maintain a cluster of web servers which use GFS to share their pages/images 
but I could use this aggregator idea for the larger scale media storage. 

I had somehow gotten a little too caught up in GFS and I was basically not 
thinking anything beyond that. This makes things so much simpler than where I 
was heading.

> I suspect that possibly overkill. It's NIC I/O you'll need more than
> anything. Jumbo frames, as big as your hardware can handle, will also help.

Doesn't NIC I/O take up a lot of CPU time?

> There is no reason why the aggregator couldn't mind it's own exports,
> and run as one of the client cluster nodes.

I just mean for fail over. It might be nice to have a little redundancy there.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]