Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

LTM vs GTM

DZone's Guide to

LTM vs GTM

In this article, we review the basic architecture of Disaster Recovery sites, and how they can help increase the performance of your web app.

· Performance Zone ·
Free Resource

xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.

In today's arena, keeping a replica of your production site is a necessity and Disaster Management plays an important role here. If you are Disaster Management Ready, then it will always make sense for organizations to invest in having multiple sites ready to be used as a production site.

A Global Trafic Manager plays an important role in redirecting traffic from a production site to the Disaster Recovery Site. Above the LTM sits the GTM, which uses the 3DNS URL to hit any site.

Down the line, LTM uses the secure port (HTTPS) and any other non-secured (HTTP) port to redirect traffic as appropriate. This whole ecosystem of LTM and GTM has eaten up legacy routing products. All router manufacturing organizations are now working a new concept, a vRouter, which will have the capability to maintain traffic across multiple sites without impacting an application's end performance.

Below is a typical, albeit simple, scenario, where the GTM (https://google.com) sends secured HTTP traffic over the network to its Local Traffic Manager (LTM) and the LTM then redirects that traffic to its respective site.

Image title

It is always mandatory to define the Architecture Model which applications will follow, to provide high availability within this whole ecosystem in order to ensure effective Disaster Recovery. 

For example, any production and DR (Disaster Recovery) site can follow an Active-Active or Active-Passive model. Many architects also call it the Hot-Hot or Hot-Cold models, in practice.

Now, how do we define Active-Passive or the other model at the application level? It is up to the Application Designer/Architect to determine how they want to come up with a mechanism to recognize the active and passive sites. Usually, a Site Status page is available at the server level (i.e. the site status page can be viewed using the server URL ), which shows if the application's site is active or passive. 

For example: https://<hostname>:<port>/<contextName>/pages/sitestatus.html

A typical example of the result of hitting the site status page on an active site would read: "Site is up." And a passive site would show, "Site is Down," at any given time.

Now, whenever an active site becomes a passive site (and vice-versa), it's important to update the site status page (either manually or using automation).

Although this model is preferred to a DataCenter specific Application Infrastructure Model, it also plays a very important role when using a Cloud platform. 

This whole ecosystem of Disaster Recovery Management will also help make your application ready for the cloud.

Discovering, responding to, and resolving incidents is a complex endeavor. Read this narrative to learn how you can do it quickly and effectively by connecting AppDynamics, Moogsoft and xMatters to create a monitoring toolchain.

Topics:
performance ,disaster recovery ,web application performance ,cloud performance

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}