Apereo CAS High-Availability with Hazelcast and Kubernetes

Misagh Moayyed recently published this blog post with the title, “Apereo CAS High-Availability with Hazelcast and Kubernetes“. In this post, Misagh discusses how to solve one of the primary concerns when deploying a highly available CAS server.

When it comes to deploying a highly available CAS server, one of the chief concerns is to choose a technology that is capable of sharing CAS-generated tickets across multiple server nodes. The task of managing and administering CAS tickets is handled today by a Ticket Registry component that is backed by a variety of technologies able to persist, manage, and distribute ticket objects across the entire CAS cluster. Perhaps the most popular and better-adopted option in this area is a ticket registry solution backed by Hazelcast.

Hazelcast, as an open source solution, is an operational in-memory computing platform that helps the CAS server manage the ticket data and distribute it across the cluster using in-memory storage and parallel execution for breakthrough application speed and scale. One of the main advantages of Hazelcast is its in-memory nature, where there is no extra requirement for a separate data store or running daemon and every CAS server node is entirely self-contained and in contact with other cluster members to efficiently share the necessary data.

There is great flexibility and a wide range of options available when it comes to discovering CAS server nodes in the same cluster. Most commonly, node members are introduced to each other statically in the CAS configuration by either IP address or DNS, and this option typically works best for smaller and more modest deployments. If this static discovery strategy is not an attractive option for your deployment, there is support for many other tactics where you can allow CAS to take advantage of AWS EC2 or Microsoft Azure’s discovery methods. This is especially useful when you do not want to or cannot provide the list of possible IP addresses for the members of the cluster, or if you wish to take advantage of more advanced features of the deployment platform such as auto-scaling or zone-aware configurations. Note that all such configuration options are provided today out-of-the-box with the current release of the CAS software, which as of this writing, is the CAS 5.3.x release line.

Starting with CAS 6, the next major version of the CAS software, a new and shiny strategy is added to the list of Hazelcast discovery options backed by Kubernetes. Kubernetes is an open source orchestration system for automating deployment, scaling, and management of containerized applications. Should you be interested in a containerized CAS deployment, and wish to manage it via Kubernetes in an HA type of setting using Hazelcast, this new discovery strategy for the Hazelcast ticket registry provides the possibility to look up IP addresses of other member’s pods. This is done by resolving those requests against a Kubernetes Service Discovery system. I should note that while this integration is provided out-of-the-box by CAS 6, it would be fairly easy to take advantage of the same strategy by integrating it with the current version of CAS 5.3.x.

Remember that as of this writing, CAS 6 is still in active development with a series of planned milestones and release candidates that gradually come alive throughout the year. The current release candidate available for adoption and testing is tagged as RC2 where the Hazelcast integration with Kubernetes lives. Feel free to give the release candidate a try to test out this functionality as time and opportunity allows, and of course, if you have any questions please contact Unicon for more information.