Home > Blogs > VMware Consulting Blog


Geo-Location Based Traffic Management with F5 BIG-IP for VMware Products (PoC)

Spas_KaloferovBy Spas Kaloferov

The increasingly global nature of content and migration of multimedia content distribution from typical broadcast channels to the Internet make Geo-Location a requirement for enforcing access restrictions. It also provides the basis for traditional performance-enhancing and disaster recovery solutions.

Also of rising importance is cloud computing, which introduces new challenges to IT in terms of global load balancing configurations. Hybrid architectures that attempt to seamlessly use public and private cloud implementations for scalability, disaster recovery and availability purposes can leverage accurate Geo-Location data to enable a broader spectrum of functionality and options.

Geo-Location improves the performance and availability of your applications by intelligently directing users to the closest or best-performing server running that application, whether it be physical, virtual or in a cloud environment.

VMware vRealize Automation Center (vRA) will be one of the products in this Proof of Concept (PoC) for which use case(s) for Load balancing and geo-location traffic management will be presented. This PoC can be used as a test environment for any other product that supports F5 BIG-IP Local Traffic Manager (LTM) and F5 BIG-IP Global Traffic Manager (GTM). After completing this PoC you should have the lab environment needed and feel comfortable enough to be able to setup more advanced configurations on your own and according to your business needs and functional requirements.

One of the typical scenarios which involving Geo-Location based traffic management is the ability to achieve traffic redirection on the basis of the source of the DNS query.

Consider a software development company that is planning to implement vRealize Automation Center to provide private cloud access to its employees where they can develop and test their applications. Later in this article I sometimes refer to the globally available vRA private cloud application as GeoApp. Our GeoApp must provide access to the company’s private cloud infrastructure from multiple cities across the globe.

The company has data centers in two locations: Los Angeles (LA) and New York (NY). Each data center will host instance(s) of the GeoApp (vRealize Automation Center). Development (DEV) and Quality Engineering (QE) teams from both locations will access the GeoApp and use it to develop and test their homegrown software products.

Use Case 1

The company has made design decisions and is planning to implement the following to lay down the foundations for their private cloud infrastructure:

  • Deploy two GeoApp instances using vRealize Automation Center minimal setup in the LA data center for use by Los Angeles employees.
  • Deploy two GeoApp instances using vRealize Automation Center minimal setup in the NY data center for use by New York employees.

The company has identified the following requirements for their GeoApp implementation:

  • The GeoApp must be accessible to all the employees, regardless if they are in the Los Angeles or New York data center, under the single common URL geoapp.f5.vmware.com.
  • To ensure the employees get a responsive experience from the GeoApp (vRA) private cloud portal website, the company requires that LA employees be redirected to the Los Angeles data center and NY employees be redirected to New York data center.
  • The workload of the teams must be distributed across their dedicated local GeoApp (vRA) instances.

This is roughly represented by the diagram below:

SKaloferov vRA 1

  • In case of a failure of a GeoApp instance, the traffic should be load balanced between available instances in the local data center.

This is roughly represented by the diagram below:

SKaloferov vRA 2

Use Case 2 

The company has made design decision and is planning to implement the following to lay down the foundations for their private cloud infrastructure:

  • Deploy 1x GeoApp instance using VMware vRealize Automation Center (vRA) distributed setup in the Los Angeles  datacenter for use by the LA employees. In this case the GeoApp can be seen as a 3-Tier application, containing 2 GeoApp nodes in each tier.
  • Deploy 1x GeoApp instance using VMware vRealize Automation Center (vRA) distributed setup in the New York datacenter for use by the NY employees. In this case the GeoApp can be seen as a 3-Tier application, containing 2 GeoApp nodes in each tier.

The company has identified the following requirements for their GeoApp implementation:

  • The GeoApp must be accessible from all the employees, regardless if they are in the Los Angeles or the New York datacenter, under a single common URL geoapp-uc2.f5.vmware.com.
  • To ensure that the employees get a responsive experience from the GeoApp (vRA) private cloud portal website, the company requires that the Los Angeles employees be redirected to Los Angeles datacenter and the New York employees be redirected to New York datacenter.
  • The workload must be distributed across the Tier nodes of the local GeoApp (vRA) instance.

This is roughly represented by the diagram below:

SKaloferov vRA 3

  • In case of failure of a single Tier Node in a given GeoApp Tier, the workload should be forwarded to the remaining Tier Node in the local datacenter.

This is roughly represented by the diagram below:

SKaloferov vRA 4

  • In case of failure of all Tier Nodes in a given GerApp Tier , the workload of all tiers should be forwarded to the GeoApp instance in the remote datacenter

This is roughly represented by the diagram below:

SKaloferov vRA 5

Satisfying these requirements involves the implementation of two computing techniques:

  • Load balancing
  • Geo-Location-based traffic management

There are other software and hardware products that provide load balancing and/or Geo-Location capabilities, but we will be focusing on two of them to accomplish our goal:

  • For load balancing: F5 BIG-IP Local Traffic Manager (LTM)
  • For Geo-Location: F5 BIG-IP Global Traffic Manager (GTM)

Based on which deployment method you choose and what functional requirements you have you will then have to configure the following aspects of F5 BIG-IP devices, which will manage your traffic:

  • F5 BIG-IP LTM Pool
  • F5 BIG-IP LTM Pool Load Balancing Method
  • F5 BIG-IP LTM Virtual Servers
  • F5 BIG-IP GTM Pool
  • F5 BIG-IP GTM Pool Load Balancing Method (Preferred, Alternate, Fallback)
  • F5 BIG-IP GTM Wide IP Pool
  • F5 BIG-IP GTM Wide IP Pool Load Balancing Method
  • F5 BIG-IP GTM Distributed Applications Dependency Level

Implementing the above use case with GTM and LTM is roughly represented by the diagram below:

SKaloferov vRA 6

Implementing Use Case 2 (UC2) with GTM and LTM is roughly represented by the diagram below:

SKaloferov vRA 7

 To learn more about how to achieve the goal of Geo-Location Based Traffic Management using F5 BIG-IP Local Traffic manager (LTM) and F5 BIG-IP Global Traffic Manager (GTM) please visit Geo-Location Based Traffic Management with F5 BIG-IP for VMware Products (PoC)


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

2 thoughts on “Geo-Location Based Traffic Management with F5 BIG-IP for VMware Products (PoC)

  1. Spas Kaloferov

    HI Roshan,
    if you go to the bottom of the page and follow the link to the full article you will find out that in Part 4 i define GTM Topology Regions and Records. I define both external networks by subnet and then define that connections coming from the external subnet in LA should be forwarded to the LA GTM Pool and connections from the external subnet in NY should be forwarded to the NY GTM Pool.
    Best Regards,
    Spas Kaloferov

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*