Every deployment of the SteelFusion product family differs due to variations in specific customer needs and types and sizes of IT infrastructure.

The following recommendations and best practices are intended to guide you to achieving optimal performance while reducing configuration and maintenance requirements. However, these guidelines are general; for detailed worksheets for proper sizing, contact your Riverbed account team.

This chapter includes the following sections:

This section describes best practices for deploying the Core. It includes the following topics:

The NFS protocol enables file-level traffic over IP networks. However, NFS is both latency and bandwidth sensitive. To optimize performance reliability, deploy Core and the storage array on Gigabit Ethernet networks.

If the branch DNS server runs on VSP and its DNS datastore is deployed on an export used with SteelFusion, use the Core IP address instead of the hostname when you specify the Core hostname and IP address.

If you must use the hostname, deploy the DNS server on the VSP internal storage, or configure host DNS entries for the Core hostname on the SteelHead.

To increase overall security, minimize congestion, minimize latency, and simplify the overall configuration of your storage infrastructure, segregate storage traffic from regular LAN traffic using VLANs (Figure 10‑1).

SteelFusion technology has built-in file system awareness for NTFS and VMFS file systems. You will likely need to pin and prepopulate the export if frequent, prolonged periods of WAN outages are expected.

When the WAN link between the remote branch office and the data center is down, data no longer travels through the WAN link. Hence, SteelFusion technology and its intelligent prefetch mechanisms no longer functions. Pin and prepopulate the export if frequent, prolonged periods of WAN outages are expected.

By default, the Edge keeps a write reserve that is 10 percent of the blockstore size. If prolonged periods of WAN outages are expected, appropriately increase the write reserve space.

Store and back up the configuration on an external server in case of system failure. Enter the following CLI commands to export the configuration:

Complete this export each time a configuration operation is performed or you have some other changes on your configuration.

If the configuration has been saved on an external server, the failed Core can be seamlessly replaced. Enter the following CLI commands to retrieve what was previously saved:

When provisioning VMs as part of a data migration, it is possible to see high traffic usage across the WAN link. This can be due to the type of VMDK that is being migrated. This table gives an example of WAN usage consumption for a Core to Edge VMDK data migration containing a 100 GiB VMDK with 20 GiB used.

For more details, see this Knowledge Base article on the Riverbed Support site:

When deploying Core-v, see the SteelFusion Core Installation and Configuration Guide to understand what hardware requirements (memory, CPU, and disk) are required to support your Core-v model. We strongly recommend that you allocate and reserve the correct amount of resources as specified in the SteelFusion Core Installation and Configuration Guide. Reserving these resources ensures that the memory and recommended CPU are dedicated for use by the Core-v instance, enabling it to perform as expected.

Core does not support Multipath input/output (MPIO). For redundancy between the Core and the backend NFS file server, consider using the Edge Virtual IP (VIP) capability on the NFS file server interfaces if it is supported by the vendor.

In a deployment where multiple network interfaces are configured on the Core to connect to backend NFS file servers, there is no interface selection for the NFS traffic. Any interface that is able to find a route to the NFS file server could be used. If you must use specific interfaces on the Core to connect to specific NFS file server ports, then consider using static routes on the Core to reach the specific NFS file server IP addresses.

Do not edit files on the exported fileshares by accessing them directly, unless the fileshare has already been unmounted from the Core. Where possible, use controls to restrict direct access to exported files on the file server.

Ensure that only the Core has write permission on the exported fileshares. This can be achieved by using IP or hostname based access control on the NFS file server configuration settings for the exports. If necessary, the permissions on exported fileshares can be configured to allow mounting read-only by other hosts.

Exported fileshares up to 16 TiB (per export) are supported on the Core. However, the number of mounted exports that are supported will depend on the model of Core.

Exported fileshares can be expanded on the backend NFS file server without first unmounting them from the Core. The resized export will be detected by the Core automatically within approximately one minute. Reduction of exported fileshares is not supported.

Replacing a Core as part of an RMA operation will require an extra configuration task if the Core is part of an NFS deployment. By default, a replacement Core will be shipped with a standard software image that would normally operate in block storage mode. As part of the procedure to replace a Core, if necessary, the Core software should first be updated to a version of supporting NFS (minimum version 5.0). If the Core needs to be upgraded to a version that supports NFS, make sure both image partitions are updated so the Core isn’t accidentally rebooted to a version that doesn’t support NFS/file mode. Once the required version of software is installed, the Core needs to be instructed to operate in NFS/file mode. This is achieved by entering the following two commands using the Core command line interface:

The first command will automatically respond back with a request for confirmation, at which point, you can enter the second command.

Once the Core is configured for NFS operations, it can be configured with the relevant storage settings.

If a Core that is part of an HA deployment needs to be replaced, use the following sequence of steps as a guideline to help with replacement of the Core:

This section describes best practices for deploying the Edge. It includes the following topics:

At the remote branch office, separate storage traffic and WAN/Rdisk traffic from LAN traffic. This practice helps to increase overall security, minimize congestion, minimize latency, and simplify the overall configuration of your storage infrastructure.

In specific circumstances, you should pin the export and prepopulate the blockstore. Additionally, you can have the write-reserve space resized accordingly; by default, the Edge has a write-reserve space that is 10 percent of the blockstore.

To resize the write-reserve space, contact your Riverbed representative.

We recommend that you pin the export in the following circumstances:

You should only allow NFS traffic on primary and auxiliary interfaces. Riverbed does not recommend that you configure your external NFS initiators to use the IP address configured on the in-path interface. Some appliance models can optionally support an additional NIC to provide extra network interfaces. You can also configure these interfaces to provide NFS connectivity.

When you have an Edge and ESXi running on the same converged platform, you must change IP addresses in a specific order to keep the task simple and fast. You can use this procedure when staging the Edges in the data center or moving them from one site to another.

This procedure assumes that the Edges are configured with IP addresses in a staged or production environment. You must test and verify all ESXi, servers, and interfaces before making these changes.

You can create Edge Local exports using the Core management console. Choose Configure > NFS: Exports and use the “Create an Edge Local Export” tool. Once you have created the Edge Local exports, they can be mapped to the Edge.

You can route Rdisk traffic out of the primary or the in-path interfaces. This section contains the following topics:

For more information about Rdisk, see “Network Quality of Service” on page 105. For information about WAN redundancy, see “Configuring WAN redundancy” on page 77.

Select the in-path interface when you deploy the SteelFusion Edge W0 appliance. When you configure Edge to use the in-path interface, the Rdisk traffic is intercepted, optimized, and sent directly out of the WAN interface toward the Core deployed at the data center.

Use this option during proof of concepts (POC) installations or if the primary interface is dedicated to management.

The drawback of this mode is the lack of redundancy in the event of WAN interface failure. In this configuration, only the WAN interface needs to be connected. Disable link state propagation.

We recommend that you select the primary interface when you deploy the SteelFusion Edge W1-W3 appliance. When you configure Edge to use the primary interface, the Rdisk traffic is sent unoptimized out of the primary interface to a switch or a router that in turn redirects the traffic back into the LAN interface of the Edge RiOS node to get optimized. The traffic is then sent out of the WAN interface toward the Core deployed at the data center.

This configuration offers more redundancy because you can have both in-path interfaces connected to different switches.

The Edges and Cores communicate with each other and transfer data-blocks over the WAN using six different TCP port numbers: 7950, 7951, 7952, 7953, 7954, and 7970.

Figure 10‑2 shows a deployment in which the remote branch and data center third-party optimization appliances are configured through WCCP. You can optionally configure WCCP redirect lists on the router to redirect traffic belonging to the six different TCP ports of SteelFusion to the SteelHeads. Configure a fixed-target rule for the six different TCP ports of SteelFusion to the in-path interface of the data center SteelHead.

By default, VMware ESXi dynamically tries to reclaim unused memory from guest virtual machines, while the Windows operating system uses free memory to perform caching and avoid swapping to disk.

To significantly improve performance of Windows virtual machines, configure memory reservation to the highest possible value of the ESXi memory available to the VM. This configuration applies whether the VMs are hosted within the hypervisor node of the Edge or on an external ESXi server in the branch that is using exports from SteelFusion.

Setting the memory reservation to the configured size of the virtual machine results in a per virtual machine vmkernel swap file of zero bytes, which consumes less storage and helps to increase performance by eliminating ESXi host-level swapping. The guest operating system within the virtual machine maintains its own separate swap and page file.

There are two antivirus scanning modes:

There are two common locations to perform the scanning:

In typical SteelFusion deployments in which the exports at the data center contain the full amount of data and the remote branch cache contains the working set, run on-demand scan mode at the data center and on-access scan mode at the remote branch. Running on-demand full file system scan mode at the remote branch causes the blockstore to wrap and evict the working set of data leading to slow performance results.

However, if the exports are pinned, on-demand full file system scan mode can also be performed at the remote branch.

Whether scanning on-host or off-host, the SteelFusion solution does not dictate one way versus another, but in order to minimize the server load, we recommend off-host virus scans.

Disk defragmentation software is another category of software that can possibly cause the SteelFusion blockstore cache to wrap and evict the working set of data. Do not run disk defragmentation software. Disable default-enabled disk defragmentation on Windows 7 or later.

Backup software is another category of software that will possibly cause the Edge blockstore cache to wrap and evict the working set of data, especially during the execution of full backups. In a SteelFusion deployment, run differential, incremental, synthetic full, and a full backup at the data center.

If jumbo frames are supported by your network infrastructure, use jumbo frames between Core and storage arrays. We make the same recommendation for the Edge and any external application servers (not hosted within VSP) that are using exports from the Edge. The application server interfaces must support jumbo frames. For details, see “Configuring Edge for jumbo frames” on page 47.

When a Core is removed from the Edge with the “preserve config” setting enabled, the Edge local exports are saved and the offline remote exports are removed from the Edge configuration. On the Core, there is no change, but the exports show as “Not connected.” In most scenarios, the reason for this procedure is replacement of the Core.

If a new Core is added to the Edge, the Edge local storage is merged from the Edge to the Core and normal operations are resumed.

However, if for some reason the same Core is added back, the Edge local storage information on the Core must be cleared from the Core by removing any entries for the specific Edge local exports, before the add operation is performed.

Once the same Core is added back again, the Edge local storage information, on the Edge, is merged to the Core configuration. At the same time, the remote offline storage information on the Core that is mapped to the Edge is merged across to the Edge.

Failure to clear the information prior to re-adding the Core will result in the Core rejecting the Edge connection and both the Core and Edge logfiles reporting a “Config mismatch.”

Further details are available on the Riverbed Support site, in Knowledge Base article S30272 - https://supportkb.riverbed.com/support/index?page=content&id=S30272.

SteelFusion Edge with NFS is not designed to be a general purpose NFS file server and is not supported in this role.

If additional nonbypass ports are available in the RiOS node due to the installation of an optional network interface card (NIC), the VIP address can be assigned on those ports.

Before unmapping or taking offline any NFS exports on the Edge, ensure that the ESXi datastore that corresponds to the exported fileshare has been unmounted.

Exported fileshares that contain sparse files can be mounted by the Core and projected to the Edge. However, SteelFusion does not maintain the sparseness and, therefore, pinning the exported fileshare may not be possible. If a sparse file is created through the Edge, it will be correctly synchronized back to the backend NFS file server. But if the export that contains the sparse file is off-lined or unmounted, the sparseness is not maintained following a subsequent on-line or mount operation.

If you need to change the VIP address on the Edge appliance, you may need to remount the datastores. In this scenario, a VIP address change will also affect the UUID generated by the ESXi server. For more details on additional administration steps required, see the Knowledge Base article on the Riverbed Support site: https://supportkb.riverbed.com/support/index?page=content&id=S30235.

Replacing an Edge as part of an RMA operation will require an extra configuration task if the Edge is part of an NFS deployment. By default, a replacement Edge will be shipped with a standard software image that would normally operate in block storage mode. As part of the procedure to replace an Edge, if necessary, the Edge software should first be updated to a version supporting NFS (minimum version 5.0). If the Edge needs to be upgraded to a version that supports NFS, make sure both image partitions are updated so the Edge isn’t accidentally rebooted to a version that doesn’t support NFS mode. Once the required version of software is installed, the Edge needs to be configured to operate in NFS mode. To complete this task, you will need to enter the following commands using the CLI:

After the command is executed, the SteelFusion appliance reboots. Use the show service CLI command to verify the mode of the appliance.

If you have any concerns about performing this task, seek guidance by opening a case with Riverbed Support.

For a more detailed step-by-step guide, see this Knowledge Base article on the Riverbed support site:

Once the Edge is configured for NFS operations, it can be configured with the relevant storage settings.

This section contains the following topics:

You can continue to use the same or existing methodologies and tools to perform patch management on physical or virtual branch servers booted over the WAN using SteelFusion appliances.

If you want to perform virtual server patching at the data center and save a round-trip of patch software from the data center to the branch office, use the following procedure.

If the export was previously pinned at the edge, patching at the data center can potentially invalidate the cache. If this is the case, you might need to prepopulate the export.