Multi-site applications

Thinking about providing an optimal user experience for your business applications that are delivered in multiple locations? Doing so can help you to enhance customer satisfaction, brand perception, productivity, and revenue. With the Citrix App Delivery and Security Service – Citrix Managed multi-site application feature, you can configure, deliver, and manage applications across multiple cloud environments for high availability and reliability.

A multi-site application provides global load balancing, site failover, and web traffic management across multiple data centers or cloud. It also plays a key role in business use cases, such as disaster recovery, application performance, application availability, and regulatory compliance.

A multi-site application routes network traffic intelligently across an organization’s data centers. To perform this function, a multi-site application monitors the health, availability, and latency for each data center. It applies any other policies that have been configured around regulatory requirements.


A multi-site application provides the following benefits:

  • Ensures multi-site resiliency and disaster recovery - Disaster recovery capability is critical to your business because downtime is costly. With a multi-site application, you have continuous monitoring for your data center’s availability, health, and responsiveness. A multi-site application redirects the traffic to the closest or best performing data center, or to healthy data centers if there is an outage.

  • Improves application performance and availability - If web traffic isn’t distributed appropriately across data centers, one site might become oversubscribed while another is underutilized. This can result in poor service for some users and the risk of a service disruption because of overflow. Also, the proximity of the user to the server can impact network latency, making site selection a key element of service quality. By providing intelligent web traffic management, a multi-site application ensures that the load is balanced more evenly across sites while also routing content to each user from the nearest available server to ensure an optimal experience.

  • Increases scalability and agility - A multi-site application solves the problem of limitation of sites and exponential growth of traffic with a greater number of sites. With scalability, you can add, upgrade, and deprovision sites transparently.

  • Reduces latency - High amount of traffic to a website can significantly increase latency. Multi-site application plays a key role in distributing network traffic across several data centers to ensure that no single data center is overloaded with too many requests. It finds the site with the fastest response time (that is, the best network conditions) for each different client through distributed and crowd-sourced round trip time (RTT) measurements, allowing users to be connected to the optimal site.

  • Optimizes user experience - A multi-site application allows you to globally load balance all the traffic, dynamically optimize the user experience, and lower service costs. It routes client requests to the nearest data center. It improves user experience by accelerating application response time. Network latency is minimized by delivering content from a data center, which is closer to the requesting user.

  • Meets regulatory and security requirements - A multi-site application enables you to service a global user base in a manner that complies with government regulations for highly regulated industries such as telecommunications, defense, and healthcare.


Before you deliver a multi-site application, you must complete the following preliminary steps: 

  • Create a Citrix cloud account profile.
  • Create an application environment.

For more information, see Deliver an application. 

How a multi-site application works

A multi-site application routes traffic across multiple data centers. DNS infrastructure is used to connect the client to the data center. When a client sends a DNS request, the GSLB DNS server identifies the server that best meets the set criteria. The criteria can be one or more of the following:

  • Availability (health) of data center.

  • Response time of the data center.

  • Geofencing rules that might limit certain data centers to specific geographic locations.

  • GSLB distribution algorithm selected.

After the connection is established, the traffic is routed directly between the client and the application.


Let’s consider the following example to understand how a multi-site application distributes traffic based on the optimal round-trip time (optimal RTT) algorithm. For more information about supported algorithms, see Algorithms:

There are two sites or data centers, one in Bengaluru and another in New York.

  1. A user in Austin requests the DNS services hosted by the GSLB to get the IP address of the server hosting the multi-site application.

  2. The GSLB DNS server gives the IP address to direct the user to the site that would work best for the user according to the criteria. Typically, based on the optimal RTT algorithm, the user is directed to the New York data center. For more information on the optimal RTT algorithm.

  3. The user connects to the New York data center.

  4. Traffic is established directly between the multi-site application and the user in Austin.

How a multi-site application works

Deployment types

The following deployment types are supported for multi-site applications:

  • Active-active - The multi-site application is deployed in multiple active sites or data centers. If a data center is unreachable, application instances running in the remaining data centers take over the user traffic. This deployment type is ideal when you have a need for global distribution of traffic in a distributed environment, optimize user experience, and reduces latency.

  • Active-passive - The multi-site application is deployed in an active and one or more passive data centers. This deployment type is ideal for disaster recovery. The active location is used to serve a client request. Traffic is routed to the passive data center only when the active data center goes DOWN.


Algorithm controls how a multi-site application directs the client request across distributed sites or data centers. The following algorithms are supported:

  • Failover - The failover algorithm supports a simple routing logic where a site is chosen based on its place in line, and its availability. It helps prevent disruption of access to applications delivered across multiple sites. Select the failover algorithm and specify the priority for each site to configure GSLB sites for high availability. This gives you the flexibility to shift traffic to a backup data center and fail over an entire site. You can create a failover chain that decides which site to select first, second, and so on.

    • For example, add primary and standby sites. If the primary site goes DOWN, the traffic is automatically diverted to the standby site. There can be multiple standby sites. Assign a priority of 1 to the primary site and an increasing priority of 2 and above to the standby sites. If the site with priority 1 is DOWN, requests are directed to the site with priority 2. If both the sites are DOWN, the traffic is directed to the site with priority 3, and so on.
  • Round robin - The round robin algorithm distributes the client requests across the sites or data centers sequentially regardless of the load. Select the round robin algorithm and assign different weights to each site. GSLB performs the weighted round robin distribution of incoming connections. It does this by skipping the lower-weighted services at appropriate intervals. Weights are proportional. You can have three sites with a weight of 2:1:1, 50:25:25, or 90:45:45. In all cases the effect is the same. You can assign weights for the prioritization and selection of each site globally.

    • You can globally assign weights for the prioritization and selection of each site.For example, you have three sites selected for your muli-site application: site A, site B, and site C. You have assigned them the weights: 60, 50, and 10, respectively. The round robin algorithm converts these values into percentages, such as site A=50%, site B=42%, and site 3=8% (which adds up to a 100%). This means that 50% of the time, user requests are routed through site A; 42% of the time through site B; and 8% of the time through site C. If all the sites are given the same weight, traffic will be evenly distributed across them over time. If you have only one site, then that site will be used 100% of the time, regardless of the weight you give it. Weights are only used for sites that are available. Unavailable sites cause the distribution to not match the configured weights. For example, if site A is weighted 100 and site B is weighted 1, and if site A is unavailable, all traffic is sent to site B.
  • Optimal RTT - The optimal RTT algorithm measures network proximity. Select the optimal RTT algorithm and specify a penalty to choose the closest healthy data center from a latency perspective. When you specify penalty to a site, you add an extra latency. The additional latency is added to the one calculated by real user measurement (RUM). Penalty is a percentage value that can be applied to a site to modify the RTT, that is, artificially increase the response time (in milliseconds). Increasing or decreasing RTT brings down the performance of the site, such that the likelihood of it being picked is lower.

    • For example, a site is maybe expensive (that is it’s hosted in a country where bandwidth or infrastructure costs are higher), and you want to reduce the likelihood of it being picked when an equivalent provider is close enough in terms of performance. So, you put in a penalty value (in percentage) that acts as a multiplier to increase the value of response time, as a result, lowering the probability of that site being picked. Let’s assume that RTT without penalty for site A is 50 milliseconds and for site B is 60 milliseconds. Specify a penalty of two (2) to site A and zero (0) to site B. The RTT for site A would be calculated as follows:
      • Site A RTT with penalty applied = RTT (Round Trip Time in milliseconds) x (1 + Penalty)

        = 50 milliseconds

        Thus, site A that now has an RTT of 150 milliseconds is not selected over site B that continues to have an RTT of 60 milliseconds.

Monitors (Site health check)

Monitors determine if a site is healthy by sending a health probe to a site. If the site responds, the monitor marks the state of the site as UP. If the site doesn’t respond to the designated number of probes within the specified time, the monitor marks the site as DOWN. No requests are forwarded to this site until its state changes to UP.

You can configure an HTTP or HTTPS type monitor, specify a port for the health check, and add a URL path for the HTTP or HTTPS health probes to determine if the site is healthy. Health probes are by default sent to http(s)://hostname/path. You can enter a custom FQDN and path, such as hostname1/path/test, if you want to override the health probes URL to http://hostname1/path/test or https://hostname1/path/test.


The custom FQDN only overrides the URL related attributes (HTTPS server name indicator and HTTP(S) host header) and not the target IP of the health probe.


Some applications require stickiness between a client and a data center. All requests in a long-lived transaction from a client must be sent to the same data center; otherwise, the application session may be broken, with a negative impact on the client.

Stickiness is accomplished by enabling site persistence. Enabling stickiness ensures that a series of client requests for the multi-site application is sent to the same back end site instead of being load balanced if this site remains healthy. This enables the clients to remain sticky to a back-end site, even in the face of changing network conditions (for optimal RTT), site health (site with higher priority became healthy again), and round robin decisions.

For example, in an e-commerce website that uses a shopping cart, the server needs to maintain the state of the connection to track the transaction. With stickiness enabled, the client requests are forwarded to the same IP address of the selected data center for all subsequent DNS requests.

If a stickiness session points to a data center that is DOWN, then the configured GSLB method is used to select a new data center.

DNS time to live

The DNS time to live (TTL) indicates how long the DNS response is cached by clients for the multi-site application. The default TTL is 20 seconds. Citrix recommends keeping the default value. Lowering the TTL increases the number of DNS queries, leading to added cost and reduced performance. Increasing the TTL results in clients caching the DNS response for a longer time and a data center might become unhealthy during this time. Therefore, it is best not to change the default value of TTL.

Radar configuration

Today’s business environment demands the ability to be able to run an application that is both globally connected and consistently high performing. To achieve this, you need a tool that measures real-time internet performance across all major clouds and CDNs, and across a global network.

Real user measurements (RUMs) on such a significant scale are achieved through Radar. It takes measurements from about 900 million users across 50,000 ISP networks, resulting in 15 billion data points every day, which enables you to ensure that the content and applications are always available, and the users receive the best experience.

RUMs can be achieved through radar tags and objects. Community members have placed objects (small .gif files) in the sites. Users retrieve these objects to measure the latency to each site. Tags are small pieces of JavaScript that are embedded in the sites. When the page is downloaded, the code is run and instructs the browser to retrieve various objects, take measurements about the latency, and sends that telemetry to Radar.

The Radar object can be deployed on the site using a responder policy and action. Responder action and policy serve a 43 bytes single pixel image whenever a URL with the extension r20.gif is requested by the user’s browser.

Radar RTT measurement

The radar RTT measurement process follows these steps:

  1. Users visit the site with a radar tag and when they download a webpage, they receive a small java script tag.
  2. When the page has finished loading, a radar tag initiates a request to each of the sites.
  3. The radar tag retrieves the small radar objects to determine the HTTP response time.
  4. The data is collated and sent to the radar community. Based on the data, perform an optimal RTT and route the traffic to the site with the lowest RTT.

Maintenance mode

Sites require periodic maintenance. The maintenance mode feature in multi-site applications enables you to plan for a scheduled maintenance or anticipate downtime for performing an upgrade, testing network connectivity, diagnosing an underlying hardware issue, and so on. Once your scheduled maintenance is completed, you can disable the maintenance mode.


For sites in the maintenance mode, the multi-site application in the analytics dashboard will be marked as under maintenance.


Regulatory compliance differs from country to country. This aspect must be kept in mind when delivering applications across multiple geographical locations and data flows across borders. Many organizations face mandates regarding the geographic location of data storage and processing. For example, the general data protection regulation (GDPR) dictates that EU-based users must be served by local servers for certain application requirements.

The Citrix App Delivery and Security Service – Citrix Managed multi-site application feature helps you to adhere to regulatory compliance. With the geofencing feature, a multi-site application can be configured to use specific data centers to serve users in specific regions, simplifying compliance with this rule. Based on the countries configured in the Geo IP database, the requests are forwarded to the servers that host content customized for the regions.

Deliver a multi-site application

The Citrix App Delivery and Security Service – Citrix Managed multi-site application feature enables you to create, configure, and deliver an application in multiple sites.

Step 1: Create a multi-site application

Follow the steps to create a multi-site application and define the application endpoints.

  1. Navigate to Multi-Site Applications > New Multi-Site Application.
  2. In the Create a Multi-Site Application page, type the application name in Application Name.
  3. Select the Application FQDN Type and do one of the following:
    • Select Auto-allocated if you want to use a DNS provider other than AWS Route 53. The Citrix App Delivery and Security Service – Citrix Managed multi-site feature handles the creation of FQDN. It displays the FQDN details in the Multi-Site Applications summary page after the application delivery. You can configure the FQDN as a CNAME record in your DNS provider.

      Create an auto-allocated multi-site application

    • Select User Defined (Route 53) if you want AWS Route 53 as the DNS provider to host the application FQDN and do the following:

      1. Select an Environment that is already deployed.
      2. Type the domain name for the application in Domain of Application FQDN.
      3. Select the hosted DNS zone from the Select Hosted DNS Zone list. The Citrix App Delivery and Security Service – Citrix Managed multi-site feature handles the creation of FQDN. A CNAME for this FQDN is automatically created in your AWS Route 53 hosted zone.

        Create a user defined multi-site application

  4. Type a value in DNS Time to Live. The value indicates how long the DNS response is cached for the application.

You have completed the steps to define the endpoint details for the multi-site application.

Click Next, to add a site.

Step 2: Add a site

Sites are locations that are load balanced by GSLB. You can either create a User Defined or a Managed site. Follow these steps to add and configure a site.

  1. Click Add a New Site.
  2. In the Add a New Site page, do one of the following:
    • Select User Defined if you want your site to be an on-premises data center, cloud, CDN, or any external platform not managed by the Citrix App Delivery and Security Service – Citrix Managed edition. Do the following:
      1. Type the name of the site in Site Name.
      2. Type an IPv4 Address (32-bit) or a DNS Name for the application hosted on the user-defined site.
      3. Type an IPv6 Address (128-bit hexadecimal) or DNS Name for the application hosted on the user-defined site.
    • Select Managed if you want the Citrix App Delivery and Security Service – Citrix Managed edition to manage the site in the AWS cloud. Do the following:
      1. Type the name of the site in Site Name.
      2. Select an application that is delivered. The FQDN and the AWS location of the delivered application is automatically populated.
  3. Configure a monitor to send health probes to the site to verify if they are healthy. Do the following:
    1. Select a protocol. You can either select HTTP or HTTPS.


      The protocol type is automatically populated for the managed site.

    2. Type a TCP port number in Port, which is used by the application hosted on the site.


      The port number is automatically populated for the managed site.

    3. FQDN is automatically populated in Destination. Optionally, you can type a custom FQDN and path in Destination. For example, type hostname1/path/test if you want to override the health probes URL to http://hostname1/path/test or https://hostname1/path/test instead. Modifying the monitor’s FQDN is necessary if there is HTTPS endpoints, since the installed certificate might result in SSL failures (that is, if there is a user-defined site with an IP address, would fail, whereas https://hostname1/ would succeed) and mark the site as unhealthy.
  4. Toggle to enable Perform Site Maintenance to mark your site in the maintenance mode.


    For sites in the maintenance mode, the multi-site application in the Analytics dashboard is marked as under maintenance.

  5. Select Configure Radar to configure the location of the radar object in the user-defined site and type the URL path to retrieve the radar object to measure the RTT of the site. For example, type http(s)://<ip-or-dns-name>/path/to/.


    • The extension, r20.gif is automatically appended to the given URL.
    • If you don’t select the Configure Radar option and successfully complete the radar object configuration, the Optimal RTT algorithm is disabled while configuring GSLB methods.
    • For successful multi-site application delivery, the radar probe URL must be reachable.
    • For managed sites, radar measurements are automatically collected.
  6. Search and select the physical location where you want to host the user-defined sites. Type the name of the city in Location and select the region based on the results. The search is integrated with Google maps. The city name, address, zip code, region, and country details are automatically populated.


    The location is automatically populated for the managed site.

  7. Select continents and countries in Geo Fencing that can access your site. By default, all the continents are selected. For example, to select a particular continent, deselect Select All and select Asia. Only users from the Asia continent are serviced from this site. You can also search for a location.

    Add a user defined site

  8. Click Add Site. The site is added, and its details are displayed.

    Multi-site application site list

  9. Click Add a New Site and repeat steps 1–8 if you want to add another site.

You have completed the steps to add and configure sites.

Click the Edit or Delete icon in the ACTIONS column to edit the site details or delete a site, respectively.


After you create a site, you can’t edit the Site Type.

To configure GSLB and deliver the multi-site application, click Next.

Step 3: Configure GSLB and deliver the multi-site application

Follow these steps to configure the GSLB algorithm to route the network traffic intelligently across sites, configure stickiness, and deliver the multi-site application.

  1. Select an algorithm to route the client traffic to sites. For more information about supported algorithms, see Algorithms.
    • Select Failover and type a value in PRIORITY for each site. For example, assign a priority of 1 to site A and an increasing priority of 2 and above to the standby sites.
    • Select Round Robin and type a value in WEIGHT to distribute the traffic to each GSLB site. For example, assign a weight nine (9) to site A and weight one (1) to site B.
    • Select Optimal RTT and type a value in PENALTY.
  2. Select Enabled in Select Stickiness to enable stickiness if necessary. If not required, continue to step 4.
  3. Type a value in Stickiness Time To Live. If stickiness is enabled, its TTL controls the time duration within which subsequent client requests for the multi-site application are sent to the same site.

    Multi-site application GSLB configuration

  4. Click Deploy.

    The multi-site application is deployed successfully.

To view the summary and manage the multi-site applications, click Manage Multi-Site Applications.

Multi-site application summary

The Multi-Site Applications summary page lists the total number of created multi-site applications and the following details:

  • MULTI-SITE APPLICATION NAME - Name of the multi-site application.

  • FQDN - Fully qualified domain name (FQDN) of the multi-site application.

  • STATUS - The current deployment status of the multi-site application. The statuses are as follows:

    • INDRAFT — The multi-site application is created, but the back-end resources are not deployed.

    • ERROR — The multi-site application deployment failed.

    • DEPLOYED — The multi-site application is successfully deployed.

    • IN PROGRESS — The multi-site application deployment is in progress.

  • ALGORITHM - Displays the GSLB method used to configure the multi-site application, such as failover, round robin, and optimal RTT. The method specified is used to determine the site that is picked up (DNS response) for client requests.

  • ACTIONS - Enables you to either modify, redeploy, undeploy, or delete a multi-site application. For more information, see Manage multi-site applications.

Multi-site application summary

Manage multi-site applications

In the Multi-Site Applications summary page, click the Edit or Delete icon in the ACTIONS column to manage your delivered multi-site applications.

Manage multi-site application

Modify and redeploy a multi-site application

Follow these steps to edit the application details, site configuration, or GSLB configuration and redeploy the multi-site application.

  1. In the Multi-Site Applications summary page, click the Edit icon.
  2. In the Edit Multi-Site Application page, click the Application Details, Location, or GSLB tab to make the required changes. For example, click GSLB and edit the algorithm.

    Modify and redeploy a multi-site application


    Parameters such as, Application Name, Application FQDN Type, Site Type, Site Name, and so on are unavailable for editing if the multi-site application is successfully deployed.

  3. Click Modify.
  4. Click Redeploy.

You have completed the steps to modify and redeploy a multi-site application.

Undeploy a multi-site application

Follow these steps to undeploy a multi-site application.

  1. In the Multi-Site Applications summary page, click the Delete icon.

    Undeploy a multi-site application

  2. In the Undeploy Multi-Site Application page, click Yes, Undeploy.

You have completed the steps to undeploy a multi-site application. Undeployed applications are in the INDRAFT status. You can either edit and redeploy, or delete them.

Delete a multi-site application

Follow these steps to delete a multi-site application.


You can delete a multi-site application only if it is undeployed.

  1. In the Multi-Site Applications summary page, click the Delete icon.

    Delete a multi-site application

  2. In the Delete Multi-Site Application page, click Yes, Delete.

You have completed the steps to delete a multi-site application.