Async Protection Domain

Paging  and , resident DR Guru's

As a general statement, if you haven't already, check out this section in the Nutanix bible: http://nutanixbible.com/#anchor-backup-and-disaster-recovery-79

Here's answers to your questions from my POV in-line

• How many VMs per PD[list]
•  - Previous versions had a limit of 50 VMs/PD, its up to 200 VMs/PD though.

Create many PDs and group by application/department/roles eg

• All Web servers in one group, all SQL servers, all application servers
• All HR based systems, All IT based systems, All Fiance based systems
•  - Generally we recommend people map PD's to Application stacks, so everything within an app stack gets treated the same. Classic example is something like sharepoint, which has a web front end tier, App server tier, and the DB/blob backends. Put all of those items in a single PD and call it "sharepoint01" or something similar

Is there a limit on how many PDs you can have in a cluster

•  not that I've seen

What's the dis/advantage to having fewer large PDs over many smaller PDs

•  - Disadvantage - Scheduling granularity of large PD's is less flexible
•  - Advantage - Large PD's make for less configuration, and conceptually thats a bit easier to manage
•  - general commentary - if you align PD's to your applications, you'll find that you'll naturally have more PD's and they'll be relatively self documenting, which helps greatly from a DR perspective.

What frequency and retention are the local/remote snapshots

•  - I've seen just about everything you'd imagine from short, more active snaps, to different days of the week, to once per week, and so on. EITHER WAY, this is should be directly linked to your business requirements and what sort of RPO's your applications need, rather than just taking a zillion snapshots and keeping them forever (providing you have space for htat)

What issues arrise when activating a PD

•  - In general, I'll be candid, the largest challenges are recovery ordering (which servers come up first, etc) and network/IP addressing. We're enhancing the product to take care of these as part of future releases, but those are the areas we get the most feedback in from my 2 cents.

I believe the IP address will be removed and the MAC will change...correct??, any scripts or automation applied?

•  - If you are NOT using AHV on both sides, then yes, we do not yet have IP address orchestration (that orchestration is coming). If you ARE using AHV, you can map Network A to Network B, and IP addresses will be handled automatically. That said, there are a handful of scripts out there that will help out here, functionality varies, but if you're a saavy scripter, you should be able to make the bacon.
• https://next.nutanix.com/t5/Scripts/SRM-like-functionality-script/m-p/2345
• http://next.nutanix.com/t5/Scripts/DC-DR-Failover-Migration-script-based-on-powershell-HyperV-on/m-p/4644
• http://www.breekeenbeen.nl/2014/04/24/nutanix-protection-domains-migration-with-vmware-vds-fails/

[/list]

Hi  Thanks for the detailed response.

My thoughts were to group VMs (or entities to use the Nutanix terminology) by application/solution into CGs then in a PD based on snapshot schedule.

Our DB backups take transaction logs every hour for critical system so it's really the OS and applications we're protecting.

We are running ESX/AHV over the two clusters and I did think about reserving the IP in DHCP but I know that could cause other issues.

The scripts you have linked to are complicated and not something I would want to throw into a production environment, so they'll have to wait for our test cluster to be built and I'll be testing them. In the mean time I'll have to resort to old school batch scripting for now.

Thanks again for your response Jon.


Regards
Dave