Physical Server DR Orchestration Plan

By Style Sync
| Published on
945db-dlf.pt-hardware-icon-png-2114057

Veeam Availability Orchestrator will help you build and execute a DR plan based on VMWare workload. Consider your Microsoft SQL running on a physical server, or a Linux physical server, and you wish to include them in your DR plan? Can you add a physical server to be part of the Veeam Availability Orchestrator DR plan?

Scenario

Last week I was working with a customer on a challenging datacentre setup. Some of his critical workloads are running as a VMWare virtual workload, but many others are still run as physical Linux servers. To add more complexity to the mix, some are running Microsoft SQL on Linux.

The customer’s wish is to use Veeam Availability Orchestrator to build, manage and execute his DR planning; but the lack of physical server support causes him some unhappiness. The DR plans will never be comprehensive enough to cover the entire application stack.

After some discussion, with the customer and based on his requirement, I came with the below solution to help him achieve his desire objective. Build the Veeam availability Orchestration plan for the VMWare workload, but use Veeam Agent for Linux to cover the physical servers.

So how that can be achieved?

Infrastructure

Before I start with the workaround explanation, lets first look to the lab environment I built to test the workaround solution.

 

 

As you can see, the VMWare workload is protected by, and replicated to, the DR site using Veeam Backup and Replication. The Linux Server is protected using the Veeam Backup Agent for Linux, and the backup is directed to the Veeam backup repository.

To ensure the Veeam agent backup is included on the DR plan, and to be specific, the DEV and Testing validation check, I used the Veeam Instant recovery feature to mount the Veeam Linux Agent Backup to the Veeam Data Lab for testing and development.

The customization:

As mentioned previously, the requirement dictates that the Agent Linux backup is used during the DR Orchestration with DataLabs for development and testing purposes. To achieve this, I wrote a simple PowerShell scripts to instantly mount the Linux Agent backup to the DataLabs network before the VMWare workload is mounted and started. The script is quite simple, and is shown below:

<Pre-Plans Steps Script>

Add-PSSnapin VeeamPSSnapin

Connect-VBRServer -Server “192.168.33.30” -User “<UserName>” -Password “<Password>”

$restorepoint = Get-VBRBackup -Name “magentsrv mAgent” | Get-VBRRestorePoint | Sort-Object $_.creationtime -Descending | Select -First 1

$EsxSrv = Get-VBRServer -Name “<ESXi Host/Cluster>”

$srcNet = Get-VBRComputerNetworkInfo -RestorePoint $restorepoint

#Use if you are using Virtual Switch

$trgNet = Get-VBRViServerNetworkInfo -Server $EsxSrv | Where-Object { $_.NetworkName -eq “<NetWorkName>” }

#Use if you are VDS Switch

#$trgNet = Get-VBRViServerNetworkInfo -Server $EsxSrv | Where { $_.Type -eq “ViDVS” -and $_.SwitchName -eq “<VDS Switch Name>” -and $_.NetworkName -eq “<NetworkName>” }

Start-VBRViComputerInstantRecovery -RestorePoint $restorepoint -Server $EsxSrv -RestoredVMName “LinuxAG_Restored” -SourceNetwork $srcNet -TargetNetwork $trgNet -PowerOnAfterRestoring -ConnectVMToNetwork -GenerateNewSystemUUID -Force

 

<Post-Plans Steps Script>

Add-PSSnapin VeeamPSSnapin

Connect-VBRServer -Server “192.168.33.30” -User “<UserName>” -Password “<Password>”

Get-VBRInstantRecovery | Select -Last 1 | Stop-VBRInstantRecovery

 

After you copy, modify and save the script shown above as a PowerShell file on the Veeam Availability Orchestrator server, you are ready to add this script to your VAO for the DR plan by following these steps:

From Veeam Availability Orchestrator –> Administration –> Plan Steps –> press Add; next, browse to the path where you saved your script:

 

As we are going to use this script only during the DR testing, we must modify the execution steps to Test Action only. See the figure below:

 

Note: If you wish to restore the Agent backup during Failover, then you must write the PowerShell script to restore the backup to the destination location during the DR Failover Plan execution. Set the “Failover & Undo Failover Action” to “Execute”, and “Test Action” to “Skip”. On this blog post, I’m showing the Test Action only.

Setup the Orchestration Plan

Following these previous steps, you are ready to create a DR Plan and include the script in the Pre/Post Plans steps, or in any stage, you wish to include. On my lab, I added during these to my Pre/Post Plan steps:

Pre-Plan Steps:

 

Post-Plan Steps

 

Outcome

Following the steps above allows you to use Veeam Availability Orchestrator to build your DR plans and incorporate any Veeam backup agent. This assists you to build and manage a comprehensive DR plan without the limits imposed by using only VM storage plans. The script on this blog post is a basic script to help you get started.  It proves that the workaround works fine, as it is setup on the screenshots. You can use the script on this blog to help you build a better and more sophisticated script to achieve the best DR plan for your critical workload.

I hope this blog post helps you think about more use cases to use Veeam Availability Orchestrator, and please don’t hesitate to share your feedback with us all.

 

What do you think?

What do you think?

0 Comments:
January 12, 2021

Hello, thanks for the post.
Do you know if we can use VAO without VBR and leverage only on NetApp Snapmirror Asynch replication to restart VMs on the DR site?

January 13, 2021

Hi Renaud, thanks for your message and interest on my blog. Regarding your question, if you don’t use a standalone VBR server, VAO will leverage the embedded VBR server instead.

January 13, 2021

Hi, thanks for the quick reply 🙂

July 5, 2021

Hello, I have plan to test VAO on my lab so can you recommend for my lab environment can work for VAO test or not?

  • NetApp single controller and deploy 2 SVM inside, one smv for DC and one sim for DR
  • VMWare system:
    • Single vCenter, single VMWare DataCenter and single VMWare cluster
    • Inside VMWare cluster have 2 ESX and I plan ESX#1 for DC and ESX#2 for DR

Thanks.

July 5, 2021

Hi Pop,

I don’t see any issue with the environment you are using. try to create two datacenters (one production and one DR) and on each DC, create a cluster and attach the ESXi to the cluster, then attach each SVM to the appropriate cluster. So, to summarize you will end up with the below (the below what I have on my lab):
1 x vCenter
2 x datacenter + 2 Clusters
4 x ESXi virtual hosts (2 on each DC or just one)
2 x SVM’s for each DC

Hope this help

Regards…
HY.

July 5, 2021

Hi, thanks for the quick reply.

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to Our Newsletter

Table of Contents

Related Insights