Hi there, I was wondering if anyone had any experience doing this.
As a project for work I am interested in building a low cost scalable SAN so we can apportion disk space off to our customers. The design involves using a distributed file system (in this case GlusterFS), but unfortunately Gluster doesn't support file system quotas nor does it provide support for Windows and we can see a beneficial user experience using block level storage for our customers. The idea involves creating files of X GB in size off of this glustered filesystem and finally exporting them via vblade. Additionally the system must remain redundant which therefore involves concurrent vblades. Currently for this I have simply ran vblade using the same shelf/slot against multiple machines (therefore advertising the same shelf/slot for the same file from multiple machines). I have tested this setup with gluster in a virtualized environment. Taking two machines advertising the same file using the same shelf/slot and then formatting/mounting the specified vblade that comes up on the initiating machine. The results are promising - so far! Taking off one of the vblades tends to stall the mounted filesystem I am using but it looks to run aoe-discover again to find another vblade using the same shelf/slot and thus continuing where it left off. You could consider what I am doing is the opposite of clients sharing storage, instead servers sharing storage and only one client accessing it (I am aware of the limitations / planning necessary to run block level storage concurrently on multiple clients and I dont ever intend to do this). My questions are as follows: a) When an initiator has found its target will it "remember" and always send to the same MAC address when sending future requests? Is there a timeout with this remembering assuming its there? Plus will it rediscover in the event it cannot find the mac address again? b) Will running vblade off of a NAS level filesystem, be it Gluster or NFS be problematic? (bandwidth/latency issues aside for now - im thinking more about locking) c) Will concurrently running vblades in this manner cause all kinds of unpredictability - again, locking issues? My idea revolves around the following presumption that a mac address once known to have the aoe target your after is always used. Another idea which is similar is to run vblades on only one machine and have a hot standby ready to failover in the event the master comes unresponsive (this eliminates running vblades concurrently on servers). This of course still leaves me with the potential issue of running vblades from files that are actually on a NAS themselves. Anyone have any thoughts to share as to whether or not this seems like a good idea and if not why not. I'd love feedback before trying to commit to something that will ultimately fail. P.S I am aware we could offer redundancy by raiding the aoe targets on the initiating machine but in the interests of keeping it simple for our customers i'd like to not do this, plus gluster provides plenty of mirroring capability. Many thanks. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Aoetools-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
