cloud complianceDRaaShyperscale cloudssecurity

Considerations When Comparing iland to Hyperscale Disaster Recovery Providers

ByNovember 7, 2018

Comparing iland to Hyperscale Disaster Recovery Providers When planning your disaster recovery (DR) solution there are many considerations and challenges to take into account when comparing cloud providers. Every provider has their own solutions, strengths and weaknesses. Listed below are some of the top items to consider when setting up a DR solution along with how providers stack up against iland.

Ease of Use

The Challenges

Hyperscale providers have their own consoles for managing a cloud environment. Consoles can vary greatly between each provider. The terminology, navigation, process and features are all different. Basic tasks, such as simply navigating to your virtual machines after a failover or configuring network access can become a difficult and frustrating experience. With most providers, you are also required to purchase a support package or pay for on-demand support for all technical requests. Costs can quickly escalate and increase when trying to configure and test a DR solution.

Unfortunately, this is a common issue, as server IPs, group policies and firewall configurations may change over time. Changes that occur within the operating system can prevent access to your replicas and impact production for this server. If your provider does not have a web console to access this server, a user could be permanently locked out or required to add more resources to try to enable remote access.

The iland Advantage

The iland Secure Cloud Console℠ was designed for simple and intuitive virtual machine (VM) management. Not only are users able to perform management tasks on their replica servers, but they can also access them through the iland web console. This feature is a tremendous benefit when troubleshooting remote access issues. The web console also provides another avenue to access a virtual machine that you may not want exposed to the public internet.

The deployment of the iland cloud environment also includes an onboarding session with iland’s Cloud Services team. On this call, iland engineers walk through the common tasks and procedures needed for the DR Solution. After the onboarding process there is continued access to iland’s 24×7 support team.

Setting Up the DR Environment

The Challenges

The initial setup of the DR environment comes with its own challenges. Different partners provide different services. Most providers supply the infrastructure that is needed to replicate – but nothing more. Organizations are, therefore, on their own to set up the target replica infrastructure, including VPN connectivity and failover network configuration. As noted above, certain providers have their own terminology, or process, for creating and configuring networks. In addition, there may also be questions about how best to configure replication vs. failover networking or how users will access the environment during a failover scenario. With these type of situations, along with many others, users will be either on their own or will need to pay extra for DR consulting.

After the network and base infrastructure is complete, the next steps is to pair (connect) the source and DR site to configure the actual VM replication. Hyperscale cloud providers often use their own hypervisor, rather than VMware, so you will have to fit your source servers into your provider’s format. Many providers use an instance or VM package that includes a static set of resources. For instance, if protecting a server with 4CPU, 8GB RAM and 200GB of hard disk space, you will need to map the server to a particular VM package that has the same resources. This can become tiring as a user is forced to review the resource allotment for all servers, search through provider’s size packages and pick a matching instance. Users often run into situations where the resource allotment doesn’t fit a specific package and they are then required to spend money on unneeded resources. Any resource changes down the road on the production servers also means the replication for the server will need to be updated to map to the new VM size.

The iland Advantage

During deployment, the iland Cloud Services team will schedule a preliminary kickoff call to understand the specifics of an organization’s environment (e.g., confirm types of servers replicating, discuss failover networking and access requirements, etc.) The next step is for iland to provision the environment, including the replication and failover networks and target infrastructure. The organization is only responsible for its premise site.

Once the initial deployment has been complete, the iland Engineering team will assist with getting VPN connectivity back to the production site and review the process for creating the first replication jobs. Over the years, iland has accumulated a vast amount of experience deploying, maintaining and testing DR solutions with customers of varying sizes and complexities. That experience is crucial when a user is uncertain as to the best practices or best setup for its environment. Lastly, as the iland cloud is built on top of a VMware infrastructure, the VMware virtual machines are able to be replicated and imported to the iland infrastructure as an exact clone. There is no need to fit your VMs to a “VM size package,” thus saving a significant amount of time and effort when setting up replication.

DR Performance

The Challenges

When an organization is planning a DR strategy it is critical to keep RPO (Recovery Point Objective) and RTO (Recovery Time Objective) goals in mind. Some providers may only be able to replicate with image based replication, which typically means a higher RPO, while other providers may offer continuous replication. Another associated concern is some providers may limit (throttle back) to meet a certain amount of bandwidth per month. This will slow replication down, increase RPO times and may require an organization to increase its contracted resources or pay burst charges.

Once a failover is initiated, you may experience longer than expected recovery times. This is common with hyperscale providers that run on non-VMware platforms. During a failover, your source servers must be converted to a compatible VM within your provider’s environment. This process can take a significant amount of time and increase your downtime during a failover scenario. Once failed over, you may notice a significant drop in VM performance, especially if you choose the cheaper VM size packages. You may even have servers that come up corrupted or have services and VMs that are inaccessible. Again, with the DIY providers, you will be on your own to figure out many of these issues — which is the last thing you need during an emergency.

The iland Advantage

iland offers a variety of methods for replication, enabling organizations to meet many different RTO and RPO goals. The iland network is unthrottled, so organization’s are only limited by their available bandwidth at premise when replicating. Because of iland’s VMware-based infrastructure, there is no need to convert VMs during a failover. This drastically reduces the RTO times compared to other providers. Some providers have failover times of 30 or more minutes per VM. At iland, you can expect a VM to failover in two minutes or less. Once failed over, users will have the continued full support of iland engineers to ensure the environment and servers have failed over and booted up successfully. The iland team will also help to plan and execute the move back to the production environment ensuring a smooth transition.

Security and Compliance

The Challenges

Another primary concern when selecting a cloud provider is the ability for an organization to ensure it’s meeting established security and compliance goals. Most hyperscale cloud providers leave security and compliance entirely up to the organization, which can be cumbersome and complicated in less user-friendly portals. A user may end up accidentally exposing a server to the internet when trying to figure out how to access it. Or, when selecting a production VM size, a user may accidentally select an option on a lower unprotected storage tier. Complex portals increase the difficulty users have in fully understanding if its environment is protected.

Selecting a provider and installing and configuring replication software is not enough to meet security and compliance goals. Organizations will need to be able to test and confirm that it is able to failover during a disaster. If you are never able to fully get through this whole process, you may have devoted a lot of time, and money, and still miss your DR compliance goals.

The iland Advantage

The iland Secure Cloud infrastructure allows users to easily manage their ever-evolving security and compliance requirements. iland has an in-house compliance team and offers compliance services to help direct companies toward a secure, compliant program. iland is certified for HIPAA, GDPR, *SSAE16 – SOC 2, PCI DSS v3, FedRAMP, NIST, ISO 27001 and other regulations.

The iland Cloud Services onboarding experience also walks you through a DR failover event. Ensuring not only that a user is able to perform a failover in the future, but iland engineers also ensure that the DR solution works as expected. This helps ease concerns that an environment is protected and an organization will be able to fulfill its DR compliance needs by completing the failover. iland’s console also has auto-generated failover reports that can be used for any documentation needed.


The Challenges

Often the of a DR solution is one of the primary deciding factors when choosing a cloud provider. One possible major pitfall when choosing a provider is not fully understanding all of the costs that will be included in the DR solution. Many providers seem inexpensive at first, but after setting up the environment extra charges start to creep on to the invoice. For instance, each VPN tunnel may cost a certain amount of money per month, outbound data transfer and disk usage may be subject to burstable charges and extra IPs for access in lieu of a web console increase your monthly bill.

As noted above, with other providers you may be required to build the replica infrastructure in the DR site. This could include new networks and a running virtual machine at all times while replicating. This generates extra usage charges that may not have been considered or communicated to you. Depending on the provider, this running replication server may add another $350 or more per month on top of all the replica costs. This is assuming that you are able to correctly configure the Zerto infrastructure on your own without any assistance. If support from the provider or a third party is required, expect to pay a significant amount.

The iland Advantage

iland’s cost model is clear, upfront and easy to track with the billing integration in the iland console. At iland, you don’t have to worry about hidden costs as VPN tunnels, outbound data transfers, disk performance and usage are all included with your monthly costs. VMs are billed by the resources they use, not just by how much they consume. For instance, if your servers total 50 CPU, and 100GB of RAM, but are only running at half capacity, you only pay for the 25 CPU and 50GB of RAM. With the other providers that form your VMs into a instance or size package, you will have to pay a steady cost for the package itself. In this case, a VM that is sitting idle and a duplicate VM that is maxed out in CPU and RAM will cost you the same amount at the end of the day. iland’s costing model ensures that during a failover, or if you run live VMs in the iland Cloud, you only pay for the resources you actually use.

Read more about how iland’s award-winning DRaaS solution compares to hyperscale providers in the 2018 Gartner Magic Quadrant for DRaaS.
Mike Mosley

Mike Mosley

Mike Mosely is a cloud engineer at iland and has worked at the company for over 3 years. He holds a number of VMware certifications including VCP5 as well as the Veeam VMCE certification. Mike works closely with customers to build cloud solutions that fit their requirements.