Boot Order

In either the BIOS setup or by using the UEFI, you can influence the order of the devices where the system will search for boot files. The most common source of boot files is the hard drive, but the files can also be located on DVDs, USB drives, and external drives, or they can be accessed from network locations as well as by using a PXE boot. The system will execute the first boot files (or any executable files) that it encounters in this search. When installing the operating system, you want the system, when booted, to look first in the location where the installation files are located.

If the system already has an operating system, this becomes even more important. This is because normally the first place the system looks is the hard drive. If this order is unaltered, the system will continue to boot to the old operating system, even though you may have the installation DVD in the DVD drive or the installation files located on a USB drive.

This means you must be familiar with entering the BIOS or UEFI and changing this boot order. It also means that when you have completed the installation you need to change it back so that it boots to the operating system you just installed.

Many new servers allow you to use either UEFI or BIOS settings to manage the boot process. In the following exercises, based on a Dell PowerEdge server, you will enter both systems. In either system you can set the boot mode, which tells the server which system to use to manage the boot process.

In the first exercise, you will use the traditional BIOS; in the second you will use the UEFI.

This exercise demonstrates the process on a Dell PowerEdge. Your system may be different. Consult your documentation.

RAID Types

RAID stands for Redundant Array of Independent Disks. It’s a way of combining the storage power of more than one hard disk for a special purpose such as increased performance or fault tolerance. RAID can be done with SCSI drives, but it is more often done with Serial Attached SCSI (SAS) drives. Several types of RAID are covered in the following sections. Due to the methods used to provide fault tolerance, the total amount of usable space in the array will vary, as discussed in each section.

RAID Setup

The management of hardware RAID is usually done through a utility that you select to access during the boot process, as you would if you were selecting to enter setup. An example of this is the PowerEdge Expandable RAID Controller BIOS Configuration Utility. When you boot the server, you press Ctrl+M to launch this utility. From a high level you will use the utility and the arrow keys to do the following:

1. Select Configure ➢ View/Add Configuration on the initial screen, as shown in Figure 2.1.
2. On the next screen (Figure 2.2), drives that are already online will show as ONLINE and any that have just been added will be shown with a status of READY. For any drives that still show as READY, select the drive and press the spacebar, which will change the status from READY to ONLINE. When you have selected the drives that will be in the array, they will be blinking. Press Enter to confirm that these drives will be members of this array.
3. Press F10 to display the Array configuration screen (Figure 2.3).
4. The array number that was assigned for the new disk drives from the previous step is displayed here. Press the spacebar to display the Span-1 message just below where the array number appears. Press F10 and you are now ready to select the RAID level, as shown in Figure 2.4.
5. Select the RAID level, keeping in mind the number of drives required for each type. Finally, select the size of the array.
6. Save the configuration and reboot the system.

Partitioning

When all of the volumes have been configured as you would like them, you must create a partition on one of the volumes to contain the operating system. This can be done during the installation of the operating system using the GUI provided with the installation utility. For example, during the installation of Windows Server 2012 R2 (see Figure 2.5), you can create a partition of the desired size. Be mindful of the space required for the operating system and include some additional space.

Formatting

Once the partition has been created, it must be formatted with a filesystem. The filesystem choices will be driven by the operating system. Windows, for example, will require using either FAT or NTFS. Other systems, such as Unix and Linux, will use other filesystems. We’ll look at filesystems in a bit. You can format the partition during the installation. Using the Windows Server 2012 R2 example, you’d choose the Format option shown in Figure 2.5. Similar options are provided during the installation of many forms of Linux and Unix as well.

Filesystem Type

There are many different filesystems you may encounter. In the following sections, we’ll take a brief survey of these filesystem types and see where and when they are used.

Swap

Today’s operating systems support the use of swap files. These are files located on the hard drive that are utilized temporarily to hold items moved from memory when there is a shortage of memory required for a particular function. The running programs believe that their information is still in RAM, but the OS has moved the data to the hard drive. When the application needs the information again, it is swapped back into RAM so that the processor can use it. Providing adequate space for this file is a key disk management issue. Every operating system seems to have its own recommendations as to the optimum size of this file, but in all cases the swap file should be on a different drive than the operating system if possible.

Patching

Just as the driver files that comes with every operating system is dated the moment that the installation DVD leaves the factory, so is the security posture of the operating system. As soon as possible after the installation, you need to apply all operating system patches and service packs. Some operating systems, such as the Windows and Linux systems, offer the ability to download and apply these updates during the installation.

OS Hardening

The next thing that should be done is harden the operating system. The goal of hardening an operating system is to reduce the attack surface. This involves disabling all services that are not used and turning off any features that are not required. The theory behind this is that all services, applications, and features have well-known vulnerabilities that hackers can leverage to compromise the machine. Although keeping up with security patches mitigates this, disabling any unnecessary services just makes sense. An additional benefit is better server performance since it must no longer allocate resources for that service.

Finally, any application not in use should be uninstalled and any ports that are unneeded should be closed. Any user accounts that may exist that are not needed should be deleted and any built-in accounts should have the default passwords changed.

Complying with Company Procedures/Standards

While applying all firmware and operating system patches is a starting baseline for securing the new server, your company’s standards and procedures may require that you go further. It may be that upon review of these documents you may find that there are additional actions that you must take. For example, it could be that according to policy certain server roles require that the network service the server provides (SQL or Project Management Server, for example) be configured to run under the security context of a user account rather than under the context of the system account (a very common safeguard). The bottom line is that no new server should be released to the network until it conforms to all security policies and procedures.

Server Optimization

The term server optimization refers to the proper allocation of resources to servers so that the resources are neither under- nor overutilized. In the past, this would be accomplished by examining the role of each server, attempting to anticipate the workload and then installing resources (CPU, NIC, memory, disk) to as closely as possible match the needs of the server. Invariably, no matter how much care is taken, resources still tended to be over- and underutilized. It is simply impossible to know the future.

Today, virtualization of servers is making this task much easier. Servers deployed as virtual machines can be dynamically assigned resources in real time as the need arises. Then these resources can be dynamically reallocated and deployed elsewhere when the workload of the server drops. Virtualization will be covered later in this chapter in the section “Purpose and Operation of Virtualization Components.”

Swap or Pagefile Optimization

Earlier in this chapter you were introduced to the concept of the swap file, or the pagefile as it is sometimes called. Optimizing this file amounts to determining the proper amount of disk space to allocate for this function. Although it is not easy to pin down some vendors on a specific recommendation, you should always start with whatever guidelines the vendor may provide. Best practices have evolved over time.

With regard to Windows servers, here are some best practices:

• Set the pagefile at 1.5 times the RAM.
• Servers hosting databases or resource-hungry applications should have the pagefile set at 3 times the RAM.
• Split the pagefile on two different drives, preferably on two different disks.
• For Windows 2008, Windows Server 2008 R2, and Windows Server 2012 R2, the C drive should have a 6 GB pagefile.

In Linux, there is a parameter called swappiness that controls how aggressively the system swaps to disk. It ranges from 0 to 100, and when swappiness=0 it tells the kernel to avoid swapping processes out of physical memory for as long as possible. When swappiness=100 it tells the kernel to aggressively swap processes out of physical memory and move them to swap cache. You may want to experiment with this setting if you find the system is swapping frequently (which hurts performance).

Regardless of the operating system, if the server is frequently swapping to the swap or pagefile, that means the server needs more physical memory. Moving data back and forth from memory to disk and having to retrieve something from disk that should have been in memory hurts performance.

Deploying Images and Cloning

One way in which operating systems can be deployed quickly and with consistency is to create images of completed installations and use disk imaging software to copy the image to a drive. Not only does this speed the deployment process, but the image can be preconfigured according to the company policy with regard to the role the server will play.

Another of the advantages of a virtualized environment is the ability to maintain an inventory of these images for quick use. Virtualization is not required, however, and there are tools provided by vendors such as Microsoft that make the creation, management, and deployment of images easier. Windows Deployment Services (WDS) in Windows Server 2012 R2 is one such tool. This tool can be used to

• Capture an image of an existing server
• Create a boot image to send down to devices with no existing operating system so they can boot up and connect to the deployment server using PXE boot (more on PXE boot in a bit)
• Create boot media containing images used to connect to the deployment server for devices that do support PXE boot
• Perform unattended installations that contain an answer file that answers all of the prompts in the installation (more on these types of installations in the next section)

Scripted Installs

Scripted installations differ from simple image deployment in one way: there is some type of file associated with the deployment that makes changes to the deployment or provides answers for the installation. In a Windows classic unattended installation, this file is called an answer file. When using Windows Deployment Services or any third-party deployment tool, there will be a number of script files that might be used during either an image deployment or a full installation. In an image deployment, the file makes changes to or provides drivers for the image; in a full installation, the full installation process takes place with the file providing answers to the prompts.

Regardless of which type of deployment is taking place, the new system, with no operating system, must be able to

• Boot up and get an IP configuration
• Locate the deployment server
• Download the image or installation files
• Locate and download any additional scripts that need to run

There are a couple of ways to accomplish this, and we’ll look at them now.

PXE Boot and TFTP

Preboot Execution Environment (PXE) makes it possible to boot a device with no operating system present and come to a location in the network where the operating system files might be found and installed.

A device that is PXE-enabled will have an additional boot option called PXE Boot. When the device is set to boot to that option, it will attempt a PXE network boot. The process after that follows these steps:

1. The system begins by looking for a DHCP server. This is referred to as Discover.
2. The DHCP server answers with a packet called the Offer packet, indicating a willingness to supply the configuration. This step is referred to as Offer.
3. The client indicates to the DHCP server that it requires the location of the network boot program (NBP). This step is called the Request.

4. The DHCP server supplies the IP address of this location. This step is called Acknowledge.

5. The client, using Trivial File Transfer Protocol (TFTP), downloads the NBP from the network location specified by the PXE server.
6. The NBP is initialized. At this point, either the full installation occurs with an answer file or an image is deployed with or without additional script files.

Note that the process is independent of the operating system. Although we have framed this discussion in terms of Windows, the system being deployed can be any operating system. The PXE boot process is shown in Figure 2.11.

KVM

When working with servers locally—that is, standing in the same room with the server—one of the most common ways technicians connect to the server is through a KVM. A keyboard, video, and mouse (KVM) device allows you to plug multiple PCs (usually servers) into the device and to switch easily back and forth from system to system using the same mouse, monitor, and keyboard. The KVM is actually a switch that all of the systems plug into. There is usually no software to install. Just turn off all the systems, plug them all into the switch, and turn them back on; then you can switch from one to another using the same keyboard, monitor, and mouse device connected to the KVM switch. The way in which this switch connects to the devices is shown in Figure 2.12.

Serial

Although serial connections have been largely replaced by the use of KVM switches, it is still possible to connect to a server using a serial connection. The issue that arises is that even if a technician’s laptop had a serial port (which is unlikely today), there would be at most one. This conundrum led to the development of the serial device server. It provides a number of serial ports, which are then connected to the serial ports of other equipment, such as servers, routers, or switches. The consoles of the connected devices can then be accessed by connecting to the console server over a serial link such as a modem, or over a network with terminal emulator software such as Telnet or SSH, maintaining survivable connectivity that allows remote users to log in the various consoles without being physically nearby. This arrangement is shown in Figure 2.13. One of the advantages of this is the ability to get to the servers “out of band.” This means even if the network is down, servers can be reached through the serial ports either locally or through the modem.

Virtual Administration Console

To manage servers in a virtual environment, vendors of virtualization software provide administration consoles that allow for one server to another for the purpose of maintenance and administration. Examples include the VMware Server Console and the Virtual Machine Manager Console in Windows Hyper-V.

In Figure 2.14, an example of the VMware Server Console is shown. Here the System Monitor page shows the workload on a specific virtualization host (more on virtualization later, but a host is a physical machine that has multiple virtual machines on it). You can see there are four VMs hosted by server, all of which are currently powered off. That would explain why only 2 percent of CPU and only 1.3 GB of memory are being used, none it by the VMs.

The Virtual Machine Manager (VMM) Console in Hyper-V is shown in Figure 2.15. It also allows for managing the servers centrally from this console. Here two VMs are shown on the host named Hypervisor8. One of the two VMs is 90 percent through the creation process whereas the other is stopped.

KVM over IP

Earlier you learned about using a basic KVM switch. KVM vendors have responded to the need for a KVM switch that can be accessed over the network. The switch is like the one you saw earlier with one difference—it can be reached through the network, as shown in Figure 2.16. This means it is accessible not only from a workstation in the next room, but from anywhere. In this particular implementation (it can be done several ways), each server has a small device between it and the KVM switch that accepts the serial and keyboard/mouse connections.

iLO

Integrated Lights-Out (iLO) is technology embedded into Hewlett-Packard (HP) servers that allows for out-of-band management of the server. Out-of-band management refers to any method of managing the server that does not use the network.

The physical connection is an Ethernet port that will be on the server and will be labeled iLO. In Figure 2.17, one of these iLO ports is shown in an HP Moonshot chassis (these hold blade servers). HP iLO functions out-of-the-box without additional software installation regardless of the server’s state of operation, giving you complete access to the server from any location via a web browser or the iLO Mobile App.

iDRAC

A Dell Remote Access Controller (DRAC) card provides out-of-band management for Dell servers. The iDRAC refers to a version of these interface cards that is integrated on the motherboard of the server. There will be a port on the back of the server that looks like an Ethernet port that functions as the iDRAC port. In Figure 2.18 it is labeled the designated system management port.

Once configured, the port will present the technician with an interface on their computer, which is connected to the port when the connection is established. This console interface is shown in Figure 2.19.

RDP

Developed by Microsoft, Remote Desktop Protocol (RDP) allows you to connect to remote computers and run programs on them. When you use RDP, you see the desktop of the computer you’ve signed into on your screen. The computer at which you are seated is the client and the computer you’re logging into is the server. The server uses its own video driver to create video output and sends the output to the client using RDP. All keyboard and mouse input from the client is encrypted and sent to the server for processing. RDP also supports sound, drive, port, and network printer redirection.

A tool that can be used for this is the Microsoft Remote Desktop Connection Manager (RDCMan). It is a handy console, as shown in Figure 2.20. Note it is not limited to managing Microsoft servers and clients can be found for non-Microsoft systems.

SSH

If you don’t need access to the graphical interface and you just want to connect to a server to operate at the command line, you have two options: Telnet and SSH. Telnet works just fine, but it transmits all of the data in cleartext, which obviously would be a security issue. Therefore, the connection tool of choice has become Secure Shell (SSH). It’s not as easy to set up because it encrypts all of the transmissions and that’s not possible without an encryption key.

Although the commands will be somewhat different based on the operating system, you must generate a key, which is generated using some unique information about the server as seed information, so that the key will be unique to the server (the encryption algorithm will be well known). Once configured, the connection process will be very similar to using Telnet, with the exception, of course, that the transmissions will be protected.

VNC

Another remote administration tool that functions like RDP is Virtual Network Computing (VNC). It differs in that it uses the Remote Framebuffer (RFB) protocol. It operates like RDP with respect to the experience, but it is not a secure protocol. It doesn’t transmit in cleartext, but cracking the password is possible if the encryption key and the password are captured. Therefore, strong passwords should be used, and it may be advisable to tunnel it over a VPN or SSH connection.

Command Line or Shell

A shell is a type of user interface that may or may not be graphical. In most cases shells are command-driven interfaces. There are many shells for Unix systems. They all have their own command, syntax, and capabilities. Some operating systems have a single shell—for example, the MS-DOS program. Other Windows systems have multiple shells that can be used such as PowerShell. Devices like routers and switches also have shells like the Cisco IOS. When used over the network, shells are sometimes referred to as remote shells.

Type I

A Type I hypervisor (or native, bare-metal) runs directly on the host’s hardware to control the hardware and to manage guest operating systems. A guest operating system runs on another level above the hypervisor. Examples of these are VMware vSphere and Microsoft Hyper-V.

Type II

A Type II hypervisor runs within a conventional operating system environment. With the hypervisor layer as a distinct second software level, guest operating systems run at the third level above the hardware. VMware Workstation and VirtualBox exemplify Type II hypervisors. A comparison of the two approaches is shown in Figure 2.23.

Hybrid

In the datacenter you will most likely encounter Type I hypervisors, but you should be aware of an emerging type of hypervisor: the hybrid. This is basically a Type II hypervisor, but it is integrated with a cloud. The best example of this is VMware Workstation version 12. With this version, it is possible to connect to vCloud Air or to any private cloud and upload, run, and view VMs from the Workstation interface.

Another new approach that might be considered a hybrid is container-based virtualization. Container-based virtualization is also called operating system virtualization. This kind of server virtualization is a technique where the kernel allows for multiple isolated user-space instances. The instances are known as containers, virtual private servers, or virtual environments.

In this model, the hypervisor is replaced with operating system–level virtualization, where the kernel of an operating system allows multiple isolated user spaces or containers. A virtual machine is not a complete operating system instance but rather a partial instance of the same operating system. The containers in Figure 2.24 are the blue boxes just above the host OS level. Container-based virtualization is used mostly in Linux environments, and examples are the commercial Parallels Virtuozzo and the open source OpenVZ project.

BIOS/UEFI Compatibility and Support

In many cases the motherboard and associated BIOS/UEFI settings need no alteration to provide services to virtual machines. However, some of the virtualization products, such as Microsoft Hyper-V, require that the motherboard support hardware-assisted virtualization. This is because in these cases the virtualization product is not installed on top of a regular operating system but instead is installed directly on bare metal—that is, as an integral part of the operating system, as in Windows Server 2012 R2.

The benefit derived from using hardware-assisted virtualization is it allows the hypervisor to dynamically allocate memory and CPU to the VMs as required. When the motherboard and the BIOS support this technology, you must ensure that it is enabled. Figure 2.25 shows an example of the settings. Although most new servers will support hardware-assisted virtualization, it is a feature and a consideration you should know about.

CPU Compatibility Support

One of the key issues to consider when reviewing compatibility guides is the CPU. This component plays a critical role in the overall success of the virtualization solution. You should not only ensure that the CPU you are considering or that is present in the candidate host machine is listed on the compatibly list, but you should also make every effort to use a CPU that supports instruction extensions and features designed to enhance virtualization. Let’s look at two major vendors and their technologies.

AMD-V and Intel VT

CPUs come with varying abilities to support or enhance virtualization. Intel provides an entire line of processers that support what they call Intel Virtualization Technology. The benefits derived from using a CPU with this technology include

• Acceleration of fundamental virtualization processes throughout the platform
• Reduced storage and network latencies, with fewer potential bottlenecks
• The enhanced security that a solid hardware foundation provides
• Improved short- and long-term value from your software and server investments

AMD has a similar line of processors with a technology they call AMD Virtualization (AMD-V). It adds to the instruction set of the CPU and provides many of the same benefits as the Intel technology.

CPUs

You can control the allocation of physical CPU(s) use in one of three ways:

Shares Values such as Low, Normal, High, and Custom (using VMware as an example) are compared to the sum of all shares of all VMs on the server. Therefore, they define the relative percentage each VM can use.

Reservation Guaranteed CPU allocation for a virtual machine.

Limit Upper limit for a virtual machine’s CPU allocation.

These settings are used to ensure that the desired VMs have priority to the CPU (shares), that certain VMs are always guaranteed CPU time (reservations), and that no single VM monopolizes the CPU (limits). In Figure 2.26, you can see how this is done in Microsoft Hyper-V. Although the terminology is slightly different, the concepts are the same. As this figure shows, you can assign multiple virtual CPUs to a VM, which is another way to influence the VMs’ performance.

Storage

A benefit of virtualization is the ability of VMs to share storage. This storage can be located in a single storage device or appliance, or it can be located on multiple storage devices. By logically centralizing the storage and managing it centrally, you reduce the waste that formerly occurred when each server used its own storage.

Increasingly, storage is presented to the VMs as local storage but is actually located in either a storage area network (SAN) or on network-attached storage (NAS). A SAN is a high-performance data network separate from the LAN, and NAS is a storage device or appliance that resides on the LAN.

The VMs reside on the host servers and the host servers are attached to the shared storage devices, as shown in Figure 2.27. Conceptually, the shared storage could be either NAS or a SAN, the difference being that, with a SAN, the servers will need to have a host bus controller card installed that can connect the server to the fiber network that typically comprises the SAN.

One of the benefits of shared storage is more efficient use of the storage, with less storage sitting idle while other storage is stressed. When you create VMs, one of the steps involves the creation of a virtual hard drive for the VM. This is space in the shared storage for keeping the image of the VM. There are several types of virtual disks you can create, and some types have unique abilities that aid in this efficient use of space. Every virtualization vendor attaches somewhat different names for these, but they all offer the same basic types. As an example, we’ll look at the types offered by VMware, the market leader in virtualization.

Thick Provision Lazy Zeroed This is analogous to the classic regular hard drive with one exception. Like the classic disk, space required for the virtual disk is allocated during creation. If data is present on the disk, it is not deleted until the space is needed for new data.

Thick Provision Eager Zeroed This is like lazy zeroed but any data on the disk is zeroed out ahead of time. This means it takes longer to create one of these disks.

Thin Provision This is where the disk efficiency comes in. At first, a thin-provisioned disk uses only as much datastore space as the disk initially needs. If the thin disk needs more space later, it can grow to the maximum capacity allocated to it.

In Figure 2.28, you can see how this is done in Hyper-V, and although the terminology is slightly different, the concepts are the same with most vendors. As this figure shows, you can create what is called a differencing disk. This disk type is not unique to Hyper-V. It is used to store changes made to an image when you decide to keep a copy of a previous version of the image. This is what allows for the process of rolling back an image after making changes that you would like to reverse. This makes virtualization perfect for testing changes before an enterprise rollout.

Memory

Memory resources for a virtual machine are allocated using reservations, limits, and shares, much in the same way as CPU time. A virtual machine can use three user-defined settings that affect its memory resource allocation.

Limit Limits the consumption of memory for a virtual machine. This value is expressed in megabytes.

Reservation Guarantees a minimum allocation for a virtual machine. The reservation is expressed in megabytes.

Shares Represent a relative metric for allocating memory capacity. The more shares a virtual machine is assigned, the more often it gets a time slice of a memory when there is no memory idle time.

In Citrix XenServer, you can use Dynamic Memory Control, which permits the memory utilization of existing VMs to be compressed so that additional VMs can boot on the host. Once VMs on that host are later shut down or migrated to other hosts, running VMs can reclaim unused physical host memory. You enable Dynamic Memory Control by defining minimum and maximum memory settings for virtual machines, as shown in Figure 2.29. In VMware, this concept is called overcommitting memory.

Network Connectivity

It is possible to connect VMs together in a network and that network can be the same network as the LAN or separate from the LAN. The network can have Internet access or not, depending on how you use the virtual networking components at your disposal. Some of the ways you can connect VMs to the host, to one another, and to devices “outside the box” are covered in this section.

Direct Access (Bridging) vs. NAT

There are two basic options for connecting the VM to the host machine:

• Direct access (bridging), which uses the physical NIC on the host system.
• Network Address Translation (NAT), which creates a private network on the host system, with the host system acting as a DHCP server. When access to networks beyond this private network is required, the host will perform NAT on the private IP address and use its own IP address.

The easiest configuration is to bridge the VM to use the NIC of the host and use its own IP address. But if you want the IP address of the VM to be hidden, then using NAT will ensure that all packets coming from either the VM or its host will appear to come from the host.

If you want to create a network in which the VMs can reach one another, you can use either configuration. Figure 2.30 shows that both methods can be used in the host. You see that some of the hosts are using NAT, which is why they have IP addresses that are used on the LAN, whereas one of the VMs has been bridged and thus does not have an IP address that works on the LAN.

Virtual Switches

To create a virtual network as discussed in the previous section, you have to create a virtual switch that will interconnect the VMs and the host. The vNICs of the VMs are connected to the virtual switch, which in turn (if desired) is connected to the physical NIC on the host, as shown in Figure 2.31. Notice that one of the switches is connected to the LAN and other is not.

When creating a vSwitch, you can choose whether or not to connect the vSwitch to a physical NIC. In Figure 2.32, a vSwitch created in VMware indicates there are two physical adapters available to assign to this switch.

Video

In a virtual desktop infrastructure (VDI), VMs are used to house images that are used by users as their desktops. One of the pain points often experienced when implementing VMs in this fashion is poor video performance: screens that are slow to drag, changes to the display that occur slowly, and other issues that crop up.

This issue is not limited to a VDI but is common to it. Use the video adapter settings of the VM to increase the video memory of the problematic VM, as shown in Figure 2.33. In cases where this must be done to a large number of VMs, you can use a PowerShell script to change them all.