Set up high availability

Mirantis Secure Registry is designed to scale horizontally as your usage increases. You can increase the number of replicas for each of the resources that MSR deploys.

Note

Additional replicas make MSR more tolerant to failure, but be aware that performance degradation can result from having too many replicas in your RethinkDB cluster.

All MSR replicas run the same set of services, and changes to their configuration are automatically propagated to other replicas.

When sizing your MSR installation for high availability, Mirantis recommends the following best practices:

• Do not scale RethinkDB with only two replicas.

  Caution

  RethinkDB cannot tolerate a failure with an even number of replicas.

  MSR replicas	Failures tolerated
  1	0
  3	1
  5	2
  7	3

• Address failed replicas quickly, as the number of failures your cluster can tolerate decreases whenever a replica is offline.

High availability prerequisites

High availability on MKE and MSR requires:

• Three dedicated nodes on which to install MKE with high availability.

• Three dedicated nodes on which to install MSR with high availability.

• The number of nodes you deem necessary for running your containers and applications.

• That MSR replicas are configured to share the same object storage.

Join additional MSR replicas

To add replicas to an existing MSR deployment:

1. Use SSH to log into any MKE node.

2. Run the MSR join command:

   docker run -it --rm \
     mirantis/dtr:2.9.16 join \
     --ucp-node <mke-node-hostname> \
     --ucp-insecure-tls
   

   The --ucp-insecure-tls option permits the certificates that are in use by MKE.

3. If you are running a load balancer, add the new MSR replica to the load balancing pool.

Remove existing replicas

To remove an MSR replica from your deployment:

1. Use SSH to log into any node that is already a part of MKE.

2. Run the MSR remove command:

   docker run -it --rm \
   mirantis/dtr:2.9.16 remove \
   --ucp-insecure-tls
   

   As a result, you will be prompted for the following data:

   Existing replica id

   The ID of any healthy MSR replica in the cluster.

   Replica id

   The ID of the MSR replica you want to remove, which can be the ID of an unhealthy replica.

   MKE username and password

   The administrator credentials for MKE.

Important

If you are load balancing user requests across multiple MSR replicas, be sure to remove this replica from the load balancing pool.