Setting up various topologies to test with Visual Studio Lab Management – Part 3

Artigo
05/07/2010

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

Corp network – Would refer to the corp. network where TFS is hosted. A Corp network would have one or more ATs, DTs, Load balancers, Proxy, VMM server. Clients are typically connected to this network while at work.

Test network – Would refer to the network where the testing of the apps would happen. Test controller, Build controller, VMM server, VMM Library VMM hosts are present in this network. Please note that VMM server can either be in Corp network on in Test network depending on your choice.

Corp Domain – the domain controller in corp. network

Private Lab Domain – the domain controller in Private Test network.

AT – Application Tier

DT – Data Tier

VMM – System Centre Virtual Machine Manager

TC – Test controller

BC – Build Controller

BSH – Build Service Host

And few more that we would be using in this discussion…

TMG – Microsoft Forefront Threat Management Gateway

ALM – Application Lifecycle Management

LE – Lab Environment

LS – A Lab System within Lab Environment

VIP – Virtual IP or the Cluster IP in Windows NLB

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

https://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

https://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:

General properties

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

IIS Bindings

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.

TFS URLs

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.

Lab URL

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.

Controller configuration

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.

Environment snapshots

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.

Compartilhar via