Openmix

Überblick

NetScaler Intelligent Traffic Management (ITM) Openmix bietet einen revolutionären Ansatz für Global Traffic Management/Global Server Load Balancing (GTM/GSLB). Für das traditionelle globale Traffic Management bietet ITM einen DNS-basierten Ansatz für das Load-Balancing. ITM verwendet DNS-CNAME- oder -Einträge, bei denen DNS-Antworten in Echtzeit basierend auf der erforderlichen Geschäftslogik geändert werden. Openmix kann auf vielfältige Weise in den Video-Workflow und die Bereitstellung integriert werden.

GTM- oder GSLB-Tools und -Dienste basieren auf proprietären, nicht erweiterbaren, statischen Regelwerken, um eine begrenzte Anzahl fester Richtlinien für Failover, Round-Robin und Geo-Targeting zu definieren und zu steuern. Die Mission von NetScaler ITM ist es, Cloud-Strategien der nächsten Generation zu ermöglichen, die auf Echtzeit-Datenfeeds basieren. Die Openmix-Plattform bietet eine äußerst robuste Möglichkeit, Echtzeitdaten aus verschiedenen Quellen aufzunehmen. Sie stellt die Metadaten als Umgebungsvariablen bereit, die bei jeder Anfrage ausgewertet werden können.

Openmix: Hauptvorteile

• Beseitigung von Abhängigkeiten von einem einzigen Anbieter und Gewährleistung einer 100%igen Verfügbarkeit
• Kontrolle von Preis-/Leistungs-Kompromissen und Beseitigung von Problemen, die mit Multi-Sourcing verbunden sind
• Beseitigung von Unsicherheiten bei älteren Performance-Tools und selektives sowie strategisches Auslagern von Traffic
• Anwendung spezifischer Anbieter zur gezielten Ansprache einzelner Märkte

Funktionsweise von Openmix

Kunden melden sich im Citrix ITM-Portal an, um ihre erste Anwendung bereitzustellen. Eine Bibliothek mit Beispiel-Apps ist verfügbar, um den Einstieg zu erleichtern, sowie ein Schritt-für-Schritt-Assistent zur Erstellung von Anwendungen mit der gängigsten Routing-Logik. ITM Openmix-Anwendungen können zwei Protokolle zur Traffic-Steuerung unterstützen: DNS oder HTTP.

Anwendungsdefinierte Steuerung

Die global verteilte, bedarfsgesteuerte Openmix-Plattform verlagert die GTM/GSLB-Entscheidungsfindung näher an Ihre Anwendungszielgruppen. Jeder Host kann seine eigene benutzerdefinierte Openmix-Anwendung haben, die aktuelle Metriken und Variablen berücksichtigt, die die beste Optimierung für jede Routing-Anfrage bieten.

Openmix-Skripte werden in JavaScript programmiert, einer Sprache, die den meisten Webprogrammierern und Netzwerkadministratoren zugänglich ist. Dieser skriptbasierte Ansatz ermöglicht die Implementierung praktisch jeder Geschäftslogik mit minimaler Komplexität, um sie als Grundlage für wirklich dynamische Traffic-Management-Richtlinien zu nutzen. Dank der kollaborativen Natur unserer Kundengemeinschaft bietet ITM auch “Quick Start Apps” an, die Standardanwendungen sind, die keinen Code erfordern.

Wann HTTP- oder DNS-Dienste verwendet werden sollten

ITM Openmix ermöglicht eine breite Palette von Optimierungen der Inhaltsbereitstellung. Welche Methode Sie zur Aktivierung von Openmix verwenden, hängt weitgehend von den Besonderheiten Ihres Anwendungsfalls ab. Die DNS-Methode ist einfach zu implementieren, für Clients weitgehend transparent und für eine Vielzahl von Inhalten nutzbar. Die Möglichkeit, Anbieter zu wechseln, ist jedoch durch den in der DNS-Antwort festgelegten TTL-Wert begrenzt, und einige Inhalte können nicht mitten im Stream zu einem anderen Anbieter gewechselt werden. HTTP bietet mehr Integrationsflexibilität, und Optimierungsentscheidungen können getroffen werden, wenn dies für den Client optimal ist. Diese größere Flexibilität erfordert jedoch mehr Aufwand bei der Integration mit einem CMS oder Client.

Die folgende Tabelle fasst die Anwendungsfälle für Kunden für die DNS- und HTTP-Schnittstellen zusammen.

Openmix: DNS

CNAME-Delegierung

Die einfachste Integration für ITM-Kunden ist die Verwendung der DNS-CNAME-Delegierung. Die CNAME-Delegierung funktioniert, indem der Kunde seinen Endbenutzer-Hostnamen (im folgenden Beispiel www.acme.com) auf einen ITM-Hostnamen verweist.

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

Beim Empfang einer DNS-Anfrage von einem Endbenutzer trifft das ITM-System eine Echtzeitentscheidung. Die Entscheidung basiert auf Radar-Daten, der Geschäftslogik in der Anwendung und allen Informationen von Drittanbietern. Diese Entscheidung wird entweder als weiterer CNAME-Eintrag (in unserem Beispiel unten acme.cdn1.net) oder als A-Eintrag wie 111.222.111.222 formuliert.

Durch die Bereitstellung eines CNAME-Eintrags “leitet” ITM den Endbenutzer zum CDN, zur Cloud oder zum Rechenzentrum seiner Wahl. Es leitet den Endbenutzer an, diesen Anbieter anstelle eines anderen zu verwenden.

2-02-123d-000d.cdx.cedexis.net.  19  IN  CNAME acme.cdn1.net.
<!--NeedCopy-->

Sobald der CDN- oder Cloud-CNAME bereitgestellt ist, setzt der Computer des Endbenutzers die Auflösungskette fort. Er fordert einen CDN-Nameserver an, bis eine IP-Adresse des Knotens oder Servers empfangen wird. Daraufhin beginnt der Prozess des Herunterladens von Inhalten. Wenn ein Eintrag als Teil der Logik bereitgestellt wird, empfängt der Computer des Endbenutzers die IP-Adresse. Er verbindet sich direkt mit dem Server und initiiert den Download von Inhalten.

acme.cdn1.net.  132  IN  A  111.222.222.111
<!--NeedCopy-->

Zonen-Delegierung

Zusätzlich ist die autoritative DNS-Zonen-Delegierung eine Option zur Implementierung von Openmix. Der Kunde erstellt eine DNS-Zone und delegiert diese an eine im ITM-Portal erstellte Predictive DNS-Zone. Erstellen Sie einen Hostnamen in der delegierten Zone. Konfigurieren Sie ihn so, dass er eine Openmix-Anwendung oder einen dynamischen Predictive DNS-Eintrag verwendet, um eine Antwort zu generieren. Der Vorteil dieser Option ist, dass keine CNAME-Delegierung zwischen dem Hostnamen und der dynamischen Antwort von der ITM-Plattform erforderlich ist. Unter Verwendung des vorhergehenden Beispiels www.acme.com wird der Hostname direkt auf den konfigurierten Wert für das optimale CDN, die Cloud oder das Rechenzentrum aufgelöst.

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

A/AAAA-Einträge können auch anstelle von CNAMEs verwendet werden, und der Hostname wird direkt auf den Eintrag des optimalen Ziels aufgelöst.

www.acme.com. 19 IN A 111.222.222.111

DNS- und Time-To-Live-Auswirkungen

Faktoren wie Time-To-Live (TTL)-Werte werden sorgfältig berücksichtigt, wobei eine angemessene Zeit für den Inhalt und die Entscheidungsfindung für die Benutzer festgelegt wird. In den meisten Fällen empfiehlt ITM eine TTL von 20 Sekunden für Seiten- und Objektinhalte. Für Videoinhalte arbeitet der ITM-Berater mit dem Kunden zusammen, um das am besten geeignete Gleichgewicht basierend auf der Chunk-Länge und der Integrationsmethode zu finden.

Openmix: HTTP

Eine Alternative zu DNS ist die Verwendung der HTTP-API. Openmix verwendet HTTP-Anfragen, um einen Client wie einen Videoplayer oder ein CMS darüber zu informieren, welche Plattform zu einem bestimmten Zeitpunkt verwendet werden soll.

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"
    }
  ]
}
<!--NeedCopy-->

Der HTTP Openmix-Dienst verwendet dieselbe Anwendungslogik wie sein DNS-basiertes Gegenstück. Er enthält auch einige zusätzliche Erweiterungen, die eine weitere Profilerstellung eines Client-Computers ermöglichen. Mit HTTP Openmix ist es beispielsweise möglich, die Header für User-Agent String, X-Forwarded-For und Referer zu betrachten. IP-Überschreibungen können mithilfe von Abfragezeichenfolgen-Parametern bereitgestellt werden. Da die Nutzlast für HTTP Openmix erweiterbarer ist als DNS, ist es auch möglich, die Auswahl der CDN-, Cloud- oder Server-Entscheidung auf verschiedene Weisen bereitzustellen. Am häufigsten war bisher eine geordnete Liste von der bevorzugtesten Plattform zur am wenigsten bevorzugten (wie oben). Eine vollständige Liste ermöglicht es, den Entscheidungsrang an das CMS oder den Client zu übermitteln, erlaubt aber dennoch die Verwendung interner Heuristiken bei der Auswahl des Anbieters.

CMS-Integration

Einige Kunden bevorzugen es, die Anbieterauswahl serverseitig zu handhaben, anstatt die Anbieterauswahl in jedem Client zu implementieren. Die HTTP-API kann verwendet werden, um eine Optimierungsentscheidung von Openmix zum Zeitpunkt der Anfrage vom Client abzurufen. Sie kann verwendet werden, um eine Datei zu füllen, die vom CMS an den Client zurückgegeben wird.

Standardmäßig verwenden Openmix HTTP-Endpunkte die IP des Aufrufers für die Geolokalisierung und Entscheidungskriterien. Wenn Sie von einem CMS oder einem anderen System aufrufen, das sich zwischen dem Endbenutzer-Client und Openmix befindet, können Sie die IP als Parameter für die Entscheidung angeben.

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"
    }
  ]
}
<!--NeedCopy-->

Diese Methode ermöglicht es Ihnen, eine CMS-Integration zu verwenden, um Entscheidungen von Openmix abzurufen. Sie können auch die Vorteile der Geo- und ISP-Routenoptimierung für den Endbenutzer nutzen. Der von Openmix zurückgegebene Hostname wird dann in die Antwort, z. B. eine Video-Manifestdatei, verpackt und vom CMS an den Client zurückgegeben. Der Client verwendet die optimierte Entscheidung, ohne dass Änderungen zur Unterstützung der Openmix-Optimierung erforderlich sind.

Openmix-Anwendungen

Openmix Quickstart-Anwendungen sind Load-Balancing- und Traffic-Management-Anwendungen. Diese Anwendungen bieten Echtzeit-Traffic-Routing zum besten Anbieter basierend auf einer Reihe von Regeln.

Die Anwendungen werden für jede an Openmix gestellte Anfrage verarbeitet, und eine Routing-Entscheidung wird basierend auf der angegebenen Logik getroffen. Ein Kunde kann eine Anwendung für Inhalte mit hohem Geschäftswert und eine andere Anwendung für Inhalte mit geringerem Wert haben. Diese Anfragen werden separat geroutet.

Wenn Sie eine Anwendung aufrufen, geht eine einzelne Anfrage an einen der Load-Balancer von Citrix. Für DNS ist es eine einzelne DNS-Anfrage an die DNS-Load-Balancer. Für HTTP ist es eine GET- oder HEAD-Anfrage an den Openmix HTTP-Endpunkt.

Die folgenden Apps sind derzeit über das NetScaler Intelligent Traffic Management Portal verfügbar.

• Statisches Routing
• Failover
• Round Robin
• Optimale Round Trip Time (ORTT)
• Durchsatz
• Statische Nähe

Openmix Custom JavaScript-Anwendungen werden von spezialisierten Openmix-Servern verwendet, um auf DNS- oder HTTP-Anfragen basierend auf der Logik in den Skripten zu antworten. Die Bereitstellung der Skripte erfolgt über das Kundenportal, wo die App konfiguriert und veröffentlicht wird. Weitere Informationen zur Möglichkeit, eigene JavaScript-Skripte zu erstellen, finden Sie in den Informationen auf unserer Developer Exchange.

Bevor Sie mit der Einrichtung der Apps fortfahren, ist es wichtig, die folgenden Konzepte zu verstehen:

Verfügbarkeitsschwelle

Die Verfügbarkeitsschwelle ist der minimale Verfügbarkeitswert, den eine Plattform erreichen muss, um für das Routing in Betracht gezogen zu werden. Die standardmäßige minimale Verfügbarkeitsschwelle für alle Anwendungen beträgt 80 %. Sie können diesen Prozentsatz jedoch ändern und einen Wert festlegen, der für Ihren Standort, Ihre Netzwerkverfügbarkeit und Zuverlässigkeit angemessen ist.

Hinweis: Wenn keine Plattform diese minimale Verfügbarkeitsschwelle (den Standardwert von 80 % oder den von Ihnen festgelegten Wert) erreicht, wird für Round Robin-, ORTT- und Durchsatzanwendungen ein zufälliges Routing durchgeführt.

Fallback

Die Fallback-Antwort wird zurückgegeben, wenn die Openmix-Anwendung aus irgendeinem Grund nicht erfolgreich ausgeführt wird oder wenn Sonar bestätigt, dass keine Plattformen verfügbar sind. Daher muss ein gültiger Fallback-CNAME/A/AAAA-Eintrag oder eine IP (oder ein Pfad in HTTP) angegeben werden, mit dem Openmix antworten kann. Diese Fallback-URL oder dieser CNAME-Eintrag kann für eine Plattform sein, die in Openmix vorkonfiguriert ist. Fallback tritt manchmal auch in den folgenden Szenarien auf:

• Wenn Sie zwischen Versionen Ihrer Anwendung wechseln, laden Sie ein neues Skript hoch und veröffentlichen es. Es gibt eine kurze Millisekunden-Zeitspanne des Fallbacks, bis das neue Skript initialisiert und das alte entfernt wird.
• Sollte es jemals zu einer Überlastung kommen (was selten vorkommt), antwortet Openmix mit dem Fallback-CNAME/A/AAAA, da der Fallback die Last auf den Dienst ausgleicht.

Für den Fallback müssen Sie einen gültigen Hostnamen (CNAME/A/AAAA-Eintrag) oder eine IP-Adresse in DNS und eine gültige URI (sie kann die Form scheme:[//host[:port]][/path][?query][#fragment]) in HTTP haben) eingeben.

TTL

In Openmix teilt die DNS Time to Live (TTL) für die Anwendung den Resolvern mit, wie lange sie die Entscheidung beibehalten müssen, bevor sie Openmix erneut anfragen. Die TTL wird verwendet, um das Traffic-Volumen zu steuern, das eine Openmix-App erhält. Sie steuert auch, wie empfindlich eine App auf Änderungen in den Daten reagieren muss, auf die sie reagiert. Die Standard-TTL beträgt 20 Sekunden. Obwohl Sie diesen Wert ändern können, wird dies nicht empfohlen. Wenn Sie die TTL senken, erhalten Sie mehr Volumen und mehr Echtzeit-DNS-Abfragen. Dies kann zu zusätzlichen Kosten und einer geringeren Leistung führen, da DNS-Abfragen auf dem Client Zeit in Anspruch nehmen. Daher ist es am besten, den Standardwert der TTL nicht zu ändern.

Hinweis: Die Time to Live gilt für Quickstart-Apps, benutzerdefinierte JS-Apps, wenn in dem Code keine TTL angegeben ist, und für alle Fallback-Antworten.

Gewichte (für Round Robin verwendet)

Sie können Gewichte für die Priorisierung und Auswahl jeder Plattform global und/oder nach Markt oder Land zuweisen.

Nehmen wir zum Beispiel an, Sie haben drei Plattformen für Ihre Anwendung ausgewählt – P1, P2 und P3. Sie geben ihnen die Gewichte: 60, 50 bzw. 10. Die Round-Robin-App wandelt diese Werte in Prozentsätze um, z. B. P1=50 %, P2=42 % und P3=8 %, die sich zu 100 % addieren. Diese Prozentsätze bedeuten, dass 50 % der Zeit Benutzer über P1, 42 % der Zeit über P2 und 8 % der Zeit über P3 geleitet werden.

Die Gewichte, die Sie den Plattformen geben, müssen sich nicht zu 100 addieren. Sie können eine beliebige ganze Zahl zwischen 0 und 1.000.000 sein. Die Gewichte, die den Plattformen gegeben werden, addieren sich, wenn sie in Prozentsätze umgerechnet werden (durch die App im Backend), zu 100 %. Wenn alle ausgewählten Plattformen das gleiche Gewicht erhalten, wird der Traffic im Laufe der Zeit gleichmäßig auf sie verteilt. Wenn Sie eine Plattform haben, wird diese Plattform zu 100 % der Zeit verwendet, unabhängig vom Gewicht, das Sie ihr geben.

Gewichte werden nur für Plattformen verwendet, die gemäß den Verfügbarkeitsprüfungen von Radar und Sonar als verfügbar gelten, abhängig von der Konfiguration der Anwendung. Nicht verfügbare Plattformen führen dazu, dass die Verteilung nicht den konfigurierten Gewichten entspricht. Wenn beispielsweise P1 100 wiegt und P2 0 wiegt, aber P1 die Radar-Verfügbarkeitsprüfung nicht besteht, geht der gesamte Traffic an P2.

Handicap (für ORTT und Durchsatz verwendet)

Das Handicap ist ein Prozentwert, der auf eine Plattform angewendet werden kann, um die Radar-Werte für RTT und Durchsatz zu modifizieren, d.h. die Antwortzeit (in Millisekunden) künstlich zu erhöhen oder den Durchsatz (in kbps) zu verringern. Das Erhöhen oder Verringern dieser Werte senkt die Leistung der Plattform, sodass die Wahrscheinlichkeit, dass sie ausgewählt wird, gering wird. Handicaps können global oder separat für bestimmte Märkte oder Länder zu Plattformen hinzugefügt werden. In Fällen, in denen eine Plattform in einem bestimmten Markt oder Land teuer ist und Sie deren Wahrscheinlichkeit, ausgewählt zu werden, verringern möchten, wenn ein gleichwertiger Anbieter in Bezug auf die Leistung nahe liegt. Sie setzen einen Handicap-Wert als Multiplikator, um den Wert der Antwortzeit zu erhöhen oder den Wert des Durchsatzes zu verringern. Dies senkt die Wahrscheinlichkeit, dass eine Plattform ausgewählt wird.

Im Folgenden wird grob beschrieben, wie Handicap im Backend funktioniert:

• Plattform-RTT mit angewendetem Handicap = RTT (Round Trip Time in Millisekunden) * (1 + Handicap) oder
• Plattform-Durchsatz mit angewendetem Handicap = (Durchsatz in kbps) * (1 – Handicap)

Hinweis: Die RTT- und Durchsatzwerte für die Plattform sind Werte aus Radar-Daten. Die folgende Tabelle zeigt, wie sich Handicap auf die beiden Plattformen P1 und P2 auswirkt. Und wie das Handicap die Wahrscheinlichkeit verringert, dass P1 ausgewählt wird.

Workflow für Filterung, Ranking und Auswahl

Beispiel-Flussdiagramm für die Durchsatz-App

Plattformauswahlkriterien

Openmix Quickstart-Apps verwenden die folgenden Kriterien als Filter der 1., 2. und 3. Ebene, um die beste Plattform zu bewerten und auszuwählen.

Filterebene|Auswahlkriterien|ORTT| Durchsatz| Round Robin| Failover| Statisches Routing | Statische Nähe | —|—|—|—|—|—|—|—|

1. Ebene

   Sonar-Verfügbarkeitsprüfung (falls aktiviert)

   X

   X

   X

   X

   X

   X

2. Ebene

   Radar-Verfügbarkeitsprüfung (falls aktiviert)

   X

   X

   X

   X

   X

   NA

3. Ebene

   Gewichte (benutzerdefiniert)

   NA

   NA

   X

   NA

   NA

   NA

4. Ebene

   Round Trip Time (in Millisekunden)

   X

   NA

   NA

   NA

   NA

   NA

5. Ebene

   Durchsatz (in kbps)

   NA

   X

   NA

   NA

   NA

   NA

Berichterstattung über Ursachencodes

Ursachencodes geben Aufschluss darüber, warum die Entscheidung getroffen wurde, und zeigen auch, welcher Teil des App-Codes ausgeführt wird. Während der Ausführung kann eine App jederzeit etwas zum Ursachencode-Feld hinzufügen. Ursachencodes bedeuten für jede Quickstart-App unterschiedliche Dinge. Es gibt einige Gemeinsamkeiten zwischen den Ursachencodes für jede App, aber sie sind nicht umfassend.

Hinweis: Damit Ursachencodes korrekt angezeigt werden, dürfen sie die maximale Zeichenbegrenzung von 200 Zeichen nicht überschreiten. Wenn diese Begrenzung überschritten wird, wird der Ursachencode als Unbekannt angezeigt. Wenn der Benutzer keinen Ursachencode hinzugefügt hat, wird Unbekannt angezeigt.

Die folgenden Ursachencodes gelten für Quickstart-Apps:

Openmix Quickstart-Anwendungen

1. Melden Sie sich beim NetScaler Intelligent Traffic Management Portal an.
2. Navigieren Sie im linken Navigationsmenü zu Openmix > Application Configuration.
3. Wenn Sie Ihre Openmix-App zum ersten Mal konfigurieren, sehen Sie die Seite Get Started, wenn Sie auf Openmix > Application Configuration klicken.
4. Um eine neue App zu konfigurieren, klicken Sie entweder auf die Schaltfläche Get Started oder auf die Schaltfläche Add oben rechts auf der Seite. Wenn Openmix-Apps zuvor konfiguriert wurden, sehen Sie eine Liste der Apps auf dieser Seite.

Die folgenden Abschnitte führen Sie durch den Prozess der Konfiguration von Openmix-Apps im Portal.

Statisches Routing

Diese Art von Anwendung verwendet keine Bewertungslogik, um zu entscheiden, welche DNS-Antwort dem Endbenutzer bereitgestellt werden muss. Die App wählt hier immer eine einzelne, vom Benutzer angegebene Plattform aus. Daher verwendet die App nur eine einzelne DNS-CNAME- oder IP-Adressantwort. Die Static Routing-Anwendung kann über das Portal auf der Seite Application Configuration konfiguriert werden.

Hinweis: Bevor Sie Ihre Anwendung konfigurieren, stellen Sie sicher, dass Ihre Plattformen zuerst konfiguriert sind. Informationen zur Plattformkonfiguration finden Sie auf der Seite Plattformen.

Navigation

1. Navigieren Sie zu Openmix > Application Configuration.
2. Klicken Sie oben rechts auf die Schaltfläche Add.

Das Dialogfeld Basic Information wird geöffnet.

Grundlegende Informationen

Führen Sie die folgenden Schritte aus, um Grundlegende Informationen einzugeben:

1. Wählen Sie für Protocol DNS oder HTTP aus der Liste aus.
2. Wählen Sie für Application Type Static Routing aus. Oder wenn Sie einen anderen App-Typ konfigurieren, wählen Sie diesen aus der Liste aus.
3. Geben Sie Ihrer Anwendung einen Namen (Pflichtfeld); fügen Sie eine Beschreibung (optionales Feld) und ein Tag (optionales Feld) hinzu.
4. Klicken Sie auf Next für Configuration.

Konfiguration

Um die App zu konfigurieren, gehen Sie wie folgt vor:

1. Wählen Sie die zugehörige Plattform aus der Platform-Liste aus. Dies ist die Plattform, die Sie auf der Seite Plattformen eingerichtet haben und die das CDN, die Cloud oder das Rechenzentrum repräsentiert.
2. Geben Sie einen CNAME/A/AAAA-Eintrag (für DNS) oder eine URL (für HTTP) ein. Der DNS-CNAME oder die HTTP-URL für die ausgewählte Plattform muss auf eine gültige IP-Adresse oder einen Hostnamen verweisen.
3. Wählen Sie für CORS in einem HTTP-Protokoll None, All oder Custom für CORS aus. CORS ermöglicht Ihnen die Kontrolle des Zugriffs auf Ihre Website von anderen Websites. Sie können den Zugriff auf Ihre Website von anderen Websites entweder vollständig einschränken (indem Sie auf None klicken), den Zugriff von allen anderen Websites zulassen (indem Sie auf All klicken) oder den Zugriff nur von bestimmten Websites zulassen (indem Sie auf Custom klicken).
4. Geben Sie eine TTL (Time-To-Live) für die Antwort ein. Der Standardwert ist 20 Sekunden, kann aber überschrieben werden.
5. Klicken Sie auf Complete.
6. Klicken Sie im Bestätigungs-Pop-up auf Done oder Publish, um Ihre App auf der Openmix-Anwendungsseite anzuzeigen. Wenn Sie auf Publish klicken, wird Ihre App sofort live geschaltet und hat einen grünen Status. Dies bedeutet, dass die Anwendung in Produktion ist. Wenn Sie auf Done klicken, wird Ihre App weiterhin auf der Anwendungsseite angezeigt, ist aber nicht veröffentlicht, und der Status ist rot.

Failover

Die Failover-Anwendung unterstützt eine einfache Routing-Logik, bei der eine Plattform basierend auf ihrer Reihenfolge und ihrer Verfügbarkeit ausgewählt wird. Der Kunde kann eine Failover-Kette erstellen, die entscheidet, welche Plattform zuerst, zweitrangig usw. ausgewählt werden soll. Diese Failover-Kette kann entweder global oder für einzelne Märkte und Länder erstellt werden.

Die Failover-Anwendung kann im Portal auf der Seite Application Configuration konfiguriert werden.

Hinweis: Bevor Sie Ihre Anwendung konfigurieren, stellen Sie sicher, dass Ihre Plattformen zuerst konfiguriert sind. Informationen zur Plattformkonfiguration finden Sie auf der Seite Plattformen.

Navigation

1. Melden Sie sich beim Portal an.
2. Navigieren Sie im linken Navigationsmenü zu Openmix > Application Configuration.
3. Klicken Sie oben rechts auf die Schaltfläche „Add“, um zum Dialogfeld „New Openmix Application“, Basic Information zu gelangen.

Grundlegende Informationen

1. Wählen Sie DNS aus der Protocol-Liste aus.
2. Wählen Sie aus der Application Type-Liste Failover aus.
3. Geben Sie Ihrer Anwendung einen Namen (Pflichtfeld); fügen Sie eine Beschreibung (optionales Feld) und ein Tag (optionales Feld) hinzu.
4. Klicken Sie anschließend auf Next.

Konfiguration

1. Wählen Sie im Dialogfeld „Configuration“ das Kontrollkästchen Availability Threshold aus. Die Verfügbarkeitsschwelle hat einen Standardwert von 80 %. Eine Plattform muss einen Verfügbarkeitswert haben, der mindestens so hoch wie dieser Schwellenwert ist, um für das Routing in Betracht gezogen zu werden.
   • Wenn Sie die Standard-Verfügbarkeitsschwelle ändern möchten, geben Sie einfach einen neuen Wert ein, um den Standardwert zu ersetzen.
   • Wenn keine Plattform einen Verfügbarkeitswert hat, der gleich oder größer als der angegebene Schwellenwert ist, wird der Fallback-CNAME oder A- oder AAAA- oder IP-Adresse verwendet.
   • Wenn das Kontrollkästchen nicht ausgewählt ist, nimmt die Plattform eine Verfügbarkeitsschwelle von Null an. Dies bedeutet, dass für diese Plattform keine Radar-Verfügbarkeitsprüfung durchgeführt wird.
2. Geben Sie einen CNAME/A/AAAA oder eine IP-Adresse für Fallback ein. Der Fallback-CNAME/A/AAAA oder die IP wird typischerweise verwendet, wenn die Anwendung Probleme oder Fehler aufweist.
3. Geben Sie eine TTL (Time-To-Live) für die Antwort ein. Der Standardwert ist 20 Sekunden. Sie können diesen Wert bei Bedarf überschreiben.

Plattforminformationen

1. Wählen Sie im Dialogfeld Platform Information eine Platform aus der Liste aus.
   • Sie können mehrere Plattformen über die Schaltfläche Add Platforms auswählen. Die Idee ist, alle verfügbaren Plattformen auszuwählen, die für globales und geografisches (Märkte und Länder) Routing anwendbar sind.
   • Die Plattformen in dieser Liste sind diejenigen, die Sie auf der Seite Plattformen im Portal eingerichtet haben und die Ihr CDN, Ihre Cloud oder Ihr Rechenzentrum repräsentieren.
   • Alle Openmix-Apps erfordern eine zugehörige Plattform, die zuvor eingerichtet wurde. Wenn Sie keine Plattform in der Liste finden, können Sie diese auf der Seite Plattformen im Portal einrichten.
2. Geben Sie den CNAME/A/AAAA-Eintrag für die Plattform ein.
3. Stellen Sie sicher, dass das Kontrollkästchen Enabled (was anzeigt, dass die Plattform aktiviert ist) ausgewählt ist, bevor Sie mit dem nächsten Schritt fortfahren.
4. Wenn Sonar konfiguriert ist und Sie Sonar-Daten verwenden möchten, um den anfänglichen Entscheidungsprozess zu unterstützen, stellen Sie sicher, dass Sie das Kontrollkästchen Use Sonar for Platform Availability aktivieren. Hinweis: Das Sonar-Kontrollkästchen wird nur angezeigt, wenn Sonar für diese Plattform aktiviert ist.
5. Klicken Sie auf Next für Location Configuration.

Standortkonfiguration

1. Wählen Sie im Dialogfeld Location Configuration die erforderlichen Plattformen für das globale Routing aus.
   • Global zeigt an, dass Sie eine Kette von Plattformen für das globale Routing einrichten.
   • Wenn Sie in das Feld Global klicken, wird eine Liste aller Plattformen angezeigt, die Sie im Schritt Platform Information ausgewählt haben.
   • Wählen Sie die erforderlichen Plattformen aus der Liste für das verfügbarkeitsbasierte globale Routing aus.
   • Die Reihenfolge, in der Sie die Plattformnamen in diesem Feld platzieren, bestimmt die Priorität für deren Auswahl. Wenn beispielsweise die erste Plattform in Ihrer Liste nicht verfügbar ist, wird die zweite ausgewählt. Wenn keine der Plattformen in der Liste verfügbar ist, wird der Fallback verwendet.
   • Sie können die Plattformnamen ziehen, um ihre Prioritätsreihenfolge zu ändern.
2. Klicken Sie auf Markets & Countries, wenn Sie Plattformen für das lokale Geo-Routing einrichten möchten.
   • Wenn Sie in das Feld Markets & Countries klicken, wird eine Liste aller Plattformen angezeigt, die Sie im Schritt Platform Information ausgewählt haben.
   • Wählen Sie Plattformen für das lokale Geo-Routing separat für jedes Geo (Markt/Land) aus.
   • Die Reihenfolge, in der Sie die Plattformnamen in diesem Feld platzieren, bestimmt die Priorität für deren Auswahl. Wenn Sie beispielsweise in China zuerst den China POP verwenden möchten und nur wenn dieser nicht verfügbar ist, möchten Sie, dass Ihr Singapur POP verwendet wird, den Sie als Nächstes in die Reihe setzen würden, und so weiter.
   • Sie können die Plattformnamen ziehen, um ihre Prioritätsreihenfolge zu ändern.

   

3. Klicken Sie auf Complete, um die Konfiguration Ihrer App abzuschließen.
4. Klicken Sie im Bestätigungs-Pop-up auf Done oder Publish, um Ihre App auf der Openmix-Seite anzuzeigen.
   • Wenn Sie auf Publish klicken, wird Ihre App sofort live geschaltet und hat einen grünen Status. Ihre Anwendung ist in Produktion.
   • Wenn Sie auf Done klicken, wird Ihre App weiterhin auf der Openmix-Seite angezeigt, ist aber nicht veröffentlicht, und der Status ist rot.

Round Robin

Diese Anwendung folgt einer typischen Global Server Load-Balancing-Methodik von Round Robin, bei der jeder CNAME abwechselnd an Endbenutzer zurückgegeben wird, wenn DNS-Anfragen gestellt werden. Sie verwendet Sonar-Daten (falls Sonar aktiviert ist) und die Platform Availability-Schwelle, um die beste Plattform für den anfragenden Benutzer zu bewerten. Jede Plattform wird basierend auf der Round-Robin-Verteilungsmethodik ausgewählt. Wenn beispielsweise die Plattformen P1, P2 und P3 die Verfügbarkeitsschwelle erfüllen, wird die erste Anfrage an P1, die zweite an P2 und die dritte an P3 weitergeleitet. Die vierte Anfrage wird erneut an P1 weitergeleitet und so weiter.

Um eine neue Round-Robin-App zu konfigurieren, klicken Sie auf die Schaltfläche Add oben rechts auf der Openmix-Seite. Das Dialogfeld Basic Information wird geöffnet.

Navigation

1. Melden Sie sich beim Portal an.
2. Navigieren Sie im linken Navigationsmenü zu Openmix > Application Configuration.
3. Klicken Sie oben rechts auf die Schaltfläche „Add“, um zum Dialogfeld „New Openmix Application“, Basic Information zu gelangen.

Grundlegende Informationen

1. Wählen Sie im Dialogfeld „Basic Information“ DNS als Protokoll für Round Robin aus. Hinweis: Für die Round-Robin-App ist das Routing nur über einen DNS-CNAME verfügbar.
2. Wählen Sie den Application Type aus der Liste aus. Geben Sie der App einen Namen (Pflichtfeld), eine Beschreibung (optionales Feld) und ein Tag (optionales Feld).
3. Klicken Sie auf Next für die Konfiguration.

Konfiguration

1. Die Availability Threshold hat einen Standardwert von 80 %. Um diesen Wert zu ändern, geben Sie einfach einen neuen Wert ein, um den Standardwert zu ersetzen.
2. Geben Sie einen CNAME/A/AAAA oder eine IP-Adresse für Fallback ein. Der Fallback-CNAME/A/AAAA oder die IP wird typischerweise verwendet, wenn die Anwendung Probleme oder Fehler aufweist.
3. Geben Sie eine TTL (Time-To-Live) für die Antwort ein. Der Standardwert ist 20 Sekunden, dieser Wert kann jedoch bei Bedarf überschrieben werden.
4. Klicken Sie auf Next für Plattforminformationen.

Plattforminformationen

1. Wählen Sie eine Plattform aus der Platform-Liste aus. Hinweis: Alle Openmix-Apps erfordern eine zugehörige Plattform, die zuvor eingerichtet wurde. Wenn Sie keine Plattform in der Liste finden, können Sie diese auf der Seite Plattformen im Portal einrichten.
2. Wählen Sie weitere Plattformen aus, indem Sie auf die Schaltfläche Add Platform klicken.
3. Geben Sie einen CNAME oder einen A/AAAA-Eintrag oder eine IP (in DNS) oder eine URL (in HTTP) für diese Plattform ein. Es muss eine gültige URL, ein Hostname oder eine IP-Adresse sein. Es kann die Form haben: scheme:[//host[:port]][/path][?query][#fragment].
4. Stellen Sie sicher, dass das Kontrollkästchen Enabled (was anzeigt, dass die Plattform aktiviert ist) ausgewählt ist, bevor Sie mit dem nächsten Schritt fortfahren.
5. Wenn Sonar verfügbar ist und Sie Sonar-Daten verwenden möchten, um den anfänglichen Entscheidungsprozess zu unterstützen, stellen Sie sicher, dass Sie das Kontrollkästchen Use Sonar for Platform Availability aktivieren.
6. Klicken Sie auf Save, um zu Schritt 4 zu gelangen und geeignete Gewichte für jede Plattform zuzuweisen.

Standortkonfiguration

1. Weisen Sie Gewichte für die Priorisierung und Auswahl jeder Plattform global und/oder nach Markt oder Land zu.
2. Um Plattformgewichte separat für Markt oder Land zuzuweisen, geben Sie den Namen in das Suchfeld „Markets & Countries“ ein und wählen Sie aus der Liste aus.
3. Klicken Sie auf Complete, damit Ihre Anwendung erstellt wird.
4. Klicken Sie im Bestätigungs-Pop-up auf Done oder Publish, um Ihre App auf der Openmix-Seite anzuzeigen. Wenn Sie auf Publish klicken, wird Ihre App sofort live geschaltet und hat einen grünen Status. Ihre Anwendung ist in Produktion. Wenn Sie auf Done klicken, wird Ihre App weiterhin auf der Openmix-Seite angezeigt, ist aber nicht veröffentlicht, und ihr Status ist rot.

Optimal Round Trip Time (ORTT) App

Die ORTT-App verwendet die Radar-Antwortzeit, Sonar-Daten (falls Sonar aktiviert ist) und die Plattform-Verfügbarkeitsschwelle, um die beste Plattform für den anfragenden Benutzer zu bewerten. Die Verfügbarkeitsschwelle ist die minimale Verfügbarkeit (80 % ist der Standardwert), die die Plattform erreichen muss, um ausgewählt zu werden. Darüber hinaus verwendet die ORTT-App auch einen Handicap-Wert, der es Kunden global oder lokal ermöglicht, die Weiterleitung von Endbenutzern zu beeinflussen.

Die ersten drei Schritte – Grundlegende Informationen, Konfiguration und Plattforminformationen – werden auf die gleiche Weise wie bei den anderen Apps eingegeben.

Führen Sie die folgenden Schritte aus, um Standortinformationen zu konfigurieren und Werte für Handicap für jede Plattform, global oder nach Standort/Markt, einzugeben.

Standortkonfiguration

1. Geben Sie im Dialogfeld Location Configuration einen Wert für Handicap für eine oder alle ausgewählten Plattformen ein. Sie können einen Handicap-Wert zwischen 0 und 6000 eingeben. Der Zweck des Handicaps besteht darin, die Wahrscheinlichkeit, dass eine bestimmte Plattform für das Routing ausgewählt wird, manuell zu verringern, wenn bessere Plattformen in Bezug auf Kosten oder Bequemlichkeit verfügbar sind. Je höher der Handicap-Wert, desto geringer ist die Wahrscheinlichkeit, dass die Plattform ausgewählt wird. Sie können eine Plattform bei Bedarf abwählen, indem Sie die Schaltfläche Platform Selection deaktivieren.

2. Klicken Sie auf Markets & Countries, um einen bestimmten Markt oder ein Land aus der Liste auszuwählen und Handicap-Werte separat für jede der zugehörigen Plattformen einzugeben.

3. Klicken Sie auf Complete, um die Konfiguration Ihrer App abzuschließen.

4. Klicken Sie im Bestätigungs-Pop-up auf Done oder Publish, um Ihre App auf der Openmix-Anwendungsliste anzuzeigen. Wenn Sie auf Publish klicken, wird Ihre App sofort live geschaltet und hat einen grünen Status. Ihre Anwendung ist in Produktion. Wenn Sie auf Done klicken, wird Ihre App weiterhin auf der Anwendungsseite angezeigt, ist aber nicht veröffentlicht, und ihr Status ist rot.

Durchsatz

Die Throughput-App wählt die Plattform basierend auf Sonar-Daten (falls Sonar aktiviert ist), dem höchsten Durchsatz (unter Verwendung von Radar-Daten) und der Plattform-Verfügbarkeitsschwelle (die standardmäßig 80 % beträgt) aus. Darüber hinaus ermöglicht Ihnen diese App, einen Handicap-Wert hinzuzufügen, um den Durchsatz für bestimmte Plattformen zu verringern und zu beeinflussen, wie Endbenutzer weitergeleitet werden. Dieser optionale Handicap-Wert kann global und/oder lokal (für bestimmte Märkte oder Länder) zugewiesen werden.

Die ersten drei Schritte – Basic Information, Configuration und Platform Information – werden auf die gleiche Weise wie bei den anderen Apps eingegeben. Die Location Configuration wird auf die gleiche Weise wie in der ORTT-App eingegeben.

Wenn Sie fertig sind, klicken Sie auf Complete, um zur Openmix-Anwendungsliste zurückzukehren. Klicken Sie abschließend auf Publish, um Ihre Anwendung zu veröffentlichen, wenn Sie bereit sind, live zu gehen.

Status der Anwendung

Der Status der App zeigt ihre aktuelle Konfiguration an.

• Rot steht für unveröffentlicht. Wenn Sie die Konfiguration abgeschlossen haben und auf Done klicken, wird Ihre Anwendung auf der Anwendungsseite mit einem roten Punkt angezeigt, der darauf hinweist, dass sie noch nicht veröffentlicht wurde.
• Grün steht für veröffentlicht. Wenn Sie auf Publish klicken, wird Ihre App sofort live geschaltet und mit einem grünen Punkt gekennzeichnet, was bedeutet, dass die Anwendung in Produktion ist.
• Gelb steht für die neueste Version, die unveröffentlicht ist. Der gelbe Punkt zeigt an, dass die Anwendung erstellt und bearbeitet wurde und die zuletzt geänderten Einstellungen noch nicht veröffentlicht wurden.

Statische Nähe

Die Static Proximity-Anwendung antwortet auf die Plattform, die sich in der Nähe des Breiten- und Längengrads des anfragenden Benutzers befindet.

Hinweis:

Alle Openmix-Apps erfordern eine Reihe von zugehörigen Plattformen, die zuvor eingerichtet wurden. Wenn Sie keine Plattform in der Liste finden, können Sie diese auf der Seite „Platforms“ im Portal einrichten.

Navigation

1. Melden Sie sich beim NetScaler Intelligent Traffic Management Portal an.
2. Navigieren Sie im linken Navigationsmenü zu Openmix > Application Configuration.
3. Klicken Sie oben rechts auf die Plus-Schaltfläche Add Openmix App.
4. Wählen Sie Quickstart App aus.

Grundlegende Informationen

1. Wählen Sie im Dialogfeld Basic Information DNS als Protokoll aus.
2. Wählen Sie Static Proximity als Anwendungstyp aus. Geben Sie der App einen Namen (Pflichtfeld), eine Beschreibung (optionales Feld) und ein Tag (optionales Feld).
3. Klicken Sie auf Next für die Konfiguration.

Konfiguration

1. Falls aktiviert, hat die Availability Threshold einen Standardwert von 80 %. Geben Sie einen neuen Wert ein, um den Standardwert zu ersetzen.
2. Geben Sie einen CNAME/A/AAAA oder eine IP-Adresse für Fallback ein. Der Fallback-CNAME/A/AAAA oder die IP wird typischerweise verwendet, wenn die Anwendung Probleme oder Fehler aufweist. Dieses Feld darf nicht leer sein.
3. Geben Sie die TTL (Time-To-Live) für die Antwort ein. Der Standardwert ist 20 Sekunden, dieser Wert kann jedoch bei Bedarf überschrieben werden.
4. Klicken Sie auf Next für Persistency Controls.

Persistenzkontrollen

Richten Sie die lokale Persistenz ein. Weitere Informationen finden Sie unter Lokale Persistenz. Klicken Sie auf Next für Plattforminformationen.

Plattforminformationen

Jede Plattform muss ihre Breiten- und Längengrade über die Seite Platforms eingerichtet haben. Aliase für Community-Plattformen erben zunächst Geo-Informationen von der Community-Plattform, obwohl Sie diese nach dem Erstellen eines Alias ändern können. Private Plattformen müssen beim Erstellen oder danach über ihren Konfigurationsbereich eingerichtet werden. Um den Konfigurationsbereich anzuzeigen, klicken Sie einfach auf den Plattform-Eintrag der Tabelle.

Nur Plattformen, die zu den folgenden Kategorien gehören, können Geo-Informationen haben und Teil der Antwortliste einer opx-App sein:

• Cloud Computing
• Cloud Storage
• Rechenzentrum

1. Wählen Sie eine Plattform aus der Platform-Liste aus.

2. Geben Sie einen CNAME oder einen A/AAAA-Eintrag oder eine IP (in DNS) oder eine URL (in HTTP) für die Plattform ein. Es muss eine gültige URL, ein Hostname oder eine IP-Adresse sein. Es kann die Form haben:

   scheme:[//host[:port]][/path][?query][#fragment]

3. Stellen Sie sicher, dass das Kontrollkästchen Enabled ausgewählt ist (was anzeigt, dass die Plattform aktiviert ist), bevor Sie mit dem nächsten Schritt fortfahren.

4. Wenn Sonar für diese Plattform verfügbar ist und Sie Sonar-Daten während der DNS-Auflösung berücksichtigen möchten, stellen Sie sicher, dass Sie das Kontrollkästchen Use Sonar for Platform Availability aktivieren.

5. Sie können weitere Plattformen hinzufügen, indem Sie auf Add Platform klicken.

6. Klicken Sie auf Next für Location Configuration.

Standortkonfiguration

1. Im globalen Teil des Dialogfelds „Location Configuration“ können Sie eine Kette von Plattformen für das globale Routing einrichten. Sie können die Auswahl jeder Plattform global aktivieren oder deaktivieren.

2. In „Markets & Countries“ können Sie verschiedene Setups pro Markt oder Land erstellen und so effektive Geo-Fencing-Regeln für diese festlegen.

3. Klicken Sie auf Complete, um Ihre Anwendung zu erstellen.

Klicken Sie im Bestätigungs-Pop-up auf Publish, Add another oder Done:

• Wenn Sie auf Publish klicken, wird Ihre App sofort live geschaltet und der Status ist grün. Dies bedeutet, dass die Anwendung in Produktion ist.

• Wenn Sie auf Done klicken, wird Ihre App auf der Openmix-Seite angezeigt, ist aber nicht veröffentlicht, und der Status ist rot.

• Wenn Sie auf Add another klicken, ist der Status der App derselbe wie bei Done, aber Sie starten denselben Prozess, um eine neue App zu erstellen.

Verwalten von Quickstart-Anwendungen

Verwenden Sie die oberen Registerkarten im Anwendungsmanager-Panel, um die Versionshistorie der Anwendung zu bearbeiten, zu duplizieren, zu löschen, zu testen, Berichte anzuzeigen, die Quelle anzuzeigen und die Versionshistorie der Anwendung anzuzeigen. Klicken Sie auf Ihre Anwendung auf der Openmix-Anwendungslistenseite, um den Anwendungsmanager zu erweitern.

Bericht anzeigen

View Report führt Sie zur Seite „Openmix Decision Reports“, wo Sie den Trend der Openmix-Entscheidungen für jede Ihrer Anwendungen, Plattformen und geografischen Gebiete anzeigen können.

Bearbeiten

Um Ihre Openmix-App zu bearbeiten, klicken Sie einfach auf das Edit-Symbol oben im Anwendungsmanager-Panel. Sie können auch einzelne Bearbeitungen separat für grundlegende Informationen, Konfiguration, Plattform- oder Standortinformationen vornehmen, indem Sie auf die Edit-Schaltflächen innerhalb des Panels klicken, wie in der Abbildung gezeigt. Wenn Sie mit der Bearbeitung fertig sind, klicken Sie auf Done, um die App mit einem unveröffentlichten Status aufzulisten (für weitere Bearbeitungen später), oder klicken Sie auf Publish, um sofort live zu gehen.

Duplizieren

Klicken Sie auf Duplicate, um die Konfiguration der aktuellen Anwendung zu replizieren und unter einem neuen Namen zu speichern.

Löschen

Klicken Sie auf Delete, um Anwendungen zu entfernen, die Sie nicht mehr benötigen.

Veröffentlichen

Klicken Sie auf Publish, um die Anwendung direkt über den Openmix-Anwendungsmanager zu veröffentlichen. Diese Option ist nur sichtbar, wenn die App noch nicht veröffentlicht wurde.

Openmix Custom JavaScript-Anwendungen

Openmix JavaScript-Anwendungen sind Apps mit anpassbaren JavaScripts. Sie können diese über die Benutzeroberfläche im ITM-Portal erstellen, konfigurieren, testen und veröffentlichen.

Hinweis: Dieser Leitfaden behandelt nicht die eigentliche Erstellung des benutzerdefinierten Skripts (Syntax, Variablen usw.). Weitere Informationen zur Erstellung von benutzerdefiniertem JavaScript finden Sie in der Developer Exchange.

Navigation

1. Melden Sie sich beim ITM-Portal an.
2. Navigieren Sie im linken Navigationsmenü zu Openmix.
3. Wählen Sie Application Configuration aus.
4. Um eine neue Openmix-App zu konfigurieren, klicken Sie auf das Hinzufügen-Symbol oben rechts.
5. Wählen Sie Custom JS App aus.
6. Die Seite Openmix Application Configuration wird geöffnet.

Grundlegende Informationen

1. Application Name: Geben Sie Ihrer App einen Namen.
2. Description: Geben Sie hier eine Beschreibung für die App ein oder fügen Sie eine Versionshinweis hinzu. Dies ist ein optionales Feld.

3. Tags: Geben Sie bei Bedarf ein passendes Tag ein. Tags helfen, Ihre App zu identifizieren und zu organisieren. Dies ist ein optionales Feld.

4. Protocol: Wählen Sie DNS oder HTTP als Protokoll aus.
   • DNS: Wenn Sie DNS auswählen, muss ein TTL-Wert eingegeben werden.
   • HTTP: Wenn Sie HTTP auswählen, können Sie Secure Access aktivieren.
5. TTL: Geben Sie eine DNS Time to Live für die Anwendung ein. Der empfohlene Wert beträgt 20 Sekunden. Hinweis: Diese TTL gilt, wenn keine TTL von der benutzerdefinierten JS-App festgelegt wurde oder wenn die Antwort ein Fallback-Wert ist.

6. Fallback: Geben Sie einen CNAME/A/AAAA oder eine IP-Adresse für Fallback ein. Der Fallback-CNAME/A/AAAA oder die IP wird typischerweise verwendet, wenn die Anwendung Probleme oder Fehler aufweist.

7. Secure Access: Wenn Secure Access aktiviert ist, muss die HTTP-API bei Aufruf einen OAuth-Zugriffsschlüssel vom Client anfordern. Weitere Informationen finden Sie unter Sichern der Openmix HTTP API.

   Hinweis: Das Aktivieren des sicheren Zugriffs zeigt ein Schlosssymbol neben dem App-Namen in der Liste der Apps auf der Openmix-Startseite an.

Benutzerdefiniertes JavaScript

Sobald Sie die Konfigurationsinformationen eingegeben haben, können Sie Ihr benutzerdefiniertes JavaScript hochladen.

1. Klicken Sie auf die Schaltfläche Choose File und wählen Sie die JavaScript-Datei aus, die Sie hochladen möchten. Sie können jederzeit eine neue Datei hochladen, um eine vorhandene zu überschreiben.

2. Klicken Sie auf Save & Test, um Ihre Anwendung zu speichern.

   Hinweis: Die Anwendung wird beim Hochladen und Speichern automatisch mit einem Anwendungsprüfer getestet. Wenn Fehler auftreten, zeigt der Anwendungsprüfer die Fehlerinformationen und den Speicherort des Fehlers an. Weitere Informationen zu den vom Anwendungsprüfer verfügbaren Daten finden Sie im Abschnitt Anwendungsüberprüfung.

   

3. Klicken Sie auf Cancel, um zur Openmix-Anwendungsseite zurückzukehren, oder klicken Sie auf Publish, wenn Sie bereit sind, die Anwendung live zu schalten.

   Hinweis: Wenn Sie auf Publish klicken, wird Ihre App sofort live geschaltet und hat einen grünen Status. Ihre Anwendung ist in Produktion.

   Wenn Sie auf Cancel klicken, wird Ihre App auf der Anwendungsseite angezeigt, ist aber unveröffentlicht, und der Status ist rot. Weitere Informationen zum Status finden Sie im Abschnitt Status der Anwendung.

Gestaffelte Anwendungsbereitstellung

Sie können die Bereitstellung Ihrer Anwendung steuern, indem Sie einen kleinen Prozentsatz Ihres Web-Traffics über eine neue Version leiten, manchmal auch als Canary Deployment bezeichnet. ITM ermöglicht es Ihnen, einen bestimmten Prozentsatz des Traffics an die neue Version einer App zu senden, um sicherzustellen, dass die Anwendungslogik wie erwartet funktioniert. Sie können das Verhalten der vorhandenen und neuen Versionen melden, um die Änderungen an Ihrer App in einer Live-Umgebung zu bewerten. Diese Option ermöglicht es Ihnen, alle auftretenden Probleme oder Anomalien zu beheben, bevor Sie 100 % Ihres Web-Traffics über die neu bearbeitete App leiten. Nachdem Sie das gewünschte Verhalten überprüft haben, können Sie den Prozentsatz des Traffics zur neuesten Version erhöhen oder die Anwendung für alle Benutzer bereitstellen.

Um die Anwendungsbereitstellung zu staffeln und eine Testversion Ihrer neu geänderten App freizugeben, gehen Sie wie folgt vor:

• Klicken Sie auf den App-Namen (auf der Openmix-Anwendungslistenseite). Das Anwendungsmanager-Panel wird geöffnet.
• Klicken Sie auf das Edit-Symbol, um Ihre App zu bearbeiten.
• Ändern Sie Ihre vorhandene App mit allen notwendigen Änderungen.
• Wenn Sie mit den Bearbeitungen fertig sind, klicken Sie auf Save and Test.
• Scrollen Sie zum unteren Rand der Seite mit den Schaltflächen Cancel und Publish. Geben Sie den Prozentsatz des Web-Traffics (1 % bis 99 %) ein, den Sie durch diese neu geänderte Version leiten möchten.
• Aktivieren Sie das Kontrollkästchen für die teilweise Verteilung des Traffics durch diese neue Version der Anwendung. Der verbleibende Traffic wird an die vorherige Live-Version gesendet.
• Klicken Sie auf Publish. Diese neue Testversion der App wird nun in der Liste der Apps auf der Seite Openmix Configuration mit einem neuen Status-Symbol angezeigt. Das neue Status-Symbol bedeutet, dass nur ein Teil des Web-Traffics live durch diese Version fließt.

Sie können den Traffic-Fluss zur Testversion ändern und den Prozentsatz des Traffic-Flusses anpassen, um die Leistung anzuzeigen.

![Kanarienvogel](/en-us/citrix-intelligent-traffic-management/media/openmix-jsapp-edit-canary.png)

Um die Leistung Ihrer App zu überprüfen, gehen Sie zum Openmix Decision Report. Wählen Sie Application als Ihre primäre Dimension und Version als Ihre sekundäre Dimension. Klicken Sie dann auf Apply Filters, nachdem Sie Ihre Anwendung aus der Liste ausgewählt haben. Das Diagramm zeigt die Leistung verschiedener Versionen Ihrer Anwendung.

Sobald Sie mit der Leistung dieser Version der App zufrieden sind, können Sie 100 % Ihres Web-Traffics über sie leiten, indem Sie auf die Schaltfläche Go Live klicken.

Diese Version ersetzt die aktuelle Live-Version durch die neu bearbeitete Version.

Wenn Sie mit dieser Version nicht live gehen möchten, klicken Sie auf Unpublish. Ihre Änderungen werden gespeichert und erscheinen als unveröffentlichte App in der Liste der Apps auf der Seite Openmix Configuration. Nun fließen 100 % Ihres Web-Traffics durch die aktuelle Live-Version Ihrer App.

Test

Sie können Ihre JavaScript-Anwendung mit der Schaltfläche Test App vor oder nach der Veröffentlichung testen.

Es ermöglicht Ihnen, Testergebnisse über bestimmte Märkte, Länder, Regionen und Staaten hinweg anzuzeigen. Sie können die App von bestimmten IP-Adressen aus abfragen.

Testergebnisse umfassen: von der App ausgewählte Plattform, empfangene Antwort, Ursachencode, Ursachenprotokoll, Radar-Scores, Verteilung und so weiter.

Diese Funktion ermöglicht es Ihnen auch, die Verteilung von Entscheidungen über verschiedene Plattformen hinweg anzuzeigen. Wenn beispielsweise zwei Plattformen für das Routing verwendet werden, können Sie die Anzahl der Entscheidungen und die empfangene Antwort für jede von ihnen anzeigen.

Klicken Sie auf den Link Show All Details, um die Testergebnisse Ihrer App anzuzeigen.

Die folgenden Werte werden als Testergebnisse angezeigt:

Hinweis: Sie können diesen Test für die Live-App oder die unveröffentlichte Version ausführen, d.h. wenn die App noch nicht veröffentlicht ist.

Sobald Ihre App veröffentlicht ist, haben Sie die Möglichkeit, die Live-App zu testen, indem Sie die Option Test Live App anklicken. Wenn Sie Ihre App bearbeiten oder eine neue Version hochladen, können Sie diese vor der Veröffentlichung testen, indem Sie die Schaltfläche Test Unpublished App anklicken.

Anwendungsüberprüfung

Um sicherzustellen, dass benutzerdefinierte JavaScript-Apps wie erwartet funktionieren, führen Sie die App beim Hochladen in das ITM-Portal durch einen Code- und Logikprüfer. Der Anwendungsprüfer führt die App über einen Entscheidungsserver mit synthetischem Traffic aus, um zu testen, ob die Anwendung erfolgreich kompiliert und ausgeführt wird.

Wenn die Anwendung fehlerfrei läuft, liefert der Prüfer Informationen über die Entscheidungsverteilung und Ausführungsmerkmale. Wenn der Entscheidungsserver hingegen während der Ausführung der App einen Fehler feststellt, liefert der Prüfer Informationen über den Fehler. Wir empfehlen, dass die Anwendung vor der Veröffentlichung fehlerfrei sein muss.

Bei Fehlern können Sie die JavaScript-Datei lokal beheben und sie erneut in das Portal hochladen, indem Sie auf die Schaltfläche Choose File klicken.

Veröffentlichen

Um Ihre App zu veröffentlichen und live zu schalten, klicken Sie auf die Schaltfläche Publish. Diese Option ist ausgegraut, wenn die App noch nicht gespeichert oder bereits veröffentlicht wurde. Wenn die App live geht, erscheint sie auf der Openmix-Anwendungsmanager-Seite mit einem grünen Status. Weitere Informationen zum App-Status finden Sie im Abschnitt Status der Anwendung.

Hinweis: Die App wird bei Bedarf mit Fehlern veröffentlicht.

Verwalten von benutzerdefinierten JavaScript-Anwendungen

Verwenden Sie die oberen Registerkarten im Anwendungsmanager-Panel, um Berichte anzuzeigen, zu bearbeiten, zu duplizieren, zu löschen, zu veröffentlichen, die Quelle anzuzeigen, die Live-Version anzuzeigen und den Verlauf anzuzeigen.

Klicken Sie auf Ihre App in der Openmix-Anwendungslistenseite, um das Anwendungsmanager-Panel zu erweitern.

Bericht anzeigen

View Report führt Sie zur Seite Openmix Decision Reports, wo Sie den Trend der Openmix-Entscheidungen für jede Ihrer Apps, Plattformen und geografischen Gebiete anzeigen können.

Bearbeiten

Um eine benutzerdefinierte Openmix-Javascript-App zu bearbeiten, klicken Sie auf den App-Namen (auf der Openmix-Anwendungslistenseite). Das Anwendungsmanager-Panel wird geöffnet. Änderungen und Aktualisierungen können an der Konfiguration vorgenommen werden, indem Sie auf das Edit-Symbol klicken.

Quelle anzeigen

View Source ermöglicht es Ihnen, den JavaScript-Quellcode der App anzuzeigen, d.h. die neueste Version der App, unabhängig davon, ob sie veröffentlicht wurde. Diese Option ist nur für benutzerdefinierte JavaScript-Apps verfügbar.

Live-Version anzeigen

Sie können die neueste veröffentlichte Version der App anzeigen, kopieren und herunterladen. Diese Option ist nur für benutzerdefinierte JavaScript-Apps verfügbar.

Anwendungsverlauf

Application History ermöglicht es Ihnen, verschiedene Versionen der App anzuzeigen. Sie können die Liste Select a Version verwenden, um von einer Live-Version zu einer älteren Version zu wechseln. Klicken Sie auf Get Content, um zur älteren Version zu wechseln. Diese Option ist nur für benutzerdefinierte JavaScript-Apps verfügbar.

Vergleichen

Die Compare-Funktion ermöglicht es Ihnen, verschiedene Versionen Ihrer JavaScript-Datei zu vergleichen. Sie können die Unterschiede zwischen den beiden Versionen Ihrer App deutlich mit hervorgehobenen Skriptzeilen sehen.

Löschen

Um eine Openmix-App zu löschen, klicken Sie auf den App-Namen (auf der Openmix-Anwendungslistenseite). Das Anwendungsmanager-Panel wird geöffnet. Klicken Sie auf das Delete-Symbol und wählen Sie dann die Schaltfläche Delete im Bestätigungsdialogfeld. Die App verschwindet aus der Liste.

App wiederherstellen

Die Funktion Restore App ermöglicht es Ihnen, eine App nach dem Löschen wieder zu aktivieren. Um eine App wiederherzustellen, gehen Sie wie folgt vor:

1. Klicken Sie auf das Add +-Symbol oben rechts auf der Seite.

2. Wählen Sie Restore App aus dem Dropdown-Menü. Das Fenster Restore Application wird geöffnet.

   

3. Suchen Sie die App, die Sie wieder aktivieren möchten, in der Liste und klicken Sie auf die entsprechende Schaltfläche Restore.

Die App wird mit demselben Status wieder in die Liste auf der Openmix-Seite aufgenommen.

Lokale Persistenz

Die Funktion Local Persistence bietet die Möglichkeit der Entscheidungs-„Stickiness“, wenn sie für eine Openmix-Anwendung aktiviert ist. Die Anfragen werden anhand der IP-Subnetzmaske identifiziert, deren Länge konfigurierbar ist. Wenn beispielsweise ein Client eine Anfrage an dieselbe Anwendung innerhalb eines bestimmten Zeitraums wiederholt, wird die ursprüngliche Entscheidung zurückgegeben. Dies kann eine wesentliche Funktion sein, wenn ein Client während einer bestimmten Sitzung nicht zwischen verschiedenen Entscheidungen wechseln soll. Sie ist sowohl für DNS- als auch für HTTP-Openmix-Anwendungen verfügbar.

Aufgrund der zugrunde liegenden natürlichen Einschränkungen des Mechanismus ist die Persistenz nicht für 100 % der Anfragen garantiert. Stattdessen wird ein Best-Effort-Ansatz angewendet. Tests haben gezeigt, dass die erwartete Persistenzgenauigkeit im Bereich von 95-97 % liegt.

Hinweis:

Um die Funktion „Local Persistence“ für Ihr Konto zu aktivieren, öffnen Sie ein Support-Ticket oder wenden Sie sich an Ihren Customer Success Manager. Zusätzlich ist eine Predictive DNS-Zone erforderlich, die mit den Nameservern ns5.cedexis.net und ns6.cedexis.net konfiguriert ist. Berücksichtigen Sie die erhebliche Zeit, die DNS-Zonenaktualisierungen für die Verbreitung im Internet benötigen können.

Konfiguration

Um die lokale Persistenz zu aktivieren, wählen Sie unter den Openmix-Anwendungsoptionen Persistency Controls > Edit aus.

Die verfügbaren Einstellungen sind wie folgt:

1. Geben Sie im Dialogfeld „Configuration“ die Persistency TTL ein. Die Standardoption ist 300 Sekunden. Werte zwischen 60 und 1440 sind zulässig. Nach einer ersten Anfrage wird die bereitgestellte DNS-Entscheidung maximal 300 Sekunden lang beibehalten. Wenn eine weitere Anfrage aus demselben IP-Subnetzbereich im System vor Ablauf eingeht, wird dieselbe Entscheidung bereitgestellt.

2. Sowohl IPv4- als auch IPv6-Masken werden zur Einstellung der Granularität der Persistenz-„Stickiness“ bereitgestellt. Standard ist „/32“ und „/64“ für IPv4 bzw. IPv6. Zulässige Werte sind:

   • /8 bis /32 für IPv4
   • /32 bis /64 für IPv6

   Diese Maskierung der IP-Adresse des Clients bestimmt den im internen Datenspeicher verwendeten Persistenzschlüssel. Wenn beispielsweise zwei (oder mehr) Client-IPs derselben maskierten IP-Adresse zugeordnet werden, erhalten sie dieselbe persistente Entscheidung.

Dieselben Einstellungen sind auch unter den Einstellungen für prädiktive Anwendungen verfügbar.

Die Openmix-Entscheidungen, die über den internen Datenspeicher bereitgestellt werden, werden im Entscheidungsbericht mit dem Ursachencode Persistent app gemeldet.

Gesundheitsprüfungen

Entscheidungen, die aus dem Persistenz-Cache bereitgestellt werden, unterliegen zusätzlichen Gesundheitsprüfungen, bevor sie bereitgestellt werden:

1. Wenn die Anwendung mit Sonar Availability Check konfiguriert ist, wird die Sonar-Verfügbarkeitsprüfung durchgeführt, bevor eine zwischengespeicherte Entscheidung bereitgestellt wird. Wenn Sonar meldet, dass die Plattform “down” ist, wird die zwischengespeicherte Entscheidung ignoriert und die OpenMix-Anwendung erneut ausgeführt.

2. Wenn die Anwendung mit Radar Availability Check konfiguriert ist, wird die Radar-Verfügbarkeitsprüfung durchgeführt, bevor eine zwischengespeicherte Entscheidung bereitgestellt wird. Wenn die Verfügbarkeit der Plattform unter dem konfigurierten Schwellenwert liegt, wird die zwischengespeicherte Entscheidung ignoriert.

Hinweis:

Für die Persistenz ist der maximale Schwellenwert für die Radar-Verfügbarkeitsprüfung auf feste 10 % festgelegt.

Sichern der Openmix HTTP API

Openmix ist über DNS oder eine HTTP-API für die Integration in Nicht-DNS-Workflows verfügbar. Standardmäßig wird die HTTP-API über unverschlüsseltes HTTP aufgerufen. Die API kann auch über TLS und Schlüsselauthentifizierung gesichert werden. Dies geschieht über die Benutzeroberfläche, indem das Kontrollkästchen Require Secure API Access (HTTPS) aktiviert wird.

Erstellen von API-Schlüsseln

Um die Schlüsselauthentifizierung zu aktivieren, gehen Sie wie folgt vor.

1. Wählen Sie das Kontrollkästchen Require Secure API Access (HTTPS) auf der Seite Openmix Application Configuration aus, um den sicheren Zugriff für jede Anwendung zu aktivieren.

2. Um einen sicheren Zugriffsschlüssel zu generieren, navigieren Sie zu My Account -> API -> Openmix HTTP API Keys.

   

3. Wenn Sie ein Erstbenutzer sind, werden Sie aufgefordert, mit der Eingabe Ihrer Client-ID zu beginnen. Geben Sie Ihre Client ID in das Dialogfeld New Client ein und klicken Sie auf Complete.

4. Der Client Secret-Schlüssel wird neben der Client ID auf der Seite Openmix HTTP API Authentication Configuration angezeigt.

5. Sie können nun eine Anfrage an die Openmix-App unter Verwendung der Basisauthentifizierung stellen. Verwenden Sie Ihre Client ID als Benutzernamen und das Client Secret als Passwort, um die App im Browser aufzurufen.

   Um die App über die Befehlszeile aufzurufen, verwenden Sie den folgenden cURL-Befehl:

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

Hinweis: Die von Ihnen erstellten Schlüssel gewähren Ihnen Zugriff auf alle Ihre Openmix-Anwendungen.

Weitere Informationen zum Aufrufen der Openmix HTTP API finden Sie in der Openmix HTTP API-Nutzungsdokumentation.

Löschen von API-Schlüsseln

1. Um einen Schlüssel zu löschen, navigieren Sie zur Seite Openmix HTTP API Authentication Configuration.
2. Klicken Sie auf die Client ID.
3. Wählen Sie Delete in der Liste aus. Der Schlüssel wird aus dem System entfernt. Er ist nicht mehr gültig für die Authentifizierung oder den sicheren Zugriff auf die Openmix-Anwendung.

Zugreifen auf Protokolle

Entscheidungsprotokolle, die von Openmix erstellt wurden, können gesammelt und zum sicheren Download bereitgestellt werden. Diese Protokolle können Ihnen helfen, die von Ihrer Openmix-Anwendung getroffenen Entscheidungen zu analysieren und das Anforderungsverhalten zu debuggen. Die Protokolle können auf Kontoebene ein- und ausgeschaltet sowie gesichert werden. Details zum Aktivieren und Herunterladen von Openmix-Protokollen sowie zu den Protokollbeschreibungen finden Sie unter Netscope.

Openmix-Berichte

Openmix-Berichte bieten eine leistungsstarke Transparenz über die Openmix-Entscheidungen, die für Ihren DNS- oder HTTP-Traffic getroffen wurden. Jeder Bericht wird im folgenden Abschnitt definiert, aber hier sind einige wichtige Aspekte zu den Berichten:

Primäre und sekundäre Dimensionen

Die primäre Dimension des Diagramms wird über eine Liste oberhalb des Diagramms ausgewählt. Verwenden Sie diese Liste als leistungsstarken Pivot für den Bericht. Eine sekundäre Dimension kann ebenfalls ausgewählt werden, um die Berichterstattung weiter zu verfeinern.

Umschalter für Visualisierungshintergrund

Diagramme sind standardmäßig auf einen weißen Hintergrund eingestellt. Schalten Sie den Hintergrund auf eine dunkle Farbe um, um Monitore mit hohem Kontrast über den Hintergrund-Umschalter zu verwenden.

Datenexport

Zusätzlich kann der Endbenutzer die Diagramm- und Tabellendaten über den Download-Link oben im Bericht herunterladen.

Filter: Berichtszeitraum

Sie können einen Bericht mit einem Zeitbereich der letzten 60 Minuten, 24 Stunden, 48 Stunden, 7 Tage, 30 Tage oder einem benutzerdefinierten Bereich generieren. Die Standardansicht ist die letzten 24 Stunden.

Filter: Leistungsstarke Drilldown-Funktionen

Die Berichte variieren leicht in Bezug auf die geeigneten Filter, basierend auf den Daten. Die folgenden sind die häufigsten:

• Statistic – Wählen Sie den im Diagramm angezeigten Wert aus, meist die Anzahl der Entscheidungen.
• Traffic Source – Wählen Sie den anzuzeigenden Traffic-Typ aus: DNS oder HTTP.
• Application – Wählen Sie eine oder mehrere Openmix-Anwendungen zur Anzeige aus.
• Platform – Wählen Sie eine oder mehrere Plattformen (Anbieter) zur Aufnahme aus.
• Continent – Wählen Sie einen oder mehrere Kontinente zur Aufnahme aus.
• Country – Wählen Sie ein oder mehrere Länder zur Aufnahme aus.
• Region – Wählen Sie eine oder mehrere geografische Regionen (falls zutreffend) zur Aufnahme aus.
• State – Wählen Sie einen oder mehrere geografische Staaten (falls zutreffend) zur Aufnahme aus.
• Network – Wählen Sie ein oder mehrere Netzwerke (ASN) zur Aufnahme aus.

Nutzenbericht

Der Nutzenbericht zeigt Ihnen die Gesamtverbesserung der Leistung Ihrer Anwendungsbereitstellung, wenn Sie den NetScaler Intelligent Traffic Management (ITM)-Dienst verwenden. Der Nutzen wird als prozentuale Verbesserung der Antwortzeit und des Durchsatzes dargestellt. Wählen Sie eine bestimmte Plattform aus dem Pool der Kandidatenplattformen aus, um den Bericht zu generieren.

Primäre Dimensionen für den Nutzenbericht

Primäre Dimensionen sind unabhängige Messgrößen, auf deren Grundlage der Nutzenbericht angezeigt wird. Die folgenden Abschnitte beschreiben jede dieser primären Dimensionen im Detail.

Zusammenfassung

Summary ist die standardmäßige primäre Dimension. Das Übersichtsdiagramm zeigt den Durchschnitt des gesamten prozentualen Nutzens (in Bezug auf Antwortzeit oder Durchsatz), der von allen Anwendungen erzielt wurde.

Hinweis: Sie können zwischen dem Nutzen, der in Bezug auf die Antwortzeit oder den Durchsatz angezeigt wird, wechseln, indem Sie den Filter Statistic verwenden.

Anwendung

Wenn Application als primäre Dimension ausgewählt wird, zeigt das Diagramm jede der Anwendungen und die entsprechende Leistung (in Bezug auf Antwortzeit oder Durchsatz) als prozentualen Nutzen bei der Auswahl einer bestimmten Plattform gegenüber anderen Kandidatenplattformen an.

Hinweis: 0 % bedeutet, dass es keinen zusätzlichen Nutzen oder keine Verbesserung bei der Auswahl einer bestimmten Plattform gegenüber einer anderen gab.

Standort (Kontinent, Land, Region, Bundesland)

Wenn der Standort (Continent, Country, Region oder State) als primäre Dimension ausgewählt wird, zeigt der Nutzenbericht den Durchschnitt der gesamten prozentualen Leistungsverbesserung (in Bezug auf Antwortzeit oder Durchsatz) für jeden Standort an. Sie können den Standort nach Kontinent, Land, Region oder Bundesland auswählen.

Hinweis: Plattformen, die aufgrund von Geo-Regeln oder aus anderen Gründen nicht für die Auswahl in Frage kommen, werden bei der Berechnung nicht berücksichtigt. Plattformen, die für den betreffenden Standort geofenced sind, werden jedoch gezählt.

Netzwerk

Wenn Sie Network als primäre Dimension auswählen, sehen Sie die prozentuale Leistungsverbesserung für Benutzer, die in die spezifischen Netzwerke (oder Dienstanbieter) gruppiert sind, von denen aus Benutzer auf ITM zugreifen. Dies hilft Ihnen zu erkennen, welche Benutzergruppen den Leistungsvorteil sehen, wenn sie von diesen spezifischen Netzwerken kommen.

Plattform

Wenn Sie Platform als primäre Dimension auswählen, sehen Sie einzelne Plattformen, die von verschiedenen Apps ausgewählt wurden, und die entsprechende verbesserte Leistung, wenn sie ausgewählt werden. Die verbesserte Leistung oder der Nutzen wird in Bezug auf Antwortzeit oder Durchsatz (in Prozent) angegeben.

Hinweis: Die prozentuale Leistungsverbesserung wird angezeigt, wenn eine App diese Plattform auswählt. Die Liste im Diagramm gibt nicht unbedingt eine Leistungsrangfolge zwischen diesen Plattformen an.

Ursachencode

Wenn Sie Reason Code als primäre Dimension auswählen, ist der im Diagramm angezeigte Prozentsatz der durchschnittliche Gesamtnutzen, wenn Entscheidungen für einen bestimmten Ursachencode getroffen werden.

Plattformen im Nutzenbericht ignorieren

Um die Genauigkeit der Openmix-Entscheidungen für Ihren Nutzenbericht zu verbessern, können Sie bestimmte Plattformen ignorieren und die App so einstellen, dass sie nur aus Plattformen auswählt, die am besten für den Vergleich geeignet sind.

Ihre Anwendung hat beispielsweise fünf Plattformen, die für den Vergleich in Betracht gezogen werden sollen – drei in Europa für den europäischen Traffic und zwei in den USA für den US-Traffic. Geo-Regeln legen fest, dass der europäische Traffic über die europäischen Plattformen und der US-Traffic über die US-Plattformen geleitet werden muss.

Um sicherzustellen, dass die Berechnung mit den drei europäischen Plattformen erfolgt, können Sie die App so einstellen, dass die anderen beiden nicht-europäischen Plattformen ignoriert werden. Verwenden Sie die Methode ignoredProvider() in Ihrem JavaScript.

Die Methode nimmt den Alias des Anbieters (z. B. provider-1, provider-2) als Eingabeargument entgegen (ähnlich wie die Methode requireProvider()). Die API muss einmal pro Alias aufgerufen werden.

Verwenden Sie diesen Beispielcode in Ihrer JavaScript-Datei innerhalb der onRequest-Funktion:

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');
}
<!--NeedCopy-->

Geo-Standortbericht für Entscheidungen

Dieser Bericht zeigt das Volumen der Openmix-Entscheidungen für jedes Land. Diese Kartenansicht kann im Zeitverlauf (basierend auf dem für den Bericht gewählten Zeitraum) durch Auswahl der Schaltfläche Play am unteren Rand des Diagramms angezeigt werden.

Entscheidungsbericht

Dieser Bericht zeigt den Trend der Openmix-Entscheidungen für jede der Anwendungen, Plattformen und geografischen Gebiete.