VMware Live Recovery Reviews

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.

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.

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's my experience with pricing, setup cost, and licensing?

What other advice do I have?

Valuable Features

Improvements to My Organization

Room for Improvement

Stability Issues

Scalability Issues

Customer Service and Technical Support

Initial Setup

Other Advice

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 support?

How would you rate customer service and support?

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

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?

How are customer service and technical support?

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

How was the initial setup?

Which other solutions did I evaluate?

What other advice do I have?

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

What was my experience with deployment of 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?

What was our ROI?

Which other solutions did I evaluate?

What other advice do I have?

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

How was the initial setup?

What other advice do I have?

Which deployment model are you using for this solution?