This chapter describes the Core and Edge components as a virtual storage system. It includes the following sections:

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 are deployed with Network Attached Storage (NAS) by using the Network File System (NFS) protocol.

Core is a physical or virtual appliance in the data center that mounts all storage (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:

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.

The SteelFusion implementation uses NFSv3 over TCP. In the branch office, SteelFusion Edge supports the export of NFS fileshares to external ESXi servers where they can be used as datastores. SteelFusion Edge also supports the export of fileshares to the ESXi server that is hosted inside the hypervisor node of the SteelFusion Edge.

Figure: Use of NFS protocol shows a basic deployment diagram, including an external ESXi server in the branch, indicating the protocols in use.

To accommodate the NFS capability within SteelFusion, the use of some network interfaces in Core and Edge may differ from that used in a block storage deployment. Therefore, care must be taken to ensure the correct assignments and configuration settings are made. For details, see Core interface and port configuration and Edge interface and port configurations.

Although the majority of existing SteelFusion features available in a block storage deployment are also available with an NFS/file deployment, there are a few items that are not currently supported. For details, see Existing SteelFusion features available with NFS/file deployments and Unsupported SteelFusion features in NFS deployments.

It is important to note that a SteelFusion NFS deployment is separate from a block storage (iSCSI, Fibre Channel) installation. The two deployment modes (block storage and NFS) cannot be combined within the same SteelFusion appliance (SteelFusion Core or SteelFusion Edge).

With SteelFusion in an NFS/file deployment, the following features are supported:

In addition to these features, SteelFusion with NFS has been qualified with the following storage systems for both the data path and snapshot integration:

This backup software is qualified:

The following SteelFusion Core models support NFS/file deployments:

With SteelFusion in an NFS/file deployment, the following features from previous versions are not currently supported or available:

SteelHead EX does not support NFS/file deployments.

The following SteelFusion Core models do not support NFS/file deployments:

 

The SteelFusion product family is designed to simplify infrastructure in remote offices and branch offices and manage it centrally from a data center. In NFS mode, the NFS protocol is used 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 includes the following components:

For a list of qualified software and storage systems, we strongly recommend that you read the SteelFusion Interoperability Matrix at https://support.riverbed.com/bin/support/download?did=ccm3j58psj432nf6ui8kvejjt7. Ensure that you select the version of the guide that corresponds with your SteelFusion software release.

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:

For details on blockstore population, see Blockstore prefetch and prepopulation.

Figure: Generic SteelFusion block storage deployment shows the various components in a basic SteelFusion deployment.

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 requests for the NFS protocol. 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 exported fileshares 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 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 fileshares exported from the data center file server 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.

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.

One of the drawbacks of storage protocols like NFS, iSCSI, or Fibre Channel communicating across a wide area network (WAN) is that the subsequent requests for further data may be nonsequential 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 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:

For more information about how to enable or configure the different types of prepopulation, see the SteelFusion Command-Line Interface Reference Manual.