I was asked today about using (W2008 R2 SP1 Hyper-V) Dynamic Memory and Forefront Threat Management Gateway (TMG). To be honest, I hadn’t looked at TMG on virtualisation before – Microsoft has a huge product catalogue.
I searched, and found a long and detailed article on the subject. The guidance starts with understanding the network role of the TMG installation in question. That means understanding workloads (network and server) that the VM will be handling. This leads to some general TMG configurations, which will obviously affect resource requirements and performance. We are reminded that the TMG VM will be sharing a host with other VM workloads, and therefore a spiking TMG VM could affect resource utilisation of other VMs. Consider this when sizing hosts or placing virtual machines. The TMG group recommends doing a 2 week proof-of-concept or assessment to gather empirical data for this sizing process. TMG will eat CPU and memory.
Speaking of memory, a SQL back end is used for logging. This is normally an Express install. This edition (at the moment) doesn’t have the ability to deal with expanding memory such as Hyper-V Dynamic Memory. The minimum RAM for TMG is 2 GB. Well, SQL Express has a “one GB memory limit for the buffer pool”. If you decide you must enable DM on your TMG VM(s), then maybe you should set the start up memory setting for a TMG VM to 2048 MB. That will leave SQL Express in a healthy state in terms of memory (knowing how much to take at startup) and will ensure that TMG always has the minimum required. You can set your maximum memory setting to what you find is required after your assessment.
Physical networking is discussed. Any VLANing or DMZ/edge network designs for a physical installation should still apply. Don’t redesign or compromise the network design to suit virtualisation; do redesign the virtualisation hosts to suit the network and security requirements.
Ideally, a host used for providing capacity to network security VMs should not run other VM roles, e.g. you ideally won’t mix Exchange VMs and TMG VMs on the same host. But hey, sounds great in mid/enterprise environments but a bit pricey for SMEs.
There’s lots of advice on lock down policies, patching, and enabling BitLocker on the parent partition. And of course, only provide access to the parent partition as and when is (business critically) required.
An interesting one which might answer many forum questions, the TMG group recommends that internal and external virtual NICs should not share virtual switches. That means you should ideally use different physical NICs for those networks, and maybe use different virtual NICs that are created by your network provider (e.g. Broadcom, HP NCU, etc).
There is a reminder to disable everything except the virtual switch protocol in the parent partition NICs that are used for external virtual switches.
You should have a way to log into or manage/monitor the parent partition separately from the virtual machine workloads. In other words, have a dedicated parent partition physical network card that is not used by virtual networks. This will allow you to manage the parent partition and it’s other workloads if something like a DOS attack happens and the internet facing NIC for the TMG VM is being hammered.
For your virtual machine disks, it is recommended that you place OS, SQL logs on different drives. If you are using host server internal disks then you’ll need to create different LUNs. Things aren’t that simple in a SAN where virtual disk systems are used, because different LUNs are actually striped across the same disks in the disk group. I’d consider a CSV with all VHDs on there. And then you get into the normal CSV/backup design decision making process. Remember to keep IOPS requirements (from the assessment) in mind.
The article ends with a discussion of various virtual networking designs and how they will impact on the performance of your TMG VM.