Setting up Apigee X Multi-Region Architecture for internal clients

This article talks about setting up multi region Apigee failover setup specifically for the traffic that is internal to GCP cloud. The setup leverages the health checks feature of Geolocation policy in GCP Cloud DNS to route the traffic to appropriate Apigee instances through internal load balancer.

Authors : Tanmay Bangale , Payal Jindal

Context

We can have a multi region failover setup for the Apigee for internal clients. This means internal clients coming from respective geographies can reach the closest Apigee instance region. In case of failover of Apigee instance in either of the regions, the traffic can then be forwarded to available regions without any downtime.

For this we rely on two features :

1. DNS Geolocation Routing policy with health checks
2. Internal Load Balancer with global access enabled.

Let’s discuss them one by one.

DNS Geolocation Routing policy with health checks

Cloud DNS supports health checks for internal TCP/UDP load balancers that have global access enabled. Also, an appropriate routing policy within Cloud DNS also needs to be configured. In this case, we are going with a geo routing policy. Geo routing policy. This policy will direct the whole traffic coming from us-central1 region to the us-central1 Internal load balancer and similarly traffic coming from region 2 will be routed to load balancer in the second region. All other traffic from other regions will be rerouted based on which region is closer.

This policy leverages the load balancer health checks [only internal TCP/UDP load balancers] to determine whether to resolve the domain name to that particular load balancer.

TCP load balancer with Global access

Global access will be enabled on the Internal TCP Load balancers so that cloud DNS supports the health checks. By Global access, we mean that the internal clients who are sending the request to these load balancers could reside in any region, but the backends of these load balancers need to be in the same region as the load balancer.

End-to-End

So, this is how the whole flow will look like-

Cloud DNS resolving FQDN to respectively Load Balancer IP closer to clients

Requests from internal clients or customers use a domain name to reach Apigee. The resolution is directed to privately hosted Cloud DNS to resolve it to the IP address of the load balancer. Cloud DNS selects load balancer ip addresses based on the region from where the traffic is coming, as determined by the geolocation policy. This policy can also be configured to use health checks. Thus, if the selected load balancer is not healthy during DNS resolution, Cloud DNS will resolve the ip address to another load balancer in the closest region.

Once the resolution is complete, the request is sent to the specific load balancer, which forwards it to the backend, which is a MIG that redirects all requests to the Apigee Instance.

Thus such multi-region failover setup can help to improve the availability of Apigee services by providing a backup region in case of an outage in the primary region as shown below

Cloud DNS resolving the FQDN to Load Balancer IP in another region

Steps to create above setup

Step 1 — Setting up the internal Load Balancer

1. Create an HTTPS health check.

gcloud compute health-checks create https test-health-check \
--region europe-west1 \
--port 443 \
--request-path /healthz/ingress

2. Create a backend service.

gcloud compute backend-services create network-lb-backend-service \
--load-balancing-scheme=INTERNAL \
--network apigee-network \
--protocol TCP \
--health-checks test-health-check \
--health-checks-region europe-west1 \
--region europe-west1

3. Add instance groups to backend services.

gcloud compute backend-services add-backend network-lb-backend-service \
--instance-group mig-ew1 \
--instance-group-zone europe-west1-b \
--region europe-west1

4. Create the forwarding rule

gcloud compute forwarding-rules create network-lb-forwarding-rule-ipv4 \
--load-balancing-scheme INTERNAL \
--region europe-west1 \
--ports 80 \
--backend-service network-lb-backend-service \
--allow-global-access \
--network apigee-network \
--subnet apigee-exposure-1

NOTE: You’ll also have to enable certain firewall rules as well.

Step 2 — Setting up Cloud DNS with health checks

1. Create a private Cloud DNS managed zone

gcloud dns managed-zones create eg-dns-zone \
--dns-name=apg.local. \
--description="Private DNS zone for network1-vpc" \
--visibility=private \
--networks=apigee-network

2. Add a record in the managed zone

gcloud dns record-sets create foo.apg.local. \
--type=A \
--ttl=60 \
--routing-policy-type=GEO \
--routing-policy-data="europe-west1=network-lb-forwarding-rule-ipv4;europe-west2=network-lb-forwarding-rule2-ipv4" \
--enable-health-checking \
--zone=eg-dns-zone

This setup to have a failover access route for Apigee instances can also be replicated for any other backend resources like compute engine or cluster served by internal load balancer.