| Oracle® VM User's Guide Release 3.0 for x86 Part Number E18549-03 |
|
|
PDF · Mobi · ePub |
| Oracle® VM User's Guide Release 3.0 for x86 Part Number E18549-03 |
|
|
PDF · Mobi · ePub |
A server pool is a domain of physical and virtual resources to host virtual machines, perform virtual machine migration, HA, and so on.
This chapter describes how to create and manage server pools and includes the following sections:
A server pool consists of one or more Oracle VM Servers, and represents a logical view of the storage where the virtual machines reside.
A server pool is scalable. If you find a server pool does not have sufficient resources, such as CPU or memory, to run the virtual machines, you can expand the server pool by adding more Oracle VM Servers. See Section 7.7.1, "Adding an Oracle VM Server to a Server Pool".
Oracle VM's deployment architecture utilizes server pools, with shared access to storage across Oracle VM Servers in the server pool. Virtual machines are stored on the shared storage and placed on one of the Oracle VM Servers to balance the workloads of the server pool.
Since the virtual machines are not bound to any specific Oracle VM Server in the server pool,virtual machines are not prevented from starting up simply because an individual Oracle VM Server happens to be down for maintenance or otherwise unavailable at the time. Further, since the load-balancing algorithm assures that a virtual machine is placed on the Oracle VM Server with the most resources available, it also helps assure the maximum aggregate performance from the server pool.
Oracle VM works in concert with Oracle OCFS2 to provide shared access to server pool resources residing in an OCFS2 file system. This shared access feature is crucial in the implementation of high availability (HA) for virtual machines running on the Oracle VM Servers that belong to a server pool with clustering enabled.
OCFS2 is a cluster file system for Linux, which allows multiple nodes (Oracle VM Servers) to access the same disk at the same time. OCFS2, which provides both performance and HA, is used in many applications that are cluster-aware or that have a need for shared file system facilities. With Oracle VM, OCFS2 ensures that Oracle VM Servers belonging to the same server pool access and modify resources in the shared repositories in a controlled manner.
The OCFS2 software includes the core file system, which offers the standard file system interfaces and behavioral semantics and also includes a component which supports the shared disk cluster feature. The shared disk component resides mostly in the kernel and is referred to as the O2CB cluster stack. It includes:
A disk heartbeat to detect live servers
A network heartbeat for communication between the nodes
A Distributed Lock Manager (DLM) which allows shared disk resources to be locked and released by the servers in the cluster
OCFS2 also offers several tools to examine and troubleshoot the OCFS2 components. For detailed information on OCFS2, see the OCFS2 documentation at:
http://oss.oracle.com/projects/ocfs2/documentation/
Oracle VM decouples storage repositories and clusters so that if a storage repository is taken offline, the cluster is still available. A loss of one heartbeat device does not force an Oracle VM Server to self fence.
When you create a server pool, you have a choice to activate the cluster function which offers these benefits:
Shared access to the resources in the repositories accessible by all Oracle VM Servers in the cluster.
Protection of virtual machines in the event of a failure of any Oracle VM Server in the server pool.
To configure the server pool cluster and enable HA in a server pool, select the Activate Cluster check box when you create or edit a server pool. See Section 7.6, "Creating a Server Pool" and Section 7.7.3, "Editing a Server Pool" for more information on creating and editing a server pool.
When you create a server pool, you specify:
Server pool name and description
A virtual IP address
Whether or not to activate the cluster
A server pool file system for the global heartbeat and other cluster information
During server pool creation, the server pool file system specified for the new server pool is accessed and formatted as an OCFS2 file system. This formatting creates several management areas on the file system including a region for the global disk heartbeat. Oracle VM formats the server pool file system as an OCFS2 file system whether the file system is accessed by the Oracle VM Servers as an NFS share, a FC LUN or iSCSI LUN.
The virtual IP address is used by Oracle VM Manager to communicate with the server that is designated as the Master in the server pool. If the master changes, the virtual IP address is transferred to the new Master, insuring that Oracle VM Manager continues to communicate with the Master.
The next step is to add Oracle VM Servers to the newly created server pool. When Oracle VM Servers are added, Oracle VM:
Selects a Master Oracle VM Server.
Configures the Virtual IP address selected during pool creation as a virtual network interface on top of the management interface for the Master Oracle VM Server.
Creates the cluster configuration file and the cluster time-out file.
Pushes the configuration files to all Oracle VM Servers in the server pool.
Starts the cluster.
On each Oracle VM Server in the cluster, the cluster configuration file is located at /etc/ocfs2/cluster.conf, and the cluster time-out file is located at /etc/sysconfig/o2cb.
Starting the cluster activates several services and processes on each of the Oracle VM Servers in the cluster. The most important processes and services are discussed in Table 7-1.
| Service | Description |
|---|---|
|
02net |
The o2net process creates TCP/IP intra-cluster node communication channels on port 7777 and sends regular keep-alive packages to each node in the cluster to validate if the nodes are alive. The intra-cluster node communication uses the network with the Cluster Heartbeat role. By default, this is the Server Management network. You can however create a separate network for this function. See Section 6.2, "Network Usage" for information about the Cluster Heartbeat role. Make sure the firewall on each Oracle VM Server in the cluster allows network traffic on the heartbeat network.By default, the firewall is disabled on Oracle VM Servers after installation. |
|
o2hb-diskid |
The server pool cluster also employs a disk heartbeat check. The o2hb process is responsible for the global disk heartbeat component of cluster. The heartbeat feature uses a file in the hidden region of the server pool file system. Each pool member writes to its own block of this region every two seconds, indicating it is alive. It also reads the region to maintain a map of live nodes. If a server pool member's block is no longer updated, the Oracle VM Server is considered dead. If an Oracle VM Server dies, the Oracle VM Server is fenced. Fencing forcefully removes dead members from the server pool to make sure active pool members are not obstructed from accessing the fenced Oracle VM Server's resources. |
|
o2cb |
The o2cb service is central to cluster operations. When an Oracle VM Server boots, the o2cb service starts automatically. This service must be up for the mount of shared repositories to succeed. |
|
ocfs2 |
The ocfs2 service is responsible for the file system operations. This service also starts automatically. |
|
ocfs2_dlm and ocfs2_dlmfs |
The DLM modules (ocfs2_dlm, ocfs2_dlmfs) and processes (user_dlm, dlm_thread, dlm_wq, dlm_reco_thread, and so on) are part of the Distributed Lock Manager. OCFS2 uses a DLM to track and manage locks on resources across the cluster. It is called distributed because each Oracle VM Server in the cluster only maintains lock information for the resources it is interested in. If an Oracle VM Server dies while holding locks for resources in the cluster, for example, a lock on a virtual machine, the remaining Oracle VM Servers in the server pool gather information to reconstruct the lock state maintained by the dead Oracle VM Server. |
WARNING:
Do not manually modify the cluster configuration files, or start and stop the cluster services. Oracle VM Manager automatically starts the cluster on Oracle VM Servers that belong to a server pool. Manually configuring or operating the cluster may lead to cluster failure.
When you create a repository on a shared disk, an OCFS2 file system is created on the shared disk. This occurs for local repositories as well. The resources in the repositories, for example, virtual machine configuration files, virtual disks, ISO files, templates and assemblies, can then be shared safely across the server pool. When a server pool member stops or dies, the resources owned by the departing server are recovered, and the change in status of the server pool members is propagated to all the remaining Oracle VM Servers in the server pool.
Figure 7-1 illustrates server pool clustering, the disk and network heartbeats, and the use of the DLM feature to lock resources across the cluster.
Figure 7-1 Server Pool clustering with OCFS2 features
Figure 7-1 represents a server pool with three Oracle VM Servers. The server pool file system associated with this server pool resides on an NFS share. During server pool creation, the NFS share is accessed, a disk image is created on the NFS share and the disk image is formatted as an OCFS2 file system. This technique allows all Oracle VM server pool file systems to be accessed in the same manner, using OCFS2, whether the underlying storage element is an NFS share, an iSCSI LUN or a Fibre Channel LUN.
After the server pool is created, the Oracle VM Servers are added to the server pool. At that time, the cluster configuration is created, and the cluster state changes from offline to heartbeating. Finally, the server pool file system is mounted on all Oracle VM Servers in the cluster and the cluster state changes from heartbeating to DLM ready. As seen in Figure 7-1, the heartbeat region is global to all Oracle VM Servers in the cluster, and resides on the server pool file system. The network heartbeat, which is illustrated as a private network connection between the Oracle VM Servers, is configured before creating the first server pool in your Oracle VM environment. Using the network heartbeat, the Oracle VM Servers establish communication channels with other Oracle VM Servers in the cluster, and send keep-alive packets to detect any interruption on the channels.
For each newly added repository on a physical storage element, an OCFS2 file system is created on the repository, and the repository is usually presented to all Oracle VM Servers in the pool. Figure 7-1 shows one repository, Repository 3, which is accessible by Oracle VM Server 1 only. Any virtual machine whose resources reside on this repository cannot take advantage of the high availability feature afforded by the server pool.
Note that repositories built on NFS shares are not formatted as OCFS2 file systems. See Section 5.8, "Preparing and Configuring Storage Repositories" for more information on repositories.
Figure 7-1 shows several virtual machines with resources in shared Repositories 1 and 2. As virtual machines are created, started, stopped, or migrated, the resources for these virtual machines are locked by the Oracle VM Servers needing these resources. Each Oracle VM Server ends up managing a subset of all the locked resources in the server pool. A resource may have several locks against it. An exclusive lock is requested when anticipating a write to the resource while several read-only locks can exist at the same time on the same resource. Lock state is kept in memory on each Oracle VM Server as shown in the diagram. The distributed lock manager (DLM) information kept in memory is exposed to user space in the synthetic file system called dlmfs, mounted under /dlm. If an Oracle VM Server fails, its locks are recovered by the other Oracle VM Servers in the cluster and virtual machines running on the failed Oracle VM Server are restarted on another Oracle VM Server in the cluster. If an Oracle VM Server is no longer communicating with the cluster via the heartbeat, it can be forcibly removed from the cluster. This is called fencing. An Oracle VM Server can also fence itself if it realizes that it is no longer part of the cluster. The Oracle VM Server uses a machine reset to fence. This is the quickest way for the Oracle VM Server to rejoin the cluster.
When creating a server pool, you specify whether the servers in the pool will be part of a cluster or not. In most cases, you create a clustered server pool. You can create a non-clustered pool when all servers in the pool are expected to use only NFS shares as repositories. If your Oracle VM Servers are also expected to access repositories on physical disks, then these servers should be part of a clustered server pool.
Figure 7-2 illustrates server pools in an unclustered configuration, with shared access to resources on NFS storage but no HA features for the servers.
Figure 7-2 Unclustered Server Pools Using Only NFS Storage
Non-clustered server pools do not require a server pool file system, though a Virtual IP is still required and the Master function is also assigned to one of the server pool members. A non-clustered server pool does not support HA for virtual machines deployed on its servers. If a server fails, the virtual machines on this server have to be restarted manually on a server in this server pool, or possibly on a server in another server pool, if that server pool also has access to the repositories needed for deploying the virtual machines on the failed server. Live Migration is supported between servers in a non-clustered pool if the servers have the same CPU affinity (same family and type of CPU). One cannot create a repository on a physical disk local to a server if that server does not belong to a clustered server pool. If you want to create a pool with one server, and use a physical disk attached to that server as a repository, you have to create a clustered pool and add this single server to the newly defined clustered pool.
Note:
Converting non-clustered server pools to clustered server pools is not supported in Release 3.0 of Oracle VM.You can set up HA to help ensure the uninterrupted availability of a virtual machine. If HA is configured and a Oracle VM Server is restarted or shut down, the virtual machines running on it are either restarted on, or migrated to, another Oracle VM Server.
The following prerequisites are requirement to implement HA:
The server pool must contain multiple Oracle VM Servers. HA cannot be implemented with a stand-alone Oracle VM Server.
All Oracle VM Servers must be Oracle VM Server Release 3.0 or above.
To use HA, you must first enable HA on the server pool, then on all virtual machines, as shown in Figure 7-3, "Enabling HA". If you enable HA on the server pool and then for virtual machines, when an Oracle VM Server is shut down or fails, the virtual machines are migrated or restarted on another available Oracle VM Server. HA must be enabled for both the server pool and for virtual machines.
To automatically configure the server pool cluster and enable HA in a server pool, select the Activate Cluster check box when you create or edit a server pool. See Section 7.6, "Creating a Server Pool" and Section 7.7.3, "Editing a Server Pool" for more information on creating and editing a server pool.
To enable HA on a virtual machine, select the Enable High Availability check box when you create or edit a virtual machine. See Section 8.7, "Creating a Virtual Machine" and Section 8.9.9, "Editing a Virtual Machine" for more information on creating and editing a virtual machine.
If HA is enabled, when you restart, shut down, or delete an Oracle VM Server in Oracle VM Manager, you are prompted to migrate the running HA-enabled virtual machines to another available Oracle VM Server. If you do not migrate the running virtual machines, Oracle VM attempts to find an available Oracle VM Server on which to restart the virtual machines.
If there are noOracle VM Servers available, the virtual machines are shut down (Powered Off) and are restarted when an Oracle VM Server becomes available.
The possible HA scenarios are:
If you shut down or restart an Oracle VM Server in Oracle VM Manager, you are prompted which virtual machines to migrate to another available Oracle VM Server. Any virtual machines which are not migrated, are restarted on an available Oracle VM Server.
If an Oracle VM Server fails, all running virtual machines are restarted automatically on another available Oracle VM Server.
If an Oracle VM Server fails and no other Oracle VM Servers are available, all running virtual machines are restarted when an Oracle VM Server becomes available.
Figure 7-4 shows an Oracle VM Server failing and the virtual machines restarting on other Oracle VM Servers in the server pool.
Figure 7-4 HA in effect for an Oracle VM Server failure
You should test your HA configuration to ensure it is properly configured in the event of a real failure.
Figure 7-5 shows an Oracle VM Server restarting or shutting down and the virtual machines migrating to other Oracle VM Servers in the server pool.
Figure 7-5 HA in effect for an Oracle VM Server restart or shut down
This section discusses the policies you can set to manage server pools, the Oracle VM Servers and virtual machines in server pools, and the networks used in a server pool. The server pool policies available are:
The Distributed Resource Scheduler (DRS) optimizes virtual machine resource utilization in a server pool. DRS automatically moves running virtual machines to another Oracle VM Server in a server pool if any of the Oracle VM Servers exceed a specified CPU threshold for a specified period of time. DRS continuously samples performance data from every Oracle VM Server and every virtual machine.
The movement of virtual machines is policy-driven. When a threshold is reached, Oracle VM Manager live migrates the running virtual machine from one Oracle VM Server to another, without down time. Oracle VM Manager allows you to specify a DRS threshold for each server pool, and to choose which Oracle VM Servers participate in the policy.
See Section 7.7.4, "Editing Server Pool Policies" for information on enabling and configuring the DRS in a server pool.
Distributed Power Management (DPM) is used when there are periods of relative low resource utilization to increase the consolidation ratio on fewer Oracle VM Servers. DPM dynamically migrates virtual machines from under-utilized Oracle VM Servers. When there are Oracle VM Servers without virtual machines running the Oracle VM Server can be powered off, conserving power until the Oracle VM Server is needed again.
DPM aims to keep only the minimum necessary number of Oracle VM Servers running. If a periodic check reveals that a Oracle VM Server's CPU utilization is operating at below a user-set level, virtual machines are live migrated to other Oracle VM Servers in the same server pool.
When all virtual machines are migrated, the Oracle VM Server is shut down.
If an Oracle VM Server exceeds the DPM policy CPU threshold, Oracle VM Manager looks for other Oracle VM Servers to migrate virtual machines to from the busy Oracle VM Server. If no powered Oracle VM Servers are available, Oracle VM Manager finds and starts a powered-off Oracle VM Server to power on. When that Oracle VM Server is running, Oracle VM Manager off-loads the virtual machines from the busy Oracle VM Server to the newly started Oracle VM Server.
Oracle VM Manager allows you to specify a DPM threshold for each server pool, and to choose which Oracle VM Servers participate in the policy.
See Section 7.7.4, "Editing Server Pool Policies" for information on enabling and configuring DPM in a server pool.
Both the DRS and DPM policies can also be set for the networks used by Oracle VM Servers in a server pool. When a network used by an Oracle VM Server exceeds its threshold, virtual machines are migrated to other Oracle VM Servers to either balance the resources used (DRS), or reduce the power used (DPM). Each network on an Oracle VM Server can have a threshold set. The threshold applies to either the received data or the transmitted data. If the threshold is set to say 50%, when an Oracle VM Server's receive or transmit traffic on that network exceeds 50% of the theoretical capacity of the network, the Oracle VM Server is deemed to be over the threshold. The theoretical capacity of a network on an Oracle VM Server is equal to the port speed of the physical Ethernet adapter on the Oracle VM Server. If the network is bonded in a fail-over configuration, then the port capacity is equal to the port speed of one of the Ethernet adapters. If the network is bonded on a Oracle VM Server with link aggregation, then the network capacity is equal to the sum of the speed of the bonded Ethernet adapters.
You set the network policies for DRS and DPM when you set up the server pool policy. See Section 7.7.4, "Editing Server Pool Policies" for information on enabling and configuring network DRS and DPM policies in a server pool.
A server pool consists of at least one, but usually multiple Oracle VM Servers. All Oracle VM Servers in a server pool should have CPUs in the same CPU family and of the same type. If they are not in the same CPU family and type, some operations such as live migration may fail. Though the CPUs should be in the same CPU family, they may have differing configurations, such as different number of cores. Other hardware components on the host computer may also differ, such as the amount of RAM, the number and size of disk drives, and so on.
Although the host computers may have differing configurations, Oracle recommends that all Oracle VM Servers in a server pool are identical. Oracle VM Manager contains rules for processor compatibility groups. If live migration is attempted between incompatible processors, an error message is displayed.
Before creating a server pool, you must have:
IP addresses for the Oracle VM Servers.
IP address to use as the virtual IP address.
Password to access the Oracle VM Agent installed on the Oracle VM Server(s).
Note:
The Oracle VM Agent password must be the same on each Oracle VM Server in a server pool. For information on changing the Oracle VM Agent password on an Oracle VM Server, see the Oracle VM Installation and Upgrade Guide.A server pool should have a dedicated file system (either a NAS export, or a LUN) to use as the server pool's file system. Oracle recommends that you create this storage with a size of at least 10 GB.
If any errors are encountered when you create a server pool, the Oracle VM Servers are returned to the unconfigured state.
To create a server pool:
In the Home view, select Create Server Pool from the Actions menu. The Create Server Pool dialog box is displayed.
Enter the server pool information:
Server Pool Name: The name of the server pool.
A server pool name must consist of alphanumeric characters, and must not contain spaces or special characters, except the underscore (_) or hyphen (-) characters. The maximum length of a server pool name is 200 characters.
Description: A description of the server pool. This field is optional.
Virtual IP: An IP address used to identify the master Oracle VM Server, which controls the other Oracle VM Server in the server pool. In the event that the master Oracle VM Server fails or is placed into maintenance mode, another Oracle VM Server is selected to perform the master role, and this IP address is then assigned to the new host.
Keymap: The key mapping to be used when connecting to a virtual machine's console.
Secure VM Migrate: Select whether to enable encrypted migration of virtual machines. When Secure VM Migrate is checked, virtual machines are migrated using SSL to protect the data during the migration process. Secure migration of a virtual machine may effect the time taken to perform the migration as the encryption and decryption of data requires more system resources and time.
Activate Cluster: Select whether to enable clustering of the Oracle VM Servers in the server pool to enable HA. See Section 7.4, "High Availability (HA)" for more information on HA policies and configuration.
Type of Pool File System: Select the file system type to use for the server pool, either a Network File System, or a Physical Disk. The server pool file system is used to hold the server pool and cluster data, and is also used for cluster heartbeating. Oracle recommends that you create this storage with a size of at least 12 GB, as a NAS export or LUN.
A server pool file system is exclusive, just like other storage. That is, in the same way that you cannot create two storage repositories on the same export path, the server pool file system cannot be shared with other server pools, or with storage repositories. Each fully qualified export path (for example, /export/myexport/one, /export/myexport/two) must be used for one, and only one, purpose, that is, for a storage repository, or a server pool file system.
For information on creating storage, see Chapter 5, "Managing Storage".
Network File System: The file system to use as the pool file system. Click the Search icon in the Location field to search for a network file system. This field is displayed if you select Network File System in the previous field.
Physical Disk: The file system to use as the pool file system. Click the Search icon in the Location field to search for a physical disk. This field is displayed if you select Physical Disk in the previous field.
Click Finish.
The server pool is created.
When you have created a server pool, the next step is to add Oracle VM Servers to it. Before you can add an Oracle VM Server to a server pool, you must first discover it. See Section 7.8.1, "Discovering Oracle VM Servers". When the Oracle VM Server is discovered, add it to the server pool, see Section 7.7.1, "Adding an Oracle VM Server to a Server Pool".
When you have created a server pool, you can perform a number of actions on it, like adding and removing Oracle VM Servers, and editing server pool policies. This section discusses the actions you can perform on a server pool and contains:
When you need more resources in a server pool (such as the number of CPUs and the size of memory), you can add more Oracle VM Servers. For example, when you want to run more virtual machines and the resources in the server pool are reaching capacity, you can add more Oracle VM Servers which increases the available resources.
Adding Oracle VM Servers to a server pool requires the modification of both the cluster configuration information and the server pool information, on all Oracle VM Servers. This is performed automatically.
Adding Oracle VM Servers to a server pool may trigger pending HA operations if there were previously insufficient resources to run all HA virtual machines.
Note:
All Oracle VM Servers in a server pool must have the same Oracle VM Agent password.To add Oracle VM Servers to a server pool:
In the Home view, select the server pool in the Server Pools folder in the navigation pane. Select Add/Remove Servers from the Actions menu. The Add/Remove Servers from the Server Pool dialog box is displayed.
Select the Oracle VM Servers you want to add to the server pool from the Available Servers list box and move them to the Selected Servers list box. Click OK.
The server pool is updated to include new Oracle VM Servers.
When you want to remove resources in a server pool, perhaps to be used elsewhere, you can remove an Oracle VM Server from a server pool. Removing an Oracle VM Server from a server pool does not delete it, but places it in the unconfigured state.
Before you can remove an Oracle VM Server from a server pool, it must be suspended from participating in all server pool roles and all virtual machines stopped or migrated. To automatically migrate the running virtual machines and suspend all server pool roles, place the Oracle VM Server in maintenance mode. See Section 7.8.9, "Placing an Oracle VM Server into Maintenance Mode" for information on putting an Oracle VM Server into maintenance mode.
Removing an Oracle VM Server from a server pool requires modification of both cluster configuration information and server pool information on all Oracle VM Servers in the server pool. This is performed automatically.
To remove Oracle VM Servers from a server pool:
In the Home view, select the server pool in the Server Pools folder in the navigation pane. Select Add/Remove Servers from the Actions menu. The Add/Remove Servers from the Server Pool dialog box is displayed.
Select the Oracle VM Servers you want to remove from the server pool from the Available Servers list box and move them to the Selected Servers list box. Click OK.
The server pool is updated and the Oracle VM Servers are removed and placed in the Unassigned Servers folder in the Hardware view.
You can edit the configuration information of a server pool, including the server pool name, description, and key mapping. You can also change the master server, which controls the cluster, as well as whether the virtual machines are migrated securely. You cannot change the virtual IP address or the file system used for the server pool.
To add or remove Oracle VM Servers from a server pool, see Section 7.7.1, "Adding an Oracle VM Server to a Server Pool" and Section 7.7.2, "Removing an Oracle VM Server from a Server Pool".
To edit a server pool:
In the Home view, select the server pool in the Server Pools folder in the navigation pane. Select Edit Server Pool from the Actions menu. The Edit the Server Pool dialog box is displayed.
Edit the server pool information:
Server Pool Name: The name of the server pool.
A server pool name must consist of alphanumeric characters, and must not contain spaces or special characters, except the underscore (_) or hyphen (-) characters. The maximum length of a server pool name is 200 characters.
Description: A description of the server pool.
Virtual IP: This field cannot be modified.
Pool File System: This field cannot be modified.
Keymap: The key mapping to use in the consoles for all virtual machines in the server pool.
Secure VM Migrate: Select whether to enable encrypted migration of virtual machines.
Click OK.
The server pool changes are automatically propagated to all Oracle VM Servers in the server pool by the server master.
You can set power and resource utilization policies for a server pool. The two policies you can set are for:
Distributed Resource Scheduler (DRS): Optimizes virtual machine resource utilization in a server pool.
Distributed Power Management (DPM): Increases the consolidation ratio to use fewer Oracle VM Servers during periods of relative low resource utilization.
The policy is also able to be set for networks used in a server pool. You can set the server pool to use either DRS, or DPM, but not both at the same time.
See Section 7.5, "Server Pool Policies" for more information on these server pool policies.
To set or edit a server pool policy:
In the Home view, select the server pool in the Server Pools folder in the navigation pane. Select Edit Policies from the Actions menu.
The Configure Policy step of the Configure DRS/DPM wizard is displayed.
Enter the server pool policy information:
Policy Control:
Policy Type: You can choose from either DRS, DPM, or none. You cannot set both DRS and DPM to be active at the same time.
Time Period (Minutes): The time period for the policy job to run. This sets the policy job to run every n minutes, for example, 10 sets the policy job to run every 10 minutes. You can enter a number between 1 and 60.
Server CPU:
Enable: Set whether to enable or disable logging of CPU performance and utilization.
Threshold (%): The maximum amount of CPU percentage usage allowed before the policy must be enacted. You can enter between 0 and 99.
Servers: Select the Oracle VM Servers for which the policy should be enabled by moving the selected Oracle VM Servers from the Available Servers to the Selected Servers shuttle box.
Click Next.
The Select Networks step of the Configure DRS/DPM wizard is displayed. Select the networks that should be included in the policy. Click Next.
The Network Settings step of the Configure DRS/DPM wizard is displayed. Select whether to enable the policy on the network, and select the threshold at which the policy should be enacted for the network. Click Finish.
The policy is set for the server pool. When you select a server pool in the navigation pane, a Policies tab is available in the management pane. The Policies tab shows the policy settings for the server pool.
Before you can delete a server pool, you must delete all virtual machines and remove all Oracle VM Servers from the server pool.
To delete a virtual machine, see Section 8.9.10, "Deleting a Virtual Machine". To remove an Oracle VM Server from a server pool, see Section 7.7.2, "Removing an Oracle VM Server from a Server Pool".
To delete a server pool:
In the Home view, select the server pool in the Server Pools folder in the navigation pane. Select Delete from the Actions menu.
The Delete Confirmation dialog box is displayed.
Select OK to delete the server pool.
The server pool is deleted.
Use Oracle VM Manager to manage Oracle VM Servers. Do not manage Oracle VM Servers directly using the Oracle VM Server command line.
A server pool must contain at least one Oracle VM Server. After installing an Oracle VM Server, you must discover it in Oracle VM Manager before it can be added to a server pool.
Before you discover Oracle VM Servers and add them to a server pool, you must:
Identify the IP address of the Oracle VM Server(s). If you installed Oracle VM Server with a static IP address (recommended), this is the IP address you use. If you installed Oracle VM Server with a dynamic IP address, log onto the Oracle VM Server and determine the IP address.
Identify the password to access the Oracle VM Agent installed on the Oracle VM Server.
This section contains:
When an Oracle VM Server is installed and starts up, it listens for Oracle VM Manager server pool discovery events. Before you can add an Oracle VM Server to a server pool, it must first be discovered.
To discover an Oracle VM Server:
In the Hardware view, select Discover Servers from the Actions menu. The Discover Servers dialog box is displayed.
Enter information about the Oracle VM Server(s) to be discovered:
Specify an IP Address (or range): The IP address of the Oracle VM Server. Click Add. If you want to discover more Oracle VM Servers, enter the IP address for each, and click Add to add the Oracle VM Server to the IP Addresses list box.
Tip:
If you want to copy/paste an IP address into this field, copy the IP address into your copy/paste buffer, then in the first IP address field paste the contents of the buffer and press the Tab or Enter key on your keyboard.IP Addresses: Lists the IP address(es) of the Oracle VM Server(s) to be discovered. Add IP addresses using the Specify an IP Address field. To remove an IP address select it and click Delete.
Oracle VM Agent Port: The port on which the Oracle VM Agent is listening. This is most likely the default port 8899.
Oracle VM Agent Password: The password to connect to the Oracle VM Agent. The password must be the same on all Oracle VM Servers.
Click OK.
The Oracle VM Servers are discovered and added to the Unassigned Servers folder. The newly discovered Oracle VM Server contains some basic information about itself, and about any immediate connectivity to a shared SAN, but it is considered to be in an unconfigured state. The Oracle VM Server cannot be used to perform any virtual machine, or active cluster operations. Physical network and storage configuration can be performed, and any subsequent storage discovery operations may also be performed.
When an Oracle VM Server is discovered, it is configured to use the Oracle VM Manager host computer as the Network Time Protocol (NTP) time source. This ensures that all Oracle VM Servers are in sync with each other in the Oracle VM Manager environment.
The Utilization % column in the Servers tab does not report the utilization statistics of an Oracle VM Server that is in the Unassigned Servers folder . This field does not report utilization statistics unless an Oracle VM Server is included in a server pool.
Note:
Discovered Oracle VM Servers do not use a Virtual IP address until they are properly configured by being included in a server pool.When an Oracle VM Server has been discovered, it can be added to a server pool. See Section 7.7.1, "Adding an Oracle VM Server to a Server Pool" for information on adding an Oracle VM Server to a server pool.
If the physical state of an Oracle VM Server changes, you should discover it again to update the configuration information in Oracle VM Manager.
To rediscover an Oracle VM Server:
Select the Oracle VM Server in the navigation pane.
Select Rediscover Server from the Actions menu.
The configuration information about the Oracle VM Server is updated in Oracle VM Manager.
By default, the user to who adds the Oracle VM Server to Oracle VM Manager has ownership of that Oracle VM Server. If an Oracle VM Server is in the Unassigned Servers folder in the Hardware view and does not have ownership by your user, you need perform the following steps to take ownership and use the Oracle VM Server in a server pool.
To take ownership of an Oracle VM Server:
In the Hardware view, select the Oracle VM Server in the Unassigned Servers folder in the navigation pane. Select Edit Server from the Actions menu. The Edit Server dialog box is displayed.
Select the Take Ownership check box to take ownership of the Oracle VM Server. Click OK.
To relinquish ownership of the Oracle VM Server, repeat the same procedure and uncheck the Take Ownership check box.
You cannot relinquish ownership of an Oracle VM Server while it is in a server pool, you must first remove it from a server pool. See Section 7.7.2, "Removing an Oracle VM Server from a Server Pool" for information on removing an Oracle VM Server from a server pool.
You can edit the configuration information for an Oracle VM Server to change the name, description, any server pool roles, and to take it offline to perform system maintenance.
To edit the configuration information of an Oracle VM Server:
In the Home view, select the Oracle VM Server in the navigation pane. Select Edit Server from the Actions menu. The Edit Server dialog box is displayed.
Edit the information about the Oracle VM Server:
Name: The name of the Oracle VM Server.
Description: A description of the Oracle VM Server.
Maintenance Mode: Select whether to place the Oracle VM Server in maintenance mode. See Section 7.8.9, "Placing an Oracle VM Server into Maintenance Mode" for more information about Oracle VM Server maintenance mode.
Take Ownership: Select to take ownership of the Oracle VM Server. See Section 7.8.3, "Taking Ownership of an Oracle VM Server" for information on ownership of an Oracle VM Server.
Tip:
You cannot edit the ownership of an Oracle VM Server if it is included in a server pool.Configure Server IPMI: Select to enable the Intelligent Platform Management Interface (IPMI). IPMI allows you to remotely power off an Oracle VM Server, and to send a wake on lan message to power on an Oracle VM Server without having to physically press the power button. To configure IPMI enter the following information in the fields:
Username: The username for the IPMI.
Password: The password for the IPMI.
To set or modify the IPMI password, you must also select the Change Password check box.
IP Address: The IP address of the IPMI.
Click OK. The Oracle VM Server is updated.
When you start an Oracle VM Server, it is started using the Intelligent Platform Management Interface (IPMI), or Wake-on-LAN (WOL). If neither IPMI nor WOL have been configured, the job to start the Oracle VM Server cannot be completed. The Oracle VM Server must then be powered on manually. See Chapter 7, "Editing Oracle VM Server Information" for information on configuring IPMI.
To start an Oracle VM Server:
In the Home view, select the Oracle VM Server in the navigation pane. Select Start Server from the Actions menu.
The Oracle VM Server is started.
When you stop an Oracle VM Server, it is stopped using the Intelligent Platform Management Interface (IPMI), or a system power off command. Before you can stop an Oracle VM Server, you must stop any running virtual machines, or place the Oracle VM Server into maintenance mode to automatically migrate the running virtual machines.
WARNING:
Make sure that the IPMI is properly configured on the Oracle VM Server, otherwise it cannot be started again remotely. See Chapter 7, "Editing Oracle VM Server Information" for IPMI configuration.
Alternatively, make sure that the Oracle VM Server are on the same subnet and activate the Wake-on-LAN (WOL) feature in the Oracle VM Server BIOS. If an Oracle VM Server cannot start through IPMI or WOL, it must be power-cycled manually.
To stop an Oracle VM Server:
Stop or migrate any running virtual machines. To stop the virtual machines see Section 8.9.5, "Shutting Down a Virtual Machine". To automatically migrate the virtual machines to other Oracle VM Servers in the server pool, place the Oracle VM Server into maintenance mode, see Section 7.8.9, "Placing an Oracle VM Server into Maintenance Mode".
In the Home view, select the Oracle VM Server in the navigation pane. Select Stop Server from the Actions menu.
The Oracle VM Server is powered off.
When you restart an Oracle VM Server, an operating system restart command is sent and the Oracle VM Server is restarted. Before you can restart an Oracle VM Server, you must stop any running virtual machines, or place the Oracle VM Server into maintenance mode to automatically migrate the running virtual machines.
When the Oracle VM Server is restarted and rejoins the server pool, the master Oracle VM Server initiates any pending HA operations in the server pool. When Oracle VM Manager is notified that the Oracle VM Server is online and available, any pending state changes are reconciled before any policy actions are resumed.
To restart an Oracle VM Server:
Stop or migrate any running virtual machines. To stop the virtual machines see Section 8.9.5, "Shutting Down a Virtual Machine". To automatically migrate the virtual machines to other Oracle VM Servers in the server pool, place the Oracle VM Server into maintenance mode, see Section 7.8.9, "Placing an Oracle VM Server into Maintenance Mode".
In the Home view, select the Oracle VM Server in the navigation pane. Select Restart Server from the Actions menu.
The Oracle VM Server is restarted.
You can select which Oracle VM Server performs the master Oracle VM Server role in a server pool with the Edit the Server Pool dialog box. See Section 7.7.3, "Editing a Server Pool" for information on using the Edit the Server Pool dialog box.
An Oracle VM Server can be placed into maintenance mode to perform hardware or software maintenance. When an Oracle VM Server is placed in maintenance mode, any virtual machines running on the Oracle VM Server are automatically migrated to other Oracle VM Servers in the server pool, if they are available, otherwise they are stopped. If the Oracle VM Server is the master Oracle VM Server in the server pool, this role is moved to another Oracle VM Server in the server pool, if available.
To place an Oracle VM Server into maintenance mode:
In the Home view, select the Oracle VM Server in the navigation pane. Select Edit Server from the Actions menu. The Edit Server dialog box is displayed.
Select the Maintenance Mode check box to place the Oracle VM Server into maintenance mode. Click OK.
The Oracle VM Server is placed into maintenance mode.
When you have finished performing maintenance on the Oracle VM Server and you are ready for it to rejoin the server pool, perform the same procedure and uncheck the Maintenance Mode check box.
When you delete an Oracle VM Server, it is removed from the Oracle VM Manager repository and becomes unmanaged. The Oracle VM Server is not stopped, nor is anything physically done to the Oracle VM Server.
Before you can delete an Oracle VM Server, you must stop any running virtual machines, or place the Oracle VM Server into maintenance mode to automatically migrate the running virtual machines. You must also remove the Oracle VM Server from the server pool.
To delete an Oracle VM Server and remove it from Oracle VM Manager:
Stop or migrate any running virtual machines. To stop the virtual machines see Section 8.9.5, "Shutting Down a Virtual Machine". To automatically migrate the virtual machines to other Oracle VM Servers in the server pool, place the Oracle VM Server into maintenance mode, see Section 7.8.9, "Placing an Oracle VM Server into Maintenance Mode".
Remove the Oracle VM Server from the server pool. See Section 7.7.2, "Removing an Oracle VM Server from a Server Pool" for information on removing Oracle VM Server from server pools.
Select the Hardware view. Select the Hardware tab in the navigation pane, and select the Unassigned Servers folder. Select the Oracle VM Server and select Delete from the Actions menu.
The Delete Confirmation dialog box is displayed. Click OK.
The Oracle VM Server is deleted from Oracle VM Manager.
Updates and upgrades to Oracle VM Servers can be automatically performed using a Yum repository. To access patch updates for Oracle VM, you should contact Oracle to purchase an Oracle VM Support contract and gain access to the Unbreakable Linux Network (ULN) which contains updates for Oracle VM. If you have access to ULN you can use this to set up your own Yum repository to use when updating your Oracle VM Servers. Setting up a Yum repository is beyond the scope of this documentation, however you can read about setting one up in an OTN article "Yum Repository Setup" at:
http://www.oracle.com/technetwork/topics/linux/yum-repository-setup-085606.html
Make sure you subscribe to the Oracle VM Release 3.0 channel on ULN when you set up your Yum repository. If you have a Yum repository configured for Oracle VM Server updates, you add this to Oracle VM Manager and perform the updates from within the Oracle VM Manager user interface.
To add a Yum repository:
Select Server Update Management (YUM) from the Tools menu. The Server Update Management (YUM) dialog box is displayed.
Enter the following information about the Yum repository:
YUM Repository Name: A name for the Yum repository.
YUM Base URL: The URL to access the Yum repository, for example:
http://example.com/OracleVM-3.0/
Enable GPG Key: Whether to use a GPG key for the Yum repository. The GPG key (or GnuPG key) is the key used in the GNU project's implementation of the OpenPGP key management standard. The GPG key is used to check the validity of the Yum repository, and any packages (RPMs) downloaded from the repository.
YUM GPG Key: The GPG key for the Yum repository, for example:
http://example.com/RPM-GPG-KEY-OVM-3.0
The GPG key must be available via one of HTTP, FTP, FILE or HTTPS protocols.
The GPG key for Oracle-signed updates from ULN is pre-installed on Oracle VM Server at /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle. If you want to use this GPG key, enter:
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
This field is only enabled when you select Enable GPG Key.
Click OK.
The YUM repository is added and ready to use.
When an Oracle VM Server update is available, an event is posted to the Oracle VM Server and displayed in the Update Required column in the Servers tab.
To update an Oracle VM Server, the virtual machines on the Oracle VM Server must first be migrated to another Oracle VM Server. You can manually migrate the virtual machines if you prefer, or have the upgrade job perform the virtual machine migration automatically. If the Oracle VM Server is a master Oracle VM Server, the master role is transferred to another Oracle VM Server in the server pool.
To update an Oracle VM Server:
Select the Oracle VM Server in the navigation pane and select Upgrade Server from the Actions menu. The Oracle VM Server is placed into maintenance mode, and the update performed. Any virtual machines on the Oracle VM Server are automatically migrated to another Oracle VM Server when it is put into maintenance mode. When the update is complete the Oracle VM Server is restarted and remains in maintenance mode.
To have the Oracle VM Server rejoin the server pool as a fully functioning member, edit the Oracle VM Server and take it out of maintenance mode.
For information on manually migrating virtual machines, see Section 8.9.2, "Live Migration of a Virtual Machine". For information on taking an Oracle VM Server out of maintenance mode, see Section 7.8.9, "Placing an Oracle VM Server into Maintenance Mode".
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
