In today's global economy, enterprises maintain multiple sites across multiple time zones. These heterogeneous networking environments may be interconnected by Wide Area Networks (WAN), Network Attached Storgae (NAS), Virtual Private Networks (VPN) and the Internet. Although the individual locations may be secured within corporate firewalls, confidential proprietary data must be distributed and consolidated between the locations over insecure and often much slower connections. In this scenario, content is automatically generated on a master server. The content must then be securely distributed (using encryption) to international offices, which then act independently to allow the content to propagate to regional offices and individual systems.
An example would be an entire knowledge base that is updated on the master server, yet each regional office must have an up-to-date locally held copy. The data distribution must be transparent in every way. Interactive users and network processes must not be impacted by slow network response times and network drag due to a hyper-voluminous synchronization, and must never be able to access an incomplete file in the process of being updated. As a final security precaution, each independently administered network will not compromise network security by divulging a system username and password for the data to be replicated. The solution must be easily scalable, and flexible enough to allow the addition of heterogeneous network devices.
The Solution: Configuring RDS
VPNs:
Even over a secure Virtual Private Network (VPN), bandwidth is never used to its full capacity. The reason being that although the source and target systems may have a high bandwidth pipe to the Internet, the Internet itself is a "fuzzy cloud". The path that maximizes throughput cannot be predetermined, leaving transfer speeds at the mercy of the slowest link in the cloud. The maximum speed a given transfer can achieve may only be 20 kbps, when the source and target have a 256 kbps connection to the Internet. To overcome this problem, RDS supplies the possibility of using multiple transfer streams. Each stream will take a unique and independent path through the cloud, meaning that each parallel stream can achieve the "maximum" of 20 kbps. The result: an effective transfer speed approaching the theoretical maximum of the source and target systems.
Leased Lines And Reducing Network Strain:
The RepliWeb Deployment SuiteTM (RDS) has advanced data transport options that include asynchronous, transparent compression and bandwidth control. Leased lines are often paid for in terms of volume of data sent. Using RepliWeb Comparative Snapshot TechnologyTM (CST) in conjunction with the aforementioned compression, the data sent over the network is kept at a minimum. CST will ensure that only files that have been modified on the source are replicated, in the case when only NTFS permissions or UNIX security has changed, only the new security information will be transferred. Note that only RDS, RepliWeb's cross-platform solution, replicates to and from UNIX systems.
Using built-in compression algorithms, effective transfer rates over slow connections can be drastically increased. No user interaction is necessary to compress a file before transfer, and uncompress it afterwards: while packet 1 is being sent, packet 2 is being compressed on the source. While packet 2 is being received on the target, packet 1 is being uncompressed.
Using the bandwidth control option, RDS can dynamically or statically control the bandwidth allocated to a specific replication. For example, limiting the transfer to 5% of the available bandwidth during peak network usage hours and to 75% during off-work hours. This means increasing transfer speed when more bandwidth becomes available and decreasing it when there is more network activity. If the transfer spans outside work hours, the transfer will automatically increase to use up to 75% of the available bandwidth.
Security:
RDS can be configured to employ rule-based screening and virtual passwords. For the above scenario, a network administrator would supply the initiating node a "bogus" username and password. The 'account' supplied does not actually exist on the administrators system. When an RDS job is initiated with the bogus information, and RDS authenticates the username and password on the administrators system, the transfer will transparently be mapped to a real system account that the replication will be carried under. The initiating node has not been supplied with any real network information that could be compromised. The virtual username and password can only be used by RDS and can be restricted to read and write from a given directory. RDS can be configured to use encryption for any file transfer.
