Cisco Cisco Access Registrar 3.5 - Manual (Page 39)

C H A P T E R
4-1
Cisco Access Registrar 3.5 Concepts and Reference Guide
OL-2683-02
4
Understanding Replication
This chapter describes Cisco Access Registrar's configuration replication features, functions, limitations
and operation.
Replication Overview
Cisco Access Registrar replication feature can maintain identical configurations on multiple machines
simultaneously. When replication is properly configured, changes an administrator makes on the primary
or master machine are propagated by Cisco Access Registrar to a secondary or slave machine.
Replication eliminates the need to have administrators with multiple Cisco Access Registrar installations
make the same configuration changes at each of their installations. Instead, only the master's
configuration need be changed and the slave is automatically configured eliminating the need to make
repetitive, error-prone configuration changes for each individual installation. In addition to enhancing
server configuration management, using replication eliminates the need for a hot-standby machine.
Using a hot-standby machine is a common practice to provide more fault-tolerance where a
fully-installed and configured system stands ready to takeover should the primary machine fail.
However, a system setup for hot-standby is essentially an idle machine only used when the primary
system fails. Hot-standby or secondary servers are expensive resources. Employing Cisco Access
Registrar's replication feature, both servers may perform RADIUS request processing simultaneously,
eliminating wasted resources.
The replication feature focuses on configuration maintenance only, not session information or
installation-specific information such as Administrator, Interface, Replication or Advanced
machine-specific configuration changes. These configuration items are not replicated because they are
specific to each installation and are not likely to be identical between master and slave. While changes
to Session Managers, Resource Manager, and Remote Servers are replicated to the slave and stored in
the slave's configuration database, they are not hot-configured on the slave (see Hot Configuration
Detailed below for more information)
Changes should be made only on the master server. Making changes on a slave server will not be
replicated and may result in an unstable configuration on the slave. Any changes made using replication
will not be reflected in existing aregcmd sessions. aregcmd only loads its configuration at start up; it is
not dynamically updated. For example, if aregcmd is running on the slave, and on the master aregcmd
is used to add a client, the new client, while correctly replicated and hot-configured, will not be visible
in the slave's aregcmd until aregcmd is exited and restarted.