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 logical unit numbers (LUNs) provisioned for the branch offices from a storage array, and manages block transfers between these LUNs and Edges. Additionally, SteelFusion Core-v can mount LUNs via Fibre Channel. At the data center, the Core integrates with existing storage systems and SteelHead implementations and connects dedicated LUNs with each Edge at the branch office.

• SteelFusion Edge - A standalone or high-availability Edge is deployed in the branch and presents the LUNs mounted on the Core at the branch through iSCSI targets. The Edge can also host local LUNs without a Core connection.

• LUN - A unique identifier associated with individual storage devices or collections of storage devices used with SCSI, iSCSI, or Fibre Channel interfaces.

• Branch server - The branch-side servers access data from the SteelFusion system 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 LUNs presented by the Edge. Blockstore also stores cached portions of the LUNs to quickly serve read requests.

The following diagram shows a typical SteelFusion deployment.

SteelFusion initially populates the blockstore using the following methods:

• First request - Blocks 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. Reactive prefetch and policy-based prefetch minimizes these first requests.

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

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

Blocks are transferred between Edges and Cores through an internal protocol. The Core then writes the updates to the data center LUNs through the iSCSI or Fibre Channel protocol. Optionally, you can further optimize traffic between the branch offices and the data center by implementing SteelHeads.

When the branch office server requests blocks, those blocks are served locally from the blockstore (unless they are not present, in which case the Edge retrieves them from the data center LUN via the Core). Similarly, newly written blocks 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 implementation is linked to one or more dedicated LUNs at the data center, the blockstore is authoritative for both reads and writes and can tolerate WAN outages without affecting cache coherency.

Riverbed strongly recommends 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.