Configure caches for high availability¶
If you’re deploying a MSR cache in a zone with few users and with no uptime SLAs, a single cache service is enough.
But if you want to make sure your MSR cache is always available to users and is highly performant, you should configure your cache deployment for high availability.
System requirements¶
Multiple nodes, one for each cache replica.
A load balancer.
Shared storage system that has read-after-write consistency.
The way you deploy a MSR cache is the same, whether you’re deploying a single replica or multiple ones. The difference is that you should configure the replicas to store data using a shared storage system.
When using a shared storage system, once an image layer is cached, any replica is able to serve it to users without having to fetch a new copy from MSR.
MSR caches support the following storage systems:
Alibaba Cloud Object Storage Service
Amazon S3
Azure Blob Storage
Google Cloud Storage
NFS
Openstack Swift
If you’re using NFS as a shared storage system, make sure the shared directory is configured with:
/dtr-cache *(rw,root_squash,no_wdelay)
This ensures read-after-write consistency for NFS.
You should also mount the NFS directory on each node where you’ll deploy a MSR cache replica.
Label the MSR cache nodes¶
Use SSH to log in to a manager node of the swarm where you want to deploy the MSR cache.
If you’re using MKE to manage that swarm you can also use a client bundle to configure your Docker CLI client to connect to that swarm.
Label each node that is going to run the cache replica, by running:
docker node update --label-add dtr.cache=true <node-hostname>
Configure and deploy the cache¶
Create the cache configuration files by following the instructions for deploying a single cache replica.
Make sure you adapt the storage
object, using the configuration
options for the shared storage of your choice.
Configure your load balancer¶
The last step is to deploy a load balancer of your choice to load-balance requests across the multiple replicas you deployed.