High Availability & Scaling
Connexion can be setup in a fault-tolerant configuration to provide high up time as well as rolling upgrades.
This configuration requires several components:
Two (or more) Connexion Instances. Only one Connexion application server is ever active, with other cluster members being hot standbys.
A fault-tolerant database backplane. This is usually one of the Sql Server high availability technologies like Always-On or Mirroring.
A smart switch which can direct traffic to the active Connexion application server.
Connexion works well in cloud environments like AWS. You can utilize various cloud technologies, like Aurora or RDS, which provide high availability with a very simple configuration.
Configuring a Connexion cluster is easy, and is done by choosing a specific database during the initial setup / configuration (in the Configuration Wizard).
The first step is to install the first Connexion application server as though it will be a stand-alone instance. Any Connexion installations which use the same configuration database as the first instance will automatically become part a cluster.
When running the Configuration Wizard for the second instance, select the database created by the first instance. Note that you may need to also select a Sql Server high-availability technology, if used.
When prompted to choose accounts and credentials, it’s important to use an account and credentials which will work for all Connexion application servers. One option is to use an Active Directory account available to all Connexion application servers with the Use Existing User Account option below, with Windows Authentication. Another option is to use the same SQL Authentication credentials for each Connexion application server (but don’t use sa - this is just an example).
Once you complete the second Connexion application server install, you will see the cluster on the Servers UI.
In clustered deployments, it’s important that resources access by Connexion are accessible to all notes in the cluster. This means file resources should be on a shared drive, and accounts used to access resources must be configured on all nodes.
It’s also important to ensure any certificates are installed in the certificate stores on each node (most Connexion devices utilizing certificates do not use the store, and instead store them in the common configuration database).
Scaling
The current Connexion model does not support sharding channels across application servers within a cluster - there is only ever one active application server. This means that CPU and memory only scale vertically with the host machine.
In the future, we may move to a model which partitions channels across all application servers within the cluster. In practice, however, Memory is very easy to scale and CPU is typically not a performance limiting factor. Usually, the limiting factor is I/O - getting message data to and from the database.
In cases where CPU is a limiting factor, you can employ other servers to perform heavy tasks. We have built infrastructure for this scenario in the past, but there are other options such as AWS Lambda.
In order to scale I/O, Connexion supports multiple message databases. Each group within Connexion is assigned to a specific message database when it is created. When one database host becomes I/O limited (or memory/cpu bound), you can spin up another host and create a new message database for each newly added group.
It is also possible to migrate a group from one database to another, although this is an advanced feature which should only be undertaken with support from Conevity.
It’s important to note that a multiple message databases can be hosted in a single database. If your host hardware / VM has the capability, databases can often be configured to use dedicated drives or storage. This allows scaling I/O without needing additional licenses.
Adding Message Databases
To add a message database, navigate to the servers UI and click the Add Repository button. This will display the Add Repository dialog. Fill in the necessary connection information and wait for the status bar on the bottom to turn green. Once it does, click the Create Database button.
After clicking the Create Database button, you should see detailed logs along with the status (success, or error). Notice the new database is now shown in the server diagram.
When creating a new group, you can now specify which message repository will be used for all channels within that group.
You can hover over the name of a channel to see which repository it’s associated with.
Application Servers
Interact with application servers by right-clicking on each icon. There are a number of actions available.
Set as Active: Manually set the active application server.
Bring Online / Take Offline: Temporarily exclude an application server from participating in the cluster.
Decommission: Permanently remove this application server from the cluster. If this instance of Connexion is still running, it will automatically re-add itself to the cluster. You must uninstall the instance you want to remove prior to performing this action.
Database Operations: Various actions which can be performed on the configuration database.
Application servers can take up to 30 seconds to take ownership of the cluster. When ownership changes, you should see the message database icons move to the newly active node.