Datasheet
everRun® Extend
Enabling disaster recovery of fault tolerant applications across sites connected via a WAN, using asynchronous replication
Whether caused by nature, mechanical or power failure, or human error, disasters can result in the total loss of all computing resources in a facility, potentially leaving your business unable to function for days, or even weeks. With Stratus® everRun® Extend, powered by Arcserve Continuous Availability, you can combine system redundancy with wide area network-based disaster recovery to maintain a hot stand-by system located in remote site.
Arcserve Continuous Availability software extends the core capabilities of Stratus everRun software to support disaster recovery (DR) capabilities across a wide area network (WAN), in conjunction with system redundancy in either, or both, primary site and remote DR site.
Key Benefits
- Ensure business continuity: Protect critical applications and data against site-wide disasters
- Simplify deployment and management: Use the intuitive Scenario Builder and Control Service to make set up, configuration and management quick and easy
- Pay for only what you need: Choose from three different configurations that match your physical and virtual requirements
How it fits with everRun
everRun protects customers from server failures, or other system or network component failures. Arcserve Continuous Availability provides disaster recovery in the event of site disasters. The most typical customer configuration includes an everRun system running in a primary site, and a Windows or Linux system running on a single physical machine in a secondary DR site. Arcserve Continuous Availability provides DR between the primary and DR site (also called the Master and Replica). Some customers also maintain everRun systems at their DR site, to ensure high availability after a disaster recovery scenario is executed.
The Arcserve DR software is installed in the Windows or Linux system to protect the applications running on that system. It is a complementary and layered product for the everRun product suite. The Windows/Linux system can run on a physical machine, on a virtual machine (e.g. on VMware) or a Windows/Linux system running in an everRun Protected Virtual Machine (PVM).
Arcserve Continuous Availability also is installed in a Windows/ Linux system at the remote DR site. This can also be a Windows/Linux system running on a physical machine, on a virtual machine (e.g. on VMware) or a Windows/Linux system running in an everRun Protected Virtual Machine (PVM).
Three configurations are possible:
1. V2P: The primary site has the application running in an everRun PVM and the DR site has the application running on a non-everRun system.
2. V2V: Both sites have the application running in an everRun PVM.
3. P2P: Both sites have the application running in a Windows/Linux system running on a physical machine or non-everRun system.
The same software is used to enable and deliver all three configurations. But, the licensing costs for these three configurations vary. There is no difference in the capabilities and functions for these three configurations, aside from the differences outlined above.
How it is set up
A system is set up in the primary site to run the application to be protected. Another system is set up in the DR site to run the application. Either system can be an everRun or non-everRun VM or physical Windows/Linux system. The application is loaded on both sides and the Arcserve engine is loaded in the operating system on both sides. A WAN connection is set up for Arcserve to use for the purposes explained below.
During normal processing, the Arcserve software performs real-time and immediate asynchronous replication of all application data, between the primary site and the DR site. The primary site runs the active application. The DR site does not run the application and is simply being kept up to date in order to be able to take over from the primary site when needed.
When the primary site has a complete failure, the Arcserve software will execute a DR scenario, which brings the DR site up on the network with the identity of the primary site, and restarts applications using up-to-date copies of data.
A separate component, the Control Service module, is installed on a standalone machine (physical or virtual). The Control Service can be replicated for high availability. The fail-over scenario, which drives the fail-over from a primary server to the DR server and back (when needed), is executed from the Control Service.
The Control Service is the central controlling system and users/system managers can use a Manager interface, which is browser based, to connect to the Control Service, and have visibility and control over their entire configuration.
The Control Service functions as the single point of control of the Arcserve recovery and fail-over operation, and it contains the data of the existing scenario. The Control Service manages all scenario-related tasks, and the Managers that are connected to it enable you to monitor Arcserve activities. To overcome the danger of losing the Control Service data, or losing the ability to manage and monitor your scenarios, Arcserve Continuous Availability offers you replication (redundancy) and fail-over for the Control Service to assure very high availability of the Control Service data and functionality.
Technical details
1. Maximum distance between the two servers:
- There is no maximum distance. The two servers are connected via a WAN.
2. Extra hardware requirements for the Windows systems in the primary and the DR site:
- None. Two systems (Standard Windows/Linux server or everRun based system) properly configured to run the application, can have Arcserve added without any additional hardware.
3. Software requirements for the Windows systems in the primary and the DR site:
- Windows Server 2019, Windows 2016, 2012 R2, 2012, 2008 R2, 2008.
4. Software requirements for the Linux systems in the primary and the DR site:
- Red Hat 7.4 – 7.7, 6.8 – 6.10, CentOS 6.8-6.10, 7.4-7.6, SUSE Enterprise Server 11 SP4, 12 SP2-SP4, 15, Oracle Linux 7.4-7.6, 6.8-6.10.
5. Hardware/OS requirements for Control Service system:
- Windows Server 2019, Windows Server 2016, 2012 R2, 2012.
6. Minimum bandwidth for the WAN connections between the two servers:
- Adequate to carry the file/database updates sent over from the primary to the DR site. Users can do back-of-the-envelope calculations, based upon their knowledge of the application, or run the assessment mode to determine the bandwidth needed.
7. Maximum round-trip latency between the two servers:
- Latency is not an issue, as long as a reliable WAN connection exists.
8. Management:
- The management utility, called the Management Center, is available through a browser to present the status of the system to the user. The browser connects to the Control Service.
- The system can be set up to execute tasks for every significant event that occurs:
i. Send a message with a description of the event.
ii. Execute a user specified script.
To learn more about worry-free computing, visit stratus.com.
