No problem. Let me know if you have any questions. I had thought that it could really enhance the Scalr offering, and I am sure you guys will come up with some really cool uses for it.
On Oct 29, 2:46 am, Alex Kovalyov <[EMAIL PROTECTED]> wrote: > Thanks. I am going to investigate glusterfs closer within next few days - > hopefully you will be able to answer couple questions when they pop up. > > Alex > > On 29.10.08 10:41, "mikeytag" <[EMAIL PROTECTED]> wrote: > > > > > Hi Alex, > > > I originally designed our application to use a clustered filesystem > > for things like apache conf files, svn repos, web directories, etc. > > This simplifies incredibly the administration and has been a big plus > > with the move to Scalr/Amazon. You see, if I edit /etc/apache2/ > > apache2.conf I can save it and simply restart apache on the different > > web nodes. Synchronize all isn't required because I serve that file > > off of the clustered filesystem. > > > The filesystem that i am using is known as Gluster. You can check out > > more info about it athttp://www.gluster.org. It has been very > > impressive in our setup, but getting it to work in the Xen/Amazon/ > > Scalr environment was no easy task. They recommend a patched version > > of the fuse module to get better performance, and actually due to some > > weird issue with Hardy on the Scalr AMIs, I had no choice but to > > compile the custom module myself as Gluster couldn't make use of the > > stock fuse kernel out of the ubuntu repos. > > > Gluster is incredibly flexible and you can do all sorts of cool stuff > > like automatic file replication, striping, unifying volumes etc, and > > the really cool part is the more storage nodes and clients you add > > into the system, the faster it becomes. Crazy I know, but check out > > the benchmarks at gluster.org and you can see for yourself. As far as > > Scalr goes I currently have 2 m1.small instances classified as sto1 > > and sto2. Each node has it's own EBS volume attached to it which it > > shares with the cluster. My cluster configuration unifies both of > > those volumes into 1 logical volume in the cluster and if I ever want > > more capacity or performance, I can simply make a sto3,sto4, etc. I > > decided to attach EBS rather than using /mnt because I wanted the ease > > of snapshotting along with the fault tolerance and reliability that > > EBS provides, but there isn't anything to say that these nodes > > couldn't share /mnt with the cluster or any other type of volume for > > that matter. > > > If you are interestead further, I can send you over my gluster config > > settings along with the custom compiled fuse modules that I was able > > to get installed on my Scalr AMIs. > > > Mike > > > On Oct 28, 12:29 pm, Alex Kovalyov <[EMAIL PROTECTED]> wrote: > >> Can you tell more about your setup? What role clustered FS plays, if that's > >> a single EBS volume? > >> Thanks. > > >> On 28.10.08 20:56, "mikeytag" <[EMAIL PROTECTED]> wrote: > > >>> Hi Sam, > > >>> I'll put in my two cents from using Scalr/Amazon over the past month > >>> on our production systems. I originally went with the mysqllvm64 role > >>> with master/slave replication. I too have large databases, around 50GB > >>> or so. My experience was that it would take about 3-5 hours to spool > >>> up a new instance. (About 3 hours to bring up a slave and about 5 for > >>> a master because the master has to re-upload everything it just > >>> downloaded to make sure subsequent slaves have the right data). Which > >>> is mostly attributed to the time it takes to download/upload all the > >>> pieces of the database from S3. The system ran fine until we ran into > >>> a problem where we overloaded the master and the two slaves we had. We > >>> were basically down for an entire work day as I was forced to just sit > >>> and watch /var/log/messages as piece by piece or our system was > >>> restored from S3. This was simply something I could not live with > >>> happening again, so here is what I did. > > >>> A big part of our problem was the fact that our application is > >>> incredibly write heavy. Because of this adding slaves only makes > >>> matters worse because they begin to lag so far behind the master that > >>> they become of no use. This is not an issue with Scalr/Amazon or any > >>> hardware for that matter. It is an issue with the single threaded > >>> nature of MySQL replication. I knew we had to start sharding/ > >>> partitioning and fast. So I fired up a base64 instance and downloaded > >>> the RC for mysql-5.1 which includes partitioning built into MySQL. > >>> Also, rather than using /mnt I decided to add another EBS volume to my > >>> farm and use that. I have had good experiences with EBS and our > >>> clustered file system and was fairly confident that the performance > >>> would be fine for our needs. > > >>> Needless to say, I think I am going to stick with my homegrown > >>> solution to MySQL because that's what I need to do for our > >>> application. I like the fact that I am in control over scaling the > >>> cluster now. Although, I loved the fact before that Scalr took care of > >>> everything for me, it just took way too long. I am sure others here > >>> can give you their opinions and the solutions they have come up with. > > >>> Mike > > >>> On Oct 27, 1:50 pm, sam lee <[EMAIL PROTECTED]> wrote: > >>>> Scenario 1: use mysqllvm (or mysqllvm64) role > >>>> Scenario 2: run mysql on EBS (by enabling EBS on a mysql role and > >>>> setting datadir and log_bin options in my.cnf to point at /mnt/ > >>>> storage) > > >>>> Which scenario is better overall? We need to store "large" database > >>>> and backup frequently. I'm not told how large the database would be. > >>>> We are really cautious about losing data. > > >>>> Scenario 1 seems to be Ok except that when all mysql instances die, we > >>>> might lose data for delta minutes, where delta being rebundle/backup > >>>> frequency. > > >>>> Scenario 2 can cost us more money since each mysql instance will get a > >>>> large EBS. But I assume when they all die, up-to-minute snapshot of > >>>> database is on each EBS. Am I correct? > > >>>> Would it be better for me to wait until hybrid of EBS/LVM based mysql > >>>> roles are available? Is the hybrid being developed? > > >>>> Thank you. > >>>> Sam. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
