Enable Automatic Virtual Server Relocation
IBM Systems Director 6.1 streamlines virtualization management.
As virtualization technology emerges, more and more enterprises are using a virtual server as their main server because of the increased server utilization, workload optimization and energy efficiencies. But the availability and performance of virtual servers depend highly on the host. IBM Systems Director 6.1 provides a solution to monitor the resource utilization on the hosts, and perform planned actions on the virtual servers.
In this article, we’ll describe the relocation function of IBM Systems Director Virtualization Manager, and detail how to enable automatic virtual server relocation, when the host server is suffering from high CPU utilization. This solution is helpful to ensure the availability of the virtual servers, especially ones that run important applications.
IBM Systems Director 6.1
IBM Systems Director 6.1 is a platform-management foundation that streamlines the way you manage physical and virtual systems across a heterogeneous environment. By using industry standards, it supports multiple operating systems and virtualization technologies across IBM and non-IBM platforms. IBM Systems Director 6.1 contains a set of common tasks including discovery, inventory, configuration, system health, monitoring, updates, event notification and automation across managed systems. With these core capabilities, it provides consistent views for viewing managed systems, determining system relationships and identifying system statuses—helping users correlate technical resources with business needs.
Virtualization Manager provides the capability to manage the lifecycle of virtual resources through Systems Director. Currently, it supports virtualized environments including Hardware Management Console (HMC), Integrated Virtualization Manager (IVM), Microsoft Virtual Server (MSVS), VMware and Xen virtualization. Some additional basic discovery and health management is supported for z/VM virtualization. Virtualization Manager can be used to:
- View topology that shows the connections between physical and virtual resources, which can vary dynamically across time,
- Track alerts and system status for virtual resources and their and their related physical resources to easily diagnose problems affecting virtual resources,
- Create automation plans based on events and actions from virtual and physical resources, such as relocating a virtual server based on critical hardware alerts,
- Create, delete and manage virtual servers and virtual farms for several virtualization technologies in the industry and
- Relocate virtual servers to alternate physical hosts.
IBM Systems Director Virtualization Manager provides the capability to relocate a single virtual server or all the virtual servers on a host. Virtual server relocation is the act of moving a virtual server from one host to another host. There’re two types of relocation: live and static. The types of relocation are highly dependent on the environment.
Live relocation allows you to continue to run workloads on the virtual server during relocation, while static means either the virtual server was already powered off by the user prior to relocation, or the virtual server is powered off, relocated and powered back on by IBM Systems Director during the relocation process. Any platform that supports live relocation can also support static relocation, including IBM Power Systems under the control of the HMC or the IVM.
Enable automatic relocation based on CPU Utilization
You can automatically relocate virtual servers from one host to another when the primary host utilization reaches a specified threshold, such as 80 percent (see Figure 1). The Systems Director relocation and automation functions will release the overloaded host, and ensure the applications keep running on virtual servers. This solution can be applied in all the virtual environments supported by Systems Director 6.1. The virtual resource type can vary based upon CPU utilization, entitled processing units, memory and processor usage.
Preparation for Relocation Manager
Relocation requirements—Before you start a virtual server relocation, ensure you meet the relocation requirements. These can be found in the IBM InfoCetner Relocation of virtual servers is only possible between hosts within the same virtual farm. A virtual farm is a logical grouping of hosts and their virtual servers; it doesn’t represent a physical system. It’s used to facilitate tasks such as relocation. Relocation of clustered virtual servers isn’t supported.
Both the source and target host must have access to a shared storage area network (SAN). For Xen relocation, the virtual server image must be available on a shared storage volume, with that volume mounted by both the source and target host. Both the source and target host must have access to a shared communications network. Additionally, both must have a virtual network device with the same label. For Xen, the bridge must have the same name on both the source and target hosts.
The target host must have enough memory to support the virtual server. Additionally, for Xen, the source host must have memory available that’s equal to or greater than the virtual server or virtual servers you want to relocate. The target host must also support the configuration version of the virtual server.
Virtual servers to be relocated cannot be connected to a removable device such as a CD drive or diskette drive. Relocation of virtual servers that are suspended or in a transition state isn’t supported. Additionally, for Xen, the virtual server cannot be in an offline or paused state.
The version of a configuration file for a virtual server must be supported by the virtualization application that the virtualization manager subagent communicates with. Otherwise, the virtual server cannot be relocated. IBM Power Systems users must ensure they meet the minimum virtualization software requirement to relocate a virtual server. For HMC, you must be at version 7.3.3 or higher; for IVM, you must be at version 1.5.2 or higher.
Environment setup—In this example environment, VC2.5 manages two ESX3.5 hosts: “IBM 8837 45U KPGLF20” and “IBM 8837 45U KPGLF18.” Each host has virtual servers running. VMotion should be enabled in VC2.5 for two ESX3.5 hosts in order to support live relocation. To set up the environment:
- Install IBM Systems Director 6.1 to the management server, and start the application.
- Install the Systems Director CAS Agent to the managed systems, both ESX3.5 hosts and the VC2.5 server.
- Log in the IBM Systems Director 6.1 Server Web console: http://management_server_IP:8421/ibm/console. Discover the agent systems and request access to them.
- Install virtualization management subagent to the VC2.5 server using Update Manager. This subagent will provide virtual environment management functions. It can be applied to ESX3.x, VMware Virtual Center and Microsoft Virtual Server. Xen, HMC and IVM, don’t need additional subagent installed.
- Create a VMware Virtual Center type virtual farm named “VC25farm,” and add the two ESX3.5 hosts “IBM 8837 45U KPGLF20” and “IBM 8837 45U KPGLF18” into the farm.
For more details of IBM Systems Director 6.1 server and agent installation, please refer to its InfoCenter .
Create a Relocation Plan
A relocation plan specifies the source and destination of relocation. The source can be a single virtual server or all the virtual servers of a virtual host. The target should be a host in the same farm as the source host. VMware provides another option in the target field, “Relocated by CPU utilization,” which will relocate the virtual servers to any other host in the same farm as the source host, according to the virtual server CPU utilization. To create a plan:
- Select “Availability-> Relocation Plans.” Click the Create button to launch the Relocation Plan creation panel.
- The welcome page is shown when the Create Relocation Plan wizard is launched. Specify the source. It can be a single virtual server or all the virtual servers of a virtual host. In our example, for all virtual servers, we select “IBM 8837 45U KPGLF20” as the source host.
- Specify the target. We selected “IBM 8837 45U KPGLF18” as the target host or “Relocated by CPU utilization.”
- In this Save Plan panel, you can choose to save the plan or relocate the servers immediately. As we’ll use this relocation plan later, we selected “Save plan only.”
- After you click the Finish button, this relocation plan, named “Relocation All”, is saved in Systems Director. See Figure 2 for a summary of the relocation plan.
Create an Automation Plan
The automation plan contains two main parts: one is an event filter that catches specified events, and the other is event action, which can be executed automatically when the event filter catches events. In this example, we created an event filter tied to CPU utilization of the source host (IBM 8837 45U KPGLF20) identified in the relocation plan created earlier. Follow the steps below to create and set the relocation plan as an event action.
- Click “Automation->Automation Plans->Create” to launch the Creation panel.
- Enter the automation plan name “CPU-Relocation” and its description.
- Select the target. We selected the IBM 8837 45U KPGLF20 host as the target, because we’ll create an event filter based on its CPU utilization.
- Events. In this panel, we will create an event filter. Select “Advanced Event Filters,” and then click the Create button.
- In the pop-up panel, choose “Simple Event Filter.” Click “OK.”
- Wait for the Java GUI to start. Check IBM Systems Director Program->Virtualization ->Resource Monitor->CPU Utilization %-> Critical-High. Save this event filter as “VM CPU High” and check it. When the CPU utilization rate of the host reaches the Critical-High threshold, this event filter will catch the CPU event. We will set the Critical- High threshold to 80 percent or higher later.
- In Event Actions panel, click “Create.”
- Select “Start a task on the system that generate the event” to create an action.
- Wait for the Java GUI to launch. Select the relocation plan “Relocate All.”
- Save the action as “Execute Relocation Plan” and check it.
- Choose 24-7 as the time range.
The automation plan is created (Figure 3), and you can apply it now or later. It attaches both the relocation plan and the CPU Utilization event filter.
Set the Event Filter Threshold
Now, we’ll set the threshold of the critical-high event filter to 80 percent.
- Choose “System status and health ->Monitors,” in the Monitor panel. You’ll see an item called “Virtualization Manager Monitors;” it monitors four virtual resources of the virtual host, including the CPU utilization.
- Click the Browse button to select the virtual host IBM 8837 45U KPGLF20.
- Click “Virtualization Manager Monitors” In this panel, you’ll see all the virtual resources monitors of host IBM 8837 45U KPGLF20. We plan to set the CPU Utilization monitor threshold to 80 percent (Figure 4).
- Select the CPU utilization checkbox in the right-click menu, and select “Activate Threshold.”
- Choose “Critical,” and then input 80 percent as the threshold.
- Switch to the Options tab, and edit the minimum duration to five seconds. You can set the duration from seconds to days to meet your needs. You can also specify the amount of time in “Resend delay” to regenerate the event for the threshold.
- Active the automation plan “CPU-Relocation.”
Now, IBM Systems Director 6.1 starts monitoring the CPU utilization of host IBM 8837 45U KPGLF20. If its CPU utilization is greater than 80 percent for more than five seconds, all the virtual servers on IBM 8837 45U KPGLF20 will be relocated to host IBM 8837 45U KPGLF18. As the two ESX3.5 hosts are managed by VMware Virtual Center, which supports live relocation, all the applications running on the virtual servers won’t be interrupted during and after relocation.
IBM Systems Director 6.1 Virtualization Manager provides a simplified availability solution for customers using standalone ESX, Virtual Center/ESX, Microsoft Virtual Server, HMC, IVM, and Xen based virtualization. IBM Systems Director 6.1 can monitor the resource utilization and take actions (eg. relocation) accordingly to avoid downtime and improve the performance while all the actions are completely transparent to the operating system and applications.