High availability is the concept of making software resilient to failures by means of running multiple replicas with shared and synchronised software context. If one replica fails for any reason, the software stays alive, unless all replicas fail. In Juju, high availability is provided for deployed applications as well as the Juju controller itself.
Application high availability
In the event of an outage affecting one’s backing cloud, application high availability strives to ensure that not all units of an application will become unresponsive at the same time. This default behaviour in Juju thus maximises your application’s availability.
Making an application highly-available is easy: Scale your application out so that it would be running as a distribution group consisting of multiple units (though in theory an application with a single unit is still considered as a distribution group), as shown below:
juju deploy -n 10 <application>
Every time a unit is added to an application, Juju will spread out that application’s units, distributing them evenly across the availability zones that it detects from the cloud (for the particular region, credential, VPC, etc.), to best ensure high availability. So long as a cloud’s availability zones don’t all fail at once, and the charmed operator and the charmed operator’s application are well written (changing leaders, coordinating across units, etc.), you can rest assured that IaaS downtime will not affect your application.
Controller high availability
Juju controllers can be made highly-available by enabling more than one machine to each run a separate controller agent instance, where each machine effectively becomes an instance of the controller. This set of Juju agents collectively use a database replicaset to achieve data synchronisation amongst them. The concept of controller high-availability is depicted in the following figure.
Last updated 6 months ago.