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

    image

    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.

    image

    image

    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

    image 

    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:

    General properties

    image image

    image image

    image

    Listening on both External and Perimeter networks

    image

    Redirecting both HTTP and HTTPS connections to HTTP endpoint of application tier

    image

    Certificates for listening exposed HTTPS endpoint of TFS website in proxy

    image

    image

    Exposed public name

    image

    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.

    image

    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

    image

    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.

    image

    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

    image

    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.

    image 

     

     

    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.