Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Deploying S2D Cluster in Microsoft Azure with a Highly Available Active Directory Domain

  • December 9, 2024
  • 12 min read
Storage and Virtualization Engineer. Volodymyr has broad experience in solution architecture and data protection, backed by a technical background in applied physics.
Storage and Virtualization Engineer. Volodymyr has broad experience in solution architecture and data protection, backed by a technical background in applied physics.

Introduction

This article provides a step-by-step guide on deploying a Windows Server Storage Spaces Direct (S2D) cluster in Microsoft Azure with a highly available Active Directory domain. Storage Spaces Direct is a software-defined storage solution that enables the creation of highly available and scalable storage by leveraging locally attached disks across clustered servers.

Prerequisites

Before proceeding the deployment, ensure you have:

An active Microsoft Azure subscription with sufficient permissions to provision and manage resources.

A foundational understanding of core Azure concepts, including Resource Groups, Virtual Networks, Virtual Machines, and Storage Accounts.

Step 1: Deploying a Highly Available Active Directory Domain

The Azure Resource Manager (ARM) template “active-directory-new-domain-ha-2-dc” is designed to establish a new Active Directory domain with built-in high availability. It provisions two virtual machines as domain controllers, placing them within an Azure Availability Set to ensure continuous availability.

Step-by-Step Guide on Deploying the AD Domain

You can deploy the Active Directory domain using the ARM template via the Azure portal or Azure CLI/PowerShell.

Option 1: Using the Azure Portal

  1. Navigate to the template link: https://learn.microsoft.com/en-us/samples/azure/azure-quickstart-templates/active-directory-new-domain-ha-2-dc/
  2. Click the “Deploy to Azure” button.
  3. Choose your subscription and create a new Resource Group.
  4. Fill out required parameters: Admin credentials, DNS prefix, Domain name.

Option 2: Using Azure CLI/PowerShell

Azure CLI Example:

az group create --name myResourceGroup --location eastus

az deployment group create \

--resource-group myResourceGroup \

--template-uri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.activedirectory/active-directory-new-domain-ha-2-dc/azuredeploy.json \

--parameters adminUsername=adminUser \

adminPassword="YourP@ssw0rd123" \

dnsPrefix=mydns \

domainName=mydomain.local

Azure PowerShell Example:

New-AzResourceGroup -Name myResourceGroup -Location "East US"

New-AzResourceGroupDeployment \

-ResourceGroupName myResourceGroup \

-TemplateUri "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.activedirectory/active-directory-new-domain-ha-2-dc/azuredeploy.json" \

-adminUsername adminUser \

-adminPassword "YourP@ssw0rd123" \

-dnsPrefix mydns \

-domainName mydomain.local

Explanation of Key Parameters

  • Subscription: Azure subscription under which resources will be provisioned.
  • Resource Group: Logical container for deployed resources.
  • Location: Azure region where resources will be physically located.
  • Admin Username and Admin Password: Local administrator account credentials for domain controller VMs.
  • Domain Name: Fully qualified domain name (FQDN) for the new Active Directory domain.
  • Dns Prefix: Unique DNS name for the public IP address associated with the load balancer.

Verification Steps

  1. Confirm all resources are created in the Azure portal.
  2. Check the deployment status is “Succeeded” in the Resource Group’s “Overview” blade.
  3. Connect to the domain controller VMs via RDP.
  4. Verify the domain creation and the second domain controller VM listing using “Active Directory Users and Computers.”

Step 2: Configuring the Virtual Network for S2D Integration

The ARM template creates a Virtual Network (VNet) with a defined private IP address space and a default subnet for the domain controllers.

1. Create a Subnet for S2D Nodes (Azure CLI)

Create a new subnet within the existing Virtual Network for the S2D cluster nodes. Use a distinct IP address range that doesn’t overlap with the AD subnet.

Azure CLI Example:

az network vnet subnet create \

--resource-group myResourceGroup \

--vnet-name myVnet \

--name s2dSubnet \

--address-prefixes 10.0.1.0/24

Azure PowerShell Example:

$vnet = Get-AzVirtualNetwork -Name myVnet -ResourceGroupName myResourceGroup

Add-AzVirtualNetworkSubnetConfig -Name s2dSubnet -AddressPrefix "10.0.1.0/24" -VirtualNetwork $vnet | Set-AzVirtualNetwork

2. Configure Network Security Groups (NSGs)

Create NSGs for both the AD subnet and the S2D subnet. Allow necessary traffic between the subnets and for remote management access.

$nsg = New-AzNetworkSecurityGroup -ResourceGroupName myResourceGroup -Location "East US" -Name "s2d-nsg"

# Allow RDP

$nsgRule = New-AzNetworkSecurityRuleConfig -Name "Allow-RDP" -Protocol Tcp -Direction Inbound -Priority 1000 -SourceAddressPrefix "*" -SourcePortRange "*" -DestinationAddressPrefix "*" -DestinationPortRange 3389 -Access Allow

$nsg.SecurityRules += $nsgRule

Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg

3. Ensure Proper DNS Configuration

Verify the DNS server settings for the Virtual Network. Ensure the private IP addresses of the domain controllers are listed as DNS servers.

$vnet.DhcpOptions.DnsServers = @("10.0.0.4", "10.0.0.5")

Set-AzVirtualNetwork -VirtualNetwork $vnet

Step 3: Deploying the Windows Server S2D Cluster

Deploy the S2D cluster template via the Azure portal or Azure CLI/PowerShell, specifying the existing Resource Group, Virtual Network, and dedicated subnet.

Appropriate VM Sizes and Storage Configurations

  1. Choose VM series like DS-series or ES-series that support premium storage.
  2. Utilize premium SSDs for all disks used by S2D.
  3. Consider tiered storage configurations with NVMe or premium SSDs for the cache tier.

To deploy the S2D cluster, follow these steps:

1. Create Virtual Machines

Deploy two or more Windows Server VMs (Windows Server 2022 Datacenter edition recommended) into the same Availability Set for redundancy:

New-AzVM -ResourceGroupName "myResourceGroup" `

-Name "s2d-node01" `

-Location "East US" `

-VirtualNetworkName "myVnet" `

-SubnetName "s2dSubnet" `

-AvailabilitySetName "s2d-avset" `

-Image "Win2022Datacenter" `

-Size "Standard_DS4_v2" `

-AdminUsername "adminUser" `

-AdminPassword "YourP@ssw0rd123"

Repeat this for each cluster node.

2. Join VMs to the Active Directory Domain

From each node:

Add-Computer -DomainName "mydomain.local" -Credential (Get-Credential)

Restart-Computer

3. Install Required Features

Install Failover Clustering and File Server roles:

Install-WindowsFeature -Name Failover-Clustering, FS-FileServer -IncludeManagementTools

4. Validate the Cluster

Run cluster validation tests:

Test-Cluster -Node s2d-node01, s2d-node02

Review the report and ensure all required checks pass.

5. Create the Cluster

New-Cluster -Name "s2d-cluster" -Node s2d-node01,s2d-node02 -StaticAddress "10.0.1.100" -NoStorage

6. Enable Storage Spaces Direct

Enable-ClusterS2D -Confirm:$false

Once S2D is enabled, it will automatically create the storage pool from all available eligible disks.

7. Tag the Disks (Optional)

If you’d like to manually tier storage (e.g., cache and capacity), tag disks:

Get-PhysicalDisk | Where-Object FriendlyName -Like "*P10*" | Set-PhysicalDisk -Usage Journal

Step 4: Configuring the S2D Cluster

Connect to the Cluster Nodes

RDP into each node and open PowerShell as Administrator.

Enable Storage Spaces Direct

Enable-ClusterS2D -Confirm:$false

Create Virtual Disks and Volumes

# Optional: list available physical disks

Get-PhysicalDisk

# Virtual disk

New-Volume -StoragePoolFriendlyName "S2D on Cluster" -FriendlyName "Volume1" -FileSystem ReFS -Size 1TB

Setup Cloud Witness

Set-ClusterQuorum -CloudWitness -AccountName "mystorageacct" -AccessKey "<access_key>"

Best Practices and Considerations for S2D in Azure

  1. Network Recommendations: Use high-performance, low-latency networking with a minimum of 10 GbE bandwidth.
  2. Storage Configuration Best Practices: Use premium SSDs for all S2D disks and consider tiered storage configurations.
  3. Performance Tuning and Monitoring: Utilize tools like Performance Monitor and Failover Cluster Manager to track performance metrics.
  4. Resiliency Options and Fault Tolerance: Choose appropriate data resiliency options based on the number of nodes and data criticality.
  5. Integration with Other Azure Services: Leverage Azure Backup, Azure Monitor, and Azure Site Recovery to enhance availability and manageability.

Troubleshooting Common Deployment Issues

  1. Potential Problems During AD Deployment: Connectivity issues, domain join failures, DNS resolution problems.
  2. Potential Problems During S2D Deployment: Template deployment failures, domain join issues, disk recognition problems.
  3. Common Configuration Errors and Their Resolutions: Incorrect network settings, misconfigured cloud witness, incompatible disk types.

By following this guide and adhering to best practices, you can successfully deploy a highly available Windows Server S2D cluster in Microsoft Azure with an Active Directory domain, providing a robust and scalable storage solution for critical workloads.

Hey! Found Volodymyr’s article helpful? Looking to deploy a new, easy-to-manage, and cost-effective hyperconverged infrastructure?
Alex Bykovskyi
Alex Bykovskyi StarWind Virtual HCI Appliance Product Manager
Well, we can help you with this one! Building a new hyperconverged environment is a breeze with StarWind Virtual HCI Appliance (VHCA). It’s a complete hyperconverged infrastructure solution that combines hypervisor (vSphere, Hyper-V, Proxmox, or our custom version of KVM), software-defined storage (StarWind VSAN), and streamlined management tools. Interested in diving deeper into VHCA’s capabilities and features? Book your StarWind Virtual HCI Appliance demo today!