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:
- Elvis Server and Enterprise Server are set up in Amazon Web Services (AWS).
- Elvis and Enterprise both have a load balancer set up; either the Classic Load Balancer or the Application Load Balancer.
- The Elvis Server setup consists of multiple nodes.
- 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.
The following table shows a summary of this information. For more details, see the sections below.
|Sticky Sessions||Recommended but not required||Only required when also set up for the
Elvis load balancer
|CLB and ALB support||
In combination with Enterprise 10.4: CLB only.
In combination with Enterprise 10.5 or higher: CLB and ALB.
|CLB and ALB|
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.
- 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.
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 CLB1
- With Enterprise Server 10.5 or higher connected: use ALB
1 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.
- 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.
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.
Do you have corrections or additional information about this article? Leave a comment! Do you have a question about what is described in this article? Please contact Support.
This article sets up two areas to concern about, the Websockets for the Elvis Agent and Sticky Sessions.
Please refer to the comparison of Load Balancers from AWS here:
Web sockets are both available for ALB and NLB, Sticky Sessions are available for ALB and CLB.
ALB also has layer 7 support including support for headers like X-Forwarded-For which are necessary for having correct URLs returned by Elvis for downloads and thumbnails.
We recommend to use ALB unless you are running Enterprise 10.4, then use CLB.
The use of the term "ELB" is ambiguous.
ELB is a grouping of all AWS load balancer options, currently these three:
I assume you mean either NLB or CLB when you use ELB in this page, but could you clarify this point, please?
Please sign in to leave a comment.