Reference Architecture for Pivotal Cloud Foundry
Overview
Pivotal Cloud Foundry (PCF) is an enterprise-grade Platform as a Service (PaaS) based on the open source Cloud Foundry project. PCF’s container-based architecture will run apps in any programming language over a variety of cloud service providers. This allows developers to use the cloud platform that suits specific application workloads and move those workloads as necessary with no changes to the application.
About Avi Vantage
The Avi Vantage platform is built on software-defined principles, enabling a next generation architecture to deliver the flexibility and simplicity expected by IT and lines of business. The Avi Vantage architecture separates the data and control planes to deliver application services beyond load balancing.
The Avi Components
The Avi Vantage platform has two core components:
-
The Avi Controller
-
The Avi Service Engines
The Avi Controller
The Avi Controller is the single point of management and control that serves as the brain of Avi Vantage. The Avi Controllers continually exchange information securely with the SEs and with one another. The health of servers, client connection statistics, and client-request logs collected by the SEs are regularly offloaded to the Controllers, which share the work of processing logs and aggregating analytics.
The Avi Service Engine
The Avi Service Engines (SEs) handle all data plane operations within Avi Vantage by receiving and executing instructions from the Controller. The SEs perform load balancing and all client and server-facing network interactions.
Avi Vantage for Pivotal Foundry
Avi Vantage works in conjunction with the Gorouter component of PCF. The Gorouter routes incoming traffic from the world to the virtual machines that are running the deployed application, similar to an ingress in Kubernetes. Avi Vantage can also be used to load balance TCProuters at layer 4 for non-HTTP applications.
Avi Vantage can be deployed on-prem or on any cloud ecosystem which allows for easy deployment to load balance application traffic in any ecosystem. Avi offers real time application insights and wide range of metrics to simplify troubleshooting.
Design Considerations
The considerations for deploying Avi for Pivotal Cloud Foundry load balancing include:
- Multi-size architecture (requires GSLB)
- Sizing
The same deployment designs can be used both on premises on vCenter and in public cloud.
Reference Architecture
Avi Vantage can be used as the load balancer for Gorouters as well as global load balancing across availability zones within a datacenter/region or across multiple datacenters/regions.
Local Gorouter/TCProuter Load Balancing
The following methods can be used for routing external traffic destined for PCF-hosted applications to Avi:
-
Static routing / directly connected subnets
-
Upstream router peering using BGP to dynamically advertise Virtual Service IPs
-
NSX-T write access integration
Static Routing / Directly Connected Subnets
This option would use either a directly connected subnet/port group attached to the service engine for virtual service addressing, or would utilize a VIP pool that is reached via static routes configured on the upstream router.
Advantage
- Easy to configure.
Disadvantage
- Traffic must be dispatched from the primary SE to the secondary SEs in a scaled-out scenario, slightly impacting performance (Layer 2 scaleout)
Supported Clouds
-
vsphere write access
-
No access
BGP
This option would use BGP to peer with the upstream routers in order to advertise the VIP address. This increases scalability and performance through ECMP.
Advantage
- Allows greater scale via Layer 3 scaleout
Disadvantage
- Requires configuration on upstream routers
For more information, refer to BGP Support for Virtual Services.
Supported Clouds
-
vsphere write access
-
No access
NSX-T Write Access Cloud
Starting from Avi Vantage version 20.1.1 onwards, we support NSX-T write access cloud type, which allows the service engine to sit adjacent to the NSX-T t1 router and static routes would be programmed automatically.
Advantages
-
SE lifecycle automation
-
Automatic route programming
-
Consistent policy model between Avi and NSX-T
-
SE is contained within the NSX-T overlay environment reducing load on edge nodes
-
Layer 3 scaleout
For more information, refer to Avi NSX-T Integration.
Global Site Load Balancing
Site/AZ load balancing using Anycast
Advantages
-
Less configuration in the load balancer
-
Reduced licensing cost
Disadvantages
-
Requires specialized routing configuration for anycast
-
No way to gracefully drain a site for maintenance, can only pull the route advertisement
-
Not well supported in public cloud
Site/AZ load balancing using Avi GSLB
Advantages
-
Global load balancing analytics
-
Ability to control traffic ratios per site
-
Intelligent health checks
Disadvantages
-
Extra Avi infrastructure and configuration required to handle GSLB functionality
-
DNS forwarding will have to be configured
Health Monitors
In order to validate the health of the GoRouters, an endpoint is provided, that Avi uses to query their health status. Configure the health monitor to target health on port 8080. GoRouter will return 200, if healthy.
For more information, click here.
Sizing Considerations
Avi Controller Sizing
It is recommended to have three Controllers in a cluster configured for production deployments. The Avi Controller requires minimum specifications of CPU, RAM and storage. Refer to the Avi Controller Sizing article for sizing guidelines.
Avi SE Sizing
For PCF deployments, the SE sizing depends on application traffic profiles. Refer to the Sizing Service Engines article for SE sizing guidelines.
The SE performance can be impacted by GoRouter sizing. If GoRouters are undersized for the applications, SE performance will be limited. Backend re-encryption can also reduce GoRouter performance.
Each site will require to be sized for its own SEs with an additional SE for GSLB requirement between sites.