VMware Live Recovery Reviews

Most VMware administrators have heard of Site Recovery Manager (SRM). SRM has been the standard in disaster recovery for some time. It plays into VMware’s parent company’s (EMC) product line, traditionally leveraging storage based replication. This architecture leverages write journaling technology we spoke of in our first article in the series, so Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) could be very aggressive.

The down side to this architecture is that the customer has to have similar storage arrays at both the production and disaster recovery site. If for example the customer had a fiber channel array on the production side, and a lower grade NFS array from a different vendor on the other side SRM was not compatible Bummer…

VMware however released vSphere replication in the vSphere 5 family suite and allowed administrators to replicate their virtual machines without common storage subsystems. What this means is that you could have your traditional fibre channel SAN on the production side, and NFS, or internal storage on your disaster recovery site. The underlying storage type is completely irrelevant as long as the workload is supported. This is a gift for DR budgets everywhere. Additionally you can recover to previous points in time using snapshots at the recovery site much the same as you would use a traditional snapshot.

SRM in thie configuration sits on top of the vSphere replication instead of RPAs that are common in array to array based architectures. These replication appliances are Linux virtual machines that are deployed in the VMware environment. I will give VMware a large amount of credit here, where some competing technologies are cumbersome to install, vSphere replication installation takes only a few mouse clicks. Your vSphere replication appliances are functional in just a few minutes. Replication can be configured through the VMware fat client or the web client.

So what’s the catch? vSphere replication would fall into the snap and replicate category. This means that RTOs and RPOs wont be as aggressive as with array to array based replciation, or hypervisor technologies that use write journaling. The current RTOs and RPOs that can be achieved by vSphere replication with SRM over vSphere replication is 15 minutes. There are rumors that this will be coming down to 5 minutes in the future, but it’s only a rumor at this point. Also if you are trying to move to the web client then you will dismayed to learn that SRM can still only be managed through the VMware fat client. I don’t know to many administrators that are excited about the web client, but it’s a relevant piece of information for your day to day work.

So what about the licensing and additional costs? There are pros and cons to the vSphere replication / SRM model.

The virtual appliances are Linux based – pro

This means there aren’t additional Windows licenses required to operate the environment. Some of the other products use Windows based virtual appliances. When you have to stand up more Windows servers you have to patch and manage them, this adds to the cost of the solution. SRM can generally be installed on your Windows system that vCenter runs on. If you’re using the Linux based vCenter appliance SRM isn’t compatable. I would expect this to be resolved soon as VMware is trying to eliminate the need for Windows systems in the environment.

The base vSphere replication is free – pro

Yes you heard that correct, vSphere replication is free. If you have lower priority virtual machines you don’t have to buy SRM licenses. This means you can save money and buy only the SRM licenses (sold in packs of 25) for your mission critical VMs.

SRM is the orchestration tool on top of vSpherer replication – nutural

SRM and all of it’s power can be scoped down to only the systems you need it for. I personally like the flexability and choice, most companies don’t need to replicate all of their virtual machines with very tight RTOs and RPOs. If you are trying to replicate your entire VMware environment, you maybe better off with a solution that licenses by socket as it maybe more cost effective.

Snap and replicate technology – con

At the end of the day snap and replicate technologies are limited. Because the recovered virtual machine ends up with snapshots scalability can be an issue. Let’s look at an example.

VMware recommends that you only have 21 snapshots at a maximum using vSphere replication. More snapshots than this can lead to snapshot consolidation issues. If you wanted to have a recovery point every hour, you wouldn’t be able to recover your virtual machine to a point further back than 21 hours. This a limitation of any snaphost based replication technology not a defiency with in SRM or vSphere replication.

Scalability – neutral

The upper limit to SRM with vSphere replication is 1000 virtual machines. This will suit most enterprises; however, for very large scale deployments this may not be enough. SRM with storage array replication for example can support up to 1500 vitual machines. This limit is roughly about what you would get with any other snap and replication technology. In my personal experience Veeam starts to have problems after 300 virtual machines in a single instance.

Speaking of Veeam this is the next technology that we will discuss. Veeam is a good product that not only provides DR capabilities, but also a very mature backup solution. Join us for our next article in the series.

Originally published here: https://simplecontinuity.com/dr-for-vmware-srm-on-vsphere-replication/

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and technical support?

How was the initial setup?

What's my experience with pricing, setup cost, and licensing?

What other advice do I have?

Which deployment model are you using for this solution?

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What about the implementation team?

Which other solutions did I evaluate?

What other advice do I have?

Which deployment model are you using for this solution?

What is our primary use case?

How has it helped my organization?

What is most valuable?

What needs improvement?

For how long have I used the solution?

Originally published in Spanish at https://www.rhpware.com/2015/09/vmware-site-recovery-manager-61

It is well known that VMware Site Recovery Manager is a high availability solution for applications and data transfer in private cloud environments. This is accomplished using isolation and encapsulation of virtual machines, resulting in simplified automation of the processes involved in replication to remote sites. Thus, SRM reduces the costs associated with obtaining efficient Recovery Time Objectives (RTO), providing a robust and standardized solution for business continuity and dramatically reduce the risk of data loss in our VMware virtualized data centers.

Among the features offered by SRM is the ability to create and maintain disaster recovery plans more effective, which do not use written procedures and maintenance costs that this entails, as well as automated processes generate maintenance and testing, which allows our environment thoroughly tested before the event of a disaster.

But these are general skills that we already know and VMware Site Recovery Manager, now is time to see that brought back the brand new version 6.1 of the product. We are going to analyze in further detail what is each of them.

Storage Profile Based Protection

SRM 6.1 incorporates a new type of group policy-based protection. These groups use Storage Profiles provided by vSphere to identify and protect the datastores and virtual machines. This automates the process of adding or removing the protection of VMs and datastores fully integrated and allowing these tasks to monitor vRealize Automation, for example.

Protection groups based storage policies uses vSphere tags (ability to attach metadata inventory of vSphere) with policies, allowing vSphere administrator automate the provisioning of virtual machines meeting the requirements of performance, availability and protection.

The way to do this is:

• Create a tag and associate with datastores in each protection group

• Then, an associate for each protection group policy is created using this tag

• Finally, the protection group is created and associated with the storage policy created in the previous step

Thus, when a virtual machine is associated with this policy it will automatically be protected by SRM. Just simple.

Extended Storage and vMotion orchestration

Site Recovery Manager 6.1 is now a complete solution optimized for both the multi-storage as well as to migrate from one place to another, and can also fulfill the function of disaster recovery. In previous versions this was not possible in one product simultaneously. SRM 6.1 supports vMotion between remote vCenters with stretched storage, with the benefits this brings.

This integration allows you to integrate SRM with stretched storage, which could previously only be achieved using vSphere Metro Storage Clusters. The advantages of this new system are:

• Maintenance downtime is eliminated. Recovery plans and orchestration between sites allow vMotion migration of workloads completely transparent to the end user and applications

• Disaster downtime is eliminated. Hot migration of using vMotion between remote sites allows Site Recovery Manager 6.1 eliminate downtime associated with recovery

Having stretched storage added to the deployment of Site Recovery Manager exponentially reduces recovery time in the event of disasters, as workloads are migrated hot, uninterrupted by presenting the same storage architecture at both sites by using synchronous replication, allowing registered and lighted move VMs transparently.

Improved integration with VMware NSX

It is no surprise that VMware leads the integration of network virtualization with NSX to all its products, and SRM is no exception. But let's see why.

As in every event of disaster recovery it should be taken into account and fine-tuned the specifics of the network, such as maintaining consistency in IP addresses, firewalls and routing rules previously set, opening ports and other vital aspects. To this we must add that the use of vMotion between vCenters remote requires a Layer 2 network complexity increases significantly.

Now with the availability of newly released NSX 6.2 and many new features were added, Site Recovery Manager is benefited greatly. Now you can use both products together quickly to maintain perfect consistency and efficient networking between sites and perform the migration automatically without worrying about specific aspects of the network, as it has resolved NSX.

In NSX 6.2 can create Universal Logical Switches. Such switches can create Layer 2 networks that exceed the limits of vCenter, which means that when these switches are used with NSX will create a protected port groups connected to the same Layer 2 network.

Thus, when virtual machines are connected to these port groups of a Universal Logical Switch, SRM 6.1 will automatically recognize and not the manual mapping of networks between protected sites will be required. Site Recovery Manager intelligently recognize that it is the same logical network connecting both sites maintain cohesion by creating a single network protected.

This ability to create a Layer 2 network beyond the limits of vCenter eliminates the need to reconfigure IP addresses in case of failure reducing by more than 40% recovery time. In addition, security policies and security groups, firewall rules and edge configurations are preserved in the virtual machines recovered, gaining even more time after a recovery event.

We now know that NSX 6.2 also supports synchronization rules firewalls as well as routing information. This makes it easy to ensure that the configurations in a production network and recovery are kept synchronized making it much easier to create a safe isolation between sites non-disruptively for testing recovery plans.

The implicit network resources mapping, extended capabilities of layer 2 and the testing capacity provided by NSX in conjunction with Site Recovery Manager, added to protection groups based policies radically simplify the administration and operation, low costs associated operations, increased testing capabilities and dramatically reduces recovery times.

Conclusion

As you can see, Site Recovery Manager 6.1 introduces fundamental characteristics that achieve levels of automation until now never seen on the platform, as well as a detailed and comprehensive policy-based control that seamlessly integrate with NSX offer really amazing capabilities face events and disaster recovery between them and turn everything can be done in half the time it took before. We must also not forget the support on extended storage vMotion, which also significantly reduces time and can achieve much lower RTO.

Thanks for reading the article and if you wish you can collaborate sharing on your social networks.

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How was the initial setup?

What about the implementation team?

What's my experience with pricing, setup cost, and licensing?

What other advice do I have?

What is most valuable?

How has it helped my organization?

What needs improvement?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

Which solution did I use previously and why did I switch?

How was the initial setup?

What about the implementation team?

Which other solutions did I evaluate?

What other advice do I have?

Originally posted https://theithollow.com/2015/08/31/vmware-site-recovery-manager-6-1-annouced/

VMware announced Site Recovery Manager version 6.1 this week at VMworld in San Francisco California. Several new features were unveiled for VMware’s flagship Disaster Recovery product.

Storage Profile Protection Groups

Remember back in the old days (prior to today), when deploying a new virtual machine we had to ensure the datastore we were putting the virtual machine on was replicated? Not only that, but if this new VM was part of a group of similar VMs that needed to fail over together, we needed to make sure it was in the same protection group? Well VMware decided this was a cumbersome process and added “Storage Profile Protection Groups”.

In SRM 6.1 we will use storage profiles to map datastores with protection groups. Now we’ll be able to deploy a VM and select a storage profile to automatically place the VM in the correct datastore and even better, configure protection for the virtual machine.

Orchestrated vMotion in Active-Active Datacenters

Yeah, you kind of expected something like this right? VMware announced long distance vMotion and cross vCenter vMotions with vSphere 6.0 last VMworld. We can now start doing live migrations between physical locations so why not add this to the disaster recovery orchestration engine?

I think this new feature might be very useful for some companies that routinely deal with disasters where there is some warning, like a hurricane. Prior to SRM 6.1 you would have been able to do a planned failover through a previous version of SRM, but it would have required a small amount of downtime. You might also have been able to do a long distance vMotion but this would have been some manual or scripted work. With SRM 6.1 the planned failover could be done in an orchestrated fashion with zero downtime!

OK, you’ve probably got some questions about this, lets see if I can knock out a few of them.

Question 1: What if my virtual machine has a lot of RAM and vMotions could take a very long time? Do I have to vMotion them for planned migrations?

Answer 1: Nope! If you have certain VMs that you know you never want to vMotion during your planned migration, you’ll have the option to select the VM and disable the vMotion option during protection.

Question 2: What about the network?

Answer 2: Yeah, the network needs to be the same on both vCenters or your VM won’t be able to communicate with the rest of the network anymore. This is the same as a normal vMotion. SRM will be able to change IP Addresses like it always has, but this requires a small amount of downtime as you might guess.

Question 3: Do I have two different planned recovery options then?

Answer 3: There is one planned recovery still, but now there is an option to enable the vMotion of eligible VMs.

vCenter Spanned NSX Integration

The last main feature of the product is its integration with the NSX product. You used to have to explicitly map each VM with a recovery network. Now in SRM 6.1 if you’re using NSX on both vCenters and the NSX networks are the same on each, SRM will map these networks for you. (yes, you can override this mapping if you need).

Other Notes

SRM 6.1 has also done some rearranging of the recovery plans so that you can get better visibility into what is going on during a failure. If you’ve ever had to troubleshoot a failover this is a great addition to help narrow down the problem. It also provides more places to but scripts into your failover, which is welcomed.