Azure Stack Ignite Notes

As I noted in yesterday’s post, I have been intrigued by Microsoft’s approach to Azure Stack. I took a lot of notes during sessions and conversations at Ignite and so I decided to list them out in a new post. For those that are unfamiliar with Azure Stack, then I would suggest this whitepaper as a starting point. 

In a nutshell, Azure Stack is Microsoft’s hyper-converged integrated system for flexible service delivery using Azure based management and automation. It’s Microsoft’s cloud in a box using Azure’s framework to ultimately Keep a consistent experience. Keep in mind this product is not GA yet, so anything I state below may or may not come to fruition. 

Availability: 
Microsoft at Ignite 2016, announced the 2nd technical preview of Azure Stack, with general availability expected in the second half of 2017. I also heard an expectation of TP3 during the 1st quarter of 2017. 
Currently Azure Stack offers IaaS but later this month Microsoft plans to release an update where Microsoft’s PaaS “App Service Resource Provider” will be available on Azure Stack TP2. 
 

Architecture: 
•    Built on top of Server 2016 Server Core, (Nano Server will be supported in the future) However, TP2 is currently using Server 2012 R2 Server Core. 
•    Hyper-Converged Deployment model with a pair of ToR switches and a BMC switch to manage the server integrated stack. 
•    Hyper-V is sealed under Azure Stack, only access to Hyper-V is from API. 
•    Windows Server Failover Clustering is used along with Storage Spaces Direct. 
•    Minimum Resource Req.: Dual Socket, 8 cores per socket. 256GB memory. 
•    RDMA will be supported - converged NIC: SDN + Storage, or use two 10Gb nics, with switch-embedded teaming for port link residency.  
•    Storage Protocol Support: CSVRFS with ReFS, SMB3, SMB Direct, SATA, SAS, NVMe
•    Multi-Resilient Volume: writes are mirrored for performance then as the data gets cold it will then write a large chunk to parity for a balanced approach of performance and capacity. 

Caching Capabilities:
•    All writes up to 256kb are cached. 
•    Reads of 64kb or less are cached on first miss. 
•    Reads of 64kb + are cached on second miss.  
•    Writes are de-staged to HDD in a optimal order. 
•    Sequential reads of 32 + KB are not cached. 
•    In an All Flash System, only Writes are cached
•    Min. req.: 2 cache devices with Min. req.: 4 capacity devices  
 

Integrated Stack:
I heard a lot of people say that they didn’t like the direction of an integrated system requirement for Azure Stack. The belief is that it will lock them into a hardware vendor that may not provide enough flexibility or choice. I attended a few sessions where Microsoft heard this feedback loud and clear, and so it was stated that the current plan is to continue and partner with Dell, HPE, Lenovo to provide the hardware for a complete certified Azure Stack integrated system. It’s after this, where Microsoft hopes additional testing and assurance can be made on a defined HCL, Microsoft hopes to offer Azure Stack as a production ready software solution for a wider array of hardware platforms. I personally had hoped for a software only solution, but I do see why an integrated system will allow Microsoft to control the experience and deliver on the expected promises. I just hope that the integrated system is not priced out of reach of most customers, as we have seen similar examples of this in the past! 

An Integrated System is part of what Microsoft calls a Scale Unit. Each Scale unit must include homogenous hardware; however separate scale units can be heterogeneous hardware. Each scale unit must include at least 4 Azure Stack nodes, with one node dedicated for patch and updates. Each scale unit must also include the items in this list. 

•    A pair of ToR Switches for availability and internal networking. 
•    One BMC switch for hardware management
•    An Aggregate switch for external connections

Each scale unit is part of one region, (same physical location), multiple scale units can be part of the same region as well and so are part of the same fault domain. 

The cool part is that you can designate your Azure Stack deployment as a region and in the future this could become part of Azure when deploying new workloads with the option of not only designating Azure regions but your own on-premises Azure Stack regions. 

One surprise that I found was that the Azure Stack software framework is actually run in virtual machines on top of Hyper-V.  I guess this surprised me because I thought that Azure Stack would have been developed as an application with native hooks into the server operating system. I can certainly understand why they chose this path, but it also makes me wonder about performance in this type of design. This of course can be easily rectified by an optimization product like from DataCore software! :) 

Currently authentication is joined through Azure, but plans to support Facebook, Twitter, MS Account, & AD will be supported for authentication and authorization on Azure Stack. 

If and when you use Azure Stack App Service you will have the ability to deploy new internal assemblies, like Go, Ruby, Java and even components like Oracle Clients. These are types of things that Azure Stack will have that the Azure public app service won't have support for. 

As you can see there is a lot going on here, but I'm only touching the surface. I hope to provide more interesting notes about the Azure Stack Architecture as I have more time to play with TP2.