Amazon


27
Oct 09

Competing in a Commodity Hosting Market

We knew it was going to happen but perhaps not so soon. Today Amazon announced that it would be reducing it’s pricing on EC2 linux instances by 15%. That’s a pretty significant cost reduction but we also have to factor in a whole bunch of other costs to figure out what their strategy seems to be.

Unlike with most bundled VPS services where you get a certain amount of disk space, bandwidth, memory and CPU resources, the Amazon model breaks things down into separate categories. You pay per use on everything. Instances per hour, Bandwidth and Storage per Gig, etc. Under this model it makes sense to shift your revenue to things that are higher margin. What that means is that with enough scale, you could almost afford to break even on the server instance and make money on other things – like bandwidth.

This is similar to the concept of “Freemium” in the Web Apps world. You get to use the basic version at a heavy heavy discount (in some cases free), but the add-ons, extra functionality, etc results in having to pay. The difference is that in the harsh reality of hosting, it costs real money to run a server.


20
Oct 09

How to move a Virtual Machine From EC2 to VirtualBox or KVM

There have been quite a few requests on forums and blog posts on a few sites we frequent asking someone to figure out how to move a virtual machine from EC2 to VirtualBox or KVM. We’ve got quite a bit of experience working with KVM so we figured why not try our hand at importing a virtual machine template from the Amazon AMI repository so that developers or sysadmins could run them in their local environments. We’ve already written a howto on importing an AMI from Amazon, so you may want to read that first, but this howto also applies to just creating a KVM or VirtualBox image from a linux filesystem of any kind. Right now this particular method only works with Linux but there are more OS agnostic (and much slower) methods for transposing virtual machines. So without further delay, let’s get started.

You’ll need at least 15 gigs of free space to make this work.

1) Download and unpack an AMI from Amazon

You can learn how to do that here, or if you have sufficient knowledge you can build a full linux filesystem

2) Prepare a new raw drive file

We’ll create a file backed drive, set it up so we can partition it and create a new filesystem.

Create the file by using the ‘dd’ command.

dd if=/dev/zero of=newimage.raw bs=1M count=10240

Add it to a loopback device

losetup -fv newimage.raw

Partition the file backed loopback device. For this we’ll just create one partition which is the whole disk. Make sure its bootable.

cfdisk /dev/loop0

Write the partition and exit

Now we’re going to create a filesystem on the partition we just created. Please note that there’s a problem with the way mfks works. When trying to automatically determine filesystem sizes on loopback devices it makes a mistake. So for this we need to do a few things.

Find the partition beginning, ending, number of blocks, number of cylinders, and blocksize

fdisk -l -u /dev/loop0
 
Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
 
      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63    20964824    10482381   83  Linux

Create a new loopback device for the partition. We do this by calculating the beginning of the partition x blocksize

In this case that’s 512 * 63 (actually in most cases thats what it is)

losetup -fv -o $((512 * 63)) newimage.raw
Loop device is /dev/loop1

Remember those numbers we grabbed earlier using fdisk? Plunk them into this formula. For our example:

( END – START ) x Units / Block Size
If you don’t know the block size use 4096. That’s “standard” and usually the size configured on most ext2/3 filesystems.

So for us it’s this:

echo $(((20964824 - 63) * 512 / 4096 ))

This gives is the number of blocks we need to use in our next command, which is used to create a filesystem with a blocksize of 4096 on /dev/loop1 of block count 2620595. You have to specify the blocksize, otherwise mkfs will try and automatically determine a bunch of things for you which will just break things.

mkfs.ext3 -b 4096 /dev/loop1 2620595

3) Copy & Prepare New Root Filesystem

You can now mount this newly created filesystem somewhere and copy a root filesystem into it. If that filesystem happens to be a Xen image from Amazon, you can use that.

mkdir -p /mnt/loop/1
mount -t ext3 /dev/loop1 /mnt/loop/1
cp -a /some/root/filesystem/* /mnt/loop/1/

Xen virtual machines run with a special kernel that can run under KVM using Xenner, but not other platforms like VirtualBox, so we’re going to copy a real kernel in there. You can use one from another linux system if you want, it will work fine, but you should use one that has the modules required by your virtualization platform. We already have a KVM tuned kernel and initrd available so we’re going to use those.

Note: If you’re going to just copy in the initrd and kernel then make sure the initrd includes all of the modules required to boot your machine.

cp -r /some/boot/filesystem/* /mnt/loop/1/boot/

You should now see a the kernel, initrd and the grub directory in there.

Edit the menu.lst and make sure the root= is set to /dev/sda1

vim /mnt/loop/1/boot/grub/menu.lst

Edit the /etc/fstab in your mounted vm

vim /mnt/loop/1/etc/fstab

Because amazon’s best practices involve setting a random root password, which gets overridden at start time, you’ll have to solve that little problem.

chroot /mnt/loop/1
mv /etc/rc.local /etc/rc.local-old
passwd root
exit

5) Setup Grub on the New Drive

Now unmount /mnt/loop/1 and delete the loopback device for the partition (the one with the offset) so we can setup the bootloader. Grub complains about installing the MBR code when the loopback device is still active on the partition. Leave the loopback device for the entire drive. We’ll need that to get some numbers from fdisk.

umount /mnt/loop/1
losetup -d /mnt/loop1
fdisk -l -u /dev/loop0
 
Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
 
Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63    20964824    10482381   83  Linux

Make a note of the numbers that were presented here. We’ll need the following to setup grub

  • Cylinders : 1305
  • Heads : 255
  • Sectors / Track : 63

These numbers may be different for you depending on the size of partition you created, or a whole bunch of other variables. It’s important to remember these values because we’ll need them for our next step, which is to setup grub.

The following lists the set of commands required to setup the bootloader on a file backed disk over a loopback device.

grub --device-map=/dev/null
device (hd0) /images/newimage.raw
geometry (hd0) 1305 255 63
root (hd0,0)
setup (hd0)

Here’s what that looks like in the grub dialogue:

grub --device-map=/dev/null
 
Probing devices to guess BIOS drives. This may take a long time.
Unknown partition table signature
 
[ Minimal BASH-like line editing is supported.   For
the   first   word,  TAB  lists  possible  command
completions.  Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> device (hd0) /images/newimage.raw
device (hd0) /images/newimage.raw
grub> geometry (hd0) 1305 255 63
geometry (hd0) 1305 255 63
grub> root (hd0,0)
grub> setup (hd0)
 
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  17 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub>quit

Conclusion

Yay! All you need to do now is delete all those loopback devices attached to your file, and boot it up in either KVM or VirtualBox
Hope you found that useful.


16
Oct 08

Hosting Apocalypse

Behold Sinners! The Apocalypse Aproacheth. No in all seriousness if you run a managed hosting company then your time is officially ‘up’. You won’t survive the coming hosting Apocalypse. Here’s why.

There are a few companies you may have heard of building large compute grids for consumption by the general public. They’re calling them their Cloud Computing products. IBM is building BlueCloud, Microsoft is building the Mesh, Amazon already has EC2, and Google has AppEngine. AppEngine is in a slightly different category than the others and the BlueCloud details are sparse, but they’re still worth mentioning. Of more immediate interest are Amazon and Microsoft’s solutions.

Microsoft is currently building their famous 300,000 server Data Center in Chicago. That’s roughly 3 times the number of servers that Google has. Microsoft has also announced several other Data center projects – each worth about $500 Million. It’s fair to say that that’s a lot of computing power, and it’s not all for MSN – Microsoft is planning on providing their platform in the cloud.

The real question is what Amazon will do when the Windows Cloud comes online. Microsoft has enough money in the bank to provide their 300,000 servers to customers for *years* without earning a single cent. That implies they can offer services at super low rates; Low enough to at least compete with Amazon’s EC2, which will support the Windows Server OS in fall 2008.

What happens with two huge cloud hosting companies get into a price war?

In the interest of self preservation they won’t make their services commodities – at least right away. But it won’t even matter. When you’re as big as Amazon, Microsoft, Google or IBM, you can afford to buy servers in such massive quantities that you could make money selling compute time for 10$ a month. The hosting space will change forever, because Amazon will eventually drop their prices by an *order of magnitude* and that has dire implications for the rest of the Mom’n'Pop hosting companies.

If thousands of companies can’t compete with Microsoft or Amazon on price, and they can’t compete in terms of convenience, then why would anyone use them? If you have to buy individual servers, or even servers by the rack, then you’re not going to get the price you need to be able to compete. You also don’t have access to the handful of specialized individuals and hardware required to make things work on such a grand scale.

The only answer is for all the smaller players to band together – to create a Federated Hosting environment, where together they can provide services that begin approaching levels of service and power that the Big 4 will offer.

Either way, we’re in an interesting period in the industry. Computing and the infrastructure of technology has become such a requirement for the economy that it will eventually become a general utility. The real question is who will be around.

Do you think it’s the end? We’re working on the answer, and your opinion is important.


3
Oct 08

How to move Servers Between Xen and Amazon

I’ve been working on a project that lets you quickly move systems between your private Xen implementation and Amazon’s EC2 service. There are a lot of hurdles to get this to work, and most of them are surrounding how Amazon doesn’t let you download a Kernel or Ramdisk image out of S3 unless you’re the owner. You can download someone elses image if you’ve saved it as your own but you still can’t download the kernel and ramdisk. Also, EC2 has specific requirements for how the image is built. Here’s how you can get your image out of Amazon and run it locally on your own Xen hypervisor. I will assume you are already using Amazon Web Services and have created an account. If you haven’t then sign up.

Amazon calls their instance images Amazon Machine Images or AMI’s. If you want to be able to grab one of the many images from Amazon you can use download the Amazon AMI tools and AWS tools then do the following. You can download the tools here

Find and Download the AMI

$: ec2-describe-images
IMAGE   ami-cc6386a5    ubuntu-hardy-ruby/image.manifest.xml    848278689040    available       private         i386    machine
IMAGE   ami-386c8951    ubuntu-ruby-lapack/image.manifest.xml   848278689040    available       private         i386    machine
$:

Fields 3 and 4 contain important information. For this example I’m listing the images that I own. Optionally you can provide a switch that will list all Amazon images by including ‘-a’ to the end of the ec2-describe-images command.

Field 3 is the unique identifier for the AMI, and field 4 is the bucket and AMI “manifest” – or a file that describes the AMI. Because users can specify the name of the manifest, you should pay attention to this value when trying to run the next set of commands.

The AMI tools from Amazon include a utility called ‘ec2-download-bundle’. This will download the manifest file from the bucket, parse through to see what other files it needs to download, then it will reassemble the AMI image locally, and check its signature. The AMI’s are encrypted in small (usually 10 meg) chunks. The signatures for those chunks are also included in the manifest.

To download the first AMI listed above, run the following commands

mkdir 'image-to-download'
cd 'image-to-download'
ec2-download-bundle --bucket ubuntu-ruby-lapack -m image.manifest.xml --access-key $AWS_ACCESS_KEY --secret-key $AWS_SECRET --privatekey $EC2_PRIVATE_KEY

That will start downloading the bundle to your local system.

Rebuild the AMI

Now we have to unbundle the files

ec2-unbundle -m image.manifest.xml -k $EC2_PRIVATE_KEY

This will decrypt and reassemble the image from all the individual components in the list

Now you have an image named ‘image’ in your directory. You can take a look at this file by mounting it

mkdir /mnt/image
mount -t ext3 -o loop image /mnt/image
cd /mnt/image

If you’re lucky there will be copies of the kernel and perhaps the ramdisk in the /boot partition. Otherwise you’ve got to do something really tricky : You have to guess as to what kernel will work the best. Thankfully we have a good understanding of what’s required to boot one of these images.

If you’ve created an image for Xen already then chances are your kernel will work just fine, but your ramdisk might need some adjusting. A trick you can use is to chroot to the /mnt/image folder, specify which modules you want loaded and rebuild the ramdisk – then exit the chroot, copy the kernel and ramdisk out of /mnt/image and you’ll have all the components you’ll need.

I know what you’re thinking: That’s a lot of work / guessing

You’re in luck. While there are a couple sites for sharing pre-built Xen images, the community is nowhere near as large as the Parallels or VMware ‘appliance’ sites. Jailtime.org has a hanful of images but they don’t follow any sort of standard, and the disk layouts / configurations aren’t compatible with Amazon’s EC2.

LayerBoom has a Xen image that is completely compatible with Amazons AMI format, and it can run in your own environment. This means you can copy a system into Amazon from your test environment without any hassle. It also works with the Eucalyptus project, and can be booted in xVM server as well (Instructions are coming)

Download the Xen package

url: http://layerboom.com/files/xen/images/centos52-20080930.tar.gz
md5: d54a83fc22f1ec052db6ebe3c258ee45

u/l :root/password