If you would like to read the next parts in this article series please go to:
- TMG Firewall Options for Scalability and High Availability (Part 2)
- TMG Firewall Options for Scalability and High Availability (Part 3)
When you’re considering any kind of design for your network infrastructure in general, and your TMG deployment in particular, two of the “abilities” that you need to factor in are those of scalability and high availability. Scalability will enable you to grow your firewall deployment to meet the traffic needs of your organization in the future. High Availability will make it possible to have the longest uptime possible. This combination of scalability and high availability comprise one of the characteristics that separate enterprise level deployments from those seen in mid-sized and small businesses.
TMG options supporting scalability and high availability
First, let’s review some of the features and functionalities in TMG that make it able to offer what enterprises need. The TMG firewall is able to meet enterprise-level scalability and high availability requirements by providing the following:
- Support for multiple Internet Service Providers so that if one of them becomes unavailable, another Internet Service Provider can take its place without disruption of service to users.
- Support for the ability to deploy multiple TMG firewalls so that they act as a single logical firewall wherein all the members of that logical firewall share the same configuration settings (arrays).
- Support for high availability of the web servers that are published by the TMG firewall or TMG firewall array.
Notice that the first two options apply to the TMG firewall itself, whereas the third high availability option applies to other machines (servers) that are being protected by the TMG firewall.
Let’s now take a look at these options in more detail.
Scalability and TMG arrays
Let’s start with the logical firewall concept that allows for scalability. In order to achieve your scalability goals, you can deploy TMG firewalls in an array. This is in contrast to a standalone deployment of the TMG firewall. The TMG firewall array is different because multiple TMG servers can participate in array. There are several advantages that you can accrue from using arrays:
- Distributed caching. When you deploy a TMG firewall array, you can take advantage of the Cache Array Routing Protocol (CARP). When you deploy CARP, each member of a firewall array will be responsible for a percentage of the total possible URL space so that when you combine all the firewalls in the array, the total URL space is covered. This can significantly speed up cache response time because the size of the cache on any single member of the array is going to be smaller than if the entire cache was contained on a single TMG firewall.
- High Availability. A TMG firewall array increases availability by allowing you to deploy multiple TMG firewalls in a single logical configuration where members of the array can “pitch hit” for one another. In other words, if one of the members of the TMG firewall array becomes unavailable, other members of the array will still be online to service both outbound and inbound requests. Outbound requests from internal clients will be routed automatically to the TMG servers that are still running, and inbound connections will be automatically load balanced to an available server using the in-box Network Load Balancing protocol.
- Scalability. Over time, as your business grows, there’s a good chance that you’re going to need to support more and more users who connect to the Internet. However, even if your user base stays the same and you don’t have to support more users, there’s a good chance that your existing users are going to need even more bandwidth over time as bandwidth-hungry applications such as remote video conferencing become more commonly used, and this is also likely going to be related to increased use of cloud storage and other cloud based systems. As the cloud begins to take over many of the duties of your on-premises datacenter, you’re going to need ever-increasing amounts of bandwidth to support those connections to the cloud. The TMG firewall will be able to help with these requirements.
For any enterprise deployment that requires high availability and scalability, your first stop is going to be the TMG firewall array. The process of array deployment is different from that of single, standalone TMG firewalls. With a single standalone TMG firewall, all of the configuration settings are stored in the Registry on that local TMG firewall. On the other hand, when you configure an array, you’re going to need to have some kind of centralized storage, because multiple TMG firewalls are going to need to reference a single configuration in order to support a single logical TMG firewall configuration. Of course, each of the members of the TMG firewall array is also going to have some per-server configuration settings that are kept on that specific machine. However, it’s best to keep these to a minimum, for example by using some sort of desired configuration management system such as System Center Configuration Manager (SCCM) – that will make adding and removing members of the firewall array a lot easier in the future.
Types of TMG firewall arrays
Now that you have a basic understanding of the difference between an array and a single TMG firewall, let’s take that understanding a step farther and look at the differences between different types of arrays. There are two types of TMG firewall arrays:
- Standalone array
- Enterprise Management Server (EMS) managed arrays
Leave it to Microsoft to make things more confusing than they need to be; I say that because single TMG firewalls are also referred to as “standalone” firewalls. That said, there is a big difference between a standalone TMG firewall and a standalone TMG array. A standalone array is a real TMG firewall array that supports multiple TMG firewalls as a single logical firewall. In fact, a standalone array will support up to fifty TMG firewalls in the array. You can use this type of array when you plan to use an array in a single location and you don’t want to have to manage a separate server as an Enterprise Management Server for shared storage support. With a standalone array, one of the members of the standalone array will be responsible for the shared storage instead of that being handled by a separate Enterprise Management Server.
The other type of array is the EMS array. You would choose this option when you plan to have multiple TMG firewall arrays, which are typically in different physical locations. The shared storage is contained on a dedicated server that acts as the Enterprise Management Server. The EMS is able to support up to 200 arrays, whereby each of the arrays can contain up to 50 TMG firewalls each. If you do the math, you can see that this means that the EMS is able to support up to 10,000 TMG firewalls. That’s a lot of firewalls!
Actually, it gets better than that. How? You can manage many more TMG firewalls using an EMS server to support the configuration because you can replicate the EMS settings to up to 15 other EMS servers that can support up to 10,000 TMG firewalls. Doing the math again shows that you can now support up to 150,000 TMG firewalls. Wow.
Load balancing across a TMG array
One of the key capabilities that is enabled by TMG firewall arrays is load balancing. One thing you don’t want to happen is to have a single TMG firewall burdened with more of a traffic load than it has to have. When the TMG firewall handles traffic, it naturally puts a load on the memory and processor on that machine. In addition, there’s a possibility that you may hit bandwidth limits if all the traffic goes to a single TMG firewall, so you’re going to want to make sure that the traffic is as evenly distributed as possible across all the members of the TMG firewall array.
For outbound traffic, there are a couple of ways that you can do this. With web proxy connections, you can configure the web proxy clients to take advantage of WPAD. When they are configured to use WPAD, they will obtain a web proxy client configuration script from the TMG firewall array. Among other things, this script will provide the web proxy client with information regarding which firewall in the array to use when making a request for a particular URL. In this way, web proxy client requests will be evenly distributed among members of the TMG firewall array.
For non-web proxy client requests, you can take advantage of the Network Load Balancing (NLB) protocol that comes with Windows Server or you can use an external hardware load balancer. The built in NLB protocol works pretty well, so if you haven’t already invested in putting an external load balancer in place, you should give NLB a look. There are several advantages to using NLB:
- Firewall rules that you configure on the array will automatically work with NLB. You don’t have to do a complex configuration on an external load balancer to get load balancing to work with your firewall rules.
- Cost is a big advantage here. Because the NLB protocol comes with the Windows Server license that you use to install the TMG firewall software, you are essentially paying nothing for the Network Load Balancing support that is tightly integrated with the TMG firewall software.
- Network Load Balancing is very flexible and you can use it to help manage firewalls that need to be taken out of service for maintenance by taking advantage of the ability to slowly drain the connections from that firewall. Once the last connection has been disconnected, no more connections will be added to that firewall and you can take it offline to service the software or hardware.
Note that for inbound connections, there is no web proxy client option, so the only load balancing mechanism you have available is network load balancing or an external hardware load balancer.
In this article, we began our discussion of high availability and scalability design considerations for the TMG firewall. We saw that we can have HA and scalability by taking advantage of multiple ISPs and by configuring TMG firewall arrays. Then we learned about the different types of TMG firewalls arrays and finished up with a discussion about how you perform load balancing for TMG firewall arrays. We’ll continue the discussion next time in Part 2 of this series by discussing enterprise storage and multiple ISP support in more detail.
If you would like to read the next parts in this article series please go to: