Azure Cloud Shell is Awesome!

At Build 2017 Microsoft announced the Azure Cloud Shell. This is actually really cool! Check out how easy it is to use Azure CLI 2.0 to create a new storage account and get its Connection String.

Migrate a Storage Account to ARM

If you’ve been working with Azure for a while, you may have some of your Azure Storage Accounts deployed on the Classic deployment model (ASM). To simplify the deployment and management of resources, Microsoft recommends that we use Azure Resource Manager (ARM) for new resources. If possible, it’s also recommended that we redeploy existing resources through Azure Resource Manager (ARM), because the two models are not completely compatible with each other.

Fortunately, moving resources like Azure Storage is possible through PowerShell. Use
the Move-AzureStorageAccount cmdlet to prepare, migrate and to validate that the migrated Azure Storage Account is moved successfully to a resource group in the Azure Resource Manager (ARM).

Validates the Azure Storage Account for migration.

Move-AzureStorageAccount -Validate `
                         -StorageAccountName "ContosoStorageName"

Prepare the Azure Storage Account for migration.

Move-AzureStorageAccount -Prepare `
                         -StorageAccountName "ContosoStorageName"

Kick-off the migration.

Move-AzureStorageAccount -Commit `
                         -StorageAccountName "ContosoStorageName"

Source: Move-AzureStorageAccount

Deploying Azure Marketplace VMs

The first step is to gather information about the Market Place Virtual Machine (VM) image that we want to deploy. For this example I decided to deploy a Tableau Server image.

Login-AzureRmAccount

$location = 'eastus'
  
Get-AzureRmVMImagePublisher -Location $location `
    | Where-Object -Property PublisherName -Like Tableau*
 
$publisherName = 'tableau'
  
Get-AzureRmVMImageOffer -Location $location `
                        -PublisherName $publisherName
 
$offer = 'tableau-server'
  
Get-AzureRmVMImageSku -Location $location `
                      -PublisherName $publisherName `
                      -Offer $offer `
      | Select-Object -Property 'Skus'

Skus                  
----                  
bring-your-own-license

Now that we have the image information, it’s time to create an Azure Resource Manager (ARM) Template.

Geo-HA Service Fabric Cluster

One of the biggest challenges that we face when we build an Internet-scale solution, is high availability across geographic locations (Geo-HA). Why is this important? Well, there can be a few different reasons. The most common reason, is to be able to survive data center outages. Another reason, is to bring services closer to end users so that we can provide good user experiences.

Geo-HA brings challenges to the table. For example, should we use an Active-Passive or Active-Active strategy for data across regions? Keeping in mind that Active-Active is difficult to get right, we need to take time to analyze and to make the correct choices. We need to consider our Disaster recovery (DR) plan, target RPO and RTO. Azure has a whole bunch of mechanisms for replication, backup and monitoring, so how do we decide what’s the right combination?

Today’s Internet-scale services are built using microservices. Service Fabric is a next-generation middleware platform used for building enterprise-class, Tier-1 services. This microservices platform allows us to build scalable, highly available, reliable, and easy to manage solutions. It addresses the significant challenges in developing and managing stateful services. The Reliable Actors API is one of two high-level frameworks provided by Service Fabric, and it is based on the Actor pattern. This API gives us an asynchronous, single-threaded programming model that simplifies our code while still providing the advantages of scalability and reliability guarantees offered by Service Fabric.

A Service Fabric cluster is HA within its geographic region by default. Thinking about our heritage of on premise data centers, we’ve poured thousands of man-hours to deploy Disaster Recovery sites in secondary physical locations, because we know that everything is possible. Over the past few years, we’ve experienced many interesting scenarios, for example, a cut cable, or a faulty DNS entry broke the Internet. So why should we do anything differently in the cloud? We must treat each region as we treat our own data centers and think about Geo-HA.

The rest of this post is about taking high availably to the next level by deploying a Geo-HA Service Fabric cluster.

Data Locality is Important

Never would have imagined that the laws of physics would be so important in a world where virtualization is the new normal.

Data Locality, refers to the ability to move the computation close to the data. This is important because when performance is key, IO quickly becomes our number one bottleneck. Data access times vary from milliseconds to seconds because of many factors like hardware specifications and network capabilities.

Let’s explore Data Locality through the following Scenario. I have eight files containing data about multiple trucks, and I need to Identify trips. A trip consists of many segments, including short stops. So if the driver stops for coffee and starts again, this is still considered the same trip. The strategy depicted below is to read each file and to group data points by truck. This can be referred to as mapping the data. Then we can compute the trips for each group in parallel over multiple threads. This can be referred to as reducing the data. And finally, we merge the results in a single CSV file so that we can easily import it to other systems like SQL Server and Power BI.

The single machine configuration results were promising. So I decided to break it apart and distribute the process across many task Virtual Machines (TVM). Azure Batch is the perfect service to schedule jobs.

Has Something Gone Wrong?

Generally, we choose to leverage Read-Access Geo-Redundant Azure Storage Accounts (RA-GRS) because we can use it as part of our disaster recovery (DR) plan. And sometimes, we forget that our devil is in the details. Disaster recovery (DR) plans are rarely tested and can cause headaches when they are. So let’s relieve some of those headaches.

Headache…

“Geo Replication Lag” for GRS and RA-GRS Accounts is the time it takes for data stored in the Primary Region of the storage account to replicate to the Secondary Region of the storage account. Because GRS and RA-GRS Accounts are replicated asynchronously to the Secondary Region, data written to the Primary Region of the storage account will not be immediately available in the Secondary Region. Customers can query the Geo Replication Lag for a storage account, but Microsoft does not provide any guarantees as to the length of any Geo Replication Lag under this SLA.

The Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the first items that come up in DR discussions. When we use RA-GRS we control the RTO because we decide when to read from the secondary location. The RPO is a bit different because that can vary due to physics and load. The best way get current Recovery Point (RP) is to get the last sync time for the RA-GRS in question. This post is all about getting the right information, when we need it, because we need facts to make the right decisions.

Deploying Nano Server to Azure

Based on the current builds, compared to Server, Nano Server has 93 percent lower VHD size, 92 percent fewer critical bulletins and 80 percent fewer reboots!

I’ve been curious about Nano Server for a while now. And I recently noticed that it was available on Microsoft Azure. This post is definitely from a developers point-of-view. It goes through the steps required to create a functional Nano Server Virtual Machines (VM) on Microsoft Azure.

Nano Server is ideal for many scenarios:

• As a “compute” host for Hyper-V virtual machines, either in clusters or not
• As a storage host for Scale-Out File Server.
• As a DNS server
• As a web server running Internet Information Services (IIS)
• As a host for applications that are developed using cloud application patterns and run in a container or virtual machine guest operating system.

The Adventure

Nano Server is a remotely administered server operating system (OS). Wait. Let me repeat this because it’s important… Nano Server is a remotely administered server operating system (OS). Developers, Nano Server is a server OS optimized for clouds and data centers. It’s designed to take up far less disk space, to setup significantly faster, and to require far fewer restarts than Windows Server. So why does this matter? Well it means more resources, more availability and stability for our Apps. And it also means that it’s time to learn new skills, because there is no local logon capability at all, nor does it support Terminal Services. However, we have a wide variety of options for managing Nano Server remotely, including Windows PowerShell, Windows Management Instrumentation (WMI), Windows Remote Management, and Emergency Management Services (EMS).

Upload a VHD to Storage Using AzCopy

What’s the best way to upload a VHD to Azure Storage? This question comes up on a regular basis and I decided that it was time to share an example that uses PowerShell and AzCopy to upload a VHD to Azure Blob Storage. As you go through this post, remember that a VHD must be uploaded as a Page Blob for it to be usable as a Virtual Machine (VM) image.

Share this:

Microsoft Azure has a lot of options when it comes to provisioning environments and resources. In my last post about troubleshooting Virtual Machine allocations, I enumerated a few of these options and briefly mentioned that I favored destroying environments to shutting them down. In this post, I will try to give more context around my preference.

Can’t Delete an Azure Resource Group

Recently, I hit a wall. I wasn’t able to delete my Azure Resource Groups and got quite frustrated… I’m writing this post, with hopes that you may save some time, frustration and energy with your ongoing challenge.