> 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. Mike -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
