Overview of SteelFusion Core : How SteelFusion works
  
How SteelFusion works
The SteelFusion product family simplifies infrastructure in remote offices and branch offices, and you manage it centrally from a data center. SteelFusion can operate in either of two storage delivery modes. One mode utilizes iSCSI or Fibre Channel protocols to interface with block storage arrays in the data center and iSCSI to host servers at the branch office; the other mode uses the NFS protocol to interface with file servers at the data center and host servers at the branch. The SteelFusion product family is typically deployed in conjunction with SteelHeads and is composed of the following:
•  SteelFusion Core - A physical or virtual Core is deployed in the data center alongside SteelHeads and a storage array. The Core mounts LUNs (in iSCSI mode) or exports (in NFS mode) provisioned for the branch offices from a storage array and manages transfers between this storage and the Edges. Additionally, in iSCSI mode SteelFusion Core-v can mount LUNs via Fibre Channel. When deployed in an NFS configuration, Core mounts exports from the centralized file server.
Note: NFS/file mode is only supported on the physical Core model 3500 and the virtual Core-v model VGC-1500.
•  SteelFusion Edge - Edge refers to the branch component of the SteelFusion solution. The Edge hosts two distinct functions, or nodes:
–  WAN optimization
–  Hypervisor platform with VMware vSphere
When deployed in an iSCSI configuration, the Edge presents itself to application servers in the branch as an iSCSI storage portal. From the portal, the application server uses iSCSI to mount the iSCSI LUNs that are projected across the WAN from the data center. Edge can also host local LUNs for use as temporary storage that are not projected from the data center: for example, temporary or local copies of software repositories.
When deployed in an NFS configuration, Edge presents NFS version 3 storage exports projected from the data center as local exports to applications and servers at the local branch.
•  LUN (iSCSI mode only) - A unique identifier associated with individual storage devices or collections of storage devices used with SCSI, iSCSI, or Fibre Channel interfaces.
•  Export (NFS/file mode only) - 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 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 on the Edge that caches the writes on LUNs/exports presented by the Edge. Blockstore also stores cached portions of the LUNs/exports to quickly serve read requests.
Figure: Typical SteelFusion deployment - iSCSI/block mode
Figure: Typical SteelFusion deployment - NFS/file mode
SteelFusion initially populates the blockstore using these methods:
•  First request - Data is added to the blockstore when first requested. The first request is subject to standard WAN latency because it is the first time the data is being served. Subsequent traffic is optimized. Reactive prefetch and policy-based prefetch minimizes these first requests.
•  On-demand prefetch - Core observes block requests, intelligently predicts the data most likely to be requested in the near future, and then requests that data from the data center LUN/export in advance.
•  Policy-based prefetch - Configured policies identify the data that is likely to be requested at a given branch office site in advance. The Edge then requests that data from the data center LUN/export in advance.
Data is transferred between Edges and Cores through an internal protocol. Core then writes the updates to the data center storage with the appropriate protocol. Optionally, you can further optimize traffic between the branch offices and the data center by implementing SteelHeads.
When the branch office server requests data, that data is served locally from the blockstore (unless it is not present, in which case Edge retrieves the data from the data center LUN/export via Core). Similarly, newly written data is spooled to the local cache, acknowledged by 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/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.