Replication duplicates data between databases on separate sites so that both databases contain the same information. If one database fails, you can manage the entire site by using the information on the database from another site.
A replication partner is a management server on another site with a different database and management server(s). A site may have as many partners as needed. Each partner, or remote site, connects to the main site or local site, which is the site that you are logged on to. All sites that are set up as partners are considered to be on the same site farm.
Each site with which you replicate data is either a replication partner or a site partner. Both replication partners and site partners use multiple servers, but the database they use and the way they communicate is different.
- Replication causes data to be transferred or forwarded to another SEPM.
- A replication partner is a SEPM that is part of another site.
- Sites can have multiple replication partners.
- Changes made on any partner are replicated to all sites.
- Policies and groups are replicated.
- Replication between any version of SQL Server data base and the embedded database is supported.
Before setting up replication
Consider the following when you plan for replication:
- Minimum number of sites
Ideally, keep the number of sites below five (5).
- Network bandwidth and link capabilities
- Network latency
- The size of the database on the primary site
- The presence of a firewall, proxy, router, or other similar types of hardware between two sites
- Whether the firewalls or routers have a packet-scanning mechanism built in
This mechanism can strip the zip files that are passed between replication partners.
Sizing the replication server
A replication server requires a larger database than a single-server installation. The increased size requirements for the replication server include the following factors:
- Number of managed clients
- Client installation package sizes retained in the database
- Number of log files retained
- Database maintenance settings
- Log size and expiration timeframes
- Definition update sizes
- Database backup information requirements
In general, you should expect the hard disk requirements for the replication server to be at least three times the hard disk space used by the original Symantec Endpoint Protection Manager for the initial replication.
See the Sizing and Scalability Best Practices White Paper for more information.
Adding a new site to an existing replication partner
- Make sure the replication schedule is not set to Automatic.
- Make sure the LiveUpdate schedule is not set to Continuous or Every 4 hours.
- Replication should not overlap with a scheduled LiveUpdate session.
- Lower the count of content revisions in the LiveUpdate settings.
Note: A lower number of content revisions increases the likelihood that a client requests a full set of definitions. If many clients request a full set of definitions from SEPM at once, you may experience bandwidth issues.
- Purge the SEPM logs.
- Do not use more than 10 replication partners.
Review the SEPM system requirements for the version of Symantec Endpoint Protection that you use.
- For more than 3 sites or 1000 clients, do not schedule replication more frequently than once per day.
- The SEPMs must be the same version. SEP 12.1 replication does not occur if the schemas do not match.
- Replication schedules should not overlap.
- If replication occurs over a Wide Area Network (WAN), only replicate the logs.
- Ideally, you should keep the number of replicated sites below 5. The ratio would be 1:4; i.e. 1 primary site, 4 secondary sites.
- Set the value of Content revisions to keep to a lower value, for versions earlier than 12.1.5.
- If you have configured multiple replication partners, then make sure that the replication schedules do not overlap. This situation can lead to database deadlock issues.
- Delete replication partners when:
- Upgrading the SEPM from SEP 11.x to 12.1.x.
- Updating the SEPM server certificate.
- You need to execute Support-supported tools.
- You perform software or hardware maintenance on the SEPM.
- Backing up database manually.
Gather troubleshooting information
Gather the following information to assist with troubleshooting:
- Tomcat logs from both sites
- Tomcat logs from the primary site (Site 1) and Install Error logs from the secondary site (New Site), if the initial replication fails
- IP addresses and server names
- Database backup (SQL Server or embedded)
- Wireshark logs to check for network issues
- SymHelp tool logs (full data) from all the sites
Replication initiates if there is any change in the Update Sequence Number (USN). Every record in the database is associated with a USN. The USN increments/updates every time there is a change in the records. Data comparison happens on the basis of the USN. The USN defines whether a record is to be added or modified.
Note: You can use replication to move SEPM from one machine to another; however, this method is not recommended because it eliminates the primary SEPM on the site, The primary SEPM allows you to establish replication on a site. Without the primary SEPM, you cannot establish any future replication partnerships.
Replication in 12.1 and later
For SEP 11, you had to break replication between SEPMs by deleting replication partners before perform a SEPM upgrade. Failure to break replication could result in corrupt databases. SEP 11 replication did not perform version checking. SEP 12.1 and later prevents the need to disable replication prior to upgrade. Starting with SEP 12.1, replication performs version checking, and eliminates cross-version replication corruption.
Note: When you upgrade from SEP 11 to SEP 12.1, you must still break replication.
Additional replication resources
See Setting up sites and replication.