ADC-Leistungskennzahlen verstehen

Einführung

Application-Delivery-Services sind für den Erfolg von Anwendungen von entscheidender Bedeutung. Unabhängig davon, ob solche Dienste Skalierbarkeit, Zuverlässigkeit oder Sicherheit bieten, sind die meisten Anwendungen auf einen oder mehrere davon angewiesen. Application Delivery Controller (ADCs) nehmen daher in den meisten Anwendungs-, Cloud- und Rechenzentrumsarchitekturen eine zentrale Rolle ein.

Für viele Umgebungen, einschließlich Private-Cloud-Installationen, ist dedizierte ADC-Hardware nach wie vor die bevorzugte Plattform für die Bereitstellung von Application-Delivery-Services. Der Grund dafür ist, dass eine dedizierte Plattform kontrollierte, stabile und konsistente Ressourcen bietet. Eine dedizierte, speziell entwickelte Appliance kann durchgängig die Leistung und Zuverlässigkeit bereitstellen, die selbst anspruchsvollste Anwendungs-Workloads erfordern, da es keine Abweichungen beim Hypervisor, bei der Software oder der zugrunde liegenden Computing-Plattform gibt. Hinzu kommen die Vorteile spezialisierter Hardwarekomponenten, die Aufgaben von der CPU auslagern.

Doch was bedeutet „Leistung“ eigentlich? Im Allgemeinen veröffentlichen ADC-Anbieter vier Hauptarten von Kennzahlen, um die Leistung zu veranschaulichen:

• Anfragen pro Sekunde (RPS)
• Verbindungen pro Sekunde (CPS)
• Transaktionen pro Sekunde (TPS)
• Durchsatz (häufig gemessen in Gigabit pro Sekunde, Gbit/s)

Hersteller stellen umfassende Datenblätter bereit, in denen diese und weitere Plattformmerkmale aufgeführt sind, darunter Tabellen zum Durchsatz, zur Anzahl der SSL-Transaktionen oder zu gleichzeitigen Verbindungen. Um die richtige Plattform auszuwählen, ist es unerlässlich, diese Zahlen und ihre Relevanz für die Auslastung einer Anwendung richtig zu interpretieren sowie die wahrscheinlichen Grenzen und Engpässe eines Systems zu verstehen. Wenn Sie lernen, die Datenblätter der Anbieter richtig zu interpretieren und die für Ihre Anwendungen relevanten Kennzahlen zu verstehen, können Sie die passenden Plattformen für Ihr Unternehmen erfolgreicher auswählen.

Was macht ein ADC?

Ein Application Delivery Controller ist eine Infrastrukturkomponente, die als Anwendungs-Proxy fungiert und Dienste für die Anwendungsbereitstellung wie Datenverkehrsmanagement, Lastverteilung, SSL-Entschlüsselung, Sicherheit auf Anwendungsebene und Zugriffskontrolle für Anwendungen bereitstellt. Clientgeräte und Dienste stellen eine Verbindung zum ADC her, woraufhin der ADC eine separate Verbindung zur Anwendung aufbaut (oder eine bestehende wiederverwendet). In diese logische Lücke fügt der ADC Dienste für die Anwendungsbereitstellung ein.

Um die Arbeitslast eines ADC zu verstehen, ist es hilfreich, eine TCP-Verbindung und eine Anfrage auf Anwendungsebene zu betrachten. Der ADC muss Aufgaben auf mehreren Ebenen des TCP-Stacks ausführen und eine Reihe von Aktivitäten durchführen, um Anwendungsdienste für den Anwendungsdatenverkehr bereitzustellen. (Siehe Abbildung 1.) Dies kann die Interpretation der Leistungskennzahlen von ADC-Anbietern erschweren. Eine wesentliche Voraussetzung für das Verständnis, welche Kennzahlen relevant sind, ist die Bestimmung des Arbeitslasttyps.

Abbildung 1: Paketverarbeitung

Es gibt viele verschiedene Arten von Anwendungen und daher auch viele unterschiedliche ADC-Workloads. Die meisten Produktivumgebungen umfassen zwar eine Mischung verschiedener Workloads, doch die Auswirkungen und Anforderungen der einzelnen Workloads bestimmen, welche Komponenten eines ADC am stärksten beansprucht werden. Selbst innerhalb der Komponenten unterscheiden sich die Anforderungen je nach Workload. Einige Workloads reagieren möglicherweise empfindlicher auf Latenz, andere auf Jitter; manche Workloads sind anfällig für Durchsatzbegrenzungen, während andere stärker von der Verfügbarkeit abhängig sind.

Im Folgenden finden Sie die gängigsten Workloads sowie die wichtigsten Kennzahlen, die sie unterstützen:

• Die derzeit häufigste Workload, die von Websites und vielen mobilen Anwendungen genutzt wird, sind transaktionsbasierte HTTP-Webanwendungen, die häufig SSL und TLS verwenden. Die wichtigsten Kennzahlen für diese Workload sind sämtliche SSL-Kennzahlen: RPS, TPS und Durchsatz sowie RPS und CPS auf Schicht 7.
• DNS ist eine weitere häufige Arbeitslast, die bei fast allen Internetverbindungen zum Einsatz kommt. DNS wird häufig genutzt, wobei das Datenverkehrsvolumen gering ist und üblicherweise UDP anstelle von TCP verwendet wird. Daher sind der Durchsatz auf Layer 3 und Layer 4 die wichtigsten Kennzahlen.
• Die Nutzung der REST-API nimmt rasant zu. Sie stellt einen gängigen API-Übertragungsmechanismus für Dienste dar und wird daher häufig für die Maschine-zu-Maschine-Kommunikation eingesetzt. Da die REST-API auf HTTP basiert, sind dieselben Kennzahlen wie bei HTTP relevant (sämtliche SSL-Kennzahlen): RPS, TPS und Durchsatz sowie RPS und CPS auf Schicht 7.
• MQTT ist ein aufstrebendes Nachrichtenprotokoll mit vielfältigen Einsatzmöglichkeiten, das in der Kommunikation im Internet der Dinge (IoT) zunehmend Verbreitung findet. Wie die REST API kommt MQTT hauptsächlich in Machine-to-Machine-Anwendungen zum Einsatz. Die wichtigsten Kennzahlen für MQTT sind Layer-4-CPS und Durchsatz.
• Diameter ist ein Ersatz für das RADIUS-Authentifizierungsprotokoll, arbeitet auf Schicht 4 und hält TCP-Verbindungen über lange Zeiträume offen. Die wichtigsten Kennzahlen sind die CPS auf Schicht 4 und die Robustheit der Verbindungstabelle auf Schicht 4.
• Finanzhandelsprotokolle wie FIX, SAIL und OUCH reagieren sowohl auf Schicht 4 als auch auf Schicht 7 empfindlich auf Latenzen. Daher sind ihre wichtigsten Kennzahlen CPS auf Schicht 4 sowie RPS und CPS auf Schicht 7.
• Die WebSocket-Technologie ist eine relativ neue Ergänzung der Workload-Typen. Dabei kann der Server über eine langlebige Layer-4- und Layer-7-Verbindung die Kommunikation mit dem Client initiieren. Wichtige Kennzahlen sind Layer-4-CPS, Layer-7-RPS und -CPS sowie die Robustheit der Layer-4- und Layer-7-Verbindungstabellen.
• Protokollierungs- und Alarmierungs-Workloads werden alle auf Schicht 4 ausgeführt, einige basieren auf der REST-API, die auf Schicht 7 arbeitet. Daher ist CPS auf Schicht 4 eine wichtige Kennzahl und bei den auf der REST-API basierenden Workloads zusätzlich RPS und CPS auf Schicht 7.

Die Zusammensetzung der Workloads entwickelt sich kontinuierlich weiter, und es kommen ständig neue Workloads hinzu, die jeweils eigene kritische ADC-Metriken aufweisen, die sich nach den primären Vorgängen des jeweiligen Workloads richten.

Leistungskennzahlen und ihre Interpretation

Der Durchsatz eines Netzwerkgeräts hängt von der Latenz ab – der Verzögerung, die durch die Verarbeitung des Netzwerkverkehrs entsteht. Schon allein die Lichtgeschwindigkeit bedingt eine Mindestlatenz für elektrische Signale, die über Kupferleitungen übertragen werden, beziehungsweise für optische Signale, die Glasfaserkabel durchlaufen. Ein ADC überträgt die Daten jedoch nicht nur über Leitungen oder Glasfaserkabel, sondern führt auch mehrere Verarbeitungsschritte am Netzwerkverkehr durch. Die maximale Leistungsfähigkeit eines ADC ergibt sich aus der Summe der Latenzen serieller, also nicht parallel ausgeführter Vorgänge. Glücklicherweise werden viele Vorgänge parallel ausgeführt, doch die dafür benötigte Zeit begrenzt weiterhin den Gesamtdurchsatz. Ein Ziel bei der Entwicklung von ADCs besteht darin, diese Latenzen zu minimieren und so den Durchsatz zu maximieren.

Die Leistung eines bestimmten ADC zu bewerten und ihn auf eine bestimmte Bereitstellungsumgebung abzustimmen, kann eine anspruchsvolle Aufgabe sein. Netzwerkanbieter veröffentlichen Kennzahlen, die auf Tests basieren, bei denen eine bestimmte Kennzahl auf Kosten anderer maximiert werden soll. Dieser Ansatz dient dazu, einen brauchbaren Wert zu veröffentlichen, der als Orientierung für Architektur und Entscheidungen dienen kann. Den Anbietern ist jedoch bewusst, dass nicht alle veröffentlichten Werte gleichzeitig erreicht werden können. Ein Vergleich aus der Automobilwelt: Toyota bewirbt das Basismodell des Camry von 2017 mit einer Leistung von 178 PS und einem Verbrauch von 33 Meilen pro Gallone auf der Autobahn. Es wäre jedoch unrealistisch, zu erwarten, dass das Fahrzeug die vollen 178 PS erbringt – bei 6.000 U/min und vollständig durchgetretenem Gaspedal – und gleichzeitig 33 Meilen pro Gallone erreicht. Ähnlich stellen Netzwerkanbieter einzelne Leistungskennzahlen jeweils anhand eines Best-Case-Szenarios dar. In der Regel lassen sich viele der veröffentlichten Leistungskennzahlen nicht gleichzeitig reproduzieren.

Zusammenhänge zwischen Metriken und OSI-Schichten

Einige der veröffentlichten Kennzahlen können auf unterschiedliche Verarbeitungsebenen angewendet werden. Beispielsweise können Anfragen pro Sekunde Werte für die Verarbeitung auf OSI-Schicht 2 (L2) oder OSI-Schicht 7 (L7) darstellen. TPS hingegen bezieht sich häufig nur auf die SSL-Schlüsselaushandlung, während Anfragen pro Sekunde auf Schicht 7 nachfolgende kryptografische Anfragen über eine bereits aufgebaute SSL-Sitzung bezeichnen. Eine bestimmte Arbeitslast beansprucht die verschiedenen Verarbeitungskomponenten eines ADC anders als eine andere Arbeitslast. Eine weitere wichtige Erkenntnis zu veröffentlichten ADC-Kennzahlen ist, dass unterschiedliche Arbeitslasten an unterschiedliche Leistungsgrenzen stoßen.

Für jede OSI-Netzwerkschicht werden üblicherweise mehrere schichtspezifische Kennzahlen veröffentlicht. So werden Kennzahlen für Schicht 4 häufig in Verbindungen pro Sekunde angegeben; daneben gibt es weitere Kennzahlen für den Durchsatz auf Schicht 4. Die OSI-Schichten 5 und 6 lassen sich nicht ohne Weiteres dem IP-Stack zuordnen, doch Dienste wie SSL/TLS und Komprimierung können als Schichten 5 und 6 betrachtet werden. Wie bereits erwähnt, werden Tests für diese Kennzahlen häufig mit Datenverkehr durchgeführt, der gezielt auf die maximale Auslastung der jeweiligen Kennzahl ausgelegt ist und keine realen Verkehrslasten abbildet. Der maximale SSL-TPS-Wert ergibt sich beispielsweise bei einem Test mit einer SSL-Nutzlast der Länge null, sodass keine ADC-Verarbeitungszeit für die Entschlüsselung von SSL-Daten aufgewendet wird. Dies ist zwar sinnvoll, wenn ausschließlich die Leistung der SSL-Hardware ermittelt werden soll, doch keine Produktivanwendung sendet Nutzlasten der Länge null. Ebenso wird der Durchsatz auf Schicht 2 ohne aktiviertes SSL und ohne Verarbeitung auf Schicht 7 getestet, da diese Funktionen den ADC verlangsamen, obwohl sie in vielen Produktivumgebungen eingesetzt werden. Die meisten ADC-Kennzahlen werden isoliert getestet, während in den meisten Produktivumgebungen eine Kombination von ADC-Funktionen zum Einsatz kommt, wobei jede Kennzahl unterschiedliche Komponenten oder Kombinationen von Komponenten beansprucht. Zu den beteiligten Komponenten können unter anderem die CPU, die Netzwerkschnittstellenkarte (NIC), anwendungsspezifische integrierte Schaltungen (ASICs) und feldprogrammierbare Gate-Arrays (FPGAs) gehören. Verfügt ein ADC nicht über eine bestimmte Komponente, übernimmt stattdessen die CPU deren Aufgabe.

Die Paketmetrik gibt an, wie viele Pakete pro Sekunde der ADC verarbeiten kann. Welche Komponenten durch diese Verarbeitung am stärksten beansprucht werden, hängt von der jeweiligen Schicht ab. So wird bei der Verarbeitung von Paketen der Schicht 2 hauptsächlich die Netzwerkschnittstellenkarte (NIC) beansprucht, während bei der Verarbeitung von Paketen der Schicht 4 vor allem das FPGA belastet wird. Die Durchsatzmetrik bezieht sich auf allen Schichten auf den insgesamt verfügbaren Durchsatz in Gigabit pro Sekunde, während die Verbindungsmetrik angibt, wie viele Verbindungen pro Sekunde auf der jeweiligen Schicht hergestellt werden können. Die Verbindungsmetrik für Schicht 4 gibt beispielsweise an, wie viele TCP-Verbindungen pro Sekunde aufgebaut werden können.

SSL-Verarbeitungsmetriken

Die SSL-Verarbeitung zeichnet sich dadurch aus, dass Sitzungen verbindungsübergreifend aufgebaut und verwaltet werden. Eine Verbindung kann eine SSL-Sitzung aufbauen (dies wird als Transaktion bezeichnet), während nachfolgende Verbindungen eine SSL-Sitzung wiederverwenden können (dies wird als Anfrage bezeichnet). Daher werden die Kennzahlen für Transaktionen und Anfragen getrennt aufgeführt. SSL-Transaktionen dauern bei Weitem länger als nachfolgende SSL-Anfragen, sodass bei der Durchsatzleistung häufig die Transaktionskennzahl den begrenzenden Faktor darstellt. Sobald eine SSL-Sitzung aufgebaut ist und eine nachfolgende Anfrage erfolgt, müssen die Nutzdaten ver- oder entschlüsselt werden. Der Krypto-ASIC übernimmt die Ver- und Entschlüsselung; die Leistung wird anhand der Durchsatzkennzahl gemessen.

Häufig ist es sinnvoll, die Nutzdaten zu komprimieren. Die Komprimierung erfolgt durch den Komprimierungs-ASIC und wird ebenfalls anhand des Durchsatzes gemessen.

Verarbeitung auf Anwendungsebene

Schließlich nimmt Schicht 7 eine Sonderstellung ein, da angesichts der verfügbaren komplexen und vielfältigen Optionen zur Datenverkehrssteuerung die gesamte Verarbeitung auf Schicht 7 durch die CPU erfolgt. Cookie-Persistenz ist eine gängige Funktion von Schicht 7, die jede Benutzersitzung an einen bestimmten Server im Pool bindet und von der CPU ausgeführt wird. Die Kennzahl „Anfragen auf Schicht 7“ gibt die Anzahl der Anfragen auf Schicht 7 pro Sekunde an, die der ADC verarbeiten kann. Entsprechend bezeichnet die Kennzahl „Durchsatz auf Schicht 7“ den auf Schicht 7 insgesamt möglichen Durchsatz.

Schließlich muss der ADC für jede Schicht, die den Verbindungsstatus aufrechterhalten muss, eine Verbindungstabelle führen. Verbindungstabellen sind bei TCP-Verbindungen auf Schicht 4, SSL-Sitzungen und HTTP-Sitzungen auf Schicht 7 üblich. Protokolle mit langlebigen Verbindungen können die Verbindungstabelle eines ADC überlasten oder vollständig ausschöpfen.

Jede Metrik kann dabei helfen, einen bestimmten Leistungsaspekt zu ermitteln. Das Verständnis der verschiedenen Vorgänge, die auf den einzelnen Schichten ausgeführt werden, sowie der Komponenten, die von diesen Vorgängen betroffen sind, erleichtert die Bewertung der ADC-Leistungsmetriken für eine bestimmte Bereitstellung.

Spezialisierte Hardware und Leistung

Jeder Aspekt der ADC-Funktionalität kann von einer CPU bereitgestellt werden. Tatsächlich bieten viele Hersteller von ADC-Hardware auch eine reine Softwareversion an. Dies ist möglich, weil eine CPU der flexibelste verfügbare Hardwaretyp ist und nahezu jede datenbezogene Aufgabe ausführen kann.

Allerdings stößt die Übertragung sämtlicher Aspekte der ADC-Funktionalität auf eine CPU an ihre Grenzen. Von den drei wichtigsten Hardwaretypen zur Verarbeitung von Netzwerkverkehr – CPU, ASIC und FPGA – ist die CPU am langsamsten und wohl auch am teuersten, da sie auf Arbeitsspeicher und Speichercontroller angewiesen ist. Die beiden anderen Hardwaretypen zur Verarbeitung von Netzwerkverkehr sind ASIC und FPGA. Ein ASIC ist, wie der Name schon sagt, für die Ausführung einer bestimmten Aufgabe konzipiert. Kein anderer Hardwaretyp kann eine Aufgabe schneller ausführen als ein ASIC, doch seine Fähigkeiten sind auf die im Chip implementierten Funktionen beschränkt. Benötigt eine Anwendung Funktionen, die der ASIC nicht bietet, muss sie stattdessen eine CPU verwenden und die Aufgaben softwareseitig ausführen.

Wenn eine CPU flexibel und langsam und ein ASIC unflexibel und schnell ist, liegt eine dritte Technologie dazwischen: das FPGA. Ein FPGA ist langsamer als ein ASIC, aber wesentlich schneller als eine CPU. Zudem lässt es sich so programmieren, dass es Aufgaben ausführt, die von den FPGA-Entwicklern ursprünglich nicht vorgesehen waren.

Abbildung 2: Vorteile von CPU, ASIC und FPGA

Ein gut konzipierter ADC nutzt die Fähigkeiten jedes Hardwaretyps optimal aus: Häufig anfallende und einfache Aufgaben werden von ASIC-Komponenten übernommen, komplexere Aufgaben von FPGA-Komponenten und die komplexesten und am seltensten anfallenden Aufgaben von der CPU. Ein Großteil der technischen Raffinesse eines ADC beruht darauf, die verschiedenen Komponententypen so aufeinander abzustimmen, dass sie die unterschiedlichen Arbeitslasten möglichst effizient bewältigen.

Die mit Abstand häufigste Aufgabe eines ADC ist die Paketverarbeitung an den Netzwerkschnittstellen. Eine handelsübliche Standard-NIC ist entweder für ein hohes Volumen an eingehendem Datenverkehr (beispielsweise bei einem Desktop-PC oder einem anderen Endgerät) oder für ein hohes Volumen an ausgehendem Datenverkehr (beispielsweise bei einem Server) optimiert. Ein ADC stellt insofern eine Besonderheit dar, als er eine NIC benötigt, die in beiden Richtungen auf maximalen Durchsatz ausgelegt ist. Keine handelsübliche NIC wurde für maximalen Durchsatz in beiden Richtungen konzipiert. Da die Paketverarbeitung in einem ADC häufig anfällt und eine vergleichsweise einfache Aufgabe ist, eignet sich ein ASIC besonders gut dafür. In geclusterten ADC-Umgebungen fungiert ein Disaggregator-ASIC (DAG) als vorgeschalteter Load Balancer und stellt sicher, dass dieselben Client- und Serversitzungen stets über denselben Clusterknoten laufen. Der Einsatz eines DAG in einer Clusterumgebung erleichtert die horizontale Skalierung von ADC-Appliances, um das jeweilige Datenverkehrsaufkommen zu bewältigen. Bei einem sachgerecht konzipierten ADC können die gesamte Paketverarbeitung und das Switching auf Schicht 2 von spezialisierter ASIC-Hardware übernommen werden.

Verarbeitungsaufgaben auf den Schichten 3 und 4 sind komplexer und daher gut für ein FPGA geeignet. Ein FPGA kann Routing-Funktionen sowie Schutzmechanismen durch Firewalls und gegen verteilte Denial-of-Service-Angriffe (DDoS) bereitstellen, einschließlich TCP-SYN-Cookies. Der Einsatz eines FPGA auf dieser Ebene ermöglicht die Verarbeitung und Absicherung auf Schicht 4 und stellt sicher, dass der für die weitere Verarbeitung vorgesehene Datenverkehr ordnungsgemäß zusammengesetzt und gefiltert wurde.

Die Verarbeitung von Verschlüsselung und Komprimierung, etwa mit SSL oder TLS, sowie der durch HTTP/2 eingeführten neuen Funktionen ist ein weiterer Einsatzbereich für dedizierte Hardware. Für die kryptografische Verarbeitung wird häufig ein spezialisierter ASIC eingesetzt, unter anderem für die rechenintensive SSL-Schlüsselaushandlung moderner Verschlüsselungsverfahren wie Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). Nach erfolgter SSL-Schlüsselaushandlung kann die ASIC-Hardware auch die Ver- und Entschlüsselung großer Datenmengen bei nachfolgenden Anfragen übernehmen. Ebenso kann ASIC-Hardware Daten mithilfe gängiger Algorithmen komprimieren und dekomprimieren. Der Einsatz dedizierter ASIC-Komponenten ermöglicht eine schnelle Verarbeitung von Verschlüsselungs- und Komprimierungsvorgängen.

Die verbleibende Verarbeitung des Netzwerkverkehrs, die nicht von ASICs und FPGAs übernommen wird, muss durch die CPU erfolgen. Obwohl sie im Vergleich zu ASICs und FPGAs langsamer ist, stellt die CPU die flexibelste Komponente im ADC dar. Darüber hinaus übernimmt sie Aufgaben, die nicht mit der Netzwerkverarbeitung zusammenhängen, etwa die grafische Benutzeroberfläche und andere Konfigurationsaufgaben, die Verarbeitung von E/A-Interrupts oder sogar von Festplattenanfragen. Da die Auslastung der CPU schwanken und sich auf die Latenz auswirken kann und die CPU die letzte Hardwarekomponente in der Verarbeitungskette des Netzwerkverkehrs ist, sind ADCs bewusst so konzipiert, dass möglichst wenig Netzwerkverkehr von der CPU verarbeitet werden muss. Stattdessen wird so viel wie möglich von den schnelleren ASICs und FPGAs übernommen.

Fazit

Es kann schwierig sein, die von Anbietern veröffentlichten Kennzahlen auf die tatsächliche Leistung in der Praxis zu übertragen. Das Zusammenspiel zwischen den verschiedenen Arten von Workloads, den von ihnen beanspruchten Ressourcen und den Fähigkeiten einer Hardwareplattform zu verstehen, ist zwar komplex, kann Ihnen jedoch dabei helfen, die beste Kaufentscheidung für Ihr Unternehmen zu treffen.

Veröffentlichte Datenblätter und andere Ressourcen erleichtern die Auswahl der richtigen Plattform. Wann immer möglich, sollte jedoch auch direkt auf die Erfahrung und das Fachwissen des Anbieters zurückgegriffen werden. Führende Anbieter verfügen über umfassende Expertise bei der Zuordnung von Workloads zu Plattformen – und diese Expertise sollte den Kunden ohne Weiteres zur Verfügung stehen.

Wenn Sie ein gutes Verständnis der Datenverkehrsmerkmale Ihrer Anwendungen und der Plattformfunktionen mit dem Fachwissen Ihres Anbieters kombinieren, verringern Sie das Risiko und die potenziellen Kosten einer Unter- oder Überdimensionierung Ihrer Plattform.

VERÖFFENTLICHT AM 28. MÄRZ 2017