Forum Discussion

Patrik_Jonsson1's avatar
Patrik_Jonsson1
Icon for Altocumulus rankAltocumulus
Feb 04, 2017

GTM - Lingo translated from an LTM perspective (and monitoring)

Dear experts

I've set out to find typically good stuff to monitor on the GTM and to do that I had to re-evaluate some terms and things I took for granted from the LTM world. I thought I'd share what I have written down.

Hopefully it will help some other poor soul coming from the LTM side to get the grip of the basics. Please do comment if (or actually rather when) I've misunderstood something?

A diagram of a basic set-up

Lingo

Server

This is the equivalent of an F5 unit (or a generic server).

Data center

This is more or less just a container with

Servers
in them. Data center availability is determined by doing an aggregate checks of
virtual server
statuses. If all virtual servers are down, the
data-center
is down, otherwise not.

Virtual server

These are the classical virtual servers we know from the LTM.

Wide IP

This is the actual dns record and it's aliases. The wide IP uses a pool containing one or more LTM

virtual servers
(or, a manually defined fallback server IP).

The GTM uses the pool to select the best server based on criteria defined by the admin (GEO-IP based, connections, just plain round-robin, irules etc.).

Link

A link is a possible path to the internet. In case a GTM is connected to multiple routers it can also use multiple links in case one, or more of the routers is unavailable. If all links are down, the objects monitored via those links also goes down. If no link is specified the GTM would use the configured routing.

Listeners

This is where the clients would send their DNS queries. You must have at least one in order for GTM to work, but more than one is also possible.

Monitoring of virtual servers

The GTM would not monitor F5 devices like the LTM monitors its pool members and nodes. Instead it establishes a trust with the devices by running the

bigip_add
(a bit like device trust) and then the monitoring is done through iQuery.

Monitoring

In order to get a basic monitoring going I've thought out the following parts. Please let me know if something should be added?

Availability:

  • Server availability
  • Data center availability
  • Virtual server availablity
  • Wide IP availability* Link availability
  • Status of iQuery

Statistics:

  • Memory, CPU, throughput etc
  • Requests per Wide IP
  • Unhandled requests per Wide IP
  • Total requests per GTM
  • Total unhandled requests per GTM

Any comments/feedback very much appreciated!

4 Replies

  • I'd like to add some info on generic-host [non-F5 product] monitoring.

     

    Generic host - it's an object, representing some device which can host services [virtual-servers]. It's like a container for non-F5 virtual-servers.

     

    Prober pool - an ordered list of F5 GTM devices that determines where probes are sourced from. It is also a way to create redundancy for probing. (there are many other scenarios, that's just one of them)

     

    Guidelines I use when working with generic-hosts:

     

    1. If you create a new data-center, always assign a prober pool to it. Choose the closest one to your generic-host server among available. If you don't, all F5 devices (LTMs, GTMs) within the data-center hosting that generic-host server will start sending probes to virtual-servers hosted by it. This will ultimately cause firewall drops / monitor flaps / chaos.
    2. Make a generic-host server inherit prober-pool from the DC.
    3. Do not assign monitor to a generic-host server. We are more interested in status of virtual-servers rather then a box itself.
    4. Assign monitor to ALL virtual serves which are “hosted” by generic-host server . Choose the monitor based on application type running.
    5. Always adjust firewall rules so that ALL GTM’s in your prober-pool could reach your virtual servers.
    6. When building a GSLB pool, there is no need to apply any monitors to a pool consisting of virtual-servers, which are hosted by a generic-host server. It will be automatically marked red/green based on virtual-servers' state.

    This approach allowed me standardize / simplify my work with generic-hosts.

     

    Cheers