| Cluster AdministrationChapter 3. Configuring Red Hat High Availability Add-On With CongaConga is a graphical user interface that you can use to administer the Red Hat High Availability Add-On. Note, however, that in order to use this interface effectively you need to have a good and clear understanding of the underlying concepts. Learning about cluster configuration by exploring the available features in the user interface is not recommended, as it may result in a system that is not robust enough to keep all services running when components fail. This chapter consists of the following sections: Configuring Red Hat High Availability Add-On software with Conga consists of the following steps: Before starting luci, ensure that the IP ports on your cluster nodes allow connections to port 11111 from the luci server on any nodes that luci will be communicating with. For information on enabling IP ports on cluster nodes, see Section 2.3.1, "Enabling IP Ports on Cluster Nodes". To administer Red Hat High Availability Add-On with Conga, install and run luci as follows: Select a computer to host luci and install the luci software on that computer. For example: # yum install luci Typically, a computer in a server cage or a data center hosts luci; however, a cluster computer can host luci. Start luci using service luci start. For example: # service luci startStarting luci: generating https SSL certificates... done [ OK ]Please, point your web browser to https://nano-01:8084 to access luci As of Red Hat Enterprise Linux release 6.1, you can configure some aspects of luci's behavior by means of the /etc/sysconfig/luci file, including the port and host parameters, as described in Section 2.4, "Configuring luci with /etc/sysconfig/luci". Modified port and host parameters will automatically be reflected in the URL displayed when the luci service starts. At a Web browser, place the URL of the luci server into the URL address box and click Go (or the equivalent). The URL syntax for the luci server is https://luci_server_hostname:luci_server_port. The default value of luci_server_port is 8084. The first time you access luci, a web browser specific prompt regarding the self-signed SSL certificate (of the luci server) is displayed. Upon acknowledging the dialog box or boxes, your Web browser displays the luci login page. Although any user able to authenticate on the system that is hosting luci can log in to luci, as of Red Hat Enterprise Linux 6.2 only the root user on the system that is running luci can access any of the luci components until an administrator (the root user or a user with administrator permission) sets permissions for that user. For information on setting luci permissions for users, refer to Section 3.3, "Controlling Access to luci".
There is an idle timeout for luci that logs you out after 15 minutes of inactivity. 3.3. Controlling Access to luciSince the initial release of Red Hat Enterprise Linux 6, the following features have been added to the page. As of Red Hat Enterprise Linux 6.2, the root user or a user who has been granted luci administrator permissions on a system running luci can control access to the various luci components by setting permissions for the individual users on a system. As of Red Hat Enterprise Linux 6.3, the root user or a user who has been granted luci administrator permissions can also use the luci interface to add users to the system. As of Red Hat Enterprise Linux 6.4, the root user or a user who has been granted luci administrator permissions can also use the luci interface to delete users from the system.
To add users, delete users, or set the user permissions, log in to luci as root or as a user who has previously been granted administrator permissions and click the selection in the upper right corner of the luci screen. This brings up the page, which displays the existing users. To delete users, select the user or users and click on Delete Selected. To add a user, click on Add a User and enter the name of the user to add. To set or change permissions for a user, select the user from the dropdown menu under . This allows you to set the following permissions: - Luci Administrator
Grants the user the same permissions as the root user, with full permissions on all clusters and the ability to set or remove permissions on all other users except root, whose permissions cannot be restricted. - Can Create Clusters
- Can Import Existing Clusters
For each cluster that has been created or imported to luci, you can set the following permissions for the indicated user: - Can View This Cluster
Allows the user to view the specified cluster. - Can Change the Cluster Configuration
Allows the user to modify the configuration for the specified cluster, with the exception of adding and removing cluster nodes. - Can Enable, Disable, Relocate, and Migrate Service Groups
- Can Stop, Start, and Reboot Cluster Nodes
- Can Add and Delete Nodes
- Can Remove This Cluster from Luci
Click Submit for the permissions to take affect, or click Reset to return to the initial values. Creating a cluster with luci consists of naming a cluster, adding cluster nodes to the cluster, entering the ricci passwords for each node, and submitting the request to create a cluster. If the node information and passwords are correct, Conga automatically installs software into the cluster nodes (if the appropriate software packages are not currently installed) and starts the cluster. Create a cluster as follows:
Enter the following parameters on the dialog box, as necessary: At the text box, enter a cluster name. The cluster name cannot exceed 15 characters. If each node in the cluster has the same ricci password, you can check to autofill the field as you add nodes. Enter the node name for a node in the cluster in the column and enter the ricci password for the node in the column. If your system is configured with a dedicated private network that is used only for cluster traffic, you may want to configure luci to communicate with ricci on an address that is different from the address to which the cluster node name resolves. You can do this by entering that address as the . If you are using a different port for the ricci agent than the default of 11111, you can change that parameter. Click on and enter the node name and ricci password for each additional node in the cluster. If you do not want to upgrade the cluster software packages that are already installed on the nodes when you create the cluster, leave the option selected. If you want to upgrade all cluster software packages, select the option. Whether you select the or the option, if any of the base cluster components are missing (cman, rgmanager, modcluster and all their dependencies), they will be installed. If they cannot be installed, the node creation will fail. Select if desired. Select if clustered storage is required; this downloads the packages that support clustered storage and enables clustered LVM. You should select this only when you have access to the Resilient Storage Add-On or the Scalable File System Add-On.
Click Create Cluster. Clicking Create Cluster causes the following actions: If you have selected , the cluster software packages are downloaded onto the nodes. Cluster software is installed onto the nodes (or it is verified that the appropriate software packages are installed). The cluster configuration file is updated and propagated to each node in the cluster. The added nodes join the cluster.
A message is displayed indicating that the cluster is being created. When the cluster is ready, the display shows the status of the newly created cluster, as shown in Figure 3.4, "Cluster node display". Note that if ricci is not running on any of the nodes, the cluster creation will fail.
After clicking Create Cluster to create the cluster, you can add or delete nodes from the cluster by clicking the or function from the menu at the top of the cluster node display page. Unless you are deleting an entire cluster, nodes must be stopped before being deleted. For information on deleting a node from an existing cluster that is currently in operation, see Section 4.3.4, "Deleting a Member from a Cluster". Removing a cluster node from the cluster is a destructive operation that cannot be undone.
3.5. Global Cluster PropertiesWhen you select a cluster to configure, a cluster-specific page is displayed. The page provides an interface for configuring cluster-wide properties. You can configure cluster-wide properties by clicking on along the top of the cluster display. This yields a tabbed interface which provides the following tabs: , , , , and . To configure the parameters in those tabs, follow the steps in the following sections. If you do not need to configure parameters in a tab, skip the section for that tab. 3.5.1. Configuring General PropertiesClicking on the tab displays the page, which provides an interface for modifying the configuration version. The text box displays the cluster name; it does not accept a cluster name change. The only way to change the name of a cluster is to create a new cluster configuration with the new name. The value is set to 1 at the time of cluster creation and is automatically incremented each time you modify your cluster configuration. However, if you need to set it to another value, you can specify it at the text box.
If you have changed the value, click Apply for this change to take effect. 3.5.2. Configuring Fence Daemon PropertiesClicking on the tab displays the page, which provides an interface for configuring and . The values you configure for these parameters are general fencing properties for the cluster. To configure specific fence devices for the nodes of the cluster, use the menu item of the cluster display, as described in Section 3.6, "Configuring Fence Devices". The parameter is the number of seconds the fence daemon (fenced) waits before fencing a node (a member of the fence domain) after the node has failed. The default value is 0. Its value may be varied to suit cluster and network performance. The parameter is the number of seconds the fence daemon (fenced) waits before fencing a node after the node joins the fence domain. The default value is 6. A typical setting for is between 20 and 30 seconds, but can vary according to cluster and network performance.
Enter the values required and click Apply for changes to take effect. For more information about and , refer to the fenced(8) man page. 3.5.3. Network ConfigurationClicking on the tab displays the page, which provides an interface for configuring the network transport type. You can use this tab to select one of the following options: This is the default setting. With this option selected, the Red Hat High Availability Add-On software creates a multicast address based on the cluster ID. It generates the lower 16 bits of the address and appends them to the upper portion of the address according to whether the IP protocol is IPv4 or IPv6: For IPv4 - The address formed is 239.192. plus the lower 16 bits generated by Red Hat High Availability Add-On software. For IPv6 - The address formed is FF15:: plus the lower 16 bits generated by Red Hat High Availability Add-On software.
The cluster ID is a unique identifier that cman generates for each cluster. To view the cluster ID, run the cman_tool status command on a cluster node. If you need to use a specific multicast address, select this option enter a multicast address into the text box. If you do specify a multicast address, you should use the 239.192.x.x series (or FF15:: for IPv6) that cman uses. Otherwise, using a multicast address outside that range may cause unpredictable results. For example, using 224.0.0.x (which is "All hosts on the network") may not be routed correctly, or even routed at all by some hardware. If you specify a multicast address, make sure that you check the configuration of routers that cluster packets pass through. Some routers may take a long time to learn addresses, seriously impacting cluster performance. As of the Red Hat Enterprise Linux 6.2 release, the nodes in a cluster can communicate with each other using the UDP Unicast transport mechanism. It is recommended, however, that you use IP multicasting for the cluster network. UDP Unicast is an alternative that can be used when IP multicasting is not available. For GFS2 deployments using UDP Unicast is not recommended.
Click Apply. When changing the transport type, a cluster restart is necessary for the changes to take effect. 3.5.4. Configuring Redundant Ring ProtocolAs of Red Hat Enterprise Linux 6.4, the Red Hat High Availability Add-On supports the configuration of redundant ring protocol. When using redundant ring protocol, there are a variety of considerations you must take into account, as described in Section 7.6, "Configuring Redundant Ring Protocol". Clicking on the tab displays the page. This page displays all of the nodes that are currently configured for the cluster. If you are configuring a system to use redundant ring protocol, you must specify the for each node for the second ring. The page optionally allows you to specify the , the , and the for the second ring. If you specify a multicast address for the second ring, either the alternate multicast address or the alternate port must be different from the multicast address for the first ring. If you specify an alternate port, the port numbers of the first ring and the second ring must differ by at least two, since the system itself uses port and port-1 to perform operations. If you do not specify an alternate multicast address, the system will automatically use a different multicast address for the second ring. 3.5.5. Quorum Disk ConfigurationClicking on the tab displays the page, which provides an interface for configuring quorum disk parameters to configure if you need to use a quorum disk. Quorum disk parameters and heuristics depend on the site environment and the special requirements needed. To understand the use of quorum disk parameters and heuristics, refer to the qdisk(5) man page. If you require assistance understanding and using quorum disk, contact an authorized Red Hat support representative. The parameter is enabled by default. If you need to use a quorum disk, click , enter quorum disk parameters, click Apply, and restart the cluster for the changes to take effect. Table 3.1. Quorum-Disk Parameters | Parameter | Description |
|---|
| Specifies the quorum disk label created by the mkqdisk utility. If this field is used, the quorum daemon reads the /proc/partitions file and checks for qdisk signatures on every block device found, comparing the label against the specified label. This is useful in configurations where the quorum device name differs among nodes. | | - The program used to determine if this heuristic is available. This can be anything that can be executed by /bin/sh -c. A return value of 0 indicates success; anything else indicates failure. This field is required. | | - The frequency (in seconds) at which the heuristic is polled. The default interval for every heuristic is 2 seconds. | | - The weight of this heuristic. Be careful when determining scores for heuristics. The default score for each heuristic is 1. | | - The number of consecutive failures required before this heuristic is declared unavailable. |
| | The minimum score for a node to be considered "alive". If omitted or set to 0, the default function, floor((n+1)/2), is used, where n is the sum of the heuristics scores. The value must never exceed the sum of the heuristic scores; otherwise, the quorum disk cannot be available. |
Clicking on the tab propagates changes to the cluster configuration file ( /etc/cluster/cluster.conf) in each cluster node. However, for the quorum disk to operate or for any modifications you have made to the quorum disk parameters to take effect, you must restart the cluster (refer to Section 4.4, "Starting, Stopping, Restarting, and Deleting Clusters"), ensuring that you have restarted the qdiskd daemon on each node. 3.5.6. Logging ConfigurationClicking on the tab displays the page, which provides an interface for configuring logging settings. You can configure the following settings for global logging configuration: Checking enables debugging messages in the log file. Checking enables messages to syslog. You can select the and the . The setting indicates that messages at the selected level and higher are sent to syslog. Checking enables messages to the log file. You can specify the name. The setting indicates that messages at the selected level and higher are written to the log file.
You can override the global logging settings for specific daemons by selecting one of the daemons listed beneath the heading at the bottom of the page. After selecting the daemon, you can check whether to log the debugging messages for that particular daemon. You can also specify the syslog and log file settings for that daemon. Click Apply for the logging configuration changes you have specified to take effect. 3.6. Configuring Fence DevicesConfiguring fence devices consists of creating, updating, and deleting fence devices for the cluster. You must configure the fence devices in a cluster before you can configure fencing for the nodes in the cluster. Creating a fence device consists of selecting a fence device type and entering parameters for that fence device (for example, name, IP address, login, and password). Updating a fence device consists of selecting an existing fence device and changing parameters for that fence device. Deleting a fence device consists of selecting an existing fence device and deleting it. This section provides procedures for the following tasks: From the cluster-specific page, you can configure fence devices for that cluster by clicking on along the top of the cluster display. This displays the fence devices for the cluster and displays the menu items for fence device configuration: and . This is the starting point of each procedure described in the following sections. If this is an initial cluster configuration, no fence devices have been created, and therefore none are displayed. 3.6.1. Creating a Fence DeviceTo create a fence device, follow these steps: From the configuration page, click . Clicking displays the Add Fence Device (Instance) dialog box. From this dialog box, select the type of fence device to configure. Click Submit.
After the fence device has been added, it appears on the configuration page. 3.6.2. Modifying a Fence DeviceTo modify a fence device, follow these steps: From the configuration page, click on the name of the fence device to modify. This displays the dialog box for that fence device, with the values that have been configured for the device. Click Apply and wait for the configuration to be updated.
3.6.3. Deleting a Fence DeviceFence devices that are in use cannot be deleted. To delete a fence device that a node is currently using, first update the node fence configuration for any node using the device and then delete the device. To delete a fence device, follow these steps: From the configuration page, check the box to the left of the fence device or devices to select the devices to delete. Click Delete and wait for the configuration to be updated. A message appears indicating which devices are being deleted.
When the configuration has been updated, the deleted fence device no longer appears in the display. 3.7. Configuring Fencing for Cluster MembersOnce you have completed the initial steps of creating a cluster and creating fence devices, you need to configure fencing for the cluster nodes. To configure fencing for the nodes after creating a new cluster and configuring the fencing devices for the cluster, follow the steps in this section. Note that you must configure fencing for each node in the cluster. The following sections provide procedures for configuring a single fence device for a node, configuring a node with a backup fence device, and configuring a node with redundant power supplies: 3.7.1. Configuring a Single Fence Device for a NodeUse the following procedure to configure a node with a single fence device. From the cluster-specific page, you can configure fencing for the nodes in the cluster by clicking on along the top of the cluster display. This displays the nodes that constitute the cluster. This is also the default page that appears when you click on the cluster name beneath from the menu on the left side of the luci page. Click on a node name. Clicking a link for a node causes a page to be displayed for that link showing how that node is configured. The node-specific page displays any services that are currently running on the node, as well as any failover domains of which this node is a member. You can modify an existing failover domain by clicking on its name. For information on configuring failover domains, see Section 3.8, "Configuring a Failover Domain". On the node-specific page, under , click Add Fence Method. This displays the Add Fence Method to Node dialog box. Enter a for the fencing method that you are configuring for this node. This is an arbitrary name that will be used by Red Hat High Availability Add-On; it is not the same as the DNS name for the device. Click Submit. This displays the node-specific screen that now displays the method you have just added under . Configure a fence instance for this method by clicking the Add Fence Instance button that appears beneath the fence method. This displays the drop-down menu from which you can select a fence device you have previously configured, as described in Section 3.6.1, "Creating a Fence Device". Select a fence device for this method. If this fence device requires that you configure node-specific parameters, the display shows the parameters to configure. For information on fencing parameters, refer to Appendix A, Fence Device Parameters. For non-power fence methods (that is, SAN/storage fencing), is selected by default on the node-specific parameters display. This ensures that a fenced node's access to storage is not re-enabled until the node has been rebooted. For information on unfencing a node, refer to the fence_node(8) man page. Click Submit. This returns you to the node-specific screen with the fence method and fence instance displayed.
3.7.2. Configuring a Backup Fence DeviceYou can define multiple fencing methods for a node. If fencing fails using the first method, the system will attempt to fence the node using the second method, followed by any additional methods you have configured. Use the following procedure to configure a backup fence device for a node. Beneath the display of the primary method you defined, click Add Fence Method. Enter a name for the backup fencing method that you are configuring for this node and click Submit. This displays the node-specific screen that now displays the method you have just added, below the primary fence method. Configure a fence instance for this method by clicking Add Fence Instance. This displays a drop-down menu from which you can select a fence device you have previously configured, as described in Section 3.6.1, "Creating a Fence Device". Select a fence device for this method. If this fence device requires that you configure node-specific parameters, the display shows the parameters to configure. For information on fencing parameters, refer to Appendix A, Fence Device Parameters. Click Submit. This returns you to the node-specific screen with the fence method and fence instance displayed. You can continue to add fencing methods as needed. You can rearrange the order of fencing methods that will be used for this node by clicking on and . 3.7.3. Configuring a Node with Redundant PowerIf your cluster is configured with redundant power supplies for your nodes, you must be sure to configure fencing so that your nodes fully shut down when they need to be fenced. If you configure each power supply as a separate fence method, each power supply will be fenced separately; the second power supply will allow the system to continue running when the first power supply is fenced and the system will not be fenced at all. To configure a system with dual power supplies, you must configure your fence devices so that both power supplies are shut off and the system is taken completely down. When configuring your system using Conga, this requires that you configure two instances within a single fencing method. To configure fencing for a node with dual power supplies, follow the steps in this section. Before you can configure fencing for a node with redundant power, you must configure each of the power switches as a fence device for the cluster. For information on configuring fence devices, see Section 3.6, "Configuring Fence Devices". From the cluster-specific page, click on along the top of the cluster display. This displays the nodes that constitute the cluster. This is also the default page that appears when you click on the cluster name beneath from the menu on the left side of the luci page. Click on a node name. Clicking a link for a node causes a page to be displayed for that link showing how that node is configured. On the node-specific page, click Add Fence Method. Enter a name for the fencing method that you are configuring for this node. Click Submit. This displays the node-specific screen that now displays the method you have just added under . Configure the first power supply as a fence instance for this method by clicking Add Fence Instance. This displays a drop-down menu from which you can select one of the power fencing devices you have previously configured, as described in Section 3.6.1, "Creating a Fence Device". Select one of the power fence devices for this method and enter the appropriate parameters for this device. Click Submit. This returns you to the node-specific screen with the fence method and fence instance displayed. Under the same fence method for which you have configured the first power fencing device, click Add Fence Instance. This displays a drop-down menu from which you can select the second power fencing devices you have previously configured, as described in Section 3.6.1, "Creating a Fence Device". Select the second of the power fence devices for this method and enter the appropriate parameters for this device. Click Submit. This returns you to the node-specific screen with the fence methods and fence instances displayed, showing that each device will power the system off in sequence and power the system on in sequence. This is shown in Figure 3.6, "Dual-Power Fencing Configuration".
3.8. Configuring a Failover DomainA failover domain is a named subset of cluster nodes that are eligible to run a cluster service in the event of a node failure. A failover domain can have the following characteristics: Unrestricted - Allows you to specify that a subset of members are preferred, but that a cluster service assigned to this domain can run on any available member. Restricted - Allows you to restrict the members that can run a particular cluster service. If none of the members in a restricted failover domain are available, the cluster service cannot be started (either manually or by the cluster software). Unordered - When a cluster service is assigned to an unordered failover domain, the member on which the cluster service runs is chosen from the available failover domain members with no priority ordering. Ordered - Allows you to specify a preference order among the members of a failover domain. The member at the top of the list is the most preferred, followed by the second member in the list, and so on. Failback - Allows you to specify whether a service in the failover domain should fail back to the node that it was originally running on before that node failed. Configuring this characteristic is useful in circumstances where a node repeatedly fails and is part of an ordered failover domain. In that circumstance, if a node is the preferred node in a failover domain, it is possible for a service to fail over and fail back repeatedly between the preferred node and another node, causing severe impact on performance. The failback characteristic is applicable only if ordered failover is configured.
Changing a failover domain configuration has no effect on currently running services. Failover domains are not required for operation. By default, failover domains are unrestricted and unordered. In a cluster with several members, using a restricted failover domain can minimize the work to set up the cluster to run a cluster service (such as httpd), which requires you to set up the configuration identically on all members that run the cluster service. Instead of setting up the entire cluster to run the cluster service, you can set up only the members in the restricted failover domain that you associate with the cluster service. To configure a preferred member, you can create an unrestricted failover domain comprising only one cluster member. Doing that causes a cluster service to run on that cluster member primarily (the preferred member), but allows the cluster service to fail over to any of the other members. The following sections describe adding, modifying, and deleting a failover domain: 3.8.1. Adding a Failover DomainTo add a failover domain, follow the steps in this section. From the cluster-specific page, you can configure failover domains for that cluster by clicking on along the top of the cluster display. This displays the failover domains that have been configured for this cluster.
In the Add Failover Domain to Cluster dialog box, specify a failover domain name at the text box. The name should be descriptive enough to distinguish its purpose relative to other names used in your cluster. To enable setting failover priority of the members in the failover domain, click the checkbox. With checked, you can set the priority value, , for each node selected as members of the failover domain. To restrict failover to members in this failover domain, click the checkbox. With checked, services assigned to this failover domain fail over only to nodes in this failover domain. To specify that a node does not fail back in this failover domain, click the checkbox. With checked, if a service fails over from a preferred node, the service does not fail back to the original node once it has recovered. Configure members for this failover domain. Click the checkbox for each node that is to be a member of the failover domain. If is checked, set the priority in the text box for each member of the failover domain. Click Create. This displays the Failover Domains page with the newly-created failover domain displayed. A message indicates that the new domain is being created. Refresh the page for an updated status.
3.8.2. Modifying a Failover DomainTo modify a failover domain, follow the steps in this section. From the cluster-specific page, you can configure Failover Domains for that cluster by clicking on along the top of the cluster display. This displays the failover domains that have been configured for this cluster. Click on the name of a failover domain. This displays the configuration page for that failover domain. To modify the , , or properties for the failover domain, click or unclick the checkbox next to the property and click Update Properties. To modify the failover domain membership, click or unclick the checkbox next to the cluster member. If the failover domain is prioritized, you can also modify the priority setting for the cluster member. Click Update Settings.
3.8.3. Deleting a Failover DomainTo delete a failover domain, follow the steps in this section. From the cluster-specific page, you can configure Failover Domains for that cluster by clicking on along the top of the cluster display. This displays the failover domains that have been configured for this cluster. Select the checkbox for the failover domain to delete. Click on .
3.9. Configuring Global Cluster ResourcesYou can configure global resources that can be used by any service running in the cluster, and you can configure resources that are available only to a specific service. From the cluster-specific page, you can add resources to that cluster by clicking on along the top of the cluster display. This displays the resources that have been configured for that cluster. Click . This displays the drop-down menu. Click the drop-down box under and select the type of resource to configure. Click Submit. Clicking Submit returns to the resources page that displays the display of Resources, which displays the added resource (and other resources).
To modify an existing resource, perform the following steps. From the luci page, click on the name of the resource to modify. This displays the parameters for that resource. Edit the resource parameters. Click Apply.
To delete an existing resource, perform the following steps. From the luci page, click the checkbox for any resources to delete. Click .
3.10. Adding a Cluster Service to the ClusterTo add a cluster service to the cluster, follow the steps in this section. From the cluster-specific page, you can add services to that cluster by clicking on along the top of the cluster display. This displays the services that have been configured for that cluster. (From the page, you can also start, restart, and disable a service, as described in Section 4.5, "Managing High-Availability Services".) Click . This displays the dialog box. On the Add Service Group to Cluster dialog box, at the text box, type the name of the service. Use a descriptive name that clearly distinguishes the service from other services in the cluster. Check the checkbox if you want the service to start automatically when a cluster is started and running. If the checkbox is not checked, the service must be started manually any time the cluster comes up from the stopped state. Check the checkbox to set a policy wherein the service only runs on nodes that have no other services running on them. If you have configured failover domains for the cluster, you can use the drop-down menu of the parameter to select a failover domain for this service. For information on configuring failover domains, see Section 3.8, "Configuring a Failover Domain". Use the drop-down box to select a recovery policy for the service. The options are to , , , or the service. Selecting the option indicates that the system should attempt to restart the failed service before relocating the service. Selecting the option indicates that the system should try to restart the service in a different node. Selecting the option indicates that the system should disable the resource group if any component fails. Selecting the option indicates that the system should attempt to restart the service in place if it fails, but if restarting the service fails the service will be disabled instead of being moved to another host in the cluster. If you select or as the recovery policy for the service, you can specify the maximum number of restart failures before relocating or disabling the service, and you can specify the length of time in seconds after which to forget a restart. To add a resource to the service, click Add Resource. Clicking Add Resource causes the display of the Add Resource To Service drop-down box that allows you to add an existing global resource or to add a new resource that is available only to this service. To add an existing global resource, click on the name of the existing resource from the Add Resource To Service drop-down box. This displays the resource and its parameters on the page for the service you are configuring. For information on adding or modifying global resources, see Section 3.9, "Configuring Global Cluster Resources"). To add a new resource that is available only to this service, select the type of resource to configure from the Add Resource To Service drop-down box and enter the resource parameters for the resource you are adding. Appendix B, HA Resource Parameters describes resource parameters. When adding a resource to a service, whether it is an existing global resource or a resource available only to this service, you can specify whether the resource is an or a . If you specify that a resource is an independent subtree, then if that resource fails only that resource is restarted (rather than the entire service) before the system attempting normal recovery. You can specify the maximum number of restarts to attempt for that resource on a node before implementing the recovery policy for the service. You can also specify the length of time in seconds after which the system will implement the recovery policy for the service. If you specify that the resource is a non-critical resource, then if that resource fails only that resource is restarted, and if the resource continues to fail then only that resource is disabled, rather than the entire service. You can specify the maximum number of restarts to attempt for that resource on a node before disabling that resource. You can also specify the length of time in seconds after which the system will disable that resource.
If you want to add child resources to the resource you are defining, click Add Child Resource. Clicking Add Child Resource causes the display of the drop-down box, from which you can add an existing global resource or add a new resource that is available only to this service. You can continue adding children resources to the resource to suit your requirements. If you are adding a Samba-service resource, add it directly to the service, not as a child of another resource. When you have completed adding resources to the service, and have completed adding children resources to resources, click Submit. Clicking Submit returns to the page displaying the added service (and other services).
To verify the existence of the IP service resource used in a cluster service, you can use the /sbin/ip addr show command on a cluster node (rather than the obsoleted ifconfig command). The following output shows the /sbin/ip addr show command executed on a node running a cluster service: 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP> mtu 1356 qdisc pfifo_fast qlen 1000 link/ether 00:05:5d:9a:d8:91 brd ff:ff:ff:ff:ff:ff inet 10.11.4.31/22 brd 10.11.7.255 scope global eth0 inet6 fe80::205:5dff:fe9a:d891/64 scope link inet 10.11.4.240/22 scope global secondary eth0 valid_lft forever preferred_lft forever To modify an existing service, perform the following steps. From the dialog box, click on the name of the service to modify. This displays the parameters and resources that have been configured for that service. Edit the service parameters. Click Submit.
To delete one or more existing services, perform the following steps. From the luci page, click the checkbox for any services to delete. Click . As of Red Hat Enterprise Linux 6.3, before luci deletes any services a message appears asking you to confirm that you intend to delete the service groups or groups, which stops the resources that comprise it. Click to close the dialog box without deleting any services, or click to remove the selected service or services.
|
| |
