VERITAS Storage Replicator (VSR) 2.1 SP3 readme
| Article:TECH24863 | | | Created: 2009-01-05 | | | Updated: 2009-01-05 | | | Article URL http://www.symantec.com/docs/TECH24863 |
Problem
VERITAS Storage Replicator (VSR) 2.1 SP3 readme
Solution
VERITAS Storage Replicator for Windows
Version 2.1 Service Pack 3
Readme
Copyright (c) 2003 by VERITAS Software Corporation
This Readme document contains important information about
Storage Replicator. Please read this document before you
install Storage Replicator on your production systems.
You can find more information about installing and running
Storage Replicator in the product documentation set.
----------------------------------------------------------
Contents
----------------------------------------------------------
1) Introduction
2) Service Pack Installer
3) Bug fixes since last release
4) Product Enhancements
5) Known Issues
6) Product Support Information
----------------------------------------------------------
1) Introduction
----------------------------------------------------------
Welcome to VERITAS Storage Replicator. On behalf of
the entire development team, we'd like to thank you for
purchasing our product.
If you have any comments, questions, or problems, please do
not hesitate to contact our world-class technical support team
via e-mail at helpdesk@support.veritas.com
----------------------------------------------------------
2) VSR Service Pack 3 Installation
----------------------------------------------------------
There are two installers included in this release: the 'normal' product
installer and a Service Pack installer. Each installer serves a specific
purpose and the correct installer must be used in each situation.
Installing on a machine with no previous version installed:
- Use the 'normal' product installer. This can run from the CD
Browser or by double clicking on the setup executable
<cd root>\VSR\Install\Setup.exe.
Upgrading over a VSR 2.0x version:
- Use the 'normal' product installer. This can run from the CD
Browser or by double clicking on the setup executable
<cd root>\VSR\Install\Setup.exe. Every machine in the
Replication Neighborhood needs to be upgraded to the new version
as there is no backwards compatibility between VSR 2.1x and
VSR 2.0x versions.
Upgrading over a VSR 2.1x version:
- Use the Service Pack installer. Running the 'normal' installer
will prompt to uninstall the product. The Service Pack installer
can be found on the CD in <cd root>\VSR\Service Pack. This
Service Pack installer will not upgrade a VSR 2.0x version. You
must upgrade the RMS machine before upgrading any machines that
are used to run the Administrative Console or SRToolUR.
See the 'Known Issues' section below for more installation
notes.
----------------------------------------------------------
3) Bug Fixes
----------------------------------------------------------
The following defects were fixed in this Service Pack 3
release:
1. "Event 54" system hangs. The file system filter drivers have been
updated in SP3 to fix this problem.
2. PHP Script Errors. The VSR File System Filter Drivers would cause PHP
scripts to fail. The SP3 filter drivers fix this problem.
3. "Rename into Policy" replication failures. Under some circumstances, a
file renamed from one directory not under replication to a directory
that is currently being replicated by a VSR Job in Dynamic mode would
fail to replicate to the Target. The folders would have to be on the
same volume for this to occur. This is fixed in SP3.
4. VSR could interfere with SMTP e-mail generation by IIS web servers.
Fixed in SP3.
5. Some applications that create temporary files in a particular way could
cause Synchronization to fail if the Source Server was experiencing
extremely heavy I/O loads. Fixed in SP3.
The following defects were fixed in the Service Pack 2
release:
1. Bug: RMS hangs under heavy load when there are a very
large number of Servers in a Job or a very large
number of Jobs starting and stopping at the same time.
Status: The RMS can now start and stop hundreds of Jobs
and control Jobs with 120 Replication Pairs. (See the
Known Issues section for details.)
2. Bug: Occasional failure of SrToolUR and/or the Console to
Connect to the RMS under Terminal Services.
Status: The cause was identified and fixed.
3. Bug: Access Denied during replication. These problems
would happen in both Synchronization and Continuous
replication.
Status: The Access Denied problems have been addressed in
the SP2 version.
4. Bug: VSR does not install correctly on servers that have
Services for UNIX installed.
Status: VSR 2.1 SP2 installs correctly on machines that have
Services for UNIX installed. Installing Services for
UNIX after Installing VSR will break VSR, but there is
a workaround. See the Known Issues section for details.
5. Bug: Services fail to shutdown. Under some circumstances it
was possible to get the Storage Replicator RSA and RMS
services into a state where they could not be stopped
from the Service Control Manager.
Status: The services are now fully controllable from the SCM.
6. Bug: Jobs sometimes appear to be 'stuck' in canceling or
expiring state.
Status: Notification of state changes has been streamlined
so these states are not 'sticky' anymore.
7. Bug: The Console and SrToolUR were slow to respond in
environments with large numbers of servers.
Status: The Console and SrToolUR are completely functional in
Replication Neighborhoods that contain several hundreds of
servers. See the Product Enhancements section for
details.
8. Bug: The MSCS Job Agent could hang the MSCS cluster.
Status: This would happen in a rare, but possible, condition.
The bug was identified and corrected.
9. Bug: Pattern Matching Discrepancy. In some instances, the Job
Properties window, Rules Tab, Source Tree view will
display a file as though it would be replicated (shown
in normal density) when it actually will not be
replicated and should have been displayed grayed out.
Example:
Entering a rule to include "wordp*" displays
"wordpad.exe" as being replicated, but the software
does not actually replicate it. However, including
"wordp*.*" does replicate wordpad.exe.
Status: Fixed in SP2.
----------------------------------------------------------
4) Product Enhancements
----------------------------------------------------------
The following product enhancements were included in this Service Pack 3
release:
1. Windows XP Support. VSR 2.1 SP3 contains full support for Windows XP
Professional.
2. Disable Dynamic Journaling Option added to Jobs. Disabling Dynamic
Journaling allows Publication Jobs to contain more than 63 Target
Servers.
Use this new feature with extreme care! Disabling Dynamic Journaling
will also inhibit VSR's ability to track changes to the Source data set
while Synchronization is taking place. If this data set changes on the
Source Server during synchronization and Dynamic Journaling is disabled then
the data set on the Target will not have write order fidelity. This will
result in a logically inconsistent replica on the target that will not be
fixed until the next synchronization (Job Start). This option can only be
used for Synchronization Only jobs and should be used only when access to
the source data can be limited by the administrator.
Creating Publication Jobs with more than 63 Target Servers can only be
done in the command line tool SRToolUR. The Administrative Console will
stop adding Replication Pairs at 63 regardless of the state of the Disable
Dynamic Journaling option.
Use the following commands to add a Replication Pair to a Job in
SRToolUR:
Add pair to job <Job Name> with SourceServer=<Source Server Name>,
TargetServer=<Target Server Name>
Note that the Job Name and the Server Names should all be enclosed in
double quotes.
Once the pairs are added to a Job they can be edited and manipulated
(custom target paths, bandwidth settings, etc.) in the Administrative
Console or SRToolUR.
To turn the Disable Dynamic Journaling Option on and off in SRToolUR, use
the following:
Set NoDynamicJournal of job <Job Name> to <1 or 0>
The NoDynamicJournal property can be set in the Administrative Console as
well.
3. New Monitor Jobs View Columns. There are three new columns in the
Monitor Jobs View. These columns are "Current Operation", "Next Pending
Operation", and "Last Requested Operation." These columns show actions the
RMS is taking within the jobs, what RMS actions are pending, and the last
operation requested.
4. Changing NIC cards in a server no longer changes that server's unique
identifier in the Replication Neighborhood. RSAs in previous versions of VSR
would appear in the console twice when a NIC was changed and any Replication
Jobs that reference the server would need to be edited to run correctly.
5. Viewing Job Statistics is now possible in SRToolUR. Job Statistics
include:
RunStage - Will be one of the following: NotRunning, Prescan,
Synchronization, Dynamic, Resynch, NoConnection.
WhenStageStarted - The date and time the current Run Stage started.
TotalBytesSent - The total number of bytes sent over the wire to the
Target Server for the pair being monitored.
CurrentFileSize - The size (in bytes) of the current file being
replicated to the target. This is only valid during
Synchronization.
ScannedObjectTally - The count of the number of objects (files and
directories) scanned during prescan. Valid only during
PreScan.
CurrentFileName - The name of the file currently being replicated to
the target during Synchronization. Not valid during
Dynamic replication or PreScan.
TransferRate - The aggregate data transfer rate for the pair. Valid
only during Synchronization and Dynamic replication, not
PreScan.
ResynchPctComplete - Shows how far synchronization has progressed
expressed as an integral number from zero to 100. Valid
only during Synchronization and Resynchronization, and only
if PreScan is turned on for the Job.
Resyncs - The total number of resyncs since the scheduled Job start for
this pair.
TimeTilSyncDone - The time needed to complete the Synchronization of
the pair.
Example 1:
Keep showing some pair statistic as long as the pair is Synchronizing:
loop while RunStage of pair "SRC:TRG" of job "MyJob" EQ Synchronization
!cls
get Name, CurrentFileSize, CurrentFileName of pair "SRC:TRG" of job "MyJob"
wait 1 sec
end
Example 2:
Pause a batch file until a pair goes into Dynamic replication:
rem do something here before
srtoolur -cmd wait until pair "SERVER1:SERVER2" of job "Bar" EQ Dynamic
rem do something else here after
6. The debugging logs (Picilog) is no longer truncated at server start
time. An existing Picilog is renamed and a new log is started when the
services start. The old picilog is renamed picilog.txt.prev and is left in the
same directory as the new picilog file.
The following product enhancements were included in the Service Pack 2
release:
1. Server logs have been cleaned of much redundant information
and extra entries have been added.
2. Server pair restarts are more reliable in SP2. The
protocol has been simplified for the restarting of replication
between servers after a network outage. This fix addressed a
rare but seen condition where servers would not re-start
correctly after an outage.
3. Scaling Enhancements. SP2 includes many critical
enhancements to VSR's ability to run correctly in very large-
scale installations (many hundreds of servers). Specifically:
1. Server information is now stored in the database on the
RMS enabling the Consoles and SrToolUR to startup much
faster. Job creation in the Console is now faster as well.
2. RMS Job Starts are now parallelized. If one Job takes
a long time to start it will not hold up any other jobs
that are scheduled to start at the same time.
3. The Console and SrToolUR start much faster due to a cache
loading enhancement. This can cut many seconds off the
client startup time which is particularly important when
using SrToolUR in complex Perl scripts where it might be
started many times in a loop.
4. The Console no longer shows No Credentials. The Servers
are still secure and credentials will be prompted for if
they are needed when a Server Property Sheet is opened or
a Server is added to a Job.
In general, SP2 will run comfortably in an environment with
many hundreds of machines and can handle Replication jobs of
up to 120-to-one and one-to-63. (See the 'Known Issues'
section below for more information.)
4. Diagnostic logging is now dynamically configurable. Previous
versions required a stop and start of the Storage Replicator
RSA service to turn on and off diagnostic logging. This can
now be done without a restart.
5. Better performance during very heavy I/O loads. Previous
versions would occasionally exhibit problems with very high
I/O loads, particularly on the source machine. Under some
conditions this could lead to unbounded Journal growth and a
severe slow down of the source computer. This general
issue has been addressed and is much improved in SP2.
6. The User Interface now offers the option of stopping a
job at the end of a scheduled window even if the
synchronization is not complete. Previous versions would
ignore the end of the scheduled window and complete the
synchronization before stopping.
7. VSR 2.1 SP2 now supports Windows Server Appliance Kit (SAK)
installed on NAS appliances.
8. Synchronization is much more efficient for very large files.
Dirty file regions are transmitted earlier in the
region analysis and the region size has been tuned.
----------------------------------------------------------
5) Known Issues
----------------------------------------------------------
5.0 Scaling (Job Size) Issues
1. An RSA can be the Source for only 63 Replication Pairs at
any one time. It can be the Source Server for more than
63 Replication Pairs in multiple Jobs but only 63 of those
Replication Pairs will run at any one time. For example,
The RSA can:
- be a Source in one 1-to-63 job
- be a Source in a 1-to-31 Job and
be a Source in 32 1-to-1 Jobs if these jobs are
scheduled to run at the same time
- be a Source in an unlimited number of 1-to-63 Jobs
if these Jobs are not run at the same time
If an RSA is scheduled to run in more than 63 Replication
Pairs at any one time then the first 63 of those pairs will
start and the rest will not. The pairs will start as others
stop, cancel or expire.
2. An RSA can be the target for only 120 Replication Pairs at
any one time. It can be the Target Server for more than
120 Replication Pairs in multiple Jobs but only 120 of those
Replication Pairs will run at any one time. For example,
The RSA can:
- be a Target in one 1-to-120 job
- be a Target in one 1-to-60 job and
be a Target in another 60-to-one job
- be a Target in 120 1-to-1 Jobs
- be a Target in multiple 120-to-1 Jobs
if these Jobs are not run at the same time
But the RSA cannot:
- be a Target in one 1-to-140 job
- be a Target in one 1-to-80 job and
be a Target in another 80-to-one job
if both these Jobs are run at the same time
3. The limits described in 5.0.2 are reduced to 63 if Target
Protection is enabled for all Pairs. The same rules
apply for Jobs that are not run concurrently.
4. Remember, these limitations apply to jobs that are all
running at the same time. For instance, a single RSA can
appear in thousands or Replication Pairs as a Target as long
as no more than 120 of them run at any one time. And a
single RSA can appear in thousands or Replication Pairs as
a Source as long as no more than 63 of them run at any
one time.
If this limit is exceeded then the server over the limit
will refuse the new connection and the Replication Pair
will fail to start when the job starts.
5.1 General issues
1. As a general guide, it is recommended that there is
at least 10% more disk space on the target volume than
the volume that is being replicated.
2. When choosing a custom target path, be very careful
not to select any path with data that needs to be saved.
Replication will overwrite/delete all data in the
selected directory!
3. When deploying to a remote machine, the logged in user
must have Administrator access on both machines. The server
being deployed to and the machine on which the Console is running.
4. To create or edit a replication job, the logged in user
must have Backup rights for all source and target
servers paired in the job.
5. Disabling Storage Replicator SNMP support.
If the Windows SNMP service is installed on the
computer when Storage Replicator was installed,
Storage Replicator's SNMP support will be automatically
installed. To disable Storage Replicator's
SNMP support, look for the following value in the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ExtensionAg
ents
that contains this string:
"SOFTWARE\VERITAS\Storage Replicator\2.11".
To disable SNMP support, simply delete this value.
6. Storage Replicator uses the NobleNet WinRPC product.
This product uses a Sun RPC portmapper program which
acts as a location broker for WinRPC applications.
The portmapper uses the Sun RPC well-known port.
The NobleNet Portmapper is redistributed and installed
with the Storage Replicator product.
If you are using another portmapper, The following link
explains how to configure Storage Replicator to use that
portmapper:
http://support.veritas.com/docs/233973
7. When creating or editing job file selection rules, pay careful
attention to the order of the include/exclude rules. Rules
are evaluated in-order, and so rule ordering will directly
affect which files get replicated (and which files don't!).
Please note that it is possible to create conflicting sets of
rules. To avoid such conflicts, it is recommended that all
rules and their ordering are double-check prior to running a
replication job. The following is a link to a TechNote that
addresses rules in a replication job:
http://support.veritas.com/docs/236136
8. Selection of Journal directory
The user is strongly discouraged from placing the Storage
Replicator journal files on a file system that is also a source
for replication or a system drive. Under a heavy I/O load, such a
configuration could cause the source server's performance to degrade
rapidly until the server becomes totally unresponsive and appears to
have hung.
To avoid this scenario, it is strongly recommend to configure
VSR to host its databases and journal files on volume that will
never be a replication source.
Unfortunately, nothing in the Storage Replicator installer
prevents configuring VSR in this undesirable manner.
However, after installation the location of the VSR databases
and journals can be changed through the registry if necessary.
To change where these VSR database and journal files are located,
do the following:
1. Stop the RSA service
2. Copy the VSR/Databases and VSR/Journals directories to a
new volume.
3. Change the following registry keys to reflect where the
the Databases and Journals directories were copied:
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\JournalRoot
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\ProtectedDatasetDirectory
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\UnprotectedDatasetDirectory
4. Restart the RSA service.
See the following TechNote for details:
http://support.veritas.com/docs/250866
9. Running SrToolUR from a Job post-script requires some changes to
the way the Storage Replicator RSA service is configured in
the Service Control Manager. The Storage Replicator RSA
service runs under the Local System account by default and
this account doesn't have permissions to connect to the RMS.
The following TechNote is a workaround:
http://support.veritas.com/docs/250870
10. IP Address changes while VSR is running can cause Servers
to disconnect and fail to replicate. The workaround is to
assign fixed IP addresses to the VSR RSA's or to stop and
restart the ENL and RSA (and RMS) services on the machine
after the IP address change occurs.
11. Renaming a machine can cause it to show as "Unavailable"
in the Console forever.
12. Deleting Replication Pairs from a Job can leave old selection
rules in the database. These rules have no effect on
replication but can appear in the Console.
13. Running Consoles will fail to update under some conditions
when Replication Pairs are created in a Job on another
Console. Closing and re-opening the Console will clear up
the inconsistency.
5.2 Installation issues
1. While not required, it is strongly recommended that the
Replication Management System (RMS) component is installed
before installing other Replication Service Agents (RSAs).
If the RSA is installed prior to installing the RMS, and the
RSA exists on a different subnet from the RMS, it might be
necessary to add/change a registry key on the RSA in order
for the RSA to successfully attach to the correct Replication
Neighborhood.
To do this, first stop the ENL and Storage Replicator RSA
services then change the registry key (described below), and
restart both services.
From the Services screen, stop ENL service. This will display a
warning that it will also stop the Storage Replicator RSA.
Click OK.
Using REGEDIT.EXE, locate or add this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\ENL\Network.TCPIP\GATEWAY
Set this key's value to the name or IP address of the RMS
host.
When finished, start the ENL service first, and then start
the Storage Replicator RSA service.
This is explained further in the TechNote link below:
http://support.veritas.com/docs/231017
2. It is possible to push-install an RSA across subnets using
the New Server Wizard. If you push an RSA to a subnet other
than the one where the RMS is installed then you will need to
follow the instructions in (5.2.1) or in the TechNote link
below:
http://support.veritas.com/docs/231017
3. When installing VSR, never select a storage device that is
shared among nodes of a cluster to store the database or
journal files. The VSR installer will not select these
devices by default if the shared storage devices are
configured to be used by either Microsoft Cluster Server
or VERITAS Cluster Server. If the storage devices are not
configured to be used by a cluster, the installer may
incorrectly select these devices.
Please see the TechNote http://support.veritas.com/docs/250891
for more information.
5.3 Upgrading to SP3
VSR 2.1 SP3 is RSA-Compatible with all VSR 2.1x versions. The
SP3 RSAs, however, will not function with an older RMS.
There are other compatibility and behavior issues with running
the older Consoles and SrTools with the new SP3 RMS. The
SP3 compatibility guidelines are:
1. The RMS must be upgraded first.
2. Every RSA that runs the VCS or MSCS Job or RMS Cluster
Agent must be upgraded to SP3.
3. Every machine that you use the SrToolUR or Console from must
be upgraded. Don't forget any RSA's that may be running
SrToolUR from a pre- or post-Job script - these need to be
upgraded too.
Any remaining old RSA's will continue to run in the new SP3
Replication Neighborhood but will not benefit from some of the
enhancements and bug fixes. Users are encouraged to upgrade
all RSA machines as quickly as possible.
5.4 Replication issues
1. When deleting a replicated long named file by its short
name, it may not be deleted on the target when the source
is an NT 4 machine and the target is a Windows 2000 machine.
2. Pair pre and post script commands run with the same
security context as the RxRSA service on the machine
executing the command. By default, services run without
any network rights. If the application requires any network
authentication to run in a pair script, it will fail.
SrToolUR is an example of just such an application.
Because it requires authentication with the RMS, it
cannot be run from within a pre/post job script.
The following is a link to a workaround for this issue.
http://support.veritas.com/docs/250894
5.5 Firewall Support
To replicate through a firewall, open the following TCP and
UDP ports in your firewall software.
111/TCP SUN RPC portmapper
1804/UDP RxService port 0
20481/TCP RxService port 1
20482/TCP RxService port 2
20484/TCP RxService port 3
Check the following link for the TechNote on this:
http://support.veritas.com/docs/239787
5.6 Compatibility issues
1. Storage Replicator 2.1 SP3 is not compatible with Storage
Replicator 2.0x or Seagate Software's Replication Exec
product. See section 5.3 in this document for more details.
2. Other software that utilize file system filter drivers, such as
disk defragmenter utilities, certain open file agents and
some virus protection software, should not be used with this
product as there could be conflicts. If an incompatible
product is found to be installed on a Storage Replicator
server:
1. Starting both Storage Replicator and the incompatible
product may cause the system to become unstable or crash.
2. Enabling both products at system boot time will prevent the
system from booting.
It is strongly recommended that the system is protected by
ensuring the Windows emergency repair information is current
and available. Before making any major change on a
system (for example, installing a major application), use
the Windows Repair Disk Utility to update the system's
repair information. Storage Replicator Setup prompts you
to update this information.
Storage Replicator Setup installs a file system filter
driver on the system. In the unlikely event that a product
on the system would conflict with this driver, the repair
information would allow the return of the system to its
previous configuration.
If an incompatible product is installed on the system
that is to run Storage Replicator, it will be necessary
to either disable or remove the incompatible product before
installing Storage Replicator on this system.
If Storage Replicator is already installed on the system,
do not enable or start the other product while Storage
Replicator is installed and running.
3. This product is not compatible with Computer Associates
InoculateIT Virus protection software. Storage Replicator
will not replicate files in continuous mode if the InoculateIT
software's "Enable real-time file monitor" option is turned
on. Please disable this option in InoculateIT if a job is
continuously replicating data from this server.
4. This product is not compatible with Network Associates
ViruScan for Windows versions that use a file system filter driver.
5. This product is not compatible with ArcServe for Windows
2000.
6. This product is not compatible with VERITAS Storage Migrator.
----------------------------------------------------------
6) Product Support Information
----------------------------------------------------------
Support for problems, questions, and solutions can be
obtained by using our world-class support system. Please
don't hesitate to contact one of our friendly support
specialists via e-mail to helpdesk@support.veritas.com
When contacting technical support, please be sure to include
the following information:
1) Your name
2) Your company name
3) Your phone number or e-mail address
4) A brief description of the problem
Version 2.1 Service Pack 3
Readme
Copyright (c) 2003 by VERITAS Software Corporation
This Readme document contains important information about
Storage Replicator. Please read this document before you
install Storage Replicator on your production systems.
You can find more information about installing and running
Storage Replicator in the product documentation set.
----------------------------------------------------------
Contents
----------------------------------------------------------
1) Introduction
2) Service Pack Installer
3) Bug fixes since last release
4) Product Enhancements
5) Known Issues
6) Product Support Information
----------------------------------------------------------
1) Introduction
----------------------------------------------------------
Welcome to VERITAS Storage Replicator. On behalf of
the entire development team, we'd like to thank you for
purchasing our product.
If you have any comments, questions, or problems, please do
not hesitate to contact our world-class technical support team
via e-mail at helpdesk@support.veritas.com
----------------------------------------------------------
2) VSR Service Pack 3 Installation
----------------------------------------------------------
There are two installers included in this release: the 'normal' product
installer and a Service Pack installer. Each installer serves a specific
purpose and the correct installer must be used in each situation.
Installing on a machine with no previous version installed:
- Use the 'normal' product installer. This can run from the CD
Browser or by double clicking on the setup executable
<cd root>\VSR\Install\Setup.exe.
Upgrading over a VSR 2.0x version:
- Use the 'normal' product installer. This can run from the CD
Browser or by double clicking on the setup executable
<cd root>\VSR\Install\Setup.exe. Every machine in the
Replication Neighborhood needs to be upgraded to the new version
as there is no backwards compatibility between VSR 2.1x and
VSR 2.0x versions.
Upgrading over a VSR 2.1x version:
- Use the Service Pack installer. Running the 'normal' installer
will prompt to uninstall the product. The Service Pack installer
can be found on the CD in <cd root>\VSR\Service Pack. This
Service Pack installer will not upgrade a VSR 2.0x version. You
must upgrade the RMS machine before upgrading any machines that
are used to run the Administrative Console or SRToolUR.
See the 'Known Issues' section below for more installation
notes.
----------------------------------------------------------
3) Bug Fixes
----------------------------------------------------------
The following defects were fixed in this Service Pack 3
release:
1. "Event 54" system hangs. The file system filter drivers have been
updated in SP3 to fix this problem.
2. PHP Script Errors. The VSR File System Filter Drivers would cause PHP
scripts to fail. The SP3 filter drivers fix this problem.
3. "Rename into Policy" replication failures. Under some circumstances, a
file renamed from one directory not under replication to a directory
that is currently being replicated by a VSR Job in Dynamic mode would
fail to replicate to the Target. The folders would have to be on the
same volume for this to occur. This is fixed in SP3.
4. VSR could interfere with SMTP e-mail generation by IIS web servers.
Fixed in SP3.
5. Some applications that create temporary files in a particular way could
cause Synchronization to fail if the Source Server was experiencing
extremely heavy I/O loads. Fixed in SP3.
The following defects were fixed in the Service Pack 2
release:
1. Bug: RMS hangs under heavy load when there are a very
large number of Servers in a Job or a very large
number of Jobs starting and stopping at the same time.
Status: The RMS can now start and stop hundreds of Jobs
and control Jobs with 120 Replication Pairs. (See the
Known Issues section for details.)
2. Bug: Occasional failure of SrToolUR and/or the Console to
Connect to the RMS under Terminal Services.
Status: The cause was identified and fixed.
3. Bug: Access Denied during replication. These problems
would happen in both Synchronization and Continuous
replication.
Status: The Access Denied problems have been addressed in
the SP2 version.
4. Bug: VSR does not install correctly on servers that have
Services for UNIX installed.
Status: VSR 2.1 SP2 installs correctly on machines that have
Services for UNIX installed. Installing Services for
UNIX after Installing VSR will break VSR, but there is
a workaround. See the Known Issues section for details.
5. Bug: Services fail to shutdown. Under some circumstances it
was possible to get the Storage Replicator RSA and RMS
services into a state where they could not be stopped
from the Service Control Manager.
Status: The services are now fully controllable from the SCM.
6. Bug: Jobs sometimes appear to be 'stuck' in canceling or
expiring state.
Status: Notification of state changes has been streamlined
so these states are not 'sticky' anymore.
7. Bug: The Console and SrToolUR were slow to respond in
environments with large numbers of servers.
Status: The Console and SrToolUR are completely functional in
Replication Neighborhoods that contain several hundreds of
servers. See the Product Enhancements section for
details.
8. Bug: The MSCS Job Agent could hang the MSCS cluster.
Status: This would happen in a rare, but possible, condition.
The bug was identified and corrected.
9. Bug: Pattern Matching Discrepancy. In some instances, the Job
Properties window, Rules Tab, Source Tree view will
display a file as though it would be replicated (shown
in normal density) when it actually will not be
replicated and should have been displayed grayed out.
Example:
Entering a rule to include "wordp*" displays
"wordpad.exe" as being replicated, but the software
does not actually replicate it. However, including
"wordp*.*" does replicate wordpad.exe.
Status: Fixed in SP2.
----------------------------------------------------------
4) Product Enhancements
----------------------------------------------------------
The following product enhancements were included in this Service Pack 3
release:
1. Windows XP Support. VSR 2.1 SP3 contains full support for Windows XP
Professional.
2. Disable Dynamic Journaling Option added to Jobs. Disabling Dynamic
Journaling allows Publication Jobs to contain more than 63 Target
Servers.
Use this new feature with extreme care! Disabling Dynamic Journaling
will also inhibit VSR's ability to track changes to the Source data set
while Synchronization is taking place. If this data set changes on the
Source Server during synchronization and Dynamic Journaling is disabled then
the data set on the Target will not have write order fidelity. This will
result in a logically inconsistent replica on the target that will not be
fixed until the next synchronization (Job Start). This option can only be
used for Synchronization Only jobs and should be used only when access to
the source data can be limited by the administrator.
Creating Publication Jobs with more than 63 Target Servers can only be
done in the command line tool SRToolUR. The Administrative Console will
stop adding Replication Pairs at 63 regardless of the state of the Disable
Dynamic Journaling option.
Use the following commands to add a Replication Pair to a Job in
SRToolUR:
Add pair to job <Job Name> with SourceServer=<Source Server Name>,
TargetServer=<Target Server Name>
Note that the Job Name and the Server Names should all be enclosed in
double quotes.
Once the pairs are added to a Job they can be edited and manipulated
(custom target paths, bandwidth settings, etc.) in the Administrative
Console or SRToolUR.
To turn the Disable Dynamic Journaling Option on and off in SRToolUR, use
the following:
Set NoDynamicJournal of job <Job Name> to <1 or 0>
The NoDynamicJournal property can be set in the Administrative Console as
well.
3. New Monitor Jobs View Columns. There are three new columns in the
Monitor Jobs View. These columns are "Current Operation", "Next Pending
Operation", and "Last Requested Operation." These columns show actions the
RMS is taking within the jobs, what RMS actions are pending, and the last
operation requested.
4. Changing NIC cards in a server no longer changes that server's unique
identifier in the Replication Neighborhood. RSAs in previous versions of VSR
would appear in the console twice when a NIC was changed and any Replication
Jobs that reference the server would need to be edited to run correctly.
5. Viewing Job Statistics is now possible in SRToolUR. Job Statistics
include:
RunStage - Will be one of the following: NotRunning, Prescan,
Synchronization, Dynamic, Resynch, NoConnection.
WhenStageStarted - The date and time the current Run Stage started.
TotalBytesSent - The total number of bytes sent over the wire to the
Target Server for the pair being monitored.
CurrentFileSize - The size (in bytes) of the current file being
replicated to the target. This is only valid during
Synchronization.
ScannedObjectTally - The count of the number of objects (files and
directories) scanned during prescan. Valid only during
PreScan.
CurrentFileName - The name of the file currently being replicated to
the target during Synchronization. Not valid during
Dynamic replication or PreScan.
TransferRate - The aggregate data transfer rate for the pair. Valid
only during Synchronization and Dynamic replication, not
PreScan.
ResynchPctComplete - Shows how far synchronization has progressed
expressed as an integral number from zero to 100. Valid
only during Synchronization and Resynchronization, and only
if PreScan is turned on for the Job.
Resyncs - The total number of resyncs since the scheduled Job start for
this pair.
TimeTilSyncDone - The time needed to complete the Synchronization of
the pair.
Example 1:
Keep showing some pair statistic as long as the pair is Synchronizing:
loop while RunStage of pair "SRC:TRG" of job "MyJob" EQ Synchronization
!cls
get Name, CurrentFileSize, CurrentFileName of pair "SRC:TRG" of job "MyJob"
wait 1 sec
end
Example 2:
Pause a batch file until a pair goes into Dynamic replication:
rem do something here before
srtoolur -cmd wait until pair "SERVER1:SERVER2" of job "Bar" EQ Dynamic
rem do something else here after
6. The debugging logs (Picilog) is no longer truncated at server start
time. An existing Picilog is renamed and a new log is started when the
services start. The old picilog is renamed picilog.txt.prev and is left in the
same directory as the new picilog file.
The following product enhancements were included in the Service Pack 2
release:
1. Server logs have been cleaned of much redundant information
and extra entries have been added.
2. Server pair restarts are more reliable in SP2. The
protocol has been simplified for the restarting of replication
between servers after a network outage. This fix addressed a
rare but seen condition where servers would not re-start
correctly after an outage.
3. Scaling Enhancements. SP2 includes many critical
enhancements to VSR's ability to run correctly in very large-
scale installations (many hundreds of servers). Specifically:
1. Server information is now stored in the database on the
RMS enabling the Consoles and SrToolUR to startup much
faster. Job creation in the Console is now faster as well.
2. RMS Job Starts are now parallelized. If one Job takes
a long time to start it will not hold up any other jobs
that are scheduled to start at the same time.
3. The Console and SrToolUR start much faster due to a cache
loading enhancement. This can cut many seconds off the
client startup time which is particularly important when
using SrToolUR in complex Perl scripts where it might be
started many times in a loop.
4. The Console no longer shows No Credentials. The Servers
are still secure and credentials will be prompted for if
they are needed when a Server Property Sheet is opened or
a Server is added to a Job.
In general, SP2 will run comfortably in an environment with
many hundreds of machines and can handle Replication jobs of
up to 120-to-one and one-to-63. (See the 'Known Issues'
section below for more information.)
4. Diagnostic logging is now dynamically configurable. Previous
versions required a stop and start of the Storage Replicator
RSA service to turn on and off diagnostic logging. This can
now be done without a restart.
5. Better performance during very heavy I/O loads. Previous
versions would occasionally exhibit problems with very high
I/O loads, particularly on the source machine. Under some
conditions this could lead to unbounded Journal growth and a
severe slow down of the source computer. This general
issue has been addressed and is much improved in SP2.
6. The User Interface now offers the option of stopping a
job at the end of a scheduled window even if the
synchronization is not complete. Previous versions would
ignore the end of the scheduled window and complete the
synchronization before stopping.
7. VSR 2.1 SP2 now supports Windows Server Appliance Kit (SAK)
installed on NAS appliances.
8. Synchronization is much more efficient for very large files.
Dirty file regions are transmitted earlier in the
region analysis and the region size has been tuned.
----------------------------------------------------------
5) Known Issues
----------------------------------------------------------
5.0 Scaling (Job Size) Issues
1. An RSA can be the Source for only 63 Replication Pairs at
any one time. It can be the Source Server for more than
63 Replication Pairs in multiple Jobs but only 63 of those
Replication Pairs will run at any one time. For example,
The RSA can:
- be a Source in one 1-to-63 job
- be a Source in a 1-to-31 Job and
be a Source in 32 1-to-1 Jobs if these jobs are
scheduled to run at the same time
- be a Source in an unlimited number of 1-to-63 Jobs
if these Jobs are not run at the same time
If an RSA is scheduled to run in more than 63 Replication
Pairs at any one time then the first 63 of those pairs will
start and the rest will not. The pairs will start as others
stop, cancel or expire.
2. An RSA can be the target for only 120 Replication Pairs at
any one time. It can be the Target Server for more than
120 Replication Pairs in multiple Jobs but only 120 of those
Replication Pairs will run at any one time. For example,
The RSA can:
- be a Target in one 1-to-120 job
- be a Target in one 1-to-60 job and
be a Target in another 60-to-one job
- be a Target in 120 1-to-1 Jobs
- be a Target in multiple 120-to-1 Jobs
if these Jobs are not run at the same time
But the RSA cannot:
- be a Target in one 1-to-140 job
- be a Target in one 1-to-80 job and
be a Target in another 80-to-one job
if both these Jobs are run at the same time
3. The limits described in 5.0.2 are reduced to 63 if Target
Protection is enabled for all Pairs. The same rules
apply for Jobs that are not run concurrently.
4. Remember, these limitations apply to jobs that are all
running at the same time. For instance, a single RSA can
appear in thousands or Replication Pairs as a Target as long
as no more than 120 of them run at any one time. And a
single RSA can appear in thousands or Replication Pairs as
a Source as long as no more than 63 of them run at any
one time.
If this limit is exceeded then the server over the limit
will refuse the new connection and the Replication Pair
will fail to start when the job starts.
5.1 General issues
1. As a general guide, it is recommended that there is
at least 10% more disk space on the target volume than
the volume that is being replicated.
2. When choosing a custom target path, be very careful
not to select any path with data that needs to be saved.
Replication will overwrite/delete all data in the
selected directory!
3. When deploying to a remote machine, the logged in user
must have Administrator access on both machines. The server
being deployed to and the machine on which the Console is running.
4. To create or edit a replication job, the logged in user
must have Backup rights for all source and target
servers paired in the job.
5. Disabling Storage Replicator SNMP support.
If the Windows SNMP service is installed on the
computer when Storage Replicator was installed,
Storage Replicator's SNMP support will be automatically
installed. To disable Storage Replicator's
SNMP support, look for the following value in the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ExtensionAg
ents
that contains this string:
"SOFTWARE\VERITAS\Storage Replicator\2.11".
To disable SNMP support, simply delete this value.
6. Storage Replicator uses the NobleNet WinRPC product.
This product uses a Sun RPC portmapper program which
acts as a location broker for WinRPC applications.
The portmapper uses the Sun RPC well-known port.
The NobleNet Portmapper is redistributed and installed
with the Storage Replicator product.
If you are using another portmapper, The following link
explains how to configure Storage Replicator to use that
portmapper:
http://support.veritas.com/docs/233973
7. When creating or editing job file selection rules, pay careful
attention to the order of the include/exclude rules. Rules
are evaluated in-order, and so rule ordering will directly
affect which files get replicated (and which files don't!).
Please note that it is possible to create conflicting sets of
rules. To avoid such conflicts, it is recommended that all
rules and their ordering are double-check prior to running a
replication job. The following is a link to a TechNote that
addresses rules in a replication job:
http://support.veritas.com/docs/236136
8. Selection of Journal directory
The user is strongly discouraged from placing the Storage
Replicator journal files on a file system that is also a source
for replication or a system drive. Under a heavy I/O load, such a
configuration could cause the source server's performance to degrade
rapidly until the server becomes totally unresponsive and appears to
have hung.
To avoid this scenario, it is strongly recommend to configure
VSR to host its databases and journal files on volume that will
never be a replication source.
Unfortunately, nothing in the Storage Replicator installer
prevents configuring VSR in this undesirable manner.
However, after installation the location of the VSR databases
and journals can be changed through the registry if necessary.
To change where these VSR database and journal files are located,
do the following:
1. Stop the RSA service
2. Copy the VSR/Databases and VSR/Journals directories to a
new volume.
3. Change the following registry keys to reflect where the
the Databases and Journals directories were copied:
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\JournalRoot
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\ProtectedDatasetDirectory
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\UnprotectedDatasetDirectory
4. Restart the RSA service.
See the following TechNote for details:
http://support.veritas.com/docs/250866
9. Running SrToolUR from a Job post-script requires some changes to
the way the Storage Replicator RSA service is configured in
the Service Control Manager. The Storage Replicator RSA
service runs under the Local System account by default and
this account doesn't have permissions to connect to the RMS.
The following TechNote is a workaround:
http://support.veritas.com/docs/250870
10. IP Address changes while VSR is running can cause Servers
to disconnect and fail to replicate. The workaround is to
assign fixed IP addresses to the VSR RSA's or to stop and
restart the ENL and RSA (and RMS) services on the machine
after the IP address change occurs.
11. Renaming a machine can cause it to show as "Unavailable"
in the Console forever.
12. Deleting Replication Pairs from a Job can leave old selection
rules in the database. These rules have no effect on
replication but can appear in the Console.
13. Running Consoles will fail to update under some conditions
when Replication Pairs are created in a Job on another
Console. Closing and re-opening the Console will clear up
the inconsistency.
5.2 Installation issues
1. While not required, it is strongly recommended that the
Replication Management System (RMS) component is installed
before installing other Replication Service Agents (RSAs).
If the RSA is installed prior to installing the RMS, and the
RSA exists on a different subnet from the RMS, it might be
necessary to add/change a registry key on the RSA in order
for the RSA to successfully attach to the correct Replication
Neighborhood.
To do this, first stop the ENL and Storage Replicator RSA
services then change the registry key (described below), and
restart both services.
From the Services screen, stop ENL service. This will display a
warning that it will also stop the Storage Replicator RSA.
Click OK.
Using REGEDIT.EXE, locate or add this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\ENL\Network.TCPIP\GATEWAY
Set this key's value to the name or IP address of the RMS
host.
When finished, start the ENL service first, and then start
the Storage Replicator RSA service.
This is explained further in the TechNote link below:
http://support.veritas.com/docs/231017
2. It is possible to push-install an RSA across subnets using
the New Server Wizard. If you push an RSA to a subnet other
than the one where the RMS is installed then you will need to
follow the instructions in (5.2.1) or in the TechNote link
below:
http://support.veritas.com/docs/231017
3. When installing VSR, never select a storage device that is
shared among nodes of a cluster to store the database or
journal files. The VSR installer will not select these
devices by default if the shared storage devices are
configured to be used by either Microsoft Cluster Server
or VERITAS Cluster Server. If the storage devices are not
configured to be used by a cluster, the installer may
incorrectly select these devices.
Please see the TechNote http://support.veritas.com/docs/250891
for more information.
5.3 Upgrading to SP3
VSR 2.1 SP3 is RSA-Compatible with all VSR 2.1x versions. The
SP3 RSAs, however, will not function with an older RMS.
There are other compatibility and behavior issues with running
the older Consoles and SrTools with the new SP3 RMS. The
SP3 compatibility guidelines are:
1. The RMS must be upgraded first.
2. Every RSA that runs the VCS or MSCS Job or RMS Cluster
Agent must be upgraded to SP3.
3. Every machine that you use the SrToolUR or Console from must
be upgraded. Don't forget any RSA's that may be running
SrToolUR from a pre- or post-Job script - these need to be
upgraded too.
Any remaining old RSA's will continue to run in the new SP3
Replication Neighborhood but will not benefit from some of the
enhancements and bug fixes. Users are encouraged to upgrade
all RSA machines as quickly as possible.
5.4 Replication issues
1. When deleting a replicated long named file by its short
name, it may not be deleted on the target when the source
is an NT 4 machine and the target is a Windows 2000 machine.
2. Pair pre and post script commands run with the same
security context as the RxRSA service on the machine
executing the command. By default, services run without
any network rights. If the application requires any network
authentication to run in a pair script, it will fail.
SrToolUR is an example of just such an application.
Because it requires authentication with the RMS, it
cannot be run from within a pre/post job script.
The following is a link to a workaround for this issue.
http://support.veritas.com/docs/250894
5.5 Firewall Support
To replicate through a firewall, open the following TCP and
UDP ports in your firewall software.
111/TCP SUN RPC portmapper
1804/UDP RxService port 0
20481/TCP RxService port 1
20482/TCP RxService port 2
20484/TCP RxService port 3
Check the following link for the TechNote on this:
http://support.veritas.com/docs/239787
5.6 Compatibility issues
1. Storage Replicator 2.1 SP3 is not compatible with Storage
Replicator 2.0x or Seagate Software's Replication Exec
product. See section 5.3 in this document for more details.
2. Other software that utilize file system filter drivers, such as
disk defragmenter utilities, certain open file agents and
some virus protection software, should not be used with this
product as there could be conflicts. If an incompatible
product is found to be installed on a Storage Replicator
server:
1. Starting both Storage Replicator and the incompatible
product may cause the system to become unstable or crash.
2. Enabling both products at system boot time will prevent the
system from booting.
It is strongly recommended that the system is protected by
ensuring the Windows emergency repair information is current
and available. Before making any major change on a
system (for example, installing a major application), use
the Windows Repair Disk Utility to update the system's
repair information. Storage Replicator Setup prompts you
to update this information.
Storage Replicator Setup installs a file system filter
driver on the system. In the unlikely event that a product
on the system would conflict with this driver, the repair
information would allow the return of the system to its
previous configuration.
If an incompatible product is installed on the system
that is to run Storage Replicator, it will be necessary
to either disable or remove the incompatible product before
installing Storage Replicator on this system.
If Storage Replicator is already installed on the system,
do not enable or start the other product while Storage
Replicator is installed and running.
3. This product is not compatible with Computer Associates
InoculateIT Virus protection software. Storage Replicator
will not replicate files in continuous mode if the InoculateIT
software's "Enable real-time file monitor" option is turned
on. Please disable this option in InoculateIT if a job is
continuously replicating data from this server.
4. This product is not compatible with Network Associates
ViruScan for Windows versions that use a file system filter driver.
5. This product is not compatible with ArcServe for Windows
2000.
6. This product is not compatible with VERITAS Storage Migrator.
----------------------------------------------------------
6) Product Support Information
----------------------------------------------------------
Support for problems, questions, and solutions can be
obtained by using our world-class support system. Please
don't hesitate to contact one of our friendly support
specialists via e-mail to helpdesk@support.veritas.com
When contacting technical support, please be sure to include
the following information:
1) Your name
2) Your company name
3) Your phone number or e-mail address
4) A brief description of the problem
|
|
Related Articles
Legacy ID
256977
Article URL http://www.symantec.com/docs/TECH24863
Terms of use for this information are found in Legal Notices
Thank you.