ProHoster > Blog > Adminisztráció > A CDN felépítése és konfigurálása

A CDN felépítése és konfigurálása

A tartalomszolgáltató hálózatokat (CDN) a webhelyeken és alkalmazásokban elsősorban a statikus elemek betöltésének felgyorsítására használják. Ez a különböző földrajzi régiókban található CDN-kiszolgálókon található fájlok gyorsítótárazása miatt történik. A CDN-en keresztüli adatkéréssel a felhasználó azt a legközelebbi szervertől kapja meg.

Az összes tartalomszolgáltató hálózat működési elve és funkcionalitása megközelítőleg azonos. Miután megkapta a fájl letöltésére vonatkozó kérést, a CDN-kiszolgáló egyszer átveszi azt az eredeti szervertől, és átadja a felhasználónak, egyúttal meghatározott ideig gyorsítótárazva. Minden további kérésre a gyorsítótárból válaszolunk. Minden CDN rendelkezik a fájlok előtöltésével, a gyorsítótár törlésével, a lejárati dátum beállításával stb.

Előfordul, hogy valamilyen okból kifolyólag saját tartalomszolgáltató hálózatot kell megszerveznie, majd - legyen a segítségünkre a következő kerékpár összeszerelési útmutatója.

A CDN felépítése és konfigurálása
Forrás: Infographic vektor által készített pikisuperstar - www.freepik.com

Amikor saját CDN-re van szüksége

Fontolja meg azokat az eseteket, amikor van értelme saját CDN futtatásának:

  • ha van vágy pénzt megtakarítani és üzemeltetési költségeket még akkor is, ha olcsó CDN-eket használ, mint pl BunnyCDN havi több száz dollárt tesz ki
  • ha állandó gyorsítótárat vagy szerver- és csatornaszomszédok nélküli gyorsítótárat szeretnénk kapni
  • A CDN-szolgáltatások nem rendelkeznek jelenléti pontokkal a kívánt régióban
  • bármilyen speciális tartalomszolgáltatási beállítás szükséges
  • fel akarjuk gyorsítani a dinamikus tartalom kézbesítését azáltal, hogy az éles szervert közelebb helyezzük a felhasználókhoz
  • aggodalomra ad okot, hogy egy harmadik fél CDN-szolgáltatása illegálisan gyűjthet vagy használhat fel információkat a felhasználói viselkedésről (hello, nem GDPR-kompatibilis szolgáltatások), vagy más illegális tevékenységet folytathat

A legtöbb esetben célszerűbb a meglévő kész megoldások alkalmazása.

Mit kell kezdeni

Csodálatos, ha van saját autonóm rendszere (AS). Ezzel több szerverhez is hozzárendelheti ugyanazt az IP-t és ennek az utasításnak megfelelően hálózati szinten irányítsa a felhasználókat a legközelebbihez. Érdemes elmondani, hogy a /24-es címblokk segítségével is lehet tartalomszolgáltató hálózatot kiépíteni. Egyes szerverszolgáltatók lehetővé teszik, hogy bejelentést tegyen a számukra elérhető összes régióban.

Ha nem boldog tulajdonosa egy IP-cím blokkjának, akkor egy egyszerű CDN futtatásához szüksége lesz:

  • 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ó, miután megcímezte a domaint, a legközelebbi szerverre kerül

Regisztráljon egy domaint és rendeljen szervereket

A domain regisztrációval minden egyszerű - bármely zónában regisztrálunk bármely regisztrátornál. Aldomaint is használhat CDN-hez, például valami hasonlót cdn.domainname.com. Valójában a mi példánkban ezt fogjuk tenni.

Ami a szerverek megrendelését illeti, azokat azokban a régiókban és országokban kell bérelni, ahol a felhasználói közönség található. Ha a projekt interkontinentális, akkor kényelmes olyan tárhelyszolgáltatókat választani, amelyek egyszerre kínálnak szervereket az egész világon. Példák: OVH, bérleti web и 100Tb - dedikált szerverekhez, Vultr и DigitalOcean — virtuális felhőhöz*.

Privát CDN-ünkhöz 3 virtuális szervert rendelünk különböző kontinenseken. Nál nél Vultr a szerveren 5 USD/hó fogunk kapni 25GB SSD helyek és 1 TB forgalom. Telepítéskor válassza ki a legújabb Debiant. Szervereink:

A CDN felépítése és konfigurálása Frankfurt, ip: 199.247.18.199

A CDN felépítése és konfigurálása Chicago, ip: 149.28.121.123

A CDN felépítése és konfigurálása Singapore, ip: 157.230.240.216

* A Vultr és a DigitalOcean 100 dolláros jóváírást ígér azoknak a felhasználóknak, akik közvetlenül a fizetési mód hozzáadása után regisztrálnak a cikkben található hivatkozásokon keresztül. A szerző ettől is kap egy kis dicséretet, ami most nagyon jelentős a számára. Kérem, legyen megértő.

A geoDNS beállítása

Ahhoz, hogy a felhasználót a kívánt (legközelebbi) szerverre irányítsuk egy tartomány vagy CDN aldomain elérésekor, szükségünk van egy geoDNS funkcióval rendelkező DNS szerverre.

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

  1. Megadja a DNS-kérelmet küldő ügyfél IP-címét, vagy az ügyfélkérelem feldolgozásakor használt rekurzív DNS-kiszolgáló IP-címét. Az ilyen rekurzív szerverek általában szolgáltatók DNS-ei.
  2. Az ügyfél IP-je felismeri országát vagy régióját. Ehhez a GeoIP adatbázisokat használják, amelyekből ma már nagyon sok van. Vannak jók ingyenes opciók.
  3. Az ügyfél helyétől függően adja meg a legközelebbi CDN-kiszolgáló IP-címét.

A geoDNS funkcióval rendelkező DNS szerver lehet összeszerelni egyedül, de érdemesebb már kész megoldásokat használni DNS szerverek hálózatával szerte a világon és anycast a dobozból:

  • CloudDNS -tól 9.95 USD/hó, GeoDNS tarifa, alapértelmezés szerint egy DNS feladatátvétel van
  • Zilore -tól 25 USD/hó, DNS feladatátvétel engedélyezve
  • Amazon út 53 -tól 35 USD/hó nettó 50 millió földrajzi kéréshez. A DNS feladatátvétel külön számlázható
  • A DNS egyszerűvé vált -tól 125 USD/hó, 10 DNS-hibaátvétel létezik
  • CloudFlare, A „Geo Steering” funkció elérhető a vállalati tervekben

A geoDNS megrendelésekor ügyeljen a tarifában szereplő kérések számára, és tartsa szem előtt, hogy a domainre irányuló kérések tényleges száma a várakozások többszörösét is meghaladja. Pókok, szkennerek, spammerek és más gonosz szellemek milliói dolgoznak fáradhatatlanul.

Szinte minden DNS-szolgáltatás tartalmaz egy nélkülözhetetlen szolgáltatást a CDN felépítéséhez - DNS-átvétel. Segítségével beállíthatja szerverei működésének felügyeletét, és életjelek hiányában a DNS-válaszokban automatikusan lecserélheti egy nem működő szerver címét egy tartalék címre.

A CDN felépítéséhez használjuk CloudDNS, GeoDNS tarifa.

Adjunk hozzá egy új DNS-zónát személyes fiókjához, megadva a domainjét. Ha aldomainre építünk CDN-t, és a fő tartomány már használatban van, akkor a zóna hozzáadása után azonnal ne felejtse el hozzáadni a meglévő működő DNS rekordokat. A következő lépés több A-rekord létrehozása a CDN-tartományhoz/aldomainhez, amelyek mindegyike az általunk megadott régióra lesz alkalmazva. Régióként kontinenseket vagy országokat adhat meg, alrégiók az USA és Kanada számára érhetők el.

Esetünkben a CDN egy aldomainre kerül fel cdn.sayt.in. Zóna hozzáadásával mondt.in, hozza létre az első A-rekordot az aldomainhez, és irányítsa egész Észak-Amerikát a chicagói szerverre:

A CDN felépítése és konfigurálása
Ismételjük meg a műveletet más régiókra, ne felejtsük el létrehozni egy bejegyzést az alapértelmezett régiókhoz. Íme, mi történik a végén:

A CDN felépítése és konfigurálása

A képernyőképen az utolsó alapértelmezett bejegyzés azt jelenti, hogy minden meg nem határozott régió (ezek Európa, Afrika, műholdas internet-felhasználók stb.) a frankfurti szerverre kerül.

Ezzel befejeződik az alapvető DNS-beállítás. Továbbra is fel kell keresni a domain regisztrátor webhelyét, és le kell cserélni a jelenlegi domain NS-eket a ClouDNS által kibocsátottakra. És amíg az NS-ek frissítésre kerülnek, mi felkészítjük a szervereket.

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

CDN-ünk HTTPS-en keresztül fog működni, tehát ha már rendelkezik SSL-tanúsítvánnyal egy domainhez vagy aldomainhez, töltse fel azokat az összes szerverre, például a címtárba. /etc/ssl/yourdomain/

Ha nincsenek tanúsítványok, ingyenesen szerezhet be egyet a Let's Encrypt szolgáltatásból. Erre tökéletes ACME Shellscript. A kliens kényelmes és könnyen beállítható, és ami a legfontosabb, lehetővé teszi a domain/aldomain DNS általi érvényesíté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, amelyről a tanúsítványokat az összes többire másoljuk. A telepítéshez futtassa:

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

A szkript telepítése során egy CRON munka jön létre a tanúsítványok további megújítására a részvételünk nélkül.

Tanúsítvány kiadásakor a domain ellenőrzése DNS segítségével történik az API segítségével, így a ClouDNS személyes fiókban a Viszonteladói API menüben létre kell hozni egy új felhasználói API-t és be kell állítani hozzá egy jelszót. A kapott hitelesítési azonosító jelszóval be lesz írva a fájlba ~/.acme.sh/dnsapi/dns_cloudns.sh (nem tévesztendő össze a fájllal dns_clouddns.sh). Íme a megjegyzések törlése és szerkesztése szükséges sorok:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

Most SSL-tanúsítványt fogunk kérni ehhez cdn.sayt.in

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

Az opcióknál a jövőre vonatkozóan megadtunk egy parancsot, amely automatikusan újratölti a webszerver konfigurációját a tanúsítvány érvényességi időszakának minden jövőbeni megújítása után.

A tanúsítvány megszerzésének teljes folyamata akár 2 percig is eltarthat, ne szakítsa meg. Ha tartományérvényesítési hiba lép fel, próbálja meg újra futtatni a parancsot. A végén látni fogjuk, hova lettek feltöltve a tanúsítványok:

A CDN felépítése és konfigurálása

Ne felejtse el ezeket az elérési utakat, ezeket meg kell adni a tanúsítvány más szerverekre másolásakor, valamint a webszerver beállításaiban. Nem figyelünk az Nginx konfigurációk újratöltésének hibájára - a tanúsítványok frissítésekor nem lesz teljesen konfigurált szerveren.

Az SSL-hez csak annyi maradt, hogy a kapott tanúsítványt két másik szerverre másoljuk, miközben a fájlok elérési útját megtartjuk. Hozzuk létre mindegyiken ugyanazokat a könyvtárakat, és készítsünk másolatot:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

A tanúsítványok rendszeres frissítéséhez hozzon létre egy napi CRON-feladatot mindkét szerveren a következő paranccsal:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Ebben az esetben a távoli forráskiszolgálóhoz való hozzáférést konfigurálni kell kulccsal, azaz jelszó megadása nélkül. Ne felejtsd el megtenni.

Az Nginx telepítése és konfigurálása

A statikus tartalom kiszolgálásához a gyorsítótárazó proxyszerverként konfigurált Nginxet fogjuk használni. Frissítse a csomaglistákat, és telepítse mindhárom kiszolgálóra:

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

Az alapértelmezett helyett az alábbi spoiler konfigurációjá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;
    }
  }
}

Szerkessze a konfigurációban:

  • max_size — a gyorsítótár mérete, amely nem haladja meg a rendelkezésre álló lemezterületet
  • tétlen - a gyorsítótárazott adatok tárolási ideje, amelyekhez senki sem fér hozzá
  • ssl_certificate и ssl_certificate_key — az SSL-tanúsítvány- és kulcsfájlok elérési útja
  • proxy_cache_valid - a gyorsítótárazott adatok tárolási ideje
  • proxy_pass — annak az eredeti szervernek a címe, amelyről a CDN fájlokat kér a gyorsítótárazáshoz. Példánkban ez mondt.in

Amint látja, minden egyszerű. Nehézség csak a gyorsítótárazási idő beállításánál adódhat az irányelvek hasonlósága miatt tétlen и proxy_cache_valid. Elemezzük őket példánkkal. Íme, mi történik, amikor inaktív=7d и proxy_cache_valid 90d:

  • ha a kérés 7 napon belül nem ismétlődik meg, akkor ezen időszak letelte után az adatok törlésre kerülnek a gyorsítótárból
  • ha a kérés 7 naponta legalább egyszer megismétlődik, akkor a gyorsítótárban lévő adatok 90 nap elteltével elavultnak minősülnek, és az Nginx a következő kéréssel frissíti, átveszi az eredeti szerverről

A szerkesztés kész nginx.conf, töltse be újra a konfigurációt:

root@cdn:~# service nginx reload

CDN-ünk készen áll. 15 USD/hó áron. három kontinensen kaptunk jelenléti pontot és 3 TB forgalmat: 1 TB minden helyen.

A CDN működésének ellenőrzése

Nézzük meg a CDN-ünkre érkező pingeket különböző földrajzi helyekről. Bármely ping szolgáltatás működik erre.

Indítási pont
Házigazda
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

Nagy-Britannia, 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

Singapore
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ő webhely gyökerében test.jpg és ellenőrizze a letöltési sebességét a CDN-n keresztül. Azt mondják - készült. A tartalom gyorsan kézbesítve.

Írjunk egy kis szkriptet arra az esetre, ha ki akarjuk üríteni a CDN-pont gyorsítótárát.
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 gyorsítótár törléséhez csak futtassa, egy külön fájl tisztítható így:

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

Következtetések helyett

Végezetül szeretnék néhány hasznos tippet adni, hogy azonnal átléphessem a gereblyét, amitől akkor fájt a fejem:

  • A CDN hibatűrésének növelése érdekében javasolt a DNS-átvétel konfigurálása, amely segít az A rekord gyors megváltoztatásában kiszolgáló meghibásodása esetén. Ez a tartomány vezérlőpult DNS rekordjaiban történik.
  • A széles földrajzi lefedettséggel rendelkező webhelyek kétségtelenül nagyszámú CDN-t igényelnek, de ne legyünk fanatikusak. Valószínűleg a felhasználó nem észlel jelentős különbséget a fizetős CDN-hez képest, ha 6-7 helyen helyez el szervereket: Európában, Észak-Amerikában (kelet), Észak-Amerikában (nyugat), Szingapúrban, Ausztráliában, Hongkongban vagy Japánban.
  • Néha a tárhelyszolgáltatók nem engedélyezik a bérelt szerverek használatát CDN-célokra. Ezért, ha hirtelen úgy dönt, hogy tartalomszolgáltató hálózatot telepít szolgáltatásként, ne felejtse el előzetesen elolvasni egy adott tárhelyszolgáltató szabályzatát.
  • Fedezd fel víz alatti kommunikációs térképhogy a kontinensek hogyan kapcsolódnak egymáshoz, és ezt vegyék figyelembe a tartalomszolgáltató hálózat kiépítésénél
  • Próbáld ellenőrizni ping különböző helyekről a szervereidre. Így láthatja a CDN-pontokhoz legközelebb eső régiókat, és pontosabban konfigurálhatja a GeoDNS-t
  • A feladatoktól függően hasznos lesz az Nginx finomhangolása a konkrét gyorsítótárazási követelményekhez és a szerver terhelésének figyelembevételéhez. Az Nginx gyorsítótárról szóló cikkek sokat segítettek ebben - itt és a munka gyorsítása nagy terhelés mellett: itt и itt

Forrás: will.com