Check Replica Status – Before deleting it – Part 2

My previous article explained the procedure to perform a failover from VBR console explaining why it is safe (Click here to read it)

In this second article, I’ll show you what can happen if you try a failover in a different way, answering the behavior that a partner had during a cleanup procedure.

In my lab, I created a new Replica Job where the original VM is still Ubuntu-02 (Picture 1) and the replica VM has the suffix _Rep_vc01-1-1 (Picture 2).

Picture 1

Picture 2

After the VM has been created (Picture 3) It is switched it on directly from the vCENTER console (Picture 4). To be sure it works as expected, it is possible to connect remotely.

Picture 3

Picture 4

Picture 5

Going back to VBR console it’s possible to see that nothing has changed (Picture 6) just because the power-on action has been performed directly from the  VMware console,

Picture 6

Attention point: If you try to perform a replica task it fails because the VM is running (picture 7)

Picture 7

Now the main point of the two articles:

It’s a bad choice to delete VMs from VBR “Ready Replica VM”  menu (picture 8/9) without knowing if the VMs have been started from vCENTER console. Why? Because also the production VM gets deleted as shown in picture 10.

Picture 8

Picture 9

Picture 10

Let’s get a little wild with some supposing:

1. If you see the “active” status icon switched on ( from VBR console) it means the failover is started (picture 11)

Picture 11

2. If a permanent failover was performed, the VM disappears from “Replica Ready” menu and replica job results to be empty (Picture 12)

Picture 12

3. If the replica job works fine it means that no permanent failover has been performed

4. If the replica Job works fine but when clicking on the delete button (from “Replica ready menu” of VBR console) (picture 13) the production VM disappears, it means that a new replica job has been re-created after the manual failover has been launched (picture 14).

Picture 13

Picture 14

Knowing that deleting a VM replicated from VBR console needs a little attention, especially if you do not have the continuous and complete control of the VMware architecture, the question is: is it possible to think an easy checking-up before deleting VM?

The answer is Yes and Veeam One can easily help just creating them.

a. From vCENTER: setting up a report that checks if the VM to be deleted is running (power state status) (Table 1)

b. From VBR: if a Replication job is setted-up for that VM (Table 2)

Table 1

Table2

Is there another way to check it up?

Yes. using Powershell scripts.

The example you can find here below is just the first idea that can be polished with a little bit of your effort.

NB1: I’m not a PowerShell expert, I just love writing scripts easy to read by anyone.

NB2: Before trying it please ask your PowerShell expert a consultant!

NB3: It is meant to be launched from VBR.

NB4: If you think that it can be a feature request write to me!

Table 3

That’s all for now guys!

VDrO – Netapp Integration

The fifth article will show how to use VDrO to automatize the Disaster Recovery using the Netapp snap-mirror technology as an engine.

 

Netapp – SnapMirror

The article (quite long) is composed of 6 parts:

  1. Setting up Netapp Snap-mirror Protection
  2. Setting up the Recovery Location
  3. Setting up the Scope
  4. Creation of Orchestration Plan
  5. Starting the Plan
  6. Checking the Orchestration Plan status

1 Setting up Netapp Snap-mirror Protection

In my personal lab, I added two NetApp simulators 9.6 setted-up in peer relationships.

Pictures 1 to 5,  show how I set-up  a protection rule for a single Volume (named Vol_iScsi_N01)

Picture 1

Picture 2

Picture 3

Picture 4

Picture 5

Picture 6 shows the VMware console view of DR site; the replicated volume is presented as read-only volume.

Picture 6

Tips: My personal suggestion is asking your storage expert the right procedure to set-up a snap-mirror relation between two Netapp storages.

2. Setting up the Recovery Location

The recovery location wizard is shown in pictures 7, 8 and 9.

Picture 7

Picture 8

Picture 9

3. Setting up the Scope

The Scope wizard is shown in picture 10.

Picture 10

4. Creation of Orchestration Plan

Let’s go back to the main steps.

The wizard drives the users to select the right voices as shown in pictures 11, 12, 13 and 14.

Picture 11

Picture 12

Picture 13

Picture 14

The test scenarios are available in this configuration too

The Readiness Test is a low-impact and fast method one to confirm that configuration of an orchestration plan matches the DR environment.

The Data-lab test verifies the DR plan starting VM in a separate network.

 As shown in pictures 15,16,17 and 18. the steps are:

– Assigning  Datalab to VM Group (it is available from the admin menu)

– Setting up the Lab Group

Picture 15

Tips: for testing the Netapp integration select the option Restore.

It means the Replica option is just available for VBR Replica jobs.

Picture 16

Picture 17

Picture 18

5. Starting the Plan

Next pictures show how to run the just created Orchestration plan.

Picture 19

Picture 20

Picture 21

Picture 22 shows the restore points available.

Tips:  the shown Restore points are the replicated snapshot  (created by snap-mirror).

Picture 22

Picture 23 shows my favorite option available on VDrO in the Storage replica scenario.

Let’s imagine you run the orchestration plan.
While failover is running, the primary site is back normal operativity.

Your IT manager asks to revert the failover. Is it possible? Well, it can be. If you selected “reprotect storage volumes after failover” during the steps you can easily do it!

Picture 23

Picture 24

Picture 25

6. Checking the Orchestration Plan status

Time to run the orchestration plan and watch the steps performed.

I would like you to give your attention to the following three pre-plan steps:

  • Breaking the snapshot relationship
  • Putting the destination volumes on-line
  • Mounting the volumes

(Clicking on the picture you can enlarge the images)

Picture 26

From picture 27 you can see  the main steps:

  • VM registration
  • Network founding and connection
  • Booting VM

Picture 27

Pictures 28 and 29 show the result of post plan steps:

  1. Heart-beating test
  2. Unmounting source Datastore

Picture 28

Picture 29

Tips: how to check in 5 points if everything is correctly working

1. VM in the DR site is running (from DR vCenter console connect remotely to VM as shown in picture 30 and 31).

Picture 30

Picture 31

2. Source VM has been deleted (from Production vCenter console check if VM is disappeared) (Picture 32).

Picture 32

3. The Orchestration plan launch button is grey and the plan has to be reset (picture 33).

Picture 33

4. Destination volumes on Netapp console have been set as read/write (Picture 34).

Picture 34

5. The Netapp relationship between source and destination volumes is broken (Picture 35).

Picture 35

– Readiness check report example dowload

That’s all folks for now and take care

Replicas from Backup

27th July 2020 Update:

From now on it’s possible to create a replica Job from a backup copy job set-up as immediate copy mode.

https://www.veeam.com/kb3228

In my last article, I talked about how to throttle the network when you need to perform replicas Job (click here for more details).

In this second article, I will show you how to replicate a VM using a Backup as a source.

The main three points are:

  1. Setting up a Backup Job
  2. Setting up a Backup Copy Job
  3. Setting up a Replication Job

Let’s go!

1. It’s quite easy to create a new backup job. If you didnìt read the guide, the next pictures will show the more important points:

Picture 1

Picture 2

Picture3

2. Now it’s time to configure the backup copy Job selecting the just created primary backup as a source.

Picture 4

Picture 5

To simplify reading the article, please pay attention to the name of the second Repository (XFS-Repo-DR)

3. Now it’s time to set up the Replica Job

Picture 6

Picture 7

This is the main point of the article:

Click on the “Source” Button (yellow row) and select the Repository XFS-Repository-DR as a source of the Replica, as shown in Picture 8.

Picture 8

The last steps are:

  • Completing the Replica Wizard creation
  • Running the job

Picture 9

To be sure that everything is working fine you can use any tools that check up the I/O on Repository.

In this article, I choose IOSTAT because it’s light, powerful, and easy to use on Linux Repositories

Picture 10 shows the disk status before the replica job is launched while Picture 11 shows the disk status when it runs.

Picture 10

Picture 11

Take care and see you soon!