Remote Data Replicator (RDR) V6.1 User Guide
Remote Data Replicator (RDR) V6.1 User Guide
Version 6.1
User Guide
Remote Data Replicator User Guide
V6.1
Catalog No: X92075
Drawing No: 432006-2442-063-A00
May 2016
1st Edition
The qualification lab is accredited by A2LA for competence in electrical testing according to
the International Standard ISO IEC 17025-2005 General Requirements for the Competence of
Testing and Calibration Laboratories.
NOTE: ems, enm, nms, obi, and stms are used to identify RDR instances. EMS-MPT, EMS-XDM,
EMS-SYNCOM, LightSOFT, LightINSIGHT, and STMS are used to identify the corresponding
applications. For more information see Instances.
A configuration of an instance on a specific component is referred to as a component instance.
Related documents
EMS-MPT User Guide
EMS-XDM User Guide
EMS-SYNCOM User Guide
LightSOFT Documentation Suite
LightINSIGHT Documentation Suite
STMS User Guide
Contact information
Telephone Email
ECI Documentation Group +972-3-9268145 techdoc.feedback@ecitele.com
ECI Customer Support +972-3-9266000 on.support@ecitele.com
1.1.1 Components
RDR components provide the infrastructure for RDR backup and synchronization functionality on servers.
There are three types of components:
Primary: Contains one or more of the management applications that the RDR backs up.
Backup: Administers the storage of backups (replicas) on backup stations.
Mirror: Restores application databases from the backup station to a mirror station, enabling the
network to be managed from the mirror station in the event of a primary station failure.
Shadow: Restores the Backup server
NOTE: The backup and mirror can share the same station.
RDR components are referred to as belonging to sites – primary components to a primary site, mirror
components to a mirror site, and the backup component (when not sharing a mirror component's station)
to a backup site.
1.1.2 Instances
An RDR instance is an occurrence of a supported application that is running on the primary component
(such as EMS-SYNCOM, EMS-MPT, LightSOFT, LightINSIGHT, or STMS in any combination).
RDR instances are not the actual applications, but the data relating to the applications that need to be
backed up (for example, the database and configuration).
Each instance is identified by its own unique name. The instance name has the following structure:
tag@hostname[:zone_prefix]
tag: Identifies the application:
nms: LightSOFT Server application
ems: EMS-MPT or EMS-XDM application.
stms: STMS application
obi: LightINSIGHT OBIEE application
enm: EMS-SYNCOM application
hostname: The host name (primary or mirror components) where the instance is located.
zone_prefix: The zone identifier for Multi-Zone configurations. It is the first part of the standard
zone name in ECI installations (zn).
In the case of a Single-Zone (Legacy) configuration, the zone_prefix is omitted.
EXAMPLE: The RDR instance name for EMS-MPT on host foo in zone
z3-foo is: ems@foo:z3.
The RDR modular structure provides separate backup/recovery mechanisms for each supported instance.
Each instance on each component can be configured according to user requirements, for example, to have
different backup schedules or a different number of backups per cycle.
NOTE: When the LightSOFT server involves a cluster configuration (main server and one or
more plain servers), only the main server that contains the database is installed with RDR and
is relevant for backup purposes.
1.1.3 Replicas
RDR replicas are backup data sets of primary component instances (databases). The replicas are stored in a
special folder on the backup server for each primary component instance in a user-configurable path.
Two to five full regular replicas can be configured for each primary component instance (ems, enm, nms,
obi, or stms), with the newest backup overwriting the currently oldest backup on a cyclical basis.
An archive replica, which is not automatically overwritten, can also be created for each primary component
instance. An archive replica is a static backup from a specific time used to freeze the system state on the
backup server.
Recovery can be performed based on either any cyclical replica or the archive replica.
The number of replicas that can be stored is only limited by the available disk capacity (see Minimum
Backup Server Disk Capacit y).
For each primary component instance, backups can be scheduled to be performed automatically at
constant intervals (set time span between backups) or non-constant intervals (specific time on selected
days of the week or month).
Replicas at constant intervals can be set to occur at very short intervals, as frequently as every 10 minutes,
according to user requirements. (The selected interval cannot be shorter than the time it takes to create a
backup.)
To simplify recovery, it is recommended to schedule all primary component instances with the same
backup intervals. Offsets can be used to stagger individual starting times (setting them a number of minutes
apart), to balance the load and avoid network congestion.
NOTE: The replica of the instance on the shadow server is automatically located in the same
location as on the backup server. This allows the recovery session to also restore the instance
from the shadow server.
In this example, the backup and mirror components share a common host.
NOTE: If required, the primary component 2 application can be recovered on the mirror
component 1, thereby "merging" the two applications on mirror component 1.
In this example, the backup component and one mirror component share a common host, while the second
mirror component resides on its own host.
In this example, the backup server is deployed on a dedicated host. It should have adequate disk space for
the large number of replicas from all the primary components.
NOTE: A local cache is used to eliminate a communication link bottleneck. The local cache
location is configurable for every instance on the primary component, so that the RDR can use
available disk space in the most efficient way.
The RDR can be set to automatically invoke backup sessions at prescheduled times. These regular replicas
are stored cyclically on the backup component with the oldest replica deleted first. The amount of replicas
saved on the backup component is configured during instance configuration. Archive backups, which are
replicas that are not overwritten, can also be configured for each instance.
The general replication scheme is shown in the following figure.
Figure 1-4: General replication scheme
NOTE: During reverse update, the applications on both the primary and mirror components
must be shut down.
Instance name
Instance backup status idle (green) or backup (red)
Resources consumption (Memory and CPU in %)
NOTE: The RDR package must be installed in the global zone of the Oracle server along with
the EMS, OBI, and STMS.
NOTE: RDR can also be used in networks based on other EMSs such as BroadGate and ATS. In
these cases, the EMSs are not backed up by RDR but rather deployed in parallel in both the
primary and backup sites.
Where:
BDB - required minimum backup-server disk capacity for backup
EPDB - actual DB size of each primary EMS instance (NMS/XDM/STMS/SYNCOM).
ENR - number of replicas of each primary EMS instance (add 1 for the archive)
For EPDB, use the actual instance database sizes or estimate the required capacity as follows:
For each XDM NE, min. capacity per replica:
Estimate 50 MB for a backup initiated from EMS-MPT or EMS-XDM.
Estimate 60 MB for a backup initiated from LightSOFT.
For each SYNCOM NE, min. capacity per replica:
Estimate 5 MB for a backup initiated from EMS-SYNCOM or LightSOFT.
Be sure to include sufficient additional capacity for network growth.
2.2 Installation
The RDR application must be installed in every server in the global zone.
The RDR application should be installed according to the standard ECI package installation
recommendations.
NOTE: Do not attempt to mix installing a SPARC package on an x86 server or vice versa.
NOTE: SunOS, the OS Version and architecture are optional and appear when necessary.
<architecture> is SPARC or i386.
NOTE: For an STMS backup, the following items are not maintained in the DB and must be
stored and backed up separately on a Network File System (NFS) server that is mounted under
the root directory of the STMS server:
Historical counters
Software builds
If the NFS server is mounted at the same point in the file system, the standby STMS is able to
access these items.
If this is the first time that you are running the RDR, the tool informs you that there are no instances
that have been previously discovered on the Backup Server Component (BSComp).
"No discovered Primary Components data found on BSComp."
The Possible RDR modes of Activity menu is displayed.
Figure 4-3: Possible RDR modes of Activity
Manual RDR instances discovery: Manually enter the host names to be configured as primary
components.
Discover RDR instances by hosts DB: The RDR application automatically discovers the primary
components using the /etc/hosts file.
4. To automatically discover the instances from the /etc/hosts file, select 2 Discover RDR instances by
hosts DB. The discovery process begins. When finished, a list of the hosts and the number of found
instances appears.
NOTE: Before continuing with configuration, you must quit and re-enter the RDR application
in order for the updates to take effect.
NOTE: Enter the host name, not the IP. The hosts entered must be listed in the etc/hosts file.
If you enter a host that is not listed, you receive an error.
NOTE: Before continuing with configuration, you must quit and re-enter the RDR application
in order for the updates to take effect.
NOTE: Non-standard configuration, such as alternate cache location, should be done on the
primary component.
2. Enter y.
A prompt requesting the backup directory path appears.
3. Press ENTER to accept the default or enter a new path and press ENTER.
A prompt for the number of regular replicas appears.
4. Enter the number of replicas according to the desired reliability level and existing disk capacity.
For more details, see Replicas.
The defined instance parameters are listed.
NOTE: Only directories can be added to the list, not individual files.
4. To view the current pattern file, select 1-Show Current Pattern File. A list appears of the directories
to be backed up.
5. To return to the default pattern file, select 3 Reset Pattern File to Default and enter y to confirm. The
pattern file is reset to default.
3. To view the list of hosts receiving alarms, Select 3 Show Current Notification List.
The hosts receiving alarms for the selected instance are displayed.
4. To add a host to receive alarms, Select 1 Add a Display to Notification List and enter the host name to
be added.
The host is added and will receive any alarm notifications from the selected instance.
6. To remove all configured hosts, allowing only the default hosts to receive the alarms, select 4 Remove
All Configured Entries.
NOTE: The replica instance directory may be assigned to different paths in the Shadow and
Backup servers.
NOTE:
Configure the shadow backup server only after performing an initial manual backup of each
instance to test the replication process. This provides the backup data necessary to form a
shadow replica.
It is recommended to postpone shadow backup configuration until all basic components
(excluding mirror components) have been configured.
c. Enter the shadow server name or IP, and replica path, then y to confirm.
The server is assigned as a shadow server for the current instance.
3. To remove the shadow server,
a. From the RDR Instance Configuration Options menu (see Step 1), select 2 Advanced
Configurations Options.
The Advanced Configuration Options menu is displayed.
(When a shadow server is already assigned to the instance, option 2 in this menu becomes
Remove Shadow Backup Server.)
b. To remove the shadow server, select 2 Remove Shadow Backup Server and enter y at the
confirmation.
CAUTION: This action cannot be reversed. All data backups will be lost.
4. Select the primary host to remove instances. A warning appears reminding you that this action cannot
be undone.
CAUTION: All information associated with the primary component will be lost.
NOTE: In case of Primary cache relocation, you should not only share the EMS / STMS /NMS
zone with the new cache folder (in global zone), but also the Oracle zone.
3. Select an instance.
The old cache directory is displayed and you are prompted for the new cache directory location.
4. Enter the new cache directory. Be sure that there is enough space to hold the database backup. If the
directory does not exit, it is created.
5. Enter y to confirm.
NOTE: This procedure is required to share the alternate cache directory with the EMS zone.
For OBIEE, STMS, EMS-MPT, and EMS-XDM version 8.1 and higher, this procedure also needs
to be operated for the Oracle zone.
1. As user root, run the ZoneAdmin tool and select the relevant zone.
The Zone Actions Menu appears.
5. Enter y to confirm.
The directory is shared.
NOTE: To remove sharing, select 4 Remove Global Shared Directory and then reboot the
zone.
NOTE: Reverse update doesn't use an alternative mirror cache directory (if it was defined).
NOTE: Alternate cache location is not relevant for NMS, OBIEE, STMS, EMS-MPT, EMS-XDM,
and EMS-Syncom instances.
NOTE: The alternate cache location applies only for recovery actions, not for reverse update.
For information about reverse update, see Restarting the Primary Instance after Recovery
(Reverse Update).
3. Enter the required name or IP. You are asked for the cache location path.
NOTE: Large automatic database backups may impair system performance. They take time
and heavily load the system. You can avoid network congestion by assigning appropriate
offsets to each instance’s replication sessions, so that they do not run at the same time.
IMPORTANT: You Can Not perform simultaneous backup of instances (applications) using the
same Oracle DB Server.
1. From the RDR Instances list (see RDR Instances List), select a configured instance.
2. Select 3 Start Regular Backup Session.
The backup session begins.
NOTE: Only one backup session can run on a primary component at a time. If you try to run a
backup on a primary component that has another backup session in progress, you receive a
Backup Session Overrun error.
NOTE: Even though archive backups ensure additional redundancy, take into account that an
archived replica uses additional disk space.
NOTE: Scheduling a backup session is a very sensitive operation and must be performed
cautiously. Be careful to avoid scheduling conflicts and backup session overlaps.
4. Select an instance.
The types of available scheduling methods are listed.
5. Select a scheduling method and answer all the questions about scheduling. For more information, see
Backup Sched.
6. When you are finished, enter q.
The Crontab entries are listed, including the backup sessions you have just scheduled.
The pending entry is displayed in regular font with the word {pending} in red. The backups that have
already been added to Crontab are in a bold black font.
NOTE: At this point, you have only defined the scheduled backup. It is listed as a Crontab
entry with a "pending" status. It will not take effect until you append it to the Crontab as
explained in the following step.
Backup Sessions that have taken effect are applied entries and are displayed in bold.
The following table describes the options available in the RDR Scheduler menu.
Regular Backup - at Specific A regular backup, scheduled at a specific time of a specific day.
Time of the Day
Use the following illustrated examples to guide you in configuring the backup schedule:
Figure 5-1: Scheduling a regular backup at constant interval
NOTE: Before restoring from backup, make sure that the application is configured in the
target server.
NOTE: For an STMS backup, the following items are not maintained in the DB and must be
stored and backed up separately on a Network File System (NFS) server that is mounted under
the root directory of the STMS server:
Historical counters
Software builds
If the NFS server is mounted at the same point in the file system, the standby STMS is able to
access these items.
NOTE: Additional manual configuration operations may be required to provide full system
functionality on the mirror site. These operations are application specific depending on the
recovery case, RDR, and the managed network topology, and are beyond the scope of this
manual. For information, refer to the relevant application manuals and engineering
procedures.
On a system with LightSOFT and EMS(s), first start the LightSOFT server and then the EMS(s), so that each
EMS is registered on the LightSOFT server.
Upon successful completion of the recovery session, start the application in the regular way.
After the primary component is ready to be returned to operation, a Reverse Update procedure is used to
load the primary component with changes that occurred to the system when the mirror component was
active. This is described in Restarting the Primary Instance after Recovery (Reverse Update).
NOTE: When a mirror station is installed with components that do not have to be mirrored
(for example a single mirror station supporting an nms server and ems residing on two
stations), be sure to only start the relevant mirror component/s.
NOTE: When the procedure is performed on a primary component, the menu text implies
that a "mirror" component is involved. However all the steps apply to the type of component
currently being restored and the presented instance choices pertain to the current
component.
Select 3 Mirror Component Actions. The RDR Mirror Component Actions menu appears. (This
choice applies even if you are restoring to a primary component.)
NOTE: If the instance is running, the following warning appears and you cannot continue with
the restore.
"Error!!! Cannot perform recover when LightSoft Network Manager Server is running."
RDR then lists the instances available on the backup server which match the type of mirror (or
primary) instance you have selected in this step.
NOTE: The RDR lists both automatic and archive backup replicas.
6. Select a replica.
The utility compares the versions of the selected instance to recover with the one existing on the
mirror.
If they do not match, the following warning appears.
If they do match, or you selected y above, RDR displays a summary of the recovery session
defined in the previous steps. A confirmation appears.
7. Enter y to confirm.
The recovery session begins.
NOTE:
Valid mirror station configurations in the following procedures may include:
LightSOFT client on a dedicated station, OR
EMSs on a dedicated station, OR
LightSOFT server in combination with a LightSOFT client and/or EMSs
A mirror station cannot only include an active LightSOFT client and EMS(s).
When the LightSOFT client and/or EMSs must be recovered on the same mirror station as the
LightSOFT server, perform the LightSOFT server recovery procedure first.
1. Restore the required instances to the mirror component (see Starting a Mirror or Primary Recovery
Session).
2. Enable autostart for each component that will be activated by the Mirror by running the following
commands as root user:
touch /etc/ .NO_NMS_AUTO_START (Any NMS)
touch /etc/ .NO_SYN_AUTO_START (EMS-Syncom B10.100 or later)
touch /etc/ .NO_XDM_AUTO_START (EMS-XDM V5 or later)
touch /etc/ .NO_STMS_AUTO_START (STMS V4.1 or later)
touch /etc/ .NO_OBI_AUTO_START (OBIEE)
NOTE: If the same mirror station is also used to recover the LightSOFT server, perform the
LightSOFT server recovery procedure first.
In the mirror site, activate the required LightSOFT clients on the mirror component, as follows:
If only a LightSOFT client is to be activated on the mirror (the LightSOFT server remains active on
the primary site), enter /opt/NMS/client/sh/SetupNMS.sh
OR
If the LightSOFT server is distributed amongst multiple servers, select Configure NMS cluster.
OR
If both the LightSOFT server and a LightSOFT client are to be activated on the same mirror, enter
/opt/NMS/server/sh/SetupNMS.sh
No actions are required on either LightSOFT clients or EMSs on the primary site.
NOTE: If the same mirror station is also used to recover the LightSOFT server, perform the
LightSOFT server recovery procedure first.
In the mirror site, activate the required EMSs on the mirror component as follows:
1. Update ems.conf or enm.conf by modifying the expression
R &env_mtnm_ems_no EMS_INSTANCE_NUMBER ### 1 999
substituting ### with the EMS ID of the Primary EMS.
2. Update ems.conf or enm.conf by modifying the expression
S &env_ns_port ENBARH_NAMESERV_PARAMS NMSComp:5075:2
substituting NMSComp with the hostname of the station that functions as the LightSOFT server, as
follows:
If the LightSOFT server remains active on the primary component, specify the primary
component station.
If the LightSOFT server has been recovered on a mirror station, specify that station’s name.
3. Enter RegisterEMS -f NMSComp:5075:2
In place of NMSComp, substitute the hostname of the station that functions as the LightSOFT server.
4. Enter :
No actions are required on either LightSOFT clients or the LightSOFT server on the primary site.
NOTE: If the same mirror station is also used to recover the LightSOFT server, perform the
LightSOFT server recovery procedure first.
In the mirror site, activate the required EMSs on the mirror component as follows:
1. Configure the STMS using ConfigureSTMS.sh. If the STMS server was already configured, reconfigure it
(using "ConfigureSTMS.sh –U" to un-configure and then run the configuration tool). Pay attention to
the following configuration parameters:
a. is this STMS Server being integrated with ECI LightSOFT NMS? (yes / no)
if yes: )
Ensure that the instance application to be recovered is shut down on the primary component.
Ensure that the appropriate applications are correctly installed on the primary component.
NOTE: You cannot perform direct recovery after a reverse update. In such a case, a backup
should be taken.
3. RDR displays a summary of the recovery session defined in previous steps. A confirmation appears.
NOTE: Reverse update doesn't use an alternative mirror cache directory (if it was defined).
NOTE: The Reverse update feature uses the standard default cache (/var/containers/share)
and not an alternate mirror cache configured to accommodate large DBs in a multi-zone
environment; see Restoring Large Mirror Component DB with Alternate Cache Location. If the
standard cache system is insufficient for the current DB, reverse update must be performed
using a manual procedure.
Ensure that the instance application to be reverse updated is shut down on the mirror and primary
components.
Ensure that the appropriate applications are correctly installed on the primary component.
This section describes how to perform reverse update to the primary component.
After completing this procedure, you must set the other servers to recognize that the primary component
has been returned to duty in place of the mirror component.
The utility compares the versions of the selected mirror and primary instances. If they do not match, a
warning appears.
The RDR lists the details of the reverse update with a warning that the reverse update will overwrite
all current data
6. Confirm the reverse update session.
The session begins.
NOTE: This procedure is not applicable for EMS-MPT V2.1 and up.
NOTE: This procedure is not applicable for EMS-MPT V2.1 and up.
12.1 SyncMaster
RDR synchronization (replication) utility.
Function description: Performs direct replication between the primary component and backup server.
Supports regular and archive replications. Normally invoked by cron (see SetCronRDR).
Usage:SyncMaster [-i inst_name] [-dest target]
[-a] [-l] [-ll log_level] [-dd debug_level]
[ -suspend | -continue ] [-help ]
Options:
-i <instance name> Instance name.
-dest <target> Backup to specific target (replica name).
-a Archive backup.
-dd <debug_ level> Set debug level [0-3, default - 0].
-l Enable logging.
-ll <log_level> Set log level [0-3, default - 1].
-suspend Temporarily suspend activity.
-continue Resume backup activity (if suspended).
-help Print help message.
12.2 ReverseUpdate
RDR Primary component restore utility.
Functional description: Restore Primary Component from Mirror
Usage: ReverseUpdate
[-M mirror host] [-p primary_instance]
[-m mirror_instance] [-dd debug_level] [-f ] [ -help ]
Options:
M <hostname> Restore from specified mirror host.
- p <instance name> Instance on Primary Host to restore to.
- m <instance name>D Instance on Mirror Host from where to
restore.
-dd <debug_level> Set debug level [0-3], default – 0.
-f Set force (non-interactive mode).
-help Print help message.
12.3 RestartMirror
RDR restore (recovery) utility.
Functional description: Interactive utility for restoring a replica from a backup server and launching an
application on a mirror component.
Usage: RestartMirror
[-p inst_name] [-m inst_name] [-b hostname]
[-r replica] [-f] [-dd debug_level] [-help]
Options:
--p <inst_name> Primary instance name.
--m <inst_name> Mirror instance name.
-b <hostname> Backup Server from which to restore.
r <replica> Replica from which to restore.
dd <debug_level> Set debug level [0-3].
-help Print help message.