This section describes how to deploy two or more Client Accelerator Controllers in a redundant configuration. This section requires that you be familiar with multiple Client Accelerator Controller deployments.

Figure: Two active Client Accelerators shows Client Accelerator A and Client Accelerator B installed in the data center and configured with a basic setup. You can install Client Accelerators in different data centers and continue to provide redundancy.

Complete the following steps on both of the Client Accelerators.

Perform this task to configure two Client Accelerators for redundancy:

You can repeat these steps to add additional Client Accelerators to the redundant configuration later. In each case, add the hostname or IP address of the additional Client Accelerators to the Endpoint Settings in the relevant policy on all the Client Accelerators in the redundant configuration.

To avoid clients receiving an untrusted certificate message, multiple Client Accelerator Controllers in a redundant configuration must have the same Certificate Authority (CA) certificates.

This section describes how to prepare two or more Client Accelerators to form a Client Accelerator high-availability cluster. Client Accelerator clusters work together as a single entity with respect to client policies and some elements of the reporting. You can administer the Client Accelerator cluster from any member of the cluster.

Any client policy that you update on any cluster member automatically replicates and synchronizes with the other members of the cluster. Conflicts in which the same policy is inadvertently edited at the same time on different cluster members resolve automatically. Policies, packages, and some reporting statistics are automatically passed among cluster members. By default, this communication is through a TCP connection on port 7870.

Before a Client Accelerator can join a cluster, the Client Accelerator must:

No geographic or latency restrictions exist between the nodes of a Client Accelerator cluster, because the Client Accelerators in a cluster use the same protocol that a Client Accelerator uses with a Client Accelerator. Typically, the current connection between the Client Accelerator and the Client Accelerators supports round-trip times in excess of 3 seconds.

After a Client Accelerator successfully joins the cluster, it is automatically populated with the packages, policies, and other client-related settings from the existing members of the cluster, and any existing settings are deleted. If you want to retain a copy of the original settings, make sure that you back up the Client Accelerator configuration before joining it to an existing cluster. You do not need to configure existing cluster members for a new Client Accelerator to join.

To set up a cluster, make sure that all Client Accelerators meet the requirements listed above, choose one Client Accelerator to start with, and join the remaining Client Accelerators to the cluster one-by-one.

An HA cluster provides the ability to survive the failure of an individual Client Accelerator and potentially multiple Client Accelerator failures if you have a configuration that supports this (for example, the number of cluster members is greater than two).

Clustering also enables scalability for the number of supported endpoints. When multiple Client Accelerators are joined together to form an HA cluster, the endpoint licenses that each Client Accelerator instance had prior to joining are put into a license pool. The license pool is available for all cluster members to use.

In a cluster that comprises a mixture of different Client Accelerator platforms, make sure that surviving cluster members can sustain the total number of endpoint licenses in the pool.

As a result of ongoing development and enhancements, this information is always subject to change. We recommend that you contact your Riverbed account team if you have a need to extend beyond these limits.

There are many different scenarios related to HA clusters and endpoint licensing. To have a successful deployment, you must understand how these endpoint licenses move in and out of the pool.

Every cluster member must have some number of endpoint licenses before it joins the cluster. Generally, a new Client Accelerator has a number of endpoint licenses included by default. The actual quantity of default endpoint licenses depends on the model of the Client Accelerator. Additional endpoint licenses are supplied in packs, with each pack containing 10 licenses. For example, to add 100 licenses to a Client Accelerator, you purchase ten packs. When a Client Accelerator joins a cluster, it gives licenses to the pool if it has more than 100 licenses (this is the default setting).

For example, if a Client Accelerator has 130 licenses when it joins the cluster, it gives 30 licenses to the pool and keeps 100 licenses. If a Client Accelerator has 60 licenses, it does not give any licenses to the pool when it joins the cluster. Giving licenses to the pool is known as check in.

You can change the default of how many licenses the Client Accelerator keeps initially with the following command on the Client Accelerator CLI:

For example:

This command changes the default of licenses kept from 100 to 50. In that, when a Client Accelerator Controller joins a cluster for the first time, if it has more than 50 endpoint licenses, it checks in the excess to the pool.

A Client Accelerator cluster member assigns a license from the cluster pool to a Client Accelerator client when the client requests one.

When the license count of a Client Accelerator drops below a certain threshold, the Client Accelerator takes more licenses from the pool. Taking licenses from the pool is known as check out. If there are no licenses in the pool, the Client Accelerator continues to assign licenses on request until it either runs out of licenses or the pool is populated with more available licenses.

If there are no more licenses for the Client Accelerator and there are no licenses in the pool, the Client Accelerator client automatically contacts another Client Accelerator for a license (assuming the client is configured with multiple Client Accelerators). If the other Client Accelerators do not have an available license, the Client Accelerator client passes through connections while continuing to request a license at 10-second intervals. After a license is issued, any new connections are accelerated.

There are a number of threshold settings related to license check out and check in.

When a Client Accelerator takes licenses from the pool, by default it checks out up to 100 licenses. You can change the default value with the following command on the Client Accelerator CLI:

For example:

This command changes the default threshold from 100 to 40. In that, when a Client Accelerator reaches its low threshold value, it checks out 40 more licenses.

If the pool contains fewer licenses than the value for checkout-count, then the Client Accelerator takes all the remaining licenses, leaving the pool empty.

After a Client Accelerator has joined a cluster, checking in its excess licenses to the pool, it also detects how many licenses it has kept.

You can configure the Client Accelerator with two thresholds associated with the license usage. The high threshold is when a Client Accelerator has assigned most of its licenses (in other words, license usage is high) and needs to check out more licenses from the pool.

The low threshold is when the number of assigned licenses drops (in other words, license usage is low). When a client machine running the Client Accelerator client goes offline for a while (shuts down, hibernates, disconnects from the network, and so on) the Client Accelerator that assigned the license to the client marks the license as available for another request. When the number of assigned licenses in the Client Accelerator drops beneath the low-threshold value, the Client Accelerator Controller has an excess of available licenses and checks in excess licenses to the pool.

The high-threshold and low-threshold values are expressed as a percentage. These two values are by default 90 and 70 respectively. You can change the default value with the following command on the Client Accelerator CLI:

and

For example:

This command changes the default value from 90% to 80%. In that, when a Client Accelerator has assigned 80% of its initial count of licenses, it checks out more licenses from the pool as specified by the checkout-count value.

One of the benefits of using multiple Client Accelerators in a cluster rather than having them as individual (autonomous) instances is that you can pool the licenses in such a way that they remain available with one surviving member in the cluster.

When a Client Accelerator fails as part of a cluster, any licenses that it has are automatically placed in the pool and can be used by surviving Client Accelerators in the cluster.

When the failed Client Accelerator recovers, it automatically checks out licenses.

Individual Client Accelerators that are part of an HA cluster share the same Client Accelerator group assignments, policies, packages and other general configuration details. This information is sent to a new cluster member at the time of joining the cluster. During the lifetime of the cluster, any changes or additions to deployment configuration data that are completed on one of the cluster members is automatically communicated to the other cluster members. Likewise, the data associated with endpoint reports is also communicated between the cluster members.

As a new cluster member joins, there can be a comparatively large amount (10s of MB) of information sent from an existing member to the new member. There is no real time limit for this transfer to complete, but if the link between the members is low bandwidth and high latency (for example, a WAN link, then the initial transfer can take some time. The new member only transitions to the Connected, Synced status after the transfer has completed. When this status is reached, the member is fully operational within the cluster.

The cluster members use a persistent connection on TCP port 7870 to send the configuration and report data. This port is the same TCP port that is used by Client Accelerator to communicate with the Client Accelerator.

After the cluster members are all in sync, any configuration changes to one member are automatically broadcast to the other members. Even if there is no change, there is a poll every 5 minutes between random pairs of cluster members to compare the configuration between the pair. This ensures that any changes that have been missed are properly synced.

Client Accelerators and Client Accelerator clients use the following TCP ports to communicate with each other:

This section describes some of the communication between Client Accelerator clients and the Client Accelerator. .

A client machine with the Client Accelerator client software installed and enabled begins accelerating traffic after it has completed some initial interaction with a Client Accelerator. This initial contact with the Client Accelerator is triggered by the Client Accelerator client when it intercepts the first connection that is to be accelerated.

The Client Accelerator begins by contacting a Client Accelerator that is already included on the list of controllers defined in the policy of the client. In a small deployment, there is probably only one Client Accelerator on the list. In a larger deployment, there might be more than one Client Accelerator. In such a case, the first Client Accelerator contacted is either the one at the top of the list (depending on the endpoint settings in the policy) or one that is chosen at random.

Contact is made through a TCP connection on port 7870. If there are no problems, the Client Accelerator issues a license. If the Client Accelerator does not have a license available, it instructs the client to contact the next Client Accelerator on its list. The Client Accelerator client continues through its list of Client Accelerators, contacting each one in turn, until it receives a license. If no licenses are available, the client continues to try and contact Client Accelerators every 20 seconds until it receives a license. After a license has been issued, the Client Accelerator client can continue to accelerate any new connections that it intercepts that match relevant in-path rules in the client policy.

During this initial interaction after a license has been issued, the Client Accelerator takes the opportunity to check the policy that the client already has, and if a newer one exists, the controller automatically downloads it to the client. If a newer policy is downloaded, it takes immediate effect.

The Client Accelerator also checks the current version of the Client Accelerator client software, and if a newer version is available for the client, it might prompt the client to update its software. This step can occur differently depending on the way you have configured the endpoint settings for the client policy: for example, if you have a manual update process.

The connection on TCP port 7870 to the Client Accelerator from the Client Accelerator client is kept open to allow the client to send updates for reporting purposes (for example, accelerated connections, data reduction, and so on). These updates are typically sent every 5 minutes.

If the end user logs off the client machine but there are still accelerated connections in the background, the Client Accelerator client remains licensed and the connections continue to be accelerated.

The Client Accelerator releases the client license under one of the following circumstances:

In this last case, the client instantly requests a license once more if a new connection is intercepted for acceleration.

Location awareness enables the Client Accelerator client to enter branch mode and may use branch warming.

Location awareness enables Client Accelerators to detect that they are in a branch office with a SteelHead, and it enables the branch office SteelHead to accelerate the traffic of Client Accelerator clients.

When a Client Accelerator client is at a branch office that has a SteelHead, location awareness enables you to choose which device performs acceleration. If the Client Accelerator performs acceleration and is not in branch mode, the Client Accelerator warms its local RiOS data store. It also consumes a Client Accelerator license.

If a branch office and data center have a SteelHead, the Client Accelerator client can use location awareness to put the client into branch mode. In branch mode you can use the branch office SteelHead for acceleration so that the end user does not consume a Client Accelerator license. But in that case, the Client Accelerator does not warm its local RiOS data store. Branch warming enhances location awareness by warming the Client Accelerator RiOS data store. By default, branch warming is disabled.

You can configure location awareness in the following ways:

This section describes how branch warming on the Client Accelerator interacts with the SteelHeads in the branch office and the data center.

Branch warming works in conjunction with location awareness, enabling the Client Accelerator user to experience warm acceleration regardless of the location. Branch warming tracks the data segments created while a Client Accelerator is in a SteelHead-enabled branch office. Location awareness enables Client Accelerator to detect that it is in a branch office with a SteelHead, and it enables the SteelHead to accelerate Client Accelerator traffic.

When you enable branch warming, Client Accelerator and the SteelHead cooperate to provide warm data for out-of-branch use. Client Accelerator shares segments with the SteelHead, thereby providing warm data wherever possible. Branch warming populates new data transfers that are occurring between the client and server, placing them into the RiOS data stores of Client Accelerator, the branch office SteelHead, and the server-side SteelHead.

When you download data from the server, the server-side SteelHead checks to see if either Client Accelerator or the branch office SteelHead has the data in its RiOS data store. If either device already has the data segments, the server-side SteelHead sends only references to the data. Client Accelerator and the branch office SteelHead communicate with each other to resolve the references.

Other clients at the branch office also benefit from branch warming, because data transferred by one client at a branch office populates the branch office SteelHead RiOS data store. Performance improves for all clients at the branch office because they receive warm performance for that data.

Figure: Branch warming example shows how branch warming enables mobile users to accelerate traffic with the server-side SteelHead, while feeding segments that these users generate into the branch office SteelHead RiOS data store.

For each data request, the server-side SteelHead checks whether the branch office SteelHead or the Client Accelerator RiOS data store making the request already has the data. If either one has the data, the SteelHead sends a reference to the Client Accelerator.

After the Client Accelerator gets the reference, it checks if its RiOS data store already has the reference. If it does, the Client Accelerator communicates with the server-side SteelHead that it need not send the data again. Simultaneously, the Client Accelerator checks whether the branch office SteelHead has the same reference. If the branch office SteelHead has the reference, the communication concludes; otherwise, the Client Accelerator shares the reference and data with it.

If the Client Accelerator does not have the reference or if its RiOS data store is deleted, it checks with the branch office SteelHead to determine if it has the reference. If it does, then the Client Accelerator takes the data segments from the branch-side SteelHead and communicates with the server-side SteelHead that it need not send the data again.

However, if the branch office SteelHead does not have the reference, the Client Accelerator requests the new data from the server-side SteelHead and shares the new data and reference with the branch office SteelHead so that at the end this communication, all three—the server-side SteelHead, the branch office SteelHead, and the Client Accelerator—have the reference.

A Client Accelerator with branch warming enabled, inside a branch office using the branch SteelHead, uses one connection on the server-side SteelHead and one connection on the branch office SteelHead. It does not use a Client Accelerator license when in the branch mode.
A single Client Accelerator license allows an unlimited number of connections.

The Client Accelerator uses a license only when it detects that the SteelHead with which it has accelerated connections is not in branch mode.

Enable enhanced autodiscovery on all SteelHeads to ensure that branch warming is successful. By default, enhanced autodiscovery is enabled.

With enhanced autodiscovery enabled, the last SteelHead along the network path from the client to the server is automatically detected. Acceleration then occurs between the Client Accelerator and the last SteelHead.

You can display, add, and modify enhanced autodiscovery settings on a SteelHead in the Optimization > Network Services: Peering Rules page.

Typically in a web-based application, the client authenticates the server. You install an SSL certificate on a web server for the client to check the credentials of the certificate to make sure it is valid and signed by a trusted third party. Trusted third parties that sign SSL certificates are called CA certificates.

Client Accelerator supports both traditional SteelHead SSL optimization and advanced high-security SSL optimization. We recommend that you use advanced high-security SSL optimization to protect your system.

In traditional SteelHead SSL optimization with a Client Accelerator, a client-side SteelHead and the Client Accelerator can accelerate traffic from any client.

In traditional SSL optimization, the client-side SteelHead runs on the client machine. An attacker can redirect network traffic to their Client Accelerator-enabled system and obtain the client session key sent from the server-side SteelHead, thereby decrypting the client traffic.

To prevent such man-in-the-middle attacks, and to ensure that Client Accelerator can decrypt traffic originating on only one machine, Client Accelerator provides advanced high-security SSL optimization.

This section provides an overview of advanced high-security SSL optimization. We recommend that you use advanced high-security SSL optimization to protect your system.

Advanced SSL optimization:

Figure: Advanced high-security SSL optimization using a Client Accelerator shows the steps in the advanced high-security SSL optimization using Client Accelerator. The steps are as follows:

Client Accelerator takes the CN and uses the CA certificate it injected to generate a signed server certificate that it passes to the application. The application can trust this certificate because it is signed by the CA that exists in its trusted certificates list.

This section provides an overview of the basic steps required to configure SSL.

With Client Accelerator, the client can continue to provide SSL optimization in deployments in which you use SSL proxy devices.

When you configure this option with the Management Console, use the setting in the SSL section of the policy page. When configuring the policy using the CLI on the Client Accelerator Controller, use the following command:

By default, after you have completed the steps in Configuring Client Accelerator and SSL, the Client Accelerator client supports SSL connections that use TLS 1.0.

Client Accelerator 6.3.0 supports TLS 1.1 or 1.2. You must enable this capability using the following CLI command on the Client Accelerator:

Even though TLS 1.1 is not mentioned in the syntax of this command, using this command automatically enables support for both TLS 1.1 and 1.2.

You must make sure that the server-side SteelHead is configured to support TLS 1.2 by using the following commands on the SteelHead CLI:

An SSL configuration requires there be a trust relationship between the Client Accelerator and Client Accelerator. Without this trust relationship, the Client Accelerator cannot connect to and provide the Client Accelerator with configuration details.

Client Accelerators in a redundant deployment or a high-availability cluster must have identical signing CA certificates. Having identical signing CA certificates is a prerequisite for a Client Accelerator to join a cluster with other Client Accelerators. Client Accelerators generate their own certificates. If the Client Accelerators do not have the identical signing CA certificates, the Client Accelerator clients receive an untrusted certificate message.

This section lists best practices and includes other factors to consider when deploying Client Accelerator.

Consider the following types of deployment scenarios. Figure: Same SteelHead for mobile employees and office employees shows the same SteelHead for office and mobile employees—use fixed-target rules if the VPN ingress point is different.

Figure: Using one SteelHead for mobile employees and one SteelHead for office employees shows one SteelHead for mobile employees and one SteelHead for office employees.

Consider the following factors when deciding between using a SteelHead or Client Accelerator for a branch office:

If you are deploying the Windows operating system and software by cloning, you might run into an issue in which you create duplicate SIDs (ghosting).

The best practices to deploy and manage Client Accelerator are as follows:

The best practices for end-user licensing are as follows:

You can configure certain antivirus tools installed on a Windows or Mac platform to scan files that have recently changed. Configure the antivirus scanner to ignore the Client Accelerator RiOS data store.

Because Client Accelerator is constantly updating its RiOS data store when the user is sending and receiving data with accelerated connections, the Client Accelerator RiOS data store is scanned frequently. This might lead to end-user performance problems. Because the Client Accelerator RiOS data store does not contain files of any type (just unique data segments), there is no need to scan it for viruses.

You do not have to configure the Client Accelerator policy to support signed SMB connections. For traffic to accelerate correctly you must configure the server-side SteelHead to accelerate signed SMB traffic (joined to a Windows domain, configured with a suitable authentication mode, and so on).

If configured correctly, the Current Connections report on the server-side SteelHead shows CIFS-SIGNED.

With Client Accelerator, Signed SMB connections are supported for SMB1, SMB2, and SMB3 dialects. Previous versions of Client Accelerator supported only SMB1 and SMB2.

Enter the following commands on the Client Accelerator substituting <id> for the relevant policy ID used by Client Accelerator:

Client Accelerator includes support for SSL client authentication. This feature enables Client Accelerator to accelerate traffic when the client PC is using a Common Access Card (CAC).

To enable support for client authentication, you need to configure both the Client Accelerator and the server-side SteelHead.

Follow these steps on the Client Accelerator:

Perform Steps 1 and 2 within the Client Accelerator Controller policy assigned to the relevant client(s). Perform Step 3 on the Client Accelerator Management Console on the Configure > SSL > Peering page.

Client Accelerator provides an option to deploy in a FIPS-compliant mode. The FIPS mode is only applicable to the Client Accelerator itself and does not apply to Client Accelerator that it might be responsible for.

Before enabling FIPS mode, the Client Accelerator must have a FIPS license installed.

Client Accelerators that are part of an HA cluster can be FIPS enabled. We strongly recommend that you have all members of the cluster FIPS enabled rather than have a mixture of FIPS and non-FIPS Client Accelerators.

You can enable FIPS mode only through the CLI of the Client Accelerator.

As part of a Client Accelerator installation, several processes run in the background, including rbtsport. Windows or MacOS starts rbtsport when the host operating system starts up. Therefore, even before a user has logged in, the acceleration service is already running. This means that the Client Accelerator can accelerate a user login process. It can also provide acceleration for other system processes that are occurring automatically in the background, such as backups.