Overview of SteelHead-v
This chapter provides an overview of SteelHead-v. It includes the following sections:
Product Dependencies and Compatibility
This section provides information about product dependencies and compatibility.
Third-Party Software Dependencies
This table summarizes the software requirements for SteelHead-v.
Component | Software Requirements |
Microsoft Hyper-V Hypervisor | SteelHead-v models VCX255 through VCX1555 support Hyper-V, available on Windows Server 2012 R2 and Windows Hyper-V Server. |
VMware ESX/ESXi Hypervisor | SteelHead-v supports ESX/ESXi 4.0, 4.1, 5.0, 5.1, and 5.5. If you use the Riverbed network interface card (NIC), you must use ESXi 4.1 or later. For ESXi 5.0 and later, the method for supporting the card differs from the 4.1 method. For information, see the section Completing the Preconfiguration Checklist. |
Linux Kernal-based Virtual Machine (KVM) Hypervisor | SteelHead-v has been tested on RHEL 7, CentOS 7, and Ubuntu 13.10 with virtio paravirtualized device drivers. |
SteelHead-v Management Console | Any computer that supports a web browser with a color image display. The Management Console has been tested with all versions of Chrome, Mozilla Firefox Extended Support Release version 38, and Microsoft Internet Explorer 11. The SteelCentral Controller for SteelHead has been tested with Mozilla Firefox Extended Support Release version 38 and Microsoft Internet Explorer 11. JavaScript and cookies must be enabled in your web browser. |
SNMP-Based Management Compatibility
This product supports a proprietary Riverbed MIB accessible through SNMP. SNMP1 (RFCs 1155, 1157, 1212, and 1215), SNMP2c (RFCs 1901, 2578, 2579, 2580, 3416, 3417, and 3418), and SNMP3 are supported, although some MIB items might only be accessible through SNMP2 and SNMP3.
SNMP support enables the product to be integrated into network management systems such as Hewlett-Packard OpenView Network Node Manager, BMC Patrol, and other SNMP-based network management tools.
SCC Compatibility
To manage SteelHead 9.2 appliances, you need to use SCC 9.2. Earlier versions of the SCC do not support 9.2 SteelHeads. For details about SCC compatibility across versions, see the SteelCentral Controller for SteelHead Installation Guide.
Understanding SteelHead-v
SteelHead-v is software that delivers the benefits of WAN optimization, similar to those offered by the SteelHead hardware, while also providing the flexibility of virtualization.
Built on the same RiOS technology as the SteelHead, SteelHead-v reduces bandwidth utilization and speeds up application delivery and performance. SteelHead-v on VMware vSphere is certified for the Cisco Service-Ready Engine (SRE) module with Cisco Services-Ready Engine Virtualization (Cisco SRE-V).
SteelHead-v runs on both the VMware vSphere and Microsoft Hyper-V hypervisors, installed on industry-standard hardware servers.
Figure: SteelHead-v and Hypervisor Architecture
SteelHead-v enables consolidation and high availability while providing most of the functionality of the physical SteelHead, with the following exceptions:
• Virtual Services Platform (VSP) or Riverbed Services Platform (RSP)
• Proxy File Service (PFS)
• Fail-to-wire (unless deployed with a Riverbed NIC card)
Note: Hyper-V does not currently support the Riverbed bypass NIC card.
• Hardware reports such as the Disk Status report
• Hardware-based alerts and notifications, such as a RAID alarm
You can integrate SteelHead-v into a wide range of networks. You can deploy SteelHead-v out-of-path, virtual in-path, or using the Discovery Agent. SteelHead-v supports both asymmetric route detection and connection forwarding features. You can make SteelHead-v highly available in active-active configurations, with data store synchronization as serial clusters.
After you license and obtain a serial number for SteelHead-v appliances, you can manage them across the enterprise from a Riverbed SteelCentral Controller for SteelHead (SCC) 8.0.0 or later.
SteelHead-v supports up to 24 virtual CPUs and 10 interfaces.
SteelHead-v Optimization
With SteelHead-v, you can solve a range of problems affecting WANs and application performance, including:
• Insufficient WAN bandwidth
• Inefficient transport protocols in high-latency environments
• Inefficient application protocols in high-latency environments
RiOS intercepts client-server connections without interfering with normal client-server interactions, file semantics, or protocols. All client requests are passed through to the server normally, while relevant traffic is optimized to improve performance.
The optimization techniques RiOS uses are:
• Data Streamlining - SteelHead products (SteelHead-v, SteelHeads, and SteelCentral Controller for SteelHead Mobile) can reduce WAN bandwidth utilization by 65 to 98 percent for TCP-based applications using data streamlining. In addition to traditional techniques like data compression, RiOS uses a Riverbed proprietary algorithm called Scalable Data Referencing (SDR). SDR breaks up TCP data streams into unique data chunks that are stored in the hard disk (data store) of the device running RiOS (a SteelHead or SteelCentral Controller for SteelHead Mobile host system). Each data chunk is assigned a unique integer label (reference) before it is sent to a peer RiOS device across the WAN. When the same byte sequence is seen again in future transmissions from clients or servers, the reference is sent across the WAN instead of the raw data chunk. The peer RiOS device (SteelHead-v software, SteelHead, or SteelCentral Controller for SteelHead Mobile host system) uses this reference to find the original data chunk in its data store and to reconstruct the original TCP data stream.
• Transport Streamlining - SteelHead-v uses a generic latency optimization technique called transport streamlining. Transport streamlining uses a set of standards and proprietary techniques to optimize TCP traffic between SteelHeads. These techniques:
– ensure that efficient retransmission methods, such as TCP selective acknowledgements, are used.
– negotiate optimal TCP window sizes to minimize the impact of latency on throughput.
– maximize throughput across a wide range of WAN links.
• Application Streamlining - In addition to data and transport streamlining optimizations, RiOS can apply application-specific optimizations for certain application protocols: for example, CIFS, MAPI, NFS, TDS, HTTP, and Oracle Forms.
• Management Streamlining - Management streamlining refers to the methods that Riverbed developed to simplify the deployment and management of RiOS devices. These methods include:
– Autodiscovery Process - Autodiscovery enables SteelHead-v, the SteelHead, and SteelCentral Controller for SteelHead Mobile to automatically find remote SteelHead installations and to optimize traffic using them. Autodiscovery relieves you from having to manually configure large amounts of network information. The autodiscovery process enables administrators to control and secure connections, specify which traffic is optimized, and specify peers for optimization.
Enhanced autodiscovery automatically discovers the last SteelHead in the network path of the TCP connection. In contrast, the original autodiscovery protocol automatically discovers the first SteelHead in the path. The difference is only seen in environments where there are three or more SteelHeads in the network path for connections to be optimized.
Enhanced autodiscovery works with SteelHeads running the original autodiscovery protocol, but it is not the default. When enhanced autodiscovery is enabled on a SteelHead that is peering with other appliances using the original autodiscovery method in a “mixed” environment, the determining factor for peering is whether the next SteelHead along the path uses original autodiscovery or enhanced autodiscovery (regardless of the setting on the first appliance).
If the next SteelHead along the path is using original autodiscovery, the peering terminates at that appliance (unless peering rules are configured to modify this behavior). Alternatively, if the SteelHead along the path is using enhanced autodiscovery, the enhanced probing for a peer continues a step further to the next appliance in the path. If probing reaches the final SteelHead in the path, that appliance becomes the peer.
– SteelCentral Controller - The SCC enables remote SteelHeads to be automatically configured and monitored. It also gives you a single view of the data reduction and health of the SteelHead network.
– SteelHead Mobile Controller - The Mobile Controller is the management appliance you use to track the individual health and performance of each deployed software client and to manage enterprise client licensing. The Mobile Controller enables you to see who is connected, view their data reduction statistics, and perform support operations such as resetting connections, pulling logs, and automatically generating traces for troubleshooting. You can perform all of these management tasks without end-user input.
SteelHead-v is typically deployed on a LAN, with communication between appliances occurring over a private WAN or VPN. Because optimization between SteelHeads typically occurs over a secure WAN, it is not necessary to configure company firewalls to support SteelHead-specific ports.
For detailed information about how SteelHead-v, the SteelHead, or SteelCentral Controller for SteelHead Mobile works and deployment design principles, see the SteelHead Deployment Guide.
Configuring Optimization
You configure optimization of traffic using the Management Console or the Riverbed CLI. You configure the traffic that SteelHead-v optimizes and specify the type of action it performs using:
• In-Path rules - In-path rules determine the action that a SteelHead-v takes when a connection is initiated, usually by a client. In-path rules are used only when a connection is initiated. Because connections are usually initiated by clients, in-path rules are configured for the initiating, or client-side, SteelHead-v. In-path rules determine SteelHead-v behavior with SYN packets. You configure one of the following types of in-path rule actions:
– Auto - Use the autodiscovery process to determine if a remote SteelHead is able to optimize the connection attempted by this SYN packet.
– Pass-through - Allow the SYN packet to pass through the SteelHead. No optimization is performed on the TCP connection initiated by this SYN packet.
– Fixed-Target - Skip the autodiscovery process and use a specified remote SteelHead as an optimization peer. Fixed-target rules require the input of at least one remote target SteelHead; an optional backup SteelHead might also be specified.
– Deny - Drop the SYN packet and send a message back to its source.
– Discard - Drop the SYN packet silently.
• Peering rules - Peering rules determine how a SteelHead-v reacts to a probe query. Peering rules are in ordered lists of fields that a SteelHead-v uses to match with incoming SYN packet fields—for example, source or destination subnet, IP address, VLAN, or TCP port—as well as the IP address of the probing SteelHead-v. This rule is useful in complex networks. Following are the types of peering rule actions:
– Pass - The receiving SteelHead does not respond to the probing SteelHead and allows the SYN+ probe packet to continue through the network.
– Accept - The receiving SteelHead responds to the probing SteelHead and becomes the remote-side SteelHead (the peer) for the optimized connection.
– Auto - If the receiving SteelHead is not using enhanced autodiscovery, Auto has the same effect as Accept. If enhanced autodiscovery is enabled, the SteelHead becomes the optimization peer only if it is the last SteelHead in the path to the server.
For detailed information about in-path and peering rules and how to configure them, see the SteelHead Management Console User’s Guide.