Integrating Elvis 6 in Enterprise Server 10 on AWS - Load balancer information

When integrating Elvis 6 with Enterprise Server 10 in an Amazon AWS environment, load balancers can optionally be used.

Various ways of doing this exist. To help in setting up the environment, this article provides information to determine the following:

• If Sticky Sessions should be enabled
• If the AWS Classic Load Balancer (CLB) and/or the AWS Application Load Balancer (ALB) are supported

Note: Looking for similar information for Elvis 5? See: Integrating Elvis 5 in Enterprise Server 10 on AWS - Load balancer information.

Before you start

The information in this article can only be used when all of the following applies to your environment:

1. Elvis Server and Enterprise Server are set up in Amazon Web Services (AWS).
2. Elvis and Enterprise both have a load balancer set up; either the Classic Load Balancer or the Application Load Balancer.
3. The Elvis Server setup consists of multiple nodes.
4. The Enterprise Server setup consists of multiple Application Servers that are connected to one database.

Note: Also refer to the comparison of Load Balancers from AWS.

Summary

The following table shows a summary of this information. For more details, see the sections below.

Sticky Sessions

For the Elvis Server load balancer, enabling Sticky Sessions is recommended but not required.

For the Enterprise Server load balancer, enabling Sticky Sessions is only required when it has also been set up for the Elvis load balancer.

Background information

• Elvis Server works with JWT tokens which can be validated by any node without the help of cached session data. This means that technically sessions do not have to be sticky.

However, data is also cached locally by the nodes to work more efficiently. When one node serves a request it will set up cached data for the session. When this data is not present, it will be retrieved.

Because this process takes a little time it could be more efficient to enable the Sticky Session option for the Elvis load balancer.

• Enterprise Server 10.4: The acting Smart Connection or Content Station user is logged on to Elvis by Enterprise Server (if the user is unknown to Elvis, a configured fallback user is used).

The token/session is stored in a cookie jar that travels over the back-end connection between one particular Application Server of Enterprise and the Elvis load balancer.

If the next request from Smart Connection or Content Station would arrive on a different Application Server of Enterprise, the cookie jar would not be found and it would therefore log on to Elvis again. This would be very inefficient. Using Sticky Sessions resolves this.

• Enterprise Server 10.5 or higher does not use cookies and it also does not log on to Elvis. Instead, it has a trusted connection with Elvis based on a client secret and ID.

Access tokens are used which automatically expire. Once expired, Enterprise requests a new access token by using the client secret and ID. It impersonates the connection with the acting Smart Connection or Content Station user (if the user is unknown to Elvis, a configured fallback user is used). The access token is stored in the Enterprise database.

Each Enterprise Application Server can take the access token from the database and set up an authorized connection to Elvis.

For this reason, Sticky Sessions are not required.

Note: When you have decided to enable Sticky sessions for the Elvis load balancer, it should also be enabled for the Enterprise load balancer to create a fixed route from Smart Connection or Content Station over Enterprise to Elvis. If Sticky Sessions are not set up for the Elvis load balancer then it is not required for the Enterprise load balancer either.

CLB and ALB support

For the Elvis Server load balancer:

• With Enterprise Server 10.4 connected: use CLB¹
• With Enterprise Server 10.5 or higher connected: use ALB

¹ Does not support the use of Elvis Agent (see below).

For the Enterprise load balancer:

• Both CLB and ALB are supported for the load balancer for Enterprise 10.4 and for Enterprise 10.5 or higher.

Background information

• Enterprise 10.4: Although Enterprise Server accepts simultaneous Content Station requests over multiple Application Servers, this seems to confuse ALB in its session registrations using cookies. ALB is therefore not supported for the Elvis load balancer in combination with Enterprise 10.4.

Note: This means that Elvis Agent cannot be used with this combination of Elvis and Enterprise. See the note about Elvis Agent below.

• Enterprise 10.5 or higher does not use cookies for the Elvis connection and therefore supports both CLB and ALB for the Elvis load balancer. However, ALB is required to make use of Elvis Agent (See the note about Elvis Agent below).

Elvis Agent

Elvis Agent (used for efficiently checking out files in their native application) makes use of WebSockets. Support for WebSockets is available in ALB but not in CLB.