🥇Sestavujeme a konfigurujeme svůj CDN

Sítě pro doručování obsahu (CDN) se používají na webových stránkách a v aplikacích především ke zrychlení načítání statických prvků. K tomu dochází díky ukládání souborů na servery CDN, které jsou umístěny v různých geografických oblastech. Při dotazu na data přes CDN uživatel obdrží odpověď z nejbližšího serveru.

Princip fungování a funkcionalita všech sítí pro doručování obsahu jsou přibližně stejné. Když obdrží požadavek na načtení souboru, server CDN jednorázově získá soubor z originálního serveru a poskytne ho uživateli, přičemž ho zároveň ukládá na určenou dobu. Na všechny další požadavky je odpověď z dodaného cache. Všechny CDN nabízejí možnosti přednačítání souborů, čištění cache, nastavení doby uchovávání a mnoho dalšího.

Někdy je zapotřebí z různých důvodů zorganizovat vlastní síť pro doručování obsahu, a pak – budiž v pomoc instrukce pro sestavení dalšího kola.

Zdroj: Infografika vektor vytvořena pikisuperstar – www.freepik.com

Kdy je potřeba vlastní CDN

Podíváme se na případy, kdy má smysl spustit vlastní CDN:

když máte chuť ušetřit, a současné náklady i při používání levných CDN jako BunnyCDN se pohybují v řádu několika stovek dolarů měsíčně
pokud chcete mít trvalou cache nebo cache bez spolukomponentů na serveru a kanálu
v požadované oblasti nemají CDN služby žádné bodové přítomnosti
potřebujete nějaké zvláštní nastavení pro doručování obsahu
chcete urychlit dodání dynamického obsahu umístěním produkčních serverů blíže k uživatelům
existuje obava, že externí CDN služba může nezákonně shromažďovat nebo využívat informace o chování uživatelů (ahoj službám bez souladu s GDPR) nebo se zapojit do jiných nezákonných činností

Ve většině ostatních případů je rozumnější využít existující hotová řešení.

Co potřebujete pro spuštění

Je skvělé, pokud máte vlastní autonomní systém (AS). S ním lze přiřadit stejnou IP několika serverům a podle tohoto návodu na úrovni sítě směrovat uživatele k nejbližšímu. Je třeba říci, že i s blokem adres /24 je možné vybudovat síť pro doručování obsahu. Někteří poskytovatelé serverů umožňují provést oznámení pro použití ve všech dostupných regionech.

Pokud nejste šťastným majitelem bloku IP adres, pro spuštění jednoduchého CDN budete potřebovat:

doménové jméno nebo subdoménu
minimálně dva servery v různých regionech. Server může být jak dedikovaný, tak virtuální
geoDNS nástroj. Pomocí něj bude uživatel, když se obrátí na doménu, nasměrován na nejbližší server

Zaregistrujeme doménu a objednáme servery

S registrací domény je to jednoduché — registrujeme v jakékoliv zóně u jakéhokoliv registrátora. Také pro CDN lze použít subdoménu, například něco jako cdn.názvemdomény.com. V našem příkladu to uděláme právě takto.

Pokud jde o objednání serverů — je dobré je pronajmout v regionech a zemích, kde se nachází vaše uživatelská veřejnost. Pokud je projekt mezikontinentální, je vhodné vybírat hostingové poskytovatele, kteří nabízejí servery po celém světě. Příklady: OVH, Leaseweb a 100Tb — pro dedikované servery, Vultr a DigitalOcean — pro virtuální cloudové*.

Pro naše soukromé CDN objednáme 3 virtuální servery na různých kontinentech. Na Vultr serveru za $5/měsíc dostaneme 25GB SSD místa a 1TB datového přenosu. Při instalaci vybereme poslední Debian. Naše servery:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapur, ip: 157.230.240.216

* Vultr a DigitalOcean slibují $100 kreditu uživatelům, kteří se zaregistrují prostřednictvím odkazů v článku, ihned po přidání platební metody. Autor také za to dostává malou odměnu, což je pro něj nyní velmi důležité. Prosím, buďte pochopení.

Nastavujeme geoDNS

Aby uživatel při přístupu na doménu nebo subdoménu CDN byl směrován na potřebný (nejbližší k němu) server, potřebujeme DNS server s funkcí geoDNS.

Princip a postup práce geoDNS je následující:

Určuje IP klienta, který poslal DNS dotaz, nebo IP rekurzivního DNS serveru, který se používá při zpracování klientského dotazu. Takové rekurzivní servery bývají většinou DNS poskytovatelů.
Podle IP klienta zjistí jeho zemi nebo region. K tomu se používají databáze GeoIP, kterých je dnes nespočet. Existují i dobré bezplatné varianty.
Na základě umístění klienta vrátí jeho IP adresu nejbližšího CDN serveru.

DNS server s funkcí geoDNS lze sestavit samostatně, ale je lepší použít hotová řešení se sítí DNS serverů po celém světě a Anycast přímo z krabice:

ScloudDNS od $9.95/měsíc, tarif GeoDNS, defaultně je zde jeden DNS Failover
Zilore od $25/měsíc, zahrnuto DNS Failover
Amazon Route 53 od 35 $/měsíc za čistých 50M geo-dotazů. DNS Failover je účtován zvlášť
DNS Made Easy od 125 $/měsíc, 10 DNS Failover je k dispozici
Cloudflare, funkce „Geo Steering“ je dostupná v tarifních plánech Enterprise

Při objednávání geoDNS je třeba věnovat pozornost počtu zahrnutých dotazů v tarifu a vzít v úvahu, že skutečný počet požadavků na doménu může výrazně překročit očekávání. Miliony robotů, skenerů, spammerů a jiné nepříjemnosti pracují neúnavně.

Téměř všechny DNS služby zahrnují v ceně nezbytnou službu pro vytváření CDN — DNS Failover. S její pomocí můžete nastavit monitoring funkčnosti svých serverů a v případě absence jakýchkoliv známek života automaticky měnit v DNS odpovědích adresu nefunkčního serveru na záložní.

Pro vytvoření našeho CDN použijeme ClouDNS, tarif GeoDNS.

Přidáme v uživatelském rozhraní novou DNS zónu a uvedeme svou doménu. Pokud budeme CDN vytvářet na subdoméně a hlavní doména už je používána, nezapomeňte ihned po přidání zóny přidat existující funkční DNS záznamy. Dalším krokem je vytvoření několika A-záznamů pro CDN doménu/subdoménu, z nichž každý bude použit pro určený region. Jako regiony můžete uvést kontinenty nebo země, pro USA a Kanadu jsou k dispozici subregiony.

V našem případě bude CDN spuštěn na subdoméně cdn.sayt.in. Přidáním zóny sayt.in, vytvoříme pro subdoménu první A-záznam a nasměrujeme celou Severní Ameriku na server v Chicagu:

Opakujeme tuto akci pro další regiony, nezapomeňte vytvořit jeden záznam pro výchozí regiony. Takhle to nakonec dopadne:

Poslední výchozí záznam na screenshotu znamená, že všechny nezadané regiony (tedy Evropa, Afrika, uživatelé satelitního internetu atd.) budou směrovány na server ve Frankfurtu.

Tímto je základní nastavení DNS dokončeno. Zbývá se přihlásit na web registrátora domény a vyměnit aktuální NS domény za ty, které vydal ClouDNS. A zatímco se NS aktualizují, připravíme servery.

Instalace SSL certifikátů

Náš CDN bude fungovat přes HTTPS, proto pokud již máte SSL certifikáty pro doménu nebo subdoménu, nahrajte je na všechny servery, například do adresáře /etc/ssl/вашдомен/

Pokud certifikáty nemáte, můžete získat bezplatné od Let’s Encrypt. K tomu se skvěle hodí ACME Shell script. Klient je pohodlný a snadný na nastavení, a především umožňuje provádět ověření domény/subdomény prostřednictvím DNS přes API od ClouDNS.

Nainstalujeme acme.sh pouze na jednom ze serverů — evropském 199.247.18.199, ze kterého budou certifikáty kopírovány na všechny ostatní. Pro instalaci spusťte:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

Během instalace skriptu bude vytvořeno CRON úkol pro další aktualizaci certifikátů bez naší účasti.

Ověření domény při vydání certifikátu bude prováděno přes DNS pomocí API, proto je potřeba v osobním kabinetu ClouDNS v nabídce Reseller API vytvořit nového API uživatele a nastavit mu heslo. Získaný auth-id s heslem zapíšeme do souboru ~/.acme.sh/dnsapi/dns_cloudns.sh (neplést se souborem dns_clou– perioda anténní mřížky (vzdálenost mezi sousedními prvky),dns.sh). Zde jsou řádky, které je třeba odkomentovat a upravit:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Nyní požádáme o získání SSL certifikátu pro cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

V parametrech jsme pro budoucnost uvedli příkaz pro automatické obnovení konfigurace webového serveru po každé aktualizaci platnosti certifikátu v budoucnu.

Celý proces získání certifikátu může trvat až 2 minuty, nepřerušujte ho. Pokud dojde k chybě ověření domény, zkuste příkaz spustit znovu. Na konci uvidíme, kam byly certifikáty uloženy:

Zapamatujeme si tyto cesty, budou potřebné při kopírování certifikátu na další servery, stejně jako v nastavení webového serveru. Na chybu při znovu načítání konfigurací Nginx nevěnujeme pozornost — na plně nakonfigurovaném serveru při aktualizaci certifikátů se neobjeví.

Vše, co nám zbývá ohledně SSL, je zkopírovat získaný certifikát na dva další servery se zachováním cesty k souborům. Vytvoříme na každém z nich stejné adresáře a provedeme kopii:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Aby bylo aktualizace certifikátů pravidelné, vytvoříme na obou serverech denní CRON úkol s příkazem:

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Přitom přístup k vzdálenému zdrojovému serveru musí být nastaven pomocí klíče, t.j. bez zadání hesla. Nezapomeňte to udělat.

Instalace a nastavení Nginx

Pro dodávání statického obsahu budeme používat Nginx, nakonfigurovaný jako cache proxy server. Aktualizujeme seznamy balíčků a nainstalujeme ho na všechny tři servery:

root@cdn:~# apt update
root@cdn:~# apt install nginx

Místo výchozího použijeme konfiguraci z níže uvedeného spoileru:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;

    proxy_temp_path /var/cache/tmp;
    proxy_cache_path /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

V konfiguraci upravíme:

max_size — maximální velikost cache, která nepřesahuje dostupné místo na disku
inactive — doba uchování cacheovaných dat, ke kterým nikdo nepřistupoval
ssl_certificate a ssl_certificate_key — cesty k souborům SSL certifikátu a klíče
proxy_cache_valid — doba uchování cacheovaných dat
proxy_pass — adresa originálního serveru, ze kterého CDN bude požadovat soubory pro caching. V našem příkladu je to sayt.in

Jak vidíme, je vše jednoduché. Složitost může nastat pouze při nastavení doby cachování kvůli podobnosti direktiv. inactive a proxy_cache_validPodíváme se na ně na našem příkladu. Tady je, co se děje při inactive=7d a proxy_cache_valid 90d:

pokud se požadavek neopakuje po dobu 7 dní, data budou odstraněna z cache po uplynutí tohoto období
pokud se požadavek bude opakovat alespoň jednou za 7 dní, data v cache budou považována za zastaralá po uplynutí 90 dní a při příštím požadavku Nginx je aktualizuje, vezme je z originálního serveru.

Po dokončení úprav nginx.conf, zrestartujeme konfiguraci:

root@cdn:~# service nginx reload

Náš CDN je plně připraven. Za $15/měsíc jsme získali přístupový bod na třech kontinentech a 3 TB provozu: po 1 TB v každé lokalitě.

Kontrolujeme funkci CDN

Podíváme se na pingly k našemu CDN z různých geografických lokalit. K tomu se hodí jakékoli pingovací služby.

Startovní bod
Hostitel
IP
Avg čas, ms

Německo, Berlín
cdn.sayt.in
199.247.18.199
9.6

Nizozemsko, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francie, Paříž
cdn.sayt.in
199.247.18.199
16.3

Velká Británie, Londýn
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

USA, San Francisco
cdn.sayt.in
149.28.121.123
52.7

USA, Dallas
cdn.sayt.in
149.28.121.123
23.1

USA, Chicago
cdn.sayt.in
149.28.121.123
2.6

USA, New York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Japan, Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Výsledky jsou dobré. Teď umístíme zkušební obrázek do kořenového adresáře hlavního webu. test.jpg a zkontrolujeme rychlost jeho načítání přes CDN. Řekl jsem, — provedeno. Obsah se rychle načítá.

Napíšeme malý skript pro případ, že bychom chtěli vyčistit keš na CDN bodě.
purge.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

Pro odstranění celé keše stačí spustit ho, samostatný soubor lze vyčistit takto:

root@cdn:~# ./purge.sh /test.jpg

Nam místo výstupů

Nakonec chci poskytnout několik užitečných rad, abych se vyhnul překážkám, které mi způsobily bolesti hlavy:

Pro zvýšení odolnosti CDN se doporučuje nastavit DNS Failover, který pomáhá rychle změnit A záznam v případě poruchy serveru. Provádí se to v ovládacím panelu DNS záznamů domény.
Weby s širokým geografickým pokrytím bezpochyby vyžadují velké množství CDN bodů, ale pojďme na to bez přehánění. Pravděpodobně si uživatel nevšimne podstatného rozdílu ve srovnání s placeným CDN, pokud umístíte servery na 6-7 místech: Evropa, Severní Amerika (východ), Severní Amerika (západ), Singapur, Austrálie, Hongkong nebo Japonsko.
Někdy poskytovatelé hostingu neumožňují používání pronajatých serverů pro účely CDN. Proto, pokud se náhodou rozhodnete rozšířit síť pro doručování obsahu jako službu, nezapomeňte si nejprve přečíst pravidla konkrétního poskytovatele hostingu.
Prostudujte mapu podmořských komunikačních sítí, abyste měli představu, jak jsou kontinenty propojeny a řídili se tím při budování sítě pro doručování obsahu.
Zkuste zkontrolovat pingy z různých míst na vaše servery. Takto můžete vidět nejbližší regiony k CDN bodům a správněji nastavit GeoDNS.
V závislosti na úkolech nebude na škodu doladit Nginx podle konkrétních požadavků na kešování a s ohledem na zátěž serveru. V tomto mi velmi pomohly články o keši Nginx — zde a zrychlení provozu při vysokých zátěžích: zde a zde