Centralized configuration for the mid tier
Centralized configuration refers to storing configuration form data at a common location that can be accessed by other computers. Centralized configuration simplifies the management of configuration data and the sharing of configuration settings across servers. For more information, see Centralized configuration.
You must configure a BMC Remedy AR System server to act as a Centralized Configuration Server (CCS). The Centralized Configuration Server is a BMC Remedy AR System server that does not have any applications installed or any end-user interactions. Centralized Configuration Server needs limited resources in terms of CPU and RAM.
The Centralized Configuration Server ensures consistency by communicating changes to the global properties across all the mid tiers in a cluster. If a configuration server is defined while adding a tenant, that tenant configuration server maintains a copy of the tenant-specific settings. When a tenant-specific property is modified on one mid tier, the Tenant Configuration Server automatically sends the notification to other mid tiers that have the same tenant added, so that these configuration changes are also synchronized by each mid tier in the same cluster.
For example, you have 10 mid tiers in a cluster. Before centralized configuration, each tenant was managed independently. To change a configuration setting, you had to make the same change for each tenant in the cluster. With centralized configuration, because all settings are stored in forms, you can change the settings for multiple tenants in a cluster at one time. Centralized configuration enables you to share configuration settings across all tenants in a cluster.
Centralized configuration
Overview of global and local level configurations for the mid tier
You can choose to define global and local level configurations for mid tier. You must configure the mid tier in a cluster to set the global and local level configurations. Global level configurations are defined for all servers in a server group. Local level configurations are defined for an individual server. Any configuration in the centralized configuration that is specified under the Component Name field as "*" is a global level configuration. For more information, see Managing AR Server Group components by setting global-level and local-level configurations.
The global level configuration is applicable to all the clusters and all the mid tiers under those clusters. The local level configurations are applicable to a particular cluster.
The following diagram illustrates global and local level configurations for clusters:
Configuring the AR System server as a Centralized Configuration server
You can configure the AR System server as a Centralized Configuration Server or a Tenant Configuration Server only if the AR System server version supports centralized configuration and has the following configuration-related system forms:
- AR System Configuration Component
- AR System Configuration Component_Backup
- AR System Configuration Component Setting
- AR System Configuration Component Setting_Backup
- AR System Configuration Component Setting_Backup_Unique
- AR System Configuration Component Setting Audit
- AR System Configuration Component-Setting Mapping
- AR System Configuration Component-Setting Mapping_Backup
When the configuration is successful, the Centralized Configuration Server Setting page on the Mid Tier configuration tool displays the following confirmation message:
To set the Centralized Configuration Server properties
- Open the BMC Remedy Mid Tier Configuration Tool from the URL: http://hostname:port/arsys/shared/config/config.jsp.
- Click Central Config Settings.
- In the Central Config Settings page, enter the following information:
- In Server Name, enter the name of the AR System server that is the designated as the Centralized Configuration Server in the cluster.
- In Cluster ID, enter the unique cluster ID of the cluster to which the mid tier belongs.
- Enter the administrator password.
- (Optional) Enter the port number and RPC number.
Click Save.
Click Publish to create or update global properties from the config.properties file to Centralized Configuration Server.
Note
After you publish, properties that are deleted from the config.properties file are not deleted from the Centralized Configuration Server. However, deleted properties are reflected in the current mid tier memory immediately and are restored when the mid tier is restarted. Click Restore to restore global settings from the Centralized Configuration Server to the config.properties file. Exercise caution when deleting any property directly from the Centralized Configuration Server forms.
- Click Restore to update the global settings from Centralized Configuration Server to the config.properties file.
A ccs.properties file is added to the midTierInstallationDirectory\WEB-INF\classes folder and contains the following information:
- arsystem.cluster.id
The cluster identifier of the mid tier cluster. All mid tier instances in the same cluster share the cluster identifier. - arsystem.ccs.password
The encrypted mid tier service password for the Centralized Configuration Server. - arsystem.ccs.host
The name of the Centralized Configuration Server. - arsystem.ccs.port
The port number of the Centralized Configuration Server.
The mid tier uses the ccs.properties file for connecting to the Centralized Configuration Server on startup and for updating its configuration files for global settings (config.properties) and tenant-specific settings (config.tenantName.properties).
Note
If you have configured a valid Centralized Configuration Server or Tenant Configuration Server, refrain from making any changes directly to the properties files. These changes might be overwritten during the next mid tier restart. Make all the necessary changes in the BMC Remedy AR System Configuration Component Setting form on the Centralized Configuration Server or Tenant Configuration Server, using the appropriate cluster ID or tenant name. The changes will take effect in all concerned mid tier instances and corresponding properties files by means of a periodic notification (typically after 30 seconds). However, changes to some of the properties, such as Ehcache settings and number of threads, require the mid tier to be restarted. For more information, see Centralized configuration.
Comments
Log in or register to comment.