libertus

I have a simple task; migrate a bog-standard LAMP from a co-located physical server (bricks and mortar) to the Amazon Elastic Compute Cloud (EC2) architecture (virtual). The physical server provides core business services so the success criteria for the migration are minimising functional distortion and minimising down-time. In other words, a virtually seamless transition.

Getting Set Up

I already have an Amazon account so I signed on to it and signed up for an Amazon Web Services (AWS) account then an EC2 account. I was asked for payment details during the EC2 account sign-up. EC2 operates a capacity-based charging (CBC), pay as you go (PAYG) charging model. To effectively use EC2 services, a Simple Storage Service (S3) account is also required, which is also PAYG but should cost nothing if used only to supply machine images and instance storage. When I went to sign up for S3, I was told I already had access. First step done.

Getting Genned Up

I’m already comfortable with configuring a machine from scratch into full service. With a physical machine, the initial steps involve being with the machine, providing power and network connections and booting the operating system installation image (usually from CD). With a virtual machine, these steps are not only already done but one has a choice from a catalogue of different configurations that in the real world would fill a warehouse. Choose server type (big or small), operating software (anything free) and it’s there, pretty much without having to wait. A physical installation takes tiiiiiiiiiiiime, mostly waiting.

I need to learn how to command the Amazon system to commission, reconfigure and decommission my virtual machines, up to the same point at which, during a physical installation, I would remove myself from the machine to a console somewhere more convenient.

I already know the software that needs to run on the virtual server and I know that some of it is sensitive to the public IP address, so I need to learn how to manage the network configuration.

Authentication

EC2 is a secure service requiring strong authentication. I generate and store the necessary credentials.

Booting A Machine With My Operating System Of Choice

I RTFM.

I have to download some command-line tools written in Java that are configured for authentication using environment variables.

On the other hand, the resource centre links to a web interface called AWSZone.com, which I thought might be easier, but doesn’t work when I click through.

Hmmm… but there is a Firefox extension. That’ll be my first choice. If I don’t have to learn the commands right now, so much the better?

Elasticfox is a full-page application accessed from the Tools menu. Added my credentials to it, waited for a list of machine images to appear, found one with my operating system of choice using the search box, then didn’t launch an instance because I still have reading to do. In the meantime, I downloaded the command-line tools.

Configuring Network Access To The Machine

I generated a SSH key pair for my upcoming first instance and imported it into PuTTY. Now I can start an instance.

I click “Launch” in Elasticfox and get presented with a huge form asking lots of questions. The command-line tools looked a lot simpler but I’ll read on.

Hmmm… How Much Will This Cost Again?

The manual finally clarifies the last variable in the charging model. As soon as I start an instance, I have to pay per hour, per CPU, even when the instance is idle. That isn’t capacity-based, it is availability-of-capacity-based. A small instance running 24×7 (the minimum requirement for a core business server) at 10 cents a unit costs 75 bucks a month.

Back To Basics

Having checked that the cost is acceptable and now knowing that I can create and destroy machines at will with a configuration of my choosing, the next step is to figure out how to turn one of these virtual instances into a clone of the server to be migrated. The physical server has particular characteristics that a virtual instance need not necessarily have, for instance permanent storage.

Assessing Storage Requirements

The physical server’s storage is used for the operating system, monitoring data, distribution-supplied software packages, vendor-specific configuration, vendor-supplied software, customer data and company data.

The data is precious and must not vanish with the instance. Data must be in a store that persists instances yet can be easily attached to and detached from any instance. This implies some kind of mountable shared filesystem model that I’m sure Amazon’s S3 service will provide.

The operating system and certain distribution software will be automatically available on creation of an instance, leaving the vendor-specific configuration including software packages, vendor-supplied software and the data to be made available before an instance is ready for service. I’m sure Amazon’s EC2 has instance images with post-creation hooks.

Still more reading to do…

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.