Scribd
Upload
10 views2 pages

GTM Best Practices and Notes For Large Configurations-V2

This document outlines best practices and considerations for managing large GTM configurations, specifically those exceeding 500 wideips, 500 pools, and 1000 virtual servers. It emphasizes the importance of using appropriate hardware models, memory provisioning, and upgrade procedures to ensure optimal performance. Additionally, it provides insights on synchronization processes and the handling of Zonerunner in large setups.

Uploaded by

other.yeung
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
10 views2 pages

GTM Best Practices and Notes For Large Configurations-V2

This document outlines best practices and considerations for managing large GTM configurations, specifically those exceeding 500 wideips, 500 pools, and 1000 virtual servers. It emphasizes the importance of using appropriate hardware models, memory provisioning, and upgrade procedures to ensure optimal performance. Additionally, it provides insights on synchronization processes and the handling of Zonerunner in large setups.

Uploaded by

other.yeung
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

GTM Best Practices and Notes for Large Configurations

Notes from SA group


Sept. 29, 2008
V 2.0

Summary
This is a collection of thoughts and best practices with regards to GTM and different field experiences
from dealing with customers with large configurations. Please feel free to send me comments or your
experiences with other types of large GTM configurations. There are still some types of large
configurations that I have not been able to gather information about yet.
- Large (70,000 entries) User-Defined region topology files such as from MaxMind.
- Large (5,000) topology.inc file based on subnets
- Large (50+) number of BIG-IP LTM devices talking to a small (2) number of GTM’s where
the LTM’s have roughly 200 virtuals each.

For the purpose of this discussion, when I use the term “large config”, I am referring to a configuration
that has more than 500 wideip’s, 500 pools and 1000 virtual servers.

If you believe that a customer will have this type of large configuration, you should be selling them
1600’s or 6400’s. The 1500 and the GTM module IS A BAD CHOICE!
There is more information on the 6400 since it has been out longer but in very limited testing, the 1600
seems to be performing almost as well as the 6400, at least from a GUI perspective. Monitoring of these
large configurations hasn’t been tested yet.

For customers with these large configurations, the best minimum version to be running is 9.4.5 with HF2.

Usually, with a large configuration, the bottlenecks on the GTM are the responsiveness of the GUI and
how many virtual servers the GTM’s can monitor simultaneously.

It is better (less overhead on GTM) to have GTM monitoring LTM’s with iQuery than to have GTM
monitoring generic servers directly.

DB Keys
There are two DB keys that are commonly used when you encounter a large GTM configuration.
db Provision.extraMB (Valid in 9.3.1 and higher) – Provides more than the default memory to Linux
user land processes which helps the GUI, monitoring and GTM in general. The default allocation in
9.3.X and later to Linux is 384MB. The DB key is additive to the 384MB default so ensure you have
enough RAM in the device to support the increase (512 or higher has been a common setting). As a rule
of thumb, if the GTM has any external monitors configured, PD recommends 1MB of additional RAM be
provisioned for each instance. So if you have a generic server using LDAP external monitors for 5
defined Virtual Servers, that would be 5MB of additional host OS memory required over-and-above the
384MB standard provision.
db Provision.Tomcat.extraMB (Valid in 9.4.5 and higher) – Provides more than the default memory to
Tomcat which deals mainly with displaying GUI pages. Only change this if the customer uses the GUI
and it tends to be sluggish. Setting this to 128 or 256 can alleviate this issue.
Note: These issues are generally tied to the unit utilizing SWAP space. So changing the db variable
should be followed with a reboot if ‘top’ shows the unit has more than 100MB of SWAP in use.

Example commands:
b db Provision.extraMB 512
b db Provision.Tomcat.extraMB 256
Upgrades
When upgrading from 9.3 to any future 9.X version, DO NOT remove each GTM from the
synchronization group or change their sync group name right before upgrading. (Online documentation
used to say you need to do this. It has all been changed.) There is a version check that GTM will run
when attempting to sync which will not allow it to sync to devices that have different versions of software
on it.
If a customer has a very large configuration (over 10,000 virtual servers), you specifically don’t want to
pull the GTM out of the synchronization pool because all ‘stand-alone’ GTMs with a configuration will
become responsible for *all* monitoring. This will put excessive burden on known big3d’s in the
landscape as they will be asked to perform redundant monitoring of objects.
If the customer maintains their own internal root servers, a few good steps you may want to run when
doing the upgrade with a large configuration would be to remove a GTM from the root nameservers or
authoritative nameservers during the upgrade of a particular box. Then, stop big3d with “bigstart
shutdown big3d” and “bigstart shutdown gtmd”. Then, install the IM file. This protects the GTM from
getting to busy while trying to do the upgrade.

Zonerunner
Some people have asked about the ability to disable Zonerunner from the GUI because of slowness with
large configurations. Today, this isn’t possible. There is a ZRD daemon controlled by bigstart, but if you
stop this from starting, then zone syncing won’t work. This would only be OK if you set up a slave/master
scenario between all the GTM’s in a sync group or if you were not using BIND at all. Turning this off
would also render “Return to DNS” unusable as a load balancing method since there will be no BIND.
As of version 9.4.5, when you go into Zonerunner, the first page displayed does not show all the zones, it
only shows a search window. This ensures that this page does not take too long to load with a large
configuration and adds a much needed search feature to Zonerunner.

Syncing
Here is a description of the process that happens when a change is made to a GTM and that change is
synchronized.
1) Change is made on a GTM. That wideip.conf is now newer than the timestamp on all other
GTM’s.
2) That triggers all other GTM’s in the sync group to initiate a pull of the config changes using
rsync. Only the deltas to the wideip.conf are physically transferred.
3) Once each GTM receives the changes and puts them in its’ wideip.conf, a “gtmparse –l” is issued.
4) In a configuration with over 40,000 objects (pool, wideip, virtual, host), this process can take up
to 2 minutes on a 6400/1600 or up to 8 minutes on a 1500. This just means that a change may not
show up in the receiving GTM for a bit.
5) If you are making many changes to the configuration, just note that they might take a few minutes
to show up in the receiving GTM devices.

Upgrade from 3DNS to GTM


Be aware that a step by step document on how to convert 3DNS to GTM is included on the AskF5 site:
https://support.f5.com/kb/en-us/products/big-ip_gtm/releasenotes/related/Migrating_from_3-
DNS_to_GTM.html
This process should not be taken lightly and a full configuration review after the upgrade is suggested.

You might also like