Configuring Hierarchy Replication Rules
Hierarchy replication of resources and events is configured using replication rules. These rules define the data that you want to replicate to other Notification Servers. Each rule replicates the specified data in one direction only, up to the parent Notification Server or down to the child Notification Servers. If you set up two rules that have the same resource type being replicated in both directions, a critical alert is raised and the replication rules do not run.
Any data that is replicated down from a parent Notification Server has priority, and overwrites the corresponding data on its child servers. The replicated configuration and management items received from a parent server are usually read-only so they cannot be modified. The read-only setting ensures that it is replicated unchanged down the hierarchy. If you want to allow additions to replicated items on child servers, you need to unlock the relevant items on the Notification Server computer on which they were created. For example, you may want to allow policies to be enabled and disabled on the child Notification Servers.
You may include resource targets in a resource replication rule. Resource scoping applies to the contents (resources) of the targets that are replicated. Therefore, the resources that are replicated depend on the owner of the resource target. The Notification Server administrator can choose to replicate resource targets in their current state (owned by somebody else, with the corresponding scope). Alternatively, they can take ownership of the targets, save them with the administrator’s scope (which usually contains more resources) and replicate them in that state. All the current members of a resource target are replicated. The actual resource target item is replicated in the background as a dependent item. For example, when a replication rule is created at the parent which applies to a resource target. The resource target is replicated as a dependent item when the replication rule itself replicates down the hierarchy.
Hierarchy has two modes of replication:
Differential | Replicates the objects and the data that have changed since the last replication. This mode is enabled by default and reduces the load and the bandwidth that hierarchy uses. |
Complete | Replicates all objects and data. This mode is disabled by default. |
To minimize the load on the network and to prevent data collisions, you should schedule hierarchy replication at a different time for each Notification Server in your hierarchy.
Hierarchy replication synchronizes different types of objects in the following ways:
Configuration and Management Items | Policies, tasks, filters, and reports are replicated down the hierarchy. Items use differential replication, which is handled by hashing each item to check for changes and replicating those that have changed. Server Jobs are not replicated from parent Notification Server to child Notification Servers. |
Security Settings | Security roles, privileges, and permissions are replicated down the hierarchy. Security objects, such as roles and privileges, always use complete replication.
|
Resources | Resource information, such as computers, users, sites, and their associated data classes are replicated up or down the hierarchy. If, on parent Notification Server, you manually assign a primary user to a computer, the association is only replicated down the hierarchy. Note that this association can only be changed on parent Notification Server. Resources use differential replication. Differential replication is based on the "last changed" timestamp on the source data. Any data that has changed since the last replication is replicated to the destination server. The data on the destination is then verified, if data verification has been enabled in the appropriate replication rule. Data verification imposes significant processing load on Notification Server. To reduce this load, you can verify a specified percentage of data on the destination server with each replication. For example, if you verify 10% of the data for each replication, that ensures that all data has been verified after 10 replications. |
Packages | Packages that are associated with software resources and the data classes that are associated with the packages are replicated down the hierarchy. |
Events | Event classes, such as software delivery execution, are replicated up or down the hierarchy. Note that events can overwhelm a parent Notification Server computer when replicated. By default, no events are enabled to replicate. These should be replicated only with great caution and for limited time periods. Note that because replication does not occur real-time, raw event data cannot be used for alerting at the parent Notification Server computer. |
This task is a step in the process for implementing Notification Server hierarchy.
- To configure hierarchy replication and hierarchy replication rules
- In the Symantec Management Console, on theSettingsmenu, clickNotification Server > Hierarchy.
- On theHierarchy Managementpage, select theReplicationtab.
- Configure hierarchy replication by selecting the appropriate options.
- To configure the hierarchy replication rules, do any of the following:Create a new hierarchy replication rule
- ClickAdd.
- In theReplication Ruledialog box, specify the appropriate settings.
- ClickSave changes.
Modify an existing hierarchy replication rule- Select the appropriate rule, and then clickEdit.
- In theReplication Ruledialog box, specify the appropriate settings.
- ClickSave changes.
Enable a hierarchy replication ruleCheckEnabledbeside the replication rule name.Delete a hierarchy replication ruleSelect the appropriate rule, and then clickDelete.The replication rules that are provided with Notification Server or with the installed solutions cannot be deleted. However, you can enable and disable these rules when necessary, and you can edit the rule name and description. - ClickSave changes.