Managing Gateway Clusters
This chapter describes how to manage ACE XML Gateway clusters. It covers these topics:
•About Multiple Cluster Management
•Considerations for Using Multiple Clusters
•Working with Clusters
About Multiple Cluster Management
The ACE XML Gateway instances controlled by an ACE XML Manager are organized in the Manager's configuration by cluster. You place an ACE XML Gateway in the administrative control of a ACE XML Manager by adding it to one of its managed clusters.
An ACE XML Manager always has at least one cluster in its configuration. However, it may have more than one. While all Gateways in a cluster must apply the same policy version, different clusters administered by a single Manager can apply different policies. This ability is typically used to apply different traffic processing rules for different business units, but it also lets you centrally administer different Gateway environments that represent different stages in a given policy's life cycle, such as an environment for development, testing, and production.
What is the Default Cluster?
The Manager web console can be opened only in the context of a policy for a particular Gateway cluster. After installation, all Managers contain a single cluster named Default Cluster, which serves as a default starting point for your work.
On appliances that are configured in standalone mode, the Default Cluster is preconfigured to have this appliance as a cluster member. Manager-only appliances have an empty Default Cluster to which you add Gateways. You can change the name of the default cluster or add more Gateways to the cluster, if desired.
Note that there needs to be at least one cluster defined in the Manager. If you delete the only cluster, a new "Default Cluster" is automatically created at next login.
Considerations for Using Multiple Clusters
You can add clusters to this Manager's control on the Cluster Management page, which is accessible by clicking the Cluster Management link in the Administration section of the navigation menu. In the cluster settings page, specify the Gateways in the cluster by IP address.
Note For information on adding clusters, see "Adding Gateways to the Manager's Control" section on page 3-17.
The administrator of an ACE XML Manager can expose access to the policy for the clusters in several ways:
•As a menu choice at the login page. The Cluster menu displays the names of the clusters configured for this Manager.
•At a particular management port. The web console is presented by default at port 8243. The console for additional clusters can use other port numbers.
•At a particular IP address. Port numbers provide one mechanism for separating cluster managers. Using different IP addresses, however, makes cluster managers appear completely separate to console users. You can put the manager for Cluster A, for example, on 192.168.1.1 and for Cluster B on 192.168.1.2. Then, using your network's DNS infrastructure, you can set up descriptive hostnames, such as gateway-prod for one IP address and gateway-test for another. Users can then log in to each cluster as if they were two completely separate appliances, by addressing https://gateway-prod:8243 or https://gateway-test:8243.
The cluster settings page lets you choose an IP address for the cluster. The addresses available are those for which the Manager network interfaces are configured.
Note For more information on configuring IP address aliases on an interface, see the Cisco ACE XML Gateway Administration Guide.
Once a user is logged into a particular cluster, the Manager web console environment for that cluster appears as a completely separate environment from the other clusters, with its own policy, user accounts, and log information.
Since console user accounts exist in the context of a cluster, each user (other than the built-in
administrator user account) can only access the policy for the cluster in which they were added. To access additional clusters, the users would need to have a valid account in the other cluster policies.
To move policies between clusters, you need to use the PPF mechanism described in "Copying Objects Between Subpolicies" section on page 30-303. Specifically, in the console of the source cluster, export the policy as a PPF file and then log into the other cluster console and import the PPF.
For the most part, the settings for each cluster in a single Manager are maintained completely apart from other clusters, that is, policy settings are not shared across clusters. There are a few exceptions to this rule, mainly having to do with console system administration settings. The exceptions include:
•Audit log settings
•SDK development mode
•SDK extension modules
•Manager log level
When one of these settings are changed, the change takes effect across cluster environments. The Manager web console (in particular, the System Management > Manager Settings page) indicates which settings apply across clusters.
Considerations exist for logging when multiple clusters are enabled as well. Note the following differences between log events generated by Gateways and those generated by the Manager:
•Gateway events are shown in the Event Log only for the Gateways in the cluster to which the Manager web console is currently accessed.
•All Manager events are shown in the Event Log, across all clusters. For clarity, the events are qualified by the name of the cluster, for instance:
User "administrator" has logged in to cluster "Default Cluster" from IP address 10.0.4.5.
Also, as the monitoring point for an ACE XML Gateway implementation, the Manager receives information on ACE XML Gateway activities on an ongoing basis. A busy Gateway can generate a significant volume of event traffic. Event information is passed to the Manager via syslog, which, as a UDP protocol, offers best-effort delivery only. It's possible in a busy network to lose event log information. When designing the cluster topology for your system, it's important to consider this behavior. In particular, you should avoid using a single Manager to administer a production cluster as well as a testing cluster on which you want to conduct performance testing. Doing so may interfere with the Manager's ability to monitor the production cluster.
Note that a single ACE XML Gateway should not be controlled by more than one ACE XML Manager at a time, that is, a Gateway should not be in more than one cluster. This restriction applies whether the clusters are on a single Manager or on different ACE XML Manager appliances.
Working with Clusters
This section describes how to add, modify, and remove cluster definitions for a Manager.
Creating a Cluster
Most implementations will only require a single cluster. You should use these steps to create additional clusters only if you specifically want to manage independent policies on different Gateways or groups of Gateways from a single Manager.
To define new clusters for an ACE XML Manager:
Step 1 As a user with administrator privileges in the web console, click the Cluster Management link from the navigation menu.
The cluster management page should show a cluster named "Default Cluster." On a Manager of an appliance in standalone mode, the Default Cluster lists this appliance as the only member Gateway. Otherwise, the default cluster is empty.
Step 2 Add the Gateway to a new cluster by clicking Manage a New Cluster to define a new cluster.
Step 3 Configure these settings for the new cluster:
•In the Cluster Name field, type a name for the cluster. If multiple clusters are served on the same port of this Manager, the name will appear in the login page to users attempting to access the Manager web console. It should therefore be unique for cluster names and meaningful for your console users.
•For the Manager HTTPS Port specify the HTTP port on which the Manager should serve the web console for accessing the policy for this cluster. You can accept the default port, 8243, or type another.
Multiple clusters can use the same Manager port. If the same IP address is also used, a menu choice of which cluster to access appears on the login page.
•The IP address menu allows you to choose the address on which to serve the web console for this cluster. The menu lists any address that is configured for the physical Ethernet interface on the appliance. All cluster managers can use the same IP address. However, using different IP addresses can provide better separation of cluster environments for console users. By using different IP addresses and further using your DNS infrastructure, you can associate meaningful host names to the web console for each cluster, so that users can access the cluster by URLs such as https://gateway-prod:8243 and https://gateway-test:8243.
•The SSL Certificate shown on this page is used to secure the connection from the Manager web console to the browser. As noted in the menu, a temporary certificate is provided with the Manager. You should replace this certificate with one generated for the purpose. You can create a CSR by clicking the Manage Certificates button.
If using IP addresses to differentiate cluster managers, you will need a certificate for each cluster, with a subject CN corresponding to the hostname for each cluster manager.
Step 4 In the Cluster Members text field, type the IP address of the Gateways you want to add to this cluster. Each Gateway IP should be on its own line in the text field, such as:
Use care when entering the IP address of the Gateway. The web console interface does not validate the value you enter to ensure that it is actually the address of an ACE XML Gateway appliance. If the host IP is incorrect, the error may not be discovered until an attempt is made to deploy to the target Gateway, at which time the deploy attempt will fail.
Step 5 Click Save Changes.
Note Each ACE XML Gateway must be configured with the IP address of the ACE XML Manager that controls it. If this has not been done already, access the shell interface for each cluster member and configure the Manager address. For more information, see the Cisco ACE XML Gateway Administration Guide.
The current cluster name appears at the top of the console page.
Step 6 If you made changes that require a Manager restart, such as changes to the port configuration, the Manager prompts you to restart the Manager. Do so by clicking the Restart the ACE XML Manager button at the top of the Cluster Management page.
Step 7 The Gateways that have been added likely need to have their licenses configured. The policy cannot be deployed to the ACE XML Gateway until it is licensed. For information on configuring the license, see the Cisco ACE XML Gateway Administration Guide.
The cluster configuration is now complete. To access the policy for the new cluster, log out of the Manager and log in to the new cluster web console, either by choosing it from the Cluster menu on the login page or navigating to the appropriate port or IP address, depending on your cluster configuration. To log-in to the new cluster, use the built-in
administrator user account.
Editing a Cluster
After creating a cluster, you can modify its settings (such as its name or management port number) at any time. To modify the cluster settings, the web console for the cluster you want to change must be active in the web console. You cannot change cluster settings while the Manager is accessing the configuration for another cluster.
While accessing the Manager web console for a cluster, modify its cluster-specific configuration settings as follows:
Step 1 Click the Cluster Management link in the navigation menu.
Step 2 Click the edit link next to the cluster listed on the page.
Step 3 In the Edit Cluster Configuration page, change the cluster settings as desired. For more information on the settings, see "Working with Clusters" section.
Step 4 Click Save Changes to commit your changes to the cluster configuration.
Step 5 If you made changes that require a Manager restart, such as changes to the port configuration, the Manager prompts you to restart the Manager. Do so by clicking the Restart the ACE XML Manager button at the top of the Cluster Management page.
Removing a Cluster
Removing a cluster removes all the configuration settings for that cluster, including its policy. Therefore, you should use care when removing clusters to ensure that you do not inadvertently lose policy development work.
To delete a cluster, first access the cluster configuration from the Manager web console; you cannot delete a cluster definition while accessing the Manager web console in the context of a different cluster.
In the Cluster Management page, click the remove link for the cluster. The current cluster is removed and you are logged out of the web console.
Note that there must be at least one cluster in a Manager. If you remove a single cluster from the Manager, a new default cluster is created at next login.