In this Part3 of this topology blog series, we will talk about a topology that has TMG proxy and with application tiers being load balanced with Windows NLB. We will also touch upon testing with Lab Environments that has one of their tiers (DB tier for this discussion) outside of the Lab Environment.
Take a look at Part1 and Part2 following the links.
Here is the recap of acronyms that we have been using in this blog series
And few more that we would be using in this discussion…
This topology has following components in Corp network
Following are the components in Test network
We have already seen how to configure multiple application tiers in both Part1 and Part2 and have specifically seen how to configure application tiers with same AT service account in Part1. The Windows firewall settings for controlling test traffic in and out of Corp network have also been discussed earlier in Part1.
So for our current discussion we will only talk about specific configuration requirements in TMG, Windows NLB and any AT configurations for enabling Visual Studio Lab Management 2010. We will also discuss about the implication of one of the App tier (DB tier in our case) being outside of Lab Environment with regard to ALM scenarios.
http://technet.microsoft.com/en-us/library/cc775749(WS.10).aspx talks in detail about how to create and manage load balancing clusters.
For our discussion, let’s assume we had the clustering mode as “Multicast” for this topology. You can also have the cluster mode as “Unicast” in your setup and that does not impact the behaviour of Visual Studio Lab Management 2010.
In our case, the configuration looks as below once the AT machines have been added as part of the NLB cluster.
http://technet.microsoft.com/en-us/library/cc441445.aspx talks in detail about Forefront TMG deployment.
After Installing the enterprise, Please open the forefront TMG wizard
After successful configuration add the firewall policy rule for enabling traffic to application tier:
Right click on "Firewall Policy" and create a "New" -> "Web Site Publishing Rule" for "Outbound ports".
The firewall rules for our topology looks as below once configured:
Listening on both External and Perimeter networks
Redirecting both HTTP and HTTPS connections to HTTP endpoint of application tier
Certificates for listening exposed HTTPS endpoint of TFS website in proxy
Exposed public name
Post this configuration, all the connections made to the Public name listened by the TMG proxy will be forwarded to the Cluster IP (192.168.1.10). The request will be load balanced and will be handled by one of the ATs which is part of this cluster.
Since in our case the ATs are not directly exposed outside of corp network, both the ATs will have the TFS website bound to http. There is explicit binding to its Cluster IP, Dedicated IP and Loop back in this case.
The notification URL will be set the public name that is being listened by TMG. Launch TFS Admin Console –> Application Tier –> Change URL
The server URL will remain as loopback IP.
Given that Lab URL will be consumed only by Controller which is within the Corp network, we will change the default value of Lab URL to point to the HTTP endpoint of the local corpnet URL listened by TMG. By default the LAB URL will be same as notification URL, which in our case will be the publicly exposed name listened by TMG.
The steps to configure Controllers are same as described in Part1 and Part2. Mention the local corpnet URL listened by TMG (same as what we configured for Lab URL) while providing the TFS URL during configuration.
Your Lab Environment may not always contain all the tiers within itself. There could be situations when one of the tier has to be outside of LE. Some of the reasons why a DB tier can be outside of the environment are
When such an environment is used for testing, we will have to be mindful of few aspects that will impact the overall Lab Management 2010 ALM scenarios.
When one of the tier is not part of the LE, your manual testing scenarios or your build deploy test scenarios involving restoring snapshot to the clean state in the LE will only being the Lab systems within the LE to clean state. The tier which is outside of the LE will not be in consistent with rest of the tiers which may not be the required state for your testing to progress.
Facts to be mindful while testing manually
In summary, Visual Studio Lab Management 2010 has no knowledge of external dependencies of a LE and the user has to ensure that overall state of LE and its dependencies is maintained.
Customizing workflow to clean the external tier
To get the outside tier in a consistent state, you can customize your workflow template to clean up the tier outside during restore checkpoint.
Below is snip of how a customized workflow looks for our scenario where the DB tier is outside:
Add a invoke process activity which would invoke a remote script in DB machine that does the required cleaning
The below invoke process will be executed from build controller. Ensure that the credentials provided have enough privileges to do the cleanup in the data tier.
Network isolation and a LE tier outside
Cloning of a domain joined isolated application requires an AD inside the environment. Since AD VM is NOT connected to the external network in isolated environments, you can’t have any trust relationship between corp domain and the AD inside LE. For this reason, network isolation would not work for domain joined application if some pieces of that app, such as, DB were outside the LE.