Azure Stack is one of the most misunderstood products (apart from Zune perhaps) that Microsoft has released. It’s not even a year old yet (released September 2017) and it’s a “hybrid cloud appliance”. In these two articles we’re going to show what those terms mean, what you could use Azure Stack for and what you should definitely NOT use it for and how it might fit into your company’s IT strategy.

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

What Azure Stack is ^

Microsoft has had a few cracks at a “cloud that you can run in your datacenter”; there’s the free Azure Pack which runs on your own hardware, on top of Hyper-V and System Center. Pack gave you the “old” Azure interface (Azure Service Manager, ASM) and the ability to run VMs, websites and databases in a self-service manner. But Pack had a lot of layers and wasn’t the most stable product. Then there’s Windows Server Software Defined (WSSD), ready made clusters from several hardware vendors, again marrying Hyper-V and System Center but not really providing cloud compatibility.

Microsoft Azure Stack (MAS) is different, whilst building on the strengths of the previous efforts. You buy an integrated system from select vendors: Avanade, Cisco, Dell EMC, HPE, Huawei, Terra or Lenovo, recently availability expanded to 92 countries.

They’re all four to twelve nodes but the specifications vary, node memory is between 256 and 768 GB, CPUs come with 12-24 cores (two CPUs per host). Those CPUs now include the recent Xeon Scalable processors. Storage is a mix of SSD cache (6-12 TB) and HDD (40-100 TB) for most SKUs but there are models with NVMe (SSD connected straight to the PCI Express bus) for cache and also all flash configurations.

MAS Administrator Portal (Image Credit Microsoft)

MAS Administrator Portal (Image Credit Microsoft)

The storage layer uses Storage Spaces Direct (S2D) which pools the storage in each node (HDD, SSD, NVMe) together for resilient, tiered and performant data storage. While S2D has different options for resiliency, all Azure Stack deployments use three-way mirroring and the Resilient File System (ReFS) exclusively. Interconnecting the nodes is RDMA networking, at least 10 Gb/s, in some SKUs 40 Gb/s which carries all the storage as well as VM traffic.

On top of the physical network runs the logical Software Defined Networking (SDN) layer based on the same code used in Azure (and in Windows Server 2016). There’s a Network Controller (NC) that runs in a HA configuration across multiple VMs. The NC in turn manages all the Virtual Networks (vNets), the Software Load Balancer (SLB), the RAS Gateway and the Datacenter Firewall.

On top of this cluster of Windows Server 2016 Hyper-V hosts runs many Azure Infrastructure VMs (which you don’t have direct access to), sharing the platform with tenant VMs (in separate vNets). There is a separate AD forest for Azure Stack which you use to control access through Role Based Access Control (RBAC).

There’s a generic calculator to help you gauge what size Azure Stack system you need, you can calculate either based on VM footprint or workload footprint. Your favorite vendor may also provide you with a custom calculator for their specific SKUs.

Note that the Azure IP Advantage patent defense portfolio extends to workloads you develop for / deploy on Azure Stack.

What Azure Stack isn’t ^

Azure Stack is a turnkey solution where you have no direct access to the underlying nodes. Yes, you read that right, you can’t install your own security / backup or anti-malware agents on the physical hosts (because you can’t in Azure), just like you can’t on the SANs in your datacenter.

There’s agentless monitoring with Nagios or SCOM however and the platform itself provides a fair amount of monitoring. The reason you can’t install agents on the hosts (and don’t have direct access to them) is simple – the whole point of MAS is consistency with Azure – meaning that you have to update every month to keep up with public Azure. If you had an agent on there that wasn’t compatible with the latest version of Azure this would block the upgrade.

And while it’s running Windows Server 2016 Hyper-V, don’t think of MAS as a way to migrate your existing fleet of VMs to new hardware. If all you want to do is run a bunch of VMs, Azure Stack is not the best solution for your business. Because Azure consistency is a cornerstone of MAS, many features of Hyper-V that aren’t available in public Azure such as Generation 2 VMs, VHDX support and Live Migration also aren’t available in Azure Stack.

You also have limited access to the AD forest in Azure Stack, through a privileged Just Enough Administration (JEA) PowerShell endpoint. If you have a real emergency you can contact Microsoft’s support and if necessary they’ll provide you with a token, enabling some high-level cmdlets for management. Speaking of security one of the benefits you get from a pre-validated appliance like MAS is incredible security, with all drives encrypted with BitLocker, all servers protected with Secure Boot (TPM 2.0) and Credential Guard, as well as Device Guard for software whitelisting.

Creating an offer in MAS (Image Credit Microsoft)

Creating an offer in MAS (Image Credit Microsoft)

Azure Stack also isn’t something that you set up once and then ignore, there’s an update every month and you must update at least every three months to continue being supported. These updates not only contain security and bug fixes but also new functionality, in an effort to keep MAS up to date with public Azure.

Recent updates have brought updates to block blobs (max size from 195 GB to 4.75 TB), RBAC support for Universal Groups when using AD FS and support for adding memory to the nodes (1802). The 1802 update also brought Availability Sets (AS), which (just like in Azure) spreads VMs in an AS across fault domains.

In 1803 we got sparse file support for reduced disk usage and improved IO performance, whereas 1804 brought Av2 and F series VMs, along with Visual Studio support for disconnected MAS deployment. Finally, 1805 brought a preview Syslog client, sending audit and security logs from MAS to a Syslog server. Earlier updates brought Functions and App Service.

What’s not quite here yet but coming is IoT Hub for MAS, support for connecting VSTS Release Management to MAS as well as Team Foundation Server (TFS). There are also previews of templatized deployments of Service Fabric and Kubernetes clusters. Pivotal Cloud Foundry 2.2 has been released for MAS, showing that the third-party ecosystem is growing.

In part 2 we’ll dive into how you connect MAS to the rest of your datacenter (both for networking and identity management), which use cases MAS is ideal for and the role of the free Azure Stack Development Kit (ASDK).

Are you an IT pro? Apply for membership!

Your question was not answered? Ask in the forum!

7+

Users who have LIKED this post:

  • avatar
  • avatar
  • avatar
  • avatar
Share
2 Comments
  1. This website helped to clear my misconception about the Azure stack. I thank the author to clarify the doubt of readers through his wonderful article.

    1+

  2. […] the first half of this look at Microsoft’s Azure Stack (MAS), we looked at what MAS is, how you size it for your datacenter, the underlying technologies, the […]

    1+

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account