Well....I could throw away EBS requirement for the application servers. I did it today. Mainly it was required for making sure I do not lose log files they generate. Well...I can copy the files periodically to a gluster share.
BUT...the problem is still here. For example my gluster master resides on a server with an EBS. this EBS might also hold files of a lucene index used by a search server connected to that same EBS. In all these cases if I synchronize that server connected to the EBS....the new one will not be available untill that same EBS was mounted to the new server. Even if I have several instances for redundancy/relication/load sharing....the synchronize all according to the way I know it (might be wrong) might concurrently move EBS volumes to the new instances leaving with some downtime for the search services (accessing the index on the EBS) and gluster (the master share is on the EBS). Seems like I am stuck here... 2009/3/17 Frédéric Sidler <[email protected]> > I don't know if this help, but except the application files, all of our > files are stored on S3. > JS and CSS are uploded to S3 at deployement process. And then they are > served by CloudFront the Amazon CDN. So no more latency for static and no > more files served by the application. > All other uploaded file are directly uploaded to S3 when they are submitted > by users. > > I can read about gluster for a long time in these group and I don't know if > this makes a big difference with a gluster installation, but this work very > well with 1, 2, n app instances. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
