How do I autoscale windows servers w/ amazon ec2

Question

I'm building a distributed app which consists of a load balancer, web-server, database server, messaging queue, and backend workers. Workers consume messages off the queue, perform tasks and then update the database server. Ideally I'd like to have the ability to scale the workers based on some metric. I'm familiar with ec2, s3, cloudfront, but am new to VPC and auto-scaling.

My question is this: How do I go about setting up autoscaling windows servers based on a metric that I define. I have setup windows servers before on ec2, it's painful to RDP in, install cygwin, then ssh in, not very scalable IMO. I'd like them to be ephemeral if possible so I can save money on usage by scaling up and down. Any ideas / advice are greatly appreciated.

Thanks

Solution

Your link to how to create CloudWatch Alarms is indeed the mechanism you will wind up using if you go the Amazon Auto Scaling route. However, as you state yourself, setting up Windows servers can be quite painful -- not only is connecting to them and getting them up to the state you want rather slow, there is often also a considerable delay just getting them up and running in the first place (see Speeding up launch of Amazon EC2 Windows instances, for instance -- it's horrible).

To mitigate the pain a bit, you can create a custom Windows AMI. This lets you install your software on the machine so that it's already there when the instance comes up. Chef, the infrastructure management framework, works with Windows, so you can also go that route. Anything that makes life easier for you! If you combine the two, you can use Chef mostly for configuring software that you've already installed, saving you even more time.

However clever these approaches may be, there is still the slowness of getting Windows up and running on Amazon. If what you are auto scaling cannot deal with these delays and the instances not being up and running on time, you need a solution that can help plan ahead. Amazon's own CloudWatch service is reactive in nature, and lacks the ability to estimate future load. This gap in functionality is what caused Netflix to develop their own in-house predictive auto scaler Scryer (which is not available to the public), and what Elastisys offers in elastisys:scale, a product whose private beta one can request to join right now.

Full disclosure: I work for Elastisys AB, a company that creates auto-scaling solutions based on research performed in the Umeå University (Sweden) cloud research group.

Comments

[Grumpy]

You seem to have same avatar as I do. :d

[The Internet]

it would appear this is what i want docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/…

[The Internet]

llarson, appreciate your info. I'm going to make a custom AMI to clone instances from. I want servers to be ephemeral, meaning the process of cloning, booting up a medium instance, pulling down the binaries from a build server, connecting to the database and working, then stopping itself to be automated. I'd like to have one server per customer if we can do the steps above quickly. I just need the start / stop of medium instances to be blazing fast, not sure I need predictive analytics just yet.

[llarsson]

In that case, @TheInternet, I think your best bet will be to do the steps outlined above: custom AMI with all pertinent software (and Windows updates, ugh) pre-installed, automated scripts (don't have to be Chef, you can probably get away with a script that executes on startup). Consider having a few stopped instances ready, I find that the initial provisioning takes longer than booting a stopped one up. Finally, Linux is considerably faster to provision on EC2, your software doesn't work through Wine, does it?

[The Internet]

@llarson, I wish so badly that it worked w/ Wine. The software in question is this: appdb.winehq.org/… I just realized I don't want to pay for the EBS storage either. So everytime a customer wants work to be done a new EBS volume would have to be created, attached, and then the server be spawned. Seems like what I want, just will probably be molasses

[The Internet]

@llarson, unless you think that running SolidWorks inside a Windows VM (Like virtualbox) on Linux box would be faster. That's getting a little carried away maybe.

[llarsson]

I have a really hard time seeing that a VM within another VM, running on Amazon of all things, would be any faster than just doing the CAD rendering stuff by hand. ;) Since speed seems to be important, explore if you can have a few Windows instances up and running all the time and have them chew off work units from the queue. The instances you have just reset themselves appropriately between work units (I guess that Customer A does not want their files to still be there when the instance works on Customer B's tasks).

[The Internet]

When new files are pulled down the work environment is cleaned (rm -r oldFiles) and the new files are handled accordingly. The only reason I'm hesitant to have a few servers running all the time is that some jobs might take a long time and could clog up the queue. If everyone had their own server, even if they had to wait 4-5 minutes for it to spin up, they wouldn't even know other people used the site. Of course there could be a public and private queue that routes based on file size, but now I'm just adding more work.