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 LUNs, see Pin the LUN and prepopulate the blockstore and When to PIN and prepopulate the LUN.

In an unpinned LUNs 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 LUN 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 LUN 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 LUN through Core.

This section contains the following topics:

In the case of branch office users who are not producing new data but instead are mainly reading data from the data center and the LUNs are not pinned, you should prioritize traffic on ports 7950 and 7952 so that the iSCSI read requests for data blocks not present on the Edge blockstore cache can arrive from the data center LUN in a timely manner.

In the case of branch office users who are booting virtual machines from the data center and the LUNs are not pinned, ensure that port 7950 is the top priority for nonpinned LUN 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.