Chapter 2. Rackspace Virtual Machine

Table of Contents

Design and Launch via Rackspace Interface
Machine Design Considerations
Launch the Machine
'ping' the Virtual Machine
Initial Login to the Virtual Machine
Machine Monitoring Considerations
Virtual Machine Check Point

Design and Launch via Rackspace Interface

In this chapter we're going to launch a virtual machine via the Rackspace web interface. Before we begin the process of launching the machine, it would be nice to actually define what a virtual machine is. For the context of this class, the term virtual can be thought of as not physical. In other words, what is, in the "real" world, a physical machine is now going to become a "machine" that exists in the realm of software. Most of the counterparts of a physical machine are present in the virtual (software) machine. However, the way we need to interact with the virtual machine will be much different, since it is not (physically) something we can touch and feel. The Rackspace interface is how we interact with the virtual machine.

However, before we launch the machine, we'll take a look at the design of the machine. Defining and being aware of the scope of the machine is important so that there are no surprises when the machine "goes live". The design phase of this course is information-only. The machine we'll actually launch will be a "bare bones" server.

Finally, we'll consider what's involved in monitoring the machine, and the capability to add additional components, such as snapshots, and additional virtual hard drives.

[Important] Rackspace Interface Differences

Rackspace is constantly making changes and updating their interface. There is a strong probability that the interface you are presented with will differ from the screenshots shown below. If you cannot determine what is the correct choice while negotiating the Rackspace interface, don't hesitate to send me an email.

Machine Design Considerations

The image below is an outline of initial machine design considerations. Using this image for reference, the list below the image can serve as a starting point for designing our machine. We have several considerations, and the scope of the machine should fit within the context of those considerations with room to grow.

Figure 2.1. Server Design Considerations

Server Design Considerations

Let's consider the image above and look at a few questions about the architecture of our machine. You may not be able to answer all these questions in one sitting. However, the answers that they demand will warrant the considerations that must be borne if the machine is to fulfill its purpose.

  1. From the top, consider the incoming Public Network. How much traffic do you expect? Will you need multiple network connections? Will you need multiple NIC (Network Interface Cards) in the machine? What networks do you plan to connect to? What types of incoming connections are available? (T1, Ethernet, etc.) Is the incoming traffic behind an existing firewall? Are you operating in a DMZ (De-Militarized Zone)?
  2. Will the expected traffic warrant the use of more than one machine to service requests? If you're operating within a cluster, do you need a load balancer?
  3. If the machine is to face the Internet, a firewall is a must. On some local networks, a firewall is a must. In this day and age, a firewall is a must. Therefore, when enumerating the services to run on the machine, which ports will need to be opened? Are there additional considerations for the firewall, such as restrictions regarding certain types of traffic? ...or specific hosts or sub-nets? Are there special considerations such as IP Masking, etc?
  4. If the machine is to be redundant with another machine, or part of a cluster, there will need to be provisions set in place to connect them. This will be taken care of by the Service Network and elements such as a Network File System (NFS) etc. A method of distributing the connfiguration and user accounts across machines will need to be considered, such as rsync, or LDAP (Lightweight Directory Access Protocol). This class will use the simplest approach possible, only one machine with very limited services.
  5. When setting up the machine, list the specific applications that will be installed on the machine. Sum up the required resource demands of all the applications (memory, cpu, network, storage), and add at least 50% - 100% over that for "room to grow". [2]
  6. What kind of data to you expect to handle? Different types of data require different levels of security and restrictions. Are you housing a) Social Security Numbers, b) Medical data, c) Credit Card numbers, d) highly personal information, etc. What measures are you putting in place to protect this data? Are you familiar with industry best practices and standards (HIPPA, FERPA, etc.) that may apply to your machine?
  7. What kind of disk writes to you expect to make? Do you need to commit to SSDs (Solid State Devices)?
  8. Are you going to enable (or are you required to enable) SELinux (Security Enhanced Linux)? See National Security Agency Security-Enhanced Linux for more information.[3]
  9. Set up the operating system on its own partition or disk. If needed, there can be additonal disks added for '/home', '/var', etc. added to hold that data if a large volume of data is expected. This modular scheme is described more in detail below, and facilitates disaster recovery and backup routines. Use LVM (Logical Volume Management) for flexibility and expandability. Use a journaling file system (EXT4, etc.) for ease of recovery from crashes, power failures, etc.
  10. What kind of backup/snapsot routines are needed? There's more on this below. Consider that in an environment that is very fluid, where data changes from minute to minute, several backups and/or snapshots daily may be warranted.
  11. Do you plan to use a database? If so, which one? Is that application suitable to support the applications that it will serve? MySQL is a very different creature from Postgres, and both are very different from Oracle. In the end, you'll get what you pay for, so is it worth paying the extra price? Is the machine sized and resourced accordingly for the applications that it will house?
  12. What kind of "uptime" is required for your system? Consider sites such as CNN, Google, and Yahoo, wherein even an hour of down time could be devastating. Are you headed for that level of demand? If so, look at the SLA (Service Level Agreement) offered by your provider. Does it guarantee an excess of 99% uptime?[4]

An ancillary consideration is what to do if the machine should somehow become unusable or otherwise non-functional. Preparing for this contingency is extremely important. There are three basic areas that converge when considering recovery from a disaster. Preparing for recovery in the event of a disaster means that these three areas have been addressed consistently and methodically, which makes recovery a simple drill. You can see how all this interrelates by referring to the image above.

  1. The base install of the Operating System.
  2. Regular backups of all crucial system configuration settings and files. On Linux, this area is encapsulated in the '/etc' directory.
  3. Maintain the critical data on a separate drive/disk and maintain a regular backup routine for this disk.

With these key elements in place, well maintained and current, recovery is a three-part exercise.

  1. Reinstall the Operating System or launch a new Virtual Machine. If Machine Snapshots are being taken, the machine can be restored from a snapshot. If reinstalling the OS, include the necessary software that was part of the original machine.[5]
  2. Restore the contents of the '/etc' directory as needed to duplicate the configuration.
  3. Plug the separate data drive back into the machine.

When all the above is in place and current, I've seen complete recovery of a machine from "dust" take less than an hour. There are two additional concepts that bear mention, left as an exercise for the student: Continuous Availability and Fault Tolerance .

With all this in mind, we'll move forward to create our machine. We'll keep it as simple as possible for this class. However, if you are ever in a position to expand or create a server with additional load or functionality, the above will help you make your decisions.

Launch the Machine

The first thing to do is to log in to rackspace web utility. Once logged in, follow the steps below to create the virtual machine.

Figure 2.2. Create a Rackspace Server, Step #1

Create a Rackspace Server, Step #1

As shown in the screenshot above, click on "Create Server".

Figure 2.3. Create a Rackspace Server, Step #2

Create a Rackspace Server, Step #2

As per the above screenshot, name the server "alpha.<domain-name>". Also, under Image, choose "Linux -> CentOS 6."[6].

[Caution] CentOS 6 vs CentOS 7

CentOS now comes in two main flavors: 6 & 7. There were dramatic changes introduced with the release of CentOS 7. This curriculum is written for CentOS 6. DO NOT LAUNCH A CentOS 7 INSTANCE, as that will create many more problems later.

Figure 2.4. Create a Rackspace Server, Step #3

Create a Rackspace Server, Step #3

As shown in the above screenshot, under Flavor, choose "Standard".

Figure 2.5. Create a Rackspace Server, Step #4

Create a Rackspace Server, Step #4

The above screenshot shows that under Network, "PublicNet" and "ServiceNet" are checked. Then, click "Create Server".

[Important] Copy & Write Down the 'root' Password

You will get one - and only one - opportunity to capture the 'root' password for your new machine. Make sure to copy it exactly, and write it down. If you fail to do this, you will not be able to access the machine. If that happens, the only alternative will be to delete the machine and repeat the process from the beginning.

Also, make sure to write down both the internal and external IP addresses of your virtual machine. We will use the public IP address throughtout this course.

Figure 2.6. Create a Rackspace Server, Step #5

Create a Rackspace Server, Step #5

As shown above, in a few seconds (minutes) the Server Status will go green, or 'Active'.

Figure 2.7. Create a Rackspace Server, Step #6

Create a Rackspace Server, Step #6

Above you can see that at this time nothing else needs to be done under Images, Monitoring, Storage, or Backups. It's possible to configure these items at this point in creation, however we'll leave them "as is" for now. These items can be enabled and configured later, and are considered in the section called "Machine Monitoring Considerations".

Figure 2.8. Create a Rackspace Server, Step #7

Create a Rackspace Server, Step #7

When you click on "Back to Servers List", the machine should show up in the "Cloud Servers" list as shown above. Note also that the public IP address is visible from this screen. When you click on an individual server, you will be taken to a screen with the details of that machine as well as a list of actions that can be performed on the machine.

Figure 2.9. Create a Rackspace Server, Step #8

Create a Rackspace Server, Step #8

The above screenshot shows the details and actions available for our new machine. Also note on the right side the `ssh` command that will give you a kickstart to log in to the machine.

Figure 2.10. Reboot the Rackspace VM

Reboot the Rackspace VM

We can reboot the machine from this interface, as shown above. A soft reboot is simply that - a simple reboot. A hard reboot is a complete power cycle of the machine, equivalent to turning the machine completely off and back on again.

'ping' the Virtual Machine

You should be able to successfully 'ping' your new machine by ip address: `ping -c 4 <public ip>`. At this time, perform that test. Access a command line utility and enter the command as shown. If you get a successful return, congratulations. If you do not get a successful return of the ping packets, stop and figure out why. If you need a review of the `ping` command, see Chapter 10, Linux Command Line Review.

Initial Login to the Virtual Machine

You can, at this point, log in to your machine by IP address via SSH. The actual command is listed in the screenshot above. If you need an introduction to SSH, see Chapter 5, SSH for more details.

Machine Monitoring Considerations

The RackSpace interface provides a rich array of utilities to facilitate monitoring and enhancing our Virtual Machine. While none of these items are required for our class, a brief description of each is provided for your reference.

Figure 2.11. RackSpace Machine Monitoring Overview

RackSpace Machine Monitoring Overview

The image above gives an overview of the utilities we can invoke and employ for our server. Under the Images section, we can Create an Image or Create Schedule. An Image is a "snapshot" of the state of our machine at a specific point in time, the point being when we created the image. Once we have this image, or a selection of images, we can restore our machine to the exact state that it was in at the moment we created the snapshot. By creating a schedule, we can save the state of our machine for future reference or recovery purposes. This is extremely important under several circumstances, particularly when doing development or when in production and a backup of the machine will be crucial. The Create Image routine corresponds to saving the entire virtual machine, as well as the crucial configuration data pointed out in the architecture image above.

Figure 2.12. RackSpace Machine Checks

RackSpace Machine Checks

The Install Agent link shown above opens the dialog box shown below.

Figure 2.13. RackSpace Machine Check Installation

RackSpace Machine Check Installation

You can install Cloud Monitoring Agents that will then monitor your server, explained below. See RackSpace Monitoring Agents for more information about this procedure.

Figure 2.14. RackSpace Machine Monitoring

RackSpace Machine Monitoring

By Creating a Check, as shown in the image above, you can establish any of several checks (monitors) for your machine. Once the agent is installed, the check is invoked and employed to monitor your machine. These checks will return critical information about machine availability, how your machine is responding to incoming traffic, load, memory utilization, etc. After these steps are complete, graphs will appear that will summarize the information requested.

Figure 2.15. RackSpace Networking

RackSpace Networking

The image above shows the Network arrangement that is available to our machine. The PublicNet section is just that: available via the public Internet. If you want to add an additional network interface for increased traffic, this is where to do that. The ServiceNet is not a public address, and private information/data that needs to travel between machines goes over this network. In production, if we had several machines in our fleet, we may need to transfer files and information back and forth between them without that data being available to the public. The ServiceNet is how this happens.

Figure 2.16. RackSpace Machine Create Volume

RackSpace Machine Create Volume

Figure 2.17. RackSpace Machine Volumes

RackSpace Machine Volumes

The Storage Volumes section will create the equivalent of an additional hard drive that will be plugged in to your machine. This corresponds to the external Data Volume that is shown in the architecture image above. Keeping the data we work with separate from the operating system gives our system a modular architecture, wherein each piece is independent, yet can be set up to be interrelated to the other pieces. The two images above show the sequence of events: a) create the volume, then b) attach the volume. Volumes can be attached and detached as needed.

Figure 2.18. RackSpace Machine Backup

RackSpace Machine Backup

Backups are subtly different from images, as shown above. See Figure 2.11, "RackSpace Machine Monitoring Overview" for information about images. Whereas an image applies to the entire disk, a backup is a file-level, restorable way of being able to grab individual, granular pieces (files) from the machine when needed. One way to make the distinction between a disk image and a backup is that an image restores the entire machine to a previous state, and a backup makes available individual files in their previous state. See Rackspace Backup Agent for help with this utility.

Virtual Machine Check Point

Much of the information in this chapter is "read only", no action required. To fulfill the Check Point for this chapter, send me the public IP address of your machine. I will `ping` the machine. If I get a successful return from the machine, you're finished with this chapter. You can test this for yourself by running the `ping` test as outlined above.



[2] Databases are notorious resource hogs, being memory, processor and disk input/output intensive. For this reason, in demanding environments, there is often a dedicated machine or cluster of machines set up for database interaction.

[3] In this class, we're "keeping it simple". SELinux is beyond the scope of what we'll cover.

[4] Consider that 95% yearly uptime (which leaves 5% of the year for being down) is about 18.25 days, or about 8.5 hours per week. If this all happens at the same time, how will it affect your operation? 99% (two nines) uptime leaves approximately 3.65 days of down time per year, or about 1.68 hours per week. What if even that hour and a half comes during your peak demand?

[5] It is wise to consider the state of OS upgrades and patch management. If the original server has not been updated and patched, moving forward to a newer version may introduce challenges. It's not to say that the transition can't be done, but it will take more thought and strategy than moving to a similar version of the machine.

[6] Centos 6.4 was the latest version at the time of this writing. Depending on the state of updates, the latest version may be higher than 6.4. Choose the latest version.