In this article by Markus Klein and Susan Roesner, authors of the book Azure Stack for Datacenters, we will help you to plan, build, run, and develop your own Azure-based datacenter running Azure Stack technology. The goal is that the technology in your datacenter will be a 100 percent consistent using Azure, which provides flexibility and elasticity to your IT infrastructure.
We will learn about:
- Cloud basics
- The Microsoft Azure Stack
- Core management services
- Using Azure Stack
- Migrating services to Azure Stack
(For more resources related to this topic, see here.)
Cloud as the new IT infrastructure
Regarding the technical requirements of today’s IT, the cloud is always a part of the general IT strategy. It does not depend upon the region in which the company is working in, nor does it depend upon the part of the economy—99.9 percent of all companies have cloud technology already in their environment.
The good question for a lot of CIOs is general: “To what extent do we allow cloud services, and what does that mean to our infrastructure?” So it’s a matter of compliance, allowance, and willingness.
The top 10most important questions for a CIO to prepare for the cloud are as follows:
- Are we allowed to save our data in the cloud?
- What classification of data can be saved in the cloud?
- How flexible are we regarding the cloud?
- Do we have the knowledge to work with cloud technology?
- How does our current IT setup and infrastructure fit into the cloud’s requirements?
- Is our current infrastructure already prepared for the cloud?
- Are we already working with a cloud-ready infrastructure?
- Is our Internet bandwidth good enough?
- What does the cloud mean to my employees?
- Which technology should we choose?
The definition of the term “cloud” is not simple, but we need to differentiate between the following:
- Private cloud: This is a highly dynamic IT infrastructure based on virtualization technology that is flexible and scalable. The resources are saved in a privately owned datacenter either in your company or a service provider of your choice.
- Public cloud: This is a shared offering of IT infrastructure services that are provided via the Internet.
- Hybrid cloud: This is a mixture of a private and public cloud. Depending on compliance or other security regulations, the services that could be run in a public datacenter are already deployed there, but the services that need to be stored inside the company are running there. The goal is to run these services on the same technology to provide the agility, flexibility, and scalability to move services between public and private datacenters.
In general, there are some big players within the cloud market (for example, Amazon Web Services, Google, Azure, and even Alibaba). If a company is quite Microsoft-minded from the infrastructure point of view, they should have a look at Microsoft Azure datacenters. Microsoft started in 2008 with their first datacenter, and today, they invest a billion dollars every month in Azure.
As of today, there are about 34 official datacenters around the world that form Microsoft Azure, besides some that Microsoft does not talk about (for example, USGovernment Azure). There are some dedicated datacenters, such as the German Azure cloud, that do not have connectivity to Azure worldwide. Due to compliance requirements, these frontiers need to exist, but the technology of each Azure datacenter is the same although the services offered may vary.
The following map gives an overview of the locations (so-called regions) in Azure as of today and provide an idea of which ones will be coming soon:
The Microsoft cloud story
When Microsoft started their public cloud, they decided that there must be a private cloud stack too, especially, to prepare their infrastructure to run in Azure sometime in the future.
The first private cloud solution was the System Center suite, with System Center Orchestrator and Service Provider Foundation (SPF) and Service Manager as the self-service portal solution. Later on, Microsoft launched Windows Azure Pack for Windows Server. Today, Windows Azure Pack is available as a product focused on the private cloud and provides a self-service portal (the well-known old Azure Portal, code name red dog frontend), and it uses the System Center suite as its underlying technology:
Microsoft Azure Stack
In May2015, Microsoft formally announced a new solution that brings Azure to your datacenter. This solution was named Microsoft Azure Stack. To put it in one sentence: Azure Stack is the same technology with the same APIs and portal as Public Azure, but you could run it in your datacenter or in that of your service provider. With Azure Stack, System Center is completely gone because everything is the way it is in Azure now, and in Azure, there is no System Center at all. This is what the primary focus of this article is.
The following diagram gives a current overview of the technical design of Azure Stack compared with Azure:
The one and only difference between Azure Stack and Azure is the cloud infrastructure. In Azure, there are thousands of servers that are part of the solution; with Azure Stack, the number is slightly smaller. That’s why there is the cloud-inspired infrastructure based on Windows Server, Hyper-V, and Azure technologies as the underlying technology stack. There is no System Center product in this stack anymore. This does not mean that it cannot be there (for example, SCOM for on-premise monitoring), but Azure Stack itself provides all functionality with the solution itself.
For stability and functionality, Microsoft decided to provide Azure Stack as a so-called integrated system, so it will come to your door with the hardware stack included. The customer buys Azure Stack as a complete technology stack. At general availability(GA), the hardware OEMs are HPE, DellEMC, and Lenovo. In addition to this, there will be a one-host PoC deployment available for download that could be run as a proof of concept solution on every type of hardware, as soon as it meets the hardware requirements.
Looking at the technical design a bit more in depth, there are some components that we need to dive deeper into:
The general basis of Azure Stack is Windows Server 2016 technology, which builds the cloud-inspired infrastructure:
- Storage Spaces Direct (S2D)
- Nano Server
- Azure Resource Manager (ARM)
Storage Spaces Direct (S2D)
Storage Spaces and Scale-Out File Server were technologies that came with Windows Server 2012. The lack of stability in the initial versions and the issues with the underlying hardware was a bad phase. The general concept was a shared storage setup using JBODs controlled from Windows Server 2012 Storage Spaces servers and a magic Scale-Out File Server cluster that acted as the single point of contact for storage:
With Windows Server 2016, the design is quite different and the concept relies on a shared-nothing model, even with local attached storage:
This is the storage design Azure Stack is coming up with as one of its main pillars.
With Windows Server 2012, Microsoft introduced Software-Defined Networking(SDN)and the NVGRE technology. Hyper-V Network Virtualization supports Network Virtualization using Generic Routing Encapsulation (NVGRE) as the mechanism to virtualize IP addresses. In NVGRE, the virtual machine’s packet is encapsulated inside another packet:
Hyper-V Network Virtualization supports NVGRE as the mechanism to virtualize IP addresses. In NVGRE, the virtual machine’s packet is encapsulated inside another packet.
VXLAN comes as the new SDNv2protocol, is RFC compliant, and is supported by most network hardware vendors by default. The Virtual eXtensible Local Area Network (VXLAN) RFC 7348 protocol has been widely adopted in the marketplace, with support from vendors such as Cisco, Brocade, Arista, Dell, and HP. The VXLAN protocol uses UDP as the transport:
Nano Server offers a minimal-footprint headless version of Windows Server 2016. It completely excludes the graphical user interface, which means that it is quite small, headless, and easy to handle regarding updates and security fixes, but it doesn’t provide the GUI expected by customers of Windows Server.
Azure Resource Manager (ARM)
The “magical” Azure Resource Manager is a 1-1 bit share with ARM from Azure, so it has the same update frequency and features that are available in Azure, too.
ARM is a consistent management layer that saves resources, dependencies, inputs, and outputs as an idempotent deployment as a JSON file called an ARM template. This template defines the tastes of a deployment, whether it be VMs, databases, websites, or anything else. The goal is that once a template is designed, it can be run on each Azure-based cloud platform, including Azure Stack. ARM provides cloud consistency with the finest granularity, and the only difference between the clouds is the region the template is being deployed to and the corresponding REST endpoints.
ARM not only provides a template for a logical combination of resources within Azure, it manages subscriptions and role-based access control(RBAC) and defines the gallery, metric, and usage data, too. This means quite simply that everything that needs to be done with Azure resources should be done with ARM.
Not only does Azure Resource Manager design one virtual machine, it is responsible for setting up one to a bunch of resources that fit together for a specific service. Even ARM templates can be nested; this means they can depend on each other.
When working with ARM, you should know the following vocabulary:
- Resource: Are source is a manageable item available in Azure
- Resource group: A resource group is the container of resources that fit together within a service
- Resource provider: A resource provider is a service that can be consumed within Azure
- Resource manager template: A resource manager template is the definition of a specific service
Declarative syntax: Declarative syntax means that the template does not define the way to set up a resource; it just defines how the result and the resource itself has the feature to set up and configure itself to fulfill the syntax to create your own ARM templates, you need to fulfill the following minimum requirements:
- A test editor of your choice
- Visual Studio Community Edition
- Azure SDK
Visual Studio Community Edition is available for free from the Internet. After setting these things up, you could start it and define your own templates:
Setting up a simple blank template looks like this:
There are different ways to get a template so that you can work on and modify it to fit your needs:
- Visual Studio templates
- Quick-start templates on GitHub
- Azure ARM templates
You could export the ARM template directly from Azure Portal if the resource has been deployed:
After clicking on View template, the following opens up:
For further reading on ARM basics, the Getting started with Azure Resource Managerdocument is a good place to begin:
PowerShell Desired State Configuration
We talked about ARM and ARM templates that define resources, but they are unable to design the waya VM looks inside, specify which software needs to be installed, and how the deployment should be done. This is why we need to have a look at VMextensions.VMextensions define what should be done after ARM deployment has finished. In general, the extension could be anything that’s a script. The best practice is to use PowerShell and its add-on called Desired State Configuration (DSC).
DSC defines—quite similarly to ARM—how the software needs to be installed and configured. The great concept is that it also monitors whether the desired state of a virtual machine is changing (for example, because an administrator uninstalls or reconfigures a machine). If it does, it makes sure within minutes whether the original state will be fulfilled again and rolls back the actions to the desired state:
Migrating services to Azure Stack
If you are running virtual machines today, you’re already using a cloud-based technology, although we do not call it cloud today. Basically, this is the idea of a private cloud. If you are running Azure Pack today, you are quite near Azure Stack from the processes point of view but not the technology part. There is a solution called connectors for Azure Pack that lets you have one portal UI for both cloud solutions. This means that the customer can manage everything out of the Azure Stack Portal, although services run in Azure Pack as a legacy solution.
Basically, there is no real migration path within Azure Stack. But the way to solve this is quite easy, because you could use every tool that you can use to migrate services to Azure.
Azure website migration assistant
The Azure website migration assistant will provide a high-level readiness assessment for existing websites. This report outlines sites that are ready to move and elements that may need changes, and it highlights unsupported features. If everything is prepared properly, the tool creates any website and associated database automatically and synchronizes the content.
You can learn more about it at https://azure.microsoft.com/en-us/downloads/migration-assistant/:
For virtual machines, there are two tools available:
- Virtual Machines Readiness Assessment
- Virtual Machines Optimization Assessment
Virtual Machines Readiness Assessment
The Virtual Machines Readiness Assessment tool will automatically inspect your environment and provide you with a checklist and detailed report on steps for migrating the environment to the cloud.
The download location is https://azure.microsoft.com/en-us/downloads/vm-readiness-assessment/.
If you run the tool, you will get an output like this:
Virtual Machines Optimization Assessment
The Virtual Machine Optimization Assessment tool will at first start with a questionnaire and ask several questions about your deployment. Then, it will create an automated data collection and analysis of your Azure VMs. It generates a custom report with tenprioritized recommendations across six focus areas. These areas are security and compliance, performance and scalability, and availability and business continuity.
The download location ishttps://azure.microsoft.com/en-us/downloads/vm-optimization-assessment/.
Azure Stack provides a real Azure experience in your datacenter. The UI, administrative tools, and even third-party solutions should work properly. The design of Azure Stack is a very small instance of Azure with some technical design modifications, especially regarding the compute, storage, and network resource providers. These modifications give you a means to start small, think big, and deploy large when migrating services directly to public Azure sometime in the future, if needed.
The most important tool for planning, describing, defining, and deploying Azure Stack services is Azure Resource Manager, just like in Azure. This provides you a way to create your services just once but deploy them many times. From the business perspective, this means you have better TCO and lower administrative costs.
Resources for Article:
- Deploying and Synchronizing Azure Active Directory [article]
- What is Azure API Management? [article]
- Installing and Configuring Windows Azure Pack [article]