High Availability Architecture¶
This document describes the architecture of a high availability ESS deployment on Amazon Web Services (AWS).
Architecture Overview¶
Virtual Private Cloud¶
ESS runs within a Virtual Private Cloud.
Availability Zones¶
Inrupt recommends running in at least 2 availability zones. Each availability zone should contain a public subnet and a private subnet. Only the load balancer should run on the public subnet.
Gateway (Optional)¶
Although not strictly required for high availability, an application gateway can sit in front of the VPC.
If you choose to add a gateway component, ensure that the gateway can support availability across multiple availability zones and balance traffic as needed.
Load Balancers¶
Load Balancers are the only ESS component in the public subnets. If reliance on the SLA of a single load balancer for the ESS deployment insufficient, you can use multiple load balancers; i.e., have a load balancer in each availability zone. You can even use another load balancer to front the multiple load balancers.
The Load Balancers will each have public DNS addresses. These should be
added as CNAME entries to your DNS configuration as follows,
substituting your domain for <DOMAIN>:
identity.<DOMAIN><DOMAIN>oidc.<DOMAIN>
Separate Management of Public and Backend Services¶
Separate the resource management for public “ess” services (e.g. LDP, Solid OIDC Broker) from the “backend” services (e.g., monitoring, logging).
For the AWS deployment, two Auto-Scaling Groups (ASG) are used to provide separate pools of EC2 instances, one for the “ess” services and one for the “backend” services. This allows the two EC2 pools to be managed separately. For example, you could launch your own custom container into the “backend” pool without impacting the performance of the critical services in the “ess” pool.
PostgreSQL¶
The ESS system stores data in a PostgreSQL database.
This guide assumes the use of Amazon’s managed service Relational Database Service (RDS). Inrupt recommends enabling “Multi-AZ” on RDS instances.
Secrets/Certificate Management¶
Various services related to secrets and certificate management are generally only required during container or service start/stop/restart. As such, outside of these periods, ESS can continue to operate during an outage to one of these services.
Container Registry¶
Inrupt recommends against relying on a public repository, such as Inrupt’s own software releases. Instead, pull the Docker images from your own container registry.
The container registry is only required during container startup if you need to pull the Docker image. Outside of this reliance, ESS can continue to operate during a container registry outage.