kép forrása: Infographic vector created by pikisuperstar — www.freepik.com

a tartalomszolgáltató hálózatokat (CDN) általában a webhelyek és alkalmazások használják a statikus elemek betöltésének felgyorsítására. Ez a fájlok gyorsítótárazásával érhető el a világ különböző régióiban található CDN szervereken. Miután adatokat kért CDN-n keresztül, a felhasználó megkapja azokat a legközelebbi szerverről.

a CDN-ek mögött meghúzódó alapelvek és azok funkcionalitása mindegyiknél megközelítőleg azonos. Miután megkapta a fájl iránti kérelmet, a CDN-kiszolgáló egyszer átveszi azt az eredeti szerverről, majd továbbítja a felhasználónak, és egy ideig gyorsítótárazza annak másolatát. Az adatok további kéréseit a gyorsítótár segítségével kezeljük. Minden CDN-nek lehetősége van a fájlok előzetes betöltésére, a gyorsítótár törlésére, a gyorsítótár megőrzési idejére és még sok másra.

néha különböző okok miatt előfordulhat, hogy az embernek szüksége van saját CDN felépítésére, ezért a következő útmutatót mutatjuk be annak megvalósításához.

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

vessünk egy pillantást azokra a helyzetekre, amikor szükség lehet saját CDN létrehozására:

• amikor megpróbál pénzt megtakarítani, és még megfizethető megoldások, mint BunnyCDN végén olcsóbb, akkor több száz dollárt havonta
• ha azt szeretnénk, hogy állandó cache vagy szükség garantált sávszélesség és erőforrások
• meglévő CDN-k nem pop a cél régióban
• van szükség speciális tartalom Szállítási beállítások
• szeretné gyorsítani a
• attól tart, hogy harmadik féltől származó CDN-k illegálisan gyűjthetnek és használhatnak felhasználói adatokat (Hé, olyan szerverek, amelyek nem

a legtöbb esetben életképesebb a meglévő kész megoldások használata.

hozzunk létre saját CDN-t

még egy egyszerű tartalomszolgáltató hálózat felépítéséhez is szüksége van a következőkre:

• domain név vagy aldomain
• legalább két szerver különböző régiókban. A szerverek lehetnek dedikált vagy virtuális
• geoDNS eszköz. Ezzel a felhasználó, aki kérést küld a domainnek, a legközelebbi szerverre irányul

domain regisztrálása és szerverek megrendelése

a domain név regisztrálása egyszerű — csak regisztrálja azt bármelyik domain zónában. A CDN, akkor is használhatja egy aldomain, mint cdn.domainname.com. ez a helyzet a következő példában.

ha szerverekről van szó, azokat olyan régiókban és országokban kell bérelni, ahol a célközönség található. Ha az Ön projektje intercontinental, akkor célszerű olyan tárhelyszolgáltatók közül választani, amelyek világszerte kínálnak szervereket, mint például az OVH, a Leaseweb és a 100tb (dedikált szerverekhez), vagy a Vultr és a DigitalOcean (virtuális és felhőszerverekhez).

a privát CDN-hez rendeljünk három virtuális szervert különböző kontinenseken. A Vultr 25 GB SSD helyet és 1 TB forgalmat kínál nekünk havi 5 dollárért. A telepítés során válassza ki a legújabb Debian-t. Itt vannak a szervereink:

• Frankfurt, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Szingapúr, ip: 157.230.240.216

Geodns konfigurálása

annak biztosítása érdekében, hogy az ügyfelek a megfelelő (legközelebbi) szerverekre irányuljanak, amikor kéréseket küldenek a domainünkre vagy aldomainünkre, szükségünk lesz egy geoDNS funkcióval rendelkező DNS-kiszolgálóra.

így működik a geoDNS:

1. megkapja az ügyfél IP-jét (ha elküldték a DNS-kérést) vagy a kérés feldolgozásához használt rekurzív DNS-kiszolgáló IP-jét. Általánosságban elmondható, hogy az ilyen rekurzív szerverek általában az internetszolgáltatók DNSs-je.
2. az ügyfél IP-je alapján azonosítja országát vagy régióját. Ez a művelet használatát igényli GeoIP adatbázis, amelyek rendelkezésre állnak nincs hiány. Még tisztességes ingyenes lehetőségek is vannak.
3. az ügyfél helyétől függően a geoDNS visszaadja neki a legközelebbi CDN szerver IP-címét.

a geoDNS funkcióval rendelkező DNS-kiszolgálót maga is felépítheti, de jobb, ha olyan kész megoldásokat használ, amelyek a világ minden táján vannak szerverekkel és egy dobozon kívüli Anycast opcióval:

• ClouDNS, 9 dollárból.95 / hó, GeoDNS csomag, egy DNS feladatátvétel alapértelmezés szerint biztosított
• Zilore, 25 USD/hó, magában foglalja a DNS feladatátvételt
• Amazon Route 53, 35 USD/hó 50 millió geo-kérésért. DNS Failover ára külön
• DNS Made Easy, a $ 125 / hó, a 10 DNS Failovers
• Cloudflare, Geo kormányzás funkció biztosított vállalati csomagok

megrendelésekor geoDNS meg kell figyelni, hogy a kérelmek száma tartalmazza a csomagot, és tartsa szem előtt, hogy a valós kérelmek száma jelentősen meghaladhatja a várakozásokat. Webrobotok, Szkennerek, spamküldők és más ördögök milliói dolgoznak bármikor.

szinte minden DNS – szolgáltatás tartalmaz egy hasznos funkciót a CDN-építéshez-DNS feladatátvétel. Ezzel konfigurálhatja a tevékenységfigyelést úgy, hogy ha egy szerver leáll, a rendszer automatikusan átirányítja az ügyfeleket a működő szerverekre.

a CDN-hez használjuk a ClouDNS-t és annak GeoDNS csomagját.

a profilban adjon hozzá egy új DNS-zónát, és adja meg a domain nevét. Ha aldomaint használ, és a fő tartomány használatban van, ne felejtse el azonnal hozzáadni a meglévő DNS-rekordokat a zóna hozzáadása után. A következő lépés több a rekord létrehozása a CDN tartományhoz / aldomainhez, amelyek mindegyikét a megadott régióhoz használják. A kontinenseket vagy országokat régióként jelölheti meg, és a kistérségi lehetőségek az Egyesült Államok és Kanada számára állnak rendelkezésre.

példánkban a CDN a cdn.sayt.in aldomain. Miután hozzáadta a sayt.in zóna, hozza létre az aldomain első a rekordját, és irányítsa az összes NA klienst a Chicago szerverre:

ismételje meg ezt a lépést a többi régió esetében, és ne felejtsen el létrehozni egy rekordot az alapértelmezett régiókhoz. Itt van, amit a végeredmény úgy néz ki, mint:

Az utolsó alapértelmezett rekord azt jelenti, kéréseket minden nem specifikált régió (Európa, Afrika, műholdas Internet felhasználók, stb.) kell irányulni, hogy a Frankfurt-kiszolgáló.

Ez arra a következtetésre jut, hogy az alapvető DNS-konfiguráció. Minden, ami maradt, hogy menjen a regisztrátor honlapján, és cserélje ki a jelenlegi névszerverek által biztosított ClouDNS. Amíg frissítik őket, beállítjuk a szervereket.

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

CDN-nk HTTPS használatával fog működni, tehát ha már rendelkezik SSL tanúsítvánnyal a domainhez vagy az aldomainhez, töltse fel őket az összes szerverre, például az /etc/ssl/yourdomain/ könyvtárba.

ha nincs tanúsítványa, ingyenesen beszerezheti a Let ‘ s Encrypt – től. Az ACME Shell script nagyszerű lehetőség. Felhasználóbarát klienssel rendelkezik, és ami még fontosabb, lehetővé teszi a domain/Aldomain érvényesítését DNS-en keresztül, API-k segítségével.

telepítjük acme.sh csak egy szerveren — az Európai (199.247.18.199), onnan pedig a tanúsítványokat átmásolják az összes többihez. A telepítéshez futtassa a következő parancsot:

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

a telepítés során létrejön egy cron feladat a tanúsítványok automatikus frissítésére.

a tanúsítvány kiadásakor a Domain ellenőrzése DNS-en keresztül történik az API használatával, így a ClouDNS profilban, a viszonteladói API alatt hozzon létre egy új API-felhasználót, és adja meg a jelszót. Írja be a kapott auth-id-t a jelszóval együtt a következő fájlba: ~/.acme.sh/dnsapi/dns_cloudns.sh (nem tévesztendő össze a dns_clouddns.sh). itt vannak a sorok, amelyeket ki kell fejteni és szerkeszteni:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

most kérjük az SSL tanúsítvány kiadását a cdn számára.sayt.a

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

a későbbi felhasználás érdekében a paraméterekben a tanúsítvány minden megújítása után elhagytunk egy parancsot az automatikus konfigurációs újraindításhoz.

a tanúsítvány megszerzésének folyamata akár két percet is igénybe vehet, ezért ne szakítsa meg. Tartományellenőrzési hiba esetén próbálkozzon újra a parancs futtatásával. Végül meglátjuk, hol töltötték le a tanúsítványokat.

ne feledje ezeket az útvonalakat, meg kell adnunk őket, amikor a tanúsítványokat más szerverekre másoljuk, és meg kell adnunk őket a kiszolgáló beállításaiban. Hagyja figyelmen kívül az Nginx config újratöltési hibát, — a tanúsítvány megújítása során nem fordul elő teljesen konfigurált kiszolgálón.

ami az SSL tanúsítványt illeti, csak annyit kellett tennünk, hogy átmásoljuk a két másik szerverre, mentve a tanúsítvány elérési útját. Hozzon létre azonos könyvtárakat minden kiszolgálón, majd másolja a tanúsítványfájlokat:

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ány megújításának automatizálásához létre kell hoznia egy napi CRON feladatot mindkét kiszolgálón. Az alábbiakban látható a parancs, amelyet hozzá kell adnia a CRON feladatokhoz:

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

ne feledje, hogy a távoli származási kiszolgálóhoz való kapcsolathoz kulcson keresztüli hozzáférés szükséges jelszó megadása nélkül. Ne felejtsd el létrehozni.

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

statikus tartalomszolgáltatáshoz az Nginx-et használjuk, amely gyorsítótárazási proxykiszolgálóként van konfigurálva. Frissítse a csomagok listáját, és telepítse mind a három kiszolgálóra:

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

az alapértelmezett konfiguráció helyett használja az alábbiakat:

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 config-ben szerkesszük:

• max_size — a gyorsítótár mérete nem haladja meg a rendelkezésre álló lemezterületet
• inaktív — a nem kért gyorsítótárazott adatok megőrzési ideje
• ssl_certificate and ssl_certificate_key — az SSL tanúsítvány és kulcs elérési útja
• proxy_cache_valid — a gyorsítótárazott adatok megőrzési ideje
• proxy_pass — annak az eredeti kiszolgálónak a címe, ahonnan a CDN adatokat kér a gyorsítótárazáshoz. Példánkban ez sayt.in

mint látható, ez nem rakéta tudomány. Az egyetlen nehézség a retenciós idő beállítása, tekintettel az inaktív és a proxy_cache_valid paraméterek közötti hasonlóságokra. Vessünk egy közelebbi pillantást. Ez történik az inactive=7D és proxy_cache_valid=90d esetén:

• ha a kérés 7 napon belül nem ismétlődik meg, az adatok törlődnek a gyorsítótárból
• ha a kérés még egyszer is megismétlődik 7 nap alatt, a gyorsítótár 90 nap elteltével elavultnak minősül, és a következő kérés miatt az Nginx frissíti azt az origin szerverről

az nginx-szel.conf kezelve, töltse be újra a konfigurációt:

root@cdn:~# service nginx reload

tehát a CDN használatra kész! A $ 15 / hó kaptunk durran három kontinensen és 3TB forgalom: 1TB minden régióban.

ellenőrzése a CDN

vessünk egy pillantást ping a CDN különböző helyeken. Ebben az esetben minden ping szolgáltatás megtörténik.

az eredmények jók. Most tegyünk egy tesztképet test címmel.JPG a fő szerveren, és ellenőrizze, hogy milyen gyorsan töltődik keresztül CDN. Mondtam és kész. A betöltés gyors.

készítsünk egy kis szkriptet arra az esetre, ha törölnünk kellene a gyorsítótárat egy CDN ponton.

purge.sh

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

a kiszolgáló összes gyorsítótárának törléséhez egyszerűen futtassa a szkriptet. Ha szüksége van egy néhány fájl megtisztított, csak adja meg az elérési útját:

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

a gyorsítótár mindenhol történő kiürítéséhez a szkriptet minden CDN-kiszolgálón futtatni kell.

következtetések helyett

végül szeretnék néhány hasznos tippet adni, hogy elkerülje a már kitisztított buktatókat:

• vegye figyelembe a jövőbeni CDN életképességét és fenntartási költségeit. A legtöbb esetben sokkal hatékonyabb és könnyebb olcsó CDN-t vásárolni, amely valószínűleg stabilabb és jobb minőségű lesz.
• a CDN hibatűrésének javítása érdekében ajánlott beállítani egy DNS feladatátvételt, amely lehetővé teszi az a rekord gyors váltását, ha egy szerver megszakad. Ezt a DNS rekordok vezérlőpultján teheti meg.
• a széles lefedettségű webhelyek nagy számú pop-ot igényelnek, de nem válnak túlbuzgóvá. Valószínűleg a felhasználó nem veszi észre a különbséget a CDN és a fizetett között, ha 6-7 helyszínen (Európa, Észak-Amerika (Kelet), Észak-Amerika (Nyugat), Szingapúr, Ausztrália, Hong Kong vagy Japán) vannak szerverei.
• néha a tárhelyszolgáltatók nem engedélyezik a bérelt szerverek használatát CDN-ekhez. Tehát, ha CDN szolgáltatást szeretne létrehozni, feltétlenül olvassa el a tárhelyszolgáltató feltételeit.
• tanulmányozza a tengeralattjáró kábel térképét, hogy megértse, hogyan kapcsolódnak a kontinensek, és használja ezt a tudást a CDN építésekor.
• próbálja meg pingelni a szervereket különböző helyekről. Így észreveheti a pop-okhoz legközelebb eső régiókat, és ez segít a Geodn-ek konfigurálásában.