Azure

Virtualisation has been around for a number of years, with companies such as VMware being formed in 1998.  We are used to the abstraction of compute resources from the underlying hardware to provide logical isolation of virtual machines driving greater consolidation on providing a better return on investment.

Microsoft have taken the concept of a virtual machines and broken it down further to enable the consumption of Azure resources to be easier depending on the purpose of the virtual machine.  To explain this further lets delve into the three types of Azure Virtual Machines.

App Service

The purpose of the App Service is to allow the developer to create and manage websites and applications without needing to worry about managing and maintaining the underlying operating system.

Depending on the App Service Plan chosen, will entitle you to a number of features for your website which are:

• Amount of disk space
• SLA
• Auto Scale
• Geo Distributed Deployment
• Custom Domain
• Staging Environment

Most businesses would choose the Standard Tier as this provides an SLA of 99.95% along with Auto-Scale.  More information on the types of App Service plans can be found here.

Cloud Services

Azure Cloud Services are the middle ground between an App Service and a traditional virtual machines.

Cloud Service virtual machines provide two options which are:

• Web Role which runs Windows Server and IIS
• Work Role which runs Windows Server without IIS

When you create a Cloud Service you specify how many of each type you require and the underlying virtual machine, configuration and patching is performed by Microsoft.  You do however get the ability to RDP onto the virtual machine and install services.

It is important to note that Cloud Service virtual machines do not provide persistent storage, so this needs to be handled in the application architecture.  They do however support load balancing, and fault tolerance via in built availability sets.

Cloud Servies virtual machines use the same categories of pricing and specification as tradtional virtual machines which I will cover later in this blog post.

Virtual Machines

Azure Virtual Machines provide the most control.  You are responsbile for deployment, patching, load balancing and availability of the operating system and in-guest application.  Pretty much the same as when you run virtual machines on premises.

Each virtual machines comes with a persistent operating system disk and a non-peristent temporary drive which can be used to store data or perform storage related tasks whilst the VM is powered on.

The diagram below shows the complexity of management per Azure virtual machine type.

Great stuff, now we understand the types of virtual machines, what about virtual machines sizes, performance and capacity?

Virtual Machine Sizes

When a number of virtual machines are accessing the same underlying physical hardware, there has to be winners and loosers when resources become contended.  Depending on the type of virtual machine you purchase, will result in the performance characteristics available.

In Azure, Microsoft break down virtual machines into three categories which are A, D and G series.

A Series virtual machines are designed to run your standard everyday workload. They provide upto 500 IOPS per disk and can support up to the following specifications:

• 56GB RAM
• 8 CPU Cores
• 4 NICs
• 16 Data Disks at 500 IOPS each

Microsoft offer a subset of subset of the A Series called Compute Intensive which provide up to the following specifications:

• 112GB RAM
• 16 CPU Cores
• 4 NICs
• 16 Data Disks at 500 IOPS each

D Series virtual machines are designed to run more intensive workloads with the key difference being that the temporary disk is backed by SSD.  They provide upto 500 IOPS per disk and can support up to the following specifications:

• 112GB RAM
• 16 CPU Cores
• 8 NICs
• 32 Data Disks at 500 IOPS each
• 800GB Temporary SSD

Microsoft offer the Dv2 Series virtual machine which provides a slightly better specification CPU.  The more interesting subset of the D Series is the DS.  This category provides shared SSD for the operating system disk.  Specifications are up to the follwing:

• 112GB RAM
• 16 CPU Cores
• 8 NICs
• 32 Data Disks at 224GB and 50,000 IOPS each with 512MB bandwidth

G Series virtual machines are massive and provide a huge amount of compute power, with specifications as follows:

• 448GB RAM
• 32 CPU Cores
• 8 NICs
• 64 Data Disks at 500 IOPS each
• 6,144GB Temporary SSD

Again we have a subset of the D Series which is the DS Series.  This provides the same specification with shared storage the operating system disk.

The diagram below shows different virtual machines sizes.

More information on Azure Virtual Machine sizes can be found here.

 

Final Thoughts

It is clear that Microsoft have given alot of thought to Azure Virtual Machines with different catergories catering for different levels of ownership and performance.  It is worthwhile reviewing the Azure Subscription Limits, Quotas and Constraints documentation to ensure that your virtual machines aren’t constrained by an unknown factor.

When I think about storage, I normally visualize hard drives in client devices, some type of enterprise shared storage or a hyper-converged appliance that supports a single person or business towards meeting it’s requirements for storage capacity, performance, integrity and recoverability.

To talk about Azure Storage, I need to shift my perspective slightly.  Azure Storage is truly a web scale storage solution currently supporting over 50 Trillion or 50,000,000,000,000,000,000 objects which is alot!

To understand Azure Storage we need to understand how it all fits together.  When you have cloud multi-tenancy you need a way to ensure that only you have access to your own data (unless of course you choose to share it).  This is the fundamental underpin of Azure Storage which is your Azure Storage Account.

Azure Storage Account

An Azure Storage Account is the gateway to accessing storage in Azure.  When created you receive a unique namespace which is linked to the type of storage your are going to use for example http://storagevmfocus.blob.core.windows.net.  This then in turn links to your storage billing which is based around four factors:

1. Storage usage
2. Replication of data
3. Read and write operations
4. Data transferred out to other Azure regions

Azure Storage Types

Now that we know that the starting point is an Azure Storage Account, what types of storage can Azure offer?  These are broken down into four areas (I’m beginning to think Microsoft link the number four) which are Blob, Table, Queue and File.

Blob Storage

Blobs is the name given to Microsoft’s cost effective cloud storage.  It is used to store large amounts of unstructured data for example:

• Azure VM Hard Drives
• Documents
• Media Files
• Backup Files

Blobs are further broken down into different categories this is to ensure that the storage is optimized for it’s intended workloads.

Table Storage

Table storage is provided by Microsoft’s NoSQL which is a distributed scale out store. Essentially its a repository for metadata that is captured and then needs to be accessed quickly. Example use cases for Table Storage is shown in the diagram below.

Queue Storage

Queue storage is essentially a reliable messaging solution that passes information between different tiers of an application.

When held in the ‘queue’ data is kept until it is passed ‘a synchronously’ to the application.  Example use cases for Queue Storage are:

• Communication between Websites and Applications
• Hybrid communications between on-premises and Azure applications

File Storage

File storage is your traditional SMB 2.1 or 3.0 file share that we are used to accessing on a daily basis for example \vmfocuscustomer_files.  Access to the file share can be granted from on-premises using the net use command with the storage key for example

net use z: \vmfocusprodstorage.file.core.windows.netvmfocusfileshare /u:vmfocusprodstorage  m1G1Xatnb9NgzEjCrx1gBtQ/xpyFR4N71i6imkt38VvKCWB2bK9X==

This can then be added to a group policy login script for users.

An application would access the file share from an on-premises location using the REST API.

My understanding is that SMB 3.0 file shares provide encryption and persistency they do not provide Role Based Access Control (RBAC) via Active Directory Users & Groups.

Storage Redundancy

Great you say, I have moved some of my on-premises storage to Azure, but how do I make sure that data is available?  Well Azure offers the concept of Storage Redundancy which is broken down into, yes you guessed it four areas, these are:

• Locally redundant storage (LRS)
• Zone redundant storage (ZRS)
• Geo redundant storage (GRS)
• Read access geo redundant storage (RA_GRS)

Locally Redundant Storage (LRS)

Data is held within the same datacentre, however it is replicated three times.  Each replica sits inside a separate fault and update domains.  This uses the same concept as Availability Sets, but for storage.

Use cases, include:

• Protection from hardware failures
• Provide redundancy inside a local datacentre to meet compliance or regulatory requirements

Zone Redundant Storage (ZRS)

Data is held across two or three datacentres either in the same region or across regions.

• Protection from hardware failures
• Provides a higher level of fault tolerance above LRS

Geo Redundant Storage (GRS)

Data is replicated to a second region.  Data is replicated three times in the primary region like ZRS then replicated to a secondary region ‘a synchronously’.  The purpose behind this is to ensure continued storage performance.  Waiting for an acknowledgement from a replicated region would slow storage responses down.

Read Access Geo Redundant Storage (RA_GRS)

Works in the same was as GRS.  However you have read access to the data at the secondary location.  This can be useful for data mining operations where you don’t want to run against the primary set of data.

 

Final Thoughts

Azure storage is huge and needs to be thought about very carefully to ensure that no single part of the chain becomes the bottleneck for example you might have sufficient disk I/O but the limiting factor is the network throughput from source to target.

This leads us onto the next topic of discussion which is Virtual Machines.

Availability Sets are used within Microsoft Azure to ensure that virtual machines are deployed into different Update Domains and different Fault Domains. This allows Microsoft Azure to provide an SLA of 99.95% for the service provided by the virtual machines within the availability set.

• Updates are planned events. For example when the underlying Azure fabric is patched it may require the restart of your guest VM’s.  This is defined as an Update Domain (UD).
• Failures are unexpected events such as hardware failure whether this is physical or logical that impacts the availability of your Guest VM. This is defined as an Fault Domain (FD)

As a minimum two virtual machines are required to be in an Availability Set for Microsoft to provide the 99.95% SLA.

• An Availability Set can be created with a single virtual machine, however Microsoft will not provide an uptime SLA
• Virtual machines within an Availability Set must reside in the same Cloud Service
• A maximum of 100 virtual machines can reside in an Availability Set
• Five update domains are available per Availability Set

That’s all very well and good, but this now means that our application needs to be able to cope with being restarted when a failure or update occurs.  This point for me needs careful consideration when you are trying to meet your business SLA’s within the framework that Microsoft provides in Azure.

We also need to consider how traffic is directed to each of the Guest VM’s within an Availability Set.  This is where a load balancer comes in to direct traffic to the most appropriate Guest VM within the availability set.

You might think that you could put a single VM into an Availability Set to meet SLA requirements.  However this is where Microsoft have a get out of jail free card, a single VM does not receive the 99.95% SLA.  I guess this is because Microsoft don’t know how long it will take that Guest VM to become available in another update or fault domain.

Final Thoughts

Availability Sets require consideration around the design of the application layer to ensure that not only the Guest VM is available but also access to shared data services between them.  It’s also worth noting that application or service failures are not included within the 99.95% SLA.

 

 

When we talk about Identity and Access what do we really mean?  For me, it boils down to who you are and what you are entitled to access.

Simple statement, but it does start to get rather complicated when you think about Identity Management.  If you think about your own organisation what directory service does it use? Probably Active Directory Domain Services (AD DS).  Think about how many years it has it been fine tuned with integration with third party solutions such as:

• Remote access via RADIUS servers
• Two factor authentication
• Single sign on into applications
• Synchronization of user accounts and groups into hosted web services for web filtering
• Integration with software that provides corporate wide email signatures
• Integration with software that provides automated provisioning and de-provisioning of users

The list does truly go on and on.  Most organisations will treat their on-premises Active Directory Domain Services (AD DS) as the one source of all truth for users, groups, permissions and passwords.

So that’s the on-premises bit, what’s this Azure Active Directory all about?

What is Azure Active Directory

According to Microsoft Azure ‘What is Azure Active Directory‘ homepage it is Microsoft’s multi-tenant cloud based directory and identity management service.  Great you say but what does that really mean?

The key is in the multi-tenant part, its a directory service built for Microsoft. It isn’t architected in the same way as AD DS, most of us are used to the terms Kerberos, NLTM and LDAP, well these aren’t available in Azure AD.  Instead Azure AD uses web centric language such as SAML 2.0, WS-Federation and OAuth2.0  More details on Azure AD Authentication Protocols can be found here.

For those among us who like facts and figures Azure AD Basic and Premium has an SLA of 99.95% and operates out of twenty eight of Microsoft datacentres.   With the object and metadata being held across two or more locations.

Noticeably Azure AD, doesn’t provide the same features set that we are used to with AD DS, for example group policy isn’t available.  Azure AD Join is out for Windows 10 devices which provides some enrollment and integration features into areas such as email, but again it doesn’t provide the rich feature set you would expect from your on-premises AD DS.

Microsoft are adding features continuously to Azure AD, so I’m sure things will progress and update in the near future.  This then leaves us with three choices when it comes to accessing cloud based solutions:

• Separate
• Synchronized
• Federated

Separate

This is where you have a separate identify and access for your on-premises AD DS and Azure AD.

A user ‘John Smith’ has to manage his credentials for both on-premises access to applications via AD DS and different set of credentials for access to applications in Azure AD.

Synchronized

These are identities that exist on-premises in AD DS and in Azure AD.  Typically Azure AD Connect would be used to manage the password synchronization using hashing algorithms.  It uses a SQL Server database to store identity data, with the Express version enabling you to manage 100,000 objects.

Using AD Connect you will gain the on-premises password will authenticate both AD DS and Azure AD. Users will have single sign-on for an extensive set of pre-integrated SaaS applications.  At the moment 2,577 applications are pre-configured for Azure AD integration.

Federated

Federated enables your on-premises AD DS to be the source of authentication into Azure AD and other cloud based resources or partner organizations.  Essentially it supports advanced scenarios that cannot be achieved using the synchronized deployment method for example your security policy prohibits password hashes being synchronized to the cloud.

It should be noted that it is higher maintenance, requires additional servers and extensive setup and redundancy to ensure users can authenticate.

Azure AD Free, Basic and Premium

Just to make things slightly more complicated, Microsoft have three versions of Azure AD, these are Free, Basic and Premium.

• Free – This is the entry level option that doesn’t provide an SLA or company branding.  It does however give you the following:
  • Up to 500,000 objects
  • You have access to SSO applications using the 2,577 Azure AD pre-integrated SaaS applications
  • Ability to extend on-premises AD DS into Azure AD
  • Self Service Password Changes for Azure AD users

• Basic – This is the first paid for option which extends the free features by including:
  • No object limit
  • 99.9% SLA
  • Company branding for login pages and access panel
  • Self Service Password Resets for Azure AD users

• Premium – This is the top option, which extends the Basic features by including:
  • Self service group management
  • Self Service Password Resets with on-premises writeback
  • Multi-Factor Authentication
  • Self service Bitlocker recovery

Final Thoughts

Azure AD is a web scale directory that provides SSO and integration with SaaS and on-premises directory structures and applications.  It is maturing all time with the inclusion of new features on a regular basis.

In the next article I will look at Availability Set concepts, see you in the next installment.

I seem to be spending more and more of my time on Microsoft Azure, so thought it would be a good idea to start a blog series on Azure Concepts to provide an overview of the following:

• Identity and Access
• Availability Sets and Patching
• Storage
• Virtual Machines
• Network Connectivity
• Hybrid Cloud
• Disaster Recovery

What is Microsoft Azure?

So the first question is what is Microsoft Azure?  The best explanation that I could find is from Wikipedia

“Microsoft Azure is a cloud computing platform and infrastructure, created by Microsoft, for building, deploying and managing applications and services through a global network of Microsoft-managed and Microsoft partner hosted datacenters. It provides both PaaS and IaaS services and supports many different programming languages, tools and frameworks, including both Microsoft-specific and third-party software and systems”

For me, the part which is missing from the above statement is “providing resources on demand on a pay as you go basis”.

Scale

To give you an idea of the current scale of Microsoft Azure, I thought it would be fun to share a few facts:

• Microsoft Azure operates in 21 different regions
• Microsoft Azure recieves over 90,000 new customers a month
• 1.4 Million SQL Databases are held in Microsoft Azure
• More than 50 Trillion storage objects in Microsoft Azure
• Over 425 Million Azure Active Directory users
• 3,200 Azure Marketplace applications are available

Trying to keep up to date in all things Microsoft Azure is a full time job.   To make things slightly easier Microsoft offer a Cloud Platform Roadmap which enables you to see the upcoming applications, services and infrastructure items.

Final Thought

Microsoft Azure is complicated, you often have a number of ways to achieve the same end results. Hopefully this upcoming series of blog posts will provide you with the concepts that underpin Microsoft’s cloud service offering.