Configuring Hyperflex 2.5 Replication

There are many cool HX 2.5 features and one of them is native replication. But how do you configure this ? Well. Let’s start.

What is Hyperflex replication ?

It is possible to replicate VM’s from one Hyperflex Cluster to another Hyperflex cluster. In case of a disaster, you can (manually) start the replicated VM’s at the secondary cluster. Right now there are some limitations. Please read always the release notes of the software version.

Hyperflex Replication

Step 1 : Create replication network on the Hyperflex clusters.

First you will have to configure the Replication Network. It’s easier to have a routed network.

 

I am lazy so I like the UCS Manager configure the VLAN for me on the Fabric interconnects. I got a special VLAN for the replication. The IP Range should be #Nodes + 1 ! So if you have 4 nodes, the range should be at least 5 ip addresses. Make sure your range is big enough for the future.

It’s possible to have some bandwidth restrictions regarding replication traffic.

Finally the replication network is created and you will see something different.

Now you can configure the Replication Pair

Step 2 : Replication Pair

Fill in the name of the Replication Pair. Right now Hyperflex 2.5(1c) can only have a 1:1 relation with eachother.

 

The username here is NOT local/admin ! It’s a user with admin right of the SSO of vCenter !

 

Now we can map the datastores. It’s just a place where the replication will land. It’s easy to have a dedicated datastore for replication, but it’s not a must.

 

 

 

Step 3 : Create Protection Groups

A protection group is a group of VM’s with the same replication scheme.

Ofcourse it’s also possible to protect a VM without group scheme.

Step 4 : Protect the VM

Just select VM’s you want to protect.

The Protectiongroup was already created, but you can create your own also right now. Now you can see that the VM’s are protected and to which group they belong.

Step 5 : Monitoring the VM Protection

As long as you see green arrows, it’s alright. If the status is active, then the replication is not finished yet.

 

 

In the overview you can see how many VM’s are protected and how many replications are in progress. Click on the graph and you will see some details regarding bandwidth.

Bandwidht usage of the Replication.

Step 6 : Test

A disaster is never a happy event and you can test in advance if everything is working.

First you will need the ID of the VM :

stcli dp vm list –brief
With :

stcli dp vm recover test –vmid <vmid> –poweron –newname <NewName>

This test will create the VM at the recovery stite. With –poweron the image will also be powered on and I use –newname just to give it another name.

Ofcourse you can do this also with the API !

And here you see the image running.If you’re doing some testing in the lab, make sure that the booted VM’s don’t interrupt eachother with the same IP addresses etc. It’s better to choose a different network.

Step 7 : Disaster Recovery of the VM’s.

For a real disaster Recovery you will halt the replication with :

stcli dp vm halt –vmid <VMID> or sticli dp group halt –id <group id> 
Now you can type :

stcli dp vm recover failover –vmid <vmid> and that’s it !

Once you halted the replication, you can’t start it anymore. Works as designed !

Step x : Automation

Wouldn’t it be an easy world if everything was automated and you don’t have to do any manual labor ? In the next blog I will explain how you can create your own script with API calls to automate everything.

 

 

Some nice Cisco Validated Design documentation about Hyperflex can be found at : here

Be the first to comment

Leave a Reply

Your email address will not be published.


*