Als we aan Content Delivery Networks (CDN's) denken, is het gemakkelijk om rechtstreeks naar de grote merken te gaan die we kennen, zoals Netflix, Hulu, enz. Dat is logisch; het is intuïtief om na te denken over de nieuwste aflevering van uw favoriete programma die wordt gedistribueerd naar uw telefoon of tv in de woonkamer. Het is natuurlijk veel ingewikkelder dan dat, en opslag met hoge capaciteit speelt een grote rol in de klantervaring.
Als we aan Content Delivery Networks (CDN's) denken, is het gemakkelijk om rechtstreeks naar de grote merken te gaan die we kennen, zoals Netflix, Hulu, enz. Dat is logisch; het is intuïtief om na te denken over de nieuwste aflevering van uw favoriete programma die wordt gedistribueerd naar uw telefoon of tv in de woonkamer. Het is natuurlijk veel ingewikkelder dan dat, en opslag met hoge capaciteit speelt een grote rol in de klantervaring.
Bij het bellen Slotherhouse op Hulu, zal uw streamingapparaat eerst een edge-CDN dichtbij huis bereiken. Hoe meer gegevens het CDN-knooppunt kan bevatten, hoe groter de kans dat de service een snelle start levert in plaats van naar een verder weg gelegen knooppunt te stuiteren om de gevraagde inhoud op te halen. De voordelen van het verminderen van de hop die nodig is voor videostreaming liggen nogal voor de hand, maar CDN's doen veel meer dan dat.
CDN's maken andere gebruiksscenario's mogelijk, zoals over-the-air (OTA) updates voor auto's als Tesla of het verplaatsen van filmstreams van internet naar de binnenkant van een commercieel vliegtuig. Ongeacht het type bestanden dat wordt aangeleverd, is één ding duidelijk: hoe meer je aan de rand kunt opslaan, hoe responsiever een CDN kan zijn. Dit is van cruciaal belang omdat klanten succes afmeten aan de draaiingen van de dreun, zonder zich druk te maken over de onderliggende infrastructuur waardoor het allemaal gebeurt.
Zoals gebruikelijk bij onze rapporten wilden we niet alleen speculeren over hoe CDN's werken en waar de druk op de architectuur het meest waarschijnlijk te vinden is. We zijn naar de deskundigen gegaan. In dit geval is dat zo Vernis Software, een van de meest vooraanstaande leiders op het gebied van software voor het leveren van inhoud.
We hebben samengewerkt met Varnish om een perfecte edge CDN-node in ons laboratorium te configureren, uitgerust met Varnish's content delivery-software, een CDN-specifieke server van Supermicro, een enorme opslagcapaciteit dankzij 30.72TB Solidigm P5316 SSD's en een snelle 200GbE-interconnect van NVIDIA om beter grip te krijgen op de stressoren op edge CDN-nodes en hoe opslag in het bijzonder de resultaten beïnvloedt.
Wie is Varnish Software?
Varnish biedt software voor het leveren van inhoud waarmee u eenvoudig digitale interacties kunt versnellen, enorme verkeersbelastingen kunt afhandelen en de webinfrastructuur kunt beschermen. Varnish helpt organisaties de levering van content zo dicht mogelijk bij de klant te brengen om de beste ervaring te garanderen en tegelijkertijd het maximale rendement op investeringen in infrastructuur mogelijk te maken.
De basis is gebaseerd op een feature-rijke en robuuste open-source HTTP-cache en reverse proxy, Varnish Cache, die zich tussen de oorsprong en de client bevindt. Het is geoptimaliseerd om de maximale prestaties en efficiëntie uit de onderliggende hardware te halen. Varnish Cache stroomlijnt wachtrijen, opslag en ophalen op systeemniveau, waardoor het de ideale methode is voor het benchmarken van contentlevering en edge-delivery-workloads.
Vernis kan op vrijwel alles worden gebruikt, maar het heeft een voordeel om hun edge-nodes op een paar belangrijke gebieden meer pk's te geven om de klantervaring te verbeteren. Elke sprong terug naar het datacenter vanaf het clientapparaat introduceert latentie, dus hoe meer het edge-knooppunt kan leveren, hoe beter. Daartoe hebben we het ultieme edge CDN-knooppunt gebouwd en getest met de rigoureuze knooppuntvalidatietools van Varnish.
Wat maakt Varnish CDN zo snel?
CDN’s hebben meer nodig dan een snel netwerk, vooral aan de edge. Het zou inefficiënt en traag zijn als elk verzoek terug moest gaan naar de hostsite voor vernieuwing. De optimale oplossing zou een opslagsysteem zijn om gegevens dicht bij de klant te verwerken en op te slaan. Het systeem heeft enorme opslagcapaciteiten nodig en een krachtige server die snel informatie uit de cache kan halen en deze zonder vertraging kan afleveren.
Varnish Software heeft een oplossing geïmplementeerd die zeer grote datasets ondersteunt om aan vrijwel elke omgeving met krachtige servers en opslagsystemen met hoge dichtheid te voldoen. Maak kennis met de Massive Storage Engine.
De Massive Storage Engine (MSE) van Varnish Software is een geoptimaliseerde schijf- en geheugencache-engine. MSE maakt hoogwaardige caching en persistentie mogelijk voor datasets van meer dan 100 TB die video- en mediadistributie, CDN's en gebruiksscenario's met grote caches ondersteunen. MSE is perfect geschikt voor bedrijven waar hoogwaardige levering van grote datasets van cruciaal belang is.
Met de goed presterende MSE blijft de cache intact tussen herstarts en upgrades, waardoor dure en tijdrovende cache-aanvullingen worden voorkomen. Dit zorgt voor snel ophalen en helpt netwerkcongestie na een herstart te voorkomen.
De MSE-oplossing kan objecten van vrijwel onbeperkte grootte in de cache opslaan en bedienen, voor snelle en schaalbare levering van inhoud. MSE is geoptimaliseerd om inhoud te leveren met minder fragmentatie voor het minst recent gebruikte (LRU) cache-uitzettingsbeleid, wat resulteert in superieure prestaties en gelijktijdigheid. Voor klanten met een cachegrootte van meer dan 50 GB of een beperkt geheugen raadt Varnish het gebruik van MSE aan.
De nieuwste generatie MSE (MSE 4) maakt het mogelijk om schijven op een elegante manier uit te laten vallen, waardoor persistente cache-footprints de werking automatisch kunnen hervatten nadat een schijffout is gedetecteerd.
Hardwareconfiguratie van Edge CDN-knooppunt
In ons testscenario hebben we gebruik gemaakt van een enkele server die fungeert als een Edge CDN-knooppunt en een enkele client. Ons CDN-knooppunt is gebaseerd op de Supermicro SYS-111E-WR-server met een enkele Intel Xeon Gold 6414U CPU. Deze CPU biedt 32 cores en heeft een basisfrequentie van 2GHz.
We hebben deze CPU gecombineerd met 256 GB DDR5-geheugen en acht Solidigm P5316 30.72 TB QLC SSD's. Dit ontwerp was bedoeld om te laten zien wat een lean implementatiemodel kan bieden op het gebied van prestaties zonder dat er duurdere SSD's of extra CPU-bronnen nodig zijn die onderbenut zouden blijven.
Aan de clientkant gebruikten we in ons laboratorium een beschikbaar dual-processorplatform met Intel Xeon Platinum 8450H CPU's, wat overdreven is maar voldoende middelen had om ervoor te zorgen dat het knelpunt het netwerk of het CDN-knooppunt was.
Onze systemen waren geconfigureerd met Ubuntu 22.04 als besturingssysteem en elk was uitgerust met een NVIDIA 200Gb NIC. De 200Gb Ethernet-fabric bood voldoende bandbreedte voor dit testscenario.
Prestaties van Edge CDN-knooppunten
Bij de testrun werd gekeken naar de algehele prestaties van Varnish Software op het edge-knooppunt dat we hadden gebouwd. De geëvalueerde kritische meetgegevens omvatten met name TTLB (Time to Last Byte), verzoeken/seconde, overdracht/seconde (bytes), totaal aantal verzoeken, fouten, CPU-gebruik, geheugengebruik, doorvoer en goodput. Voor alle duidelijkheid: doorvoer is alles wat door Varnish wordt verzonden, en goede doorvoer is wat de klant daadwerkelijk ziet, waarbij hertransmissies of overheadgegevens worden genegeerd.
De tests zijn uitgevoerd met behulp van WRK als een tool voor het genereren van belasting, waarbij bestandsfragmenten van verschillende grootte uit een video-backend worden gehaald met behulp van 100 TCP-verbindingen. De test is ontworpen om een cachetrefferratio van 90% tot 95% te hebben om te simuleren wat vaak wordt gezien in geïmplementeerde video-leveringsomgevingen. Om verschillende werklasten te simuleren, hebben we ons gericht op de prestaties van kleine en grote bestanden, waarbij kleinere bestanden API-aanroepen konden simuleren en grotere bestanden verschillende videokwaliteiten konden vertegenwoordigen in een live- of video-on-demand (VOD)-scenario.
We hebben bestandsgroottes van 100 en 500 kilobytes getest voor de kleinere objecttests en 1,000, 10,000, 16,000 en 50,000 kilobytes voor grotere objecten. We hoopten een mix van CDN-gebruiksscenario's vast te leggen door naar verschillende bestandsgroottes te kijken. Voor organisaties die grote maar kleine API-aanroepen uitvoeren, zal 100 kilobytes waarschijnlijk groter zijn dan de meeste. Voor VOD kan een object van 10 MB een korte videoclip vertegenwoordigen, 16 MB een HD-video en 50 MB een video van nog hogere kwaliteit. Deze bestandsgroottes kunnen ook worden toegepast op het distribueren en leveren van ISO-images, software-updates en installatiepakketten.
De belastingtesttool WRK retourneert TTLB (Time to Last Byte), dus de latentiestatistieken tonen de volledige laadtijd voor het hele videofragment. Bovendien is TTFB (Time to First Byte) de tijd van de eerste serverreactie, meestal gemeten in milliseconden, en is constant voor veel verschillende bestandsgroottes.
We hebben TTLB’s van 4.4 ms tot 995.2 ms waargenomen. Voor het kleinste videofragment van 100 kilobyte was de gemiddelde volledige respons slechts 4.4 ms. Voor de grootste omvang van 50 MB werd het volledige laden gemiddeld nog steeds binnen 1 seconde voltooid.
Andere belangrijke statistieken zijn het aantal fouten; de enige geconstateerde fouten waren enkele resterende time-outfouten. Deze worden verwacht voor de grootste objecten. Het CPU- en geheugengebruik bleef gezond, ~50 procent tot 60 procent van de volledige capaciteit tijdens deze tests. Het hoogste CPU-gebruik was tijdens de 100 KB-test met 58.8 procent en de 50 MB-test met 58 procent, vanwege het enorme aantal verzoeken voor de kleinere bestanden en de grootte van de grotere bestanden.
De gemiddelde doorvoer voor de grotere video was 170.5+ Gbps, en het gemiddelde voor de kleinere video was 164+ Gbps.
Goodput-gemiddelden voor de grotere formaten waren 158.8+ Gbps en 149.1+ Gbps voor de kleinere formaten met één WRK-client als laadgenerator. Er wordt verwacht dat hogere doorvoersnelheden kunnen worden bereikt door de WRK-clients op te schalen, zoals waargenomen in een paar andere experimenten die intern door Varnish worden uitgevoerd, maar dat valt buiten de reikwijdte van dit artikel.
Hoewel ruwe prestatiestatistieken belangrijk zijn, is het energieverbruik een andere overweging voor Edge CDN-systemen. Dit is waar het platform dat we voor dit project hebben gekozen in het spel komt. Het enkele stopcontact Supermicro SYS-111E-WR-server biedt een compact NVMe-opslagplatform met voldoende PCIe-slots voor NIC's zonder te energie-agressief te worden met dubbele processors.
Om het stroomverbruik van de server te meten bij toegepaste belasting, hebben we gebruik gemaakt van onze Quarch Mains Power Analysis Module. Dit geeft ons een nauwkeurig beeld van het vermogen dat van de server wordt afgenomen, met een responstijd van 125us. Hier hebben we elke testgroep gedurende dezelfde periode doorgenomen en het gemiddelde vermogen gemeten vanaf het begin van de werklast tot het einde.
We hebben ons gericht op twee vermogensstatistieken: het totale RMS-systeemvermogen versus de testbestandsgrootte en verzoeken per seconde per watt. Hoewel de eerste veronderstelling zou zijn dat het stroomverbruik toeneemt bij hogere overdrachtssnelheden, was dat niet het geval. We zagen een verhoogd stroomverbruik bij lagere overdrachtsgroottes, dat enigszins afnam naarmate de overdrachtsgrootte groter werd. Dit komt neer op de kleinere overdrachtsgroottes die meer I/O-processen aandrijven, met grotere overdrachtsgroottes met minder I/O-processen.
Kijkend naar het totale systeemvermogen, met een overdrachtsgrootte van 1M, hebben we een systeemvermogensniveau van 473.9W gemeten, dat afnam tot 426.5W met een overdrachtsgrootte van 50M. Wanneer we dat uitsplitsen in verzoeken per seconde per watt, bedroeg de overdrachtsgrootte van 1M 46.9, tot 1.09 voor de overdrachtsgrootte van 50M.
Evenwicht tussen prestaties en kosten
Ons Varnish CDN-knooppunt is gemaakt om uitzonderlijke prestaties en dichtheid te bieden. Niet alleen met de 1U-serverrackdichtheid, maar ook met de capaciteitsdichtheid van de Solidigm SSD's. We gebruiken momenteel “slechts” de P30.72-schijven van 5316 TB, maar er is nog meer voordeel beschikbaar met de P61.44-eenheden van 5336 TB. Wat nog beter is, is dat de CDN-werklast extreem veel leeswerk vergt, wat betekent dat deze op QLC gebaseerde SSD's perfect zijn voor deze taak. Grappig terzijde: toen de ingenieur de prestatiecijfers met Varnish beoordeelde, dacht hun ingenieur dat we Gen5 SSD's gebruikten omdat de prestaties van de knooppunten zo indrukwekkend waren.
Hoewel serverdichtheid een cruciaal element is, is een kostengeoptimaliseerd CDN-knooppunt iets anders. De Supermicro-server met één processor die we hier gebruikten, biedt Varnish veel hardwarekracht en uitbreidingsmogelijkheden, terwijl we met de tien NVMe-bays meer dan 600 TB aan opslag kunnen accumuleren met behulp van Solidigm's leiderschap op het gebied van SSD-capaciteit. De relatieve prestaties per dollar, en als je wat dieper in onze gegevens wilt duiken, de prestaties per watt, zijn hier onbetwistbaar.
CDN's hebben de niet benijdenswaardige taak om gegevens in een mum van tijd te leveren met soms voorspelbare, vaak niet-aanvragen. Een nauwkeurig afgestemd stukje serverhardware maakt het verschil als het gaat om de prestaties van deze CDN-nodes, die steeds verder naar de rand worden geduwd. Met de enorme enterprise SSD's van Solidigm kunnen deze knooppunten de cachehitrates dramatisch verbeteren, wat uiteindelijk een superieure klantervaring oplevert.
Dit rapport is gesponsord door Solidigm. Alle standpunten en meningen in dit rapport zijn gebaseerd op onze onbevooroordeelde kijk op het (de) product(en) in kwestie.
Neem contact op met StorageReview
Nieuwsbrief | YouTube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | RSS Feed
