I'm going to try to get Aegir working with Project Mercury. Just wondering if anyone else with past experience would like to collaborate on some best practices and perhaps getting those into a wiki with me?
Just going to start collecting bits here:
Resources
Mercury 1.0 Install Wiki
• http://groups.drupal.org/node/50408
Discussion about Mercury + Aegir
• http://groups.drupal.org/node/35984
Aegir Install Instructions
• http://git.aegirproject.org/?p=provision.git;a=blob_plain;f=INSTALL.txt;...
• http://www.mig5.net/content/video-installing-aegir-04-alpha5
========
Got stuck setting up the virtual host for Aegir on the Mercury Install.
Added NameVirtualHost 75.101.157.185:80 to apache2.conf in /etc/apache2
Create aegir.xtrgood.com in /etc/apache2/sites-available
<VirtualHost 75.101.157.185:80>
ServerName aegir.xtrgood.com
ServerAlias www.aegir.xtrgood.com
ServerAdmin admin@xtrgood.com
DocumentRoot /var/aegir
</VirtualHost>Created sym link in /etc/apache2/sites-enabled
aegir.xtrgood.com -> ../sites-available/aegir.xtrgood.com
Comments
Sweet
I will clean up my install docs and paste it up here, ive mapped out almost everything needed but multi-core solr... doc is two methods, one being a fresh install and the other a migration of existing mercury-aegir rig to another server. Also it includes moving db and webroot to EBS drives with consistent snapshots. Its pretty easy once you have all the steps to look at. I just have to clean out my personal info and generalize it with more links and added tips on the various steps. Will post what I have up asap & we can kick it around and improve it.
To me the coolest thing we could do would be a branch of the mercury bcfg2 method that does almost all the steps for us on boot; then all we have to do is the ebs trickery and then move our sites in. Still I think mapping things out here is the smart first step & will give us the reference point we need for bcfg2 goodness.
Cheers!
Great!
How are you getting the consistent snapshots? Are you using ext3 with Jaunty? My limited reading suggested this isn't straightforward.
No im using XFS, I couldn't
No im using XFS, I couldn't bring myself to use ext3. There were three things that haunted me with xfs + jaunty. One was a known bug (on the 32 bit) that caused the server to be unresponsive on reboot, two I was using an xfs raid which kept chewing the data if the slightest thing went wrong, and three (most silly) with an array and using mdadm I did not properly configure the array to start upon reboot, just the fstab is not enough; you have to rebuild the conf file. So while I did have a lot of trouble it was mostly just me learning something new and fucking it up a lot lol.
For me at least the raid was giving me so much trouble I decided that since im only using the 64bit servers I should be safe from the known bug, which so far I have had no trouble at all. Instead I use multiple drives... One for all the database stuff, one for the webroot and I might bring in more yet. Its nicer separate IMO.
I wish that Amazon would release the api they use for their db service, seems it snaps in very small intervals and they dont charge anything for storage, I may end up using their db if I get sick of maintaining and/or more obsessive about the auto snapshotting. So far things have been smooth though, cant complain.
Interesting
I've been testing on 32 bit, with production going to 64. Didn't realize this bug showed only on small instances. Good to know.
As for multiple volumes, what do you see as the advantage? I'd also like to back up other things like solr's index, and logs. And it would be nice to assume any other tweaks I've made are persisted, like upping java limits and installing munin. In the event of a crash, it would be nice not to have to run through a manual reinstall.
I like to keep at least the
I like to keep at least the db separate from the webroot so its faster when snapshoting and its easier to maintain the snapshots when they are apart.
You should be able to keep persistence of the changes you've made to config files in several different ways.
One - would be to press out a new AMI from the server once you get it to the state you like.
Two - press out an EBS bootable AMI which you can also then run snapshots on.
Three - save copies of all pertinent changed files to one of your drives that gets backed up, so they can be moved into a fresh instance if need be.
I prefer option number two. Though ive not done it yet personally.
Cheers!
Option two is my current thinking
Just need to figure out what I don't need to persist, to minimize the churn. BTW, I would think it would actually be more effort to maintain multiple snapshots in parallel. The db and webroot are pretty much joined at the hip, at least in my case. But I can see the speed issue.
I just took a quick peek at your wiki entry - very excited to see xfs working with consistent snapshots on the 64 bit instance. Thanks very much for that. This is getting close to reality!
I agree I was a bit taken
I agree I was a bit taken back by this concept... I thought "I want it all to persist!" ...which really I still do, thats why I like option 2 the most as well.
The consistent snapshot freezes and flushes the drive when its backing up the one that has mysql on it so I found it went a bit faster when there was less on the drive. Chances are the webroot will be a lot bigger and take longer to snapshot. Plus I would think read/write performance is a tad bit faster too. I am also toying with the idea of having the db drive backup a lot more frequently than the webroot drive & maybe a daily snap of the AMI EBS boot disk when I make it too.
Good point
Hadn't really considered how long that freeze might be. Any sense of it?
I like your idea of a less frequent (maybe nightly) full system snap, to get the system back up and running quickly when the red lights and horns are blaring. I've got the webroot (with the exception of files) under source control anyway...
Let's Use the Wiki
Hey Macrocosm,
Cool. Looking forward to getting the documentation sorted. If it's cool with you, let's use the wiki that I set up:
http://groups.drupal.org/node/55033
Thanks for your help!
Perfect, Ill try and get it
Perfect,
Ill try and get it cleaned tomorrow and drop it in ... then we can fill in any holes and streamline it wherever it needs it.
Cheers!
Its posted
Ive turned your wiki page into the main Aegir + Mercury page and added a link to the first set of install instructions for a fresh install. I think its best to keep relevant bits in their own wiki pages so we dont end up with one giant page.
Its still a little rough but I know it works because Ive set up Aegir + Mercury a ton of times in my testing.
It's is as boiled down as it gets until we work out a bcfg2 branch and/or public ami with all these goodies in them.
Built a new Mercury large instance with 200 GiB EBS RAID Volume
I have been using Mercury for some development as my site is not yet live. Yesterday I spun up a large instance and created 4 50Gib Volumes creating a 200 GiB for the database which I moved already. Macrocosm, thank you for your contributions as I will take a look at your docs for moving the web root to another EBS volume. I think then I'll create the snaps and start to work on developing the site.
Thank you to all - chules
I am going EBS Nuts
Need some help here. I used the "EBS as a RAID" how to at http://groups.drupal.org/node/36750 to create the 200 GiB RAID Volume and move my database as per the instructions. I then tried to use Macrocosm's wiki page to figure out how to move the webroot drive by creating another drive and using the following from the directions:
echo "/dev/sdo /vol xfs noatime 0 0" | sudo tee -a /etc/fstab
When I tried to enter the next command , sudo mkdir -m 000 /vol, it failed because /vol was already there as per the instructions at /36750. So I removed the line added in /etc/fstab referencing /dev/sdo and deleted the volume.
My question is how do I move the webroot to the /vol I have already created using node/36750. I am new to this and it's really is just adding a step into that article "EBS as RAID" that move the webroot. Any help would be greatly appreciated
Chules
you can call that drive
you can call that drive something else if you've already used it for your db & the raid. Name it whatever you like and adjust the commands and other bits to reflect the name you have chosen.
Same thing goes for Aegir you
Same thing goes for Aegir you can and probably should change the username's drive/dir names and such to your liking. Also disable root access once your done deving and create some system users that have sudo permissions, there are ubuntu instructions for that bit.
Sweet
Looks really cool! Looking forward to getting a little time to spin up a server. Thanks for putting this all together!