At the completion of this session, you should be able to:
- Identify major components of the Neverfail Continuity Engine product architecture.
- Describe major component configuration.
- Identify advantages of the Neverfail Continuity Engine product architecture.
- Recall Neverfail Continuity Engines high availability architecture.
To understand the architecture of the Neverfail Continuity Engine product you must fully understand each of the major components. As we discuss each component, note the relative simplicity of the Neverfail Continuity Engine design.
- Engine Management Service
- Active-Passive Server Pair
- LAN and WAN.
- Hardware Agnostic.
- Shared Nothing.
- Cloned Servers.
- Identity and Role.
- The Neverfail Channel.
- Windows Filtering Platform.
- Neverfail Continuity Engine versus Neverfail plugins.
- Data Replication.
- Replication Queues.
- Wide Area Network or WAN Environment.
- WAN Acceleration.
Engine Management Service
Continuity Engine employs the web-based Engine Management Service (EMS) to deploy the primary and secondary servers. Additionally, using the web-based EMS user interface, you can perform most routine operations. This includes most functions used to manage Neverfail Continuity Engine.
Active-Passive Server Pair
Neverfail Continuity Engine provides a fully redundant Failover solution. To do this, Continuity Engine employs an Active - Passive server pair methodology. If the active production server fails for any reason, the fully redundant passive server can quickly take over all application processing, keeping end users continuously connected to a working application.
LAN and WAN
Neverfail Continuity Engine provides flexibility, in that it can be distributed on a LAN for high availability, or it can also be distributed remotely, over a WAN environment, to provide the additional benefit of disaster recovery.
One key feature of the Continuity Engine product is that it is hardware agnostic, within reason. When deployment includes physical servers, the active and passive servers can be different in terms of manufacturer, model, and even processing power, simplifying deployment and potentially lowering the total cost of ownership.
Hardware should not be so different that significant differences in overall performance exist. Otherwise, it will be difficult for the slower server to keep up with replication and handle Failovers adequately.
Remember! Either server may be active in providing application service to the clients at a given time.
Disk subsystem performance on servers should be of similar magnitude. Significant differences between the Primary and Secondary server disk subsystems could bottleneck the server pair and impact performance.
You should also know that Neverfail Continuity Engine employs a shared nothing architecture. Typical clusters share a quorum, holding the configuration on a shared data drive, typically implemented on the Storage Area Network or SAN. This introduces a single point of failure. Neverfail Continuity Engine does not use any shared hardware resulting in no single point of failure, instead all data changes that occur on the active server replicate to the passive server so that two separate copies of the data exist.
Neverfail Continuity Engine employs a unique installation process which automatically clones the servers, so they appear to be identical. This includes all protected applications, all configuration settings, machine name, security identifier and IP address in a LAN environment. Continuity Engine's unique approach offers seamless Failover to users without complex updates to Windows Active Directory and presents a single server to the Windows network. It also simplifies the installation process, removing the need to pre-configure the Secondary server with the same applications and configuration settings as the Primary server, saving time and eliminating the chance of errors at this critical set up stage.
Identity and Role
As mentioned previously, Neverfail Continuity Engine uses a server pair to provide High Availability and Disaster Recovery. Each server in the pair has both an identity and a role. The identity of the servers in the pair does not usually change, unless you replace either physical hardware or the virtual instance. The role of the server changes if Continuity Engine carries out a switchover or a Failover. This section, therefore, defines and discusses these terms: a server's identity refers to its physical hardware or virtual instance and can be either Primary, Secondary or Tertiary, if deployed as a trio.
The terms Primary, Secondary and Tertiary identify a server machine (physical or virtual) and never swap during any operations. The Primary server is the principal server in the cluster, usually referred to as a Production server, before you install Neverfail Continuity Engine. The Secondary server is the opposing server to the Primary in the cluster.
Refer to the identity when you want to discuss the physical equipment or virtual machine. For example, you might describe the Primary and Secondary servers by location, color, manufacturer. As an example: “The Primary server is an Acme machine with a grey case, located in the basement of the corporate headquarters, while the Secondary is an ABC server with a black case, located on the second floor in the satellite office.”
The server's role refers to what the server is doing currently. The role can be active or passive. When you read Neverfail Continuity Engine literature, including the administrator guide, in the installation guide, or communicate to other employees, Neverfail partners or with a customer support team, refer to the server role when you want to discuss what a server is doing or what it's expected to do.
The active server is a server that is visible to the clients through the network. The active server is running protected applications and servicing client requests.
The passive server is the standby server in the pair. The passive is receiving replicated data across the replication channel. The passive server is not delivering service to the clients. It's hidden from the rest of the network. Either one of the Neverfail Continuity Engine protected servers can assume the role of passive or active.
The Neverfail Channel
Neverfail Continuity Engine communicates between servers using the Neverfail Channel. The Neverfail Channel is used for data replication and the heartbeat (are you alive) messages.
The Neverfail Channel consists of at least one network connection added to each server, typically connected with either a crossover cable or a switch. This calls for a network subnet providing communications between the Primary, Secondary and, if installed, Tertiary servers. These communications can be on a dedicated subnet or a subnet shared with the LAN. Neverfail recommends the use of an additional second channel to provide redundancy and avoid a single point of failure. All replication and management communications occur across the channel using predefined IP addresses and ports, which can be changed. It is important to note that firewalls must allow traffic between the servers on predefined ports. Since the Neverfail Channel is a private network segment, data is not encrypted unless you use external encryption, such as a Virtual Private Network (VPN).
Windows Filtering Platform
To hide the passive server from the network and ensure that name and IP address conflicts don't occur, Neverfail Continuity Engine uses Windows Filtering Platform on both servers.
Windows Filtering Platform allows the active server to be visible to the local network while the passive server is hidden.
Switchover and Failover
During a switchover or Failover, Windows Filtering Platform manages network visibility, allowing the active server to become passive and hidden from the local network while the passive server becomes active and visible to the users.
You can configure both servers with multiple local network IP addresses, allowing you to manage either server even when they might be in the passive mode.
Neverfail Continuity Engine versus Neverfail Plugins
The Engine is the real plumbing of the Neverfail Continuity Engine product. It provides data replication, server monitoring, network monitoring and data rollback capabilities.
On the other hand, Neverfail Continuity Engine various plugins define the data replication needs for a given application, the services to monitor and stop/start during switchover and failover process and monitoring needs for application specific performance counters. Plugins also perform the actual application and performance monitoring.
Data replication is a critical function of the Neverfail Continuity Engine product and keeps your data safe. Continuity Engine replicates critical files used to store application data and important registry settings, to ensure that changes to the applications configuration are synchronized between servers. Neverfail Continuity Engine will auto discover any data that needs protection in real time, without user intervention (for example, when new databases or file shares are created). You can also manually create file filters via Engine Management Service or through the Neverfail Advanced Management Client.
Neverfail Continuity Engine performs replication asynchronously, to ensure that the active server never slows down because it's waiting to replicate data to the passive server. To do this, it queues all replication traffic. Continuity Engine uses two types of cues: the Send queue and the Receive queue. Since either server can assume the active or passive role, each server will have both a Send and Received queue.
Another feature of the Neverfail Continuity Engine product is its ability to work in the Wide Area Network (WAN, providing the same level of High Availability experienced in a LAN environment. Key differences in WAN operations include servers in different subnets and large application loads.
Servers operating in different subnets require unique IP addresses. Continuity Engine overcomes this by automatically updating domain name servers, redirecting users to the currently active server. Low time to live or TTL values ensure that the DNS caches on client machines expire quickly, resulting in faster seamless Failover times.
Under large application loads in a WAN environment, it is normal to experience a build-up of data in the same queue, due to the lower bandwidth typically found in these environments. In these cases, Continuity Engine offers a WAN Acceleration option. WAN Acceleration compresses data and performs deduplication before transmitting, to reduce the amount of traffic across the network. Additionally, it makes use of disks (rather than RAM) for the replication cues, to prevent exceeding RAM capacity.
Both the Primary and Secondary servers can run on physical hardware or within a virtual machine. By using hardware virtualization technology, you can fail multiple physical servers over to one physical server hosting multiple virtual machines, resulting in a many to one relationship. It's important to remember that when you use any virtualization technology, it needs to be sized appropriately so that replication and Failover processes run seamlessly. A secondary virtual server must be just as powerful as a secondary physical server would have been.
Continuity Engine Trio
Neverfail Continuity Engine can be configured to operate in both a LAN and WAN simultaneously, providing both High Availability and Disaster Recovery, using a third server. In a trio configuration, the Primary and Secondary servers perform High Availability operations in the LAN while the Secondary and Tertiary servers perform Disaster Recovery operations in a WAN. With the trio configuration, Continuity Engine uses one active server and two passive servers.
In a trio configuration, any of the three servers can perform an active or a passive role, providing flexibility and maintaining High Availability concurrently with Disaster Recovery.
In the trio configuration, the active server replicates to the first passive server and the first passive server replicates to the second passive server.
When configured in a trio, the following should be considered:
- Each server requires a minimum of 2 channels resulting in 2 separate IP addresses for channel communications per server.
- The Tertiary server will not operate in the middle of the replication chain, thereby preventing replication across the network in both directions.
- The communications between servers in the trio is a closed system and all channel connections must be functional to maintain both HA and DR.
Congratulations for completing this learning session. This knowledge, combined with knowledge gained from other Neverfail learning articles will assist you in achieving full success with Neverfail Continuity Engine products.