
:guide-id: bblocks-multi-site
:guide-title: Building blocks multi-site deployments
:guide-summary: Overview of building blocks, alternatives and not considered options
:guide-priority: 999
:guide-tile-visible: true
:version: 26.0.2

include::../attributes.adoc[]

[[bblocks-multi-site]]
= Building blocks multi-site deployments

ifeval::["" == "true"]
WARNING: This {section} is describing a feature which is currently in preview.
ifeval::["" == ""]
Please provide your feedback while we’re continuing to work on this.
endif::[]
ifeval::["" != ""]
Please provide your feedback by link:[joining this discussion] while we’re continuing to work on this.
endif::[]
endif::[]


The following building blocks are needed to set up a multi-site deployment with synchronous replication.

The building blocks link to a blueprint with an example configuration.
They are listed in the order in which they need to be installed.

include::partials/blueprint-disclaimer.adoc[]

== Prerequisites

* Understanding the concepts laid out in the link:{links_high-availability_concepts-multi-site_url}[{links_high-availability_concepts-multi-site_name}] {section}.

== Two sites with low-latency connection

Ensures that synchronous replication is available for both the database and the external {jdgserver_name}.

*Suggested setup:* Two AWS Availability Zones within the same AWS Region.

*Not considered:* Two regions on the same or different continents, as it would increase the latency and the likelihood of network failures.
Synchronous replication of databases as a services with Aurora Regional Deployments on AWS is only available within the same region.

== Environment for {project_name} and {jdgserver_name}

Ensures that the instances are deployed and restarted as needed.

*Suggested setup:* Red Hat OpenShift Service on AWS (ROSA) deployed in each availability zone.

*Not considered:* A stretched ROSA cluster which spans multiple availability zones, as this could be a single point of failure if misconfigured.

== Database

A synchronously replicated database across two sites.

*Blueprint:* link:{links_high-availability_deploy-aurora-multi-az_url}[{links_high-availability_deploy-aurora-multi-az_name}].

== {jdgserver_name}

A deployment of {jdgserver_name} that leverages the {jdgserver_name}'s Cross-DC functionality.

*Blueprint:* link:{links_high-availability_deploy-infinispan-kubernetes-crossdc_url}[{links_high-availability_deploy-infinispan-kubernetes-crossdc_name}] using the {jdgserver_name} Operator, and connect the two sites using {jdgserver_name}'s Gossip Router.

*Not considered:* Direct interconnections between the Kubernetes clusters on the network layer.
It might be considered in the future.

== {project_name}

A clustered deployment of {project_name} in each site, connected to an external {jdgserver_name}.

*Blueprint:* link:{links_high-availability_deploy-keycloak-kubernetes_url}[{links_high-availability_deploy-keycloak-kubernetes_name}] that includes connecting to the Aurora database and the {jdgserver_name} server.



== Load balancer

A load balancer which checks the `/lb-check` URL of the {project_name} deployment in each site, plus an automation to detect {jdgserver_name} connectivity problems between the two sites.

*Blueprint:* link:{links_high-availability_deploy-aws-accelerator-loadbalancer_url}[{links_high-availability_deploy-aws-accelerator-loadbalancer_name}] together with  link:{links_high-availability_deploy-aws-accelerator-fencing-lambda_url}[{links_high-availability_deploy-aws-accelerator-fencing-lambda_name}].
