As a side-note, the secondary SQL servers, DBs, and failover groups are located in the primary resource group, not the DR resource group. This is so that the DR resource group can simply be deleted when the primary region comes back on-line. Don't forget point 1 of resource groups: the resources inside should share the same lifecycle.
But moving on to the topic of the title: the DR environment is identical to prod minus the SQL servers and databases. There's no point scripting up two ARM templates when things are this similar, and fortunately Azure has us covered with ARM template conditions. This is the best use for them that I've found so far, but you could also use it for any other environments/deployments which are quite similar.
First, in the Powershell script (we're using a modified version of the Sitecore Azure toolkit's
Sitecore.Cloud.Cmdlets.psm1
Start-SitecoreAzureDeployment
function), we dynamically set the template property based on a flag:if($IsDR) { $paramJson | Add-Member -NotePropertyName "Environment" -NotePropertyValue @{ "value" = "DR" } -Force }
Then in the template we add our Environment property:
"Environment": { "type": "string", "allowedValues": [ "Prod", "DR" ], "defaultValue": "Prod", "metadata": { "description": "Select whether this environment is prod (requires SQL) or DR (no SQL required)." } }
Finally, in the resource itself we add the condition to only create SQL servers if it's not DR:
{ "condition": "[not(equals(parameters('Environment'), 'DR'))]", "type": "Microsoft.Sql/servers", "name": "[variables('dbServerNameTidy')]", ... etc. }
You can also use the conditions in your properties, which is required in the DR deployment to get the old FQDN of the original prod SQL servers.
"sqlServerFqdn": "[reference(if(equals(parameters('Environment'), 'DR'), resourceId(parameters('prodResourceGroup'), 'Microsoft.Sql/servers', variables('oldDbServerNameTidy')), resourceId('Microsoft.Sql/servers', variables('dbServerNameTidy'))), variables('dbApiVersion')).fullyQualifiedDomainName]",
Easy as that! Now you have one ARM template which can be used for both environments, just by passing the
-IsDr
parameter to your powershell deployment script.You could easily modify the Environment parameter to contain more values for different environments if you have more which are similar. However if they're more than a little different it's probably worth having a different nested template, or entire set of templates, for each environment.
It was a nice article on what is RTO RPO backup. I found this information very helpful. Thanks for sharing
ReplyDelete