This chapter describes how to use the Sun Cluster maintenance commands to manage resources, resource groups, and resource types within the cluster. To determine if you can use other tools to complete a procedure, see Tools for Data Service Resource Administration.
For overview information about resource types, resource groups, and resources, see Chapter 1, Planning for Sun Cluster Data Services and Sun Cluster Concepts Guide for Solaris OS.
This chapter contains the following sections.
Suspending and Resuming the Automatic Recovery Actions of Resource Groups
Disabling Resources and Moving Their Resource Group Into the UNMANAGED State
Displaying Resource Type, Resource Group, and Resource Configuration Information
Changing Resource Type, Resource Group, and Resource Properties
Reregistering Preregistered Resource Types After Inadvertent Deletion
Migrating the Application From a Global-Cluster Voting Node to a Global-Cluster Non-Voting Node
Synchronizing the Startups Between Resource Groups and Device Groups
Configuring an HAStoragePlus Resource for Cluster File Systems
Modifying Online the Resource for a Highly Available File System
Changing the Cluster File System to a Local File System in an HAStoragePlus Resource
Replicating and Upgrading Configuration Data for Resource Groups, Resource Types, and Resources
The following table summarizes the tasks for installing and configuring Sun Cluster data services. The table also provides cross-references to detailed instructions for performing the tasks.
Table 2–1 Tasks for Administering Data Service Resources
The procedures in this chapter describe how to use the Sun Cluster maintenance commands to complete these tasks. Other tools also enable you to administer your resources. See Tools for Data Service Resource Administration for details about these options.
Configuring a Sun Cluster data service involves the following tasks.
Registering a resource type
Upgrading a resource type
Creating resource groups
Adding resources to resource groups
Bringing online resources
Use the procedures in this chapter to update your data service configuration after the initial configuration. For example, to change resource type, resource group, and resource properties, go to Changing Resource Type, Resource Group, and Resource Properties.
A resource type provides specification of common properties and callback methods that apply to all of the resources of the given type. You must register a resource type before you create a resource of that type. For details about resource types, see Chapter 1, Planning for Sun Cluster Data Services.
An administrator can register a resource type for a zone cluster by specifying a resource type registration (RTR) file that resides inside the zone cluster. In other words, the file must be under the zone root path. The RTR file inside the zone cluster cannot have the Global_zone property set to TRUE. The RTR file inside the zone cluster cannot be of type RTR_LOGICAL_HOSTNAME or RTR_SHARED_ADDRESS.
The administrator can also register a resource type for a zone cluster from the location /usr/cluster/lib/rgm/rtreg. The administrator in the zone cluster cannot modify any RTR files in this directory. This enables registering system resource types for a zone cluster, even when the RTR file has one of the properties that cannot be set directly from the zone cluster. This process provides a secure way of delivering system resource types.
The resource types in the /usr/cluster/lib/rgm/rtreg directory are for the exclusive use of the global cluster.
Perform this procedure from any cluster node.
Ensure that you have the name for the resource type that you plan to register. The resource type name is an abbreviation for the data service name. For information about resource type names of data services that are supplied with Sun Cluster, see the release notes for your release of Sun Cluster.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Register the resource type.
# clresourcetype register resource-type |
Specifies name of the resource type to add. See the release notes for your release of Sun Cluster to determine the predefined name to supply.
Verify that the resource type has been registered.
# clresourcetype show |
The following example registers the SUNW.krb5 resource type, which represents the Sun Java System Web Server application in a Sun Cluster configuration.
# clresourcetype register SUNW.krb5 # clresourcetype show SUNW.krb5 Resource Type: SUNW.krb5 RT_description: HA-Kerberos KDC server for Sun Cluster RT_version: 3.2 API_version: 6 RT_basedir: /opt/SUNWsckrb5/bin Single_instance: False Proxy: False Init_nodes: All potential masters Installed_nodes: <All> Failover: True Pkglist: SUNWsckrb5 RT_system: False |
After registering resource types, you can create resource groups and add resources to the resource group. For details, see Creating a Resource Group.
The following man pages:
Upgrading a resource type enables you to use new features that are introduced in the new version of the resource type. A new version of a resource type might differ from a previous version in the following ways.
Default settings of resource type properties might change.
New extension properties of the resource type might be introduced.
Existing extension properties of the resource type might be withdrawn.
The set of standard properties that are declared for the resource type might change.
The attributes of resource properties such as min, max, arraymin, arraymax, default, and tunability might change.
The set of declared methods might differ.
The implementation of methods or the fault monitor might change.
Upgrading a resource type involves the tasks that are explained in the following sections:
The instructions that follow explain how to use the clresource(1CL) command to perform this task. However, you are not restricted to using the clresource command for this task. Instead of the clresource command, you can use SunPlex Manager or the Resource Group option of the clsetup(1CL) command to perform this task.
Consult the documentation for the resource type to determine what you must do before installing the upgrade package on a node. One action from the following list will be required:
You must reboot the node in noncluster mode.
You may leave the node running in cluster mode, but you must turn off monitoring of all instances of the resource type.
You may leave the node running in cluster mode and leave monitoring turned on for all instances of the resource type.
If you must reboot the node in noncluster mode, prevent a loss of service by performing a rolling upgrade. In a rolling upgrade, you install the package on each node individually while leaving the remaining nodes running in cluster mode.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Install the package for the resource type upgrade on all cluster nodes where instances of the resource type are to be brought online.
Register the new version of the resource type.
To ensure that the correct version of the resource type is registered, you must specify the following information:
The resource type name
The resource type registration (RTR) file that defines the resource type
# clresourcetype register -f path-to-new-rtr-file resource-type-name |
The format of the resource type name is as follows:
vendor-id.base-rt-name:rt-version
For an explanation of this format, see Format of Resource Type Names.
Display the newly registered resource type.
# clresourcetype show resource-type-name |
If necessary, set the Installed_nodes property to the nodes where the package for the resource type upgrade is installed.
You must perform this step if the package for the resource type upgrade is not installed on all cluster nodes.
The nodelist property of all resource groups that contain instances of the resource type must be a subset of the Installed_nodes property of the resource type.
# clresourcetype set -n installed-node-list resource-type |
Specifies the names of nodes on which this resource type is installed.
The instructions that follow explain how to use the clresource(1CL) command to perform this task. However, you are not restricted to using the clresource command for this task. Instead of the clresource command, you can use SunPlex Manager or the Resource Group option of the clsetup(1CL) command to perform this task.
Consult the instructions for upgrading the resource type to determine when you can migrate resources to a new version of the resource type.
Any time
Only when the resource is unmonitored
Only when the resource is offline
Only when the resource is disabled
Only when the resource group is unmanaged
The instructions might state that you cannot upgrade your existing version of the resource. If you cannot migrate the resource, consider the following alternatives:
Deleting the resource and replacing it with a new resource of the upgraded version
Leaving the resource at the old version of the resource type
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
For each resource of the resource type that is to be migrated, change the state of the resource or its resource group to the appropriate state.
If you can migrate the resource at any time, no action is required.
If you can migrate the resource only when the resource is unmonitored, type the following command:
# clresource unmonitor resource |
If you can migrate the resource only when the resource is offline, type the following command:
# clresource disable resource |
If other resources depend on the resource that you are migrating, this step fails. In this situation, consult the error message that is printed to determine the names of the dependent resources. Then repeat this step, specifying a comma-separated list that contains the resource that you are migrating and any dependent resources.
If you can migrate the resource only when the resource is disabled, type the following command:
# clresource disable resource |
If other resources depend on the resource that you are migrating, this step fails. In this situation, consult the error message that is printed to determine the names of the dependent resources. Then repeat this step, specifying a comma-separated list that contains the resource that you are migrating and any dependent resources.
If you can migrate the resource only when the resource group is unmanaged, type the following commands:
# clresource disable -g resource-group + # clresourcegroup offline resource-group # clresourcegroup unmanage resource-group |
The replaceable items in these commands are as follows:
Specifies the resource group that is to be unmanaged
For each resource of the resource type that is to be migrated, change the Type_version property to the new version.
If necessary, set other properties of the same resource to appropriate values in the same command. To set these properties, specify the -p option in the command.
To determine whether you are required to set other properties, consult the instructions for upgrading the resource type. You might be required to set other properties for the following reasons:
An extension property has been introduced in the new version of the resource type.
The default value of an existing property has been changed in the new version of the resource type.
# clresource set -p Type_version=new-version \ [-p extension-property=new-value] [-p standard-property=new-value] resource |
If the existing version of the resource type does not support upgrades to the new version, this step fails.
Restore the previous state of the resource or resource group by reversing the command that you typed in Step 2.
If you can migrate the resource at any time, no action is required.
After migrating a resource that can be migrated at any time, the resource probe might not display the correct resource type version. In this situation, disable and re-enable the resource's fault monitor to ensure that the resource probe displays the correct resource type version.
If you can migrate the resource only when the resource is unmonitored, type the following command:
# clresource monitor resource |
If you can migrate the resource only when the resource is offline, type the following command:
# clresource enable resource |
If you disabled in Step 2 other resources that depend on the resource that you are migrating, enable the dependent resources also.
If you can migrate the resource only when the resource is disabled, type the following command:
# clresource enable resource |
If you disabled in Step 2 other resources that depend on the resource that you are migrating, enable the dependent resources also.
If you can migrate the resource only when the resource group is unmanaged, type the following commands:
# clresource enable -g resource-group + # clresourcegroup manage resource-group # clresourcegroup online resource-group |
This example shows the migration of a resource that can be migrated only when the resource is offline. The new resource type package contains methods that are located in new paths. Because the methods are not overwritten during the installation, the resource does not need to be disabled until after the upgraded resource type is installed.
The characteristics of the resource in this example are as follows:
The new resource type version is 2.0.
The resource name is myresource.
The resource type name is myrt.
The new RTR file is in /opt/XYZmyrt/etc/XYZ.myrt.
No dependencies on the resource that is to be migrated exist.
The resource that is to be migrated can be taken offline while leaving the containing resource group online.
This example assumes that the upgrade package is already installed on all cluster nodes according to the supplier's directions.
# clresourcetype register -f /opt/XYZmyrt/etc/XYZ.myrt myrt # clresource disable myresource # clresource set -p Type_version=2.0 myresource # clresource enable myresource |
This example shows the migration of a resource that can be migrated only when the resource is unmonitored. The new resource type package contains only the monitor and RTR file. Because the monitor is overwritten during installation, monitoring of the resource must be disabled before the upgrade package is installed.
The characteristics of the resource in this example are as follows:
The new resource type version is 2.0.
The resource name is myresource.
The resource type name is myrt.
The new RTR file is in /opt/XYZmyrt/etc/XYZ.myrt.
The following operations are performed in this example.
Before the upgrade package is installed, the following command is run to disable monitoring of the resource:
# clresource unmonitor myresource |
The upgrade package is installed on all cluster nodes according to the supplier's directions.
To register the new version of the resource type, the following command is run:
# clresourcetype register -f /opt/XYZmyrt/etc/XYZ.myrt myrt |
To change the Type_version property to the new version, the following command is run:
# clresource set -p Type_version=2.0 myresource |
To enable monitoring of the resource after its migration, the following command is run:
# clresource monitor myresource |
You can downgrade a resource to an older version of its resource type. The conditions for downgrading a resource to an older version of the resource type are more restrictive than the conditions for upgrading to a newer version of the resource type. The resource group that contains the resource must be unmanaged.
The instructions that follow explain how to use the clresource(1CL) command to perform this task. However, you are not restricted to using the clresource command for this task. Instead of the clresource command, you can use SunPlex Manager or the Resource Group option of the clsetup(1CL) command to perform this task.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify and solaris.cluster.admin RBAC authorizations.
Switch offline the resource group that contains the resource that you are downgrading.
clresourcegroup offline resource-group |
Disable all resources in the resource group that contains the resource that you are downgrading.
clresource disable -g resource-group + |
Unmanage the resource group that contains the resource that you are downgrading.
clresourcegroup unmanage resource-group |
If necessary, reregister the old version of the resource type to which you are downgrading.
Perform this step only if the version to which you are downgrading is no longer registered. If the version to which you are downgrading is still registered, omit this step.
clresourcetype register resource-type-name |
For the resource that you are downgrading, set the Type_version property to old version to which you are downgrading.
If necessary, edit other properties of the same resource to appropriate values in the same command.
clresource set -p Type_version=old-version resource-todowngrade |
Enable all the resources that you disabled in Step 3.
# clresource enable -g resource-group + |
Bring to a managed state the resource group that contains the resource that you downgraded.
# clresourcegroup manage resource-group |
Bring online the resource group that contains the resource that you downgraded.
# clresourcegroup online resource-group |
A resource group contains a set of resources, all of which are brought online or offline together on a given node or set of nodes. You must create an empty resource group before you place resources into it. A resource group can be configured to run in global-cluster non-voting nodes.
The global-cluster non voting nodes that are specified in the resource group's node list do not need to exist when the resource group is created. If the node specified in the node list is not detected by the RGM, a warning message is displayed but does not result in an error.
The two resource group types are failover and scalable. A failover resource group can be online on one node only at any time, while a scalable resource group can be online on multiple nodes simultaneously.
The following procedures explain how to use the clresourcegroup(1CL) command to create a resource group.
For conceptual information about resource groups, see Chapter 1, Planning for Sun Cluster Data Services and Sun Cluster Concepts Guide for Solaris OS.
A failover resource group contains the following types of resources:
Network address resources, which are instances of the built-in resource types LogicalHostname and SharedAddress
Failover resources, which are the data service application resources for a failover data service
The network address resources and their dependent data service resources move between cluster nodes when data services fail over or are switched over.
Perform this procedure from any cluster node.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Create the failover resource group.
# clresourcegroup create [-n node-zone-list] resource-group |
Specifies a comma-separated, ordered list of nodes that can master this resource group. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource group is created on all nodes in the cluster.
To achieve highest availability, specify global-cluster non-voting nodes on different global-cluster voting nodes in a failover resource group's node list instead of different nodes on the same global-cluster voting node.
Specifies your choice of the name of the failover resource group to add. This name must begin with an ASCII character.
Verify that the resource group has been created.
# clresourcegroup show resource-group |
This example shows the creation of the failover resource group resource-group-1. The global cluster voting nodes phys-schost-1 and phys-schost-2 can master this resource group.
# clresourcegroup create -n phys-schost1,phys-schost-2 resource-group-1 # clresourcegroup show -v resource-group-1 === Resource Groups and Resources === Resource Group: resource-group1 RG_description: <NULL> RG_mode: Failover RG_state: Unmanaged RG_project_name: default RG_affinities: <NULL> RG_SLM_type: manual Auto_start_on_new_cluster: True Failback: False Nodelist: phys-schost-1 phys-schost-2 Maximum_primaries: 1 Desired_primaries: 1 RG_dependencies: <NULL> Implicit_network_dependencies: True Global_resources_used: <All> Pingpong_interval: 3600 Pathprefix: <NULL> RG_System: False Suspend_automatic_recovery: False |
After you create a failover resource group, you can add application resources to this resource group. See Tools for Adding Resources to Resource Groups for the procedure.
The clresourcegroup(1CL) man page.
A scalable resource group is used with scalable services. The shared address feature is the Sun Cluster networking facility that enables the multiple instances of a scalable service to appear as a single service. You must first create a failover resource group that contains the shared addresses on which the scalable resources depend. Next, create a scalable resource group, and add scalable resources to that group. The node list of a scalable resource group or of the shared address resource group must not contain more than one global-cluster non-voting node on the same node. Each instance of the scalable service must run on a different cluster node.
You can configure a scalable resource group to run in a global-cluster non-voting node as well. Do not configure a scalable resource to run in multiple global-cluster non-voting nodes on the same node.
Perform this procedure from any cluster node.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Create the failover resource group that holds the shared addresses that the scalable resource is to use.
Create the scalable resource group.
# clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\ -p RG_dependencies=depend-resource-group\ [-n node-zone-list] resource-group |
Specifies the maximum number of active primaries for this resource group.
Specifies the number of active primaries on which the resource group should attempt to start.
Identifies the resource group that contains the shared address resource on which the resource group that is being created depends.
Specifies a comma-separated, ordered list of nodes in which this resource group is to be available. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource group is created on all nodes in the cluster.
The node list of the scalable resource can contain the same list or a subset of nodename:zonename pairs as the node list of the shared address resource
Specifies your choice of the name of the scalable resource group to add. This name must begin with an ASCII character.
Verify that the scalable resource group has been created.
# clresourcegroup show resource-group |
This example shows the creation of the scalable resource group resource-group-1. This resource group is to be hosted in the global cluster of nodes phys-schost-1 and phys-schost-2. The scalable resource group depends on the failover resource group resource-group-2, which contains the shared address resources.
# clresourcegroup create\ -p Maximum_primaries=2\ -p Desired_primaries=2\ -p RG_dependencies=resource-group-2\ -n phys-schost-1, phys-schost-2\ resource-group-1 # clresourcegroup show resource-group-1 === Resource Groups and Resources === Resource Group: resource-group-1 RG_description: <NULL> RG_mode: Scalable RG_state: Unmanaged RG_project_name: default RG_affinities: <NULL> Auto_start_on_new_cluster: True Failback: False Nodelist: phys-schost-1 phys-schost-2 Maximum_primaries: 2 Desired_primaries: 2 RG_dependencies: resource-group2 Implicit_network_dependencies: True Global_resources_used: <All> Pingpong_interval: 3600 Pathprefix: <NULL> RG_System: False Suspend_automatic_recovery: False |
After you have created a scalable resource group, you can add scalable application resources to the resource group. See How to Add a Scalable Application Resource to a Resource Group for details.
The clresourcegroup(1CL) man page.
A resource is an instantiation of a resource type. You must add resources to a resource group before the RGM can manage the resources. This section describes the following three resource types.
Logical hostname resources
Shared-address resources
Data service (application) resources
Sun Cluster provides the following tools for adding resources to resource groups:
Sun Cluster Manager. For more information, see the Sun Cluster Manager online help.
The clsetup(1CL) utility.
Sun Cluster maintenance commands.
You can use the wizards in the Sun Cluster Manager, the clsetup utility, or the Sun cluster maintenance commands to add the logical hostname resources and shared-address resources to the resource group.
Sun Cluster Manager and the clsetup utility enable you to add resources to the resource group interactively. Configuring these resources interactively reduces the possibility for configuration errors that might result from command syntax errors or omissions. Sun Cluster Manager and the clsetup utility ensure that all required resources are created and that all required dependencies between resources are set.
Always add logical hostname resources and shared address resources to failover resource groups. Add data service resources for failover data services to failover resource groups. Failover resource groups contain both the logical hostname resources and the application resources for the data service. Scalable resource groups contain only the application resources for scalable services. The shared address resources on which the scalable service depends must reside in a separate failover resource group. You must specify dependencies between the scalable application resources and the shared address resources for the data service to scale across cluster nodes.
The DEPRECATED flag marks the logical hostname or shared address resource as a deprecated address. These addresses are not suitable for outbound requests since they can migrate to a different cluster node due to a failover or switchover.
For more information about resources, see Sun Cluster Concepts Guide for Solaris OS and Chapter 1, Planning for Sun Cluster Data Services.
The following instructions explain how to add a logical hostname resource to a resource group by using the clsetup utility. Perform this procedure from one node only.
This procedure provides the long forms of the Sun Cluster maintenance commands. Most commands also have short forms. Except for the forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix A, Sun Cluster Object-Oriented Commands.
Ensure that the following prerequisites are met:
An entry for each logical hostname that is to be made available by the resource is added to the name service database.
If you are using IP Networking Multipathing (IPMP) groups, the groups are configured on the nodes where the logical hostname resource can be brought online.
Any global-cluster non-voting node that can master the resource is already configured on your cluster nodes.
Ensure that you have the following information:
The hostnames that you plan to add to the resource group
Become superuser on any cluster node.
Start the clsetup utility.
# clsetup |
The clsetup main menu is displayed.
Type the number that corresponds to the option for data services and press Return.
The Data Services menu is displayed.
Type the number that corresponds to the option for configuring the Logical Hostname resource and press Return.
The clsetup utility displays the list of prerequisites for performing this task.
Verify that the prerequisites are met, and press Return to continue.
The clsetup utility displays a list of the cluster nodes where the logical hostname resource can be brought online.
Select the nodes where the logical hostname resource can be brought online.
To accept the default selection of all listed nodes in an arbitrary order, type a and press Return.
To select a subset of the listed nodes, type a comma-separated or space-separated list of the numbers that correspond to the nodes. Then press Return.
To select all nodes in a particular order, type a comma-separated or space-separated ordered list of the numbers that correspond to the nodes and press Return.
Ensure that the nodes are listed in the order in which the nodes are to appear in the logical hostname resource group's node list. The first node in the list is the primary node of this resource group.
To confirm your selection of nodes, type d and press Return.
The clsetup utility displays a screen where you can specify the logical hostname that the resource is to make available.
Type the logical hostname that this resource is to make available and press Return.
The clsetup utility displays the names of the Sun Cluster objects that the utility will create.
If you require a different name for any Sun Cluster object, change the name as follows.
Type the number that corresponds to the name that you are changing and press Return.
The clsetup utility displays a screen where you can specify the new name.
At the New Value prompt, type the new name and press Return.
The clsetup utility returns you to the list of the names of the Sun Cluster objects that the utility will create.
To confirm your selection of Sun Cluster object names, type d and press Return.
The clsetup utility displays information about the Sun Cluster configuration that the utility will create.
To create the configuration, type c and press Return.
The clsetup utility displays a progress message to indicate that the utility is running commands to create the configuration. When configuration is complete, the clsetup utility displays the commands that the utility ran to create the configuration.
(Optional) Type q and press Return repeatedly until you quit the clsetup utility.
If you prefer, you can leave the clsetup utility running while you perform other required tasks before using the utility again. If you choose to quit clsetup, the utility recognizes your existing logical hostname resource group when you restart the utility.
Verify that the logical hostname resource has been created.
Use the clresource(1CL) utility for this purpose. By default, the clsetup utility assigns the name node_name-rg to the resource group.
# clresource show node_name-rg |
When you add a logical hostname resource to a resource group, the extension properties of the resource are set to their default values. To specify a nondefault value, you must modify the resource after you add the resource to a resource group. For more information, see How to Modify a Logical Hostname Resource or a Shared Address Resource.
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the failover resource group to which you are adding the resource
The hostnames that you plan to add to the resource group
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Add the logical hostname resource to the resource group.
# clreslogicalhostname create -g resource-group -h hostnamelist, … [-N netiflist] resource |
Specifies the name of the resource group in which this resource resides.
Specifies a comma-separated list of UNIX hostnames (logical hostnames) by which clients communicate with services in the resource group. When a logical hostname resource is added to a resource group that runs in a global-cluster non-voting node, the corresponding IP addresses are configured in that node. These IP addresses are available only to applications that are running in that global-cluster non-voting node.
You must specify the fully qualified name with the -h option if you require a fully qualified hostname.
Specifies an optional, comma-separated list that identifies the IPMP groups that are on each node. Each element in netiflist must be in the form of netif@node. netif can be given as an IPMP group name, such as sc_ipmp0. The node can be identified by the node name or node ID, such as sc_ipmp0@1 or sc_ipmp@phys-schost-1
Sun Cluster does not support the use of the adapter name for netif.
Specifies an optional resource name of your choice. You cannot use the fully qualified name in the resource name.
Verify that the logical hostname resource has been added.
# clresource show resource |
This example shows the addition of logical hostname resource (resource-1) to a resource group (resource-group-1).
# clreslogicalhostname create -g resource-group-1 -h schost-1 resource-1 # clresource show resource-1 === Resources === Resource: resource-1 Type: SUNW.LogicalHostname:2 Type_version: 2 Group: resource-group-1 R_description: Resource_project_name: default Enabled{phats1}: True Enabled{phats2}: True Monitored{phats1}: True Monitored{phats2}: True |
This example shows the addition of the following logical host name resources to the resource group nfs-fo-rg:
A resource that is named cs23-rs, which identifies the IPMP group sc_ipmp0 on node 1 and node 2
A resource that is named cs24-rs, which identifies the IPMP group sc_ipmp1 on node 1 and node 2
# clreslogicalhostname create -g nfs-fo-rg -h cs23-rs -N sc_ipmp0@1,sc_ipmp0@2 cs23-rs # clreslogicalhostname create -g nfs-fo-rg -h cs24-rs -N sc_ipmp1@1,sc_ipmp1@2 cs24-rs |
After you add logical hostname resources, see How to Bring Online Resource Groups to bring the resources online.
Adding a resource causes the Sun Cluster software to validate the resource. If the validation fails, the clreslogicalhostname command prints an error message and exits. To determine why the validation failed, check the syslog on each node for an error message. The message appears on the node that performed the validation, not necessarily the node on which you ran the clreslogicalhostname command.
The clreslogicalhostname(1CL) man page.
The following instructions explain how to add a shared address resource to a resource group by using the clsetup utility. Perform this procedure from any cluster node.
This procedure provides the long forms of the Sun Cluster maintenance commands. Most commands also have short forms. Except for the forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix A, Sun Cluster Object-Oriented Commands.
Ensure that the following prerequisites are met:
The shared address that is to be made available by the resource has an entry in a name service database.
If you are using IP Networking Multipathing (IPMP) groups, the groups are configured on the nodes where the shared address resource can be brought online.
Any global-cluster non-voting node that can master the resource is already configured on your cluster nodes.
Ensure that you have the following information:
The hostnames that you plan to add to the resource group.
Become superuser on any cluster node.
Start the clsetup utility.
# clsetup |
The clsetup main menu is displayed.
Type the number that corresponds to the option for data services and press Return.
The Data Services menu is displayed.
Type the number that corresponds to the option for configuring the shared address resource and press Return.
The clsetup utility displays the list of prerequisites for performing this task.
Verify that the prerequisites are met, and press Return to continue.
The clsetup utility displays a list of the cluster nodes where the shared address resource can be brought online.
Select the nodes where the shared address resource can be brought online.
To accept the default selection of all listed nodes in an arbitrary order, type a and press Return.
To select a subset of the listed nodes, type a comma-separated or space-separated list of the numbers that correspond to the nodes. Then press Return.
To select all nodes in a particular order, type a comma-separated or space-separated ordered list of the numbers that correspond to the nodes and press Return.
To confirm your selection of nodes, type d and press Return.
The clsetup utility displays a screen where you can specify the shared address that the resource is to make available.
Type the shared address that this resource is to make available and press Return.
The clsetup utility displays the names of the Sun Cluster objects that the utility will create.
If you require a different name for any Sun Cluster object, change the name as follows.
Type the number that corresponds to the name that you are changing and press Return.
The clsetup utility displays a screen where you can specify the new name.
At the New Value prompt, type the new name and press Return.
The clsetup utility returns you to the list of the names of the Sun Cluster objects that the utility will create.
To confirm your selection of Sun Cluster object names, type d and press Return.
The clsetup utility displays information about the Sun Cluster configuration that the utility will create.
To create the configuration, type c and Press Return.
The clsetup utility displays a progress message to indicate that the utility is running commands to create the configuration. When configuration is complete, the clsetup utility displays the commands that the utility ran to create the configuration.
(Optional) Type q and press Return repeatedly until you quit the clsetup utility.
If you prefer, you can leave the clsetup utility running while you perform other required tasks before using the utility again. If you choose to quit clsetup, the utility recognizes your existing shared address resource group when you restart the utility.
Verify that the shared address resource has been created.
Use the clresource(1CL) utility for this purpose. By default, the clsetup utility assigns the name node_name-rg to the resource group.
# clresource show node_name-rg |
When you add a shared address resource to a resource group, the extension properties of the resource are set to their default values. To specify a nondefault value, you must modify the resource after you add the resource to a resource group. For more information, see How to Modify a Logical Hostname Resource or a Shared Address Resource.
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the resource group into which you are adding the resource. This group must be a failover resource group that you created previously.
The hostnames that you plan to add to the resource group.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Add the shared address resource to the resource group.
# clressharedaddress create -g resource-group -h hostnamelist, … \ [-X auxnodelist] [-N netiflist] resource |
Specifies the resource group name. In the node list of a shared address resource, do not specify more than one global-cluster non-voting node on the same global-cluster voting node. Specify the same list of nodename:zonename pairs as the node list of the scalable resource group.
Specifies a comma-separated list of shared address hostnames.
Specifies a comma-separated list of node names or IDs that identify the cluster nodes that can host the shared address but never serve as primary if failover occurs. These nodes are mutually exclusive, with the nodes identified as potential masters in the resource group's node list. If no auxiliary node list is explicitly specified, the list defaults to the list of all cluster node names that are not included in the node list of the resource group that contains the shared address resource.
To ensure that a scalable service runs in all global-cluster non-voting nodes that were created to master the service, the complete list of nodes must be included in the node list of the shared address resource group or the auxnodelist of the shared address resource. If all the nodes are listed in the node list, the auxnodelist can be omitted.
Specifies an optional, comma-separated list that identifies the IPMP groups that are on each node. Each element in netiflist must be in the form of netif@node. netif can be given as an IPMP group name, such as sc_ipmp0. The node can be identified by the node name or node ID, such as sc_ipmp0@1 or sc_ipmp@phys-schost-1.
Sun Cluster does not support the use of the adapter name for netif.
Specifies an optional resource name of your choice.
Verify that the shared address resource has been added and validated.
# clresource show resource |
This example shows the addition of a shared address resource (resource-1) to a resource group (resource-group-1).
# clressharedaddress create -g resource-group-1 -h schost-1 resource-1 # clresource show resource-1 === Resources === Resource: resource-1 Type: SUNW.SharedAddress:2 Type_version: 2 Group: resource-group-1 R_description: Resource_project_name: default Enabled{phats1}: False Enabled{phats2}: False Monitored{phats1}: True Monitored{phats2}: True |
After you add a shared address resource, use the procedure How to Bring Online Resource Groups to enable the resource.
Adding a resource causes the Sun Cluster software to validate the resource. If the validation fails, the clressharedaddress command prints an error message and exits. To determine why the validation failed, check the syslog on each node for an error message. The message appears on the node that performed the validation, not necessarily the node on which you ran the clressharedaddress command.
The clressharedaddress(1CL) man page.
A failover application resource is an application resource that uses logical hostnames that you previously created in a failover resource group.
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the failover resource group to which you are adding the resource
The name of the resource type for the resource
The logical hostname resources that the application resource uses, which are the logical hostnames that you previously included in the same resource group
This procedure also applies to proxy resources.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Add a failover application resource to the resource group.
# clresource create -g resource-group -t resource-type \ [-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource |
Specifies the name of a failover resource group. This resource group must already exist.
Specifies the name of the resource type for the resource.
Specifies a comma-separated list of extension properties that you are setting for the resource. The extension properties that you can set depend on the resource type. To determine which extension properties to set, see the documentation for the resource type.
node-specifier is an optional qualifier to the -p and -x options. This qualifier indicates that the extension property or properties on only the specified node or nodes are to be set when the resource is created. The specified extension properties on other nodes in the cluster are not set. If you do not include node-specifier, the specified extension properties on all nodes in the cluster are set. You can specify a node name or a node identifier for node-specifier. Examples of the syntax of node-specifier include the following:
-p "myprop{phys-schost-1}" |
The braces ({}) indicate that you are setting the specified extension property on only node phys-schost-1. For most shells, the double quotation marks (“) are required.
You can also use the following syntax to set an extension property in two different global-cluster voting nodes on two different nodes:
-x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}" |
The extension property that you specify with node-specifier must be declared in the RTR file as a per-node property. See Appendix B, Standard Properties for information about the Per_node resource property attribute.
Specifies a comma-separated list of standard properties that you are setting for the resource. The standard properties that you can set depend on the resource type. To determine which standard properties to set, see the documentation for the resource type and Appendix B, Standard Properties.
Specifies your choice of the name of the resource to add.
The resource is created in the enabled state.
Verify that the failover application resource has been added and validated.
# clresource show resource |
This example shows the addition of a resource (resource-1) to a resource group (resource-group-1). The resource depends on logical hostname resources (schost-1, schost-2), which must reside in the same failover resource groups that you defined previously.
# clresource create -g resource-group-1 -t resource-type-1 \ -p Network_resources_used=schost-1,schost2 resource-1\ # clresource show resource-1 === Resources === Resource: resource-1 Type: resource-type-1 Type_version: Group: resource-group-1 R_description: Resource_project_name: default Enabled{phats1}: False Enabled{phats2}: False Monitored{phats1}: True Monitored{phats2}: True |
After you add a failover application resource, use the procedure How to Bring Online Resource Groups to enable the resource.
Adding a resource causes the Sun Cluster software to validate the resource. If the validation fails, the clresource command prints an error message and exits. To determine why the validation failed, check the syslog on each node for an error message. The message appears on the node that performed the validation, not necessarily the node on which you ran the clresource command.
The clresource(1CL) man page.
A scalable application resource is an application resource that uses shared-address resources. The shared-address resources are in a failover resource group.
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the scalable resource group to which you are adding the resource
The name of the resource type for the resource
The shared address resources that the scalable service resource uses, which are the shared addresses that you previously included in a failover resource group
This procedure also applies to proxy resources.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Add a scalable application resource to the resource group.
# clresource create -g resource-group -t resource-type \ -p Network_resources_used=network-resource[,network-resource...] \ -p Scalable=True [-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource |
Specifies the name of a scalable service resource group that you previously created.
Specifies the name of the resource type for this resource.
Specifies the list of network resources (shared addresses) on which this resource depends.
Specifies that this resource is scalable.
Specifies a comma-separated list of extension properties that you are setting for the resource. The extension properties that you can set depend on the resource type. To determine which extension properties to set, see the documentation for the resource type.
node-specifier is an optional qualifier to the -p and -x options. This qualifier indicates that the extension property or properties on only the specified node or nodes are to be set when the resource is created. The specified extension properties on other nodes in the cluster are not set. If you do not include node-specifier, the specified extension properties on all nodes in the cluster are set. You can specify a node name or a node identifier for node-specifier. Examples of the syntax of node-specifier include the following:
-p "myprop{phys-schost-1}" |
The braces ({}) indicate that you are setting the specified extension property on only node phys-schost-1. For most shells, the double quotation marks (“) are required.
You can also use the following syntax to set an extension property in two different global-cluster voting nodes on two different nodes:
-x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}" |
The extension property that you specify with node-specifier must be declared in the RTR file as a per-node property. See Appendix B, Standard Properties for information about the Per_node resource property attribute.
Specifies a comma-separated list of standard properties that you are setting for the resource. The standard properties that you can set depend on the resource type. For scalable services, you typically set the Port_list, Load_balancing_weights, and Load_balancing_policy properties. To determine which standard properties to set, see the documentation for the resource type and Appendix B, Standard Properties.
Specifies your choice of the name of the resource to add.
The resource is created in the enabled state.
Verify that the scalable application resource has been added and validated.
# clresource show resource |
This example shows the addition of a resource (resource-1) to a resource group (resource-group-1). Note that resource-group-1 depends on the failover resource group that contains the network addresses that are in use (schost-1 and schost-2 in the following example). The resource depends on shared address resources (schost-1, schost-2), which must reside in one or more failover resource groups that you defined previously.
# clresource create -g resource-group-1 -t resource-type-1 \ -p Network_resources_used=schost-1,schost-2 resource-1 \ -p Scalable=True # clresource show resource-1 === Resources === Resource: resource-1 Type: resource-type-1 Type_version: Group: resource-group-1 R_description: Resource_project_name: default Enabled{phats1}: False Enabled{phats2}: False Monitored{phats1}: True Monitored{phats2}: True |
After you add a scalable application resource, follow the procedure How to Bring Online Resource Groups to enable the resource.
Adding a resource causes the Sun Cluster software to validate the resource. If the validation fails, the clresource command prints an error message and exits. To determine why the validation failed, check the syslog on each node for an error message. The message appears on the node that performed the validation, not necessarily the node on which you ran the clresource command.
The clresource(1CL) man page.
To enable resources to begin providing HA services, you must perform the following operations:
Enabling the resources in their resource groups
Enabling the resource monitors
Making the resource groups managed
Bringing online the resource groups
You can perform these tasks individually or by using a single command.
After you bring online a resource group, it is configured and ready for use. If a resource or node fails, the RGM switches the resource group online on alternate nodes to maintain availability of the resource group.
Perform this task from any cluster node.
On a cluster member, become superuser or assume a role that provides solaris.cluster.admin RBAC authorization.
Type the command to bring online the resource groups.
If you have intentionally disabled a resource or a fault monitor that must remain disabled, type the following command:
# clresourcegroup online rg-list |
Specifies a comma-separated list of the names of the resource groups to bring online. The resource groups must exist. The list may contain one resource group name or more than one resource group name.
You can omit the rg-list option. If you omit this option, all resource groups are brought online.
If you require the resources and their fault monitors to be enabled when the resource groups are brought online, type the following command:
# clresourcegroup online -emM rg-list |
Specifies a comma-separated list of the names of the resource groups to bring online. The resource groups must exist. The list can contain one resource group name or more than one resource group name.
You can omit the rg-list option. If you omit this option, all resource groups are brought online.
If any resource group that you are bringing online declares a strong affinity for other resource groups, this operation might fail. For more information, see Distributing Online Resource Groups Among Cluster Nodes.
Verify that each resource group that you specified in Step 2 is online.
The output from this command indicates on which nodes each resource group is online.
# clresourcegroup status |
This example shows how to bring online the resource group resource-group-1 and verify its status. All resources in this resource and their fault monitors are also enabled.
# clresourcegroup online -emM resource-group-1 # clresourcegroup status |
If you brought resource groups online without enabling their resources and fault monitors, enable the fault monitors of any resources that you require to be enabled. For more information, see How to Enable a Resource Fault Monitor.
The clresourcegroup(1CL) man page.
You can enable a resource that you neglected to enable when you brought online a resource group.
Perform this procedure from any cluster node.
Ensure that you have created and have the name of the resource that you intend to enable.
On a cluster member, become superuser or assume a role that provides solaris.cluster.admin RBAC authorization.
Enable the resource.
# clresource enable [-n node-zone-list] resource |
Specifies a comma-separated, ordered list of nodes on which to enable the resource. If you specify a global-cluster non-voting node, the format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource is enabled on all nodes in its resource group's node list.
If you specify more than one node with the -n option, you can specify only one resource.
Specifies the name of the resource that you want to enable.
Verify that the resource has been enabled.
# clresource status |
The output from this command indicates the state of the resource that you have enabled.
The clresource(1CL) man page.
To stop a resource group from continuously switching from one node to another when a START or STOP method fails, bring it to a quiescent state. To bring a resource group to a quiescent state, you issue the clresourcegroup quiesce command.
When you quiesce a resource group, resource methods that are executing are allowed to run until they are completed. If a serious problem occurs, you might need to quiesce a resource group immediately. To do so, you specify the -k command option, which kills the following methods:
Prenet_start
Start
Monitor_start
Monitor_stop
Stop
Postnet_stop
The Init, Fini Boot, and Update methods are not killed when you specify this command option.
However, if you immediately quiesce a resource group by killing methods, you might leave one of its resources in an error state such as Start_failed or Stop_failed. You must clear these error states yourself.
Become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Quiesce the resource group.
# clresourcegroup quiesce resource-group |
Become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Immediately quiesce the resource group.
# clresourcegroup quiesce -k resource-group |
The Prenet_start, Start, Monitor_start, Monitor_stop, Stop, and Postnet_stop methods that are associated with the resource group are killed immediately. The resource group is brought to a quiescent state.
The clresourcegroup quiesce -k command blocks until the specified resource group has reached a quiescent state.
You can temporarily suspend the automatic recovery actions of a resource group. You might need to suspend the automatic recovery of a resource group to investigate and fix a problem in the cluster. Or, you might need to perform maintenance on resource group services.
To suspend the automatic recovery actions of a resource group, you issue the clresourcegroup suspend command. To resume automatic recovery actions, you issue the clresourcegroup resume command.
When you suspend the automatic recovery actions of a resource group, you also bring the resource group to a quiescent state.
A suspended resource group is not automatically restarted or failed over until you explicitly issue the command that resumes automatic recovery. Whether online or offline, suspended data services remain in their current state. You can still manually switch the resource group to a different state on specified nodes. You can also still enable or disable individual resources in the resource group.
A dependency or affinity is suspended and not enforced when you suspend the automatic recovery actions of a resource group that does one of the following:
Contains a resource that has a restart dependency on another resource
Declares a strong positive or negative affinity for another resource group
When you suspend one of these categories of resource groups, Sun Cluster displays a warning that the dependency or affinity is suspended as well.
Setting the RG_system property does not affect your ability to suspend or resume the automatic recovery actions of a resource group. However, if you suspend a resource group for which the RG_system property is set to TRUE, a warning message is produced. The RG_system property specifies that a resource group contains critical system services. If set to TRUE, the RG_system property prevents users from inadvertently stopping, deleting, or modifying a resource group or its resources.
When you suspend the automatic recovery actions of a resource group, resource methods that are executing are allowed to run until they are completed. If a serious problem occurs, you might need to suspend the automatic recovery actions of a resource group immediately. To do so, you specify the -k command option, which kills the following methods:
Prenet_start
Start
Monitor_start
Monitor_stop
Stop
Postnet_stop
The Init, Fini Boot, and Update methods are not killed when you include this command option.
However, if you immediately suspend automatic recovery actions by killing methods, you might leave one of its resources in an error state such as Start_failed or Stop_failed. You must clear these error states yourself.
Become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Suspend the automatic recovery actions of the resource group.
# clresourcegroup suspend resource-group |
The resource group that you specify is not automatically started, restarted, or failed over until you resume automatic recovery actions. See How to Resume the Automatic Recovery Actions of a Resource Group.
Become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Immediately suspend the automatic recovery actions of the resource group.
# clresourcegroup suspend -k resource-group |
The Prenet_start, Start, Monitor_start, Monitor_stop, Stop, and Postnet_stop methods that are associated with the resource group are killed immediately. Automatic recovery actions of the resource group is suspended. The resource group is not automatically started, restarted, or failed over until you resume automatic recovery actions. See How to Resume the Automatic Recovery Actions of a Resource Group.
The clresourcegroup suspend -k command blocks until the specified resource group has reached a quiescent state.
Become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Resume the automatic recovery actions of the resource group.
# clresourcegroup resume resource-group |
The resource group that you specify is automatically started, restarted, or failed over.
The procedures in this section explain how to disable or enable resource fault monitors, not the resources themselves. A resource can continue to operate normally while its fault monitor is disabled. However, if the fault monitor is disabled and a data service fault occurs, automatic fault recovery is not initiated.
See the clresource(1CL) man page for additional information.
Perform these procedures from any cluster node.
On any cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Disable the resource fault monitor.
# clresource unmonitor [-n node-zone-list] resource |
Specifies a comma-separated, ordered list of nodes on which to unmonitor the resource. If you specify a global-cluster non-voting node, the format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource is unmonitored on all nodes in its resource group's node list.
If you specify more than one node with the -n option, you can specify only one resource.
Specifies the name of the resource or resources.
Run the clresource command on each cluster node and check for monitored fields (RS Monitored) to verify that the resource fault monitor has been disabled.
# clresource show -v |
# clresource unmonitor resource-1 # clresource show -v ... RS Monitored: no... |
On any cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Enable the resource fault monitor.
# clresource monitor [-n node-zone-list] resource |
Specifies a comma-separated, ordered list of nodes on which to monitor the resource. If you specify a global-cluster non-voting node, the format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global cluster, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource is monitored on all nodes in its resource group's node list.
If you specify more than one node with the -n option, you can specify only one resource.
Specifies the name of the resource or resources.
Run the clresource command on each cluster node and check for monitored fields (RS Monitored) to verify that the resource fault monitor has been enabled.
# clresource show -v |
# clresource monitor resource-1 # clresource show -v ... RS Monitored: yes... |
You do not need to remove resource types that are not in use. However, if you want to remove a resource type, follow this procedure.
Perform this procedure from any cluster node.
Removing a resource type involves disabling and removing all resources of that type in the cluster before unregistering the resource type.
To identify all instances of the resource type that you are removing, type the following command:
# clresourcetype show -v |
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Disable each resource of the resource type that you are removing.
# clresource disable resource |
Specifies the name of the resource to disable.
Remove each resource of the resource type that you are removing.
# clresource delete resource |
Specifies the name of the resource to remove.
Unregister the resource type.
# clresourcetype unregister resource-type |
Specifies the name of the resource type to unregister.
Verify that the resource type has been removed.
# clresourcetype show |
This example shows how to disable and remove all of the resources of a resource type (resource-type-1) and then unregister the resource type. In this example, resource-1 is a resource of the resource type resource-type-1.
# clresource disable resource-1 # clresource delete resource-1 # clresourcetype unregister resource-type-1 |
The following man pages:
To remove a resource group, you must first remove all of the resources from the resource group.
Perform this procedure from any cluster node.
To identify all resources in the resource group that you are removing, type the following command:
# clresource show -v |
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Run the following command to switch the resource group offline.
# clresourcegroup offline resource-group |
Specifies the name of the resource group to take offline.
Disable all of the resources in the resource group that you are removing.
# clresource disable resource |
Specifies the name of the resource to disable.
Remove all of the resources from the resource group.
For each resource, type the following command.
# clresource delete resource |
Specifies the name of the resource to be removed.
Remove the resource group.
# clresourcegroup delete resource-group |
Specifies the name of the resource group to be removed.
Verify that the resource group has been removed.
# clresourcegroup show |
This example shows how to remove a resource group (resource-group-1) after you have removed its resource (resource-1).
# clresourcegroup offline resource-group-1 # clresource disable resource-1 # clresource delete resource-1 # clresourcegroup delete resource-group-1 |
The following man pages:
Disable the resource before you remove it from a resource group.
Perform this procedure from any cluster node.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Disable the resource that you are removing.
# clrsource disable resource |
Specifies the name of the resource to disable.
Remove the resource.
# clresource delete resource |
Specifies the name of the resource to remove.
Verify that the resource has been removed.
# clresource show |
This example shows how to disable and remove a resource (resource-1).
# clresource disable resource-1 # clresource delete resource-1 |
Use the following procedure to switch over a resource group from its current primary to another node that is to become the new primary.
Perform this procedure from any cluster node.
Ensure that the following conditions are met:
You have the following information:
The name of the resource group that you are switching over
The names of the nodes where the resource group is to be brought online or to remain online
The nodes where the resource group is to be brought online or to remain online are in the cluster.
These nodes have been set up to be potential masters of the resource group that you are switching.
To see a list of potential primaries for the resource group, type the following command:
# clresourcegroup show -v |
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Switch the resource group to a new set of primaries.
# clresourcegroup switch [-n node-zone-list] resource-group |
Specifies a comma-separated, ordered list of global-cluster non-voting nodes that can master this resource group. The resource group is switched offline on all of the other nodes. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource group is switched on all nodes in the resource group's node list.
Specifies the name of the resource group to switch.
If any resource group that you are switching declares a strong affinity for other resource groups, the attempt to switch might fail or be delegated. For more information, see Distributing Online Resource Groups Among Cluster Nodes.
Verify that the resource group has been switched to the new primary.
The output from this command indicates the state of the resource group that has been switched over.
# clresourcegroup status |
This example shows how to switch the resource group resource-group-1 from its current primary phys-schost-1 to the potential primary phys-schost-2.
To verify that the resource group is online on phys-schost-1, the following command is run:
phys-schost-1# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- --------- --------- ------ resource-group1 phys-schost-1 No Online phys-schost-2 No Offline |
To perform the switch, the following command is run:
phys-schost-1# clresourcegroup switch -n phys-schost-2 resource-group-1 |
To verify that the group is switched to be online on phys-schost-2, the following command is run:
phys-schost-1# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- --------- --------- ------ resource-group1 phys-schost-1 No Offline phys-schost-2 No Online |
The clresourcegroup(1CL) page.
At times, you must bring a resource group into the UNMANAGED state before you perform an administrative procedure on it. Before you move a resource group into the UNMANAGED state, you must disable all of the resources that are part of the resource group and bring the resource group offline.
See the clresourcegroup(1CL) man page for additional information.
Perform this procedure from any cluster node.
When a shared address resource is disabled, the resource might still be able to respond to ping(1M) commands from some hosts. To ensure that a disabled shared address resource cannot respond to ping commands, you must bring the resource's resource group to the UNMANAGED state.
Ensure that you have the following information.
The name of each resource to be disabled
The name of the resource group to move into the UNMANAGED state
To determine the resource and resource group names that you need for this procedure, type:
# clresourcegroup show -v |
On any cluster member, become superuser or assume a role that provides solaris.cluster.admin RBAC authorization.
Disable all resources in the resource group.
# clresource disable [-n node-zone-list] -g resource-group + |
Specifies a comma-separated, ordered list of nodes on which to disable the resource. If you specify a global-cluster non-voting node, the format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource is disabled on all nodes in its resource group's node list.
If you specify more than one node with the -n option, you can specify only one resource.
Switch the resource group offline.
# clresourcegroup offline resource-group |
Specifies the name of the resource group to take offline.
Move the resource group into the UNMANAGED state.
# clresourcegroup unmanage resource-group |
Specifies the name of the resource group to move into the UNMANAGED state.
Verify that the resources are disabled and that the resource group is in the UNMANAGED state.
# clrsourcegroup show resource-group |
This example shows how to disable the resource (resource-1) and then move the resource group (resource-group-1) into the UNMANAGED state.
# clresource disable resource-1 # clresourcegroup offline resource-group-1 # clresourcegroup unmanage resource-group-1 # clresourcegroup show resource-group-1 === Resource Groups and Resources === Resource Group: resource-group-1 RG_description: <NULL> RG_mode: Failover RG_state: Unmanaged Failback: False Nodelist: phys-schost-1 phys-schost-2 --- Resources for Group resource-group-1 --- Resource: resource-1 Type: SUNW.LogicalHostname:2 Type_version: 2 Group: resource-group-1 R_description: Resource_project_name: default Enabled{phys-schost-1}: False Enabled{phys-schost-2}: False Monitored{phys-schost-1}: True Monitored{phys-schost-2}: True |
The following man pages:
Before you perform administrative procedures on resources, resource groups, or resource types, view the current configuration settings for these objects.
You can view configuration settings for resources, resource groups, and resource types from any cluster node.
You can also use the clresourcetype, clresourcegroup, and clresource commands to check status information about specific resource types, resource groups, and resources. For example, the following command specifies that you want to view specific information about the resource apache-1 only.
# clresource show apache-1 |
For more information, see the following man pages:
Sun Cluster defines standard properties for configuring resource types, resource groups, and resources. These standard properties are described in the following sections:
Resources also have extension properties, which are predefined for the data service that represents the resource. For a description of the extension properties of a data service, see the documentation for the data service.
To determine whether you can change a property, see the Tunable entry for the property in the description of the property.
The following procedures describe how to change properties for configuring resource types, resource groups, and resources.
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the resource type to change.
The name of the resource type property to change. For resource types, you can change only certain properties. To determine whether you can change a property, see the Tunable entry for the property in Resource Type Properties.
You cannot change the Installed_nodes property explicitly. To change this property, specify the -n installed-node-list option of the clresourcetype command.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Run the clresourcetype command to determine the name of the resource type that you need for this procedure.
# clresourcetype show -v |
Change the resource type property.
For resource types, you can change only certain properties. To determine whether you can change a property, see the Tunable entry for the property in Resource Type Properties.
# clresourcetype set -n installed-node-list \ [-p property=new-value]resource-type |
Specifies the names of nodes on which this resource type is installed.
Specifies the name of the standard property to change and the new value of the property.
You cannot change the Installed_nodes property explicitly. To change this property, specify the -n installed-node-list option of the clresourcetype command.
Verify that the resource type property has been changed.
# clresourcetype show resource-type |
This example shows how to change the SUNW.apache property to define that this resource type is installed on the global-cluster voting nodes of (phys-schost-1 and phys-schost-2).
# clresourcetype set -n phys-schost-1,phys-schost-2 SUNW.apache # clresourcetype show SUNW.apache Resource Type: SUNW.apache:4 RT_description: Apache Web Server on Sun Cluster RT_version: 4 API_version: 2 RT_basedir: /opt/SUNWscapc/bin Single_instance: False Proxy: False Init_nodes: All potential masters Installed_nodes: All Failover: False Pkglist: SUNWscapc RT_system: False |
This procedure explains how to change resource group properties. For a description of resource group properties, see Resource Group Properties.
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the resource group to change
The name of the resource group property to change and its new value
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Change the resource group property.
# clresourcegroup set -p property=new-value resource-group |
Specifies the name of the property to change
Specifies the name of the resource group
Verify that the resource group property has been changed.
# clresourcegroup show resource-group |
This example shows how to change the Failback property for the resource group (resource-group-1).
# clresourcegroup set-p Failback=True resource-group-1 # clrsourcegroup show resource-group-1 |
This procedure explains how to change extension properties and standard properties of a resource.
For a description of standard resource properties, see Resource Properties.
For a description of the extension properties of a resource, see the documentation for the resource's resource type.
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the resource with the property to change
The name of the property to change
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
View the current resource property settings.
# clresource show -v resource |
Change the resource property.
# clresource set -p standard-property=new-value | -p "extension-property \ [{node-specifier}]"=new-value resource |
Specifies the name of the standard property to change.
Specifies the name of the extension property to change.
node-specifier is an optional qualifier to the -p and -x options. This qualifier indicates that the extension property or properties on only the specified node or nodes are to be set when the resource is created. The specified extension properties on other nodes in the cluster are not set. If you do not include node-specifier, the specified extension properties on all nodes in the cluster are set. You can specify a node name or a node identifier for node-specifier. Examples of the syntax of node-specifier include the following:
-p "myprop{phys-schost-1}" |
The braces ({}) indicate that you are setting the specified extension property on only node phys-schost-1. For most shells, the double quotation marks (“) are required.
You can also use the following syntax to set an extension property in two different global-cluster non-voting nodes on two different global-cluster voting nodes:
-x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}" |
The extension property that you specify with node-specifier must be declared in the RTR file as a per-node property. See Appendix B, Standard Properties for information about the Per_node resource property attribute.
Specifies the name of the resource.
Verify that the resource property has been changed.
# clresource show -v resource |
This example shows how to change the system-defined Start_timeout property for the resource (resource-1).
# clresource set -p start_timeout=30 resource-1 # clresource show -v resource-1 |
This example shows how to change an extension property (Log_level) for the resource (resource-1).
# clresource set -p Log_level=3 resource-1 # clresource show -v resource-1 |
By default, logical hostname resources and shared address resources use name services for name resolution. You might configure a cluster to use a name service that is running on the same cluster. During the failover of a logical hostname resource or a shared address resource, a name service that is running on the cluster might also be failing over. If the logical hostname resource or the shared address resource uses the name service that is failing over, the resource fails to fail over.
Configuring a cluster to use a name server that is running on the same cluster might impair the availability of other services on the cluster.
To prevent such a failure to fail over, modify the logical hostname resource or the shared address resource to bypass name services. To modify the resource to bypass name services, set the CheckNameService extension property of the resource to false. You can modify the CheckNameService property at any time.
If your version of the resource type is earlier than 2, you must upgrade the resource type before you attempt to modify the resource. For more information, see Upgrading a Preregistered Resource Type.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Change the resource property.
# clresource set -p CheckNameService=false resource |
Sets the CheckNameService extension property of the resource to false.
Specifies the name of the logical hostname resource or shared address resource that you are modifying.
When the Failover_mode resource property is set to NONE or SOFT, a failure of the resource's STOP method causes the following effects:
The individual resource goes into the STOP_FAILED state.
The resource group that contains the resource goes into the ERROR_STOP_FAILED state.
In this situation, you cannot perform the following operations:
Bringing online the resource group on any node
Adding resources to the resource group
Removing resources from the resource group
Changing the properties of the resource group
Changing the properties of resources in the resource group
Perform this procedure from any cluster node.
Ensure that you have the following information.
The name of the node where the resource is STOP_FAILED
The name of the resource and resource group that are in STOP_FAILED state
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Identify which resources have gone into the STOP_FAILED state and on which nodes.
# clresource status |
Manually stop the resources and their monitors on the nodes on which they are in STOP_FAILED state.
This step might require that you kill processes or run commands that are specific to resource types or other commands.
Clear the STOP_FAILED error flag on the resources.
# clresource clear -f STOP_FAILED -n nodelist resource |
Specifies the flag name.
Specifies a comma-separated list of the names of the nodes where the resource is in the STOP_FAILED state. The list may contain one node name or more than one node name.
Specifies the name of the resource.
Check the resource group state on the nodes where you cleared the STOP_FAILED flag in Step 4.
# clresourcegroup status |
The resource group state should now be OFFLINE or ONLINE.
The resource group remains in the ERROR_STOP_FAILED state in the following combination of circumstances:
The resource group was being switched offline when the STOP method failure occurred.
The resource that failed to stop had a dependency on other resources in the resource group.
If the resource group remains in the ERROR_STOP_FAILED state, correct the error as follows.
The following man pages:
The Start_failed resource state indicates that a Start or Prenet_start method failed or timed out on a resource, but its resource group came online anyway. The resource group comes online even though the resource has been placed in a faulted state and might not be providing service. This state can occur if the resource's Failover_mode property is set to None or to another value that prevents the failover of the resource group.
Unlike the Stop_failed resource state, the Start_failed resource state does not prevent you or the Sun Cluster software from performing actions on the resource group. You need only to execute a command that restarts the resource.
Use any one of the following procedures to clear this condition.
Perform this procedure from any cluster node.
Ensure that the following conditions are met:
You have the following information:
The name of the resource group that you are switching over
The name of the node on which to switch over the resource group
The nodes where the resource group is to be brought online or to remain online are in the cluster .
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Switch the resource group to the new node.
# clresourcegroup switch [-n node-zone-list] resource-group |
Specifies a comma-separated, ordered list of nodes that can master this resource group. This resource group is switched offline on all of the other nodes. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global cluster-voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource group is switched on all nodes in the resource group's node list.
Specifies the name of the resource group to switch.
If any resource group that you are switching declares a strong affinity for other resource groups, the attempt to switch might fail or be delegated. For more information, see Distributing Online Resource Groups Among Cluster Nodes.
Verify that the resource group has been switched to the new node and that the Start_failed resource state is cleared.
# clresourcegroup status |
The output from this command indicates the state of the resource and the resource group that has been switched over.
This example shows how to clear a Start_failed resource state that has occurred on the rscon resource in the resource-group-1 resource group. The command clears this condition by switching the resource group to the global cluster voting node phys-schost-2.
To verify that the resource is in the Start_failed resource state on phys-schost-1, the following command is run:
# clresource status === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- ------- rscon phys-schost-1 Faulted Faulted phys-schost-2 Offline Offline hastor phys-schost-1 Online Online phys-schost-2 Offline Offline |
To perform the switch, the following command is run:
# clresourcegroup switch -n phys-schost-2 resource-group-1 |
To verify that the resource group is switched to be online on phys-schost-2 and that the Start_failed resource status is cleared, the following command is run:
# clresource status === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- ------- rscon phys-schost-1 Offline Offline phys-schost-2 Online Online hastor phys-schost-1 Online Online phys-schost-2 Offline Offline |
The clresourcegroup(1CL) man page.
Perform this procedure from any cluster node.
Ensure that the following conditions are met:
You have the following information:
The name of the resource group that you are restarting
The name of the node on which to restart the resource group
The nodes where the resource group is to be brought online or to remain online are cluster nodes.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Restart the resource group.
# clresourcegroup restart -n node resource-group |
Specifies the name of the node on which the resource group is to be restarted. This resource group is switched offline on all of the other nodes.
Specifies the name of the resource group to restart.
Verify that the resource group has been restarted on the new node and that the Start_failed resource state is cleared.
# clresourcegroup status |
The output from this command indicates the state of the resource and the resource group that has been restarted.
This example shows how to clear a Start_failed resource state that has occurred on the rscon resource in the resource-group-1 resource group. The command clears this condition by restarting the resource group on the global-cluster voting node phys-schost-1.
To verify that the resource is in the Start_failed resource state on phys-schost-1, the following command is run:
# clresource status === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- ------- rscon phys-schost-1 Faulted Faulted phys-schost-2 Offline Offline hastor phys-schost-1 Online Online phys-schost-2 Offline Offline |
To restart the resource, the following command is run:
# clresourcegroup restart -n phys-schost-1 –g resource-group-1 |
To verify that the resource group is restarted on phys-schost-1 and that the Start_failed resource status is cleared, the following command is run:
# clresource status === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- ------- rscon phys-schost-1 Offline Offline rscon phys-schost-2 Online Online hastor phys-schost-1 Online Online hastor phys-schost-2 Offline Offline |
The clresourcegroup(1CL) man page.
Perform this procedure from any cluster node.
Ensure that you have the name of the resource that you are disabling and enabling.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Disable and then enable the resource.
# clresource disable resource # clresource enable resource |
Specifies the name of the resource.
Verify that the resource has been disabled and enabled and that the Start_failed resource state is cleared.
# clresource status |
The output from this command indicates the state of the resource that has been disabled and re-enabled.
This example shows how to clear a Start_failed resource state that has occurred on the rscon resource by disabling and enabling the resource.
To verify that the resource is in the Start_failed resource state, the following command is run:
# clresource status === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- ------- rscon phys-schost-1 Faulted Faulted phys-schost-2 Offline Offline hastor phys-schost-1 Online Online phys-schost-2 Offline Offline |
To disable and re-enable the resource, the following commands are run:
# clresource disable rscon # clresource enable rscon |
To verify that the resource is re-enabled and that the Start_failed resource status is cleared, the following command is run:
# clresource status === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- ------- rscon phys-schost-1 Online Online phys-schost-2 Offline Offline hastor phys-schost-1 Online Online phys-schost-2 Offline Offline |
The clresource(1CL) man page.
In Sun Cluster 3.1 9/04, the following preregistered resource types are enhanced:
SUNW.LogicalHostname, which represents a logical hostname
SUNW.SharedAddress, which represents a shared address
The purpose of these enhancements is to enable you to modify logical hostname resources and shared address resources to bypass name services for name resolution.
Upgrade these resource types if all conditions in the following list apply:
You are upgrading from an earlier version of Sun Cluster.
You need to use the new features of the resource types.
For general instructions that explain how to upgrade a resource type, see Upgrading a Resource Type. The information that you need to complete the upgrade of the preregistered resource types is provided in the subsections that follow.
The relationship between the version of each preregistered resource type and the release of Sun Cluster is shown in the following table. The release of Sun Cluster indicates the release in which the version of the resource type was introduced.
Resource Type |
Resource Type Version |
Sun ClusterRelease |
---|---|---|
SUNW.LogicalHostname
|
1.0 |
3.0 |
2 |
3.1 9/04 |
|
SUNW.SharedAddress
|
1.0 |
3.0 |
2 |
3.1 9/04 |
To determine the version of the resource type that is registered, use one command from the following list:
clresourcetype list
clresourcetype list -v
This example shows the command for registering version 2 of the SUNW.LogicalHostname resource type during an upgrade.
# clresourcetype register SUNW.LogicalHostname:2 |
The information that you need to migrate an instance of a preregistered resource type is as follows:
You can perform the migration at any time.
If you need to use the new features of the preregistered resource type, the required value of the Type_version property is 2.
If you are modifying the resource to bypass name services, set the CheckNameService extension property of the resource to false.
This example shows the command for migrating the logical hostname resource lhostrs. As a result of the migration, the resource is modified to bypass name services for name resolution.
# clresource set -p CheckNameService=false -p Type_version=2 lhostrs |
The resource types SUNW.LogicalHostname and SUNW.SharedAddress are preregistered. All of the logical hostname and shared address resources use these resource types. You never need to register these two resource types, but you might inadvertently delete them. If you have deleted resource types inadvertently, use the following procedure to reregister them.
If you are upgrading a preregistered resource type, follow the instructions in Upgrading a Preregistered Resource Type to register the new resource type version.
Perform this procedure from any cluster node.
Reregister the resource type.
# clresourcetype register SUNW.resource-type |
Specifies the resource type to add (reregister). The resource type can be either SUNW.LogicalHostname or SUNW.SharedAddress.
This example shows how to reregister the SUNW.LogicalHostname resource type.
# clresourcetype register SUNW.LogicalHostname |
The clresourcetype(1CL) man page.
The procedures in this section enable you to perform the following tasks.
Configuring a cluster node to be an additional master of a resource group
Removing a node from a resource group
The procedures are slightly different, depending on whether you plan to add or remove the node to or from a failover or scalable resource group.
Failover resource groups contain network resources that both failover and scalable services use. Each IP subnetwork connected to the cluster has its own network resource that is specified and included in a failover resource group. The network resource is either a logical hostname or a shared address resource. Each network resource includes a list of IPMP groups that it uses. For failover resource groups, you must update the complete list of IPMP groups for each network resource that the resource group includes (the netiflist resource property).
The procedure for scalable resource groups involves the following steps:
Repeating the procedure for failover groups that contain the network resources that the scalable resource uses
Changing the scalable group to be mastered on the new set of hosts
For more information, see the clresourcegroup(1CL) man page.
Run either procedure from any cluster node.
The procedure to follow to add a node to a resource group depends on whether the resource group is a scalable resource group or a failover resource group. For detailed instructions, see the following sections:
You must supply the following information to complete the procedure.
The names and node IDs of all of the cluster nodes and names of zones
The names of the resource groups to which you are adding the node
The name of the IPMP group that is to host the network resources that are used by the resource group on all of the nodes
Also, be sure to verify that the new node is already a cluster member.
For each network resource that a scalable resource in the resource group uses, make the resource group where the network resource is located run on the new node.
See Step 1 through Step 5 in the following procedure for details.
Add the new node to the list of nodes that can master the scalable resource group (the nodelist resource group property).
This step overwrites the previous value of nodelist, and therefore you must include all of the nodes that can master the resource group here.
# clresourcegroup set [-n node-zone-list] resource-group |
Specifies a comma-separated, ordered list of nodes that can master this resource group. This resource group is switched offline on all of the other nodes. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the Nodelist property is set to all nodes in the cluster.
Specifies the name of the resource group to which the node is being added.
(Optional) Update the scalable resource's Load_balancing_weights property to assign a weight to the node that you are adding to the resource group.
Otherwise, the weight defaults to 1. See the clresourcegroup(1CL) man page for more information.
Display the current node list and the current list of IPMP groups that are configured for each resource in the resource group.
# clresourcegroup show -v resource-group | grep -i nodelist # clresourcegroup show -v resource-group | grep -i netiflist |
The output of the command line for nodelist and netiflist identifies the nodes by node name. To identify node IDs, run the command clnode show -v | grep -i node-id.
Update netiflist for the network resources that the node addition affects.
This step overwrites the previous value of netiflist, and therefore you must include all the IPMP groups here.
# clresource set -p netiflist=netiflist network-resource |
Specifies a comma-separated list that identifies the IPMP groups that are on each node. Each element in netiflist must be in the form of netif@node. netif can be given as an IPMP group name, such as sc_ipmp0. The node can be identified by the node name or node ID, such as sc_ipmp0@1 or sc_ipmp@phys-schost-1.
Specifies the name of the network resource (logical hostname or shared address) that is being hosted on the netiflist entries.
If the HAStoragePlus AffinityOn extension property equals True, add the node to the appropriate disk set or device group.
If you are using Solaris Volume Manager, use the metaset command.
# metaset -s disk-set-name -a -h node-name |
Specifies the name of the disk set on which the metaset command is to work
Adds a drive or host to the specified disk set
Specifies the node to be added to the disk set
SPARC: If you are using Veritas Volume Manager, use the clsetup utility.
On any active cluster member, start the clsetup utility.
# clsetup |
The Main Menu is displayed.
On the Main Menu, type the number that corresponds to the option for device groups and volumes.
On the Device Groups menu, type the number that corresponds to the option for adding a node to a VxVM device group.
Respond to the prompts to add the node to the VxVM device group.
Update the node list to include all of the nodes that can now master this resource group.
This step overwrites the previous value of nodelist, and therefore you must include all of the nodes that can master the resource group here.
# clresourcegroup set [-n node-zone-list] resource-group |
Specifies a comma-separated, ordered list of global-cluster non-voting nodes that can master this resource group. This resource group is switched offline on all the other nodes. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the Nodelist property is set to all nodes in the cluster.
Specifies the name of the resource group to which the node is being added.
Verify the updated information.
# clresourcegroup show -vresource-group | grep -i nodelist # clresourcegroup show -vresource-group | grep -i netiflist |
This example shows how to add a global-cluster voting node (phys-schost-2) to a resource group (resource-group-1) that contains a logical hostname resource (schost-2).
# clresourcegroup show -v resource-group-1 | grep -i nodelist ( Nodelist: phys-schost-1 phys-schost-3 # clresourcegroup show -v resource-group-1 | grep -i netiflist ( Res property name: NetIfList Res property class: extension List of IPMP interfaces on each node Res property type: stringarray Res property value: sc_ipmp0@1 sc_ipmp0@3 (Only nodes 1 and 3 have been assigned IPMP groups. You must add an IPMP group for node 2.) # clresource set -p netiflist=sc_ipmp0@1,sc_ipmp0@2,sc_ipmp0@3 schost-2 # metaset -s red -a -h phys-schost-2 # clresourcegroup set -n phys-schost-1,phys-schost-2,phys-schost-3 resource-group-1 # clresourcegroup show -v resource-group-1 | grep -i nodelist Nodelist: phys-schost-1 phys-schost-2 phys-schost-3 # clresourcegroup show -v resource-group-1 | grep -i netiflist Res property value: sc_ipmp0@1 sc_ipmp0@2 sc_ipmp0@3 |
The procedure to follow to remove a node from a resource group depends on whether the resource group is a scalable resource group or a failover resource group. For detailed instructions, see the following sections:
To complete the procedure, you must supply the following information.
Node names and node IDs of all of the cluster nodes
# clnode show -v | grep -i “Node ID” |
The name of the resource group or the names of the resource groups from which you plan to remove the node
# clresourcegroup show | grep “Nodelist” |
Names of the IPMP groups that are to host the network resources that are used by the resource groups on all of the nodes
# clresourcegroup show -v | grep “NetIfList.*value” |
Additionally, be sure to verify that the resource group is not mastered on the node that you are removing. If the resource group is mastered on the node that you are removing, run the clresourcegroup command to switch the resource group offline from that node. The following clresourcegroup command brings the resource group offline from a given node, provided that new-masters does not contain that node.
# clresourcegroup switch -n new-masters resource-group |
Specifies the nodes that is now to master the resource group.
Specifies the name of the resource group that you are switching . This resource group is mastered on the node that you are removing.
For more information, see the clresourcegroup(1CL) man page.
If you plan to remove a node from all the resource groups, and you use a scalable services configuration, first remove the node from the scalable resource groups. Then remove the node from the failover groups.
A scalable service is configured as two resource groups, as follows.
One resource group is a scalable group that contains the scalable service resource.
One resource group is a failover group that contains the shared address resources that the scalable service resource uses.
Additionally, the RG_dependencies property of the scalable resource group is set to configure the scalable group with a dependency on the failover resource group. For information about this property, see Appendix B, Standard Properties.
For details about scalable service configuration, see Sun Cluster Concepts Guide for Solaris OS.
Removing a node from the scalable resource group causes the scalable service to no longer be brought online on that node. To remove a node from the scalable resource group, perform the following steps.
Remove the node from the list of nodes that can master the scalable resource group (the nodelist resource group property).
# clresourcegroup set [-n node-zone-list] scalable-resource-group |
Specifies a comma-separated, ordered list of nodes that can master this resource group. This resource group is switched offline on all the other nodes. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the Nodelist property is set to all nodes in the cluster.
Specifies the name of the resource group from which the node is being removed.
(Optional) Remove the node from the failover resource group that contains the shared address resource.
For details, see How to Remove a Node From a Failover Resource Group That Contains Shared Address Resources.
(Optional) Update the Load_balancing_weights property of the scalable resource to remove the weight of the node that you are removing from the resource group.
The clresourcegroup(1CL) man page.
Perform the following steps to remove a node from a failover resource group.
If you plan to remove a node from all of the resource groups, and you use a scalable services configuration, first remove the node from the scalable resource groups. Then use this procedure to remove the node from the failover groups.
If the failover resource group contains shared address resources that scalable services use, see How to Remove a Node From a Failover Resource Group That Contains Shared Address Resources.
Update the node list to include all of the nodes that can now master this resource group.
This step removes the node and overwrites the previous value of the node list. Be sure to include all of the nodes that can master the resource group here.
# clresourcegroup set [-n node-zone-list] failover-resource-group |
Specifies a comma-separated, ordered list of nodes that can master this resource group. This resource group is switched offline on all the other nodes. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the Nodelist property is set to all nodes in the cluster.
Specifies the name of the resource group from which the node is being removed.
Display the current list of IPMP groups that are configured for each resource in the resource group.
# clresourcegroup show -v failover-resource-group | grep -i netiflist |
Update netiflist for network resources that the removal of the node affects.
This step overwrites the previous value of netiflist. Be sure to include all of the IPMP groups here.
# clresource set -p netiflist=netiflist network-resource |
The output of the preceding command line identifies the nodes by node name. Run the command line clnode show -v | grep -i “Node ID” to find the node ID.
Specifies a comma-separated list that identifies the IPMP groups that are on each node. Each element in netiflist must be in the form of netif@node. netif can be given as an IPMP group name, such as sc_ipmp0. The node can be identified by the node name or node ID, such as sc_ipmp0@1 or sc_ipmp@phys-schost-1.
Specifies the name of the network resource that is hosted on the netiflist entries.
Sun Cluster does not support the use of the adapter name for netif.
Verify the updated information.
# clresourcegroup show -vfailover-resource-group | grep -i nodelist # clresourcegroup show -vfailover-resource-group | grep -i netiflist |
In a failover resource group that contains shared address resources that scalable services use, a node can appear in the following locations.
The node list of the failover resource group
The auxnodelist of the shared address resource
To remove the node from the node list of the failover resource group, follow the procedure How to Remove a Node From a Failover Resource Group.
To modify the auxnodelist of the shared address resource, you must remove and recreate the shared address resource.
If you remove the node from the failover group's node list, you can continue to use the shared address resource on that node to provide scalable services. To continue to use the shared address resource, you must add the node to the auxnodelist of the shared address resource. To add the node to the auxnodelist, perform the following steps.
You can also use the following procedure to remove the node from the auxnodelist of the shared address resource. To remove the node from the auxnodelist, you must delete and recreate the shared address resource.
Switch the scalable service resource offline.
Remove the shared address resource from the failover resource group.
Create the shared address resource.
Add the node ID or node name of the node that you removed from the failover resource group to the auxnodelist.
# clressharedaddress create -g failover-resource-group \ -X new-auxnodelist shared-address |
The name of the failover resource group that used to contain the shared address resource.
The new, modified auxnodelist with the desired node added or removed.
The name of the shared address.
This example shows how to remove a node (phys-schost-3) from a resource group (resource-group-1) that contains a logical hostname resource (schost-1).
# clresourcegroup show -v resource-group-1 | grep -i nodelist Nodelist: phys-schost-1 phys-schost-2 phys-schost-3 # clresourcegroup set -n phys-schost-1,phys-schost-2 resource-group-1 # clresourcegroup show -v resource-group-1 | grep -i netiflist ( Res property name: NetIfList Res property class: extension ( List of IPMP interfaces on each node ( Res property type: stringarray Res property value: sc_ipmp0@1 sc_ipmp0@2 sc_ipmp0@3 (sc_ipmp0@3 is the IPMP group to be removed.) # clresource set -p netiflist=sc_ipmp0@1,sc_ipmp0@2 schost-1 # clresourcegroup show -v resource-group-1 | grep -i nodelist Nodelist: phys-schost-1 phys-schost-2 # clresourcegroup show -v resource-group-1 | grep -i netiflist Res property value: sc_ipmp0@1 sc_ipmp0@2 |
You can migrate the application resources from a global-cluster voting node to a global-cluster non-voting node.
The data services you want to migrate should be scalable and also be supported in global-cluster non-voting nodes
The procedure assumes a three node cluster with a global-cluster non-voting node created on each of the three nodes. The configuration directory that is made highly available using the HAStoragePlus resource should also be accessible from the global-cluster non-voting nodes.
Create the failover resource group with the global-cluster voting node that holds the shared address that the scalable resource group is to use.
# clresourcegroup create -n node1,node2,node3 sa-resource-group |
Specifies your choice of the name of the failover resource group to add. This name must begin with an ASCII character.
Add the shared address resource to the failover resource group.
# clressharedaddress create -g sa-resource-group -h hostnamelist, … \ [-X auxnodelist] -N netiflist network-resource |
Specifies the resource group name. In the node list of a shared address resource, do not specify more than one global-cluster non-voting node on the same global-cluster voting node. Specify the same list of nodename:zonename pairs as the node list of the scalable resource group.
Specifies a comma-separated list of shared address hostnames.
Specifies a comma-separated list of node names or IDs or zones that identify the cluster nodes that can host the shared address but never serve as primary if failover occurs. These nodes are mutually exclusive, with the nodes identified as potential masters in the resource group's node list. If no auxiliary node list is explicitly specified, the list defaults to the list of all cluster node names that are not included in the node list of the resource group that contains the shared address resource.
To ensure that a scalable service runs in all global-cluster non-voting nodes that were created to master the service, the complete list of nodes must be included in the node list of the shared address resource group or the auxnodelist of the shared address resource. If all the global-cluster non-voting nodes are listed in the node list, the auxnodelist can be omitted.
Specifies an optional, comma-separated list that identifies the IPMP groups that are on each node. Each element in netiflist must be in the form of netif@node. netif can be given as an IPMP group name, such as sc_ipmp0. The node can be identified by the node name or node ID, such as sc_ipmp0@1 or sc_ipmp@phys-schost-1.
Sun Cluster does not support the use of the adapter name for netif.
Specifies an optional resource name of your choice.
Create the scalable resource group.
# clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\ -n node1,node2,node3\ -p RG_dependencies=sa-resource-group resource-group-1 |
Specifies the maximum number of active primaries for this resource group.
Specifies the number of active primaries on which the resource group should attempt to start.
Specifies your choice of the name of the scalable resource group to add. This name must begin with an ASCII character.
Create the HAStoragePlus resource hastorageplus-1, and define the filesystem mount points.
# clresource create -g resource-group-1 -t SUNW.HAStoragePlus \ -p FilesystemMountPoints=/global/resource-group-1 hastorageplus-1 |
The resource is created in the enabled state.
Register the resource type for the application.
# clresourcetype register resource-type |
Specifies name of the resource type to add. See the release notes for your release of Sun Cluster to determine the predefined name to supply.
Add the application resource to resource-group-1, and set the dependency to hastorageplus-1.
# clresource create -g resource-group-1 -t SUNW.application \ [-p "extension-property[{node-specifier}]"=value, …] -p Scalable=True \ -p Resource_dependencies=network-resource -p Port_list=port-number/protocol \ -p Resource_dependencies=hastorageplus-1 resource |
Bring the failover resource group online.
# clresourcegroup online sa-resource-group |
Bring the scalable resource group online on all the nodes.
# clresourcegroup online resource-group-1 |
Install and boot zone1 on each of the nodes, node1, node2, node3.
Bring the application resource group offline on two nodes (node1, node2).
Ensure the shared address is online on node3.
# clresourcegroup switch -n node3 resource-group-1 |
Specifies the name of the resource group to switch.
Update the nodelist property of the failover resource group to include the global-cluster non-voting node of the corresponding nodes removed from the node list.
# clresourcegroup set -n node1:zone1,node2:zone1,node3 sa-resource-group |
Update the nodelist property of the application resource group to include the global-cluster non-voting node of the corresponding nodes removed from node list.
# clresourcegroup set node1:zone1,node2:zone1,node3 resource-group-1 |
Bring the failover resource group and application resource group online only on the newly added zones.
The failover resource group will be online only on node1:zone1 and application resource group will be online only on node1:zone1 and node2:zone1.
# clresourcegroup switch -n node1:zone1 sa-resource-group |
# clresourcegroup switch -n node1:zone1,node2:zone1 resource-group-1 |
Update the nodelist property of both the resource groups to include the global-cluster non-voting node of node3 by removing the global node, node3 from the list.
# clresourcegroup set node1:zone1,node2:zone1,node3:zone1 sa-resource-group |
# clresourcegroup set node1:zone1,node2:zone1,node3:zone1 resource-group-1 |
Bring both the resource groups online on the global-cluster non-voting nodes.
# clresourcegroup switch -n node1:zone1 sa-resource-group |
# clresourcegroup switch -n node1:zone1,node2:zone1,node3:zone1 resource-group-1 |
After a cluster boots or services fail over to another node, global devices and local and cluster file systems might require time to become available. However, a data service can run its START method before global devices and local and cluster file systems come online. If the data service depends on global devices or local and cluster file systems that are not yet online, the START method times out. In this situation, you must reset the state of the resource groups that the data service uses and restart the data service manually.
To avoid these additional administrative tasks, use the HAStoragePlus resource type. Add an instance of HAStoragePlus to all resource groups whose data service resources depend on global devices or local and cluster file systems. Instances of these resource types perform the following operations:
Forcing the START method of the other resources in the same resource group to wait until global devices and local and cluster file systems become available.
To create an HAStoragePlus resource, see How to Set Up the HAStoragePlus Resource Type for New Resources.
When you configure HAStoragePlus resources for a zone cluster, you need to perform the following additional tasks before performing the steps for global cluster:
While configuring file systems like UFS or standalone QFS in file system mount points, the file systems need to be configured to the zone cluster. For more information about configuring a file system to a zone cluster, see How to Add a Local File System to a Zone Cluster in Sun Cluster Software Installation Guide for Solaris OS.
While configuring global devices in global device paths, the devices need to be configured to the zone cluster. For more information about configuring global devices to a zone cluster, see Adding Storage Devices to a Zone Cluster in Sun Cluster Software Installation Guide for Solaris OS.
While configuring the ZFS file systems using Zpools, the ZFS pool needs to be configured to the zone cluster. For more information about configuring a ZFS file system to a zone cluster, see How to Add a ZFS Storage Pool to a Zone Cluster in Sun Cluster Software Installation Guide for Solaris OS.
The cluster file system is not supported for Zone Cluster.
In the following example, the resource group resource-group-1 contains the following data services.
Sun Java System Web Server, which depends on /global/resource-group-1
Oracle, which depends on /dev/global/dsk/d5s2
NFS, which depends on dsk/d6
To create an HAStoragePlus resource with Solaris ZFS (Zettabyte File System) as a highly available local file system seeHow to Set Up the HAStoragePlus Resource Type to Make a Local Solaris ZFS Highly Available section.
To create an HAStoragePlus resource hastorageplus-1 for new resources in resource-group-1, read Synchronizing the Startups Between Resource Groups and Device Groups and then perform the following steps.
To create an HAStoragePlus resource, see Enabling Highly Available Local File Systems.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify and solaris.cluster.admin RBAC authorizations.
Create the resource group resource-group-1.
# clresourcegroup create resource-group-1 |
Determine whether the resource type is registered.
The following command prints a list of registered resource types.
# clresourcetype show | egrep Type |
If you need to, register the resource type.
# clresourcetype register SUNW.HAStoragePlus |
Create the HAStoragePlus resource hastorageplus-1, and define the filesystem mount points and global device paths.
# clresource create -g resource-group-1 -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=/dev/global/dsk/d5s2,dsk/d6 \ -p FilesystemMountPoints=/global/resource-group-1 hastorageplus-1 |
GlobalDevicePaths can contain the following values.
Global device group names, such as nfs-dg, dsk/d5
Paths to global devices, such as /dev/global/dsk/d1s2, /dev/md/nfsdg/dsk/d10
FilesystemMountPoints can contain the following values.
Mount points of local or cluster file systems, such as /local-fs/nfs, /global/nfs
HAStoragePlus has a Zpools extension property that is used to configure ZFS file system storage pools and a ZpoolsSearchDir extension property that is used to specify the location to search for the devices of ZFS file system storage pools. The default value for the ZpoolsSearchDir extension property is /dev/dsk. The ZpoolsSearchDir extension property is similar to the -d option of the zpool(1M) command.
The resource is created in the enabled state.
Add the resources (Sun Java System Web Server, Oracle, and NFS) to resource-group-1, and set their dependency to hastorageplus-1.
For example, for Sun Java System Web Server, run the following command.
# clresource create -g resource-group-1 -t SUNW.iws \ -p Confdir_list=/global/iws/schost-1 -p Scalable=False \ -p Network_resources_used=schost-1 -p Port_list=80/tcp \ -p Resource_dependencies=hastorageplus-1 resource |
The resource is created in the enabled state.
Verify that you have correctly configured the resource dependencies.
# clresource show -v resource | egrep Resource_dependencies |
Set resource-group-1 to the MANAGED state, and bring resource-group-1 online.
# clresourcegroup online -M resource-group-1 |
The HAStoragePlus resource type contains another extension property, AffinityOn, which is a Boolean that specifies whether HAStoragePlus must perform an affinity switchover for the global devices that are defined in GLobalDevicePaths and FileSystemMountPoints extension properties. For details, see the SUNW.HAStoragePlus(5) man page.
The setting of the AffinityOn flag is ignored for scalable services. Affinity switchovers are not possible with scalable resource groups.
Read Synchronizing the Startups Between Resource Groups and Device Groups.
Determine whether the resource type is registered.
The following command prints a list of registered resource types.
# clresourcetype show | egrep Type |
If you need to, register the resource type.
# clresourcetype register SUNW.HAStoragePlus |
Create the HAStoragePlus resource hastorageplus-1.
# clresource create -g resource-group \ -t SUNW.HAStoragePlus -p GlobalDevicePaths= … \ -p FileSystemMountPoints=... -p AffinityOn=True hastorageplus-1 |
The resource is created in the enabled state.
Set up the dependency for each of the existing resources, as required.
# clresource set -p Resource_Dependencies=hastorageplus-1 resource |
Verify that you have correctly configured the resource dependencies.
# clresource show -v resource | egrep Resource_dependencies |
When an HAStoragePlus resource is configured for cluster file systems and brought online, it ensures that these file systems are available. The cluster file system is supported on the UNIX File System (UFS) and Veritas File System (VxFS). The instructions in this section apply to HAStoragePlus resources with UFS. Use HAStoragePlus with local file systems if the data service is I/O intensive. See How to Change the Cluster File System to Local File System in an HAStoragePlus Resource for information about how to change the file system of an HAStoragePlus resource.
The following examples show entries in the /etc/vfstab file for global devices that are to be used for cluster file systems.
The entries in the /etc/vfstab file for cluster file systems should contain the globalkeyword in the mount options.
This example shows entries in the /etc/vfstab file for a global device that uses Solaris Volume Manager.
/dev/md/kappa-1/dsk/d0 /dev/md/kappa-1/rdsk/d0 /global/local-fs/nfs ufs 5 yes logging,global
This example shows entries in the /etc/vfstab file for a global device that uses VxVM.
/dev/vx/dsk/kappa-1/appvol /dev/vx/rdsk/kappa-1/appvol /global/local-fs/nfs vxfs 5 yes log,global
On any node in the cluster, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Create a failover resource group.
# clresourcegroup create resource-group-1 |
Register the HAStoragePlus resource type.
# clresourcetype register SUNW.HAStoragePlus |
Create the HAStoragePlus resource and define the filesystem mount points.
# clresource create -g resource-group -t SUNW.HAStoragePlus \ -p FileSystemMountPoints="mount-point-list" hasp-resource |
The resource is created in the enabled state.
Add the data service resources to resource-group-1, and set their dependency to hasp-resource.
Bring online and in a managed state the resource group that contains the HAStoragePlus resource.
# clresourcegroup online -M resource-group-1 |
Disable and delete the HAStoragePlus resource configured for cluster file systems.
# clresource delete -F -g resource-group -t SUNW.HAStoragePlus resource |
Using a highly available local file system improves the performance of I/O intensive data services. To make a local file system highly available in a Sun Cluster environment, use the HAStoragePlus resource type.
You can specify global or local file systems. Global file systems are accessible from all nodes in a cluster. Local file systems are accessible from a single cluster node. Local file systems that are managed by a SUNW.HAStoragePlus resource are mounted on a single cluster node. These local file systems require the underlying devices to be Sun Cluster global devices.
These file system mount points are defined in the format paths[,...]. You can specify both the path in a global-cluster non-voting node and the path in a global-cluster voting node , in this format:
Non-GlobalZonePath:GlobalZonePath
The global-cluster voting node path is optional. If you do not specify a global-cluster voting node path, Sun Cluster assumes that the path in the global-cluster non-voting node and in the global-cluster voting node are the same. If you specify the path as Non-GlobalZonePath:GlobalZonePath, you must specify GlobalZonePath in the global-cluster voting node's /etc/vfstab.
The default setting for this property is an empty list.
You can use the SUNW.HAStoragePlus resource type to make a file system available to a global-cluster non-voting node. To enable the SUNW.HAStoragePlus resource type to do this, you must create a mount point in the global-cluster voting node and in the global-cluster non-voting node. The SUNW.HAStoragePlus resource type makes the file system available to the global-cluster non-voting node by mounting the file system in the global cluster. The resource type then performs a loopback mount in the global-cluster non-voting node. Each file system mount point should have an equivalent entry in /etc/vfstab on all cluster nodes and in the global-cluster voting node. The SUNW.HAStoragePlus resource type does not check /etc/vfstab in global-cluster non-voting nodes.
Local file systems include the UNIX File System (UFS), Quick File System (QFS), Veritas File System (VxFS), and Solaris ZFS (Zettabyte File System).
The instructions for each Sun Cluster data service that is I/O intensive explain how to configure the data service to operate with the HAStoragePlus resource type. For more information, see the individual Sun Cluster data service guides.
Do not use the HAStoragePlus resource type to make a root file system highly available.
Sun Cluster provides the following tools for setting up the HAStoragePlus resource type to make local file systems highly available:
Sun Cluster Manager. For more information, see the Sun Cluster Manager online help.
The clsetup(1CL) utility.
Sun Cluster maintenance commands.
Sun Cluster Manager and the clsetup utility enable you to add resources to the resource group interactively. Configuring these resources interactively reduces the possibility for configuration errors that might result from command syntax errors or omissions. Sun Cluster Manager and the clsetup utility ensure that all required resources are created and that all required dependencies between resources are set.
Any file system on multihost disks must be accessible from any host that is directly connected to those multihost disks. To meet this requirement, configure the highly available local file system as follows:
Ensure that the disk partitions of the local file system reside on global devices.
Set the AffinityOn extension property of the HAStoragePlus resource that specifies these global devices to True.
The Zpools extension property of the HAStoragePlus resource ignores the AffinityOn extension property.
Create the HAStoragePlus resource in a failover resource group.
Ensure that the failback settings for the device groups and the resource group that contains the HAStoragePlus resource are identical.
The use of a volume manager with the global devices for a highly available local file system is optional.
If you are not using a volume manager, use the appropriate format for the name of the underlying storage device. The format to use depends on the type of storage device as follows:
For block devices: /dev/global/dsk/dDsS
For raw devices: /dev/global/rdsk/dDsS
The replaceable elements in these device names are as follows:
D is an integer that specifies the device ID (DID) instance number.
S is an integer that specifies the slice number.
The following examples show entries in the /etc/vfstab file for global devices that are to be used for highly available local file systems.
Solaris ZFS (Zettabyte File System) does not use the /etc/vfstab file.
This example shows entries in the /etc/vfstab file for a global device on a physical disk without a volume manager.
/dev/global/dsk/d1s0 /dev/global/rdsk/d1s0 /global/local-fs/nfs ufs 5 no logging
This example shows entries in the /etc/vfstab file for a global device that uses Solaris Volume Manager.
/dev/md/kappa-1/dsk/d0 /dev/md/kappa-1/rdsk/d0 /global/local-fs/nfs ufs 5 no logging
This example shows entries in the /etc/vfstab file for a global device that uses VxVM.
/dev/vx/dsk/kappa-1/appvol /dev/vx/rdsk/kappa-1/appvol /global/local-fs/nfs vxfs 5 no log
The following instructions explain how to how to set up the HAStoragePlus resource type by using the clsetup utility. Perform this procedure from any global-cluster voting node.
This procedure provides the long forms of the Sun Cluster maintenance commands. Most commands also have short forms. Except for the forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix A, Sun Cluster Object-Oriented Commands.
Ensure that the following prerequisites are met:
Ensure that the required volumes, disk groups and file systems are created.
Become superuser on any cluster voting node.
Start the clsetup utility.
# clsetup |
The clsetup main menu is displayed.
Type the number that corresponds to the option for data services and press Return.
The Data Services menu is displayed.
Type the number that corresponds to the option for configuring the file system and press Return.
The clsetup utility displays the list of prerequisites for performing this task.
Verify that the prerequisites are met, and press Return to continue.
The clsetup utility displays a list of the cluster nodes that can master the highly available HAStoragePlus resource.
Select the nodes that can master the highly available HAStoragePlus resource.
To accept the default selection of all listed nodes in an arbitrary order, type a and press Return.
To select a subset of the listed nodes, type a comma-separated or space-separated list of the numbers that correspond to the nodes. Then press Return.
Ensure that the nodes are listed in the order in which the nodes are to appear in the HAStoragePlus resource group's node list. The first node in the list is the primary node of this resource group.
To select all nodes in a particular order, type a comma-separated or space-separated ordered list of the numbers that correspond to the nodes and press Return.
To confirm your selection of nodes, type d and press Return.
The clsetup utility displays a list of types of shared storage type where data is to be stored.
Type the numbers that correspond to type of shared storage that you are using for storing the data and press Return.
The clsetup utility displays the file system mount points that are configured in the cluster. If there are no existing mount points, the clsetup utility allows you to define a new mount point.
Specify the default mount directory, the raw device path, the Global Mount option and the Check File System Periodically option and press Return.
The clsetup utility returns you the properties of the mount point that the utility will create.
To create the mount point, type d and press Return.
The clsetup utility displays the available file system mount points.
You can use the c option to define another new mount point.
Select the file system mount points.
To accept the default selection of all listed file system mount points in an arbitrary order, type a and press Return.
To select a subset of the listed file system mount points, type a comma-separated or space-separated list of the numbers that correspond to the file system mount points and press Return.
To confirm your selection of nodes, type d and press Return.
The clsetup utility displays the global disk sets and device groups that are configured in the cluster.
Select the global device groups.
To confirm your selection of nodes, type d and press Return.
The clsetup utility displays the names of the Sun Cluster objects that the utility will create.
If you require a different name for any Sun Cluster object, change the name as follows.
Type the number that corresponds to the name that you are changing and press Return.
The clsetup utility displays a screen where you can specify the new name.
At the New Value prompt, type the new name and press Return.
The clsetup utility returns you to the list of the names of the Sun Cluster objects that the utility will create.
To confirm your selection of Sun Cluster object names, type d and press Return.
The clsetup utility displays information about the Sun Cluster configuration that the utility will create.
To create the configuration, type c and Press Return.
The clsetup utility displays a progress message to indicate that the utility is running commands to create the configuration. When configuration is complete, the clsetup utility displays the commands that the utility ran to create the configuration.
(Optional) Type q and press Return repeatedly until you quit the clsetup utility.
If you prefer, you can leave the clsetup utility running while you perform other required tasks before using the utility again. If you choose to quit clsetup, the utility recognizes your existing resource group when you restart the utility.
Verify the HAStoragePlus resource has been created.
Use the clresource(1CL) utility for this purpose. By default, the clsetup utility assigns the name node_name-rg to the resource group.
# clresource show node_name-rg |
The following procedure explains how to set up the HAStoragePlus resource type to make file systems other than Solaris ZFS highly available.
On any node in the global cluster, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Create a failover resource group.
# clresourcegroup create resource-group |
Register the HAStoragePlus resource type.
# clresourcetype register SUNW.HAStoragePlus |
Create the HAStoragePlus resource and define the file system mount points.
# clresource create -g resource-group \ -t SUNW.HAStoragePlus -p FileSystemMountPoints=mount-point-list hasp-resource |
Bring online and in a managed state the resource group that contains the HAStoragePlus resource.
# clresourcegroup online -M resource-group |
This example assumes that the file system /web-1 is configured to the HAStoragePlus resource to make the file system highly available for the global cluster.
phys-schost-1# vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # # /dev/md/apachedg/dsk/d0 /dev/md/apachedg/rdsk/d0 /web-1 ufs 2 no logging # clresourcegroup create hasp-rg # clresourcetype register SUNW.HAStoragePlus # clresource create -g hasp-rg -t SUNW.HAStoragePlus -p FileSystemMountPoints=/global/ufs-1 hasp-rs # clresourcegroup online -M hasp-rg |
This example assumes that the file system /web-1 is configured to the HAStoragePlus resource to make the file system highly available for a zone cluster sczone.
phys-schost-1# vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/apachedg/dsk/d0 /dev/md/apachedg/rdsk/d0 /web-1 ufs 2 no logging # clzonecluster configure sczone clzc:sczone> add fs clzc:sczone:fs> set dir=/web-1 clzc:sczone:fs> set special=/dev/md/apachedg/dsk/d0 clzc:sczone:fs> set raw=/dev/md/apachedg/rdsk/d0 clzc:sczone:fs> set type=ufs clzc:sczone:fs> end clzc:sczone:fs> exit # clresourcegroup create -Z sczone hasp-rg # clresourcetype register -Z sczone SUNW.HAStoragePlus # clresource create -Z sczone -g hasp-rg \ -t SUNW.HAStoragePlus -p FileSystemMountPoints=/global/ufs-1 hasp-rs # clresourcegroup online -Z sczone -M hasp-rg |
You perform the following primary tasks to make a local Solaris ZFS (Zettabyte File System) highly available:
Create a ZFS storage pool.
Create a ZFS file system in that ZFS storage pool.
Set up the HAStoragePlus resource that manages the ZFS storage pool.
This section describes how to complete both tasks.
Create a ZFS storage pool.
Do not add a configured quorum device to a ZFS storage pool. When a configured quorum device is added to a storage pool, the disk is relabeled as an EFI disk, the quorum configuration information is lost, and the disk no longer provides a quorum vote to the cluster. Once a disk is in a storage pool, you can configure that disk as a quorum device. Or, you can unconfigure the disk, add it to the storage pool, then reconfigure the disk as a quorum device.
Observe the following requirements when you create a ZFS storage pool in a Sun Cluster configuration:
Ensure that all of the devices from which you create a ZFS storage pool are accessible from all nodes in the cluster. These nodes must be configured in the node list of the resource group to which the HAStoragePlus resource belongs.
Ensure that the Solaris device identifier that you specify to the zpool(1M) command, for example /dev/dsk/c0t0d0, is visible to the cldevice list -v command.
The ZFS storage pool can be created using a full disk or a disk slice. It is preferred to create a ZFS storage pool using a full disk by specifying a Solaris logical device as ZFS file system performs better by enabling the disk write cache. ZFS file system labels the disk with EFI when a full disk is provided.
See Creating a ZFS Storage Pool in Solaris ZFS Administration Guide for information about how to create a ZFS storage pool.
In the ZFS storage pool that you just created, create a ZFS file system.
You can create more than one ZFS file system in the same ZFS storage pool.
HAStoragePlus does not support file systems created on ZFS file system volumes.
Do not place a ZFS file system in the FilesystemMountPoints extension property.
See Creating a ZFS File System Hierarchy in Solaris ZFS Administration Guide for information about how to create a ZFS file system in a ZFS storage pool.
On any node in the cluster, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Create a failover resource group.
# clresourcegroup create resource-group |
Register the HAStoragePlus resource type.
# clresourcetype register SUNW.HAStoragePlus |
Create an HAStoragePlus resource for the local ZFS file system.
# clresource create -g resource-group -t SUNW.HAStoragePlus \ -p Zpools=zpool -p ZpoolsSearchDir=/dev/did/dsk \ resource |
The default location to search for devices of ZFS storage pools is /dev/dsk. It can be overridden by using the ZpoolsSearchDir extension property.
The resource is created in the enabled state.
Bring online and in a managed state the resource group that contains the HAStoragePlus resource.
# clresourcegroup online -M resource-group |
The following example shows the commands to make a local ZFS file system highly available.
phys-schost-1% su Password: # cldevice list -v DID Device Full Device Path ---------- ---------------- d1 phys-schost-1:/dev/rdsk/c0t0d0 d2 phys-schost-1:/dev/rdsk/c0t1d0 d3 phys-schost-1:/dev/rdsk/c1t8d0 d3 phys-schost-2:/dev/rdsk/c1t8d0 d4 phys-schost-1:/dev/rdsk/c1t9d0 d4 phys-schost-2:/dev/rdsk/c1t9d0 d5 phys-schost-1:/dev/rdsk/c1t10d0 d5 phys-schost-2:/dev/rdsk/c1t10d0 d6 phys-schost-1:/dev/rdsk/c1t11d0 d6 phys-schost-2:/dev/rdsk/c1t11d0 d7 phys-schost-2:/dev/rdsk/c0t0d0 d8 phys-schost-2:/dev/rdsk/c0t1d0 you can create a ZFS storage pool using a disk slice by specifying a Solaris device identifier: # zpool create HAzpool c1t8d0s2 or you can create a ZFS storage pool using disk slice by specifying a logical device identifier # zpool create HAzpool /dev/did/dsk/d3s2 # zfs create HAzpool/export # zfs create HAzpool/export/home # clresourcegroup create hasp-rg # clresourcetype register SUNW.HAStoragePlus # clresource create -g hasp-rg -t SUNW.HAStoragePlus \ -p Zpools=HAzpool hasp-rs # clresourcegroup online -M hasp-rg |
The following example shows the steps to make a local ZFS file system highly available in a zone cluster sczone.
phys-schost-1# cldevice list -v # zpool create HAzpool c1t8d0 # zfs create HAzpool/export # zfs create HAzpool/export/home # clzonecluster configure sczone clzc:sczone> add dataset clzc:sczone:fs> set name=HAzpool clzc:sczone:fs> end clzc:sczone:fs> exit # clresourcegroup create -Z sczone hasp-rg # clresourcetype register -Z sczone SUNW.HAStoragePlus # clresource create -Z sczone -g hasp-rg \ -t SUNW.HAStoragePlus -p Zpools=HAzpool hasp-rs # clresourcegroup online -Z -sczone -M hasp-rg |
Disable and delete the HAStoragePlus resource that makes a local Solaris ZFS (Zettabyte File System) highly available.
# clresource delete -F -g resource-group -t SUNW.HAStoragePlus resource |
HAStorage is not supported in the current release of Sun Cluster software. Equivalent functionality is supported by HAStoragePlus. For instructions for upgrading from HAStorage to HAStorage, see the subsections that follow.
The resource groups that have the HAStorage resource configured will be in STOP_FAILED state since HAStorage is no longer supported. Clear the ERROR_STOP_FAILED flag for the resource and follow the instructions to upgrade HAStorage to HAStoragePlus.
The following example uses a simple HA-NFS resource that is active with HAStorage. The ServicePaths are the disk group nfsdg and the AffinityOn property is True. Furthermore, the HA-NFS resource has Resource_Dependencies set to the HAStorage resource.
Bring offline the resource group nfs1-rg.
# clresourcegroup offline nfs1-rg |
Remove the dependencies the application resources has on HAStorage.
# clresource set -p Resource_Dependencies="" nfsserver-rs |
Disable the HAStorage resource.
# clresource disable nfs1storage-rs |
Remove the HAStorage resource from the application resource group.
# clresource delete nfs1storage-rs |
Unregister the HAStorage resource type.
# clresourcetype unregister SUNW.HAStorage |
Register the HAStoragePlus resource type.
# clresourcetype register SUNW.HAStoragePlus |
Create the HAStoragePlus resource.
Instead of using the ServicePaths property of HAStorage, you must use the FilesystemMountPoints property or GlobalDevicePaths property of HAStoragePlus.
To specify the mount point of a file system, type the following command.
The FilesystemMountPoints extension property must match the sequence that is specified in /etc/vfstab.
# clresource create -g nfs1-rg -t \ SUNW.HAStoragePlus -p FilesystemMountPoints=/global/nfsdata -p \ AffinityOn=True nfs1-hastp-rs |
To specify global device paths, type the following command.
# clresource create -g nfs1-rg -t \ SUNW.HAStoragePlus -p GlobalDevicePaths=nfsdg -p AffinityOn=True nfs1-hastp-rs |
The resource is created in the enabled state.
Disable the application server resource.
# clresource disable nfsserver-rs |
Bring online the nfs1-rg group on a cluster node.
# clresourcegroup online nfs1-rg |
Set up the dependencies between the application server and HAStoragePlus.
# clresource set -p Resource_dependencies=nfs1-hastp-rs nfsserver-rs |
Bring online the nfs1-rg group on a cluster node.
# clresourcegroup online -eM nfs1-rg |
The following example uses a simple HA-NFS resource that is active with HAStorage. The ServicePaths are the disk group nfsdg and the AffinityOn property is True. Furthermore, the HA-NFS resource has Resource_Dependencies set to HAStorage resource.
Remove the dependencies the application resource has on HAStorage resource.
# clresource set -p Resource_Dependencies="" nfsserver-rs |
Disable the HAStorage resource.
# clresource disable nfs1storage-rs |
Remove the HAStorage resource from the application resource group.
# clresource delete nfs1storage-rs |
Unregister the HAStorage resource type.
# clresourcetype unregister SUNW.HAStorage |
Modify /etc/vfstab to remove the global flag and change “mount at boot” to “no”.
Create the HAStoragePlus resource.
Instead of using the ServicePaths property of HAStorage, you must use the FilesystemMountPoints property or GlobalDevicePaths property of HAStoragePlus.
To specify the mount point of a file system, type the following command.
The FilesystemMountPoints extension property must match the sequence that is specified in /etc/vfstab.
# clresource create -g nfs1-rg -t \ SUNW.HAStoragePlus -p FilesystemMountPoints=/global/nfsdata -p \ AffinityOn=True nfs1-hastp-rs |
To specify global device paths, type the following command.
# clresource create -g nfs1-rg -t \ SUNW.HAStoragePlus -p GlobalDevicePaths=nfsdg -p AffinityOn=True nfs1-hastp-rs |
The resource is created in the enabled state.
Disable the application server resource.
# clresource disable nfsserver-rs |
Bring online the nfs1-rg group on a cluster node.
# clresourcegroup online nfs1-rg |
Set up the dependencies between the application server and HAStoragePlus.
# clresource set -p Resource_dependencies=nfs1-hastp-rs nfsserver-rs |
Bring online the nfs1-rg group on a cluster node.
# clresourcegroup online -eM nfs1-rg |
You might need a highly available file system to remain available while you are modifying the resource that represents the file system. For example, you might need the file system to remain available because storage is being provisioned dynamically. In this situation, modify the resource that represents the highly available file system while the resource is online.
In the Sun Cluster environment, a highly available file system is represented by an HAStoragePlus resource. Sun Cluster enables you to modify an online HAStoragePlus resource as follows:
Adding file systems to the HAStoragePlus resource
Removing file systems from the HAStoragePlus resource
Sun Cluster software does not enable you to rename a file system while the file system is online.
When you remove the file systems configured in the HAStoragePlus resources for a zone cluster, you also need to remove the file system configuration from the zone cluster. For information about removing a file system from a zone cluster, seeHow to Remove a File System From a Zone Cluster in Sun Cluster System Administration Guide for Solaris OS.
When you add a local or cluster file system to an HAStoragePlus resource, the HAStoragePlus resource automatically mounts the file system.
On one node of the cluster, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
In the /etc/vfstab file on each node of the cluster, add an entry for the mount point of each file system that you are adding.
For each entry, set the mount at boot field and the mount options field as follows:
Retrieve the list of mount points for the file systems that the HAStoragePlus resource already manages.
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints |
Specifies the HAStoragePlus resource to which you are adding file systems
Specifies the resource group that contains the HAStoragePlus resource
Modify the FileSystemMountPoints extension property of the HAStoragePlus resource to contain the following mount points:
The mount points of the file systems that the HAStoragePlus resource already manages
The mount points of the file systems that you are adding to the HAStoragePlus resource
# clresource set -p FileSystemMountPoints="mount-point-list" hasp-resource |
Specifies a comma-separated list of mount points of the file systems that the HAStoragePlus resource already manages and the mount points of the file systems that you are adding. The format of each entry in the list is LocalZonePath:GlobalZonePathvooz. In this format, the global path is optional. If the global path is not specified, the global path is the same as the local path.
Specifies the HAStoragePlus resource to which you are adding file systems.
Confirm that you have a match between the mount point list of the HAStoragePlus resource and the list that you specified in Step 4.
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints |
Specifies the HAStoragePlus resource to which you are adding file systems.
Specifies the resource group that contains the HAStoragePlus resource.
Confirm that the HAStoragePlus resource is online and not faulted.
If the HAStoragePlus resource is online and faulted, validation of the resource succeeded, but an attempt by HAStoragePlus to mount a file system failed.
# clresource status hasp-resource |
This example shows how to add a file system to an online HAStoragePlus resource.
The HAStoragePlus resource is named rshasp and is contained in the resource group rghasp.
The HAStoragePlus resource named rshasp already manages the file system whose mount point is /global/global-fs/fs.
The mount point of the file system that is to be added is /global/local-fs/fs.
The example assumes that the /etc/vfstab file on each cluster node already contains an entry for the file system that is to be added.
# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints STRINGARRAY /global/global-fs/fs # clresource set \ -p FileSystemMountPoints="/global/global-fs/fs,/global/local-fs/fs" # scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints rshasp STRINGARRAY /global/global-fs/fs /global/local-fs/fs # clresource status rshasp === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- -------- rshasp node46 Offline Offline node47 Online Online |
When you remove a file system from an HAStoragePlus resource, the HAStoragePlus resource treats a local file system differently from a cluster file system.
The HAStoragePlus resource automatically unmounts a local file system.
The HAStoragePlus resource does not unmount thecluster file system.
Before removing a file system from an online HAStoragePlus resource, ensure that no applications are using the file system. When you remove a file system from an online HAStoragePlus resource, the file system might be forcibly unmounted. If a file system that an application is using is forcibly unmounted, the application might fail or hang.
On one node of the cluster, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Retrieve the list of mount points for the file systems that the HAStoragePlus resource already manages.
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints |
Specifies the HAStoragePlus resource from which you are removing file systems.
Specifies the resource group that contains the HAStoragePlus resource.
Modify the FileSystemMountPoints extension property of the HAStoragePlus resource to contain only the mount points of the file systems that are to remain in the HAStoragePlus resource.
# clresource set -p FileSystemMountPoints="mount-point-list" hasp-resource |
Specifies a comma-separated list of mount points of the file systems that are to remain in the HAStoragePlus resource. This list must not include the mount points of the file systems that you are removing.
Specifies the HAStoragePlus resource from which you are removing file systems.
Confirm that you have a match between the mount point list of the HAStoragePlus resource and the list that you specified in Step 3.
# scha_resource_get -O extension -R hasp-resource -G hasp-rg \ FileSystemMountPoints |
Specifies the HAStoragePlus resource from which you are removing file systems.
Specifies the resource group that contains the HAStoragePlus resource.
Confirm that the HAStoragePlus resource is online and not faulted.
If the HAStoragePlus resource is online and faulted, validation of the resource succeeded, but an attempt by HAStoragePlus to unmount a file system failed.
# clresource status hasp-resource |
(Optional) From the /etc/vfstab file on each node of the cluster, remove the entry for the mount point of each file system that you are removing.
This example shows how to remove a file system from an online HAStoragePlus resource.
The HAStoragePlus resource is named rshasp and is contained in the resource group rghasp.
The HAStoragePlus resource named rshasp already manages the file systems whose mount points are as follows:
/global/global-fs/fs
/global/local-fs/fs
The mount point of the file system that is to be removed is /global/local-fs/fs.
# scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints STRINGARRAY /global/global-fs/fs /global/local-fs/fs # clresource set -p FileSystemMountPoints="/global/global-fs/fs" # scha_resource_get -O extension -R rshasp -G rghasp FileSystemMountPoints rshasp STRINGARRAY /global/global-fs/fs # clresource status rshasp === Cluster Resources === Resource Name Node Name Status Message -------------- ---------- ------- -------- rshasp node46 Offline Offline node47 Online Online |
When you add a Solaris ZFS (Zettabyte File System) storage pool to an online HAStoragePlus resource, the HAStoragePlus resource does the following:
Imports the ZFS storage pool.
Mounts all file systems in the ZFS storage pool.
On any node in the cluster, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Determine the ZFS storage pools that the HAStoragePlus resource already manages.
# clresource show -g hasp-resource-group -p Zpools hasp-resource |
Specifies the resource group that contains the HAStoragePlus resource.
Specifies the HAStoragePlus resource to which you are adding the ZFS storage pool.
Add the new ZFS storage pool to the existing list of ZFS storage pools that the HAStoragePlus resource already manages.
# clresource set -p Zpools="zpools-list" hasp-resource |
Specifies a comma-separated list of existing ZFS storage pool names that the HAStoragePlus resource already manages and the new ZFS storage pool name that you want to add.
Specifies the HAStoragePlus resource to which you are adding the ZFS storage pool.
Compare the new list of ZFS storage pools that the HAStoragePlus resource manages with the list that you generated in Step 2.
# clresource show -g hasp-resource-group -p Zpools hasp-resource |
Specifies the resource group that contains the HAStoragePlus resource.
Specifies the HAStoragePlus resource to which you added the ZFS storage pool.
Confirm that the HAStoragePlus resource is online and not faulted.
If the HAStoragePlus resource is online but faulted, validation of the resource succeeded. However, an attempt by the HAStoragePlus resource to import and mount the ZFS file system failed. In this case, you need to repeat the preceding set of steps.
# clresourcegroup status hasp-resource |
When you remove a Solaris ZFS (Zettabyte File System) storage pool from an online HAStoragePlus resource, the HAStoragePlus resource does the following:
Unmounts the file systems in the ZFS storage pool.
Exports the ZFS storage pool from the node.
On any node in the cluster, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Determine the ZFS storage pools that the HAStoragePlus resource already manages.
# clresource show -g hasp-resource-group -p Zpools hasp-resource |
Specifies the resource group that contains the HAStoragePlus resource.
Specifies the HAStoragePlus resource from which you are removing the ZFS storage pool.
Remove the ZFS storage pool from the list of ZFS storage pools that the HAStoragePlus resource currently manages.
# clresource set -p Zpools="zpools-list" hasp-resource |
Specifies a comma-separated list of ZFS storage pool names that the HAStoragePlus resource currently manages, minus the ZFS storage pool name that you want to remove.
Specifies the HAStoragePlus resource from which you are removing the ZFS storage pool.
Compare the new list of ZFS storage pools that the HAStoragePlus resource now manages with the list that you generated in Step 2.
# clresource show -g hasp-resource-group -p Zpools hasp-resource |
Specifies the resource group that contains the HAStoragePlus resource.
Specifies the HAStoragePlus resource from which you removed the ZFS storage pool.
Confirm that the HAStoragePlus resource is online and not faulted.
If the HAStoragePlus resource is online but faulted, validation of the resource succeeded. However, an attempt by the HAStoragePlus resource to unmount and export the ZFS file system failed. In this case, you need to repeat the preceding set of steps.
# clresourcegroup status SUNW.HAStoragePlus + |
If a fault occurs during a modification of the FileSystemMountPoints extension property, the status of the HAStoragePlus resource is online and faulted. After the fault is corrected, the status of the HAStoragePlus resource is online.
Determine the fault that caused the attempted modification to fail.
# clresource status hasp-resource |
The status message of the faulty HAStoragePlus resource indicates the fault. Possible faults are as follows:
The device on which the file system should reside does not exist.
An attempt by the fsck command to repair a file system failed.
The mount point of a file system that you attempted to add does not exist.
A file system that you attempted to add cannot be mounted.
A file system that you attempted to remove cannot be unmounted.
Correct the fault that caused the attempted modification to fail.
Repeat the step to modify the FileSystemMountPoints extension property of the HAStoragePlus resource.
# clresource set -p FileSystemMountPoints="mount-point-list" hasp-resource |
Specifies a comma-separated list of mount points that you specified in the unsuccessful attempt to modify the highly available file system
Specifies the HAStoragePlus resource that you are modifying
Confirm that the HAStoragePlus resource is online and not faulted.
# clresource status |
This example shows the status of a faulty HAStoragePlus resource. This resource is faulty because an attempt by the fsck command to repair a file system failed.
# clresource status === Cluster Resources === Resource Name Node Name Status Status Message -------------- ---------- ------- ------------- rshasp node46 Offline Offline node47 Online Online Faulted - Failed to fsck: /mnt. |
If a fault occurs during a modification of the Zpools extension property, the status of the HAStoragePlus resource is online and faulted. After the fault is corrected, the status of the HAStoragePlus resource is online.
Determine the fault that caused the attempted modification to fail.
# clresource status hasp-resource |
The status message of the faulty HAStoragePlus resource indicates the fault. Possible faults are as follows:
The ZFS pool zpool failed to import.
The ZFS pool zpool failed to export.
Correct the fault that caused the attempted modification to fail.
Repeat the step to modify the Zpools extension property of the HAStoragePlus resource.
# clresource set -p Zpools="zpools-list" hasp-resource |
Specifies a comma-separated list of ZFS storage pool names that the HAStoragePlus currently manages, minus the ZFS storage pool name that you want to remove.
Specifies the HAStoragePlus resource that you are modifying
Confirm that the HAStoragePlus resource is online and not faulted.
# clresource status |
This example shows the status of a faulty HAStoragePlus resource. This resource is faulty because the ZFS pool zpool failed to import.
# clresource status hasp-resource === Cluster Resources === Resource Name Node Name Status Status Message -------------- ---------- ------- ------------- hasp-resource node46 Online Faulted - Failed to import:hazpool node47 Offline Offline |
You can change the file system of an HAStoragePlus resource from a cluster file system to a local file system.
Bring the failover resource group offline.
# clresourcegroup offline resource-group |
Display the HAStoragePlus resource.
# clresource show -g resource-group -t SUNW.HAStoragePlus |
Retrieve the list of mount points for each resource.
# clresource show -p FilesystemMountPoints hastorageplus-resource |
Unmount the cluster file system.
# umount mount-points |
Modify the /etc/vfstab entry of the mount points on all the nodes configured in the node list of the resource group.
Repeat the steps for all the cluster file systems of all the HAStoragePlus resources configured in the resource group.
Bring the resource group online.
# clresourcegroup online -M resource-group |
In Sun Cluster 3.1 9/04, the HAStoragePlus resource type is enhanced to enable you to modify highly available file systems online. Upgrade the HAStoragePlus resource type if all conditions in the following list apply:
You are upgrading from an earlier version of Sun Cluster.
You need to use the new features of the HAStoragePlus resource type.
For general instructions that explain how to upgrade a resource type, see Upgrading a Resource Type. The information that you need to complete the upgrade of the HAStoragePlus resource type is provided in the subsections that follow.
The relationship between a resource type version and the release of Sun Cluster is shown in the following table. The release of Sun Cluster indicates the release in which the version of the resource type was introduced.
Resource Type Version |
Sun ClusterRelease |
---|---|
1.0 |
3.0 5/02 |
2 |
3.1 9/04 |
4 |
3.2 |
6 |
3.2 2/08 |
To determine the version of the resource type that is registered, use one command from the following list:
clresourcetype list
clresourcetype list -v
The RTR file for this resource type is /usr/cluster/lib/rgm/rtreg/SUNW.HAStoragePlus.
The information that you need to migrate instances of the HAStoragePlus resource type is as follows:
You can perform the migration at any time.
If you need to use the new features of the HAStoragePlus resource type, the required value of the Type_version property is 4.
For maximum availability or optimum performance, some combinations of services require a specific distribution of online resource groups among cluster nodes. Distributing online resource groups involves creating affinities between resource groups for the following purposes:
Enforcing the required distribution when the resource groups are first brought online
Preserving the required distribution after an attempt to fail over or switch over a resource group
This section provides the following examples of how to use resource group affinities to distribute online resource groups among cluster nodes:
Enforcing collocation of a resource group with another resource group
Specifying a preferred collocation of a resource group with another resource group
Balancing the load of a set of resource groups
Specifying that a critical service has precedence
Delegating the failover or switchover of a resource group
Combining affinities between resource groups to specify more complex behavior
An affinity between resource groups restricts on which nodes the resource groups may be brought online simultaneously. In each affinity, a source resource group declares an affinity for a target resource group or several target resource groups. To create an affinity between resource groups, set the RG_affinities resource group property of the source as follows:
-p RG_affinities=affinity-list |
Specifies a comma-separated list of affinities between the source resource group and a target resource group or several target resource groups. You may specify a single affinity or more than one affinity in the list.
Specify each affinity in the list as follows:
operator target-rg |
Do not include a space between operator and target-rg.
Specifies the type of affinity that you are creating. For more information, see Table 2–2.
Specifies the resource group that is the target of the affinity that you are creating.
Operator |
Affinity Type |
Effect |
---|---|---|
+ |
If possible, the source is brought online on a node or on nodes where the target is online or starting. However, the source and the target are allowed to be online on different nodes. |
|
++ |
The source is brought online only on a node or on nodes where the target is online or starting. The source and the target are not allowed to be online on different nodes. |
|
- |
If possible, the source is brought online on a node or on nodes where the target is not online or starting. However, the source and the target are allowed to be online on the same node. |
|
-- |
The source is brought online only on a node or on nodes where the target is not online. The source and the target are not allowed to be online on the same node. |
|
+++ |
Same as strong positive, except that an attempt by the source to fail over is delegated to the target. For more information, see Delegating the Failover or Switchover of a Resource Group. |
Weak affinities take precedence over Nodelist preference ordering.
The current state of other resource groups might prevent a strong affinity from being satisfied on any node. In this situation, the resource group that is the source of the affinity remains offline. If other resource groups' states change to enable the strong affinities to be satisfied, the resource group that is the source of the affinity comes back online.
Use caution when declaring a strong affinity on a source resource group for more than one target resource group. If all declared strong affinities cannot be satisfied, the source resource group remains offline.
A service that is represented by one resource group might depend so strongly on a service in a second resource group that both services must run on the same node. For example, an application that is comprised of multiple interdependent service daemons might require that all daemons run on the same node.
In this situation, force the resource group of the dependent service to be collocated with the resource group of the other service. To enforce collocation of a resource group with another resource group, declare on the resource group a strong positive affinity for the other resource group.
# clresourcegroup set|create -p RG_affinities=++target-rg source-rg |
Specifies the resource group that is the source of the strong positive affinity. This resource group is the resource group on which you are declaring a strong positive affinity for another resource group.
Specifies the resource group that is the target of the strong positive affinity. This resource group is the resource group for which you are declaring a strong positive affinity.
A resource group follows the resource group for which it has a strong positive affinity. If the target resource group is relocated to a different node, the source resource group automatically switches to the same node as the target. However, a resource group that declares a strong positive affinity is prevented from failing over to a node on which the target of the affinity is not already running.
Only failovers that are initiated by a resource monitor are prevented. If a node on which the source resource group and target resource group are running fails, both resource groups fail over to the same surviving node.
For example, a resource group rg1 declares a strong positive affinity for resource group rg2. If rg2 fails over to another node, rg1 also fails over to that node. This failover occurs even if all the resources in rg1 are operational. However, if a resource in rg1 attempts to fail over rg1 to a node where rg2 is not running, this attempt is blocked.
The source of a strong positive affinity might be offline on all nodes when you bring online the target of the strong positive affinity. In this situation, the source of the strong positive affinity is automatically brought online on the same node as the target.
For example, a resource group rg1 declares a strong positive affinity for resource group rg2. Both resource groups are initially offline on all nodes. If an administrator brings online rg2 on a node, rg1 is automatically brought online on the same node.
You can use the clresourcegroup suspend command to prevent a resource group from being brought online automatically due to strong affinities or cluster reconfiguration.
If you require a resource group that declares a strong positive affinity to be allowed to fail over, you must delegate the failover. For more information, see Delegating the Failover or Switchover of a Resource Group.
This example shows the command for modifying resource group rg1 to declare a strong positive affinity for resource group rg2. As a result of this affinity relationship, rg1 is brought online only on nodes where rg2 is running. This example assumes that both resource groups exist.
# clresourcegroup set -p RG_affinities=++rg2 rg1 |
A service that is represented by one resource group might use a service in a second resource group. As a result, these services run most efficiently if they run on the same node. For example, an application that uses a database runs most efficiently if the application and the database run on the same node. However, the services can run on different nodes because the reduction in efficiency is less disruptive than additional failovers of resource groups.
In this situation, specify that both resource groups should be collocated if possible. To specify preferred collocation of a resource group with another resource group, declare on the resource group a weak positive affinity for the other resource group.
# clresourcegroup set|create -p RG_affinities=+target-rg source-rg |
Specifies the resource group that is the source of the weak positive affinity. This resource group is the resource group on which you are declaring a weak positive affinity for another resource group.
Specifies the resource group that is the target of the weak positive affinity. This resource group is the resource group for which you are declaring a weak positive affinity.
By declaring a weak positive affinity on one resource group for another resource group, you increase the probability of both resource groups running on the same node. The source of a weak positive affinity is first brought online on a node where the target of the weak positive affinity is already running. However, the source of a weak positive affinity does not fail over if a resource monitor causes the target of the affinity to fail over. Similarly, the source of a weak positive affinity does not fail over if the target of the affinity is switched over. In both situations, the source remains online on the node where the source is already running.
If a node on which the source resource group and target resource group are running fails, both resource groups are restarted on the same surviving node.
This example shows the command for modifying resource group rg1 to declare a weak positive affinity for resource group rg2. As a result of this affinity relationship, rg1 and rg2 are first brought online on the same node. But if a resource in rg2 causes rg2 to fail over, rg1 remains online on the node where the resource groups were first brought online. This example assumes that both resource groups exist.
# clresourcegroup set -p RG_affinities=+rg2 rg1 |
Each resource group in a set of resource groups might impose the same load on the cluster. In this situation, by distributing the resource groups evenly among cluster nodes, you can balance the load on the cluster.
To distribute a set of resource groups evenly among cluster nodes, declare on each resource group a weak negative affinity for the other resource groups in the set.
# clresourcegroup set|create -p RG_affinities=neg-affinity-list source-rg |
Specifies the resource group that is the source of the weak negative affinity. This resource group is the resource group on which you are declaring a weak negative affinity for other resource groups.
Specifies a comma-separated list of weak negative affinities between the source resource group and the resource groups that are the target of the weak negative affinity. The target resource groups are the resource groups for which you are declaring a weak negative affinity.
By declaring a weak negative affinity on one resource group for other resource groups, you ensure that a resource group is always brought online on the most lightly loaded node in the cluster. The fewest other resource groups are running on that node. Therefore, the smallest number of weak negative affinities are violated.
This example shows the commands for modifying resource groups rg1, rg2, rg3, and rg4 to ensure that these resource groups are evenly distributed among the available nodes in the cluster. This example assumes that resource groups rg1, rg2, rg3, and rg4 exist.
# clresourcegroup set -p RG_affinities=-rg2,-rg3,-rg4 rg1 # clresourcegroup set -p RG_affinities=-rg1,-rg3,-rg4 rg2 # clresourcegroup set -p RG_affinities=-rg1,-rg2,-rg4 rg3 # clresourcegroup set -p RG_affinities=-rg1,-rg2,-rg3 rg4 |
A cluster might be configured to run a combination of mission-critical services and noncritical services. For example, a database that supports a critical customer service might run in the same cluster as noncritical research tasks.
To ensure that the noncritical services do not affect the performance of the critical service, specify that the critical service has precedence. By specifying that the critical service has precedence, you prevent noncritical services from running on the same node as the critical service.
When all nodes are operational, the critical service runs on a different node from the noncritical services. However, a failure of the critical service might cause the service to fail over to a node where the noncritical services are running. In this situation, the noncritical services are taken offline immediately to ensure that the computing resources of the node are fully dedicated to the mission-critical service.
To specify that a critical service has precedence, declare on the resource group of each noncritical service a strong negative affinity for the resource group that contains the critical service.
# clresourcegroup set|create -p RG_affinities=--critical-rg noncritical-rg |
Specifies the resource group that contains a noncritical service. This resource group is the resource group on which you are declaring a strong negative affinity for another resource group.
Specifies the resource group that contains the critical service. This resource group is the resource group for which you are declaring a strong negative affinity.
A resource group moves away from a resource group for which it has a strong negative affinity.
The source of a strong negative affinity might be offline on all nodes when you take offline the target of the strong negative affinity. In this situation, the source of the strong negative affinity is automatically brought online. In general, the resource group is brought online on the most preferred node, based on the order of the nodes in the node list and the declared affinities.
For example, a resource group rg1 declares a strong negative affinity for resource group rg2. Resource group rg1 is initially offline on all nodes, while resource group rg2 is online on a node. If an administrator takes offline rg2, rg1 is automatically brought online.
You can use the clresourcegroup suspend command to prevent the source of a strong negative affinity from being brought online automatically due to strong affinities or cluster reconfiguration.
This example shows the commands for modifying the noncritical resource groups ncrg1 and ncrg2 to ensure that the critical resource group mcdbrg has precedence over these resource groups. This example assumes that resource groups mcdbrg, ncrg1, and ncrg2 exist.
# clresourcegroup set -p RG_affinities=--mcdbrg ncrg1 ncrg2 |
The source resource group of a strong positive affinity cannot fail over or be switched over to a node where the target of the affinity is not running. If you require the source resource group of a strong positive affinity to be allowed to fail over or be switched over, you must delegate the failover to the target resource group. When the target of the affinity fails over, the source of the affinity is forced to fail over with the target.
You might need to switch over the source resource group of a strong positive affinity that is specified by the ++ operator. In this situation, switch over the target of the affinity and the source of the affinity at the same time.
To delegate failover or switchover of a resource group to another resource group, declare on the resource group a strong positive affinity with failover delegation for the other resource group.
# clresourcegroup set|create source-rg -p RG_affinities=+++target-rg |
Specifies the resource group that is delegating failover or switchover. This resource group is the resource group on which you are declaring a strong positive affinity with failover delegation for another resource group.
Specifies the resource group to which source-rg delegates failover or switchover. This resource group is the resource group for which you are declaring a strong positive affinity with failover delegation.
A resource group may declare a strong positive affinity with failover delegation for at most one resource group. However, a given resource group may be the target of strong positive affinities with failover delegation that are declared by any number of other resource groups.
A strong positive affinity with failover delegation is not fully symmetric. The target can come online while the source remains offline. However, if the target is offline, the source cannot come online.
If the target declares a strong positive affinity with failover delegation for a third resource group, failover or switchover is further delegated to the third resource group. The third resource group performs the failover or switchover, forcing the other resource groups to fail over or be switched over also.
This example shows the command for modifying resource group rg1 to declare a strong positive affinity with failover delegation for resource group rg2. As a result of this affinity relationship, rg1 delegates failover or switchover to rg2. This example assumes that both resource groups exist.
# clresourcegroup set -p RG_affinities=+++rg2 rg1 |
You can create more complex behaviors by combining multiple affinities. For example, the state of an application might be recorded by a related replica server. The node selection requirements for this example are as follows:
The replica server must run on a different node from the application.
If the application fails over from its current node, the application should fail over to the node where the replica server is running.
If the application fails over to the node where the replica server is running, the replica server must fail over to a different node. If no other node is available, the replica server must go offline.
You can satisfy these requirements by configuring resource groups for the application and the replica server as follows:
The resource group that contains the application declares a weak positive affinity for the resource group that contains the replica server.
The resource group that contains the replica server declares a strong negative affinity for the resource group that contains the application.
This example shows the commands for combining affinities between the following resource groups.
Resource group app-rg represents an application whose state is tracked by a replica server.
Resource group rep-rg represents the replica server.
In this example, the resource groups declare affinities as follows:
Resource group app-rg declares a weak positive affinity for resource group rep-rg.
Resource group rep-rg declares a strong negative affinity for resource group app-rg.
This example assumes that both resource groups exist.
# clresourcegroup set -p RG_affinities=+rep-rg app-rg # clresourcegroup set -p RG_affinities=--app-rg rep-rg |
The cluster administrator can specify affinities between a resource group in a zone cluster and another resource group in a zone cluster or a resource group on the global cluster.
You can use the following command to specify the affinity between resource groups in zone clusters.
# clresourcegroup set -p RG_affinities=affinity-typetarget-zc:target-rg source-zc:source-rg |
The resource group affinity types in a zone cluster can be one of the following:
+ (weak positive)
++ (strong positive)
- (weak negative)
-- (strong negative)
The affinity type +++ is not supported for zone clusters in this release.
This example shows the command for specifying a strong positive affinity between resource groups in zone clusters.
The resource group RG1 in a zone cluster ZC1 declares a strong positive affinity for a resource group RG2 in a zone cluster ZC2.
If you need to specify a strong positive affinity between a resource group RG1 in a zone cluster ZC1 and a resource group RG2 in another zone cluster ZC2, use the following command:
# clresourcegroup set -p RG_affinities=++ZC2:RG2 ZC1:RG1 |
This example shows the command for specifying a strong negative affinity between resource groups in zone clusters. If you need to specify a strong negative affinity between a resource group RG1 in a zone cluster ZC1 and a resource group RG2 in the global cluster, use the following command:
# clresourcegroup set -p RG_affinities=--global:RG2 ZC1:RG1 |
If you require identical resource configuration data on two clusters, you can replicate the data to the second cluster to save the laborious task of setting it up again. Use scsnapshot to propagate the resource configuration information from one cluster to another cluster. To save effort, ensure that your resource-related configuration is stable and you do not need to make any major changes to the resource configuration, before copying the information to a second cluster.
Configuration data for resource groups, resource types, and resources can be retrieved from the Cluster Configuration Repository (CCR) and formatted as a shell script. The script can be used to perform the following tasks:
Replicate configuration data on a cluster that does not have configured resource groups, resource types, or resources
Upgrade configuration data on a cluster that has configured resource groups, resource types, and resources
The scsnapshot tool retrieves configuration data that is stored in the CCR. Other configuration data are ignored. The scsnapshot tool ignores the dynamic state of different resource groups, resource types, and resources.
This procedure replicates configuration data on a cluster that does not have configured resource groups, resource types, and resources. In this procedure, a copy of the configuration data is taken from one cluster and used to generate the configuration data on another cluster.
Using the system administrator role, log in to any node in the cluster from which you want to copy the configuration data.
For example, node1.
The system administrator role gives you the following role-based access control (RBAC) rights:
solaris.cluster.resource.read
solaris.cluster.resource.modify
Retrieve the configuration data from the cluster.
node1 % scsnapshot -s scriptfile |
The scsnapshot tool generates a script called scriptfile. For more information about using the scsnapshot tool, see the scsnapshot(1M) man page.
Edit the script to adapt it to the specific features of the cluster where you want to replicate the configuration data.
For example, you might have to change the IP addresses and host names that are listed in the script.
Launch the script from any node in the cluster where you want to replicate the configuration data.
The script compares the characteristics of the local cluster to the cluster where the script was generated. If the characteristics are not the same, the script writes an error and ends. A message asks whether you want to rerun the script, using the -f option. The -f option forces the script to run, despite any difference in characteristics. If you use the -f option, ensure that you do not create inconsistencies in your cluster.
The script verifies that the Sun Cluster resource type exists on the local cluster. If the resource type does not exist on the local cluster, the script writes an error and ends. A message asks whether you want to install the missing resource type before running the script again.
This procedure upgrades configuration data on a cluster that already has configured resource groups, resource types, and resources. This procedure can also be used to generate a configuration template for resource groups, resource types, and resources.
In this procedure, the configuration data on cluster1 is upgraded to match the configuration data on cluster2.
Using the system administrator role, log on to any node in cluster1.
For example, node1.
The system administrator role gives you the following RBAC rights:
solaris.cluster.resource.read
solaris.cluster.resource.modify
Retrieve the configuration data from the cluster by using the image file option of the scsnapshot tool:
node1% scsnapshot -s scriptfile1 -o imagefile1 |
When run on node1, the scsnapshot tool generates a script that is called scriptfile1. The script stores configuration data for the resource groups, resource types, and resources in an image file that is called imagefile1. For more information about using the scsnapshot tool, see the scsnapshot(1M) man page.
Repeat Step 1 through Step 2 on a node in cluster2:
node2 % scsnapshot -s scriptfile2 -o imagefile2 |
On node1, generate a script to upgrade the configuration data on cluster1 with configuration data from cluster2:
node1 % scsnapshot -s scriptfile3 imagefile1 imagefile2 |
This step uses the image files that you generated in Step 2 and Step 3, and generates a new script that is called scriptfile3.
Edit the script that you generated in Step 4 to adapt it to the specific features of the cluster1, and to remove data specific to cluster2.
From node1, launch the script to upgrade the configuration data.
The script compares the characteristics of the local cluster to the cluster where the script was generated. If the characteristics are not the same, the script writes an error and ends. A message asks whether you want to rerun the script, using the -f option. The -f option forces the script to run, despite any difference in characteristics. If you use the -f option, ensure that you do not create inconsistencies in your cluster.
The script verifies that the Sun Cluster resource type exists on the local cluster. If the resource type does not exist on the local cluster, the script writes an error and ends. A message asks whether you want to install the missing resource type before running the script again.
The Service Management Facility (SMF) enables you to automatically start and restart SMF services, during a node boot or service failure. SMF facilitates some degree of high availability to the SMF services on a single host. This feature is similar to the Sun Cluster Resource Group Manager (RGM), which facilitates high availability and scalability for cluster applications. SMF services and RGM features are complementary to each other.
Sun Cluster includes three new SMF proxy resource types that can be used to enable SMF services to run with Sun Cluster in a failover, multi-master, or scalable configuration. The following are the proxy resource types:
SUNW.Proxy_SMF_failover
SUNW.Proxy_SMF_multimaster
SUNW.Proxy_SMF_scalable
The SMF proxy resource types enables you to encapsulate a set of interrelated SMF services into a single resource, SMF proxy resource to be managed by Sun Cluster. In this feature, SMF manages the availability of SMF services on a single node. Sun Cluster provides cluster-wide high availability and scalability of the SMF services.
You can use the SMF proxy resource types to integrate your own SMF controlled services into Sun Cluster so that these services have cluster-wide service availability without you rewriting callback methods or service manifest. After you integrate the SMF service into the SMF proxy resource, the SMF service is no longer managed by the default restarter. The restarter that is delegated by Sun Cluster manages the SMF service.
SMF proxy resources are identical to other resources, with no restriction on their usage. For example, an SMF proxy resource can be grouped with other resources into a resource group. SMF proxy resources can be created and managed the same way as other resources. An SMF proxy resource differs from other resources in one way. When you create a resource of any of the SMF proxy resource types, you need to specify the extension property Proxied_service_instances. You must include information about the SMF services to be proxied by the SMF resource. The extension property's value is the path to a file that contains all the proxied SMF services. Each line in the file is dedicated to one SMF service and specifies svc fmri, path of the corresponding service manifest file.
For example, if the resource has to manage two services, restarter_svc_test_1:default and restarter_svc_test_2:default, the file should include the following two lines:
<svc:/system/cluster/restarter_svc_test_1:default>,</var/svc/manifest/system/clus ter/restarter_svc_test_1.xml> |
<svc:/system/cluster/restarter_svc_test_2:default>,</var/svc/manifest/system/clus ter/restarter_svc_test_2.xml> |
The services that are encapsulated under an SMF proxy resource can reside in the global cluster or global-cluster non-voting node. However, all the services under the same proxy resource must be in the same zone.
Do not use SMF svcadm for disabling or enabling SMF services that are encapsulated in a proxy resource. Do not change the properties of the SMF services (in the SMF repository) that are encapsulated in a proxy resource.
Encapsulating an SMF Service Into a Failover Proxy Resource Configuration
Encapsulating an SMF Service Into a Multi-Master Proxy Resource Configuration
Encapsulating an SMF Service Into a Scalable Proxy Resource Configuration
For information about failover configuration, see Creating a Resource Group
Perform this procedure from any cluster node.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Register the proxy SMF failover resource type.
# clresourcetype register -f\ /opt/SUNWscsmf/etc/SUNW.Proxy_SMF_failover SUNW.Proxy_SMF_failover |
Verify that the proxy resource type has been registered.
# clresourcetype show |
Create the SMF failover resource group.
# clresourcegroup create [-n node-zone-list] resource-group |
Specifies a comma-separated, ordered list of nodes that can master this resource group. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource group is configured on all the global-cluster voting nodes.
To achieve highest availability, specify global-cluster non-voting nodes on different nodes in the node list of an SMF failover resource group instead of different global-cluster non-voting nodes on the same node.
Specifies your choice of the name of the scalable resource group to add. This name must begin with an ASCII character.
Verify that the SMF resource group has been created.
# clresourcegroup status resource-group |
Add an SMF failover application resource to the resource group.
# clresource create -g resource-group -t SUNW.Proxy_SMF_failover \ [-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource |
The resource is created in the enabled state.
Verify that the SMF failover application resource has been added and validated.
# clresource show resource |
Bring the failover resource group online.
# clresourcegroup online -M + |
If you use the clresource status command to view the state of the SMF proxy resource type, the status is displayed as online but not monitored. This is not an error message. The SMF proxy resource is enabled and running and this status message is displayed because there is no monitoring support provided for the resources of SMF proxy resource type.
The following example registers the SUNW.Proxy_SMF_failover resource type.
# clresourcetype register SUNW.Proxy_SMF_failover # clresourcetype show SUNW.Proxy_SMF_failover Resource Type: SUNW.Proxy_SMF_failover RT_description: Resource type for proxying failover SMF services RT_version: 3.2 API_version: 6 RT_basedir: /opt/SUNWscsmf/bin Single_instance: False Proxy: False Init_nodes: All potential masters Installed_nodes: <All> Failover: True Pkglist: SUNWscsmf RT_system: False Global_zone: False |
This example shows the addition of a proxy resource type, SUN.Proxy_SMF_failover to a resource group resource-group-1.
# clresource create -g resource-group-1 -t SUNW.Proxy_SMF_failover -x proxied_service_instances=/var/tmp/svslist.txt resource-1 # clresource show resource-1 === Resources === Resource: resource-1 Type: SUNW.Proxy_SMF_failover Type_version: 3.2 Group: resource-group-1 R_description: Resource_project_name: default Enabled{phats1}: True Monitored{phats1}: True |
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Register the SMF proxy multi-master resource type.
# clresourcetype register -f\ /opt/SUNWscsmf/etc/SUNW.Proxy_SMF_multimaster SUNW.Proxy_SMF_multimaster |
Create the SMF multi-master resource group.
# clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\ [-n node-zone-list]\ resource-group |
Specifies the maximum number of active primaries for this resource group.
Specifies the number of active primaries on which the resource group should attempt to start.
Specifies a comma-separated, ordered list of nodes in which this resource group is to be available. The format of each entry in the list is node:zone. In this format, node specifies the node name and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource group is configured on the global-cluster voting nodes.
Specifies your choice of the name of the scalable resource group to add. This name must begin with an ASCII character.
Verify that the SMF proxy multi-master resource group has been created.
# clresourcegroup show resource-group |
Add an SMF proxy multi-master resource to the resource group.
# clresource create -g resource-group -t SUNW.Proxy_SMF_multimaster\ [-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource |
Specifies the name of a scalable service resource group that you previously created.
Specifies a comma-separated list of extension properties that you are setting for the resource. The extension properties that you can set depend on the resource type. To determine which extension properties to set, see the documentation for the resource type.
node-specifier is an optional qualifier to the -p and -x options. This qualifier indicates that the extension property or properties on only the specified node or nodes are to be set when the resource is created. The specified extension properties on other nodes in the cluster are not set. If you do not include node-specifier, the specified extension properties on all nodes in the cluster are set. You can specify a node name or a node identifier for node-specifier. Examples of the syntax of node-specifier include the following:
-p "myprop{phys-schost-1}" |
The braces ({}) indicate that you want to set the specified extension property on only node phys-schost-1. For most shells, the double quotation marks (“) are required.
You can also use the following syntax to set an extension property in two different global-cluster non-voting nodes on two different nodes:
-x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}" |
Specifies a comma-separated list of standard properties that you are setting for the resource. The standard properties that you can set depend on the resource type. For scalable services, you typically set the Port_list, Load_balancing_weights, and Load_balancing_policy properties. To determine which standard properties to set, see the documentation for the resource type and Appendix B, Standard Properties.
Specifies your choice of the name of the resource to add.
The resource is created in the enabled state.
Verify that the SMF proxy multi-master application resource has been added and validated.
# clresource show resource |
Bring the multi-master resource group online.
# clresourcegroup online -M + |
If you use the clresource status command to view the state of the SMF proxy resource type, the status is displayed as online but not monitored. This is not an error message. The SMF proxy resource is enabled and running and this status message is displayed because there is no monitoring support provided for the resources of SMF proxy resource type.
The following example registers the SUNW.Proxy_SMF_multimaster resource type.
# clresourcetype register SUNW.Proxy_SMF_multimaster # clresourcetype show SUNW.Proxy_SMF_multimaster Resource Type: SUNW.Proxy_SMF_multimaster RT_description: Resource type for proxying multimastered SMF services RT_version: 3.2 API_version: 6 RT_basedir: /opt/SUNWscsmf/bin Single_instance: False Proxy: False Init_nodes: All potential masters Installed_nodes: <All> Failover: True Pkglist: SUNWscsmf RT_system: False Global_zone: False |
This example shows the creation and addition of a multi-master proxy resource type SUN.Proxy_SMF_multimaster to a resource group resource-group-1.
# clresourcegroup create\ -p Maximum_primaries=2\ -p Desired_primaries=2\ -n phys-schost-1, phys-schost-2\ resource-group-1 # clresourcegroup show resource-group-1 === Resource Groups and Resources === Resource Group: resource-group-1 RG_description: <NULL> RG_mode: multimastered RG_state: Unmanaged RG_project_name: default RG_affinities: <NULL> Auto_start_on_new_cluster: True Failback: False Nodelist: phys-schost-1 phys-schost-2 Maximum_primaries: 2 Desired_primaries: 2 Implicit_network_dependencies: True Global_resources_used: <All> Pingpong_interval: 3600 Pathprefix: <NULL> RG_System: False Suspend_automatic_recovery: False |
# clresource create -g resource-group-1 -t SUNW.Proxy_SMF_multimaster -x proxied_service_instances=/var/tmp/svslist.txt resource-1 # clresource show resource-1 === Resources === Resource: resource-1 Type: SUNW.Proxy_SMF_multimaster Type_version: 3.2 Group: resource-group-1 R_description: Resource_project_name: default Enabled{phats1}: True Monitored{phats1}: True |
For information about scalable configuration, see How to Create a Scalable Resource Group
Perform this procedure from any cluster node.
On a cluster member, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
Register the SMF proxy scalable resource type.
# clresourcetype register -f\ /opt/SUNWscsmf/etc/SUNW.Proxy_SMF_scalable SUNW.Proxy_SMF_scalable |
Create the SMF failover resource group that holds the shared address that the scalable resource group is to use. See How to Create a Failover Resource Group to create the failover resource group.
Create the SMF proxy scalable resource group.
# clresourcegroup create\-p Maximum_primaries=m\-p Desired_primaries=n\ -p RG_dependencies=depend-resource-group\ [-n node-zone-list]\ resource-group |
Specifies the maximum number of active primaries for this resource group.
Specifies the number of active primaries on which the resource group should attempt to start.
Identifies the resource group that contains the shared address-resource on which the resource group that is being created depends.
Specifies a comma-separated, ordered list of nodes in which this resource group is to be available. The format of each entry in the list is node:zone. In this format, node specifies the global-cluster voting node and zone specifies the name of a global-cluster non-voting node. To specify the global-cluster voting node, or to specify a node without global-cluster non-voting nodes, specify only node.
This list is optional. If you omit this list, the resource group is created on all nodes in the cluster.
The node list of the scalable resource can contain the same list or a subset of nodename:zonename pairs as the node list of the shared address resource
Specifies your choice of the name of the scalable resource group to add. This name must begin with an ASCII character.
Verify that the scalable resource group has been created.
# clresourcegroup show resource-group |
Add an SMF proxy scalable resource to the resource group.
# clresource create-g resource-group -t SUNW.Proxy_SMF_scalable \ -p Network_resources_used=network-resource[,network-resource...] \ -p Scalable=True [-p "extension-property[{node-specifier}]"=value, …] [-p standard-property=value, …] resource |
Specifies the name of a scalable service resource group that you previously created.
Specifies the list of network resources (shared addresses) on which this resource depends.
Specifies that this resource is scalable.
Specifies that you are setting extension properties for the resource. To determine which extension properties to set, see the documentation for the resource type.
node-specifier is an optional qualifier to the -p and -x options. This qualifier indicates that the extension property or properties on only the specified node or nodes are to be set when the resource is created. The specified extension properties on other nodes in the cluster are not set. If you do not include node-specifier, the specified extension properties on all nodes in the cluster are set. You can specify a node name or a node identifier for node-specifier. Examples of the syntax of node-specifier include the following:
-p "myprop{phys-schost-1}" |
The braces ({}) indicate that you want to set the specified extension property on only node phys-schost-1. For most shells, the double quotation marks (“) are required.
You can also use the following syntax to set an extension property in two different global-cluster non-voting nodes on two different global-cluster voting nodes:
-x "myprop{phys-schost-1:zoneA,phys-schost-2:zoneB}" |
Specifies a comma-separated list of standard properties that you are setting for the resource. The standard properties that you can set depend on the resource type. For scalable services, you typically set the Port_list, Load_balancing_weights, and Load_balancing_policy properties. To determine which standard properties to set, see the documentation for the resource type and Appendix B, Standard Properties.
Specifies your choice of the name of the resource to add.
The resource is created in the enabled state.
Verify that the SMF proxy scalable application resource has been added and validated.
# clresource show resource |
Bring the SMF proxy scalable resource group online.
# clresourcegroup online -M + |
If you use the clresource status command to view the state of the SMF proxy resource type, the status is displayed as online but not monitored. This is not an error message. The SMF proxy resource is enabled and running and this status message is displayed because there is no monitoring support provided for the resources of SMF proxy resource type.
The following example registers the SUNW.Proxy_SMF_scalable resource type.
# clresourcetype register SUNW.Proxy_SMF_scalable # clresourcetype show SUNW.Proxy_SMF_scalable Resource Type: SUNW.Proxy_SMF_scalable RT_description: Resource type for proxying scalable SMF services RT_version: 3.2 API_version: 6 RT_basedir: /opt/SUNWscsmf/bin Single_instance: False Proxy: False Init_nodes: All potential masters Installed_nodes: <All> Failover: True Pkglist: SUNWscsmf RT_system: False Global_zone: False |
This example shows the creation and addition of a scalable proxy resource type SUN.Proxy_SMF_scalalble to a resource group resource-group-1.
# clresourcegroup create\ -p Maximum_primaries=2\ -p Desired_primaries=2\ -p RG_dependencies=resource-group-2\ -n phys-schost-1, phys-schost-2\ resource-group-1 # clresourcegroup show resource-group-1 === Resource Groups and Resources === Resource Group: resource-group-1 RG_description: <NULL> RG_mode: Scalable RG_state: Unmanaged RG_project_name: default RG_affinities: <NULL> Auto_start_on_new_cluster: True Failback: False Nodelist: phys-schost-1 phys-schost-2 Maximum_primaries: 2 Desired_primaries: 2 RG_dependencies: resource-group2 Implicit_network_dependencies: True Global_resources_used: <All> Pingpong_interval: 3600 Pathprefix: <NULL> RG_System: False Suspend_automatic_recovery: False |
# clresource create -g resource-group-1 -t SUNW.Proxy_SMF_scalable -x proxied_service_instances=/var/tmp/svslist.txt resource-1 # clresource show resource-1 === Resources === Resource: resource-1 Type: SUNW.Proxy_SMF_scalable Type_version: 3.2 Group: resource-group-1 R_description: Resource_project_name: default Enabled{phats1}: True Monitored{phats1}: True |
Each data service that is supplied with the Sun Cluster product has a built-in fault monitor. The fault monitor performs the following functions:
Detecting the unexpected termination of processes for the data service server
Checking the health of the data service
The fault monitor is contained in the resource that represents the application for which the data service was written. You create this resource when you register and configure the data service. For more information, see the documentation for the data service.
System properties and extension properties of this resource control the behavior of the fault monitor. The default values of these properties determine the preset behavior of the fault monitor. The preset behavior should be suitable for most Sun Cluster installations. Therefore, you should tune a fault monitor only if you need to modify this preset behavior.
Tuning a fault monitor involves the following tasks:
Setting the interval between fault monitor probes
Setting the timeout for fault monitor probes
Defining the criteria for persistent faults
Specifying the failover behavior of a resource
Perform these tasks when you register and configure the data service. For more information, see the documentation for the data service.
A resource's fault monitor is started when you bring online the resource group that contains the resource. You do not need to start the fault monitor explicitly.
To determine whether a resource is operating correctly, the fault monitor probes this resource periodically. The interval between fault monitor probes affects the availability of the resource and the performance of your system as follows:
The interval between fault monitor probes affects the length of time that is required to detect a fault and respond to the fault. Therefore, if you decrease the interval between fault monitor probes, the time that is required to detect a fault and respond to the fault is also decreased. This decrease enhances the availability of the resource.
Each fault monitor probe consumes system resources such as processor cycles and memory. Therefore, if you decrease the interval between fault monitor probes, the performance of the system is degraded.
The optimum interval between fault monitor probes also depends on the time that is required to respond to a fault in the resource. This time depends on how the complexity of the resource affects the time that is required for operations such as restarting the resource.
To set the interval between fault monitor probes, set the Thorough_probe_interval system property of the resource to the interval in seconds that you require.
The timeout for fault monitor probes specifies the length of time that a fault monitor waits for a response from a resource to a probe. If the fault monitor does not receive a response within this timeout, the fault monitor treats the resource as faulty. The time that a resource requires to respond to a fault monitor probe depends on the operations that the fault monitor performs to probe the resource. For information about operations that a data service's fault monitor performs to probe a resource, see the documentation for the data service.
The time that is required for a resource to respond also depends on factors that are unrelated to the fault monitor or the application, for example:
System configuration
Cluster configuration
System load
Amount of network traffic
To set the timeout for fault monitor probes, set the Probe_timeout extension property of the resource to the timeout in seconds that you require.
To minimize the disruption that transient faults in a resource cause, a fault monitor restarts the resource in response to such faults. For persistent faults, more disruptive action than restarting the resource is required:
For a failover resource, the fault monitor fails over the resource to another node.
For a scalable resource, the fault monitor takes the resource offline.
A fault monitor treats a fault as persistent if the number of complete failures of a resource exceeds a specified threshold within a specified retry interval. Defining the criteria for persistent faults enables you to set the threshold and the retry interval to accommodate the performance characteristics of your cluster and your availability requirements.
A fault monitor treats some faults as a complete failure of a resource. A complete failure typically causes a complete loss of service. The following failures are examples of a complete failure:
Unexpected termination of the process for a data service server
Inability of a fault monitor to connect to a data service server
A complete failure causes the fault monitor to increase by 1 the count of complete failures in the retry interval.
A fault monitor treats other faults as a partial failure of a resource. A partial failure is less serious than a complete failure, and typically causes a degradation of service, but not a complete loss of service. An example of a partial failure is an incomplete response from a data service server before a fault monitor probe is timed out.
A partial failure causes the fault monitor to increase by a fractional amount the count of complete failures in the retry interval. Partial failures are still accumulated over the retry interval.
The following characteristics of partial failures depend on the data service:
The types of faults that the fault monitor treats as partial failure
The fractional amount that each partial failure adds to the count of complete failures
For information about faults that a data service's fault monitor detects, see the documentation for the data service.
The maximum length of time that is required for a single restart of a faulty resource is the sum of the values of the following properties:
Thorough_probe_interval system property
Probe_timeout extension property
To ensure that you allow enough time for the threshold to be reached within the retry interval, use the following expression to calculate values for the retry interval and the threshold:
retry_interval >= 2 x threshold × (thorough_probe_interval + probe_timeout)
The factor of 2 accounts for partial probe failures that do not immediately cause the resource to be failed over or taken offline.
To set the threshold and the retry interval, set the following system properties of the resource:
To set the threshold, set the Retry_count system property to the maximum allowed number of complete failures.
To set the retry interval, set the Retry_interval system property to the interval in seconds that you require.
The failover behavior of a resource determines how the RGM responds to the following faults:
Failure of the resource to start
Failure of the resource to stop
Failure of the resource's fault monitor to stop
To specify the failover behavior of a resource, set the Failover_mode system property of the resource. For information about the possible values of this property, see the description of the Failover_mode system property in Resource Properties.