Tag Archives: IaaS

VM Inception | Nested Virtualization in Azure

I bet that most of you have watched the movie “Inception”, where a group of people are building a dream within a dream within a dream. Before Windows Server 2016 you couldn’t deploy a VM within a VM in Hyper-V. Lot of people are/were encouraged to use VMware as it supported this capability called “Nested Virtualization”. But with the release of Windows Server 2016 & Hyper-V server 2016 this functionality has been introduced. This is specially useful when you don’t have lot of hardware to run your lab environments or want to deploy a PoC system without burning thousands of dollars.

Microsoft announced the support for nested virtualization Azure IaaS VMs using the newly announced  Dv3 and Ev3 VM sizes. This capability allows you to create nested VMs in an Azure VM and also run Hyper-V containers in Azure by using nested VM hosts. Now let’s have look on how this is implemented in Azure Azure Compute fabric.

Image Courtesy Build 2017

As you can see in the above diagram, on top of the Azure hardware layer, Microsoft has deployed the Windows Server 2016 Hyper-V hypervisor. Microsoft then adds vCPU on top of that to expose the Azure IaaS VMs that you would normally get. With nested virtualization, you can enable Hyper-V inside those Azure IaaS VMs running Windows Server 2016. You can then run any number of  Hyper-V 2016 supported guest operating systems inside these nested VM hosts.

Following references from MSFT provides more information on how you can get started with nested virtualization in Azure.

 

 

 

 

 

Backup ARM VMs in Azure | Tips & tricks

As you already know Microsoft Azure Fabric is now in version 2 which is sometimes referred to as Azure Resource Manager (ARM) deployment model. Most of the services from old Azure Service Management model are now available in the new model (the new portal) and today we are going to see how we can backup VMs deployed using ARM deployment model using a Azure Recovery Services Vault.

Note that you may notice another two services in your Azure subscription called Backup vaults & Site Recovery vaults which are redundant and has no use. (They are just placeholders which will be removed soon I assume)

Backup ARM VMs (1)

Essentially following scenarios are supported in a new Recovery Services vault. If you are using premium storage accounts for your VMs  keep in mind that it is only supported in a public preview and not generally available as of yet.

  • Azure Resource Manager VMs
  • Classic VMs

The process can be done in few easy steps.

Creating a Recovery Services Vault

A Recovery Services vault holds all the backups and recovery points of the VMs that are being protected along with the backup policy applied to that vault.  One important thing to keep in mind is that Recovery Services Vaults are geo specific, meaning if you need to backup a VM in one region the target vault should reside in the same region as well.

In the Hub menu, click Browse and then search for Recovery Services. I’ve already added it as a favorite by clicking the star right next. Then select Recovery Services vault and click Add.

Backup-ARM-VMs-2.png

Provide a name, select the target Azure subscription, create a new resource group or select an existing one and finally select the region for your Recovery Services vault.

Backup-ARM-VMs-3.png

Next you can select the storage replication option. The default is Geo-redundant storage and if you want a cheaper (but not durable as Geo-redundant) option you can opt out for locally-redundant storage.  Click the All Settings option in your vault dashboard to get started.

Backup-ARM-VMs-4.png

Select a Backup Target

You need to discover your Azure ARM VMs first before they are added to a recovery services vault. This will identify the VMs that can be protected by your recovery services vault.

Backup-ARM-VMs-5.png

Define a Backup Policy

A backup policy defines how frequent the VMs are protected and when the recovery points are created along with the retention range for those recovery points. You can edit the default policy to fit to your needs or create new policy here. You can choose between a daily or weekly schedule to backup your VMs.

Backup-ARM-VMs-6.png

Next select the desired VMs that you wish to backup and finally click Enable Backup.

Backup-ARM-VMs-7.png

Backup-ARM-VMs-8.png

Start the Initial Backup

By default the first scheduled backup is the initial backup. If you want to manually force the first backup it is also possible. In the vault dashboard click Azure Virtual Machines and right click on the desired VM and select Backup Now.

Backup-ARM-VMs-9.png

You can see the backup job progress by clicking All Settings > Jobs > Backup Jobs as below from the vault dashboard.

Backup-ARM-VMs-10.png

When you further expand the backup job you can see the status of each task running underneath.

Backup-ARM-VMs-11.png

SOS for Azure VMs with Set-AzureRmVM

“Save Our Souls” is the International distress call for help in maritime operations. Over the years SOS has become more common term to imply a call for help in a disastrous situation. In Microsoft Azure sometime you may have faced such situations especially with IaaS VMs. For an example RDP not working in a Windows VM or SSH ceased to function in a Linux VM. When all hope is lost you may contact Azure Support or try to restart the VM (from Azure Portal) or resize the VM as a last resort.

Now going into all of the above troubles is no longer required to rescue your Azure IaaS VMs. The latest Microsoft Azure PowerShell cmdlet improvements allows you to redeploy your virtual machine when you invoke a redeploy operation through Azure PowerShell.

Important

  • Below cmdlet works only with Azure Resource Manager based VMs.
  • Latest version of Azure PowerShell needs to be installed in the management PC from which you are invoking the redeploy operation.
  • Dynamic IP addresses will be changed after completing the redeploy operation.
  • Data on local disks (ephemeral storage) will be lost.

Following is the syntax for the updated Set-AzureRmVM cmdlet. Note that the -Redeploy switch is used to invoke a redeploy operation.

SetAzureRmVM Redeploy ResourceGroupName $rgname Name $vmname

The VM status changes from Running > Updating > Starting > Running during the operation. The final Running status means that VM has been successfully redeployed.

For a complete reference of the Set-AzureRmVM cmdlet please refer here.

Microsoft Azure new SQL IaaS configuration experience

Happy New Year to all of my blog readers.

2016 is going to be an exciting year as we wait for the newest releases of Azure Stack, Windows Server & System Center from Microsoft. In my new year post I’m going to share some happy news for all Azure Ninjas out there working on IaaS.

If someone asks me what Microsoft Product makes my Azure deployment most complex I’d answer SQL server. The reason is SQL server being a awesome product needs an extra DBA care. When you are provisioning a SQL server VM in Azure you need to think about IOPs, Connectivity, Backups, Security first hand and how to provide the same level of experience as of a  on-premises data center.

Microsoft Azure team understood the pain us system administrators face when it comes to SQL server configuration and came up with a set of new configuration options for SQL VMs in Azure Resource Manager Deployment Model. In order to use the new configuration experience you need to create a VM in new Resource Manager deployment model and it supports any version of SQL server that Azure marketplace offers.

Simplified Connectivity

SQL IaaS in Azure (1)

In the classic model in order to configure SQL server connectivity from on-premises using SQL Server Management Studio (SSMS) you had to first Remote Desktop to the VM, open the SQL Server port in Windows firewall, enable SQL Server Authentication, and to allow inbound connectivity had to create a Public Azure endpoint for the VM. The new experience allows you to do all of that in the portal itself during the provisioning time and you can select whether this SQL server can only be contact from the VM itself or within the Virtual Network.

Automated Patching & Backup

SQL IaaS in Azure (3)

Another pain that IT Pros encounter with SQL server is patching. The new automated patching capability allows the administrators to define a maintenance window at their convenience during the VM provisioning itself. So if your customers need to take off the burden of patches for their SQL VM instances in Azure this is a life saver.

SQL IaaS in Azure (4)

What about backup then? The new Automated backup feature allows administrators to automatically backup all databases in SQL Server and it is not enabled by default  as different workloads can have  different backup requirements. You can retain these backups up to 30 days and even encrypt them.

Storage Optimizations

Be it on-premises or cloud the most important thing in SQL server instance is storage. Previously in Azure classic deployment model we had to attach the required number of data disks to provide the IOPs and throughput manually and stripe the SQL files across the disks or create a Storage Pool to divide the IOPs or throughput across them.  The new deployment model has all of these included in to provisioning by enabling us to specify the required IOPs, throughput and VHD size within the allowable limit of the VM instance size. The cool thing is when you tweak these settings Azure automatically changes the number of data disks using  Windows storage spaces. So you no longer have to worry about calculations.

Also you can select between any of the below three storage optimization method for your SQL VM depending on your workloads.

  • General is the default setting and supports most workloads.
  • Transactional processing optimizes the storage for traditional database OLTP workloads.
  • Data warehousing optimizes the storage for analytic and reporting workloads.

SQL IaaS in Azure (2)

For the automation geeks you can use the Azure Resource Manager templates to make it even more automated for larger deployments. Considering the amount of effort and time taken previously for SQL IaaS VM configuration in Azure the new deployment experience offers much more hassle free one time setup for SQL workloads.

Reserving existing dynamic VIPs for Azure Cloud Services

When you create a cloud service in Azure the Public Virtual IP address (VIP) assigned to it is by default dynamic. What this means is that once you stop the cloud service from Azure Portal the next time you start it you are assigned a different public IP. As an example if you de-allocate the underlying VMs in a cloud service this will happen definitely.

Microsoft understands that the customers require static Public IP addresses for their workloads due to the fact that Internet enabled DNS always rely on a static IP. When you create a new cloud service you can assign a static IP reservation for that. Previously it was only possible for new cloud services not existing deployments.

All Azure subscriptions are authorized to use 20 reserved IPs.However if you require more you can ask them an extension.

Let’s see how we can reserve an existing VIP assigned to a cloud service reserved.

Convert a dynamic VIP of to Reserved VIP

Take a look at below Azure PowerShell cmdlet.

New-AzureReservedIP -ReservedIPName “jcbvip01” -Location “Southeast Asia” -ServiceName “jcbvipcs”

Notice the -ServiceName parameter. This enables to provide an existing cloud service name where it will automatically reserve the exiting VIP.

Removing a Reserved IP from an existing deployment

You can use below cmdlet to remove the static VIP association.

Remove-AzureReservedIPAssociation -ReservedIPName “jcbvip01” -ServiceName “jcbvipcs”

Reassigning the VIP to another deployment

Here you simply provide the new cloud service name.

Set-AzureReservedIPAssociation -ReservedIPName “jcbvip01” -ServiceName “nabvipcs”

One important thing is that reassigning should occur within the same Azure region as these IP addresses are location specific. You cannot assign the same IP reservation to a service that is running in a different Azure region.

Internet Access denied in Azure VM

I’ve been working with Microsoft Azure for the past 4 years and sometimes it’s quite challenging to find answers to weird common service misconfiguration that people do. Following is such a scenario where Internet access to Azure VM suddenly stopped. Recently I’ve been working with a customer on an Azure PoC with below setup and I encountered the same issue.

Azure Site

  • One Azure VM
  • Virtual Network with a dynamic VPN Gateway
  • DNS servers are on-premise (only one DNS server)

Issue

Due to an issue with the on-premise VPN device there are frequent disconnections in the VPN. When that happen Internet access is gone in the Azure VM. However RDP access is okay.

Why did I lose Internet when VPN was down?

Since I had only one DNS server on-premise providing Name Resolution for Azure virtual network it was also providing DNS for Internet access as well. So once the VPN is down the VM is basically orphaned in terms of Internet.

Solution

When your create a VM associated to Azure virtual network it will automatically assign an Azure DNS server. You can make a note of this once you login. After you have changed the DNS settings in Azure virtual network to point your on-premise DNS server, add this Azure provided DNS server IP address as a secondary DNS from the Azure Portal.

Internet Access Issue Azure DNS 1

Remember once you do any change to the DNS settings in an Azure virtual network you will have to reboot any servers that are in the same virtual network from the Azure Portal. Restarting within the virtual machine won’t have any effect so you need to make sure you do that from portal as below.

Internet Access Issue Azure DNS 2

Once the restart is completed check the network adapter status in the VM. It will display the Azure DNS as a secondary server. Now even though the VPN is down you can access internet from the VM.

Internet Access Issue Azure DNS 3

Azure VM Reboot Logs

How many of us really pay attention to e-mails sent by Microsoft Azure regarding planned maintenance? Does anyone actually monitor what happens to our VMs during a planned maintenance window schedule by Azure Team? If the answer is NO let’s see how we can get some insight on IaaS VM availability during a scheduled maintenance.

As there are periodic updates that need to be performed in Azure data centers globally, Microsoft will notify you of any scheduled maintenance windows. Usually we are not facing any service interruption during such unless Microsoft has specifically mentioned that there will be a service unavailability. Also sometimes these updates may restart the Azure VMs if required and up to now you as a customer didn’t have any visibility other than the regular email communique.

If you play attention to any cloud service (hosting VMs) > Dashboard section you may notice that there is a new feature called View Reboot Logs is available as per below. Note that this is the only place you get such an option as of now.

Azure VM Reboot Logs 1You can select a data range and analyze what are the planned reboots that has happened. Remember this is only applicable for planned maintenance not unexpected downtime.

Azure VM Reboot Logs 2

For shell lovers below is a sample PowerShell cmdlets that you need to run to get a more liner output.

Get-AzureDeploymentEvent -ServiceName <cloudservicename> -StartTime <start time>-EndTime <end time>

The input for start and end times should be similar to the format of get-date cmdlets output.

As per Microsoft they will be adding more events to this feature where you will have complete visibility over your VM availability. For me this is yet another win for my customers to see really understand the value of Microsoft Cloud platform.

Backup Azure IaaS VMs with Azure Backup

We have an exciting update this week with Azure Backup. Now you can directly backup your Azure VMs to Azure Backup vaults easily. This is something that customers were asking for sometime. Let’s take a look at what are the considerations you are going to take into account if you are using this new feature.

  • Backup with no impact to production workloads
  • You do not need to shutdown the VMs
  • Provides application level consistency for Windows operating systems
  • Provides file system level consistency for Linux Operating systems

Backup Procedure

  • Create a backup vault in the same region as your VMs. Currently this feature supports within a single region. But I expect them to make it a geo-enabled feature as keeping the backup in the same data center seems little odd.Azure VM Backup 1
  • Discover the VMs that you need to backup first. For that expand the backup vault > Registered Items > Click DiscoverAzure VM Backup 2

Azure VM Backup 3

  • The next step is to register your VMs in the backup vault. Click the Register button as in the above picture. Keep in mind the VM should be running for the registration to be successfully completed.Azure VM Backup 4
  • Once registration is done click Protect to start protection. Here you need to select the VMs that you need to backup and create a backup policy for the same. You can select a backup frequency as well as a retention range that suits your backup requirement.Azure VM Backup 5

Azure VM Backup 6

  • Remember you can add only one backup policy per VM. Also the maximum retention period is 30 days and you only have backup time slots that are predefined with 30 minute intervals.

Performing a Backup

If you want to perform an adhoc backup out of the backup policy in the Protected Items tab of the backup vault select Backup Now. You can even stop protecting the VM by clicking Stop Protection icon.Azure VM Backup 7

Restore from a backup

  • Go to the Protected Items tab and click Restore. This opens the Restore an Item wizard.Azure VM Backup 10
  • In the Select a recovery point page you can select a restore point from available list of restore points.Azure VM Backup 11
  • In the Select restore instance page you need to specify where you want to restore the VM. This is an alternate location with new VM name, can be a different cloud service and a different Virtual Network. It’s up to you to select those parameters but you might need a new cloud service and a new network if you want to test the back up isolated first.Azure VM Backup 12

Monitor Backup Progress

You can monitor the backup progress in the Jobs page. This is important as you may need to know if a backup operation has failed or server registration has failed.Azure VM Backup 8

If I drill down through my existing adhoc backup I can see the task sequence there.

Azure VM Backup 9As you can see the word PREVIEW in this service (some pages) I wouldn’t be doing this on production but it’s still worth a try.

 

All about Azure D-Series Virtual Machines

As you already know Azure has the biggest and sweetest chocolates to offer in the IaaS market. Let’s see why these big D-series VMs are so important and why you should consider moving into D-series.

Suitable workloads for D-Series

  • Big Data
  • Video Rendering systems
  • Transaction Processing Systems
  • Analytics
  • AI

As you can see D-Series the ideal candidate for your performance eating Database Servers or Web Servers. There are two categories, General Purpose and High Memory.

Type Name No. of vCPUs Memory (GB) Local SSD (GB)
General Purpose Standard_D1 1 3.5 50
Standard_D2 2 7 100
Standard_D3 4 14 200
Standard_D4 8 28 400
High Memory Standard_D11 2 14 100
Standard_D12 4 28 200
Standard_D13 8 56 400
Standard_D14 16 112 800

As you can see the largest VM provides 16 vCPUs 112 GB of RAM and 800 GB of SSD storage which is more than enough for a high I/O, high CPU demanding workloads.

The local SSD storage is a temporary storage, same aw in AWS EC2 compute instances. If you are running SQL 2014 this will help you to leverage Buffer Pool Extensions feature to provide much higher I/O throughput. In BPE the local SSD will be used to cache memory pages from RAM whenever needed.

Also you can use D-series instances for your cloud services (web roles & worker roles) as well.

If you are uncertain about moving your workloads to cloud due to performance, I hope you already have the answer now.

Assigning Static Internal IP for an Azure VM

If you are doing your DEV/Test in Azure and de-allocating your VMs frequently you may have noticed that the Internal IPs assigned to your VMs are changing. By nature Azure wants you to run your VM continuously to have a reservation for your Internal IPs as there are million tenants like you using Azure over the world and to ensure everybody gets equal service.

If you are running DNS server in Azure you need to have a static IP regardless you de-allocate the VM, you need the same IP to work next time to prevent name resolution conflicts. Today I’m going to show you how to assign a Static DIP to Azure VM and some of the best practices that you should keep in mind when assigning DIPs.

Keep in Mind

  • If you have both IaaS & PaaS services in your tenant (i.e VMs and Cloud Services) it is always recommended to keep them in different subnets if you are using DIPs. Just in case if you are de-allocating a VM with static DIP it prevents your cloud services from acquiring the same DIP if they are in the same subnet.
  • Only assign DIPs for workloads that needs them the most (i.e DNS). Again this is not a requirement but you’l have to worry less if you have only fewer configuration changes.
  • Always use a Virtual Network with subnets properly assigned. Otherwise it would be pointless to use a DIP as there won’t be any allocation at all.

Lets take a look on the process.

Check the availability of the IP Address

You have to make sure the IP Address that you are going to use from your IP Pool is available prior assigning.

Test-AzureStaticVNetIP –VNetName JCBVNet –IPAddress 192.168.1.5

In the above example I’m checking the availability of the IP address 192.168.1.5 for the Virtual Network JCBVNet.

Assigning Static DIP

For a new VM

Make sure you get your PowerShell cmdlets right. You can use variables instead of hard coded placeholders for parameters like -Name but again that’s upto you. Parameters like -ImageName has lengthier vaules to it is better to get the image name and store it in a variable when you pass the value to a cmdlet. Some of these parameters like -AffinityGroup are not mandatory but will be useful depending on your deployment. For a complete reference just bing (yes bing not google) the cmdlet name.

New-AzureVMConfig -Name jcbdipvm1 -ImageName $img –InstanceSize Small | Set-AzureSubnet –SubnetNames JCBVNet | Set-AzureStaticVNetIP -IPAddress 192.168.1.5 | New-AzureVM –ServiceName jcbdipsvc –AffinityGroup “jcbAG”;

For an existing VM

From my experience, it is always better if you can stop the VM before you perform this on a existing VM. This is because the Update-AzureVM cmdlets restarts the VM once it has assigned the DIP. If the VM was running it will take some time and believe me you don’t want that to happen on something like DNS server. If you have previously assigned a DIP you will have to remove it first.

Get-AzureVM -ServiceName jcbdipsvc -Name jcbdipvm2| Set-AzureStaticVNetIP -IPAddress 192.168.1.6 | Update-AzureVM

Removing a DIP

Get-AzureVM -ServiceName jcbdipsvc -Name jcbdipvm1 | Remove-AzureStaticVNetIP | Update-AzureVM

As part of the update VM will automatically receive a new IP address once it is restarted by the Update-AzureVM cmdlet.

It’s not rocket since if you read carefully. This is very useful for a production environment or if you have a lab environment that is not going to be running continuously to save Azure credits but still require static IP addresses for the workloads. My advice is to learn PowerShell a bit before you deal with Azure or you can keep blaming the platform not being good enough. (Which is so not true.)