När man tänker på Content Delivery Networks (CDN) är det lätt att gå direkt till de stora varumärkena vi känner, som Netflix, Hulu, etc. Det är vettigt; det är intuitivt att tänka på att det senaste avsnittet av ditt favoritprogram distribueras till din telefon eller TV i vardagsrummet. Naturligtvis är det mycket mer komplicerat än så, och lagring med hög kapacitet spelar en stor roll för kundupplevelsen.
När man tänker på Content Delivery Networks (CDN) är det lätt att gå direkt till de stora varumärkena vi känner, som Netflix, Hulu, etc. Det är vettigt; det är intuitivt att tänka på att det senaste avsnittet av ditt favoritprogram distribueras till din telefon eller TV i vardagsrummet. Naturligtvis är det mycket mer komplicerat än så, och lagring med hög kapacitet spelar en stor roll för kundupplevelsen.
När man ringer upp Slotherhouse på Hulu, kommer din strömningsenhet först att träffa ett kant-CDN nära hemmet. Ju mer data som CDN-noden kan hålla, desto mer sannolikt ger tjänsten en snabb start snarare än att studsa till en nod längre bort för att hämta det begärda innehållet. Fördelarna med att minska antalet hopp som krävs för videoströmning är ganska uppenbara, men CDN:er gör mycket mer än så.
CDN:er möjliggör andra användningsfall som OTA-uppdateringar (Over-the-air) för bilar som Tesla eller att flytta dessa filmströmmar från internet till insidan av ett kommersiellt flygplan. Oavsett vilken typ av filer som levereras, är en sak klar: ju mer du kan lagra i kanten, desto mer lyhörd kan ett CDN vara – vilket är avgörande eftersom kunder mäter framgång genom snurrarna från throbber, med lite omsorg om underliggande infrastruktur som gör att allt händer.
Som vanligt med våra rapporter ville vi inte bara spekulera om hur CDN:er fungerar och var trycket på arkitekturen med största sannolikhet finns. Vi gick till experterna. I det här fallet, alltså Varnish programvara, en av de framstående ledarna inom programvara för innehållsleverans.
Vi samarbetade med Varnish för att konfigurera en perfekt Edge CDN-nod i vårt labb, utrustad med Varnishs programvara för innehållsleverans, en CDN-specifik server från Supermicro, ett enormt lagringsutrymme tack vare 30.72 TB Solidigm P5316 SSD:er och en höghastighets 200GbE sammankoppling från NVIDIA för att få ett bättre grepp om stressorerna på kant-CDN-noder och hur lagring, specifikt, påverkar resultaten.
Vem är Varnish Software?
Varnish erbjuder programvara för innehållsleverans som gör det enkelt att snabba upp digitala interaktioner, hantera enorma trafikbelastningar och skydda webbinfrastruktur. Varnish hjälper organisationer att flytta innehållsleverans så nära kunden som möjligt för att säkerställa den bästa upplevelsen samtidigt som den möjliggör maximal avkastning på investeringar i infrastruktur.
Grunden är baserad på en funktionsrik och robust HTTP-cache med öppen källkod och omvänd proxy, Varnish Cache, som sitter mellan ursprunget och klienten. Den har optimerats för att extrahera maximal prestanda och effektivitet från den underliggande hårdvaran. Varnish Cache effektiviserar köer, lagring och hämtning på systemnivå, vilket gör det till den idealiska metoden för benchmarking av innehållsleverans och arbetsbelastningar för kantleverans.
Varnish kan köras på nästan vad som helst, men det finns en fördel med att ge sina kantnoder fler hästkrafter inom några nyckelområden för att förbättra kundupplevelsen. Varje hopp tillbaka till datacentret från klientenheten introducerar latens, så ju mer kantnoden kan leverera, desto bättre. För det ändamålet byggde vi den ultimata Edge CDN-noden och testade den med Varnishs rigorösa nodvalideringsverktyg.
Vad gör Varnish CDN så jäkla snabbt?
CDN:er behöver mer än ett snabbt nätverk, särskilt vid kanten. Det skulle vara ineffektivt och långsamt om varje begäran måste gå tillbaka till värdsidan för en uppdatering. Den optimala lösningen skulle vara ett lagringssystem för att bearbeta och lagra data nära kunden. Systemet behöver enorma lagringsmöjligheter och en högpresterande server som snabbt kan hämta information från cachen och leverera den utan fördröjning.
Varnish Software har implementerat en lösning som stöder mycket stora datamängder för att möta praktiskt taget alla miljöer med högpresterande servrar och högdensitetslagringssystem. Möt Massive Storage Engine.
Varnish Softwares Massive Storage Engine (MSE) är en optimerad disk- och minnescachemotor. MSE möjliggör högpresterande cachelagring och beständighet för 100 TB plus datamängder som stöder video- och mediadistribution, CDN:er och användningsfall med stor cache. MSE passar perfekt för företag där högpresterande leverans av stora datamängder är avgörande.
Med den högpresterande MSE förblir cachen intakt mellan omstarter och uppgraderingar, vilket förhindrar dyra och tidskrävande cachepåfyllning. Detta ger snabb hämtning och hjälper till att undvika nätverksstockning efter en omstart.
MSE-lösningen kan lagra och betjäna objekt i nästan obegränsad storlek i cache för snabb och skalbar innehållsleverans. MSE har optimerats för att leverera innehåll med mindre fragmentering för minst nyligen använda (LRU) cache-eviction policy, vilket resulterar i överlägsen prestanda och samtidighet. För kunder med en cachestorlek större än 50 GB eller begränsat minne rekommenderar Varnish att använda MSE.
Den senaste generationen av MSE (MSE 4) möjliggör det graciösa felet på diskar, vilket gör att ihållande cache-footprints kan återupptas automatiskt efter att diskfel har upptäckts.
Edge CDN Node Hardware Configuration
I vårt testscenario utnyttjade vi en enda server som fungerade som en Edge CDN Node och en enda klient. Vår CDN-nod är baserad på Supermicro SYS-111E-WR-server med en enda Intel Xeon Gold 6414U CPU. Denna CPU har 32 kärnor och har en basfrekvens på 2GHz.
Vi parade ihop denna CPU med 256 GB DDR5-minne och åtta Solidigm P5316 30.72 TB QLC SSD. Denna design syftade till att visa vad en lean implementeringsmodell kan erbjuda när det gäller prestanda utan att kräva dyrare SSD:er eller ytterligare CPU-resurser som skulle vara underutnyttjade.
För klientsidan använde vi en tillgänglig plattform med dubbla processorer i vårt labb med Intel Xeon Platinum 8450H-processorer, vilket är överdrivet men hade gott om resurser för att säkerställa att flaskhalsen var antingen nätverk eller CDN-noden.
Våra system konfigurerades med Ubuntu 22.04 som operativsystem, och var och en var utrustad med ett NVIDIA 200Gb NIC. 200 Gb Ethernet-tyget erbjöd massor av bandbredd för detta testscenario.
Edge CDN Node Prestanda
Testkörningen tittade på den övergripande prestandan för Varnish Software på kantnoden vi byggde. Specifikt inkluderar de kritiska mätvärdena som utvärderas TTLB (Time to Last Byte), förfrågningar/sekund, överföring/sekund (byte), totala förfrågningar, fel, CPU-användning, minnesanvändning, genomströmning och goodput. Som en tydlig punkt är genomströmning allt som skickas av Varnish, och goodput är vad klienten faktiskt ser, och ignorerar återsändningar eller overheaddata.
Testerna genomfördes med hjälp av WRK som ett belastningsgenererande verktyg som drar filbitar av olika storlekar från en videobackend med 100 TCP-anslutningar. Testet utformades för att ha en cacheträffförhållande på 90 % upp till 95 % för att simulera vad som ofta ses i distribuerade videoleveransmiljöer. För att simulera olika arbetsbelastningar fokuserade vi på prestanda för små och stora filer, där mindre filer kunde simulera API-anrop och större filer kan representera olika videokvaliteter i ett live- eller video-on-demand-scenario (VOD).
Vi testade filstorlekar på 100 och 500 kilobyte för de mindre objekttesterna och 1,000 10,000, 16,000 50,000, 100 10 och 16 50 kilobyte för större objekt. Vi hoppades kunna fånga en blandning av CDN-användningsfall genom att titta på en rad filstorlekar. För organisationer som gör stora volymer men små API-anrop kommer XNUMX kilobyte sannolikt att vara större än de flesta. För VOD kan ett objekt på XNUMX MB representera ett kort videoklipp, XNUMX MB en HD-video och XNUMX MB en video med ännu högre kvalitet. Dessa filstorlekar kan också användas för att distribuera och leverera ISO-bilder, programuppdateringar och installationspaket.
Lasttestverktyget WRK returnerar TTLB (Time to Last Byte), så latensstatistiken visar hela laddningstiden för hela videodelen. Dessutom är TTFB (Time to First Byte) tiden för det första serversvaret, vanligtvis mätt i millisekunder, och är konstant för många olika filstorlekar.
Vi observerade TTLB på 4.4 ms upp till 995.2 ms. För den minsta videobiten på 100 kilobyte var den genomsnittliga fulla responsen bara 4.4 ms. För den största storleken på 50 MB var hela laddningen fortfarande klar på under 1 sekund i genomsnitt.
Andra mätvärden att notera är antalet fel; de enda fel som noterades var några kvarvarande timeout-fel. Dessa förväntas för de största objekten. CPU- och minnesanvändningen förblev bra, ~50 procent upp till 60 procent av full kapacitet i dessa tester. Den högsta CPU-användningen var under 100KB-testet med 58.8 procent och 50MB-testet med 58 procent på grund av det stora antalet förfrågningar för de mindre filerna och storleken på de större filerna.
Den genomsnittliga genomströmningen för den större videon var 170.5+ Gbps, och genomsnittet för den mindre videon var 164+ Gbps.
Goodput-genomsnittet för de större storlekarna var 158.8+ Gbps och 149.1+ Gbps för de mindre storlekarna med en WRK-klient som laddningsgenerator. Det förväntas att högre genomströmningar kan uppnås genom att skala WRK-klienterna, vilket observerats i några andra experiment som körs internt av Varnish, men det ligger utanför ramen för denna artikel.
Även om råa prestandamått är viktiga, är strömförbrukning en annan faktor för Edge CDN-system. Det är här plattformen vi valde för detta projekt kommer in i bilden. Enkeluttaget Supermicro SYS-111E-WR-server erbjuder en tät NVMe-lagringsplattform med massor av PCIe-platser för nätverkskort utan att bli för kraftagressiv med dubbla processorer.
För att mäta strömförbrukningen från servern med belastningen pålagd använde vi vår Quarch Mains Power Analysis Module. Detta ger oss en exakt bild av strömmen som dras från servern, med en svarstid på 125us. Här sprang vi igenom varje testgrupp under samma tidsperiod och mätte medeleffekten från början av arbetsbelastningen till slutet.
Vi fokuserade på två effektmått: total RMS-effekt för systemet kontra testfilstorlek och förfrågningar per sekund per watt. Medan det första antagandet skulle vara att strömanvändningen ökar med högre överföringshastigheter, var det inte fallet. Vi såg förhöjd strömförbrukning vid lägre överföringsstorlekar, som minskade något när överföringsstorleken ökade. Detta beror på att de mindre överföringsstorlekarna driver fler I/O-processer, med större överföringsstorlekar med färre I/O-processer.
När vi tittar på den totala systemeffekten, med 1M överföringsstorlek, mätte vi en systemeffektnivå på 473.9 W, som minskade till 426.5W med 50M överföringsstorlek. När vi delar upp det i förfrågningar per sekund per watt, mätte 1M-överföringsstorleken 46.9, ner till 1.09 för 50M-överföringsstorleken.
Balansera prestanda och kostnad
Vår Varnish CDN-nod skapades för att ge exceptionell prestanda och densitet. Inte bara med 1U-serverrackdensiteten, utan med kapacitetstätheten som tillhandahålls av Solidigm SSD:erna också. Vi använder "bara" P30.72-enheterna på 5316 TB idag, men det finns ännu fler fördelar med 61.44 TB P5336-enheterna. Vad som är ännu bättre, CDN-arbetsbelastningen är extremt lästung, vilket betyder att dessa QLC-baserade SSD:er är perfekta för uppgiften. Som en rolig sida, när de granskade prestandasiffrorna med Varnish, trodde deras ingenjör att vi använde Gen5 SSD: er eftersom nodens prestanda var så imponerande.
Medan serverdensitet är ett kritiskt element, är en kostnadsoptimerad CDN-nod något annat. Den enprocessors Supermicro-server vi använde här ger Varnish massor av hårdvarustyrkor och expansionsmöjligheter, medan de tio NVMe-fackarna låter oss samla över 600 TB lagring med Solidigms SSD-kapacitetsledning. Den relativa prestandan per dollar, och om du vill dyka lite djupare in i vår data, prestanda per watt, mätvärden här är obestridliga.
CDN:er har den föga avundsvärda uppgiften att leverera data med ett ögonblicks varsel med ibland förutsägbara, ofta inte, förfrågningar. En finjusterad bit serverhårdvara gör hela skillnaden eftersom det kommer till prestandan för dessa CDN-noder, som alltmer pressas längre ut mot kanten. Med Solidigms massiva SSD:er för företag kan dessa noder dramatiskt förbättra cacheträfffrekvensen, vilket i slutändan levererar en överlägsen kundupplevelse.
Denna rapport är sponsrad av Solidigm. Alla åsikter och åsikter som uttrycks i denna rapport är baserade på vår opartiska syn på produkten/de produkter som övervägs.
Engagera dig med StorageReview
Nyhetsbrev | Youtube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | Rssflöde
