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.
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…
Topology #3 – Topology with TMG, Windows NLB and with Test apps having DB tier outside of LE
This topology has following components in Corp network
- Two Application tiers. Both the AT machines are configured with Windows load balancing. Both the App tiers have been configured to run with same domain service account.
- A TMG proxy that controls the traffic flowing into TFS website.
- A single data tier with default SQL instance
Following are the components in Test network
- VMM server, Distributed Library shares, Host machines.
- Test and Workflow controllers
- All the machines have Windows firewall setting that controls the test traffic flow in and out of Corp network.
- Test app deployed with one of the tier (DB tier) being outside of the Lab Environment
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.
1) Windows NLB configurations
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.
- Cluster IP – 192.168.1.10
- AT1 dedicated IP – 192.168.1.2
- AT2 dedicated IP – 192.168.1.1
2) TMG rules configurations
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
- Configure network, system and deployment options in sequence
- While configuring network settings, choose "Back Firewall"
- Please provide all the appropriate data for the rest
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 TFS AT Service.
- Action -> Allow
- From -> External, Perimeter
- To ->
- Under Published Site : 192.168.1.10 (Appropriate VIP - Cluster IP of the windows NLB)
- Under Computer Name or IP Address : 192.168.1.10 (Appropriate VIP - Cluster IP of the windows NLB)
- Traffic -> HTTP
- Public Name ->
- Requests for the following Web sites
- Add the FQDN of the TMG machine external name
- Paths ->
- Add Internal path as /*
- Select External path as "<same as internal path>"
- Authentication Delegation -> No Delegation, but client may authenticate directly
- Link Translation - >Do not check the box
- Schedule -> Always
- Users -> All Users
- Bridging ->
- Web server
- Choose Redirect requests to HTTP port : 8080 <port on which AT Service is listening on or bound to>
- Listener ->
- Networks -> External, Internal, perimeter checked
- Connections -> Enable HTTP connections on port : 80
- Authentication ->
- No Authentication
- Under Advanced -> Check "Allow client authentication over HTTP"
- Apply the properties
- Apply the properties
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.
3) URL settings and IIS bindings in Application tiers
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.
4) ALM scenarios when one of the tier is outside the Lab Environment
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
- DB might be too big to host in a VM
- DB performance within a VM could be unacceptable
- DB might be shared among multiple apps – either read or read/write
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
- If there are DB schema changes in new builds that differs from your earlier state, users will have to take care to ensure DB schema is in compatible with rest of the app tiers.
- If there is test data in DB that requires cleanup before next iteration of testing in the same setup, users will have to ensure the required cleanup is done.
- If there are multiple testers working in different LE are sharing the same DB machine outside, it is important to have each of them work in separate database.
- Testers can however share the same DB if they would only read from it and not write.
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.