When starting out with Azure Stack HCI with SDN, it’s easy to feel like you need to rush to get up to speed. However, moving too quickly can cause you to miss the bigger picture. This is exactly what happened to me when I began my journey, and I don’t want others to make the same mistake.
So what is Azure Stack HCI? Azure Stack HCI is an operating system designed specifically for hyperconverged infrastructure, it is consumed from Azure on a consumption basis and has deep integration in to Azure. With Azure Stack HCI you can view all of your infrastructure clusters and Virtual Machines in the Azure portal alongside your other Azure resources giving you centralized visibility for all of your Azure workloads and allowing you to manage govern and secure them in a consistent way. Azure Stack HCI allows you to take advantage of Azure services in your datacenter or at the edge for workloads which can’t be moved or don’t make sense to move to Azure.
So, what is Azure Stack SDN? Software defined networking (SDN) provides a way to centrally configure and manage networks and network services such as switching, routing, and load balancing in your data center. You can use SDN to dynamically create, secure, and connect your network to meet the evolving needs of your apps. Operating global-scale datacenter networks for services like Microsoft Azure, which efficiently performs tens of thousands of network changes every day, is possible only because of SDN.
Feel free to check in on this series:
Special thanks to Lisa Clark and her time to collaborate.
Things to note about Azure Stack HCI/SDN:
- You can have a minimum of one (1) and up to sixteen (16) nodes in a single Azure Stack HCI cluster
- You can run multiple Azure stack HCI clusters in a datacenter
- Azure Stack HCI has Hyper-V as the hypervisor
- Azure Stack HCI has Storage Spaces Direct (S2D) as the underlying storage
- You can only have one (1) Network Controller Cluster environment per Azure stack HCI cluster
- Cannot stretch a NSG from the cloud to onprem
- Need third party for L7 firewall or IDS/IPs
- Lacks federation capability of stretching the same vNET across sites
*I’m sure in the coming months these numbers are scheduled to change.
Use cases:
Software Defined networking
- Dynamically deliver new networks
- Ensure tenant isolation and security
- Increase workload mobility
- Centralized Mgmt. of your virtual networks
- Network Controller (VNETs & Subnets, Connect VMs to subnets, Micro-segmentation, Network Policies, Attach Virtual Appliances & QoS)
- Software Load Balancing for both forward and internal load balancing requirements
- Varity of Gateway connectivity options (Site-to-site IPSec, GRE & Layer 3 connections)
Transformative Datacenter Projects
- Proven Azure Framework for Landing Zones
- Performance boosts and cost optimization in a multi-cluster topology
- Proven DR and HA leveraging solutions like ASR or Application replication
Azure Kubernetes Service (AKS) onprem controlled by from the Cloud
- Manage and Configure Kubernetes clusters running anywhere from Azure
- Azure consistent deployment and operation experience
- Azure Arc enabled Services for cloud native rollouts – AKS, SQL MI
- Leverage Azure for global load balancing, deployments and observability
- IAC to rollout new clusters and landing zone
Summary:
Today, the possibilities of Azure Stack HCI with SDN are incredible.
It is fair to say Azure Stack HCI does not have all the same capabilities and features as VMware but it is a viable alternative for the majority of my customers.
Once we get past the feature vs feature comparison, many customers just want to know whether Azure Stack HCI can meet their requirements.
With the above considerations, a lot of customers have some a presence in Azure already which is an advantage. Azure Stack HCI truly benefits customers who use Azure, who have workloads which can’t run in Azure but who want consistency across their environments.
*The thoughts and opinions in this article are mine and hold no reflect on my employer*
