Scenario 3
If you are not using a load balancer, or do not want to set up your replication system to work through a load balancer, then you can set up replication to work with a single specific web front-end at all times. In this case, our target Replicator is configured to communicate directly to the server where Replicator is installed, WFE1 in our example. WFE1 is the only front-end that will service Replicator requests, meaning we do not need or use the IIS virtual directories on WFE2 or WFE3. A load balancer can still be used to redirect normal web traffic coming to http://wfe.
The disadvantage of such a configuration is that you limit your system to a single WFE for all Replicator requests. This can add additional strain onto that single WFE and could therefore affect the performance of replication, or clients accessing that server.
Multiple Replicator Engines
With Metalogix Replicator Enterprise Edition, you can install Replicator on multiple front-end servers in the same farm. The benefit of doing so is:
·Instead of one server managing the load of creating and applying events, the load can be distributed over multiple web front-end servers.
·In the event that the front-end server where the Replicator services are running becomes unavailable because of an outage, then Replicator will continue to create and apply packages using the Replicator services on the other web front-end servers.
|
|
NOTE: Replicator is designed to continue capturing events as they occur, even if the front- end server running the services is not available. These events will merely be captured and placed in a queue until the server is back up and able to replicate them. |
Parallel Processing
Parallel processing involves the use of multiple threads in order to perform various computing actions simultaneously. The number of threads available determines the number of actions that can be run at the same time.
Parallel processing involves the handing of tasks simultaneously. However, it is important to note that some tasks must occur in sequence. For example, within a site we process all events in the order that they are captured, on the outbound, and the order that they are received, on the inbound. One thread is therefore used within a site to perform this processing. When a list is added, it must be processed prior to the addition of an item to that list, so that there is a list present on the target to add the item to. This means that a thread will be used to process the addition of the list, and once this processing is completed, the same thread will be able to process the addition of an item to that list. These two cannot be performed simultaneously, and therefore do not require the use of more than one thread, the same thread.
Threads
As mentioned previously, the number of threads available, determines the number of actions that can be run at the same time.
Vertical Scaling of your environment allows you to have multiple threads on a server. Having multiple threads is convenient for simultaneously performing multiple tasks.
This is particularly useful when dealing with multiple site collections or sites. With multiple site collections or sites, you can have a different thread performing the processing for each site.
Replication functions optimally if it is capable of handling inbound and outbound processing on a web application simultaneously. For instance, in the following environment, an outbound event leaving Corporate has one thread available for processing, labeled T1, and an inbound event coming into Corporate from London has one thread available for processing, labeled T2. In total two threads are available for real-time bidirectional replication to take place. This environment would function with one available thread as well; however, processing would take longer as the same thread would be required to process outbound and inbound events on the web application.
If we add another farm into the mix, then replication may be slower with just two threads. In such a scenario Replicator will wait for all outbound processing to finish before inbound packages can be applied. This in turn slows down replication.
In the following scenario two threads may cause for slower processing, as an outbound event would require one thread to handle sending the package to London from Corporate, labeled T1, and another thread to send the package to Hong Kong from Corporate, labeled T2. This means that the threads are not available to processing potential incoming packages from London or Hong Kong, until outbound processing as completed. This in turn hinders the pace of replication, causing it to be slower.
In Replicator, the number of threads available for parallel processing is determined by the edition of Replicator. Express edition has 1 available thread, Standard has 2, and Enterprise has a default of 10 threads running on each replication engine, with the ability to increase to an unlimited amount of threads.