Posts by Darryl

Azure Stack HCI with Kubernetes

The game of abstraction of infrastructure is going fast. If you don’t keep up, you could end up in a world where people point their finger at and whisper “legacy”. 

Looking back a decade, hardware evolved quick and virtualization technologies came to the rescue, allowing higher densities of workloads on one or multiple physical servers in the form of virtual machines. Applications ran in those VMs would benefit from high availability, so if a physical server fails another server takes over the virtual machine. The hypervisor technology creates hardware abstraction. However, the virtual machine is still bound to the underlying hypervisor and most probably to the hardware the hypervisor is using. This would mean that you can move virtual machines between the same type of hypervisor and hardware, but for example moving a VMware VM to Hyper-V is not possible without conversion. The same goes for moving to or between public cloud providers, no technical challenge there but the portability is not good enough. In other words, moving from and to another platform is not a one-click action. 

Containers

Being tied to a specific platform of choice is not very convenient but was accepted for many years. Applications would run in virtual machines and those virtual machines would be on a hypervisor platform. 

Containers form the new wave of innovation and modernization of applications. Containers run in virtual machines which are called ‘container host s’. While running in virtual machines, the platform creates abstraction of the underlying infrastructure (the hypervisor). 

This would mean that you can a run one container host on Hyper-V and another on VMware and deploy the same container to it. Using containers, organizations are not tied to specific platforms but can be platform agnostic.  

Management of containers is a different ball game comparing to management of virtual machines. A virtual machine would typically run one application and the VM would exist as long as the application did. In the container landscape, an application can consists out of multiple containers that are created when needed and destroyed when not used. This requires a different type of toolset and Kubernetes is the swiss knife that has all the tools build-in. 

Kubernetes 

Kubernetes is a container orchestrator platform, but it has a lot more capabilities. Seeking agnostic infrastructure, you can use Kubernetes to abstract the infrastructure away from your applications. The container hosts mentioned above are included within Kubernetes and become ‘worker nodes’ where containers are deployed. Kubernetes now orchestrates your container landscape, it notices if more containers are needed or when containers can be removed because of inactivity. Because the Kubernetes nodes can run anywhere you’d like, and Kubernetes manages where containers are deployed, your application is now highly portable and abstracted from any platform.  
  
Kubernetes itself also needs to run somewhere and is also distributed in multiple virtual machines, which is referred to as a ‘Kubernetes Management Cluster’.  

In part 2 of this blog series we’ll go in full detail how Kubernetes works. 

Kubernetes cluster in the cloud

The major cloud providers were not ignoring the container era, thus are providing customers Kubernetes clusters as a service. They are called Amazon’s Elastic Kubernetes Service (EKS), Microsoft’s Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). The Kubernetes cluster is abstracted as well in a PaaS service by the cloud providers, but you could run it anywhere you’d like. Same for the worker nodes, you could make use of AKS and run your Kubernetes worker nodes in AWS, Google cloud, and Azure Stack HCI simultaneously. Now.. that’s a true hybrid cloud. 
 
In this blog series we’re explicating the relationship between ‘traditional’ infrastructure, modern Hyper-converged infrastructure and Kubernetes. From an IT-Pro point-of-view. 

Read Azure Stack HCI with Kubernetes - part 2 here!

Azure Stack HCI details

Microsoft has announced a successor of the current Azure Stack HCI. The current solution is based on Windows Server 2019 using Hyper-V and Storage Spaces Direct. The new Azure Stack HCI solution is based on a new operating system originating from Windows Server 2019, called Azure Stack HCI. 

On our dedicated Azure Stack HCI page, we have explained what the solution is all about. In this blog, we’re diving a little deeper in the details.

Azure Stack HCI Operating System 

Azure Stack HCI is not only the name of the solution, but also the name of the Operating System. That means that Azure Stack HCI OS is breaking loose from Windows Server, and the (slow paced) release cadence. The Azure Stack HCI OS will be updates much more frequently like the SAC releases providing new features or improvements at a faster rate. 


 
As Azure Stack HCI is released before the upcoming version of Windows Server, we also get the announced enhancements sooner as expected. Such as;  

Full stack automatic updates

Firmware and drives updated through integration with Windows Admin Center. Automatic, no manual intervention needed.
See this screenshot from EMC Dell for the visuals, or take a look at their 7-min video here.




Storage rebuilds 75% faster


Azure Stack HCI includes a completely renewed Storage Spaces Direct repair mechanism! The cluster now tracks the changes in the data at a much finer granularity. This improves rebuild times up to 75%, narrowing maintenance windows further. 

 
Stretched clusters


Azure Stack HCI also provides us with the Stretched Clustering feature, build on top of Storage Replica. Using this new feature, we can span an Azure Stack HCI cluster over multiple sites providing business continuity and disaster recovery (BCDR) capabilities. 
 
 
 
Azure Stack HCI supports synchronous and A-synchronous replication. 

 
Affinity and Anti-Affinity


With the release of Azure Stack HCI there is a new feature included called ‘VM Affinity and Anti Affinity’.  

Affinity

With Affinity rules you can achieve binding of two or more resources together. For example, you want your front-end webservers and back-end databases servers on the same physical location to avoid latency and increase performance. 


Anti-Affinity

With Anti-Affinity, we achieve the exact opposite. 
If we want to distribute front-end webservers over multiple physical locations (fault domains) we can use Anti-Affinity rules. 
When one physical location is offline due to maintenance or unexpected failure, you make sure your application stays online. 
  

Windows Admin Center

With the release of Azure Stack HCI Microsoft also heavily invested again in Windows Admin Center. Windows Admin Center now includes cluster create options and with that several workflows to created different types of clusters like HCI, HCI+SDN and more.  
 
 
 
With these workflows we can setup the cluster completely using Windows Admin Center. Automation in the background makes sure the asked components are installed according to best-practices. 


Stripped down OS

Because Azure Stack HCI is intended for HCI clusters only, the OS it will be stripped down from unnecessary features. Meaning, many features that are currently part of the Window Server OS will not be available in the Azure Stack HCI OS… 
 
Current features and roles in Windows Server 2019: 268 
Current features and roles in Azure Stack HCI: 193 
 
For example, the Active Directory and related roles such as DNS, Certificate Services, Federation Services, DHCP and Print Services will not be included, and more features might follow.  
 
These features will still be available in the regular Window Server releases, just not in Azure Stack HCI.  
 

Azure Stack HCI Billing

Since Azure Stack HCI is a cloud solution, the billing model will change to a cloud billing model.

Traditional Windows Server licensing

With Windows Server there always has been a licensing model calculated per physical processor core. Depending on the number of physical processor cores in your server, a number of core-packs must be purchased.
  

Azure Stack HCI licensing

With Azure Stack HCI you are also licensed per physical processor core. The difference with Windows Server licensing is that there is no concept of core-packs, you pay for the amount of physical processor cores in your cluster.

With this model the licensing costs switches from a CAPEX to an OPEX model.
When Azure Stack HCI is down or up-scaled the day-to-day expenses change.

Because the billing is managed through Microsoft Azure we can leverage the tools available to get more insights on costs. For example, with Azure Cost Analyses we can query the information and provide forecasts. In addition, the Azure APIs can be used with third party tooling for cost management.


Guest operating systems not included

One important aspect to note is that guest operating systems are not included in the license, like with Windows Server 2019 Datacenter edition.
This means that you will need to license VMs running on the Azure Stack HCI solution.

Azure Connection required once per month

Because the billing runs through Microsoft Azure, the cluster must be registered to Microsoft Azure within 30 days after deployment. After registration the cluster needs to connect to Microsoft Azure once every 30 days to report cluster status. If the cluster is unable to report the cluster will be out of policy.

 

Support via Azure support tickets

As cloud solution, the support of Azure Stack HCI falls under the umbrella of Microsoft Azure support. That means that you could request support by going to portal.azure.com and file a support request there for your Azure Stack HCI solution.

 

Azure Stack HCI resource provider

Microsoft has created a dedicated resource type in Azure Resource Manager for Azure Stack HCI clusters.

By registering Azure Stack HCI clusters to the resource provider in Microsoft Azure an Azure Resource is created that represents the cluster.

 

Self-service VMs through Azure Portal

Want to offer your users a consistent experience with Azure? You now can.
Azure Stack HCI makes use of the same toolset as Microsoft Azure, including the portal and ARM templates. Using Azure Resource Manager (ARM) you can also delegate access to users in your Azure AD.



Contact Splitbrain for more information

Unsure how the new Azure Stack HCI fits in your organization? Or what is going to happen to your existing Azure Stack HCI clusters based on Windows Server 2019?

Contact us, we’re happy to help you.

    Terms and Conditions