Monday, May 9, 2016

Geo Replication for Azure SQL Databases

In the recent past, I wanted to have some redundancy for my databases hosted at NE (North Europe) region. 

1. Introduction

I found out Azure Geo-Replication lets you do this pretty quickly.  Active Geo-Replication lets  you configure up to 4 readable secondary databases in the same or different data center locations (regions). Secondary databases are available in the case of a data center outage or the inability to connect to the primary database.  If for any reason your primary database fails, or simply needs to be taken offline, you can failover to any of the secondary databases and the application / database would behave normal. To do the Azure Geo-Replication follow the steps:

2. Select Source Database

Select the Database as shown in the below figure. Choose the Geo-Replication option

3. Select Target Database

As seen below, the NE region is paired with WE (West Europe) region. Hence select the WE region. Enter the server name, and other details as shown below.


4. Geo-Replicate

The Geo-replication starts as indicated with dotted lines (in progress)

Once the Geo-Replication is complete, the secondary database is ready and available. If a failover is done, then secondary database comes in to picture and serves the need.

Note - I had to change my connection string of MVC application to the failed over database since the server name was different.  


Friday, May 6, 2016

Azure: Migrating VMs

This post says about how do you migrate Azure VM's from one region to other region OR move one VM from one storage account to another storage account.

Following are the steps needed: 

1. Powershell

Open an Azure Management Powershell with Admin privileges

2. Connect to tennant

2. Log on to Azure in the PowerShell window by typing the following command

3. Select the subscription of the source VM

  Select-AzureSubscription -Name "BizSpark Plus"

4. Get details for source VM

$disk = Get-AzureDisk | Where-Object { $_.AttachedTo.RoleName -eq "VM_NAME" }  #VM_NAME is the source VM
$mediaLink = $disk.MediaLink
echo $mediaLink  # Get the storage name from here e.g. by copying the storage name before the first "." e.g. portalvhdsgp72f86dj50g3
The above step would give you the storage account. The log on to the portal, get the storage , key as shown below.
You would need to spend about 10 min in getting these details. 

5. Source VM commands

From the above screenshots, we can get the values of Storage Account Name, Source Key (master key), Container and Virtual Hard Disk(vhd).
$sourceStorageAccountName = "portalvhdsgp72f86dj50g5"
$sourceKey = "d/MxXjv3SMw4TP+zSSYMJsSUHOtgBKLmFmouJgNFRYkhGVf742vdPzmYAXQW4cBJwWlccgkOtV3PCiGZEU3nAw=="
$sourceContainer ="vhds"
$sourceContext = New-AzureStorageContext –StorageAccountName $sourceStorageAccountName -StorageAccountKey $sourceKey
$blobName = "VM_Name.vhd" 

 If you want to put your destination VM or disk under a particular storage account follow step 4 to get the details of the storage account, container, and key.
If you need to create a new storage, container then create it and note down its values.

6. Destination VM commands

If the subscription to the destination VM is same, then dont select the subscription else you would need to select azure subscription
$destinationStorageAccountName = "portalvhds56k8sxsm0mns9"
$destinationKey = "uKFhc8ebZ6kA2Z4FxWNXQsWfa7k8GVKnVHs+B/FzbGM4/Jbo9NJVyz+V0+5/YaUUkQ9O0Fdb/oxpV+3KknhIVg=="
$destinationContext = New-AzureStorageContext –StorageAccountName $destinationStorageAccountName -StorageAccountKey $destinationKey   
$destinationContainerName = "migratedvhds"

6. Copy the blob now from source to target

$blobCopy = Start-AzureStorageBlobCopy -DestContainer $destinationContainerName -DestContext $destinationContext   -SrcBlob $blobName  -Context $sourceContext  -
SrcContainer $sourceContainer

7. Check the status of blog copy.

The blob copy may take up to few hours depending on the size of the blog e.g. I have seen 1 TB of data disk to be moved takes 
~4 hours
$blobCopy | Get-AzureStorageBlobCopyState   #to check the status
Once the blog gets completely copied, the next step is to create an Azure disk as shown below. If you need to use new Azure Portal, search "OS Disks" and create one.
Use the VHD URL explorer to select the blob from the destination container that was copied earlier. If you migrating the VM please select “The VHD contains an 
operating system.” If you are migrating data disk uncheck the previous check box. 
After the disk is created, if the disk created is of type "operating system" then create a new VM.
When creating the VM select the disk which just was created. This would ensure you have the same copy of the virtual machine as of the source. 

If the disk created above is a data disk, then add this disk to an existing VM using "Add Disks" option.

8. Clean up

Last and final step is clean up the source VM's, disks and blobs. 
Detach the disks you attached.
Delete the VMs.