Wenn man über Content Delivery Networks (CDNs) nachdenkt, ist es einfach, direkt zu den großen Marken zu gehen, die wir kennen, wie Netflix, Hulu usw. Das macht Sinn; Es ist intuitiv, daran zu denken, dass die neueste Folge Ihrer Lieblingssendung auf Ihr Telefon oder den Fernseher im Wohnzimmer übertragen wird. Natürlich ist es viel komplizierter und Speicher mit hoher Kapazität spielt eine wichtige Rolle für das Kundenerlebnis.
Wenn man über Content Delivery Networks (CDNs) nachdenkt, ist es einfach, direkt zu den großen Marken zu gehen, die wir kennen, wie Netflix, Hulu usw. Das macht Sinn; Es ist intuitiv, daran zu denken, dass die neueste Folge Ihrer Lieblingssendung auf Ihr Telefon oder den Fernseher im Wohnzimmer übertragen wird. Natürlich ist es viel komplizierter und Speicher mit hoher Kapazität spielt eine wichtige Rolle für das Kundenerlebnis.
Beim Anruf Slotherhouse auf Hulu, Ihr Streaming-Gerät greift zunächst auf ein Edge-CDN in der Nähe Ihres Zuhauses zu. Je mehr Daten der CDN-Knoten speichern kann, desto wahrscheinlicher ist es, dass der Dienst schnell startet, anstatt zu einem weiter entfernten Knoten zu springen, um den angeforderten Inhalt abzurufen. Die Vorteile der Reduzierung der für Video-Streaming erforderlichen Hops liegen auf der Hand, aber CDNs leisten noch viel mehr.
CDNs ermöglichen andere Anwendungsfälle wie Over-the-Air-Updates (OTA) für Autos wie Tesla oder die Übertragung dieser Filmstreams aus dem Internet in das Innere eines Verkehrsflugzeugs. Unabhängig von der Art der bereitgestellten Dateien ist eines klar: Je mehr Sie am Edge speichern können, desto reaktionsfähiger kann ein CDN sein – was entscheidend ist, da Kunden den Erfolg an den Drehungen des Taktgebers messen, ohne sich darum zu kümmern Die zugrunde liegende Infrastruktur macht alles möglich.
Wie bei unseren Berichten üblich, wollten wir nicht nur darüber spekulieren, wie CDNs funktionieren und wo der Druck auf die Architektur am wahrscheinlichsten zu finden ist. Wir gingen zu den Experten. In diesem Fall ist das so Lack-Software, einer der führenden Anbieter von Content-Delivery-Software.
Wir haben mit Varnish zusammengearbeitet, um in unserem Labor einen perfekten Edge-CDN-Knoten zu konfigurieren, der mit der Content-Delivery-Software von Varnish, einem CDN-spezifischen Server von Supermicro, einem enormen Speicherbedarf dank 30.72 TB Solidigm P5316 SSDs und einer Hochgeschwindigkeits-200-GbE-Verbindung von ausgestattet ist NVIDIA soll die Belastungen auf Edge-CDN-Knoten besser in den Griff bekommen und erfahren, wie sich Speicher insbesondere auf die Ergebnisse auswirkt.
Wer ist Varnish Software?
Varnish bietet Content-Delivery-Software, die es einfach macht, digitale Interaktionen zu beschleunigen, enorme Verkehrslasten zu bewältigen und die Web-Infrastruktur zu schützen. Varnish hilft Unternehmen dabei, die Bereitstellung von Inhalten so nah wie möglich an den Kunden zu verlagern, um das beste Erlebnis zu gewährleisten und gleichzeitig den maximalen Return on Investment in die Infrastruktur zu ermöglichen.
Die Grundlage basiert auf einem funktionsreichen und robusten Open-Source-HTTP-Cache und Reverse-Proxy, Varnish Cache, der zwischen dem Ursprung und dem Client sitzt. Es wurde optimiert, um die maximale Leistung und Effizienz aus der zugrunde liegenden Hardware herauszuholen. Varnish Cache rationalisiert Warteschlangen, Speicherung und Abruf auf Systemebene und ist damit die ideale Methode für das Benchmarking von Content-Delivery- und Edge-Delivery-Workloads.
Varnish kann auf fast allem laufen, aber es hat einen Vorteil, den Edge-Knoten in einigen Schlüsselbereichen mehr Leistung zu geben, um das Kundenerlebnis zu verbessern. Jeder Sprung vom Clientgerät zurück zum Rechenzentrum führt zu Latenz. Je mehr der Edge-Knoten liefern kann, desto besser. Zu diesem Zweck haben wir den ultimativen Edge-CDN-Knoten erstellt und ihn mit den strengen Knotenvalidierungstools von Varnish getestet.
Was macht Varnish CDN so verdammt schnell?
CDNs benötigen mehr als ein schnelles Netzwerk, insbesondere am Rand. Es wäre ineffizient und langsam, wenn jede Anfrage zur Aktualisierung an die Host-Site zurückgehen müsste. Die optimale Lösung wäre ein Speichersystem, um Daten kundennah zu verarbeiten und zu speichern. Das System benötigt enorme Speicherkapazitäten und einen Hochleistungsserver, der Informationen schnell aus dem Cache abrufen und ohne Verzögerung bereitstellen kann.
Varnish Software hat eine Lösung implementiert, die sehr große Datensätze unterstützt, um praktisch jeder Umgebung mit Hochleistungsservern und Speichersystemen mit hoher Dichte gerecht zu werden. Lernen Sie die Massive Storage Engine kennen.
Die Massive Storage Engine (MSE) von Varnish Software ist eine optimierte Festplatten- und Speicher-Cache-Engine. MSE ermöglicht leistungsstarkes Caching und Persistenz für Datensätze mit mehr als 100 TB und unterstützt die Video- und Medienverteilung, CDNs und Anwendungsfälle mit großem Cache. MSE eignet sich perfekt für Unternehmen, bei denen die leistungsstarke Bereitstellung großer Datenmengen von entscheidender Bedeutung ist.
Mit dem leistungsstarken MSE bleibt der Cache zwischen Neustarts und Upgrades intakt, wodurch teures und zeitaufwändiges Nachfüllen des Caches vermieden wird. Dies ermöglicht einen schnellen Abruf und hilft, eine Überlastung des Netzwerks nach einem Neustart zu vermeiden.
Die MSE-Lösung kann nahezu unbegrenzt große Objekte im Cache speichern und bereitstellen, um eine schnelle und skalierbare Bereitstellung von Inhalten zu ermöglichen. MSE wurde optimiert, um Inhalte mit weniger Fragmentierung für die LRU-Cache-Eviction-Richtlinie (Least Latest Used) bereitzustellen, was zu überlegener Leistung und Parallelität führt. Für Kunden mit einer Cache-Größe von mehr als 50 GB oder begrenztem Speicher empfiehlt Varnish die Verwendung von MSE.
Die neueste Generation von MSE (MSE 4) ermöglicht den ordnungsgemäßen Ausfall von Festplatten, sodass persistente Cache-Footprints den Betrieb automatisch wieder aufnehmen können, nachdem ein Festplattenausfall erkannt wurde.
Hardwarekonfiguration des Edge-CDN-Knotens
In unserem Testszenario nutzten wir einen einzelnen Server, der als Edge-CDN-Knoten fungierte, und einen einzelnen Client. Unser CDN-Knoten basiert auf dem Supermicro SYS-111E-WR-Server mit einer einzelnen Intel Xeon Gold 6414U CPU. Diese CPU bietet 32 Kerne und hat eine Grundfrequenz von 2 GHz.
Wir haben diese CPU mit 256 GB DDR5-Speicher und acht Solidigm P5316 30.72 TB QLC SSDs gepaart. Ziel dieses Entwurfs war es zu zeigen, was ein schlankes Bereitstellungsmodell in Bezug auf die Leistung bieten kann, ohne dass teurere SSDs oder zusätzliche CPU-Ressourcen erforderlich wären, die nicht ausreichend genutzt würden.
Für die Client-Seite verwendeten wir in unserem Labor eine verfügbare Dual-Prozessor-Plattform mit Intel
Unsere Systeme waren mit Ubuntu 22.04 als Betriebssystem konfiguriert und jedes war mit einer NVIDIA 200-Gb-NIC ausgestattet. Die 200-Gbit-Ethernet-Struktur bot ausreichend Bandbreite für dieses Testszenario.
Edge-CDN-Knotenleistung
Der Testlauf untersuchte die Gesamtleistung von Varnish Software auf dem von uns erstellten Edge-Knoten. Zu den kritischen ausgewerteten Metriken gehören insbesondere TTLB (Time to Last Byte), Anfragen/Sekunde, Übertragung/Sekunde (Bytes), Gesamtanfragen, Fehler, CPU-Auslastung, Speichernutzung, Durchsatz und Goodput. Zur Klarstellung: Durchsatz ist alles, was von Varnish gesendet wird, und Goodput ist das, was der Client tatsächlich sieht, wobei erneute Übertragungen oder Overhead-Daten ignoriert werden.
Die Tests wurden mit abgeschlossen WRK als lastgenerierendes Tool, das unterschiedlich große Dateiblöcke über 100 TCP-Verbindungen aus einem Video-Backend abruft. Der Test wurde auf eine Cache-Trefferquote von 90 bis 95 % ausgelegt, um zu simulieren, was in bereitgestellten Videobereitstellungsumgebungen häufig vorkommt. Um unterschiedliche Arbeitslasten zu simulieren, haben wir uns auf die Leistung kleiner und großer Dateien konzentriert, wobei kleinere Dateien API-Aufrufe simulieren und größere Dateien verschiedene Videoqualitäten in einem Live- oder Video-on-Demand-Szenario (VOD) darstellen könnten.
Wir haben Dateigrößen von 100 und 500 Kilobyte für die kleineren Objekttests und 1,000, 10,000, 16,000 und 50,000 Kilobyte für größere Objekte getestet. Wir hofften, durch die Betrachtung verschiedener Dateigrößen eine Mischung aus CDN-Anwendungsfällen zu erfassen. Für Unternehmen, die umfangreiche, aber kleine API-Aufrufe durchführen, sind 100 Kilobyte wahrscheinlich größer als die meisten anderen. Bei VOD kann ein 10-MB-Objekt einen kurzen Videoclip darstellen, 16 MB ein HD-Video und 50 MB ein Video mit noch höherer Qualität. Diese Dateigrößen können auch auf die Verteilung und Bereitstellung von ISO-Images, Software-Updates und Installationspaketen angewendet werden.
Das Lasttest-Tool WRK gibt TTLB (Time to Last Byte) zurück, sodass die Latenzmetriken die vollständige Ladezeit für den gesamten Videoblock zeigen. Außerdem ist TTFB (Time to First Byte) die Zeit der ersten Serverantwort, die normalerweise in Millisekunden gemessen wird und für viele verschiedene Dateigrößen konstant ist.
Wir beobachteten TTLBs von 4.4 ms bis 995.2 ms. Für den kleinsten Videoblock von 100 Kilobyte betrug die durchschnittliche vollständige Antwort nur 4.4 ms. Bei der größten Größe von 50 MB war der gesamte Ladevorgang immer noch in weniger als 1 Sekunde im Durchschnitt abgeschlossen.
Weitere wichtige Kennzahlen sind die Fehleranzahl; Die einzigen festgestellten Fehler waren einige verbleibende Zeitüberschreitungsfehler. Diese werden für die größten Objekte erwartet. Die CPU- und Speicherauslastung blieb in diesen Tests gesund und lag bei etwa 50 bis 60 Prozent der vollen Kapazität. Die höchste CPU-Auslastung war beim 100-KB-Test mit 58.8 Prozent und beim 50-MB-Test mit 58 Prozent zu verzeichnen, was auf die schiere Anzahl der Anfragen für die kleineren Dateien und die Größe der größeren Dateien zurückzuführen ist.
Der durchschnittliche Durchsatz für das größere Video betrug 170.5+ Gbit/s und der Durchschnitt für das kleinere Video lag bei 164+ Gbit/s.
Die Goodput-Durchschnittswerte für die größeren Größen betrugen 158.8+ Gbit/s und 149.1+ Gbit/s für die kleineren Größen, wobei ein WRK-Client als Ladegenerator diente. Es wird erwartet, dass durch die Skalierung der WRK-Clients höhere Durchsätze erreicht werden können, wie in einigen anderen von Varnish intern durchgeführten Experimenten beobachtet, aber das liegt außerhalb des Rahmens dieses Dokuments.
Während reine Leistungskennzahlen wichtig sind, ist der Stromverbrauch ein weiterer Gesichtspunkt für Edge-CDN-Systeme. Hier kommt die Plattform ins Spiel, die wir für dieses Projekt ausgewählt haben. Die Einzelsteckdose Supermicro SYS-111E-WR-Server bietet eine dichte NVMe-Speicherplattform mit zahlreichen PCIe-Steckplätzen für Netzwerkkarten, ohne mit zwei Prozessoren zu aggressiv auf die Stromversorgung zuzugehen.
Um die Leistungsaufnahme des Servers bei angelegter Last zu messen, haben wir unser Quarch-Netzstromanalysemodul genutzt. Dies gibt uns einen genauen Überblick über die vom Server verbrauchte Leistung mit einer Reaktionszeit von 125us. Hier haben wir jede Testgruppe im gleichen Zeitraum durchlaufen und die durchschnittliche Leistung vom Beginn der Arbeitsbelastung bis zum Ende gemessen.
Wir haben uns auf zwei Leistungsmetriken konzentriert: Gesamtsystem-RMS-Leistung im Vergleich zur Testdateigröße und Anforderungen pro Sekunde und Watt. Während die erste Annahme wäre, dass der Stromverbrauch mit höheren Übertragungsgeschwindigkeiten zunimmt, war dies nicht der Fall. Bei kleineren Transfergrößen konnten wir einen erhöhten Stromverbrauch feststellen, der mit zunehmender Transfergröße leicht abnahm. Dies liegt daran, dass kleinere Übertragungsgrößen mehr E/A-Prozesse verursachen, während größere Übertragungsgrößen weniger E/A-Prozesse erfordern.
Betrachtet man die gesamte Systemleistung, so haben wir bei der Übertragungsgröße 1 MB eine Systemleistung von 473.9 W gemessen, die sich bei der Übertragungsgröße 426.5 MB auf 50 W verringerte. Wenn wir das in Anfragen pro Sekunde und Watt aufschlüsseln, betrug die Übertragungsgröße von 1 Mio. 46.9, bei der Übertragungsgröße von 1.09 Mio. waren es nur noch 50.
Balance zwischen Leistung und Kosten
Unser Varnish CDN-Knoten wurde entwickelt, um außergewöhnliche Leistung und Dichte zu bieten. Nicht nur mit der 1U-Server-Rack-Dichte, sondern auch mit der Kapazitätsdichte, die die Solidigm-SSDs bieten. Wir verwenden heute „nur“ die P30.72-Laufwerke mit 5316 TB, aber mit den P61.44-Einheiten mit 5336 TB gibt es sogar noch mehr Vorteile. Was noch besser ist: Die CDN-Arbeitslast ist extrem leselastig, sodass diese QLC-basierten SSDs perfekt für diese Aufgabe geeignet sind. Witzigerweise dachte der Ingenieur bei der Überprüfung der Leistungszahlen mit Varnish, dass wir Gen5-SSDs verwenden würden, weil die Knotenleistung so beeindruckend war.
Während die Serverdichte ein entscheidendes Element ist, ist ein kostenoptimierter CDN-Knoten etwas anderes. Der hier verwendete Supermicro-Server mit einem Prozessor bietet Varnish reichlich Hardwareleistung und Erweiterungsoptionen, während wir mit den zehn NVMe-Schächten über 600 TB Speicher aufbauen können, indem wir die führende SSD-Kapazität von Solidigm nutzen. Die relative Leistung pro Dollar, und wenn Sie etwas tiefer in unsere Daten eintauchen möchten, die Leistung pro Watt, sind hier unbestreitbare Kennzahlen.
CDNs haben die wenig beneidenswerte Aufgabe, Daten kurzfristig mit manchmal vorhersehbaren, oft nicht vorhersehbaren Anforderungen bereitzustellen. Eine fein abgestimmte Server-Hardware macht den entscheidenden Unterschied bei der Leistung dieser CDN-Knoten, die zunehmend weiter an den Rand gedrängt werden. Mit den massiven Enterprise-SSDs von Solidigm können diese Knoten die Cache-Trefferraten erheblich verbessern und letztendlich ein überragendes Kundenerlebnis bieten.
Dieser Bericht wird von Solidigm gesponsert. Alle in diesem Bericht geäußerten Ansichten und Meinungen basieren auf unserer unvoreingenommenen Sicht auf das/die betrachtete(n) Produkt(e).
Beteiligen Sie sich an StorageReview
Newsletter | YouTube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | RSS Feed
