How to install Neverfail Continuity Engine in Microsoft Azure Cloud
This article provides information on how to deploy Neverfail Continuity Engine in Microsoft Azure Cloud environment.
First chapter covers the Neverfail Continuity Engine complete installation in Microsoft Azure Cloud environment (Azure-to-Azure deployment).
The second chapter covers the scenario in which the Secondary (or Tertiary, if applicable) cluster node, part of an on-premise Neverfail Engine Cluster, is (are) moved (migrated) into Microsoft Azure Cloud
environment (on-premises-to-Azure deployment).
Continuity Engine Azure-to-Azure deployments
- Production server (Primary to be) hosted in Azure Cloud
Supported Neverfail Engine deployment configurations:
- Pair HA with different Engine Public IP addresses on each node (each associated to a different static/reserved Azure public IP address)
- Pair DR with different Engine Public IP addresses on each node (each associated to a different static/reserved Azure public IP address)
- Trio HA+DR with different Engine Public IP addresses on each node (each associated to a different static/reserved Azure public IP address)
- Deploy Engine Management Service (EMS) on an Azure VM located in Production's server virtual network / subnet (dedicated server or any existing server except Primary-to-be)
- Fulfill the requirements for Primary/Production:
- VM network configuration> the private VM configured IP addresses must be configured as static (considering they are initially DHCP allocated). Make sure you preserve the exact network configurations (gateway, DNS, etc)
- Azure portal> public IP address should be static, reserved in order to be persistent across VM reboots
- Azure portal> RDP enabled for Azure VM
- Deploy Engine on Primary (usual setup via EMS, no additional steps)
- Add standby HA or DR VMs nodes for Pair deployment
- Usual setup via EMS using manual cloning procedure
- Manual cloning procedure: follow Copy An Azure VM Using Managed Disk Snapshots to create an exact copy of the source VM (including identity and SID): when Primary VM source is ready for cloning (indicated in EMS), snapshot Primary> create managed disk> create HA/DR VM from the managed disk (with no Azure Public IP address associated).
- Post cloning configuration for HA/DR node
- RDP into HA/DR node (can be done from any Azure VM connected to the HA/DR VM virtual network / subnet, using the private IP address allocated during VM creation)
- on HA/DR> set Neverfail Engine Service startup type = Manual
- azure portal> stop HA/DR VM
- azure portal> create/associate Azure Public IP resource to desired NIC
- azure portal> create channel interface resource and configure it with the channel IP address (as per HA/DR deployment setup).
- azure portal> start HA/DR VM
- RDP into HA/DR node
- on HA/DR configwiz> configure Engine on Secondary with the correct/desired Public/Channel IP addresses mapped to correct NICs
- on HA/DR> set Neverfail Engine Service startup type = Automatic
- on HA/DR> Start Engine service
- HA/DR node should connect to the Engine cluster and start replicating
- Add a HA+DR trio:
- since the cloning method used is Manual, it is not possible to create HA+DR trio directly: HA node should be added first resulting a HA Pair, then the DR node will be added to the existing HA Pair.
- Adding the HA node will follow the above procedure having Primary as the clone source
- Adding the DR node will follow the above procedure having Secondary as the clone source
- the above procedure applies also when deploying the Engine cluster across different subscriptions/vnets/sites/regions: the only additional requirement is to fix the connectivity between the Engine nodes (via VPN tunnels/gateways, VNet peering, etc.) - the solution for this is outside Engine deployment procedure scope - it strictly belongs to customer's Azure Cloud inter-connectivity configuration
- A thought: In theory it would be possible that all the Engine nodes to share the same Azure Public IP address resource. using Azure Load Balancer and PAT: bind/translate multiple private IP addresses to a single Public IP address. However, this doesn't change the way Engine cluster is deployed.
- If Azure Backups are enabled for both Active and Passive servers, the Management IP has to be set as the Primary IP Address in Azure Networking, otherwise the Azure Agent won't be able to connect.
Continuity Engine on-premises-to-Azure deployments
- Production server (Primary to be) hosted on-premises
- existing on-premises AD - Azure AD joined environment (hybrid Azure AD)
- on-premises - Azure cloud connectivity (VPN, etc)
Supported Neverfail Engine deployment configurations:
- Pair HA with same or different Engine Public IP addresses on each node (on the Azure HA VM the Engine public IP address is associated to a static/reserved Azure public IP address)
- Pair DR with same or different Engine Public IP addresses on each node (on the Azure DR VM the Engine public IP address is associated to a static/reserved Azure public IP address)
- Trio HA+DR (both HA and DR in Azure) with different Engine Public IP addresses for the standby Azure HA and DR VMs (on the HA and DR VMs, each public IP is associated to a different static/reserved Azure public IP address)
- Trio HA+DR (only DR in Azure) with same or different Engine Public IP addresses for the standby Azure DR VM (on the DR VMs, the public IP is associated to a static/reserved Azure public IP address)
The same procedure as for Azure-to-Azure Engine deployments applies except:
- EMS server should be installed on-premises
- Production server should be deployed on-premises (requirements as per installation guide)
- the way to-be-Azure-VM's will be cloned (1) and migrated (2) from on-premises to Azure:
- (1) cloning the source on-premises server
- if Engine source server (Primary or Secondary) may be cloned on-premises using automated method (via vCenter server), then the automated HA and/or DR cloning should be used during the EMS deployment
- otherwise, manual cloning method should be used (this depends on the type of the source: physical, VMware, Hyper-V, Xen, KVM, ...)
- (2) Migrate the HA and/or DR servers from on-premises to Azure cloud
- using Azure Migrate (follow the specific procedure that applies to the on-premises HA and/or DR servers type - which are the subjects to be migrated)
- or any other technique which assures the correct migration, preserving the servers identity, SID, etc...
- once the migration is completed, proceed with the Post cloning configuration for HA/DR node steps mentioned in the Azure-to-Azure procedure
Neverfail Continuity Engine 8.5 (or newer)
How to install Neverfail Continuity Engine on Google Cloud Platform
Summary This article provides information on how to deploy Neverfail Continuity Engine on Google Cloud Platform environment. First chapter covers the Neverfail Continuity Engine complete installation on Google Cloud Platform (GCP) environment ...
Continuity Engine Product Architecture
Learning objectives 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 ...
Accessing the Continuity Engine Servers
This article introduces the Neverfail Continuity Engine Management IP addressing. It allows you to manage your Neverfail Continuity Engine servers even when they are in a passive role. Continuity Engine employs 2 or 3 servers working together. One ...
Neverfail Continuity Engine disables Automatic DNS Registration on the Protected Server
Summary This Knowledge base article provides information about the configuration of Automatic DNS registration on a server protected by Neverfail Continuity Engine. More Information When Installing or Upgrading Neverfail Continuity Engine ...
How to Install Neverfail Engine Management Service (EMS - web centralized console)
Summary This Knowledgebase article provides the procedure to install the Neverfail Engine Management Service. Using this procedure will ensure that you achieve a successful installation. Note: You CAN'T install the EMS web console on a server which ...