About autodiscovery

With enhanced automatic discovery, the SteelHead automatically finds the furthest SteelHead peer in a network and optimization occurs there. By default, enhanced autodiscovery is enabled. When enhanced autodiscovery is disabled, the SteelHead uses regular autodiscovery. With regular autodiscovery, the SteelHead finds the next appliance in the group and optimization occurs there.

In some deployments, enhanced autodiscovery can simplify configuration and make your deployments more scalable. When enhanced autodiscovery is enabled, the SteelHead automatically finds the furthest SteelHead in a network and optimization occurs there. For example, if you had a deployment with four SteelHeads (A, B, C, D), where D represents the appliance that is furthest from A, the SteelHead automatically finds D. This feature simplifies configuration and makes your deployment more scalable.

The Cloud Accelerator doesn’t use automatic peering. When you run a server in the cloud, you deploy the Cloud Accelerator to be the furthest SteelHead in the network because the Discovery Client on the server is configured to use the Cloud Accelerator automatically. When you run a client in the cloud, and there are multiple SteelHeads in the path to the server, the Cloud Accelerator is selected for optimization first. You can enable automatic peering on the remote SteelHeads to make the Cloud Accelerator peer with the furthest SteelHead in the network.

We recommend enhanced autodiscovery for the following kinds of deployments.

Serial Cascade Deployments. Cascade configurations enable optimal multisite deployments where connections between the client and the server might pass through intermediate SteelHeads to reach their final destination. Enhanced autodiscovery for cascading SteelHeads detects when more than two SteelHeads are present between the client and the server and automatically chooses the two outside SteelHeads, optimizing all traffic in between.

Serial Cluster Deployments. You can provide increased optimization by deploying two or more SteelHeads back-to-back in an in-path configuration to create a serial cluster. Appliances in a serial cluster process the peering rules you specify in a spill-over fashion. When the maximum number of TCP connections for a SteelHead is reached, that appliance stops intercepting new connections. This behavior allows the next SteelHead in the cluster the opportunity to intercept the new connection, if it has not reached its maximum number of connections. The in-path peering rules and in-path rules tell the SteelHead in a cluster not to intercept connections between themselves. You can deploy serial clusters on the client-side or server-side of the network.

For environments accelerating MAPI or FTP traffic which require all connections from a client to be accelerated by one appliance, we strongly recommend using the master and backup redundancy configuration instead of a serial cluster. For larger environments that require multiappliance scalability and high availability, we recommend using the Interceptor to build multiappliance clusters. For details, see the SteelHead Interceptor Deployment Guide and the SteelHead Interceptor User Guide.

A serial cluster has the same bandwidth specification as the SteelHead model deployed in the cluster. The bandwidth capability doesn’t increase because the cluster contains multiple SteelHeads. For example, a serial cluster that is made up of two SteelHead 570-M models with a bandwidth specification of 20 Mbps has a bandwidth specification of 20 Mbps.