Running Azure Stack HCI With Nested Resiliency On DELL EMC Ready Nodes

5 min read

Introduction

In Windows Server 2016, Microsoft introduced a new type of storage called Storage Spaces Direct which is part of the new Azure Stack HCI program. Azure Stack HCI enables building highly available storage systems with locally attached disks, and without the need to have any external SAS fabric such as shared JBODs or enclosures. This is the first true Software-Defined Storage (SDS) from Microsoft. Software-Defined Storage is a concept, which involves storing data without dedicated hardware.

In Windows Server 2019, Microsoft added a lot of improvements for the Azure Stack HCI (formerly known as Windows Server Software-Defined, aka WSSD). One of these improvements is a new type of resiliency known as nested resiliency that is designed only for two-server cluster and targeted for smaller deployment such as branch offices, or for backup target storage.

With nested resiliency, we can stand multiple failures at the same time (we can lose one server and one drive, or two drives) compare to the classic two-way mirror (one server or one drive). Nested Resiliency also comes in two options:

  • Nested two-way mirror: This option is like a four-way mirror, with two copies in each server. The capacity efficiency ratio is ~25% versus 50% to the classic two-way mirror.
  • Nested mirror-accelerated parity: Combine nested two-way mirror with nested parity. The capacity efficiency ratio is around ~35% to 40%.

I recently did a 2 Nodes Azure Stack HCI Hyper-Converged deployment on top of DELL EMC PowerEdge R740xd Ready Nodes with nested mirror-accelerated parity. In this blog post, I would like to share with you my experience and performance results, and finally compare it to the previous deployment with the classic two-way mirror on Windows Server 2016.

If you are interested on running Azure Stack HCI with Nested Resiliency in a lab environment, please check my previous article here: Storage Spaces Direct with Nested Resiliency on HPE ProLiant MicroServers.

2 Nodes Cluster – Hardware Platform

I used the following hardware configuration:

  • DELL PowerEdge R740XD Azure Stack HCI Ready Nodes
  • 2 x Intel Xeon Gold 5118 2.3G (16.5MB 12C/24T)
  • 256GB (8x32GB) 2666MT/s RDIMM Memory
  • Dell Boot Optimized Storage Solution (BOSS)
  • PCIe Card with 2 x 480GB SATA M.2 SSD (RAID1)
  • 4 x 1.92TB SAS-12G 2.5″ Read Intensive Hot-Plug SSD
  • 8 x 8TB NLSAS-12G 3.5″ 7.2K Hot-Plug HDD
  • DELL PERC HBA330 12Gbps SAS HBA Controller (NON-RAID)
  • Trusted Platform Module 2.0
  • Broadcom 57412 Ports 10Gb SFP+ / 5720 Ports 1Gb Base-T NIC
  • QLogic Dual Port FastLinQ 41262 SFP28 25GbE Ethernet Adapter (Support RoCE v1, RoCE v2, and iWARP)

The Dell EMC Microsoft Azure Stack HCI Ready Nodes are pre-configured with certified components, tested and validated by Dell EMC and Microsoft to help you build Hyper-Converged clusters with ease. It’s kind like plug and play system, great hardware indeed!

In this configuration, each SSD disk will serve as a Cache device for the Capacity slow HDD (1:2 ratio).

Running Azure Stack HCI With Nested Resiliency On DELL EMC Ready Nodes 1

Software Configuration

  • Host: Windows Server 2019 Datacenter Edition with August 2019 update
  • Single Storage Pool (117 TB)
  • 1 X 8 TB (standard two-way mirror)
  • 2 X 15 TB (nested mirror-accelerated parity)
  • ReFS/CSVF file system
  • 40 virtual machines (20 VMs per node)
  • 2 virtual processors and 8 GB RAM per VM
  • VM: Windows Server 2019 Datacenter Core Edition with August 2019 update
  • Jumbo Frame enabled
  • CSV Block Cache enabled with 16GB

The 15 TB Cluster Shared Volumes are configured with (Nested mirror-accelerated parity) to balance between capacity and performance. This combine nested two-way mirroring with nested parity. Within each server, the local resiliency for most data is provided by single bitwise parity arithmetic, except new recent writes which use two-way mirroring. Then, further resiliency for all data is provided by two-way mirroring between the two servers as illustrated in the diagram below. Running Azure Stack HCI With Nested Resiliency On DELL EMC Ready Nodes 2

Image credit [Microsoft]

Workload Configuration

DISKSPD version 2.0.21a workload generator
VM Fleet workload orchestrator

First Test – Total 573K IOPS – Read/Write Latency @ 0.3/1.9(ms)

Each VM configured with:

  • 4K IO size
  • 10GB working set
  • 100% read and 0% write
  • No Storage QoS
  • RDMA Enabled

Running Azure Stack HCI With Nested Resiliency On DELL EMC Ready Nodes 3

Second Test – Total 321K IOPS – Read/Write Latency @ 0.3/1.7(ms)

Each VM configured with:

  • 4K IO size
  • 10GB working set
  • 70% read and 30% write
  • No Storage QoS
  • RDMA Enabled

Running Azure Stack HCI With Nested Resiliency On DELL EMC Ready Nodes 4

In this example, I am using 25GbE direct connection between the nodes, I set the RDMA NICs to support iWARP instead of RoCE. You may wonder why iWARP and not RoCE. iWARP is easy to set up and does not require DCB configuration, in this setup, I am not using switch between the nodes. Furthermore, this deployment will NOT grow beyond two nodes. Nested Resiliency was carefully chosen to provide maximum availability to sustain multiple failures.

Last but not least, Microsoft also added support for Windows Admin Center to manage Azure Stack HCI Hyper-Converged Infrastructure on top of Windows Server 2016 and Windows Server 2019, which gives you complete visibility to monitor and manage your Azure Stack HCI environment.

Summary

In this article, I showed you the performance results with nested mirror-accelerated parity resiliency on two nodes using DELL EMC PowerEdge R740xd Ready Nodes. For more information about Nested Resiliency, please check the Microsoft documentation here.

There are two factors to consider when using nested resiliency in Windows Server 2019. First, you will see lower read/write IOPS than the classic two-way mirror. With 100% read, we got slightly lower performance compared to the previous deployment on the same hardware with Windows Server 2016, this is because nested mirror-accelerated parity combines nested two-way mirror with nested parity, however, we saw only 70K lower IOPS with 30% write because, within each server, the local resiliency for most data is provided by single bitwise parity arithmetic, except new recent writes which use two-way mirroring. Then, further resiliency for all data is provided by two-way mirroring between the two servers.
Second, you will have less usable capacity to use for production workloads, but with nested resiliency, either nested two-way mirror or nested mirror-accelerated parity what you gain in return is higher uptime and availability.

Always remember that storage is cheap, but downtime is expensive!!!

Let me know what you think in the comment section below.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

About Charbel Nemnom 579 Articles
Charbel Nemnom is a Cloud Architect, Swiss Certified ICT Security Expert, Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT), totally fan of the latest's IT platform solutions, accomplished hands-on technical professional with over 17 years of broad IT Infrastructure experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems. Excellent communicator is adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative IT project development. Well respected by peers through demonstrating passion for technology and performance improvement. Extensive practical knowledge of complex systems builds, network design, business continuity, and cloud security.

Be the first to comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.