How SteelFusion works

SteelFusion enables branch office server systems to efficiently access storage arrays over the WAN. It is typically deployed in conjunction with SteelHeads and is composed of the following components:

• SteelFusion Core - A physical or virtual Core is deployed in the data center alongside SteelHeads and a storage array. The Core mounts NFS exports provisioned for the branch offices from a backend NAS storage array and manages transfers between these NFS exports and Edges. At the data center, the Core integrates with existing storage systems and SteelHead implementations and connects dedicated NFS exports with each Edge at the branch office.

• SteelFusion Edge - A standalone or high-availability Edge is deployed in the branch and presents the NFS exports mounted on the Core at the branch.

• NFS export - A unique identifier associated with file systems or directories located on a backend storage array that are accessible to the Core. NFS exports are mounted on the Core and then mapped to the Edge at the branch. When the Core is running in NFS/file mode, it uses the NFS protocol to talk to the storage array and presents exports to the branches. The terms NFS mode and file mode can be used interchangeably.

• Branch server - The branch-side servers access NFS exports from the Edge(s) at the branch instead of a local storage device. This server can also run as a Virtual Services Platform (VSP) VM on the local Edge.

• Blockstore - A persistent and authoritative local cache of storage blocks on the Edge that caches the writes on NFS exports presented by the Edge. Blockstore also stores cached portions of the NFS exports to quickly serve read requests.

This diagram shows a typical SteelFusion deployment.

SteelFusion initially populates the blockstore using the following methods:

• First request - Files are added to the blockstore when first requested. The first request is subject to standard WAN latency because it is the first time the blocks are being served. Subsequent traffic is optimized. On-demand prefetch and policy-based prefetch minimizes these first requests.

• On-demand prefetch - The Core observes file requests, intelligently predicts the files most likely to be requested in the near future, and then requests those files from the data center NFS export in advance.

• Policy-based prefetch - Configured policies identify the files that are likely to be requested at a given branch office site in advance. The Edge then requests those files from the data center export in advance.

Files are transferred between Edges and Cores through an internal protocol. The Core then writes the updates to the data center exports through the NFS protocol. Optionally, you can further optimize traffic between the branch offices and the data center by implementing SteelHeads.

When the branch office server requests files, they are served locally from the blockstore (unless they are not present, in which case the Edge retrieves them from the data center export via the Core). Similarly, newly written files are spooled to the local cache, acknowledged by the Edge to the branch office server, and then asynchronously propagated to the data center. Because each Edge is linked to one or more dedicated exports at the data center, the blockstore is authoritative for both reads and writes and can tolerate WAN outages without affecting cache coherency.

We strongly recommend that you read the SteelFusion Interoperability Matrix at https://splash.riverbed.com/docs/DOC-4204.

For information on compatibility between RiOS, Edge, Core, and vSphere releases, see the Knowledge Base article RiOS, SteelFusion Edge, SteelFusion Core and vSphere Release Matrix at https://supportkb.riverbed.com/support/index?page=content&id=S:S27472.