AWS: Just one thing…

Of course it wouldn’t be very British to be unequivocally positive about something (see the last post on AWS) so here’s a bit of a gripe about Windows on EC2 so I can remain in character.  But there’s a solution here as well.

EC2 instances of any flavor are not much use without persistent storage and that’s what the Elastic Block Store (EBS) provides.  On the face of it, EC2 + EBS = Done, right?  Well it is if you are willing to attach volumes manually each time you start an instance and then login to each instance to make sure the volume has been attached using the drive letter you want.

In Linux, the second problem never arises because they are mounted using a path like /sdb/myvol and you can easily add a routine into the boot process to call out and use the Amazon Web Service API to ask it to attach a volume.

In Windows you can also start a task when the machine boots using the Task Scheduler.  One of the Task Scheduler options is to run a task when the machine boots.  Great.  However, my experience is that its a but hit-and-miss whether the persistent volume you loaded last time as the E: drive will be the E: this time.  Maybe it will be the D:

 So the attached code (EC2Startup binary and source code) is for a utility called EC2Startup.exe.  This and the supporting DLL you save into a folder and have the task scheduler run it at startup.  Then bundle yourself a new image and when you start it you will be able to control what happens at startup.

The idea is that you pass configuration information to the EC2Startup program as User Data, one of the fields you can set when an instance is started.  This way, each instance started from that image can be given its own instructions, for example to attach a specific named volume.

The .exe has a configuration file (EC2Startup.exe.config) which can contain the parameters you want the program to run.  While you can set parameters in the config file you’ve saved into the bundled image if you do so each instance generated from an image will use the same parameters.  However parameters passed by User Data override those set in the configuration file.

The user data set is, infact, just a configuration file but one that is read explicitly at run time.  Here’s an example:

<?xml version=”1.0″ encoding=”utf-8″ ?>
  <add key=”volume” value=”vol-b5b551dc/e”/>
  <add key=”accesskeyid” value=”<your access key>”/>
  <add key=”secretkeyid” value=”<your secret>”/>

The EC2Startup program is written using C# and this is a standard .NET configuration file.

Unless you have other requirements the only parameters that need to be set in the user data is your access id, secret and the id of the volume you want to attach.  The access id and secret are required or the EC2Start program will be unable to authenticate the request to attach the volume which will then fail.

The EC2Start program will also try its very best to make sure the drive is attached using the drive letter you specify.  The drive is specified as an optional element in the volume specification.  By default the volume you attach will be added after existing EC2 instance volumes.  The number and size of EC2 volumes varies by instance size.  For example the m1.small size has 2 EC2 drives.  C is the system drive of 10GB and D is an ephemeral 160GB drive.  An m1.large has a 10GB C drive and two 250GB ephemeral drives mounted as D and E.

I say mounted as D and E but that’s not quite correct.  If you attach a volume before the EC2 boot process is fully completed (that’s the EC2 boot process of which booting Windows is just one step) the drive designation of the attached volume will depend upon the volumes the EC2 boot process has mounted at that point.  Drive C will always be mounted but all other bets are off.

It’s also true that the Task Scheduler starts its boot task before the overall EC2  process is complete and before EC2 has started mounting the ephermal drives.  If left unchecked the EC2Start process would mount the volume(s) requested in the user-data with an arbitrary drive letter.

Instead the EC2Start program waits until the EC2 drives are mounted and then mounts the requested volumes.  This means that the program will,  by default, mount volumes as E or F or some higher letter depending upon the number of ephermal drive EC2 mounts.  This does mean you should not specify a letter for the volumes you mount that will be have been taken by the EC2 drives.

The EC2Start program uses the DISKPART utility to review the ephermal drives mounted by EC2 and the letters assigned to them.  When the EC2Start program uses the EC2 API to attach a volume, the attached volume will be mounted as the next available drive.  If this is not the requested drive letter the EC2Start program will call the DISKPART program to remove the current drive letter assignment then assign the requested letter.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.

Other Posts

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Be the first to leave a comment!