on - edited on by
LiefZimmerman
Application Delivery Challenges
As an application user, we want to access applications whenever and wherever we can - whether it is in the middle of the day or at owl hours; whether we are in our home or while we are traveling in a different state or a different country. No matter what day and time, and no matter where we are, we want to have the same level of application user experience. Slowness? Unreachable? Connection resets? Server errors? We want none of them.
As an application provider, our top priority is to always keep our users happy and provide them with the best user experience they will ever have. If we can't satisfy our users, our business can be at risk. At the same time, we also want to keep up with our application growth, so that we don't miss out any opportunities.
F5 BIG-IP DNS and LTM in Cisco ACI Multi-Site and Multi-Pod
Cisco ACI Multi-Site and Multi-Pod solutions can interconnect multiple Cisco ACI fabrics that can be geographically dispersed. In combining F5 BIG-IP DNS and LTM, we can improve application performance and provide application resiliency and robustness across data centers while keeping up with our application growth. Figure 1 shows an example of a sunny day scenario that application services are delivered efficiently to the users based on their geographical location and user application experience can be enhanced as a result. In case of unexpected events, such as data center went down due to power outage caused by a storm or data center became unreachable due to a network outage, F5 BIG-IP DNS and LTM can continue application delivery by redirecting application request to the next available data center so that the application can continue to be available (figure 2). Although the topology example here uses Cisco ACI Multi-Site, the same concept applies to Cisco ACI Multi-Pod as well.
Figure 1 – Application delivery in a sunny day scenario
Figure 2 – Application delivery in a rainy day scenario
F5 BIG-IP DNS GSLB and LTM
F5 BIG-IP DNS provides tiered global server load balancing (GSLB) to load balance application traffic across data centers. At a high level overview, F5 BIG-IP DNS resolve a DNS request for fully qualified domain name (FQDN) and returns an IP address of a virtual server (VIP) that can reside in any data center across the globe. Traffic sourced from the client flows through the F5 BIG-IP LTM which has the selected VIP and then to an associated real application server that can be deployed in the same data center or a different data center. The followings are the key network design considerations:
- Communication between F5 BIG-IP DNS and LTM via iQuery: this is important to establish communication between BIG-IP DNS and LTM so that they can exchange information, which allows BIG-IP DNS to respond with the best available BIG-IP LTM VIP across data centers from a DNS request. Based on the information exchanged with BIG-IP LTM in each data center, BIG-IP DNS can direct traffic away from a data center that experienced outage or has poor performance, for example. A BIG-IP system communicates to another BIG-IP system using iQuery which is a F5 proprietary protocol runs on port 4353. Thus, TCP port 4353 must be opened on the BIG-IP DNS and BIG-IP LTM systems, and it must also be allowed in the path between them. All iQuery communications are encrypted through SSL. TCP port 22 needs to be opened because secure shell (SSH) protocol is used for iQuery SSL certificates exchange between BIG-IP LTM and DNS so that they are authorized to communicate to each other.
- Application traffic through F5 BIG-IP LTM: BIG-IP LTM is a stateful device, we need to ensure both directions of traffic go through the same BIG-IP LTM (except for direct server return (DSR) which doesn't have such requirement), otherwise, the traffic will be dropped. Source Network Address Translation (SNAT) and ACI Policy Based Redirect (PBR) are options that we can use to fulfill such requirement of steering the return traffic sourced from the real application server and destined to the client through the same BIG-IP LTM.
Understand Your Requirements
There are more than one option to integrate F5 BIG-IP into Cisco ACI Multi-Site and ACI Multi-Pod and it is important to understand both network and application requirements, so that you can derive a possible integration that will satisfy them both. Here are some questions that can help to better understand the requirements:
- How do we handle the return traffic from the real application server to the client? Is F5 BIG-IP LTM doing the SNAT or Cisco ACI fabric doing the PBR to steer the traffic back to the same BIG-IP?
- Are the VIP and its real application servers deployed in the same data center or distributed across data centers?
- Is there a requirement to configure the Self-IP in different data centers in the same bridge domain or different bridge domains?
- Is the VIP in the same subnet as Self-IP or outside of the subnet?
- What High-Availability (HA) Option is used for F5 BIG-IP LTM - independent active/standby HA pair or active/active HA pair in each data center? Or, active/standby HA pair or active/active HA pair stretched across data centers?
- How do the traffic flow between F5 BIG-IP DNS and LTM for information exchange? Is there a firewall in between?
- Where should we deploy F5 BIG-IP DNS to optimize the latency in DNS responses?
- How can we avoid a complete F5 BIG-IP DNS outage? Multiple standalone BIG-IP DNSs across data centers in different regions? High availability BIG-IP DNS pairs? Create BIG-IP DNS synchronization group for BIG-IP DNSs?
To learn more on how to integrate F5 BIG-IP DNS and LTM in Cisco ACI Multi-Site and Multi-Pod, please refer to Cisco ACI Multi-Site/Multi-Pod and F5 BIG-IP Design Guide, a white paper jointly developed by Cisco and F5.
Other DevCentral articles and videos in this series
F5 BIG-IP in Cisco ACI Multi-Site and Multi-Pod - Design Options
F5 BIG-IP in Cisco ACI Multi-Site and Multi-Pod - Design Considerations
Don't forget to check out the Brightboard Lesson - Designing Cisco ACI and F5 Solutions together too!
