SteelFusion technology enables remote branch offices to use storage provisioned at the data center through unreliable, low-bandwidth and high-latency WAN links. Adding this new type of traffic to the WAN links creates new considerations in terms of guaranteeing quality of service (QoS) to existing WAN applications and to the SteelFusion Rdisk protocol to function at the best possible level.

This chapter contains the following topics:

For general information about QoS, see the SteelHead Deployment Guide.

To understand the QoS requirements for the SteelFusion Rdisk protocol, you must understand how it works. The Rdisk protocol defines how the Edge and Cores communicate and how they transfer data blocks over the WAN. Rdisk uses five TCP ports for data transfers and one TCP port for management.

The following table summarizes the TCP ports used by the Rdisk protocol. It maps the different Rdisk operations to each TCP port.

Different Rdisk operations use different TCP ports. The following table summarizes the Rdisk QoS requirements for each Rdisk operation and its respective TCP port.

For more information about Rdisk, see Rdisk traffic routing options.

To prevent SteelFusion replication traffic from consuming bandwidth required for other applications during business hours, you should allow more bandwidth for Rdisk write traffic (port 7951) during the off-peak hours and less bandwidth during the peak hours. Also carefully consider your recovery point objectives (RPO) and recovering time objectives (RTO) when configuring QoS for Rdisk SteelFusion traffic.

Depending on which SteelFusion features you use, you might need to consider different priorities and bandwidth requirements.

This section contains the following topics:

For more information about pinned exports, see Pin the export and prepopulate the blockstore.

In an unpinned exports scenario, you should prioritize traffic on port 7950 so that the SCSI read requests for data blocks not present on the Edge blockstore cache can arrive from the data center export in a timely manner. You should prioritize traffic on ports 7952, 7953, and 7954 so that the prefetch data can arrive at the blockstore when needed.

In a pinned, prepopulated export scenario, all the data is present at the Edge. You should prioritize only port 7951 so that the Rdisk protocol can transfer newly written data blocks from the Edge blockstore to the data center export through Core.

This section contains the following topics:

There may be deployments where ESXi servers with datastores exported from the Edge in the branch office are not producing new data but instead are mainly reading data from the data center and the exports are not pinned. In this case, you should prioritize traffic on ports 7950 and 7952 so that the NFS read requests for data blocks not present on the Edge blockstore cache can arrive from the data center exports in a timely manner.

There may be deployments where ESXi servers with datastores exported from the Edge in the branch office are booting virtual machines from the data center and the exports are not pinned. In these scenarios, ensure that port 7950 is the top priority for nonpinned exports and that you prioritize traffic on port 7953 so that boot data is prefetched on this port in a timely manner.

This example illustrates how to configure time-based QoS rules on a SteelHead.

You want to create two recurring jobs, each undoing the other, using the standard job CLI command. One sets the daytime cap on throughput or a low minimum guarantee, and the other then removes that cap or sets a higher minimum guarantee.