5.8. Adding a Cluster Service to the Cluster


To add a cluster service to the cluster, follow these steps:
  1. At the left frame, click Services.
  2. At the bottom of the right frame (labeled Properties), click the Create a Service button. Clicking Create a Service causes the Add a Service dialog box to be displayed.
  3. At the Add a Service dialog box, type the name of the service in the Name text box and click OK. Clicking OK causes the Service Management dialog box to be displayed (refer to Figure 5.9, “Adding a Cluster Service”).

    Note

    Use a descriptive name that clearly distinguishes the service from other services in the cluster.
    Adding a Cluster Service

    Figure 5.9. Adding a Cluster Service

  4. If you want to restrict the members on which this cluster service is able to run, choose a failover domain from the Failover Domain drop-down box. (Refer to Section 5.6, “Configuring a Failover Domain” for instructions on how to configure a failover domain.)
  5. Autostart This Service checkbox — This is checked by default. If Autostart This Service is checked, the service is started automatically when a cluster is started and running. If Autostart This Service is not checked, the service must be started manually any time the cluster comes up from stopped state.
  6. Run Exclusive checkbox — This sets a policy wherein the service only runs on nodes that have no other services running on them. For example, for a very busy web server that is clustered for high availability, it would would be advisable to keep that service on a node alone with no other services competing for his resources — that is, Run Exclusive checked. On the other hand, services that consume few resources (like NFS and Samba), can run together on the same node without little concern over contention for resources. For those types of services you can leave the Run Exclusive unchecked.

    Note

    Circumstances that require enabling Run Exclusive are rare. Enabling Run Exclusive can render a service offline if the node it is running on fails and no other nodes are empty.
  7. Select a recovery policy to specify how the resource manager should recover from a service failure. At the upper right of the Service Management dialog box, there are three Recovery Policy options available:
    • Restart — Restart the service in the node the service is currently located. The default setting is Restart. If the service cannot be restarted in the current node, the service is relocated.
    • Relocate — Relocate the service before restarting. Do not restart the node where the service is currently located.
    • Disable — Do not restart the service at all.
  8. Click the Add a Shared Resource to this service button and choose the a resource listed that you have configured in Section 5.7, “Adding Cluster Resources”.

    Note

    If you are adding a Samba-service resource, connect a Samba-service resource directly to the service, not to a resource within a service. That is, at the Service Management dialog box, use either Create a new resource for this service or Add a Shared Resource to this service; do not use Attach a new Private Resource to the Selection or Attach a Shared Resource to the selection.
  9. If needed, you may also create a private resource that you can create that becomes a subordinate resource by clicking on the Attach a new Private Resource to the Selection button. The process is the same as creating a shared resource described in Section 5.7, “Adding Cluster Resources”. The private resource will appear as a child to the shared resource to which you associated with the shared resource. Click the triangle icon next to the shared resource to display any private resources associated.
  10. When finished, click OK.
  11. Choose File => Save to save the changes to the cluster configuration.

Note

To verify the existence of the IP service resource used in a cluster service, you must use the /sbin/ip addr list command on a cluster node. The following output shows the /sbin/ip addr list 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 forever
2: 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

5.8.1. Relocating a Service in a Cluster

Service relocation functionality allows you to perform maintenance on a cluster member while maintaining application and data availability.
To relocate a service, drag the service icon from the Services Tab onto the member icon in the Members tab. The cluster manager stops the service on the member on which it was running and restarts it on the new member.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.