9.4 Purpose of Linux images

You may not want to have all identical Linux servers. A typical server farm needs several kinds of servers. Each instance of the Linux operating system we call an image. As you customize a Linux image for its particular function, it becomes a specific server. For example, you can have an image that is configured to be a domain name server (DNS) serving the internal local area network, or an Apache HTTP or https server, or a firewall. Before implementing a server farm on Linux, it is advantageous to think about what kinds of servers are needed. Code sharing across servers might be possible, thus making software management easier.

Let us look at ISPCompany for an example of code sharing and easier software management. ISPCompany offers clients a standard Linux image. A custom contract gives clients the right to change the standard image, but a normal contract states that the image should remain unchanged. The standard image contains code on a read-only disk, where ISPCompany can easily support and manage the software. Client programs are on other, read-write disks. For example, if ISPCompany needs to apply a security patch, sometimes it can put the patch on a new read-only copy of the golden image disk. Each Linux image that boots from this disk will pick up the change. You can use z/VM to mark disks as read-only and to share one set of real disks among multiple Linux images as read-only.

If you are moving images from an existing server farm, you probably already know how many images you need, what they do, and which ones are similar. For security reasons, a Linux image should have only the operating system functions needed by the application it supports. Dividing up your servers according to the type of application they run gives you a rough view of what sets of images you need to create. Then, as you consider the dependencies which the applications have on distributions and other software, you can refine your view of what your images need.

Once you have determined how many unique images you need, you can construct them, create the unique golden copies, and then, with DirMaint, create the guests you need.

You can add resources such as processors, memory, minidisks, and so forth, to an existing Linux image by simple configuration changes which you can make dynamically. The initial guest definition can always be changed later.

The cost equation for doing hot standby can be drastically improved by using z/VM. One type of Linux image you are likely to consider in you design are low-cost hot-standby images. These images are redundant images that can share the file system, as shown in Figure 9-5.

Figure 9-5. Hot-standby Linux image under z/VM

If an image fails and has a hot-standby image, shared disks allow the hot standby to take over quickly. (If data are read-only, such as static Web pages, there is no need for data duplication or RAID-type storage.) You must decide on your particular schemes so that you can configure your system accordingly at the time you are setting up. Availability is discussed in detail in Chapter 11, "Achieving Higher Availability."