# High Availability

## Overview

Below is a high-level overview of setting up Keeper Connection Manager (KCM) for High Availability (HA). This is an advanced implementation that requires familiarity with load balancing, databases, security groups, VPCs, etc.

### HA Approaches

#### Active-Active

* Multiple KCM servers handle traffic simultaneously.
* Requires a load balancer with session persistence (sticky sessions) to ensure users stay connected to the same KCM instance.
* Provides higher throughput and automatic failover.

#### Active-Passive

* One primary KCM server is active, with a standby instance ready to take over.
* Failover occurs only if the active server becomes unavailable.
* Simplifies troubleshooting but does not improve overall capacity.

<figure><img src="https://3357255970-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fb7weUpu7VBcMnESSH8vG%2Fuploads%2FLI8NLfW3BXxr45mUaY14%2Fself-hosted%20KCM%20HA%20scaling.png?alt=media&#x26;token=fcb42e6a-7af7-433a-9fa3-dfc0fffd969e" alt=""><figcaption></figcaption></figure>

### Key Requirements

* **External Database** – All KCM instances must share a single database (e.g., MySQL, PostgreSQL) to ensure consistency.
* **Load Balancing** – Required for both HA models. Use a load balancer with sticky sessions for Active-Active or a failover mechanism for Active-Passive.
* **Storage Considerations** – Session recordings in KCM are stored on the local disk of the KCM instance. If storage is full, new recordings fail while old ones remain. In a cluster, you may need to consider a shared drive or a cron job to sync the files.
* **SSL Termination**:  By default, the KCM docker compose is configured with NGINX to terminate SSL with either a custom certificate or Let's Encrypt certificate. Based on your load balancer's features, you can decide to terminate the SSL at the load balancer or terminate on the KCM instance.

### Setup Steps

{% stepper %}
{% step %}

### Deploy Multiple KCM Instances

Ensure that the configuration is identical, using the same docker compose.
{% endstep %}

{% step %}

### Deploy Database

* Set up a cloud managed or locally managed database
* Ensure that database backups are enabled
* Migrate KCM data from local DB to shared DB (e.g. using `mysqldump`)
  {% endstep %}

{% step %}

### Update KCM Configuration

* Update the KCM instances (e.g. `docker-compose.yml`) to point to the shared DB
* Configure the listeners on each container based on the load balancer setup
  {% endstep %}

{% step %}

### Implement HA Model

* Active-Active: Deploy a load balancer with sticky sessions
* Active-Passive: Set up monitoring to detect failures and switch traffic
  {% endstep %}

{% step %}

### Test & Validate

* Simulate failures, monitor performance, and verify automatic failover
  {% endstep %}
  {% endstepper %}