Azure Local & Stretched clustering migration options

In version Azure Local 23H2 there have been major changes and functionalities have been added that cause problems with stretched clustering. Recently, a support statement was released in which Microsoft uses the so-called stretched clustering has been discontinued.

In this post we will outline the information we share with our customers to help you or your customers further. Sharing is caring!

Option 1: Temporary update to buy time

Support for Azure Local 22H2 is ending end of May 2025.

For Azure Local 22H2 customers, Microsoft has allowed an update from 22H2 to 23H2 for stretched clusters for the base OS. The update will not include the new features introduced in 23H2, it's just an update of the OS.

As shown in the diagram, you will not perform step 2. You will keep your cluster supported until 23H2 also goes end-of-support.

Caution: You will not be able to upgrade to later versions than 23H2 base OS.

Option 2: Migrate to Rack-Aware Clustering

If you have a stretched 22H2 Azure Local and you want to make use of the new Rack Aware Cluster (RAC) you can migrate to it. There are two very important aspects in terms of support for RAC:

• Rack Aware Cluster(RAC) is only supported for greenfield deployment?
• RAC can only be deployed when there are two racks of servers, adding servers to racks (in pair) is supported. For example, for 1+1 RAC, you can add 2 servers, one in each rack, the RAC to be 2+2.

If you have a stretched cluster you have two sites with multiple nodes per site. The method to migrate to RAC without downtime or using spare hardware would be:

1. Evict at least one node per site
2. Setup a greenfield cluster with 1+1 RAC
3. Migrate workloads
4. Evict one node per site
5. Add nodes to make a 2+2 RAC
6. Migrate workloads
7. Evict one node per site
8. Add nodes to make a 3+3 RAC
9. Etc.

There are no official prerequisites for RAC communicated other than "within the same Layer-2 network at a single location". As RAC is using one storage pool as described in the announcement blog the solution presumably has low latency requirements. If your current stretched cluster nodes are far apart from each other, maybe even using A-sync replication, it could be that your environment will not meet the needs for RAC. The only way forward would be 'Option 3' if you have a hard requirement for stretching.

Option 3: Migrate to Windows Server 2025

Windows Server has never supported 'Stretched S2D clusters' (only when using a SAN), but the announcements have been made that the 2025 edition is going to support it. It is currently not supported yet to use Windows Server 2025 GA version for Stretched clustering.

When Windows Server does support it (hopefully very soon), you can migrate in the same way as you would do with RAC. Evict nodes from your Azure Local cluster and build a new Windows Server S2D stretched cluster.

Caution: You cannot live migrate VMs from Azure Local to Windows Server.

Splitbrain is helping Microsoft to test and PoC these solutions, if you have any questions.. reach out!