Deliver a multi-site application

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, cloud, or CDNs. 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 and public cloud provider networks. To perform this function, a multi-site application monitors the health, availability, and latency for each site. It applies any other policies that have been configured around regulatory requirements.

Benefits

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.

Prerequisites 

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 Create cloud access profiles and Create an environment. 

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.

Example:

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.

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.

Algorithms

An algorithm controls how a multi-site application directs a client request across distributed sites or data centers. The CADS service supports the following load balancing algorithms:

• 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 multi-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 might be expensive (hosted in a country where bandwidth or infrastructure cost is 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.

• Static Proximity: The static proximity algorithm sends client requests to a site that is geographically nearest to the user location. The algorithm looks up the built-in GeoIP database and determines the client location based on the IP address derived by the DNS query. After identifying the location, the algorithm checks if the site is healthy and in the active state to process client requests. The healthy, active site that is geographically nearest to the user location responds to client requests.

  For example, consider a multi-site application having a healthy, active site in United States of America and in Singapore. With static proximity, client requests coming from India are sent to the Singapore site as it is geographically nearer.

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, HTTPS, or TCP 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.

Note:

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.

Stickiness

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

Domain Name System (DNS) translates human-readable domain names to machine-readable IP addresses, and vice versa.

The response from a DNS server typically has the IP address of the requested domain. If the IP address of the requested domain is unknown, the same is conveyed in the response.

Authoritative DNS integration

For multi-site applications, you can have your respective DNS records in a Citrix managed authoritative DNS zone. This allows you to manage both static records and multi-site app records through Citrix Cloud, without relying on an external DNS registrar.

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.

DNS fallback endpoint

You can add an endpoint that acts as a backup endpoint and responds to DNS queries when all sites associated with a multi-site application are in DOWN state. If the DNS fallback endpoint is left blank, an empty DNS response is sent back to such DNS queries.

Empty DNS responses

When all sites associated with a multi-site application are in DOWN state, and there is no DNS fallback endpoint configured, the application sends empty DNS responses to clients trying to connect to the server. The responses do not have any IP address record in it. However the response code is successful. Sending empty DNS responses to clients, prevents clients from reconnecting to the multi-site application that has all sites in DOWN state.

The application checks the status of sites every 20 seconds and if any of them is back in the UP state, then the responses have IP addresses of the requested domain.

To check if a multi-site application is sending an empty DNS response, run the following command at the command prompt:

dig <FQDN of the multi-site application>
<!--NeedCopy-->

In the output you can see that the DNS response does not contain any IP address record.

Example:

dig 003e.16ed0.itms.appdeliverysecurity.com
<!--NeedCopy-->

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.

Note:

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

Geofencing

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.

Cloud region recommendation engine

The location of a site is an important factor in the performance of a multi-site application. The cloud region recommendation engine in the CADS service recommends you the best locations to deploy new sites for a multi-site application. These recommendations help you boost the overall performance of your application.

The recommendations provided are based on the user location, traffic (in percentage) expected from each user location, and the provider types. You can use the recommended site location information while adding sites for a multi-site application.

The cloud region recommendation engine provides recommendations for single site, dual site, and triple site scenarios. The recommendations contain the location information, global latency, and benefit percentage. Global latency is based on real time measurements and the site location recommendations are arranged according to the best performing combination of providers’ sites. Benefit displays the advantage of choosing dual-site or triple-site in comparison with the single site.

You can get recommendations for new applications and also existing applications. For existing applications, already configured sites are also displayed and included for calculating the recommendations. You can choose to exclude the existing sites from the recommendation calculations.

The recommendations are specific to the application you select. Enter user location, traffic expected from each user location, and the provider type for an application and get the corresponding recommendations.

Note:

The cloud region recommendation engine only provides insights on the latency that the user experiences and the benefit of deploying additional sites to reduce the latency. Based on your network needs and preferences, you can decide if the lower latency outweighs the cost incurred for deploying the application in a second or third location.

To get the cloud region recommendations:

1. Navigate to Multi-Site Applications > Recommendations tab.
2. Select New Application or an existing application from Select your application.

3. Click + Location. Select the user location from the list and add the expected traffic percentage. You can add a maximum of six user locations.

   Note:

   For the United States, apart from the country level selection, you can also choose one of the 10 US regions from the list.

4. Toggle the Existing Locations. When enabled, for existing multi-site applications, the existing sites are included for recommendation calculations. This toggle does not impact recommendation calculations for new applications.
5. Select the Provider Type. You can select cloud provider sites only, CDN only, or both cloud provider sites and CDN.
6. Optionally, if you select Cloud as the provider type, select the preferred cloud provider from the Cloud Provider list.
7. Click Recommend.

8. The recommendations are listed under the Recommended Site Locations section. Click the recommendation list to view the geographic location of the site on the map.

   Initially, the best recommended sites are listed under the Recommended Site Locations section. Clicking the next recommendation icon lists the next best recommendation. As you move on with the next set of recommendations, the global latency increases. You can also view the Next 10 recommendations.

   Global latency is the latency that the user gets with the recommended sites using the Optimal RTT algorithm. Whereas the average latency is the latency specific to each area, considering the list of recommended sites.

   

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.

Prerequisites

1. Create a cloud access profile and have an environment ready to be used for your application. For more information, see Create cloud access profiles and Manage an environment.

2. Configure authoritative DNS if you want to have your DNS records in a Citrix managed authoritative DNS zone. Authoritative DNS helps you manage both static records and multi-site app records through Citrix Cloud, without relying on an external DNS registrar. For more information, see Configure authoritative DNS.

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 an Application FQDN Type:

   • 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.

     

   • 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 a Cloud Access Profile that is already configured.
     2. Type the domain name for the application in Domain of Application FQDN.

     3. Select a DNS zone from the 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. If you have configured authoritative DNS, then select a DNS zone from the list of authoritative DNS zones.

        

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

5. Type an IP address or a host name in DNS Fallback Endpoint. This endpoint acts as a backup endpoint and responds to DNS queries when there are no healthy sites available for the multi-site application. If the field is left blank, the multi-site application sends an empty DNS response.

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 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), a DNS name, or an IPv6 address (128-bit hexadecimal) in the DNS Name, IPv4, or IPv6 field for the application hosted on the user-defined site.

        Note:

        A combination of sites configured with IPv4 address (or DNS name) and IPv6 address is not supported. This combination might lead to inconsistent behavior of the multi-site application.

   • 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 select HTTP, HTTPS, or TCP.

      If you select HTTP or HTTPS, the port number gets populated automatically. If needed, you can change the port number. Enter the Host and Path.

      You can select TCP only for user-defined sites. If you select TCP, enter the port number manually.

      Note:

      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.

      Note:

      The port number is automatically populated for the managed site.

   3. FQDN is automatically populated in Host. Optionally, you can type a custom FQDN and path in Host. 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 1.1.1.1, https://1.1.1.1/ would fail, whereas https://hostname1/ would succeed) and mark the site as unhealthy.
4. Select the location type of the user-defined site. You can host your site either in a public cloud provider network or in your private data center. Choose one of the following:
   • AWS/Azure/GCP: Select AWS/Azure/GCP if you are hosting the site in a Point of Presence (POP) belonging to AWS, Azure, or Google Cloud Platform. Select the POP or Availability Zone (AZ).
   • CDN: Select CDN if you are hosting the site in a Content Delivery Network (CDN). A CDN has a globally distributed set of servers that proxies and caches web data at edge locations closest to the users. Select the CDN.
   • Private Data Center: Select Private Data Center if you are hosting the site in your private data center. Type the geographical location where the site is hosted. This field is integrated with Google maps.

   Note:

   The location is automatically populated for managed sites and user-defined sites hosted in a public cloud or a CDN.

5. Toggle to enable Configure Radar if you have chosen Private Data Center as the site location type. 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/.

   Note:

   • 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 and public cloud provider site location types, radar measurements are automatically collected.
   • Radar must be activated for the selected private data center. For more information, see Activate radar for a private data center.

6. 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.

   

7. Select the Perform Site Maintenance check-box to mark your site in the maintenance mode.

   Note:

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

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

   

9. Click Add 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.

Note:

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.
   • Select Static Proximity.

2. Select Enabled in Stickiness to enable stickiness if necessary. If not required, continue to step 5.

   Note

   The FQDN for multi-site applications is auto-generated under the itms.appdeliverysecurity.com top level domain (TLD) for sticky applications, rather than the default itms.appdeliverysecurity.com.

   Changing stickiness for existing multi-site applications takes some time to propagate. The time taken to propagate depends on the TTL of the CNAME record pointing to the itm(s).appdeliverysecurity.com autogenerated record. The TTL for a multi-site application with user-defined FQDN is 10 minutes and therefore the change propagation takes around 10 minutes. The TTL for multi-site applications with auto-allocated FQDN depends on the TTL duration configured by the application admin for the respective CNAME record.

   The previously auto-generated FQDN remains active while the CNAME change propagates. Users hitting a cached CNAME record before propagation completion can still access the multi-site application with the previous stickiness settings.

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.

4. Enter Stickiness IPv4 Mask. If stickiness is enabled, the client requests coming to the multi-site application are identified using this IPv4 subnet mask and sent to the same site.

   

5. 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 lists the following details about each application:

• 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. One of the following values is displayed:

  • 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 - GSLB method such as failover, round robin, and optimal RTT used to configure the multi-site application. The method specified is used to determine the site that is selected (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.

Manage multi-site applications

In the Multi-Site Applications summary page, click the three dots in the ACTIONS column to manage your delivered multi-site applications.

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 … in the ACTIONS column and click Edit.

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.

   

   Note:

   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 … in the ACTIONS column. Click Undeploy.

   

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.

Note:

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

1. In the Multi-Site Applications summary page, click … in the ACTIONS column. Click Delete.

   

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

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

Related topics

Activating radar for a private data center