|
| 1 | +--- |
| 2 | +title: "High Availability Patterns for PEM Deployment" |
| 3 | +navTitle: "High Availability Patterns" |
| 4 | +redirects: [] |
| 5 | +--- |
| 6 | + |
| 7 | +If you require your PEM deployment to be highly available, you can deploy multiple instances of the PEM backend database and frontend web application in a High Availability (HA) topology. |
| 8 | + |
| 9 | +This page details the fundamental requirements of such a topology. |
| 10 | + |
| 11 | +## Running multiple instances of the PEM backend database |
| 12 | + |
| 13 | +An highly available PEM backend database functions like any other standard HA Postgres cluster. The key requirements for the backend are as follows: |
| 14 | + |
| 15 | +### A primary |
| 16 | + |
| 17 | +At any given time, only one instance of the PEM backend database should accept write connections. This instance is referred to as the `primary PEM backend database`, or simply the `primary`. |
| 18 | + |
| 19 | +All other instances must function as replicas of the primary. You must implement a reliable method for promoting a replica in the event of a primary failure. This typically involves using a supported failover manager. |
| 20 | + |
| 21 | +PEM supports the following failover solutions: |
| 22 | + |
| 23 | +- EDB Failover Manager (EFM) |
| 24 | +- Patroni |
| 25 | + |
| 26 | +!!! Note |
| 27 | +EDB Postgres Distributed is not supported as a PEM backend. |
| 28 | +!!! |
| 29 | + |
| 30 | +### Connections must go to the primary |
| 31 | + |
| 32 | +All connections from active PEM web application instances and running PEM agents must connect to the primary PEM backend database. |
| 33 | + |
| 34 | +There are two general approaches to ensure this: |
| 35 | + |
| 36 | +1. Use a [single endpoint](#load-balancers-proxies-and-vips) that always routes to the primary. This can be implemented using various methods, such as a Virtual IP (VIP), a network load balancer, or a proxy that automatically routes traffic to the current primary. |
| 37 | + |
| 38 | +1. Configure clients to switch endpoints when the primary changes. This is commonly done using the [multi-host connection strings], allowing clients to retry against alternate hosts when the primary is unreachable. |
| 39 | + |
| 40 | +For more details, see [Load balancers, proxies and VIPS](#load-balancers-proxies-and-vips) and [Reference architectures](#reference-architectures). |
| 41 | + |
| 42 | + |
| 43 | +## Running multiple PEM web application instances |
| 44 | + |
| 45 | +High availability for the PEM web application is achieved by running multiple instances of the web application—all connected to the primary PEM backend, as described earlier. Unlike the backend, multiple frontend instances can run concurrently without issue. |
| 46 | + |
| 47 | +!!! Note "PEM is not stateless" |
| 48 | +PEM web application instances maintain session state. Routing requests from a single user session to different instances may lead to inconsistent behavior.This is particularly relevant if you're using a stateless load balancer. Ensure session stickiness ("sticky sessions") is enabled to route all requests from a given session to the same instance. |
| 49 | +!!! |
| 50 | + |
| 51 | +To ensure a consistent across all instances: |
| 52 | + |
| 53 | +- Configure all instances to store user preferences in the PEM backend database, not locally. |
| 54 | +- For features that generate or store files e.g. dump/restore, use a shared file system accessible to all web instances. |
| 55 | + |
| 56 | +## Upgrading an HA PEM deployment |
| 57 | + |
| 58 | +When running PEM in a high availability (HA) configuration, it's critical to have a well-defined and tested upgrade procedure. This ensures minimal downtime and maintains the integrity of both the backend database and the web application during the upgrade process. |
| 59 | + |
| 60 | +## Load balancers, proxies and VIPs |
| 61 | + |
| 62 | +In the reference architectures below, we use the term "Proxy/VIP" to refer to any component that presents a single endpoint for inbound connections and routes traffic to the current primary. This can be implemented using a variety of tools and techniques, some of which are outlined below. |
| 63 | + |
| 64 | +### Using a Virtual IP (VIP) managed by the failover manager |
| 65 | + |
| 66 | +A Virtual IP (VIP) is an IP address not tied to a specific physical network interface and can move between nodes in a subnet. Because VIPs are managed by the OS networking stack, they require no additional hardware or third-party software. |
| 67 | + |
| 68 | +To route traffic to the primary using a VIP, configure your failover manager to assign the VIP to the new primary during a failover. |
| 69 | + |
| 70 | +- EDB Failover Manager (EFM) supports VIPs natively and is recommended if you choose this method. |
| 71 | + |
| 72 | +- Limitation: VIPs are not suitable for multi-region or multi-subnet cloud environments. |
| 73 | + |
| 74 | +### Using a load balancer |
| 75 | + |
| 76 | +If your environment supports load balancers (e.g. AWS Elastic Load Balancer, on-prem F5,..), they can be used to route the traffic to the current primary. There are two common patterns: |
| 77 | + |
| 78 | +1. Use a failover manager that reconfigures the load balancer during the failover to route inbound connections to the new primary. |
| 79 | + |
| 80 | +2. Use a failover manager where the load balancer polls each node via an HTTP endpoint to determine which is the current primary. |
| 81 | + Only the primary responds positively (e.g. HTTP code 200), meaning the load balancer switches all traffic to the primary within one poll interval. |
| 82 | + This can be achieved via the `/primary` or `/read-write` endpoints in Patroni, for example. |
| 83 | + |
| 84 | +Pattern 2 is generally preferred, as it aligns with how load balancers are designed to operated and does not require administrative access to modify load balancer configurations during the failover. |
| 85 | + |
| 86 | +!!! Note |
| 87 | +The reason we say “if your environment provides a load balancer” is that this solution needs to be properly implemented to avoid being a single point of failure. |
| 88 | +Load balancer themselves must be highly available. This typically involves using DNS failover,elastic IPs, or other infrastructure-level solutions to avoid them becoming a single point of failure. |
| 89 | + |
| 90 | +Simply adding a standalone instance of HAProxy or pgBouncer in front of your database is not sufficient. EDB support cannot assist in designing or managing custom load balancer setups. The solution must be vetted, supported, and maintained by your organization's infrastructure or operations team. |
| 91 | +!!! |
| 92 | + |
| 93 | +## Multi-host connection strings |
| 94 | + |
| 95 | +Starting with PEM 10.1, both the PEM agent and the PEM web application support multi-host connection strings to connect to the backend database. |
| 96 | +With multi-host connection strings: |
| 97 | + - Clients (i.e. PEM agent or web application) try each listed host until one accepts write connections. |
| 98 | + - On failover, connections are dropped and the client begins the search again. |
| 99 | + - If the first host in the string is not the primary, it results in a failed connection attempt increasing the time taken to establish a connection to the primary and increasing resource usage on the monitored server and the PEM backend servers. |
| 100 | + |
| 101 | +!!! Note "Drawback" |
| 102 | +The multi-host connection strings are less efficient than using a single routing endpoint like a load balancer or VIP. |
| 103 | +!!! |
| 104 | + |
| 105 | + |
| 106 | +## Reference Architectures |
| 107 | + |
| 108 | +All architectures below show three nodes with PEM backend databases. However, this also work with only two nodes providing the failover manager is happy with even node numbers (if not, a witness node could be used in place of a full third node). |
| 109 | +Likewise more than three nodes also work fine but it may not yield significant benefit for most deployments. |
| 110 | + |
| 111 | + |
| 112 | +### C1: Colocated with single endpoint |
| 113 | + |
| 114 | +A minimal setup where the PEM web application and backend database both run on the same host. |
| 115 | + |
| 116 | +**Pros:** |
| 117 | + |
| 118 | +- Transparent connections for both web application users and monitoring agents, to the same endpoint. |
| 119 | +- Simplified Web application configuration and upgrades, as all instances connect to the loopback interface. |
| 120 | +- Suitable for smaller deployments. |
| 121 | + |
| 122 | +**Cons:** |
| 123 | + |
| 124 | +- Shared resources may become a bottleneck. |
| 125 | +- No resilience to failure of the web application. Failover occurs if the database fails unless you customise the failover conditions. |
| 126 | + |
| 127 | + |
| 128 | + |
| 129 | +### S1: Separated with single endpoint for database |
| 130 | + |
| 131 | +A setup where the PEM web application and backend database both run on separate hosts. |
| 132 | + |
| 133 | +**Pros:** |
| 134 | + |
| 135 | +- Transparent connections for monitoring agents, as they always connect to the same endpoint. |
| 136 | +- Web application and database components are independently scalable and redundant. |
| 137 | +- Suitable for larger deployments. |
| 138 | + |
| 139 | +**Cons:** |
| 140 | + |
| 141 | +- Users must manually choose a web application instance unless a frontend load balancer is used. |
| 142 | + |
| 143 | + |
| 144 | + |
| 145 | +### CM: Colocated with multi-host connection strings |
| 146 | + |
| 147 | +A single-endpoint setup is replaced by clients using multi-host connection strings to ensure traffic is routed to the primary. Web application and backend database are colocated. |
| 148 | + |
| 149 | +**Pros:** |
| 150 | + |
| 151 | +- No need to manage a load balancer or VIP for the database server. |
| 152 | +- Redundant web applications. |
| 153 | +- Smaller footprint than S1 and SM. |
| 154 | + |
| 155 | +**Cons:** |
| 156 | + |
| 157 | +- Hard to reconfigure as every monitoring agent and web application must be configured with the connection details of all backends databases. |
| 158 | +- It can be confusing to have multiple instances of the web application running. Users must manually choose a web application instance unless a frontend load balancer is used. |
| 159 | +- Multi-host connections are less efficient than routing through a single endpoint. |
| 160 | + |
| 161 | + |
| 162 | + |
| 163 | +### SM: Separated with multi-host connection strings |
| 164 | + |
| 165 | +This setup removes the single endpoint but separates the web application and backend database for improved scalability. |
| 166 | + |
| 167 | +**Pros:** |
| 168 | + |
| 169 | +- No need to manage a load balancer or VIP for the database server. |
| 170 | +- Redundant web application and backend database components. |
| 171 | +- Suitable for larger deployments for improved scalability. |
| 172 | + |
| 173 | +**Cons:** |
| 174 | + |
| 175 | +- Hard to reconfigure as every monitoring agent and web application must be configured with the connection details of all backend databases. |
| 176 | +- It can be confusing to have multiple instances of the web application running. Users must manually choose a web application instance unless a frontend load balancer is used. |
| 177 | +- Multi-host connections are less efficient than routing through a single endpoint |
| 178 | + |
| 179 | + |
0 commit comments