Overview of Core and Edge as a System
This chapter describes the Core and Edge components as a virtual storage system. It includes the following sections:
Introducing branch converged infrastructure
SteelFusion is a converged infrastructure solution, encompassing all branch services such as server, storage, networking, and WAN optimization. It is a dual-ended system that comprises two logical components: SteelFusion Edge and SteelFusion Core. In a basic deployment scenario, the two components work together in a topology where a single Core appliance can support multiple Edge devices. As a dual-ended system, they can be deployed in one of two storage delivery modes, either operating with block storage as part of a Storage Area Network (SAN) or with Network Attached Storage (NAS) by using the Network File System (NFS) protocol. It is not possible to have the same Edge or Core operate with both storage modes.
Note: When configured in an NFS/file deployment, SteelFusion is designed to support VMware vSphere datastores only. SteelFusion is not providing generic NFS file server access or operating as a global fileshare. Not all Core and Edge models are able to support NFS/file mode. See the release notes for the latest information regarding supported models.
Core is a physical or virtual appliance in the data center that mounts all storage (LUNs within a SAN or exported NAS fileshares via NFS) from the backend storage array or file server that needs to be made available to applications and servers at a remote location. In the remote location, Edge provides a virtualized environment that hosts the branch application servers. Core appliances communicate across the WAN with the Edge appliances at the branch.
SteelFusion delivers local user performance while enabling data centralization, instant recovery, and lower total operating costs. Unlike traditional converged infrastructures, SteelFusion enables stateless branch services. You can access applications that run locally in your branch while the primary data is centralized in your data center. Decoupling computation from its underlying storage allows your applications to run in a stateless mode, which reduces your branch footprint and centralizes management of your branch services.
With the SteelFusion product family, data center administrators can extend data center storage to a remote location, even over a low-bandwidth link. SteelFusion delivers business agility, enabling you to effectively deliver global storage infrastructure anywhere you need it.
SteelFusion provides the following functionality:
• Innovative block storage optimization ensures that you can centrally manage data storage while keeping that data available to business operations in the branch, even in the event of a WAN outage.
• A local authoritative cache ensures LAN-speed reads and fast cold writes at the branch.
• Integration with Microsoft Volume Shadow Copy Service enables consistent point-in-time data snapshots and seamless integration with backup applications.
• Integration with the snapshot capabilities of the storage array enables you to configure application-consistent snapshots through the Core Management Console.
• Integration with industry-standard Challenge-Handshake Authentication Protocol (CHAP) authenticates users and hosts (iSCSI/block mode only).
• A secure vault protects sensitive information using AES 256-bit encryption.
• Solid-state disks (SSDs) that guarantee data durability and performance.
• An active-active high-availability (HA) deployment option for SteelFusion ensures the availability of storage from SAN or NAS for remote sites.
• Customizable reports provide visibility to key utilization, performance, and diagnostic information.
By consolidating all storage at the data center and creating diskless branches, SteelFusion eliminates data sprawl, costly data replication, and the risk of data loss at the branch office.
How the SteelFusion product family works
The SteelFusion product family is designed to simplify infrastructure in remote offices and branch offices and manage it centrally from a data center. SteelFusion can operate in either of two storage delivery modes. One mode uses 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. For details about how SteelFusion works within a deployment using NFS, see
SteelFusion and NFS. The SteelFusion product family is typically deployed in conjunction with SteelHeads and includes the following components:
• Core - Core is a physical or virtual appliance deployed in the data center alongside SteelHeads and the centralized storage array. Core mounts iSCSI LUNs (in iSCSI/block mode) or NFS exports (in NFS/file mode) provisioned for the branch offices. Additionally, Core-v can mount LUNs through Fibre Channel. When deployed in an NFS configuration, Core mounts fileshares that are exported from the centralized file server.
• 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, 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 or local exports 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 itself as an NFS file server enabling a VMware vSphere server in the branch to mount exported fileshares to be used as datastores.
Note: With SteelFusion version 5.0 and later, comes support for a Virtual Edge. However, it does not include a hypervisor platform itself. Virtual Edge is a software-defined edge solution that extends SteelFusion to third-party commodity hardware. For more information about Virtual Edge, see the Virtual SteelFusion Edge System Integrator’s Guide.
For a list of qualified software and storage systems, we strongly recommend that you read the
SteelFusion Interoperability Matrix at
https://splash.riverbed.com/docs/DOC-4204. For information on compatibility between SteelHead software (RiOS), Edge, Core, and vSphere releases, see the Riverbed Knowledge Base article
RiOS, SteelFusion Edge, SteelFusion Core and vSphere Release Matrix at https://supportkb.riverbed.com/support/index?page=content&id=S27472.
The Edge connects to the blockstore, a persistent local cache of storage blocks located inside the Edge itself.
SteelFusion initially populates the blockstore using the following methods:
• First request - Data is added to the blockstore when first requested. Because the first request is cold, it is subject to standard WAN latency. Subsequent traffic is optimized.
• On-demand prefetch - The system observes block requests, applies heuristics based on these observations to intelligently predict 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 blocks that are 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.
For details on blockstore population, see
Blockstore prefetch and prepopulation.
System components and their roles
Figure: Generic SteelFusion block storage deployment shows the various components in a basic SteelFusion iSCSI/block/Fibre Channel deployment. The generic SteelFusion NFS/file deployment is shown in
Figure: Generic SteelFusion NFS/file deployment.
Figure: Generic SteelFusion block storage deployment

Figure: Generic SteelFusion NFS/file deployment

• Branch server - One or more branch-side servers that access data from the SteelFusion system instead of a local storage device. These servers can also run as virtual machines (VMs) within the Edge hypervisor node.
• iSCSI initiator (iSCSI/block mode only) - The branch-side server that sends SCSI commands to its iSCSI target that is the Edge in the branch. At the data center, the Core is an iSCSI initiator that sends SCSI commands to access LUNs through an iSCSI target in the storage array.
• NFS client - One or more branch-side VMware hypervisors that use NFS to mount exported datastores from the NFS file server (the Edge in the branch). The VMware hypervisor located within the Edge hypervisor node can also act as an NFS client to mount its ESXi datastore. At the data center, the Core is an NFS client that uses NFS to access fileshares exported by the NFS file server in the data center.
• Edge - The branch-side component of the SteelFusion system that links the blockstore through the Core to the storage (LUN or fileshare, depending on the deployment scenario) at the data center. The Edge also includes SteelHead functionality to provide WAN optimization services.
• Data center SteelHead - The data center-side SteelHead peer for WAN optimization.
• Core - The data center component of the SteelFusion product family. The Core manages block transfers between the LUN and the Edge when deployed as part of a block storage implementation. When deployed in an NFS/file scenario, the Core manages NFS transfers between the exported fileshare and the Edge.
• iSCSI target (iSCSI/block mode only) - In the branch office, it’s the Edge that communicates with the branch-side iSCSI initiator in the branch server. In the data center, it’s the storage array that communicates with the Core iSCSI initiator.
• LUN (iSCSI/block mode only) - A unit of block storage deployed from the storage array and projected through the Core to the Edge. More than one LUN can be projected to an Edge.
• NFS file server - In the branch office, it’s the Edge that communicates with the branch-side NFS client in the branch VMware hypervisor. In the data center, it’s the file server that communicates with the Core NFS client.
• Fileshare - A unit of NFS storage that is exported from the NFS file server and projected through the Core to the Edge. More than one fileshare export can be projected to an Edge.
At the data center, Core integrates with existing storage systems, virtual infrastructure, and SteelHead deployments. Depending on the deployment (block storage or NFS), Core connects dedicated LUNs or fileshare exports with each Edge appliance at the branch office.
The branch office server connects to Edge, which implements handlers for the iSCSI protocol in a block storage deployment, or requests for the NFS protocol in an NFS/file deployment. The Edge also connects to the blockstore, a persistent local cache of storage blocks within the Edge itself.
The blockstore is the Edge authoritative persistent cache of storage blocks. The blockstore is local from a branch perspective and holds data from all the LUNs or exported fileshares (depending on the deployment mode) available through a specific Edge. The blockstore is authoritative because it includes the latest-written data before it is sent through the Core to a storage array or file server at the data center. When a server at the branch office requests data, that data is served locally from the blockstore if the data is currently present. If it is not present, the Edge retrieves it through the Core from the data center LUN or exported fileshare. Similarly, newly written data is spooled to the local blockstore, 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 or exported fileshares at the data center, the blockstore is authoritative for both reads and writes and can tolerate WAN outages without affecting cache coherency.
Blocks are transferred between the Edge and the Core through an internal protocol. The Core then writes the updates to the data center LUNs through the iSCSI or Fibre Channel Protocol (FCP). The same internal protocol is used to transfer NFS data between Edge and Core where the Core then writes the updates to the fileshares exported from the data center fileserver using the NFS protocol. SteelFusion is designed to be coupled with the SteelHead WAN optimization. You can further optimize traffic between the branch offices and the data center by implementing SteelHeads.
For more information about Fibre Channel, see
SteelFusion and Fibre Channel. For more information about NFS/file deployments, see
SteelFusion and NFS. The data cache in the blockstore is stored as-is, and it is not deduplicated. Edge appliances include the SteelHead, and in the data center, the Cores are coupled with SteelHead products, which assist with data reduction and streamlining between the Edge and the Core.
You can encrypt the blockstore cache at rest using AES 128/192/256-bit encryption. This encryption eliminates the risk if your appliances are stolen. Similarly, because SteelFusion enables the removal of physical tape media and backup devices traditionally used for data protection from the remote offices, this encryption also eliminates risk of data theft. As a result, the blockstore eliminates the need for separate block storage facilities at the branch office and all the associated maintenance, tools, backup services, hardware, service resources, and so on.
For more information about blockstore encryption, see
At-rest and in-flight data security.
Blockstore prefetch and prepopulation
One of the drawbacks of block storage protocols like iSCSI or Fibre Channel communicating across a wide area network (WAN) is that the subsequent requests for further data blocks may be non-sequential to the point that they seem random. This randomness is by design and a facet of the backend storage, but it makes rapid data delivery across a WAN using a block storage protocol difficult due to the high-latency adding a long turnaround time between request and response.
One way to mitigate this effect is for the sending side to be able to predict in some way what the subsequent requests will be so that data can be sent without waiting for the request. However, this is not possible with traditional storage protocols.
The SteelFusion architecture is appropriate for this type of approach because data on the Edge is held locally in the blockstore. Blockstore is the persistent local cache of storage blocks linked to one or more dedicated LUNs at the data center. As long as the data blocks that the Edge wants to read are already in blockstore, no request needs to be transmitted across the WAN through the Core to backend storage. Instead, the Edge responds to the read request serving data at local disk speed. Since the Edge blockstore benefits from a three-tier architecture of memory, solid-state disk (SSD), and hard disk drive (HDD), the read response is faster than could be achieved by storage in traditional branch servers. But if the required data is not in blockstore (called a blockstore miss), the Edge requests the data from the backend storage by asking the Core. The Core understands specific blockstore formats and can send the requested data and also continue to proactively send across additional blocks of data to the blockstore that it predicts the Edge may need. If the prediction is successful, the Edge will then find the subsequent data it needs locally in the blockstore and therefore does not need to submit further requests to the Core.
Depending on the scenario, populating the Edge blockstore can be performed by one or more of these methods:
• Prefetch - The act of pushing data out from the Core in response to a blockstore miss at the Edge. Not only does the Core push out the requested blocks, it also sends across additional blocks that it predicts may be required by the Edge on subsequent reads. Note that prefetch is reactive (or, on-demand) in that it operates in response to the Edge. Intelligence within the Core means that prefetch works well with LUNs that are either VMFS or NTFS format, or Windows VMs on NFS.
Note: For prefetch of NFS exports with Windows VMs, you must install the Riverbed Turbo Boot Plugin. For details, see
Riverbed Turbo Boot.
• Policy-based prefetch - Not a specific prefetch technique, but a term used to describe a selection of different “proactive” methods designed to populate the Edge blockstore. These methods are all types of prepopulation.
• Prepopulation - Sometimes referred to as full prepopulation. Designed to be used for pinned LUNs or exports. Prepopulation is the act of proactively sending data without a request from the Edge. This method is used for any type of pinned LUN or export, and is very beneficial for LUNs that are not VMFS or NTFS format (for example, FAT32, ext3, ext4) and NFS exports with non-Windows VMs.
Note: Prepopulation does not work with unpinned LUNs or exports. Unpinned LUNs or exports are populated dynamically (incorporating prefetch) as the Edge begins using them.
• Branch recovery (iSCSI/block mode only) - A type of prepopulation that enables the Core to proactively send across the working set of data blocks. This feature only applies to NTFS or VMFS LUNs and uses a service called the Branch Recovery Agent. For more information about this feature, see
Branch recovery.
• Smart prepopulation (iSCSI/block mode only) - Sometimes referred to as intelligent prepopulation. A type of prepopulation where the Core proactively sends all used blocks in a volume with no regards to the working set blocks. Smart prepopulation is only required if your pinned LUN is VMFS or NTFS.
For more information about how to enable or configure the different types of prepopulation, see the SteelFusion Command-Line Interface Reference Manual.
Related information
• SteelFusion Core Management Console User’s Guide
• SteelFusion Edge Management Console User’s Guide