The Karmafoundation

The Karmafoundation Scope

Server Build, Administration

Project scope: Provide written evaluation for server requirements, Amazon EC2 suitability, and requirements for ongoing server support.

Having prepared a report on the server requirements for The Karma Foundation’s new member social network site, along with confirmation that the proposed
Amazon AWS service EC2 would be a suitable option, I was asked to build a new server and configure it ready to run as a production server

  • Preparation of a server and site requirement evaluation report
  • Preparation of server maintenance evaluation as ongoing support structure
  • Server build using AWS EC2 service
  • Server tuning optimisation for client site
  • Moving of development site files to new environment
  • Configure backup scripts and email services
  • Prepare new sandbox server for ongoing development work

The Karma Foundation front page
Site development and design realisation by

Reports and Evaluations

The first phase of this project was to evaluate the Karmafoundations requirements for a production server and any ongoing server/site administration that might be required. These were submitted for consideration and approval before moving forward.

Server build

After initial reports submitted were approved phase two was of the project began with creating a new AWS instance and choosing a bare bones Cent0S OS to act as the base server.

A view of the aws console showing the volumes in use

The server was configured with the basic required applications, PHP – upgraded to latest stable release – MySQL and PHPMyAdmin, along with the required Apache modules.

Having configured the server to requirements, a base AMI image was created to preserve the server configuration and to keep it available as a private image for Karma.

Backup scripts were configured using Rsync and Rsnapshot to provide a rolling automated backup of the main site files, these
being rotated on a hourly, daily, and weekly basis to conserve disk space but provide a rollback to a close point in time in order minimise any data loss.
As well as the file backup a script was placed as a Cron job to automatically backup the databases on a nightly basis.

To maximise the ability to recover from server failure I decided to implement separate volumes for the root server disk, the backups, and the databases.
Having separate volumes meant that I could mount them separately and that they would survive a server failure by simply and quickly re-attaching them to a new server instance, thereby ensuring the minimum of downtime.

There was also the requirement for a replacement development test bed and this was provided by creating a copy of the server from snapshots so that we had a mirror of the production server.
Using database backups and a deployment of the site files from the project SVN repository we were able to create a exact replica of the main server; later I
also tested that the backup volume could be copied and attached to the test server to demonstrate the ease of moving files around when required.

Issues & challenges:

One hurdle to overcome was that of dealing with a very large database comprising of some 2000 tables which caused issues
for the backup scripts and caused them to fail on attempting to hold open too many file handles. Careful attention had to
be given to modifying the server parameters to deal with this to ensure that backups ran through successfully.