Citrix Blogs

Cloud Guidepost: Expanding your Citrix Virtual Apps and Desktop Service options with Azure Traffic Manager

If you have read my previous series of posts on the Citrix Virtual Apps and Desktops service, you probably know by now that I love both Citrix Cloud and our partner in crime, Microsoft Azure, and experimenting with different things in them. One of the things I love the most about them is how many options you have for achieving different results based on your requirements.

In part 3 of my previous blog series, I set up an end-to-end Citrix Virtual Apps and Desktops service environment in combination with Microsoft Azure, with an Azure hosted NetScaler and StoreFront. Now, in that case, I  created a NetScaler HA pair and put it behind an Azure Load Balancer. The only caveat I’ve found when planning an environment with one our customers was that this is an active/passive setup and there is no way to achieve an active/active setup with that configuration. The reason why it is not possible is that, as you know, setting up NetScaler in HA mode gives you a primary (active) node and a secondary (passive) node. On the other hand, NetScaler clustering is not supported in Microsoft Azure so it is not a viable option for our active/active requirement in our case. Enter Azure Traffic Manager.

Azure Traffic Manager is a DNS based load balancer that allows you to control traffic distribution between different endpoints located Microsoft Azure or even your own data center by setting up a Traffic Manager Profile. Valid endpoints go from Azure IaaS VMs, Azure Web apps, non-Azure based external endpoints, and even other Traffic Manager profiles in a nested scenario. You can probably see where am I going by now.

How does it work?

Amongst the different things you need to plan when setting up your Traffic Manager Profile, here are the most important:

  1. DNS Configuration
    1. Your Traffic Manager will be created under the trafficmanager.net domain, e.g. yournetscaler.trafficmanager.net.
    2. Your Public IPs will need to have a DNS record created for them. You cannot use IPs without a DNS record, except for your external endpoints.
    3. You need to set up a DNS CNAME on your public DNS configuration that points to your trafficmanager.net profile.
  2. Configuration:
    1. You need to select a Routing Method between the following:
      1. Performance: The best performing endpoint.
      2. Weighted: You give a weight to each endpoint to allow for traffic distribution. This is the method I used by giving a value of 50 to each of my endpoints, hence splitting requests evenly between both endpoints. Keep in mind this is not a percentage so you could do 3 endpoints with a value of 5 and traffic would be distributed equally between the 3.
      3. Priority: A primary endpoint serves all traffic. Backup endpoints are set up and ready in case the primary becomes unavailable.
      4. Geographic: Direct traffic based on the geographic location where the DNS query originates from.
    2. Setup your Endpoint Monitoring settings:
      1. Protocol: Can be either HTTP, HTTPS, or DNS.
      2. Port: The port # your service utilizes, in this case, 443.
      3. Path: Only valid for HTTP and HTTPS monitors.
    3. Configure your Fast Endpoint Failover Settings:
      1. Probing Interval: How often in seconds should Traffic Manager probe your endpoints.
      2. Tolerated number or failures: How many failed probes are tolerated before an endpoint is marked as offline.
      3. Probe Timeout: Specifies how long it takes before a probe times out.
  3. Endpoints:
    1. Azure Endpoints: Select between an Azure App Service, App Service Slot, or Public IP Address (which needs a DNS label).
    2. External Endpoints: An endpoint not inside your Azure subscription, like a NetScaler HA pair on your data center, wink.
    3. Nested Endpoints: Another Traffic Manager Profile, maybe front-ending an extra pair of NetScalers in a secondary Azure region, another wink.

My environment.

My environment is this case is fairly simple:

My NetScaler Configuration.

Keep in mind that, in this case, you cannot use High Availability or Clustering to setup your NetScalers. So I set up each NetScaler as an independent entity with an almost identical NetScaler Gateway configuration, with different VIPs of course. I also set up a quick EULA to let me identify both of my NetScalers.

Since I used a Weight based routing method for my Traffic Manager Profile, traffic is being split 50/50 between both of my NetScalers. Here is what it looks like:

NetScaler #1:

 

NetScaler #2:

StoreFront configuration is nothing different from what you would usually do and does not require any advanced settings. Desktop Launch works as expected:

Takeaways:

Stay tuned for more upcoming blogs in the Cloud Guidepost series!

JP Alfaro 
Cloud Success Engineer

Exit mobile version