Skip to main content

High Availability

Avassa application availability overview

Avassa provides rich capabilities to maximize application availability. the base for this is that hosts in a site forms a cluster. The most common setup for your application to request Avassa to start a number of replicas of your application on the cluster. The Avassa builtin DNS service will then automatically round robin requests to your application across the available replicas. If an application or host fails, the request will be routed to the remaining healthy replicas. This ensures that your application remains available even in the event of failures. You can even achieve more fine-grained control by using probes to direct traffic to only healthy replicas based on custom health checks.

Replicas or failover? The recommended approach is to use replicas for applications that can scale horizontally, as this provides better availability and load distribution. For applications that cannot be scaled horizontally, failover is a suitable option to ensure availability in case of host failures.

Avassa also provides safe upgrades. The most straight-forward one is rolling upgrades of your application. Avassa will automatically start a new replica with the new version of your application and once it is healthy, it will stop one of the old replicas. This ensures that your application remains available during the upgrade process.

If your application has ongoing transactions or long-running processes, Avassa also supports "blue-green" deployments through the delayed shutdown feature. This allows you to deploy a new version of your application alongside the old version and switch traffic to the new version once it is ready. This ensures that your application remains available during the upgrade process and minimizes downtime.

Notes:

  • If you have configured a number of replicas and one host fails, a new replica will not be started since the application is still available on the remaining replicas.
  • Ingress IP addresses are not automatically moved to the new host in case of failover. If you are using IP Pools for example, you need to prepare the pool to support enough IPs for failover to work.
  • Avassa can not migrate internal application state between replicas or hosts. If your application maintains internal state, you need to ensure that this state is replicated or stored externally to ensure that failover works correctly. For example by using a replicated database. (See the Redis example below)
  • Volga is an option to use for storage of internal state. Volga is a distributed storage system that can be used to store application state and data across multiple hosts in the cluster. This ensures that even if a host fails, the application state is still available on other hosts in the cluster.

The Redis example illustrates many of the principles above. It uses replicas for availability and also illustrates the usage of probes to appoint one of the replicas as the "master" and the other replicas as "slaves". The master replica is responsible for handling requests, while the slaves are replicated. If the master replica fails, one of the slave replicas will be promoted to master, ensuring that the application remains available.