amazon have just released ebs, the final piece of technology that makes their ec2 platform really viable for running lamp stacks stuck as drupal.
ebs, the "elastic block store", provides sophisticated storage for your database instance, with features including:
- high io throughput
- data replication
- large storage capacity
- hot backups using snapshots
- instance type portability e.g. quickly swapping your database hardware for a bigger machine.
amazon are quickly rectifying these problems, and recently announced elasic ip addresses; a "static" ip address that you own and can dynamically point at any of your instances.
today amazon indicated that persistent storage will soon be available.
backups are boring, but we all know how important they are. backups can also be quite powerful when working with xen virtualization, since xen allows for convenient back-up and restore of entire systems.
i've recently been working on a flexible, general-purpose script enabling incremental backups of complete xen guests, optimized for secure, distributed environments;
xenBackup. if you're working with xen, you might find it useful.
xenBackup script leverages open-source components like ssh, rsync, and rdiff-backup to create a simple, efficient and functional solution.
in this article we get a sense of lamp performance on ec2 by running a series of benchmarks on the drupal cms system. these benchmarks establish read throughput numbers for logged-in and logged-out users, for each of amazon's hardware classes.
we also look at op-code caching, and gauge it's performance benefit in cpu-bound lamp deployments.
for some applications, a bridging configuration works better. you can set this up as follows:
there are many ways to setup xen, but i've put together a simple step-by-step guide to get a working xen system based on debian etch. easy as pie.