Prepare for the worst-case scenario with the Axcient Continuity Cloud. Downtime of critical infrastructure can cost a business dearly. When disaster strikes, backups will not be enough to keep businesses operating smoothly. The Axcient Continuity Cloud allows bare-metal backup images stored in Axcient's storage cloud to be virtualized in the cloud in minutes or hours, not days or weeks. These virtual servers can then be connected to the Internet and existing LAN networks through a virtual firewall and router or VPN tunnels.
The Axcient Continuity Cloud allows fast recovery from partial site or entire site failures. In the event of a server failure (or the failure of an entire site), a local Axcient BDR appliance can first be used to easily, quickly, and transparently virtualize the failed server(s) onsite. If the BDR has been destroyed or is otherwise unavailable, the continuity cloud can be activated to bring the failed infrastructure back up.
Powerful virtual routing and firewalling features provide easy and, in certain configurations, fully transparent access to virtualized servers.
To begin using the Axcient Continuity Cloud, a partner submits a critical (highest priority) support ticket, including details of the resources needed (number of servers, total RAM and disk space) and the account(s) containing the data for the computers to be virtualized. Our team will respond to these requests 24/7/365 and will provision one or more continuity cloud compute nodes for dedicated use by the partner. Once provisioned, the partner will have full self-management capabilities of the resources on the compute node and will no longer need to involve the Axcient team to get things done..
The partner agrees to the acceptable use terms, and then is given access to the compute node(s). Once logged in to a compute node, partners have full access to self-configure the virtual router and virtual firewall, allowing the configuration of any needed VPNs and NAT/PAT policies. If the partner chooses to virtualize a bare-metal backup image directly without any conversion process (only available for certain types of bare-metal backups, or where “hot standby” VMs have already been created automatically if using Quest Rapid Recovery), VMs are configured and spun up. Otherwise, the bare metal backup images will be “restored” or otherwise converted and copied onto the storage resources dedicated to that compute node, after which the images can be virtualized. Hyper-V, VMWare and VirtualBox are provided for maximum compatibility.
The VMs can be brought up with a variety of networking configurations. A test mode is available where the VMs are fully isolated on a virtual network. More common is the mode where VMs are bridged to a VLAN that is dedicated to and connected to all of a partner’s provisioned compute nodes. The virtual router and firewall control the flow of traffic to and from this internal, private VLAN, to a VLAN dedicated to the external connectivity of the virtual network. All compute nodes are assigned several public IPv4 addresses (IPs are provisioned as requested, up to one public IP address per VM that needs to be virtualized). All traffic to these public IPs are automatically routed to the external VLAN dedicated to the partner’s compute node(s).
The virtual router/firewall thus has full control over the entire network – virtualized servers can be exposed in a DMZ, NAT/PAT can be used, IPsec VPN tunnels can be configured, and VPN connections can be passed through to virtualized servers.
IPsec VPN tunnels are especially powerful for a partial-site failure situation where the customer site’s firewall is still operational and can form a VPN tunnel to the virtual router/firewall running in the cloud. In this situation, the internal IP addresses of the virtualized servers in the cloud can be the same as they were before, and thus users can transparently use the virtualized servers running in the cloud without any configuration changes. Additionally, any public services such as POP3 and OWA can be exposed through NAT/PAT policy rules---partners then update the DNS records of their servers to point to the new public IP addresses, and these public services become available again, just as before.
When the original servers are ready to be recovered, the virtualized servers can take incremental backups, which will update the backed up data like normal. The partner can then download and restore these bare- metal images as they normally would, or request a copy of the data on a USB drive or NAS device. Finally, the partner submits a ticket to de-provision the cloud compute nodes, and the cloud compute nodes are automatically wiped clean back to a well-known state, so that they are ready for use by the next partner.