Book Image

Learning Microsoft Azure Storage

By : Mohamed Waly
Book Image

Learning Microsoft Azure Storage

By: Mohamed Waly

Overview of this book

Microsoft Azure Storage is the bedrock of Microsoft's core storage solution offering in Azure. No matter what solution you are building for the cloud, you'll find a compelling use for Azure Storage. This book will help you get up-to-speed quickly on Microsoft Azure Storage by teaching you how to use the different storage services. You will be able to leverage secure design patterns based on real-world scenarios and develop a strong storage foundation for Azure virtual machines. You will start this book with an introduction to Microsoft Azure storage and how it can be used to build large-scale, real-world applications using Azure storage services such as blob, table, queue, and file. This book will also teach you about the different types of Azure Storage. You will then find out the best practices for designing your Azure VM storage, whether it is Windows based or Linux based and how to migrate your storage in different scenarios. You will learn also how to plan and implement your SQL database solution on Azure, and how to build your SQL database in different service models (IaaS/PaaS). Moreover, you will also learn best practices for dealing with Azure Backup, the role of Azure Site Recovery, and the solutions they offer in different scenarios. Finally, you will use StorSimple to unlock the maximum value from all of your data, and some tools that will help you manage your storage on-and off-premise (Azure), such as AzCopy and Storage Explorer. Monitoring your storage in no laughing matter, so you will learn to monitor, diagnose and troubleshoot it.
Table of Contents (9 chapters)

ASM versus ARM model

At the time of writing, Azure services are being provided via two portals, which follow two different models. The Azure classic portal follows the ASM model and the Azure portal follows the ARM model.

Azure classic portal (ASM model)

Historically, Azure services were provided via one portal prior to 2014, the classic portal, which can be accessed via the following URL

The model that was used for that portal is called the ASM model, within which each resource existed independently. You could not manage your resources together; you had to build up and track each resource. For example, you would have to manage storage from the storage blade, and the same goes for the virtual networks, VMs, and so on. So, when your environment got bigger, there would be chaos in the management scheme. You would have to know which VMs were stored in which storage account, and that could lead to some critical situations, such as reaching the IOPs limits of the storage account. In turn, this could result in you accidentally creating a new VM and assigning it to that storage account. As a result, the VM would run with terrible performance. This would not be your only concern when working with the ASM model; you might want to delete a solution with multiple resources, which you would have to do manually for each resource.

When you open the Azure classic portal, it will look like the following screenshot:

Figure 1.2: Azure classic portal

Azure portal (ARM model)

In 2014, Microsoft launched a new portal which follows a new model, called the ARM model. This portal can be accessed via the following URL

This model depends on the concept of resource groups, which means you can group all your resources within a container, resulting in resources being deployed in parallel. As a result, you will not face the same problems as you did with the classic portal.

The following diagram describes the deployed resources through the ARM model:

Figure 1.3: Resource Manager management model at a high level

Here are the benefits you will gain using this portal:

  • Ability to manage your resources as a group instead of managing them separately.
  • Use Role Based Access Control (RBAC) to control access to resources, so that you can assign permissions to a user on a resource or some resources but not to other resources (as it was in the classic portal).
  • Use tags to organize and classify your resources, which can help you with billing. For example, you might want to monitor the billing of some resources that make up a solution, for example, a web server. By assigning a tag to the resources that make up that solution, you would be able to monitor its billing, and so on.
  • Support the usability of JSON to deploy resources instead of using the portal.
    • Deploy resources in parallel instead of deploying them sequentially and waiting until every resource deployment finishes to deploy another one.
    • Specify dependencies during the deployment of resources. For example, a VM will not be created until a storage account and a virtual network are deployed because the VM VHD would need a place to be stored in and an IP Address from a virtual network./li>
    • Reuse the JSON template to deploy a solution with the same specifications.
  • Resources with the same life cycle should be gathered in the same resource group.
  • Resources in different regions can be in the same resource group.
  • The resource cannot exist in multiple resource groups.
  • A resource group supports RBAC, wherein a user can have access to some specific resources, but no access to others.
  • Some resources can be shared across resource groups, such as storage accounts.
  • ARM VMs can only be placed in ARM storage accounts.

When you open the Azure portal, it will look like the following screenshot:

Figure 1.4: Azure portal

Deployment model tricks

Here are some things you need to consider:

  • You cannot create a VM using the ARM model and assign it to a virtual network built using the ASM model
  • You cannot use a prebuilt image that was created using ASM APIs to build a VM using the ARM model, but as a workaround, you can copy the VHD files from the storage account in the classic portal to a storage account created in the ARM model
  • You can migrate assets from the ASM model to the ARM model
  • Every resource must be assigned to a resource group, so whenever you want to move a resource between resource groups you must remove it from its current resource group, then add it to the new resource group.