This section describes the steps required to create, configure, and manage a cluster using EAServer Manager.
Creating a cluster from EAServer Manager
Highlight the Clusters folder.
Select File | New Cluster Wizard.
Enter the requested data on the Wizard pages; click Help for additional information on any page.
To set the initial context used by servers in a cluster when they bind their objects into the name servers, set the com.sybase.jaguar.cluster.initialcontext property on the Advanced tab in the Cluster Properties dialog. For example, cluster “US_Cluster” may have initial context “/US”, and cluster “UK_Cluster” may have initial context “/UK”. Then clients can talk to any name server which is used by either “US_Cluster” or “UK_Cluster”, and by specifying the appropriate initial context, (either “/US” or “/UK”) the clients can be directed to the appropriate servers.
Configuring a server to
enable synchronization
Before you can add a server to a cluster, you must configure each physical server to enable synchronization from the primary server.
Use EAServer Manager to connect to the physical server. If necessary, define a server that matches a logical server name defined in the primary server's repository. In other words, if the primary server’s name is Jaguar_cluster, you must also assign the name Jaguar_cluster to each participating server.
If necessary, configure the listeners of this server. You must at least configure an IIOP listener to match the URL that will be used for cluster synchronization. Each like-named server in a cluster must also share the same listener name. Do not use ‘localhost’ for any IIOP listeners if the cluster runs on multiple machines.
Configure the account that will be used to synchronize the cluster:
If you are using jagadmin, change the jagadmin password to match that of the primary server.
If you are using an account other than jagadmin, add that account's user name or digital ID to the Admin role.
Restart the server so the new network addresses and security changes take effect.
Adding a server to a cluster
Connect to the primary server with EAServer Manager and add each physical server to the cluster definition:
Click the Clusters icon.
Select the cluster to which you want to add servers.
Select File | Properties. The primary server (the server to which you are connected) displays in the Primary Server field of the General tab.
Select the Servers tab.
Click Add.
Enter a valid IIOP address for the server, for example iiop://myhost:9000. This address is used for inter-server connections when you synchronize the cluster.
When creating a server that will join the cluster, you must define and install listeners with the same names as used by the primary (in the master configuration) for that server name.
Once you have added all the servers that you intend to add to the cluster, synchronize the cluster. The Synchronize dialog box appears automatically after you add a server and click OK. See “Synchronizing a cluster from EAServer Manager” for more information. You can add more servers later, but you must then again synchronize the cluster.
After you have synchronized the cluster, restart the new member servers. This step ensures that the new servers use the same security key information for interserver configuration.
WARNING! After you add a nonprimary server to a cluster, EAServer Manager warns you when you connect directly to that server. Direct user updates to the server’s configuration can be overwritten when the cluster is synchronized if the new server has been the target of at least one synchronization before it was added as a member of the cluster.
Adding a name server to
a cluster
Click the Clusters icon.
Select the cluster to which you want to add name servers.
Select File | Properties.
Select the Name Servers tab.
Click Add.
Enter the server’s URL (for example, iiop://myhost:9000). When
you have entered all of the name servers for the cluster, click
OK. The Synchronize dialog box appears automatically after you add
a name server and click OK. You can add more name servers later
but must synchronize the cluster afterwards.
Synchronize the cluster.
Name servers can also be “ordinary” members
of a cluster (if they are also listed on the Servers tab in the
Cluster Properties dialog). However, if a name server is used by
more than one cluster, it can be an ordinary member of only one
cluster.
EAServer requires the cluster’s bind password to authorize name context updates to the cluster’s name servers. When you create a cluster, a random bind password is automatically generated. In most cases, you do not need to edit the password. However, if a name server is used by two or more clusters, you must configure the clusters to use the same bind password.
To change the password, modify the com.sybase.jaguar.cluster.bindpassword property on the Advanced tab in the Cluster Properties dialog—see com.sybase.jaguar.cluster.bindpassword. Sybase recommends that you use one of the randomly generated passwords, as security can be compromised if clients obtain knowledge of a cluster’s bind password.
Removing a server from
a cluster
Click the Clusters icon.
Select the cluster from which to remove the server.
Select File | Properties.
Select the Servers tab.
Highlight the server you want to delete and click Delete.
Connect to the deleted server using EAServer Manager, and delete the com.sybase.jaguar.server.cluster property from the Server Properties dialog (this tells the server it is no longer a member of the cluster):
Double-click the Servers folder.
Highlight the server that has been deleted from the cluster.
Select File | Properties.
Select the Advanced tab.
Highlight the com.sybase.jaguar.server.cluster property.
Click Delete.
Synchronize the cluster, and restart the name servers.
Removing a name server
from a cluster
Click the Clusters icon.
Select the cluster from which to remove the name server.
Select File | Properties.
Select the Name Servers tab.
Highlight the server you want to delete and click Delete.
Synchronize the cluster.
Deleting an existing cluster
Click the Clusters icon.
Select the cluster you want to delete.
Select File | Delete Cluster.
For each server that was in the cluster, verify that the server is no longer configured to join the deleted cluster, as follows:
Connect to the server with Jaguar Manager (if not connected already).
Highlight the server icon.
Select File | Properties.
Select the Advanced tab.
Delete the com.sybase.jaguar.server.cluster property.
A server that was part of the deleted cluster may try to connect to the cluster if the com.sybase.jaguar.server.cluster property is set to the name of the cluster. In these cases, you see error messages in the server_name.log file (where server_name is the name of the server) indicating that the server is in Admin mode. Fix this problem by deleting the property as described above.
Rebinding a cluster
The Rebind option refreshes all of the name servers within a cluster. If you add a component to a server that is already part of a cluster and want to make that component available to the cluster, you need to rebind the cluster. You can also use the rebind option if a problem occurs when you synchronize the cluster; for example, if one of the name servers is slow to start.
Highlight the name of the cluster.
Select File | Rebind.
The name servers in a cluster use heartbeat detection to periodically verify that member servers are either accepting client connections or have failed. If a server is not accepting connections, the name server does not return profile (host:port) information to the client, and routes requests to other servers in the cluster. The name server also detects when a failed server is ready to accept connections again and starts routing client requests to that server.
If a name server using transient storage fails, the cluster rebinds automatically when you reboot the failed name server. Otherwise, the cluster provides access to components through the remaining name servers in the cluster.
If a name server using persistent storage and LDAP support fails, the cluster does not need to rebind, but LDAP may leave behind stale profiles, resulting in unnecessary client retries and failures. For this reason, Sybase recommends you use transient storage to support load balancing and high availability.
Enabling heartbeat detection from EAServer Manager
Select the Servers folder.
Highlight the name server for which you are configuring heartbeat detection.
Select File | Properties.
Open the Naming Service tab.
Select the Enable Heartbeat check box.
Enter the heartbeat frequency. This number is how often, in seconds, that the name server checks server availability. As the frequency period is shortened, server performance decreases. The default frequency is 120 seconds.
When you synchronize a cluster, the heartbeat settings (whether or not it is enabled and frequency) of the primary server are distributed to the other name servers in the cluster.
The com.sybase.jaguar.cluster.primary property stores the primary server URL for each cluster. The synchronization process maintains this automatically—see com.sybase.jaguar.cluster.primary. The cluster property, com.sybase.jaguar.cluster.version, stores the version number for each cluster. The synchronization process maintains this automatically—see com.sybase.jaguar.cluster.version.
On start-up, a server that is a member of a cluster must verify that it is “in sync” with other cluster members by checking its cluster version number against other servers in the cluster. A server that is not in-sync remains in admin mode and does not join the cluster. The com.sybase.jaguar.cluster.startup cluster property specifies the testing algorithm. Set or modify this property from the Advanced tab in the Cluster Properties window—see com.sybase.jaguar.cluster.startup.
The com.sybase.jaguar.cluster.startup values and corresponding algorithms are:
check_primary (default value) – With this setting, each server tests its cluster version number against the primary before joining the cluster, using the following algorithm:
If any other cluster member (including the primary) is reachable and has a higher cluster version number, this server moves to Admin mode since it is not “in sync.”
If the primary is available and has the same cluster version number, this server joins the cluster and is ready to accept client connections.
If the primary is available and has a different cluster version number, this server moves to Admin mode since it is not “in sync.”
If none of the above conditions are met, the server waits briefly, then returns to the first step in this algorithm.
check_servers – With this setting, each server tests its cluster version number against the other member servers before joining the cluster, using this algorithm:
If any other cluster member (including the primary) is reachable and has a higher cluster version number, this server moves to Admin mode since it is not “in sync.”
Let M be the number of cluster members (including the primary), and let N equal M/2 (integer division). If at least N other servers are available and have the same cluster version number, this server joins the cluster and is ready to accept client connections.
If none of the above conditions are met, the server waits briefly then returns to the first step in this algorithm.
The check_servers option allows a server to join a cluster even if the primary is not available. This prevents a single point of failure if the primary server becomes unavailable.
disable_check – no checking is performed. For a cluster with only two servers (including the primary), use this option and manually verify that the secondary server is “in sync.” For a cluster with three or more servers, Sybase discourages the use of this option, since it can result in “out-of-sync” cluster members running together.
A server in Admin mode can be put into Ready mode as described in “Switching to Ready mode”. If a server is in Admin mode due to a cluster version number mismatch, then using Set Ready is the manual equivalent of disable_check, so using Set Ready in this case is also discouraged as it may result in “out-of-sync” cluster members running together. Sybase recommends that you synchronize the cluster instead. See “Synchronizing a cluster from EAServer Manager” for more information.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|