Chapter 2. Rackspace Virtual Machine

Table of Contents

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

Design and Launch via Rackspace Interface Top of Page

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 Top of Page

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 "Servers", then "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 7."[6]. Also, at the top of the screen, is an estimate of what this machine will cost per day. There's more on that in Figure 2.6, "Create a Rackspace Server, Step #5".

[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 7. DO NOT LAUNCH A CentOS 6 INSTANCE, as that will create many problems. Please email me if you have questions.

Figure 2.4. Create a Rackspace Server, Step #3

Create a Rackspace Server, Step #3

Figure 2.5. Create a Rackspace Server, Step #4

Create a Rackspace Server, Step #4

Here we face a choice. Note that in the screen shot immediately above, the flavor is "General Purpose". In the screen shot above that, the flavor is "Standard". Note the differences between the specifications for each, especially the amount of a) RAM, b) System Drive, & c) Network. The Standard is a smaller machine, and it costs less. Also, if there is a heavy load to be placed on the machine, it will "choke". The screen shot below shows a cost comparison. Note also the warning in the Standard screen shot that says this is the smallest image possible. Resizing it to a smaller instance won't be an option.

Figure 2.6. Create a Rackspace Server, Step #5

Create a Rackspace Server, Step #5

The math (in terms of cost) is based on 168 hours per week 'times' 4 weeks, or 28 days. This is a rough monthly cost difference between the two machines. I'll leave the choice to you. For this class, the Standard will work well. If you are going to do much with the machine, you'll want to increase the size - either now, or later.

Figure 2.7. Create a Rackspace Server, Step #6

Create a Rackspace Server, Step #6

Click on "Create Server". The system will begin "churning", and your server will be deployed.

Figure 2.8. Create a Rackspace Server, Step #7

Create a Rackspace Server, Step #7

This screen shot shows two important things. First, the orange image says "Building", which is the status of the machine. Also, this is the ONLY SHOT you'll get at the root password. Write it down and don't lose it. If you do, life will become very complicated.

[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 (workable) alternative will be to delete the machine and repeat the process from the beginning.

Figure 2.9. Create a Rackspace Server, Step #8

Create a Rackspace Server, Step #8

This screen shot shows that the server is still "Building". As indicated, it's at 90%.

Figure 2.10. Create a Rackspace Server, Step #9

Create a Rackspace Server, Step #9

Finally, the machine is built, and "goes green". Click on "Servers" & "Cloud Servers" to go back to the main interface. This will list all the machines you have, and many options. It's a good idea to dig around the interface a little bit to see what all is available. If you don't understand it at this point, that's OK. More will be revealed.

Figure 2.11. Create a Rackspace Server, Step #10

Create a Rackspace Server, Step #10

Here's the interface with servers listed. In my interface, there are two servers. You will likely have only one.

Figure 2.12. Create a Rackspace Server, Step #11

Create a Rackspace Server, Step #11

Note that there are options to build specialized servers, called "Stacks". These are servers with a dedicated purpose and pre-installed software.

Figure 2.13. Create a Rackspace Server, Step #12

Create a Rackspace Server, Step #12

Once again, clicking on the server from the list shows details of it's status. Note the multitude of options on the right side of the interface. Some of these are important, and become useful during a crisis. Note also the "Help" and "Articles" links.

Figure 2.14. Create a Rackspace Server, Step #13

Create a Rackspace Server, Step #13

This image shows the options from the "Actions" menu in the machine's interface. Note that this is a context menu, and the actions only apply to the machine that's detailed.

If you've made it this far, congratulations. Take a break and enjoy the moment.

Machine Monitoring Considerations Top of Page

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 overview is worth the time..

Figure 2.15. 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. These checks will return critical information about machine availability, how your machine is responding to incoming traffic, load, memory utilization, etc. The checks can be configured to alert you when the machine is heavily loaded, etc.

Figure 2.16. 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 is available for private information/data that needs to travel between machines "behind the scene", outside the view of the Internet. 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.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 to different machines as needed. 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.18. Rackspace Machine Image

Rackspace Machine Image

An image is a snapshot in time of your hard drive, or machine. By creating images, especially on a regular basis - such as nightly - it will be possible to revert to a saved image at a later time. This will, in essence, roll the machine back to whatever point in time the image was created. This is an excellent recovery strategy. The down side is that a) the image process will <probably> cost money, & b) the images will be costly in terms of storage space.

Figure 2.19. Rackspace Machine Backup

Rackspace Machine Backup

Backups are subtly different from images, as shown above. See the design section above 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.

'ping' the Virtual Machine Top of Page

Now that the machine is up & running, you should be able to successfully 'ping' your new machine by ip address: `ping -c 4 <public ip>`. You can get the IP address from the machine's interface as it's listed. 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 Top of Page

Figure 2.20. Login to Rackspace Machine

Login to Rackspace 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. The first time you log in to the machine, you will be prompted to accept the "certificate" for the machine. That process is shown in the image below.

Figure 2.21. Login Certificate Acceptance Prompt

Login Certificate Acceptance Prompt

[Warning] A Note About Your New Machine

Now that you have a virtual machine in action, it's publicly available on the Internet. That also means that others are looking at it as well. If you log in and see a message as indicated below, you'll know that you're being "stalked".

Figure 2.22. New Machine Failed Logins

New Machine Failed Logins

The image above shows that there were many failed login attempts against the new machine. This is not uncommon, especially for any server that is visible from the Internet. It's important to follow security guidelines in order for the machine to not become compromised.

Virtual Machine Reboot Top of Page

Figure 2.23. Reboot the Rackspace VM

Reboot the Rackspace VM

We can reboot the machine from the machine 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.

Virtual Machine Check Point Top of Page

The objective of this chapter is to have a running machine. Much of the information in this chapter is information 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 of down time. 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 7.2 was the latest version at the time of this writing. Depending on the state of updates, the latest version may be different. Choose the latest version.