In previous parts of our series, we learned that NGINX is superior to cloud load balancers for two reasons: 

• Breaking free from vendor lock-in; NGINX is a solution applicable to any infrastructure/environment
• Cloud providers offer basic load balancers that route and encrypt traffic to endpoints. They lack in:
  • Visibility; Logs, traces, and statistics
  • Functionality; Advanced traffic management and security use cases (see part 2 and 3)

Functionality is especially important when scaling the environment to multiple cluster groups. The bulk of this section will be addressing best practices in scaling the architecture in part 2 and 3.

Below I will depict a reference architecture that replicates my Kubernetes cluster with an NGINX Ingress Controller deployment and NGINX Load Balancer with HA (High Availability).

If you recall from the part 2 and 3 of our series, I configured many ZT use cases on my NGINX Plus external load balancer. I replicated my NGINX Plus external load balancer to an active-active HA setup with NGINX Plus based on keepalived and VRRP. The method of fully rolling out HA in production will vary slightly depending on my environment. 

Public Cloud

If I am scaling the architecture in a public cloud environment, I can replicate the NGINX Plus load balancers with cloud auto-scaling groups and front them with F5 BIG-IP. I can also enable health monitors on my BIG-IP so that unresponsive connections will fail-over to healthy NGINX Plus load balancers.

On-Premises

 If I am scaling my architecture on-prem, I can replicate NGINX Plus load balancers with additional bare metal machines or use a virtualization software of my choosing.

The HA solution with NGINX Plus on-prem can be setup in three different modes:

• Active-Passive; One instance is active, and the other is redundancy. the VIP (Virtual IP) will switch over to the redundancy node when the master node fails.
• Active-Active; Both instances are active and serving traffic. Two VIPs are required, where each VIP is assigned to an instance. If one instance becomes unavailable, the assigned VIP will switch over to the other instance and vice versa.
• Active-Active-Passive; Adding an additional redundancy node to the Active-Active HA pair resulting in a three node cluster group. The redundancy node will switch on when both active nodes are down.

Choosing between these modes will depend on my current priorities.

Going with the active-passive model, I compromise efficiency for lower cost. The active node is prone to overloading while the redundant node is idle and mostly not serving traffic. Going with the active-active or active-active-passive model, I compromise cost for better efficiency. However, I will need two VIPs and a DNS load balancer (F5 GTM) fronting my NGINX HA cluster.

The table below depicts the three models measured by cost, efficiency and scale.

 

If I have the money to spend and choose both efficiency and scale, then active-active or active-active-passive is the right choice.

Synchronizing data across NGINX Plus Cluster Nodes

Recalling the part 2 and 3, we went through several ZT use cases with the NGINX Plus load balancer. Many of these ZT use cases require shared memory zones to store data and authenticate/authorize users. When scaling out the Zero Trust Architecture with HA, the key-value shared memory zone should be synchronized between NGINX Plus instances to ensure consistency.

Take for example a popular ZT use case; OIDC authentication. Tokens are stored in the Key-Value storage to examine users attempting access to protected back-end applications. We can extend our configuration and enable Key-Val zone sync with two additional steps: 

• Open a TCP medium where key-value data is exchanged. Now that you can also enable SSL on the TCP medium for extra security
• Append the optional sync directive to enable synchronization of key-value shared memory zones defined in openid_connect_configuration.conf from part 2. 

Testing the Synchronization

You can test/validate the synchronization by leveraging the NGINX Plus API to pull data from individual cluster nodes and comparing them. The data pulled from each cluster node should be identical. 
You can connect to NGINX cluster nodes via SSH and enter: 

$ curl http://localhost:8010/api/7/http/keyvals/oidc_access_tokens 

The response data from each NGINX cluster node will match when zone sync is enabled.

Data Telemetry with NGINX Management Interfaces

As my IT organization grows, so will my NGINX cluster groups. Inevitably, I will need a solution that manage complexities arising from expanding NGINX cluster groups to alternative regions and cloud environments. With NGINX management tools, you can: 

• Track your NGINX inventory for common CVEs and expired certificates
• Stage/Push config templates to NGINX cluster groups
• Collect and aggregate metrics from NGINX cluster groups
• Use our Flexible Consumption Model (FCP) model

Installation and Deployment Methods

There are two ways to get started with NGINX management capabilities: 

• F5 Distributed Cloud (XC); No installation or deployment is required. Simply log into XC and access the NGINX One SaaS console. Get started with NGINX One Early Access. 
• Self-Managed Installation; You can deploy NGINX Instance Manager to comply with policies and regulations that make the use of a SaaS console not feasible, for example, for air gapped environments inaccessible from the public internet. You can install and manage your own NGINX Instance Manager deployments by following our documentation. 

Once signed into my NGINX SaaS console, I can install agents on my NGINX HA clusters pair to discover them.

$ curl https://agent.connect.nginx.com/nginx-agent/install | DATA_PLANE_KEY="z" sh -s -- -y

$ sudo systemctl start nginx-agent

I can track my overall NGINX usage and telemetry from either the UI console or APIs. 

Under FCPs (Flexible Consumption Plans), consumption is measured yearly based on the number of managed instances. This model is becoming increasingly popular as customers increasingly opt for flexible pays-as-go licensing models.

Setting up F5 BIG-IP

I touched on 2 options to configure F5 BIG-IP depending on my cloud environment. In on-prem environments with active-active HA targets, I need to configure F5 DNS load balancing. I will now step through how to configure DNS load balancing on BIG-IP. 

The first step is to create a VS (Virtual Server) listening on UDP with service port 53 for DNS. 

Then I create a wide IP with name 'nginxdemo.f5lab.com'. This will be the domain I will use to connect to my BIG-IP DNS load balancer. 

If I click on the 'Pools' tab, I can see my gslbPool members, where each member will correspond to VIPs assigned to my NGINX Plus HA cluster nodes. 

I also need to create a datacenter with a Server List on the NGINX HA cluster nodes and the BIG-IP DNS system. Under DNS>>GSLB : Servers : Server List, I can start adding my NGINX members and BIG-IP DNS system.

Note: In a public cloud environment, I typically will not need to configure GSLB on the BIG-IP. I can simply create a VirtualServer with HTTPS and service port 443 and NGINX Plus pool members with a health monitor for redundancy fail over.

Conclusion

As we progressed in our series, I expanded my architecture to address scalability concerns that inevitably surface to any business. However, the IT architecture of a business needs to be flexible and agile if it wants to thrive, especially in this modern competitive landscape.

The solutions I presented in these series are fundamental building blocks that can technically be implemented anywhere. They enable organizations to quickly maneuver and seek out alternative options when current ones are no longer viable, which brings me to the topic of AI. 

How will enterprises adopt AI in the present and future? Ultimately it will come down to extending reference architectures (like the ones discussed in this series) with AI components (LLMs, Vector DBs, RAG, etc...). These components plug into the overall architecture to improve automation and efficiency in the overall business model.  In the next series, we will discuss AI reference architectures with F5/NGINX.