Enhancing Resilience with Azure Local Rack Aware Clustering: A Deep Dive into High-Availability On-Premises

    In the evolving world of hybrid cloud, Microsoft continues to bridge the gap between Azure's cloud-native capabilities and on-premises infrastructure. One of the standout recent additions is rack aware clustering in Azure Local (formerly building on Azure Stack HCI concepts). Currently available in preview (as of Azure Local 2510 and later), this feature lets you build highly resilient clusters that span physical racks—treating each as a local availability zone—without sacrificing the seamless Azure management experience.

What Is Rack Aware Clustering in Azure Local?

At its core, rack aware clustering distributes your Azure Local nodes across two physical racks (typically in separate rooms or buildings within the same site), connected via high-bandwidth, low-latency links using top-of-rack (ToR) switches.

Each rack operates as a local availability zone, extending awareness from the operating system layer all the way up to Azure Local management and Azure Arc-enabled VMs. This setup supports a single unified storage pool (powered by Storage Spaces Direct), with data replicas (mirrors) distributed evenly across both racks. If one rack goes down—due to power failure, fire, or hardware issues—the surviving rack maintains access to data and workloads, enabling automatic failover without data loss.

A key diagram from Microsoft illustrates this beautifully: two racks of servers linked by ToR switches between rooms, forming a fault-tolerant cluster with synchronous replication over a dedicated storage network.

Key Benefits

Rack aware clustering shines in scenarios demanding extreme uptime and rack-level fault tolerance:

• High Availability: Survive the complete loss of a rack while keeping applications running—no more single points of failure at the physical rack level.
• Even Data Distribution: Storage Spaces Direct ensures replicas are balanced across zones, reducing risk during failures and improving failover smoothness.
• Better Load Balancing & Performance: Distribute workloads (VMs, AKS clusters) across zones for optimized resource use and lower latency within the site.
• Azure-Native Management: Full integration with Azure Arc means you manage VMs, Kubernetes, monitoring, and more through the familiar Azure portal—consistent across hybrid environments.

This is especially valuable in regulated or mission-critical environments like manufacturing plants, hospitals, airports, or campuses where a single rack failure could disrupt operations.

Supported Configurations & Requirements

Rack aware clusters are designed for balanced, symmetric setups:

• Start with a 2+2 configuration (2 nodes per rack = 4 total) and scale to 3+3 (6 nodes) or 4+4 (8 nodes) by adding matched node pairs.
• Storage Resiliency: Uses two-way mirrors (for 2+2) or four-way mirrors (for larger), with storage efficiency at 50% or 25% respectively. Only all-flash NVMe/SSD data drives are supported—no external SANs.
• Networking Essentials: Round-trip latency between racks ≤ 1 ms (critical for synchronous RDMA-based replication). A dedicated storage network intent is required, with bandwidth scaling by cluster size (e.g., 40–200 GbE depending on NIC speed and node count).
• Witness: Typically uses a cloud witness (default), with options for local if needed.
• Deployment: Only for new Azure Local instances (no conversion from standard clusters). Deploy via the Azure portal or ARM templates. Post-deployment, verify machines are grouped by zone and test VM failover/live migration.

Unsupported in this release: External SANs, 3-way mirrors, adding nodes to 1+1 configs, or certain affinity rules via legacy tools.

For detailed network designs (options A–D with ToR redundancy, VLAN isolation, SDN support), check the reference architecture docs.

Use Cases & Real-World Value

Imagine a factory floor where regulatory compliance demands physical separation of critical systems—rack aware clustering delivers zone-like isolation without stretching across distant sites. Or in a hospital campus: place racks in different buildings to guard against localized disasters while keeping everything under one Azure-managed cluster.

It also pairs nicely with Azure Arc-enabled services: provision VMs into specific zones (strict or non-strict placement) for performance tuning, redundancy, or compliance, and run AKS clusters with nodes spread for better fault tolerance.

Wrapping Up: Is Rack Aware Clustering Right for You?

If you're running (or planning) Azure Local for edge, industrial, or on-premises workloads and need more than basic node-level HA, rack aware clustering is a game-changer. It evolves the old "stretched cluster" concepts into a more modern, Azure-integrated solution focused on local resilience.

The feature is in preview now, with a smooth upgrade path to GA expected in 2026—no redeployment required. If you're interested, start by reviewing the full overview on Microsoft Learn:

• Overview of Azure Local rack aware clustering
• Requirements & Supported Configurations
• Reference Architecture

Have you deployed Azure Local yet? Planning to try rack aware mode? Drop a comment—I'd love to hear your thoughts or experiences!

#Azure #AzureLocal #AzureArc #HighAvailability #OnPremisesCloud

Preparing Active Directory for Azure Local Deployment: A Step-by-Step Guide

 In the realm of hybrid cloud solutions, Azure Local brings the power of Azure to your on-premises environment. But before you dive into deployment, ensuring your Active Directory (AD) is properly configured is crucial. This setup optimizes performance, enhances security, and prevents common pitfalls like configuration drifts or permission issues. Drawing from Microsoft's official guidance, this blog post walks you through the essentials of prepping AD for Azure Local (version 23H2 and later). We'll cover prerequisites, key configurations, a detailed how-to, and tips to avoid headaches.

Overview: Why Prep Active Directory?

Active Directory serves as the backbone for authentication and management in Azure Local clusters. Proper preparation ensures seamless integration, from creating dedicated organizational units (OUs) to handling DNS and permissions. Without this, you might face slow queries in large directories, security vulnerabilities, or deployment failures. The goal is to create a controlled environment where Azure Local can manage its own security defaults while respecting your AD structure.

Key elements include scoping permissions to a dedicated OU, blocking Group Policy Object (GPO) inheritance to prevent conflicts, and managing DNS for reliable name resolution—especially in disjoint namespace scenarios.

Prerequisites: What You Need Before Starting

Before configuring AD, gather these essentials:

• Dedicated OU: Create one specifically for Azure Local computer objects and the cluster Computer Name Object (CNO). This isolates and speeds up queries in multi-site AD environments.
• Deployment User: A user account with permissions limited to the OU. It can be anywhere in the directory but must handle computer object creation/deletion and BitLocker recovery info.
• DNS Server: Preferably Microsoft DNS integrated with AD for secure dynamic updates. If using non-Microsoft DNS, prepare to manually create records.
• PowerShell Access: You'll need the Active Directory module for scripting permissions.
• Optional Precreations: Computer accounts and cluster CNO can be precreated using the deployment user.

Benefits of Proper AD Preparation

Getting AD ready isn't just a checkbox—it's a foundation for success:

• Enhanced Security: Scoped permissions minimize risks by limiting access to only what's needed.
• Performance Optimization: A dedicated OU reduces query times in large AD setups.
• Conflict Prevention: Blocking GPO inheritance lets Azure Local enforce its drift-protected security defaults without interference.
• Reliable Operations: Proper DNS handling ensures smooth cluster aware updating (CAU) and avoids manual interventions.

In short, this prep work saves time during deployment and reduces post-setup troubleshooting.

Step-by-Step Guide: Configuring Active Directory

Follow these steps to set up AD for Azure Local. Use PowerShell for precision, especially with permissions.

1. Create the Dedicated OU and Deployment User

• Run PowerShell commands like New-ADOrganizationalUnit to create the OU (e.g., "HCI001").
• Create the deployment user with New-ADUser.

2. Assign Permissions to the Deployment User

• Import the AD module: Import-Module ActiveDirectory.
• Define variables for OU path (e.g., $OUpath = 'OU=HCI001,DC=contoso,DC=com') and user (e.g., $User = 'deploymentuser').
• Get the user's SID and OU ACL.
• Create and apply access rules:
  text

  $createChild = New-Object System.Security.AccessControl.AccessRule($sid, "CreateChild, DeleteChild", "Allow", $computerObjectGuid, "All", $guidNull)
  $readProperty = New-Object System.Security.AccessControl.AccessRule($sid, "ReadProperty", "Allow", $guidNull, "Descendents", $guidNull)
  $fullControlBitLocker = New-Object System.Security.AccessControl.AccessRule($sid, "GenericAll", "Allow", $guidNull, "Descendents", $bitLockerObjectGuid)
  $acl.AddAccessRule($createChild)
  $acl.AddAccessRule($readProperty)
  $acl.AddAccessRule($fullControlBitLocker)
  Set-Acl -Path "AD:\$OUpath" -AclObject $acl
  This grants create/delete on computers, read on all, and full control on BitLocker recovery objects.Note: Don't use the AD delegation wizard for BitLocker permissions—stick to PowerShell.

3. Block Group Policy Inheritance

• Use: Set-GPInheritance -Target $OUpath -IsBlocked Yes.
• This prevents external GPOs from overriding Azure Local's settings.

4. Handle Disjoint Namespace (If Applicable)

• Append the AD domain DNS suffix to management adapters: Set-DnsClient -InterfaceIndex <index> -ConnectionSpecificSuffix "contoso.com".
• Verify: nslookup hostname.contoso.com.
• Avoid GPO-based DNS suffix lists—they're not supported.

5. Configure DNS and Disable Dynamic Updates for CAU

• Disable dynamic DNS: Get-NetAdapter "vManagement*" | Set-DnsClient -RegisterThisConnectionsAddress $false.
• If no secure dynamic updates, manually create Host A records for machine names, CNO, and VCO.
• Prestage the VCO per Microsoft's failover clustering guide.

6. Verify Configurations

• Check DNS records: nslookup "<machine name>".
• Ensure everything resolves to FQDNs.

Best Practices and Troubleshooting

• Security Best Practices: Always scope permissions to the OU. Use secure dynamic updates where possible to automate DNS.
• Warnings: Precreate objects if needed, but do it with the deployment user. Create DNS records right after disabling updates to avoid drifts.
• Troubleshooting: If queries are slow, confirm the dedicated OU. For DNS issues, double-check suffixes and records. If drifts occur, verify dynamic updates are off—Azure Local will rollback changes.

Conclusion

Prepping Active Directory for Azure Local is a straightforward process that pays off in stability and efficiency. By following these steps, you'll set up a secure, optimized environment ready for deployment. Remember, this is tailored for version 23H2—always check Microsoft's docs for updates. If you run into snags, tools like nslookup and PowerShell diagnostics are your friends. Happy deploying!

Simplifying Networking in Azure Local: A Deep Dive into Network ATC

    In the world of hybrid cloud infrastructure, managing networks in clustered environments like Azure Local can be a daunting task. Enter Network ATC—a powerful tool that's revolutionizing how administrators deploy and maintain host networking. Whether you're dealing with Azure Local or its Azure Local variant, Network ATC brings intent-based automation to the forefront, ensuring consistency, reducing errors, and enforcing best practices. In this blog post, we'll explore what Network ATC is, its core features, benefits, deployment steps, and some practical tips to get you started.

What is Network ATC?

Network ATC stands for a streamlined approach to networking configuration in Azure Local and Azure Local clusters. It's not just an acronym—it's a full-fledged tool that automates the deployment and operation of host networks using "intents." These intents define how physical network adapters should be used, specifying types like management, compute, storage, or even stretch for distributed setups.

At its core, Network ATC shifts from manual, error-prone configurations to an intent-based model. You declare your networking goals (e.g., "Use these adapters for storage traffic with specific VLANs"), and the system handles the rest: creating virtual switches, assigning IPs, setting VLANs, and more. This ensures symmetry across all cluster nodes, where adapters are configured identically based on make, model, and speed. It's mandatory in Azure Local 23H2 and later, and it's deeply integrated with tools like Windows Admin Center and PowerShell for ease of use.

In Azure Local contexts, Network ATC extends this to scenarios like stretched Storage Spaces Direct (S2D) clusters, where it handles storage replica networks without RDMA support, though you'll need to manually assign IPs in those cases.

Key Features of Network ATC

Network ATC packs a punch with features designed to make your life easier:

• Intent-Based Configuration: Define intents with a name, adapters, and types (Management, Compute, Storage, Stretch). Adapters can only belong to one intent, but you can have multiple intents per cluster. For example, a single intent might group management and compute traffic on shared adapters via an Embedded Switch Team (SET).
• Overrides for Customization: Not everything fits the defaults. Use overrides for adapters (e.g., RDMA, MTU like JumboPacket=9014), storage (e.g., disable auto IP generation), QoS, cluster settings, and proxies. This allows fine-tuning without breaking the automation.
• Automation and Validation: It automatically configures Data Center Bridging, virtual adapters, VLANs, and even cluster network naming (e.g., "storage_compute_VLAN711"). Plus, it regularly validates setups and remediates drifts—like reverting unauthorized MTU changes.
• Live Migration Optimization: Manages settings for maximum migrations, networks, and SMBDirect (RDMA) bandwidth, with overrides available.
• Proxy and Stretch Support: Ensures consistent proxy configs across nodes and supports stretched S2D without assigning IPs automatically.
• Networking Patterns: Choose from predefined patterns like grouping all traffic, management/compute together, or compute/storage, to guide your intents.

Starting from Azure Local 22H2, it even auto-detects cluster scopes and verifies adapter symmetry.

Benefits: Why Bother with Network ATC?

Adopting Network ATC isn't just about following trends—it's about real-world gains:

• Reduced Complexity and Time: Say goodbye to manual setups that take hours. Intents automate everything, cutting deployment time dramatically.
• Error Reduction and Consistency: Enforces Microsoft-validated best practices, ensuring no configuration drift. All nodes stay in sync, preventing mismatches that could cause outages.
• Built-in Remediation: If someone tweaks an MTU outside the intent, Network ATC spots it and fixes it automatically.
• Scalability for Hybrid Setups: Perfect for Azure Local's hybrid nature, with seamless integration for cloud deployments that auto-create intents based on patterns.

Compared to pre-Network ATC methods, which were manual and prone to inconsistencies, this is a game-changer—especially in versions 21H2 onward, maturing through 22H2 and becoming essential in 23H2+.

How to Deploy Network ATC: A Step-by-Step Guide

Ready to implement? Here's a practical guide based on proven steps.

Prerequisites

• Run on Windows Server Datacenter with Failover Clustering enabled.
• Install features on all nodes:
  text

  Install-WindowsFeature -Name NetworkATC, NetworkHUD, Hyper-V, 'Failover-Clustering', 'Data-Center-Bridging' -IncludeManagementTools
• Ensure adapters are in the same PCI slots across nodes for consistency.

Creating Intents

Use PowerShell to add intents. For a management/compute setup:

text

$adapteroverrides = New-NetIntentAdapterPropertyOverrides
$adapteroverrides.NetworkDirect = $false
$adapteroverrides.JumboPacket = "9014"
Add-NetIntent -Name Management_Compute -Management -Compute -AdapterName pMGMT01, pMGMT02 -ManagementVlan 31 -AdapterPropertyOverrides $adapteroverrides

For storage:

text

$storageoverrides = New-NetIntentStorageOverrides
$storageoverrides.EnableAutomaticIPGeneration = $false
$adapteroverridesstorage = New-NetIntentAdapterPropertyOverrides
$adapteroverridesstorage.JumboPacket = "9014"
Add-NetIntent -Name Storage -Storage -AdapterName pSMB01, pSMB02 -StorageVlans 711,712 -StorageOverrides $storageoverrides -AdapterPropertyOverrides $adapteroverridesstorage

Monitoring and Validation

Check status:

text

Get-NetIntentStatus | sort host | ft Intentname,host,ConfigurationStatus,ProvisioningStatus

For SDN clusters, remove existing VMSwitches first:

text

Get-VMSwitch -Name | Remove-VMSwitch -force
``` But note challenges with running VMs.

## Best Practices and Troubleshooting

- **Consistency is Key**: Always match adapter placements and test in labs.
- **SDN Integration**: Wait for Arc-enabled SDN GA if using SDN.
- **Limitations to Watch**: No RDMA for stretch intents; manual IPs for stretched S2D; can't change SR-IOV post-switch creation.
- **Troubleshooting**: If a VMSwitch is deleted, Network ATC should recreate it, but monitor management IPs—they might fallback temporarily.

## Conclusion

Network ATC is a must-have for anyone managing Azure Local or Azure Local clusters. By automating configurations and enforcing standards, it frees you from networking headaches, letting you focus on what matters. If you're on 23H2 or later, it's not optional—it's essential. Dive in with the steps above, and you'll see the difference in no time. Happy networking!