Redundancy ensures that when things go wrong, you have something to fall back on. This doc explains how redundancy works on Pagoda Box and how you can make your apps redundant. After reading it, you should be familiar with:
- How Pagoda Box facilitates redundant architectures
- How to make your app redundant
What is Redundancy?
Simply put, redundancy is failover. If something goes wrong with an instance, there's another instance or instances to fall back to. It's a simple concept, but there are details & benefits of redundant services on Pagoda Box that should be pointed out.
Redundant services consist of two or more instances. Though rare, it's possible for one instance to fail and/or stop responding. When this happens, Pagoda Box health-monitors detect the faulty instance and begin routing all requests to the other instance(s) as the faulty instance is repaired. This all happens behind the scenes with, in most cases, no noticeable impact to the end user.
When multi-instance services are created on Pagoda Box, each instance is provisioned on separate physical machines. If there's ever an issue with a host server, health monitors detect the unresponsive instance on the affected server and push all requests to instances on functioning servers.
Isn't Pagoda Box Redundant?
Yes, Pagoda Box's underlying infrastructure is redundant – meaning all underlying processes that allow Pagoda Box to function are redundant. However, this doesn't mean your app is redundant. App-level redundancy is managed by users.
App Redundancy is Handled Per Service
Each app consists of one or more services (PHP, MySQL, Redis, etc.). Each service, depending on the type, can be redundant. A service's "topology" determines whether or not the service is or can be redundant. More on topologies in the Service Topologies doc and below.
Making Services Redundant
There are multiple ways to make services redundant. When creating a service from the Boxfile or through the dashboard, you can define the service's topology. You can also add instances to code services as well as change the topology of data services service in your dashboard.
Creating a Redundant Service from Your Boxfile
When creating a service from the Boxfile, define the service's topology in the Boxfile config. Below is an example of services in the Boxfile with redundant topologies.
Redundant Services in the Boxfile YAML
web1: type: php topology: cluster database1: type: mysql topology: redundant cache1: type: redis topology: redundant
Boxfile Topologies Only Apply on Service Create
When defining a service's topology in your Boxfile, it only gets applied when the service is created. For existing services, changes to the topology Boxfile config are ignored.
Creating a Redundant Service in Your Dashboard
When adding a data service in your dashboard, select the "Redundant" topology.
Making Code Services Redundant
Code services (webs & workers) are created using the cluster topology, meaning they can have many instances working together as one. Any code service scaled to two or more instances is redundant.
To add instances to a code service, click on the service in your dashboard to expand its options. Under the "Configure" tab, you'll see the service's current number of instances. Click to expand the scaling options. Add instances by moving the slider to the right, then click "Save Changes".
Making an Existing Data Service Redundant
Most data services (databases, caches, storage, etc.) have both the "single" and "redundant" topologies available to them.
To make a manage the topology of a data service, click on the service in your dashboard to expand its options. Under the "Configure" tab, you'll see the current topology in the lower left. Click to expand the scaling options. Select the "Redundant" topology from the dropdown and click "Save Changes".
Topologies & Redundancy
As mentioned above, redundancy is enabled through a service's topology. For a deep dive into topologies, read through the Service Topologies doc. Below are quick summaries of each topology and how they facilitate redundant architectures.
Single topologies are not redundant.
Two instances in either a Master/Master, Master/Slave, or Primary/Secondary setup.
One or more instances working together as one. Services with the cluster topology are only redundant when scaled to two or more instances.
Table of Contents
- Creating a Redundant Service from Your Boxfile
- Redundant Services in the Boxfile
- Boxfile Topologies Only Apply on Service Create
- Creating a Redundant Service in Your Dashboard
- Making Code Services Redundant
- Making an Existing Data Service Redundant
If you have any questions, suggestions, or corrections, let us know.