Openmix

Overview

Citrix ITM Openmix provides a revolutionary approach to Global Traffic Management/Global Server Load Balancing (GTM/GSLB). For traditional global traffic management, ITM provides a DNS based approach to Load-balancing using DNS CNAME or A records where DNS responses are altered in real-time based on the business logic required. For video, there are multiple ways that Openmix can be integrated into the video workflow and delivery.

For many years, GTM/GSLB tools and services have relied on proprietary, inextensible, static rules engines to define, and control a narrow set of fixed policies (for instance, failover, round-robin, geo-targeting). Citrix ITM’s mission is to enable next-generation cloud strategies based on real-time data feeds. The globally distributed, on-demand Openmix platform provides a highly robust means of ingesting real-time data from various sources, and exposing this metadata as environment “variables” which can be evaluated on each request.

Openmix: Key Benefits

  • Eliminate single-vendor dependencies
  • Ensure 100% availability
  • Control price/performance trade-offs
  • Banish headaches associated with multi-sourcing
  • Remove uncertainties of legacy performance tools
  • Offload traffic selectively and strategically
  • Apply specific providers to target individual markets

How Openmix Works

Customers log into the Citrix ITM Portal to deploy their first application. A library of sample apps is available to help get started and a step-by-step wizard tool to help create applications with the most common routing logic. ITM Openmix applications can support two protocols for directing traffic: DNS or HTTP.

Application Defined Control

The globally distributed, on-demand, Openmix platform moves GTM/GSLB decision making close to your application audiences. Each host can have its own custom defined Openmix application that considers all the current metrics and variables available to provide the best optimization for any routing request.

Openmix scripts are programmed in JavaScript, a language that is accessible to most web programmers and network administrators. While this script-based approach is one where virtually any business logic can be implemented – with minimal coding complexity — to use as the basis for truly dynamic traffic management policies. Thanks to the collaborative nature of our customer community, ITM also provides “quick start apps” which are standard applications that don’t require code.

When to Use HTTP or DNS Services

ITM Openmix enables a wide range of content delivery optimization. Which method you use to enable Openmix largely depends on the specifics of your use case. The DNS method is easy to implement, mostly transparent to clients, and usable across a wide variety of content. However, the ability to switch providers is limited by the TTL set on the DNS response and some content cannot be switched to a different provider mid-stream. HTTP provides more integration flexibility and optimization decisions can be made when it is optimal for the client. That more flexibility requires more work to integrate with a CMS or client.

The following table summarizes the principle customer use case we see for the DNS and HTTP interfaces.

customer use cases for the DNS and HTTP interfaces

Openmix: DNS

CNAME Delegation

The easiest integration for ITM customers is to use DNS CNAME delegation. The CNAME delegation works by having the customer point their end-user facing host name (in the below example, www.acme.com) at an ITM host name.

www.acme.com  600  IN  CNAME  2-02-123d-000d.cdx.cedexis.net.

On receiving a DNS request from an end-user the ITM system makes a real-time decision based on the Radar data, business logic in the application and any third party information that is supplied. This decision is articulated either as another CNAME record (in our example below acme.cdn1.net) or as an A record such as 111.222.111.222.

By supplying a CNAME record ITM can effectively “point” the end-user to the CDN, Cloud, or Data Center of choice, routing the end-user to use that provider versus another.

2-02-123d-000d.cdx.cedexis.net.  19  IN  CNAME acme.cdn1.net.

Once the CDN or Cloud CNAME is supplied the end-users machine will continue the resolution chain by requesting CDN’s name servers, until receiving an IP address of the node/server to communicate with. Where upon the process of downloading content begins. If an A record is supplied as part of the logic the end-users machine receives the IP address and connect directly to the server and initiate the download of content.

acme.cdn1.net.  132  IN  A  111.222.222.111

Zone Delegation

In addition, Authoritative DNS Zone Delegation is an option to implement Openmix. The customer creates a DNS zone and delegates to a Predictive DNS zone created in the ITM Portal. A host name is created in the delegated zone and is configured to use an Openmix application or a dynamic Predictive DNS record to generate a response. The advantage of this option is that there doesn’t need to be a CNAME delegation between the host name and the dynamic response from the ITM platform. Using the example from above, www.acme.com host name will be directly resolved to the configured value for the optimal CDN, Cloud, or Data Center.

www.acme.com. 19 IN CNAME acme.cdn1.net.

A/AAAA records can also be used instead of CNAMEs, and the host name will resolve directly to the record of the optimal destination.

www.acme.com. 19 IN A 111.222.222.111

DNS and Time To Live Implications

It must be noted that factors such as TTL (Time To Live) values must be considered carefully with appropriate times being set for the content and the requirement for how the decision making must be for users. In most instances ITM recommends a 20 second TTL for page and object content. For Video content the ITM consultant works with the customer to find the most appropriate balance based on chunk length and integration method.

Openmix: HTTP

An alternative to DNS is to use the HTTP API. HTTP access to Openmix uses HTTP requests to inform a client such as a video player or CMS on which platform to use at any one point in time.

http://hopx.cedexis.com/zones/1/customers/0/apps/1/decision
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 22 Apr 2015 20:25:24 GMT
< Connection: keep-alive
< Content-Length: 177
<
{
  "providers" : [
    {
    "provider" : "cdn2",
    "host" : "foo.cdn2.net"
    },
    {
    "provider" : "cdn1",
    "host" : "acme.cdn1.net"
    }
  ]
}

The HTTP Openmix service uses the same application logic as its DNS based counterpart with the inclusion of some additional extensions, allowing further profiling of a client machine. For example, with HTTP Openmix it is possible to also look at the headers for User-Agent String, X-Forwarded-For, and Referer, and supply IP overrides using query string parameters. As the payload for HTTP Openmix is more extensible than that of DNS it is also possible to provide the CDN, cloud or server decision selection in different ways. The most common so far has been an ordered list from most preferred platform to least (as above). By supplying a full list, it allows the decision rank to be supplied to the CMS or Client, yet still allows for internal heuristics to be used in choosing the provider.

CMS Integration

Some customers prefer to handle the provider selection on the server-side rather than implement provider selection in every client. The HTTP API can be used to retrieve an optimization decision from Openmix at request time from the client, which can be used to populate a file that is returned from the CMS to the client.

By default, Openmix HTTP endpoints use the IP of the caller for geo location and decision criteria. If, instead, you are calling from a CMS or other system sitting between the end-user client and Openmix, you can specify as a parameter the IP to use in the decision.

http://hopx.cedexis.com/zones/1/customers/0/apps/1/decision?ip=1.2.3.4
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 22 Apr 2015 20:25:24 GMT
< Connection: keep-alive
< Content-Length: 177
<
{
  "providers" : [
    {
    "provider" : "cd1",
    "host" : "acme.cdn1.net"
    },
    {
    "provider" : "cdn2",
    "host" : "foo.cdn2.net"
    }
  ]
}

This method allows you to use a CMS integration to pull decisions from Openmix while also getting the benefits of geo and ISP route optimization for the end user. The host name returned from Openmix is then packaged into the response, such as a video manifest file, and returned by the CMS to the client. The client will then use the optimized decision without needing any modification to support Openmix optimization.

Openmix Applications

Openmix Quickstart applications are load balancing and traffic management applications that provide real-time traffic routing to the best provider based on a set of rules.

The applications are processed for each request made to Openmix and a routing decision is made based on the specified logic. A customer may have one application for one type of content that has high business value, and a different application for content that has a lesser value that must be routed differently.

When an application is invoked, a decision is made that is, a single request is sent to one of Citrix’s load-balancers. For DNS, it is a single DNS request to the DNS load-balancers. For HTTP, it is a GET or HEAD request to the Openmix HTTP endpoint.

The following apps are currently available through the Intelligent Traffic Management Portal.

  • Static Routing
  • Failover
  • Round Robin
  • Optimal Round Trip Time (ORTT)
  • Throughput

Openmix Custom JavaScript applications are used by specialized Openmix servers to respond to DNS or HTTP requests based on the logic in the scripts. Deployment of the scripts is done via the customer portal where the app is configured and published. For more information on the ability to create your own JavaScript scripts, refer to the information at our Developer Exchange.

Before you go ahead with setting up the apps, it is important to understand the following concepts:

Availability Threshold

The availability threshold is the minimum availability score that a platform must meet to be considered for routing. The default minimum availability threshold for all applications is 80%. However, you can modify this percentage and set it to a value that is appropriate for your location, network availability, and reliability.

Note: If no platform meets this minimum Availability threshold (the default of 80%, or the value that you set), random routing is done for Round Robin, ORTT, and Throughput applications.

Fallback

The fallback response is returned if the Openmix application does not run successfully for whatever reason. Or if Sonar confirms that there are no available platforms. Therefore, a valid fallback CNAME/A/AAAA record or IP (or path in HTTP) must be specified with which Openmix can respond. This fallback URL or CNAME record may or may not be for a platform that is pre-configured in Openmix. Fallback sometimes occurs during the following scenarios as well:

  • When there is a switching between versions of your application, that is, when you upload and publish a new script, it may lead (but not always) to a brief (milliseconds) time period of fallback as the new script is being initialized after the old one is removed.
  • If ever there is an overload (which rarely happens), Openmix responds with the fallback CNAME/A/AAAA since fallback offsets the load on the service.

For fallback, you must enter a valid host name (CNAME/A/AAAA record) or IP address in DNS, and a valid URI (it can be of the form, scheme:[//host[:port]][/path][?query][#fragment]) in HTTP.

TTL

In Openmix, the DNS Time to Live (TTL) for the application tells resolvers how long they must keep the decision before asking Openmix again. The TTL is used to:

Control the volume of traffic an Openmix app gets, and Control how sensitive an app must be to changes in the data that it acts upon. The default TTL is 20 seconds. Although you can modify this value, it is not recommended to do so. If you lower the TTL you get more volume and more real-time DNS queries. But it may lead to added costs and lower performance (because DNS queries take time on the client). Therefore, it is best not to change the default value of TTL.

Weights (Used for Round Robin)

You can assign weights for the prioritization and selection of each platform globally and/or by market or country.

For example, say you have three platforms selected for your application - P1, P2, and P3. You give them the weights: 60, 50, and 10 respectively. The Round Robin app converts these values to percentages such that, P1=50%, P2=42%, and P3=8% (which now add up to a 100%). This means that approximately 50% of the time, users would be routed through P1; approximately 42% of the time through P2; and approximately 8% of the time through P3.

The weights you give to the platforms do not have to add up to 100. They can be any integer between 0 and 1,000,000. The weights given to the platforms when converted to percentage (by the app in the back-end), will add up to a 100%. If all selected platforms are given the same weight, traffic will be evenly distributed across them over time. If you have only one platform, then that one will be used 100% of the time, regardless of the weight you give it.

Weights are only used for platforms that are considered to be available according to Radar and Sonar availability checks, depending on the configuration of the application. Unavailable platforms cause the distribution to not match the configured weights. For example, if P1 is weighted 100 and P2 is weighted 0 but P1 fails the Radar Availability check, all traffic is sent to P2.

Handicap (Used for ORTT and Throughput)

The Handicap is a percentage value that can be applied to a platform to modify the radar scores for RTT and throughput that is, artificially increase the response time (in milliseconds) or decrease the throughput (in kbps). Increasing or decreasing these values bring down the performance of the platform such that the likelihood of it being picked will become lower. Handicaps can be added to platforms globally, or separately for specific markets and/or countries. It is useful in cases where, for example, one platform is expensive (maybe in a specific market/country) 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 Handicap value (in percentage) that acts as a multiplier to increase the value of response time or decrease the value of the throughput, as a result, lowering the probability of that platform being picked.

This is roughly how Handicap works in the back-end:

  • Platform RTT with Handicap applied = RTT (Round Trip Time in milliseconds) *( 1 + Handicap) or
  • Platform Throughput with Handicap applied = (Throughput in kbps) *(1 – Handicap)

Note: The RTT and Throughput values for the platform are scores from Radar data. The following table shows how Handicap effects the two platforms - P1 and P2. And how the Handicap decreases the likelihood of P1 being picked.

  P1 P2
RTT without Handicap 50 milliseconds 60 milliseconds
RTT with 50% (0.5) Handicap for P1, and 0% (0) for P2 50(1+0.5)= 75 milliseconds 60(1+0)= 60 milliseconds
Throughput without Handicap 3000 kbps 2800 kbps
Throughput with 50% (0.5) Handicap for P1, and 0% (0) for P2 3000(1-0.5)= 1500 kbps 2800(1- 0)= 2800 kbps

Filtering, Ranking, and Selection Workflow

Sample Flow diagram for Throughput App

Sample Flow diagram

Platform Selection Criteria

Openmix Quickstart apps use the following criteria as 1st, 2nd and 3rd level filters to rank and select the best platform.

Filtration Level Selection Criteria ORTT Throughput Round Robin Failover Static Routing
1st level Sonar Availability Check (if enabled) X X X X X
2nd level Radar Availability Check (if enabled) X X X X X
3rd level Weights (user defined) NA NA X NA NA
3rd level Round Trip Time (in milliseconds) X NA NA NA NA
3rd level Throughput (in kbps) NA X NA NA NA

Reason Code Reporting

Reason codes are a way of providing visibility into why the app made the decision it did, and also knowing what parts of the app’s code was executed. During execution, an app can add something to the reason code field at any time. Reason codes mean different things for each Quickstart App. There may be some commonality between reason codes for each app, but it is not comprehensive.

Note: For reason codes to be displayed correctly, they must not exceed the maximum character limit of 200 characters. If this limit is exceeded, the reason code is displayed as Unknown. Another reason why Unknown is displayed is if the user has not added a reason code.

These are the reason codes for Quickstart Apps:

App Reason Code Logic  
Static Routing Routed by static app A single specified platform is always selected.  
Round Robin Routed by weighted round robin with Radar availability All platforms that meet the availability threshold are first chosen. On those platforms, round robin distribution methodology is applied. For example, if platforms P1, P2 and P3 meet the availability threshold —the first request is routed to P1, second to P2, third to P3, fourth to P1 again, and so on.  
    Routed to fallback due to zero weight If all the platforms have been given zero weight, then fallback is returned. For example, if all platforms have been set to a zero weight in China and a DNS/HTTP request comes from China, none of the platforms are eligible for selection due to a zero weight. A fallback is returned in this case.
    Routed by weighted round robin Routed based on round robin distribution methodology. Here, there is no availability threshold specified so the first level of filtering based on availability doesn’t happen.
    Routed randomly due to insufficient data Radar scores are not available. A platform is chosen randomly as a result.
ORTT Routed based on Radar HTTP availability data All platforms that meet the availability threshold are first chosen. Out of these platforms, the platform with the lowest RTT value is chosen.  
    Routed to fallback due to sonar availability Sonar says that the platform is down, therefore it is routed to fallback.
    Routed to fallback no available platforms None of the platforms specified in the app have Radar Availability at or above the availability threshold.
    Routed randomly due to insufficient data Radar scores are not available. A platform is chosen randomly as a result.
Throughput Routed based on Radar http_kbps and Availability All platforms that meet the availability threshold are first chosen. Out of these platforms, the platform with the highest throughput in the case of http_kbps is chosen.  
    Routed based on Radar http_kbps data The platform with the highest throughput in the case of http_kbps is chosen.
    Routed randomly due to insufficient data Radar scores are not available. A platform is chosen randomly as a result.

Openmix Quickstart Applications

  1. Log in to the Intelligent Traffic Management Portal.
  2. From the left navigation menu, navigate to Openmix > Application Configuration.
  3. If you are configuring your Openmix app for the first time, you see the Get Started page, when you click Openmix > Application Configuration.
  4. To configure a new app, either click the Get Started button or the Add button on the top right corner of the page. If Openmix apps have been configured previously, you see a list of apps on this page.

The following sections walk you through the process of configuring Openmix apps in the portal.

Static Routing

This type of application does not use any evaluative logic to decide which DNS response must be provided to the end-user. The app always selects a single platform here, specified by the user. Therefore, only a single DNS CNAME or IP address response is utilized by the app. The Static Routing application can be configured through the portal on the Application Configuration page.

Note: Before configuring your application, ensure that your platforms are first configured. See Platforms page for platform configuration.

  1. Navigate to Openmix > Application Configuration.
  2. Click the Add button on the top right

The Basic Information dialog box opens.

Basic Information

Follow these steps to enter Basic Information:

  1. For Protocol, select DNS or HTTP from the list.
  2. For Application Type, select Static Routing. Or if you’re configuring another type of app, select it from the list.
  3. Give a Name to your application (required field); add a Description (optional field); and a Tag (optional field).
  4. Click Next for Configuration.

Configuration

To configure the app, do the following:

  1. Select the associated platform from the Platform list. This is the platform you set up within the Platforms page, representing the CDN, Cloud, or Data Center.
  2. Enter a CNAME/A/AAAA record (for DNS) or URL (for HTTP). The DNS CNAME or HTTP URL for the selected platform must point to a valid IP address or host name.
  3. For CORS, (in an HTTP protocol) select None, All, or Custom for CORS. CORS allows you to control access to your site from other sites. You can either completely restrict access to your site from other sites (by clicking None), allow access from all other sites (by clicking All), or allow access only from specific sites (by clicking Custom).
  4. Enter a TTL (Time-To-Live) for the response. The default is 20 seconds but it can be overridden.
  5. Click **Complete.
  6. In the confirmation pop-up click Done or Publish to see your app listed in the Openmix applications page. If you click Publish, your app goes live instantly and have a green status. This means that the application is in production. If you click Done, your app will still be listed on the applications page but it will be unpublished, and the status will be red.

Failover

The Failover application supports a simple routing logic where a platform is chosen based on its place in line, and its availability. The customer can create a failover chain that decides which platform to select first, second, and so on. This failover chain can be created to work globally and/or for individual markets and countries.

The Failover application can be configured within the portal on the Application Configuration page.

Note: Before configuring your application, ensure that your platforms are configured first. Refer to the Platforms page for platform configuration.

  1. Log in to the Portal.
  2. From the left navigation menu, navigate to Openmix > Application Configuration.
  3. Click the Add button on the top right to get to the New Openmix Application, Basic Information dialog box.

Basic Information

  1. Select DNS from the Protocol list.
  2. From the Application Type list, select Failover.
  3. Give a Name (required field) to your application; add a Description (optional field); and a Tag (optional field).
  4. When done, click Next.

Failover Basic Information

Configuration

  1. In the Configuration dialog box, select the Availability Threshold check box. The Availability Threshold has a default value of 80%. This means that a platform must have availability score at least as high as this threshold to be considered for routing.
    • If you want to modify the default availability threshold, just type in a new value to replace the default.
    • If no platform has an availability score that is equal or greater than the specified threshold, then the fallback (CNAME/A/AAAA or IP address) is used.
    • If the check box is unselected then the platform assumes a zero availability threshold. This means that there will be no Radar availability check on this platform.
  2. Enter a CNAME/A/AAAA or IP address for Fallback. The fallback CNAME/A/AAAA or IP is typically used if the application encounters issues, or errors.
  3. Enter a TTL (Time-To-Live) for the response. The default is 20 seconds. You can override this value if necessary.

Failover Configuration

Platform Information

  1. In the Platform Information dialog box, select a Platform from the list.
    • You can select multiple platforms using the Add Platforms button. The idea is to select all available platforms applicable for global and geo (markets and countries) routing.
    • The platforms on this list are those that you set up in the Platforms page (within the portal), representing your CDN, Cloud, or Data Center.
    • All Openmix apps require an associated platform to be set up beforehand. If you don’t find a platform in the list, you can set it up in the Platforms page within the portal.
  2. Enter the CNAME/A/AAAA record for the platform.
  3. Ensure that the Enabled check box is selected (indicating that the platform is enabled) before moving to the next step.
  4. If Sonar is configured and you want to use Sonar data to help in the initial decision making process, make sure to click the Use Sonar for Platform Availability check box. Note: The Sonar check box appears only if Sonar is enabled for that platform.
  5. Click Next for Location Configuration.

Location Configuration

  1. In the Location Configuration dialog box, select the required platforms for Global routing.
    • Global indicates that you are setting up a chain of platforms for global routing.
    • When you click inside the Global field, a list displays all the platforms you selected in the Platform Information step.
    • Select the required platforms from the list for availability-based global routing.
    • The order in which you place the platform names in this field determine the priority for their selection that is, they will be selected from first to last based on availability. For example, if the first platform on your list is unavailable, the second will be selected and so on. If none of the platforms on the list are available, then fallback is used.
    • You can drag the platform names to change their order of priority.
  2. Click Markets & Countries if you would like to set up platforms for local geo routing.
    • When you click inside the Markets & Countries field, the list displays all the platforms you selected in the Platform Information step.
    • Select platforms for local geo routing, separately for each geo (market/country).
    • The order in which you place the platform names in this field determine the priority for their selection that is, they will be selected from first to last based on availability. For example, in China, you may want to use the China POP first, and only if that is not available, you would want your Singapore POP to be used, which you would place next in line, and so on.
    • You can drag the platform names to change their order of priority.

    Failover Location Information

  3. Click Complete, to finish configuring your app.
  4. In the confirmation pop-up click Done or Publish to see your app listed on the Openmix page.
    • If you click Publish, your app goes live instantly and have a green status. This means that the application is in production.
    • If you click Done, your app will still be listed on the Openmix page but it is unpublished, and the status will be red.

Round Robin

This application follows a typical Global Server Load-Balancing methodology of Round Robin, where each CNAME alternates being returned to end-users, as DNS requests are made. It uses Sonar data (if Sonar is enabled) and Platform Availability threshold to evaluate the best platform for the requesting user then. Each platform is selected based on the Round Robin distribution methodology. For example, if platforms P1, P2 and P3 meet the availability threshold —the first request is routed to P1, second to P2, third to P3, fourth to P1 again, and so on.

To configure a new Round Robin app, click the Add button on the top right corner of the Openmix page. The Basic Information dialog box opens up.

  1. Log in to the Portal.
  2. From the left navigation menu, navigate to Openmix > Application Configuration.
  3. Click the Add button on the top right to get to the New Openmix Application, Basic Information dialog box.

Basic Information

  1. In the Basic Information dialog box, select DNS as the Protocol for Round Robin.Note: For the Round Robin app, routing is available only via a DNS CNAME.
  2. Select the Application Type from the list. Give the app a Name (required field), a Description (optional field), and a Tag (optional field).
  3. Click Next for Configuration.

Configuration

  1. The Availability Threshold has a default value of 80%. To modify this value, just type in a new value to replace the default.
  2. Enter a CNAME/A/AAAA or IP address for Fallback. The fallback CNAME/A/AAAA or IP is typically used if the application encounters issues, or errors.
  3. Enter a TTL (Time-To-Live) for the response. The default is 20 seconds but this value can be overridden if necessary.
  4. Click Next for Platform Information.

Platform Information

  1. Select a platform from the Platform list. Note: All Openmix apps require an associated platform set up beforehand. If you don’t find a platform in the list, you can set it up in the Platforms page within the portal.
  2. Select more platforms by clicking the Add Platform button.
  3. Enter a CNAME or an A/AAAA record or IP (in DNS), or URL (in HTTP) for this Platform. It must be a valid URL, host name, or IP address. It can be of the form: scheme:[//host[:port]][/path][?query][#fragment].
  4. Ensure that the Enabled check box is selected (indicating that the platform is enabled) before moving to the next step.
  5. If Sonar is available, and you want to use Sonar data to help in the initial decision making process, make sure to click the Use Sonar for Platform Availability check box.
  6. Click Save** to go to Step 4 to assign appropriate weights for each platform.

Location Configuration

  1. Assign Weights for the prioritization and selection of each platform globally and/or by market or country.
  2. To assign platform weights separately for market or country, enter the name in the Markets & Countries search box and choose from the list.
  3. Click Complete for your application to be created.
  4. In the confirmation pop-up click Done or Publish to see your app listed on the Openmix page. If you click Publish, your app goes live instantly and have a green status. This means that the application is in production. If you click Done, your app will still be listed on the Openmix page but it is unpublished, and its status will be red.

Optimal Round Trip Time (ORTT) App

The ORTT app uses Radar Response Time, Sonar data (if Sonar is enabled), and the Platform Availability threshold to evaluate the best platform for the requesting user then. The availability threshold is the minimum availability (80% is the default value) that the platform must meet to be picked. In addition, the ORTT app also uses a Handicap value that can be included globally and/or locally (for specific markets or countries) to allow customers to influence how end-users are routed.

The first three steps – Basic Information, Configuration, and Platform Information, are entered in the same manner as the other apps.

Follow these steps to configure location information and enter values for Handicap for each platform, globally, or by location/market.

Location Configuration

  1. In the Location Configuration dialog box, enter a value for Handicap for one or all of the platforms selected. You can enter a handicap value between 0 and 6000. The use of the handicap is to manually lower the chances of a particular platform being picked for routing, when there are better platforms available, in terms of cost or convenience for example. The more the handicap value, the lesser the chance of the platform being picked. You can deselect a platform if required by turning off the Platform Selection button.

  2. Click Markets & Countries to select a particular market or country from the list and enter Handicap values separately for each of the associated platforms.

  3. Click Complete, to finish configuring your app.

  4. In the confirmation pop-up click Done or Publish to see your app listed on the Openmix applications list page. If you click Publish, your app goes live instantly and have a green status. This means that the application is in production. If you click Done, your app will still be listed on the Applications page but it is unpublished, and its status will be red.

Throughput

The Throughput app selects the platform based on Sonar data (if Sonar is enabled), highest throughput (using Radar data), and platform availability threshold (which is 80% by default). In addition, this app allows you to add a Handicap value to decrease the throughput for specific platforms and influence how end-users are routed. This optional Handicap value can be assigned globally and/or locally (for specific markets or countries).

The first three steps – Basic Information, Configuration, and Platform Information, are entered in the same manner as the other apps. The Location Configuration is entered in the same way as in the ORTT app.

When you’re done, click Complete to return to the Openmix applications list page. Finally, click Publish to publish your application when you are ready to go live.

Status of the application

The status of the app shows its current configuration.

  • Red stands for unpublished. When you complete configuration, if you click Done, your application is listed in the applications page with a red dot, denoting that it has not been published yet.
  • Green stands for published. If you click Publish your app goes live instantly, and be denoted with a green dot which means that the application is in production.
  • Yellow stands for latest version unpublished. The yellow dot indicates that the application was created and edited, and the last modified settings are not yet published.

Managing Quickstart Applications

You can manage Openmix applications (editing, duplicating, deleting, and testing); and also view reports, view source and view the application’s version history using the top tabs within the application manager panel. Click your application in the Openmix applications list page to expand the application manager.

Managing Openmix Applications

View Report

View Report takes you to the Openmix Decision Reports page where you are able to view the trend of Openmix decisions for each of your applications, platforms, and geographies.

Edit

To edit your Openmix app, simply click the Edit icon on the top of the application manager panel. You can also perform individual edits separately for basic information, configuration, platform, or location information by clicking the Edit buttons within the panel as shown in figure. When you finish editing, click Done, to list the app with an unpublished status (for more edits later), or click Publish to go live instantly.

Duplicate

Click Duplicate to replicate the configuration of the current application and save it with a new name.

Delete

Click Delete, to remove applications that you no longer need.

Publish

Click Publish to directly publish the application from the Openmix application manager. This option is visible only if the app is not yet published.


Openmix Custom JavaScript Applications

Openmix JavaScript applications are apps with fully customizable Java scripts that you can create, configure, test, and publish using the UI in the ITM (Intelligent Traffic Management) portal.

Note: This guide does not cover the actual creation of the custom script (syntaxes, variables and so on). For more information on creating custom JavaScripts, refer to the Developer Exchange.

  1. Log in to the ITM portal.
  2. From the left navigation menu, go to Openmix.
  3. Choose Application Configuration.
  4. To configure a new Openmix app, click the add icon on the top right corner.
  5. Select Custom JS App.
  6. The Openmix Application Configuration page opens.

Add Custom JS App

Basic Information

  1. Application Name: Give a name to your app.
  2. Description: Give the app a description or add a release note here. This is an optional field.
  3. Tags: Enter an appropriate tag, if necessary. Tags help to identify and organize your app. This is an optional field.
  4. Fallback: Enter a CNAME/A/AAAA or IP address for Fallback. The fallback CNAME/A/AAAA or IP is typically used if the application encounters issues, or errors.
  5. Protocol: Select DNS or HTTP as the protocol.
    • DNS: If you select DNS, a TTL value must be entered.
      • TTL: Enter a DNS Time to Live for the application. 20 seconds is the recommended value.
    • HTTP: If you select HTTP, you have the option to enable Secure Access.
  6. Secure Access: If Secure Access is enabled, the HTTP API must require an Oauth access key from the client when being called. Refer to Securing Openmix HTTP API to learn more.

    Note: With secure access is enabled, a lock icon is displayed next to the app name in the list of apps on the Openmix front page.

Basic Info

Custom JavaScript

Once you enter the configuration information, you can upload your custom JavaScript.

  1. Click the Choose File button and select the JavaScript file that you want to upload. You can upload a new file to overwrite an existing one at any time.

  2. Click Save & Test to save your application.

    Note: The application is automatically tested using an application checker when it is uploaded and saved. If there are errors, the application checker shows the error information and the location of the error. Refer to the Application Verification section for more information about the data available from the application checker.

    Publish

  3. Click Cancel to return to the Openmix Applications page or click Publish if you are ready for the application to go live.

    Note: If you click Publish, your app goes live instantly and have a green status. This means that the application is in production.

    If you click Cancel, your app is listed on the applications page but will be unpublished, and the status will be red. To learn more about status refer to the Status of the Application section.

Publish

Staged Application Rollout

You can manage the rollout of your application by sending a small percentage of your web traffic through a new version sometimes referred to as a Canary Deployment. ITM allows you to send a specified percentage of traffic to the newest version of an app to ensure the application logic behaves as expected. You can report on the behavior of the existing and new versions to evaluate the changes to your app in a live environment. This allows you to fix any issues or anomalies that might occur before routing 100% of your web traffic through your newly edited app. After verifying the desired behavior, you can increase the percentage of traffic to the newest version or deploy the application to all users.

To stage the application rollout and release a test version of your newly modified app, do the following:

  • Click the app name (in the Openmix applications list page). The application manager panel opens.
  • Click the Edit icon to edit your app.
  • Modify your existing app with all necessary changes.
  • Once you’re done with the edits, click Save and Test.
  • Scroll down to the horizontal panel at the bottom of the page with Cancel and Publish buttons. Enter the percentage of web traffic (1% to 99%) that you want flowing through this newly modified version.
  • Check the box for partial distribution of traffic through this new version of the application with the remaining traffic sent to the previous live version.
  • Click Publish. This new test version of the app will now appear in the list of apps in the Openmix Configuration page with a new Status icon. The new Status icon signifies that only partial web traffic is flowing live through this version.

You can further modify the traffic flow to the test version and view performance by changing the percentage of traffic flow. Canary

To check the performance of your app, go to the Openmix Decision Report. Select Application as your primary dimension, and Version as your secondary dimension. Then click Apply Filters after selecting your application from the list. The chart shows the performance of different versions of your application.

Once you’re satisfied with performance of this version of the app, you can go ahead and route 100% of your web traffic through it by clicking the Go Live button.

Canary

This replaces the current live version with the newly edited version.

If you don’t want to go live with this version, click Unpublish. Your changes are saved and appear as an unpublished app in the list of apps in the Openmix Configuration page. Now 100% of your web traffic flows through the current live version of your app.

Test

You can test your JavaScript application using the Test App button before or after publishing.

Test

It enables you to view test results across specific sets of markets, countries, regions, and states. You also have an option to query the app from specific IP addresses.

Test results include, Platform selected by the app, Response received, Reason Code, Reason Log, Radar Scores, Distribution and so on

This feature also allows you to view the distribution of decisions across different platforms. For example, if two platforms were used for routing, you can view the number of decisions (raw count, and in percentage) and the response received for each of them.

Click the Show All Details link to see the test results of your app.

Test Details

The following values are shown as test results:

Field Description
Market, Country, Region, and State The location at which the app was tested.
Platform The platform selected by the app.
Response The CNAME or IP address of the platform selected by the app.
Reason Code Describes the reason behind the decision.
Reason Log Customer defined output from the app. Enables customers to log information about the app decisions.
Radar Score The Response Time (RTT), Availability, and Throughput measurements recorded for the platform.
Distribution The distribution of platforms that are selected by the app for each location tested. The Count represents the number of times the platform was selected. And the Percentage is the percentage of the total count for platform selection.

Note: You can run this test on the live app or the unpublished version (that is, if the app is not yet published).

Once your app is published, you have the option of testing the live app by clicking the Test Live App option. If you edit your app or upload a new version, you can test it before publishing by clicking the Test Unpublished App button.

Test Live App

Application Verification

To ensure that custom JavaScript apps behave as expected, the apps are run through a code and logic verifier when they are uploaded to the ITM Portal. The application verifier runs the app through a decision server with synthetic traffic to test whether the application compiles and runs successfully.

If the application runs without error, the verifier will provide information about the decision distribution and execution characteristics. On the other hand, if the decision server encounters an error while running the app, the verifier will provide information about the error. We recommend the application be free of errors before publishing.

In errors, you can fix the JavaScript file in your local and reupload it to the Portal by clicking the Choose File button.

Publish

To publish your app and have it go live, click the Publish button. This option is grayed out if the app is not yet saved or already published. When the app goes live, it appears in the Openmix application manager page with a green status. To learn more about app status refer to the Status of the Application section.

Publish

Note: The app can be published with errors if necessary.

Managing Custom JavaScript Applications

You can manage Openmix apps (that is, view reports, edit, duplicate, delete, publish, view source, view live version, view history, and test) using the top tabs within the application manager panel.

Click your app in the Openmix applications list page to expand the application manager panel.

Manage

View Report

View Report takes you to the Openmix Decision Reports page where you are able to view the trend of Openmix decisions for each of your apps, platforms, and geographies.

Edit

To edit an Openmix custom Javascript app, click the app name (in the Openmix applications list page). The application manager panel opens. Changes and updates can be made to the configuration by clicking the Edit icon.

Edit

View Source

View Source allows you to view the JavaScript source of the app, that is, the latest version of the app whether it was published. This option is only available for custom JavaScript apps.

View Live Version

You can view, copy, and download the latest published version of the app using this option. This is only available for custom JavaScript apps.

Live

Application History

Application History allows you to view different versions of the app. You can use the Select a Version list to switch from a live version to an older version. Click Get Content to switch to the older version. This option is only available for custom JavaScript apps.

History

Compare

The Compare feature allows you to compare different versions of your JavaScript file. You can see the differences between two versions of your app clearly displayed with highlighted lines of script.

Compare

Delete

To delete an Openmix app, click the app name (in the Openmix applications list page). The application manager panel opens. Click the Delete icon, and then choose the Delete button in the confirmation dialog box. The app disappears from the list.

Restore App

The Restore App feature allows you to re-enable an app after it has been deleted. To restore an app, do the following:

  1. Click the Add + icon on the top right of the page.
  2. Choose Restore App from the dropdown menu. The Restore Application window opens.

    Restore App

  3. Find the app that you want to re-enable from the list and click its corresponding Restore button.

This will put the app back on the list in the Openmix page with the same status as before it was deleted.

Securing Openmix HTTP API

Openmix is available via DNS or an HTTP API for integration into non-DNS workflows. By default, the HTTP API is called over plain HTTP. The API can also be secured via TLS and key authentication. This can be done via the UI by checking the box for Require Secure API Access (HTTPS).

Secure Access

Creating API Keys

To enable key authentication, do the following.

  1. Turn on secure access for each application by checking the Require Secure API Access (HTTPS) box in the Openmix Application Configuration page.

  2. To generate a secure access key, navigate to My Account -> API -> Openmix HTTP API Keys

    Openmix HTTP API Keys

  3. If you’re a first time user, you are prompted to get started by entering your client ID. Enter your Client ID in the New Client dialog, and click Complete.
  4. The Client Secret key will now be displayed beside the Client ID on the Openmix HTTP API Authentication Configuration page.

  5. You can now make a request to the Openmix app using basic authentication. Use your Client ID as the user name and the Client Secret as the password when you invoke the app on the browser.

    Alternatively, if you’re invoking the app using the command line, use this cURL command -

    curl https://hopx.cedexis.com/zones/<zone>/customers/<customer_id>/apps/<app_id>/decision --user <client_key>:<client_secret>
    

Note: Keys you create will give you access to any of your Openmix applications.

For more information on calling the Openmix HTTP API, please refer to the Openmix HTTP API usage documentation.

Deleting API Keys

  1. To delete a key, navigate to the Openmix HTTP API Authentication Configuration page.
  2. Click the Client ID.
  3. Choose Delete in the list. The key is removed from the system and will no longer be valid for authentication secure access to the Openmix application.

Accessing Logs

Decisions log made by Openmix can be collected and made available for secure download. These logs can help you analyze the decisions made by your Openmix application and debug request behavior. The logs can be turned on/off and secured at the account level. For details on how to enable and download Openmix logs and see log descriptions go to Netscope.

Netscope Openmix

Openmix Reports

Openmix reports provide powerful visibility into the Openmix decisions that were made for your DNS or HTTP traffic. Each report is defined below, but here are some important aspects of all of the reports:

Primary and Secondary Dimensions

Dimensions

The primary dimension of the chart is selected through a list selection list above the chart. Use this as a powerful pivot on the report. A secondary dimension can be chosen as well to further refine the reporting.

Visualization Background Toggle

Background Toggle

Charts are set to a white background by default. Toggle the background to a dark color for high contrast monitors using the background toggle.

Data Export

Data Export

In addition, the end-user is able to download the Chart and Table data via the download link at the top of the report.

Filter: Report Time Range

Time Range

The reports can be generated with a time range of Last 60 Minutes, Last 24 Hours, Last 48 Hours, Last 7 Days, Last 30 Days, or a custom range. The default view is the Last 24 Hours.

Filters: Powerful Drill-down Capabilities

Filters

The reports vary slightly in terms of which filters are appropriate based on the data. The following are the most common:

  • Statistic - Select the value shown in the chart, most often the number of decisions.
  • Traffic Source – Select the type of traffic to display: DNS or HTTP.
  • Application – Select one or more Openmix applications to display.
  • Platform – Select one or more platforms (provider) to include.
  • Continent – Select one or more continents to include.
  • Country – Select one or more countries to include.
  • Region – Select one or more geographic regions (where applicable) to include.
  • State – Select one or more geographic states (where applicable) to include.
  • Network – Select one or more networks (ASN) to include.

Benefit Report

The Benefit report gives you the overall improvement in the performance of your application delivery when you use the Intelligent Traffic Management (ITM) service. The benefit is shown as a percentage improvement in response time and throughput generated by choosing a specific platform from the pool of candidate platforms.

Primary Dimensions for the Benefit Report

Primary dimensions are independent measures based on which the Benefit Report is displayed. The following sections describe each of these primary dimensions in detail.

Benefit Report Primary Dimensions

Summary

Summary is the default primary dimension. The summary chart shows the average of the total percentage benefit (in terms of response time or throughput) received from all the applications.

Note: You can switch between the benefit shown in terms of Response Time or Throughput by using the Statistic filter.

Benefit Report Summary

Application

When Application is chosen as the primary dimension, the chart shows each of the applications and the corresponding performance (in terms of response time or throughput) as a percentage benefit in choosing a certain platform over other candidate platforms.

Note: 0% means that there was no extra benefit or improvement in the decisions made by that application by selecting a specific platform over another.

Benefit Report by Application

Location (Continent, Country, Region, State)

When location (Continent, Country, Region, or State) is selected as the primary dimension, the benefit report shows the average of the total percentage improvement in performance (in terms of response time or throughput) for each location. You can select location by continent, country, region, or state.

Note: Platforms that are not eligible for selection because of geo rules or any other reason will not be counted in the calculation. However, platforms that are geo-fenced for the location in question will be counted.

Benefit Report by Location

Network

When you select Network as the primary dimension, you see the percentage improvement in performance for users grouped into the specific networks (or service providers) from which users access ITM. This helps you know which groups of users are seeing the performance benefit when coming from those specific networks.

Benefit Report by Network

Platform

When you select Platform as a primary dimension, you see individual platforms chosen by different apps and the corresponding improved performance when they’re chosen. The improved performance or benefit is in terms of response time or throughput (in percentage).

Note: The percentage improvement in performance shown here is when that platform is chosen by an app. The list on the chart, does not necessarily indicate a performance ranking between these platforms.

Benefit Report by Platform

Reason Code

When you select Reason Code as the primary dimension, the percentage shown in the chart is the overall average benefit when decisions are made for a specific reason code.

Benefit Report by Reason Code

Ignore Platforms in Benefit Report

To improve the accuracy of Openmix decisions for your benefit report, you can choose to ignore certain platforms and set the app to only select from platforms that are most suitable for comparison.

For example, your application has five platforms to consider for comparison - three in Europe for European traffic, and two in the US for US traffic. Geo rules specify that the European traffic must go via the European platforms; and the US traffic must go via the US platforms.

Therefore, when computing the benefit from the app, to ensure that computation is done only using the three European platforms, you can set the app to ignore the other two non-European platforms by using the ignoredProvider() method in your JavaScript.

The method takes the provider’s alias (for example provider-1, provider-2) as the input argument (much like the requireProvider() method). The API must be called once per alias.

Use this sample code in your JavaScript file within the onRequest function:

function onRequest(request, response) {
  response.ignoredProvider('provider-1');
  response.ignoredProvider('provider-2');
  response.setReasonCode('Ignoring provider-1 and provider-2');
  response.setTTL(this.__defaultTTL);
  response.respond('provider-3', 'cmg.test.fake.cname');
}

Decision Geo Location Report

This report shows the volume of Openmix decisions for each country. This map view can be viewed over time (based on the time range chosen for the report) by selecting the Play button at the bottom of the chart.

Decision Geo Location Report

Decision Report

This report shows the trend of Openmix decisions for each of the applications, platforms, and geographies.

Decision Report