🥇Összeállítjuk és beállítjuk a saját CDN-ünket

A tartalomkézbesítő hálózatok (CDN) weboldalakon és alkalmazásokban főként a statikus elemek betöltésének felgyorsítására szolgálnak. Ez a fájlok CDN szervereken való gyorsítótárazásának következménye, amelyek különböző földrajzi régiókban találhatók. Amikor a felhasználó adatokat kér a CDN-en keresztül, azokat a legközelebbi szerverről kapja meg.

A működési elv és a funkciók minden tartalomkézbesítő hálózat esetén körülbelül azonosak. Amikor a CDN szerver fájlbetöltési kérést kap, egyszeri alkalommal letölti azt az eredeti szerverről, majd a felhasználónak átadja, közben pedig a meghatározott időtartamra gyorsítótárazza. Minden további kérésre a válasz a gyorsítótárból érkezik. Minden CDN rendelkezik fájlok előzetes betöltési opcióival, a gyorsítótár törlésének lehetőségével, a tárolási idő beállításával és még sok mással.

Előfordul, hogy különböző okok miatt saját tartalomkézbesítő hálózat létrehozása válik szükségessé, és ebben az esetben — íme a hasznos útmutató a következő kerékpár összeszereléséhez.

Forrás: Az infografika vektort a pikisuperstar készítette — www.freepik.com

Mikor szükséges saját CDN

Nézzük meg azokat az eseteket, amikor értelme van saját CDN indításának:

amikor szeretnénk megtakarítani, és a meglévő költségek még a kedvező árú CDN-ek, például BunnyCDN esetén is több száz dollárt tesznek ki havonta
ha állandó gyorsítótárat szeretnénk kapni, vagy gyorsítótárat anélkül, hogy szomszédaink lennének a szerveren és a csatornán
amennyiben a szükséges régióban a CDN szolgáltatóknak nincsenek jelenléti pontjaik
ha különleges beállításokra van szükség a tartalom kézbesítéséhez
ha fel szeretnénk gyorsítani a dinamikus tartalom kézbesítését, úgy, hogy a termelési szervereket közelebb helyezzük a felhasználókhoz
ha aggódunk amiatt, hogy egy külső CDN szolgáltatás jogellenesen gyűjtheti vagy használhatja a felhasználói viselkedéssel kapcsolatos információkat (üdvözöljük a GDPR-nak nem megfelelő szolgáltatásokat) vagy jogellenes tevékenységeket folytathat

A legtöbb egyéb esetben ésszerűbb meglévő, kész megoldásokat használni.

Mi szükséges az indításhoz

Kiváló, ha van saját autonóm rendszered (AS). Ezzel ugyanazt az IP-t rendelhetsz több szerverhez, és ezen útmutató alapján a hálózat szintjén irányíthatod a felhasználókat a legközelebbihez. Érdemes megjegyezni, hogy akár egy /24-es címblokkal is lehet tartalomkézbesítő hálózatot építeni. Néhány szerver szolgáltató lehetővé teszi a bejelentést az általuk elérhető összes régió számára.

Ha nem rendelkezik IP-cím blokkal, a CDN egyszerű elindításához a következőkre lesz szüksége:

domain név vagy aldomain
legalább két szerver különböző régiókban. A szerver lehet dedikált vagy virtuális
geoDNS eszköz. Ezzel a felhasználó, aki a domainhez fordul, a legközelebbi szerverre lesz irányítva

Regisztráljunk egy domaint és rendeljünk szervereket

A domain regisztrálása egyszerű — bármely zónában bármely regisztrátornál regisztrálhat. A CDN-hez aldomain is használható, például valami ilyesmi: cdn.aredomain.com. A példánkban így is fogunk eljárni.

A szerverek megrendelésénél érdemes azokat olyan régiókban és országokban bérelni, ahol a felhasználói közönség található. Ha a projekt interkontinentális, érdemes olyan hosztingszolgáltatókat választani, amelyek világszerte kínálnak szervereket. Példák: OVH, Leaseweb és 100Tb — a dedikált szerverekhez, Vultr és DigitalOcean — a virtuális felhőkhöz*.

A privát CDN-ünk számára 3 virtuális szervert rendelünk különböző kontinenseken. A Vultr szerverünk $5/hó helyet és 25GB SSD 1TB forgalmat kapunk. Telepítéskor válasszuk a legújabb Debian verziót. A szervereink:, ip: 199.247.18.199

Frankfurt, ip: 149.28.121.123

Chicago, ip: 157.230.240.216

Szingapúr* A Vultr és a DigitalOcean $100 kredit ígér a cikkben megadott linkekre regisztráló felhasználóknak, azonnal a fizetési mód hozzáadását követően. A szerző is kap egy kis jutalékot ebből, ami számára nagyon jelentős. Kérjük, legyenek megértőek.

Beállítjuk a geoDNS-t

Ahhoz, hogy a felhasználó, amikor a CDN domainhez vagy aldomainhez fordul, a megfelelő (legközelebbi) szerverre legyen irányítva, szükségünk van egy DNS szerverre geoDNS funkcióval.

A geoDNS működési elve és folyamata a következő:

Azonosítja a DNS-kérést benyújtó kliens IP-címét vagy a rekurszív DNS-szerver IP-címét, amelyet a kliens kérésének feldolgozásához használnak. Ezek a rekurszív szerverek általában a szolgáltatók DNS-ei.

A kliens IP-címéből megtudja az országát vagy régióját. Ehhez GeoIP adatbázisokat használnak, amelyek ma már rengeteg létezik. Van néhány
jó ingyenes lehetőség A kliens tartózkodási helyétől függően a legközelebbi CDN szerver IP-címét adja vissza..
A geoDNS funkcióval rendelkező DNS szerver

, de jobb, ha kész megoldásokat használunk világszerte DNS-szerver hálózattal és saját magunk is összeállíthatjukAnycast out-of-the-box: ClouDNS

$9.95/hó tól , GeoDNS tarifával, alapértelmezetten van egy DNS FailoverZilore
$25/hó tól , be van kapcsolva a DNS Failover, bekapcsolva a DNS Failover
Amazon Route 53 tól $35/hó 50M geokérésért. A DNS Failover külön díjat von maga után
DNS Made Easy tól $125/hó, van 10 DNS Failover
Cloudflare, a „Geo Steering” funkció a vállalati tarifákban érhető el

A geoDNS megrendelésekor figyelembe kell venni a tarifában foglalt kérések számát, és azt is, hogy a domainre érkező tényleges kérések száma többszöröse lehet a vártnak. Milliók dolgoznak folyamatosan, például robotok, szkennerek, spammer-ek és egyéb nem kívánt látogatók.

Szinte az összes DNS-szolgáltatás díjába beleértendő egy elengedhetetlen CDN-hez szükséges szolgáltatás — a DNS Failover. Ezzel beállítható a szerverek működésének figyelése, és ha egy szerver nem válaszol, a DNS- válaszokban automatikusan a nem működő szerver címét egy tartalék szerver címére cserélhetjük.

CDN-ünk létrehozásához használni fogjuk ClouDNS, GeoDNS tarifa.

Hozzáadunk egy új DNS-zónát a személyes fiókunkban, megadva a saját domainünket. Ha a CDN-t egy aldomainen építjük fel, míg a fődomain már használatban van, ne felejtse el a meglévő működő DNS-bejegyzéseket is hozzáadni a zóna hozzáadása után. A következő lépés a CDN domainéhez/aldomainjéhez több A-bejegyzés létrehozása, amelyeket a megadott régióhoz rendelünk. Régióként kontinensek vagy országok is megadhatók, az Egyesült Államok és Kanada számára elérhetők az alrégiók.

A mi esetünkben a CDN egy aldomainen fog működni cdn.sayt.in. A zóna hozzáadása után sayt.in, létrehozzuk az első A-bejegyzést az aldomainhez, és az amerikai kontinens egészét a chicagói szerverre irányítjuk:

Megismételjük a lépést más régiók számára, ne feledkezve meg egy bejegyzés létrehozásáról az alapértelmezett régiókhoz. Íme, ami a végeredmény:

Az utolsó alapértelmezett bejegyzés a képernyőképen azt jelenti, hogy minden nem megadott régiós felhasználó (például Európa, Afrika, műholdas internetfelhasználók stb.) a frankfurti szerverre lesz irányítva.

Ezzel befejeződött a DNS alapbeállítása. Még annyit kell tenni, hogy belépünk a domain regisztrátor weboldalára, és a domain jelenlegi NS-ait kicseréljük azokra, amelyeket a ClouDNS adott. Amíg az NS-ek frissülnek, előkészítjük a szervereket.

SSL tanúsítványok telepítése

A CDN-ünk HTTPS-en fog működni, ezért ha már rendelkezel SSL tanúsítványokkal a domainek vagy az aldomainek számára, töltsd fel őket minden szerverre, például a következő könyvtárba: /etc/ssl/вашдомен/

Ha nincsenek tanúsítványok, ingyenesen beszerezhetők a Let’s Encrypt-től. Erre jól megfelel a ACME Shell script. Az ügyfél kényelmes és egyszerű a beállításban, ami a legfontosabb — lehetővé teszi a domain/subdomain DNS validálását a ClouDNS API-n keresztül.

Az acme.sh-t csak az egyik szerverre telepítjük — az európai 199.247.18.199-re, ahonnan a tanúsítványok minden másikra át lesznek másolva. A telepítéshez hajtsuk végre:

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

A szkript telepítése során CRON feladatot hozunk létre a tanúsítványok további frissítéséhez a mi részvételünkből.

A tanúsítvány kiadásakor a domain ellenőrzése DNS-en keresztül, API használatával fog megtörténni, ezért a ClouDNS ügyfélportálján a Reseller API menüben új API felhasználót kell létrehoznunk, és meg kell adni jelszót számára. Az auth-id-t a jelszóval a fájlban rögzítjük. ~/.acme.sh/dnsapi/dns_cloudns.sh (ne keverjük össze a fájllal, dns_clouddns.sh). Íme a sorok, amelyeket ki kell kommentálni és szerkeszteni kell:

CLOUDNS_AUTH_ID=auth-id
CLOUDNS_AUTH_PASSWORD="jelszó"

Most kérjük el az SSL tanúsítványt a következőhöz: cdn.sayt.in

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

A paraméterek között a jövőben megadtuk a parancsot a webkiszolgáló konfigurációjának automatikus újratöltésére a tanúsítvány lejárati idejének minden frissítése után.

A tanúsítvány megszerzésének folyamata akár 2 percig is eltarthat, ne szakítsa meg. Ha domain validációs hiba merül fel, próbálja meg újra futtatni a parancsot. A végén látni fogjuk, hová töltötték fel a tanúsítványokat:

Ezeket az utakat jegyezzük meg, mert ezeket meg kell adnunk a tanúsítvány más szerverekre másolásakor, és a webkiszolgáló beállításaiban is. Az Nginx konfigurációinak újratöltésekor fellépő hibákat ne vegyük figyelembe — teljesen konfigurált szerveren a tanúsítványok frissítésekor nem fog előfordulni.

Minden, ami hátra van az SSL-hez, az a megszerzett tanúsítvány másolása két másik szerverre a fájlok útvonalának megőrzésével. Hozzunk létre mindkettőn hasonló könyvtárakat, és készítsünk másolatot:

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/

Ahhoz, hogy a tanúsítványok frissítése rendszeres legyen, mindkét szerveren hozzunk létre napi CRON feladatot a következő paranccsal:

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

Eközben a távoli forrás-szerverhez való hozzáférésnek be kell állítva lennie kulcs által, azaz jelszó megadása nélkül. Ne felejtsen el ezt megtenni.

Nginx telepítése és beállítása

Statikus tartalom szolgáltatásához Nginx-et fogunk használni, amelyet gyorsítótárazó proxy-szerverként konfigurálunk. Frissítjük a csomaglistákat, és telepítjük az összes három szerverre:

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

A default helyett az alábbi konfigurációt használjuk:
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;
    }
  }
}

A konfigurációban módosítjuk:

max_size — a gyorsítótár mérete, amely nem haladhatja meg a lemezen elérhető helyet
inactive — azoknak a gyorsítótárazott adatoknak az eltávolítási ideje, amelyeket senki sem kért
ssl_certificate és ssl_certificate_key — az SSL tanúsítvány és az azt kísérő kulcs fájlok elérési útjai
proxy_cache_valid — a gyorsítótárazott adatok eltávolítási ideje
proxy_pass — az eredeti szerver címe, ahonnan a CDN fájlokat kérdez le a gyorsításhoz. A példa alapján ez sayt.in

Ahogy látjuk, minden egyszerű. A kihívások a gyorsítótár időzítési beállításaiban adódhatnak, mivel a direktívák hasonlóak. inactive és proxy_cache_validEzért bemutatjuk őket a példánkon. Íme, mi történik a következőkkel: inactive=7d és proxy_cache_valid 90d:

ha a kérés 7 napig nem ismétlődik, az adatok eltávolításra kerülnek a gyorsítótárból a periódus letelte után
ha a kérés legalább egyszer 7 napon belül megismétlődik, akkor az adatok a gyorsítótárban 90 nap elteltével elavultnak minősülnek, és a következő kéréskor az Nginx frissíti őket, az eredeti szerverről véve őket

A szerkesztés befejezése után nginx.conf, újraindítjuk a konfigurációt:

root@cdn:~# service nginx reload

A CDNünk teljesen készen áll. $15/hóért három kontinensen kaptunk jelenlétet és 3 TB forgalmat: 1 TB-t minden helyszínen.

A CDN működését ellenőrizzük.

Nézzük meg a pingeket a CDN-ünkről különböző földrajzi helyekről. Ehhez bármilyen ping-szolgáltatás megfelelő.

Indító pont
Gazda
IP
Átlagos idő, ms

Németország, Berlin
cdn.sayt.in
199.247.18.199
9.6

Hollandia, Amszterdam
cdn.sayt.in
199.247.18.199
10.1

Franciaország, Párizs
cdn.sayt.in
199.247.18.199
16.3

Egyesült Királyság, London
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

Szingapúr
cdn.sayt.in
157.230.240.216
1.7

Japán, Tokió
cdn.sayt.in
157.230.240.216
74.8

Ausztrália, Sydney
cdn.sayt.in
157.230.240.216
95.9

Az eredmények jók. Most egy tesztképet helyezünk el a főoldalon. test.jpg és ellenőrizzük a CDN-en keresztüli betöltési sebességét. Megjegyezve, — történt. A tartalom gyorsan érkezik.

Írunk egy kis scriptet arra az esetre, ha a CDN ponton want cache-t törölni.
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

A teljes cache törléséhez elegendő egyszerűen futtatni, külön fájlt pedig így lehet tisztítani:

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

Összegzések helyett

Végül szeretnék néhány hasznos tanácsot adni, hogy azonnal elkerüljük azokat a csapdákat, amelyek nekem egykor fejfájást okoztak:

A CDN megbízhatóságának növeléséhez érdemes DNS Failover-t beállítani, amely segít gyorsan módosítani az A rekordot a szerver meghibásodása esetén. Ezt a domain DNS rekordok kezelőpanelén lehet végezni.
A széles földrajzi lefedettségű weboldalak kétségtelenül sok CDN pontot igényelnek, de ne essünk túlzásba. Valószínűleg a felhasználó nem fog észrevenni jelentős különbséget a fizetős CDN-hez képest, ha 6-7 helyen helyezed el a szervereket: Európa, Észak-Amerika (kelet), Észak-Amerika (nyugat), Szingapúr, Ausztrália, Hongkong vagy Japán.
Néha a tárhelyszolgáltatók nem engedik meg bérelt szerverek használatát CDN célokra. Tehát ha véletlenül úgy döntesz, hogy tartalomszolgáltató hálózatot indítasz, ne felejtsd el előre elolvasni a konkrét tárhelyszolgáltató szabályait.
Tanulmányozd az underwater communications mapot, hogy tudomásod legyen arról, hogyan kapcsolódnak a kontinensek, és ezt figyelembe vedd a tartalomszolgáltató hálózat kiépítésekor.
Próbáld meg ellenőrizni a pingeket különböző helyekről a szervereidhez. Így láthatod a CDN pontokhoz legközelebbi régiókat, és pontosabban beállíthatod a GeoDNS-t.
A feladatoktól függően hasznos lehet az Nginx beállítása a konkrét cache igényekhez és a szerver terhelésének figyelembevételével. Ebben sokat segítettek nekem az Nginx cache-ről szóló cikkek — itt és a teljesítmény javítása nagy terhelés esetén: itt és itt