The “Big Table” was easy to “pu pu” and say “It does not fit the model”.  RDS is the “real thing” a transactional Relational Database with all the bells and …

IMHO,  we need to start looking at this new model by placing non-mission critical Backup Systems for Fail Over in RDS.  The cost of transfers into RDS is very small.  The cost for running 1 hour a day is cents.  When you need to fail over,  you can launch a HUGE db server and get ton of performance to make up for the remote location if you are “outside” EC2.  If you are “inside” ec2 this is a no-brainier.

1) First Step,  Create an RDS server with RS use a small instance.
2) Each day copy over the “backup” to a live RDS instance.
3) Turn it off.  The RDS makes a Final-SNAP backup on Deletion (read Termination)

On Fail:

1)  Start the RDS on a large server as needed for production, from back SNAP.
2)  You are up and running

COST:

Eleven (11) cents a day!!!!!  ( I assume you use a SMALL Right?)

Save:

You are up and working with a real MySQL 5.1 in under 15 min.  (Worst case) when your DB crumbles and dies one day.

Side effects:

Now you can use the RDS server each day to:

1) Test that your backups work,  NICE….

2) Do a roll up of the “stats” that the DBA was telling you “takes the site down,  stop that!!” (just use the RDS off line, VERY NICE..)

3) Test out new database ideas at now risk to production.  Or two ideas at the same time,  I love that clone feature…
4) The list of off line uses for the DB backup copy go on and on….

This time AWS does it right. The Relational Database Servers in AWS called “RDS” are the “Real Thing”.

I just transferred over my whole Drupal DB in a few moments to an RDS Instance. It was very simple.

Let me show you the one-line command solution:

(Warning Linux command comes next!)

$ mysqldump –add-drop-table –databases Comments EdwardMGoldberg NOC myCloudWatcher_drupal wikidb | mysql -h mycloudwatcher.xxx.us-east-1.rds.amazonaws.com -u TheCloudWatcher -pXxXxXxXxXx4

(all password info is fake)

Let me break down this command into the parts:

mysqldump:

This is the LINUX command line database dump program. I just used the default connection (defined in my.cnf) and dumped a few tables I wanted. I added the drop table option so I can update as many times as I like.

mysql -h :

This does the “remote” connection to the new RDS instance and most of the heavy lifting.

So with one line of shell script, I moved into the Cloud.

The RightScale Dashboard was used to set up my RDS instance. It made the whole process of configuration a point and click process.

Next step, look at the results and check out the tables:

http://dev.mysql.com/downloads/gui-tools/5.0.html

Download these great GUI tools and connect to the Database from your Laptop. You do have to “allow” the IP address for you Laptop in the configuration.

It took me about one hour to get setup and transferred into the Cloud. Not Bad.

What’s next? Get my monitor system to track the RDS and alert me when issues happen. I like collected for that task. so that will be my next step.

Take an hour and set up an RDS server for your database. It works great as a “Cold Backup Server”. You pay only a few cents for data storage on the “Cold RDS Server” stored as SNAP data. When you need to “Fail Over” in the Disaster Recovery (DR) mode just Launch the RDS from SNAP. In a very short amount of time you are back on line. To keep the DB up-to-date just launch it once a day for one hour and update the contents. Keep the “Delta” ready for the last few records you may need to add at Launch.

For DR and fail Over RDS ROCKS!!!!

It may be in Beta for now, but start learning how to use this service in the Cloud and never be caught without a Database Server again.

When the Beta ends you will be ready to use RDS full time for your next project.

If you are in the process of learning SQL, the RDS servers will provide you a real Database to do your homework with.

I Deploy and Watch servers all day as part of the http://myCloudWatcher.com service.  When I started to build the demo for this next RightScale Webinar I learned more about my application in the first few hours with the tools then I had ever seen before.

Please come join me at the Webinar and learn how you can instrument you next Deployment and provide top quality service with your next project.

The Webinar will be live:

Register here

What: Live Webinar — How to Deploy and Manage Rails Apps on the Cloud
When: Thursday, April 9, 2009 at 11 am PT / 2 pm ET
Who: RightScale & Steve Hudson, Director at New Relic

Or you can watch the movie later on the RightScale WebSite:

http://www.rightscale.com/news_events/webinars.php

The New Relic Tools Web Page:

http://newrelic.com/index.html

This new tool makes keeping your files correct with just a few clicks of the mouse.

Take a peek at:

http://cloudberrylab.com/

And read the background information on the BLOG:

http://blog.cloudberrylab.com/

Good work guys at Cloud Berry Labs!!!

So many of my clients have asked me to stick around and watch the servers for them after I finished the New Deployment Process. I enjoy training and Launching new projects. But I find it hard to just walk away and not take care on them after the first “Production Launch” is over.

So myCloudWatcher.com was born. Now I Watch many servers in many Clouds.  I get alerts and take some actions for the deployments.

The most important feature is that I watch out for new features and trends that could impact your project.  You get a team of people that look out for the servers and keep them well utilized and working well.

Process and work flow are very important to me. I feel that SVN Source Control and the Trac Ticketing program are important parts of the life cycle of a Project.

Please come talk to me about your Project needs. I would enjoy watching your servers for you.

Did I just invent WaaS ? Watching as a Service?

http://www.myCloudWatcher.com/

Edward M. Goldberg

This is a great pair to have on your team.  These two players add depth of monitoring to your Deployments.  RightScale takes the low level server metrics very nicely and SPLUNK> watches all of the application logs for you.

Now with this pair set up on every server in every Cloud Deployment.  You have one place to search the indexed logs for all of your servers and control all of the Deployments in any location from one place.

I will be doing a Webinar talking with Michael Wilde of SPLUNK> for one hour.  We will explain all about these products and show you live how to set up a set of servers with RightScale + SPLUNK> .

This event is by invitation only so use this link to get a “seat”:

https://www2.gotomeeting.com/register/280094898

If you missed the last few Webinar and waant to get ready for this one,  watch these first;

http://www.rightscale.com/news_events/webinars.php

The basic idea is servers watching servers.  With SPLUNK and RightScale watching your servers for you and collecting information you will know exactly what your servers are doing at all times.  This is a great way to prove your SLA was meet.  When you need to know what the performance of the Deployment Solution you created provided you need tools like these.

I think that it is important dispel the idea that Cloud Servers are “out of reach” and hard to examine.  In my work tools like these provide the real in depth information in real time.  Just looking at a server in a server room has little value for me.  I look at server photos in catalogs.  I watch servers perform with good tools like SPLUNK> and the RightScale Dashboard.

By setting up several external servers that watch your servers.

When I set up a deployment in the Cloud I also set up several ways to check and see if the service works well.  The more ways I can find to check and check the servers that check (and test them if I get a chance) the better feeling I get the next time I am asked:

How well are you doing,  does the service meet the SLA?

So What services are around?

I just found a new service called: http://WebCron.Org

They are in France. This is great. One more opinion from a server on the other side of the pond from AWS to check each 5 min. and see if my servers providing the service are “200″ over the internet.  This is a good example of a web service to outsource a task.

When you set up with a little magic from Google E-Mail filters. I get an E-Mail and a phone alert each time the reply from the site is != 200. Simple to set up and cheap.

This is not to say that this is a 100% one stop shopping solution for site up time checks. This is just one more tool to use and get one more opinion from France.

I keep looking for ways to get “The warm fuzzy feeling” that all is well. This just takes me closer to that state.

Good work http://WebCron.Org/ you have a nice product. Any more new stuff on the way? Keep me posted.

You will see live demonstrations of two use cases: How to respond to a server failure and how to deploy a major system update in the cloud.

You’ll see that much of what you have to do manually in the data center is automated on the cloud. You can operate at a much higher level and accomplish the same tasks with less time and frustration.

• What: Live Webinar - “Deploying a Major System Upgrade“
• When: Thursday, January 22nd, 2009 at 11:00 am PST, 2:00 pm EST, 20:00 CET
• Who: RightScale Core Development Team

Our Webinar Series, Best Practices in the Cloud, is designed to provide you with the tools and training to make your cloud deployment a success.

We hope you take advantage of this opportunity to talk directly with the RightScale Development and Engineering teams. Click here to register!

RightScale’s very own MICHAEL CRANDELL, CEO

Will be at:
The rise and meaning of Cloud Computing

Talking about:

Technologies & Cloud Computing

Obstacles to roll-out and the innovations that will overcome them

Despite all the promises that Cloud computing can bring, some IT departments are hesitant to move across the rubicon. Concerns over security, control, management and integration stand in the way of cloud computing in the enterprise. Cloud computing represents a key shift in how the application stack and platform is built. How will Cloud overcome and integrate traditional enterprise IT silos of database, applications, networking and storage?

http://www.poweredbycloud.com/speakers/mcrandell.aspx

Researchers & Producers of Powered By Cloud  - 2-3 February 2009, Lewis Media Centre, Millbank, Westminster, London UK

Here is a link to sign up for the show:

http://www.poweredbycloud.com/register/registernow.aspx

So many great events this yes for Cloud Computing.

What happened to the users guide for the AWS EC2 Servers?

First of all AWS calls them instances and gives them strange names like i-12345678 that are not very easy to remember.  So to start off most users are lost just finding the server they just Launched (like a boat?).

This document covers the basics.  How to use a new server (read instance) you booted up (Launched) in AWS EC2.

After you read this document you will know the “Lay of the land” and will have a good idea of how to drive this car off the lot and change the oil.

Preparation for Deployment

Get all of the parts of the server in place first.  A good list would look like:

• Decide what OS to use,  I use CENTOS.
• Pick the AMI to launch from,  I like the RightScale templates.
• Collect all of the code and content an svn that you can use to load the server at boot.
• Select the E-Mail address that will get all of the Alerts.
• Select the size and number of servers you want to start with,  you can change your mind later.
• Select a Dashboard to use for the Launch,  I use RightScale for most project.
• Get a pot of tea and start to work…

Networking

Each server in EC2 has two Network Interface Ports.  But wait if you type “ifconfig” you only see one?

One is used for the EBS Volume Interface and the one you see is used for TCP, UDP and ICMP connections.

The only one you can control is the one shown in the OS Networking command.  This interface “eth0″ has two uses:

1. Internal Network Connections from one server to the next in your farm
2. WAN Connections from the WWW to your servers.

Internal IP Address

FREE Bandwidth,  let me repeat, FREE Bandwidth.  All transfers from an Internal IP to and Internal IP in the same Zone are FREE.

The Internal Network address starts with “10.”  as seen above “10.248.107.68″ and is used for:

• Communication to the master Data Base.
• rsync from one server to the next in the farm.
• ssh and scp commands inside the farm.

External NAT

WARNING: $$$$$ you pay for these bytes.  Watch out,  any transfers that use this address cost you $$$$.  If you use External IP addresses for both ends you pay 2x!!!!!

The other use of the eth0 interface is from the “NAT” that connects this server to the WAN or WWW. Each server when Launched (booted) is added to the list of servers the Firewall provides an external address for access from the WAN.

You can get an external IP address in two ways:

1. Random EC2 IP address: 75.102.166.16 (ec2-75-102-166-16.compute-1.amazonaws.com)
2. EIP

Default IP Address

The luck of the draw gets each server a “re-used” IP address picked at random from well used addresses in the AWS pool.  Watch out you are not the first user and the last user may have had a “Black Hat”.  These addresses are fine for development and random uses but fall short in many ways for real use of the server on the WAN.  Each IP address comes with a Sub Domain Name string that can be used to access this address.  The IP address is “hidden” in the string.  Just extract the numbers to get a “raw” IP address for your general use.

EIP

An Elastic IP (EIP) is an address you “own” from the AWS pool.  You get to keep these addresses for as long as you want to pay for them.  If you “age” these addresses for a while the “old taint” does drop off after a few days and the address can be used for WAN uses.  I would never use any of the AWS IP Address Pool for sending E-Mail.  Use a E-Mail Forward service to keep the IP address taint issue from stopping your E-Mail in it’s tracks.  You can rent these EIP values for $00.00 and hour if they are “in use” or $00.01 an hour if left idle.  So keep them “assigned” to some server to avoid the cost of the idle IP address.

So now you have the basic facts.  Start all of the public addressed server with a “Well Aged EIP” and use the “10.” internal address for all server to server networking.  Now you know.

Every Day Tasks

Time to talk about how to full the gas and check the oil.  This section talks about the day to day uses of the servers (Instances) and general information you better know if you are going to use the server and not get stuck with a big bill or a stranded instance.

Most of this is covered in the AWS Documents is 500 or so pages.  The is a short “crib” sheet of the most important topics.

ssh

Each server is started from an AMI or Image of a Server in S3.  As part of the process of Launch the server is given a KEY to provide access to the server.  I will only address LINUX servers for now.
To access a server you must have the ssh key that it wast started with.  No other access exists to a well designed AMI based server.  Feel free to break this rule,  but at your own risk.  The WWW is a very harsh place.  If your Network Access is attacked not only is your server at risk but any information that could allow the “bad guy” to see other data you have left passwords or keys to access from this server!!!

So for now I will assume you have used “Best Practice” and the only way to access the server is the KEY you provided when you launched this server.  So to log into the server you need a few things:

• The ssh client
• The KEY used to Launch this server
• A few hints.

The hints are as follows.  The only account on all of the servers is “root”.  The root account does not have a password!

The command: (Where Demo.pem is the public key)

$ ssh -i Demo.pem root@ec2-67-202-48-82.compute-1.amazonaws.com

Is the only way to address the server from “outside”.  From “inside” use ssh root@10.248.107.68 and get free network bytes and a faster connection server to server inside your deployment.  This assumes that you have allowed access from server to server in the zone.

sftp and scp

The same rule hold for sftp and scp.  Use the KEY file and login as root with the password empty.  I use the FireFox sftp plug in all of the time.  Simple to use and set up.

Extra note for putty users.  The putty program needs to have the key reformatted.  It comes with the tool to convert the key from standard form to putty form.  Just us the conversion menu in the tool.

Web Content

The Web Server on you server may have a different places for the code and content but these idea are the same for all servers.

The best way to install the code on a server is from a svn repository.  You have one right?  All of the code on the server is in a nice safe place ready to load up on request,  right?

If you use scripts this is the command: (replace the xxxx with your username and password)

$ cd /var/www     # This is my DocRoot,  you need to adjust this as needed.
$ svn –username xxxxx  –password xxxxxx –no-auth-cache  –force –quiet export “https://angel1.projectlocker.com/EdwardMGoldberg/Demo/svn/www/htdoc/”

Let me break down this command for you:

svn

The tool to provide the code tree

–no-auth-cache

Keeps the tools from remembering the password for later uses.

–force

Overwrite the content of the local files as needed.

–quiet

Keep the output down for better speed.  Leave off to see the processing
export

Get one static copy,  no file are written for later updates or check-ins,  just the data please.

“xxxxx”

This string is provided by the svn source repository.  You need to know where this to get the correct file.
In this case the results go into:   /var/www/htdoc/…  that last directory name is the new sub directory.

With no second “location” string in the command the files are placed in the current working directory.  Now the job is 1/2 done.  You have all of the files local to the server.  Next we need to allow for apache to read them.

$ chown -R apache:apache htdoc

If you forget this step you may see errors for files that can not be read by apache.  BTW, if apache is not the owner of the server,  replace apache with your server user name as needed.

Done,  now we have a new copy of the code on the server from SVN.  We could get fancy the save the old code or delete the oldest copy…

The important part is that this script that the new code is installed from svn with no user prompts.  Add this to the boot code for the server and each time you boot the code gets installed.

On RightScale servers this script is provided as an Operational Script.  Just click on the button in the dashboard and it performs these actions for you over ssh.  Nice feature…

Now the whole script in one place:

#!/bin/bash -e
#
# Upload the code to the server.
#
cd /var/www
svn --username xxxxx  --password xxxxxx --no-auth-cache  --force --quiet export "https://angel1.projectlocker.com/EdwardMGoldberg/Demo/svn/www/htdoc/"
chown -R apache:apache htdoc
logger -t Upload "Code uploaded to the server from SVN"

General Content

You can use the same SVN code for any general content files.  The S3 access also works well for restoring files from the backups.  S3 take more tools and keys.

Take care here,  leaving the keys on the server grants access to many other services.

I also use the wget command many times to fetch files from other web servers that distribute files.

Database

The database should be configured with the my.cnf file to use the /mnt/mysql directory or a mounted EBS Volume.  The default is for the MySQL database to be at the  /var/mysql location this is very bad for many reasons.

This makes very poor use the disks on the server.  The disk mounted on the /mnt mount point is the fast disk on these servers.  Use it for large read-write file systems like MySQL.  If you leave the MySQL on the / tree it will fill up the /tmp area and other important file space.  The /mnt disk is empty at the launch of the server.

If you use EBS for your database server you need to mount the EBS Volume for the MySQL server to use.  This works very well.

Remember to never use the / file system for your Database.

Reboot

The servers can be rebooted.  The AWS command to reboot them exist is every Dashboard I have seen.  Just take care,  the server may not reboot clean.  If you want to be 100% sure that you keep your service up to the users, launch a new fresh server.  Later you can terminate the old server.  The overlap will allow you to change your mind and go back to the first server.  I never reboot servers anymore.

Launch

This is like going to Fry’s Electronics and getting a new server.  The nice part is that the return lines are zero in length!

I use the RightScale Dashboard to launch servers.  Once defined the server costs Zero $ when not running.

When you start (read Launch) one of these defined servers the $$$ start to spend.  This ends when the server is terminated (rounded up to the next whole hour,  thank you).

The server boots from a “CD-ROM” like image called an AMI.  This is not unlike a Live CD is some ways.  You request that a server be a running copy of the AMI on the selected hardware.  AWS picks a server (read instance) for you and loads up that first 10G hard drive with your AMI.  Once all of the code in in place the server boots.

Part of the boot process is the reading of the KEY from the AWS storage.  This is placed into the /root/.ssh files so you can log into the server later.  If you have not selected a KEY and have a copy of the public key for your use the server will run just fine and you will have no access to it all.

So the first step is to check that you have a KEY that matches the KEY name Amazon has so the new server will allow you to access it after launch.  Don’t worry is you have no servers running and you have lost the key.  It is easy to create new keys before the next launch.    If you have lost the key to a running server,  you are out of luck.  Just terminate it and start a new server with a new key pair.

You may read lots of information about the creation of this AMI thing.  For now just use well designed and trusted ones from RightScale.  One day you may need to get fancy and make your own.  But not at the start.

I have never made an AMI and do not plan to make my own at all.  Several web based services now make AMI on request.  Just use one of the services.  You have little to gain rolling your own for now.

Updates

I never update servers.  I just start new ones and terminate the old ones.  I have been known to debug a server for a while till I get all of the scripts working well.  But in the end I Launch a clean one and watch it hum.

It is important to get in the habit of working with Clean New Servers and not hacking old ones.  If you keep hacking old servers to fix issues one day you may need to Launch and the server will fail to work at the nasty moment.  Launch new servers and then terminate the old when you have happy with the clean new Launch.  Terminate servers that have been used up, or hacked by hand ASAP.  The cost of the “overlap” then two servers are runs is very small.

For Development it is a very different story.  Use the ssh login and hack the server all you want.  Just remember in the end the goal is a clean “One Click Launch”.  I use servers as tools all of the time.  Start one when you need a tools and turn it off then you are done with the tool.  If you need a place to save files use EBS for storage and mount it on the servers when you need access to the files.  I keep a Snap-Shot of my favorite tools ready to attach to any server I need to debug.  Just like a USB Dongle or rescue CD-ROM.

SVN

Source Code Control is very important is the Cloud Environment.  It is the place to keep any files where the date and time of each update needs to be remembered.  Later when the server gets sick you can look and the dates and times of updates and find clues as to what made the server sick.

Some people like git or CVS.  Go right ahead and use the program you like.  I use svn and have had great luck with ProjectLocker for my deployments.  You mileage may vary.

Summary

Keep all of your servers happy and follow the simple ideas outlined here and you will have good control over your servers and your intellectual property (code and content).

Good rules to follow are:

• Keep your code and data separate from uploaded and generated stuff.
• Backup any files that you care about.  Keep the backups off the server.
• Assume that the server can stop existing at any moment and all of the files go away with it.
• Use each disk, / and /mnt for it’s special uses.  Never fill up the root file system, you will be sorry.
• Keep all of the files that are loaded on the server in SVN or your pick of Source Code Control.