ProHoster > Blog > Uprava > Gradnja in konfiguracija vašega CDN

Gradnja in konfiguracija vašega CDN

Omrežja za dostavo vsebine (CDN) se na spletnih mestih in v aplikacijah uporabljajo predvsem za pospešitev nalaganja statičnih elementov. To se zgodi zaradi predpomnjenja datotek na strežnikih CDN, ki se nahajajo v različnih geografskih regijah. Z zahtevo po podatkih preko CDN jih uporabnik prejme od najbližjega strežnika.

Načelo delovanja in funkcionalnost vseh omrežij za dostavo vsebin je približno enako. Ko prejme zahtevo za prenos datoteke, jo strežnik CDN enkrat vzame iz prvotnega strežnika in jo da uporabniku, hkrati pa jo predpomni za določeno časovno obdobje. Na vse nadaljnje zahteve se odgovori iz predpomnilnika. Vsi CDN-ji imajo možnosti za prednalaganje datotek, brisanje predpomnilnika, nastavitev datuma poteka in več.

Zgodi se, da morate iz takšnih ali drugačnih razlogov organizirati lastno mrežo za dostavo vsebine, potem pa – naj nam bodo v pomoč navodila za sestavo naslednjega kolesa.

Gradnja in konfiguracija vašega CDN
Vir: Infografski vektor, ki ga je ustvaril pikisuperstar - www.freepik.com

Ko potrebujete svoj CDN

Razmislite o primerih, ko je vodenje lastnega CDN smiselno:

  • ko obstaja želja po prihranku denarja in tekočih stroških, tudi pri uporabi poceni CDN-jev, kot je BunnyCDN znašajo nekaj sto dolarjev na mesec
  • če želimo dobiti stalni predpomnilnik ali predpomnilnik brez sosedov strežnika in kanala
  • Storitve CDN nimajo točk prisotnosti v regiji, ki jo potrebujete
  • morebitne potrebne posebne nastavitve dostave vsebine
  • s postavitvijo produkcijskega strežnika bližje uporabnikom želimo pospešiti dostavo dinamičnih vsebin
  • obstaja zaskrbljenost, da lahko storitev CDN tretjih oseb nezakonito zbira ali uporablja informacije o vedenju uporabnikov (zdravo, storitve, ki niso skladne z GDPR) ali sodeluje v drugih nezakonitih dejavnostih.

V večini drugih primerov je bolj primerno uporabiti obstoječe že pripravljene rešitve.

Kaj potrebujete za začetek

Čudovito je, če imate svoj avtonomni sistem (AS). Z njim lahko isti IP dodelite več strežnikom in po tem navodilu na nivoju omrežja usmeri uporabnike na najbližje. Vredno je povedati, da je tudi z naslovnim blokom /24 mogoče zgraditi omrežje za dostavo vsebin. Nekateri ponudniki strežnikov vam omogočajo, da objavite obvestilo za uporabo v vseh regijah, ki so jim na voljo.

Če niste srečni lastnik bloka naslovov IP, boste za zagon preprostega CDN potrebovali:

  • ime domene ali poddomene
  • vsaj dva strežnika v različnih regijah. Strežnik je lahko namenski ali virtualni
  • geoDNS orodje. Z njim bo uporabnik, ki je naslovil domeno, usmerjen na najbližji strežnik

Registrirajte domeno in naročite strežnike

Pri registraciji domene je vse preprosto - registriramo se v kateri koli coni pri kateremkoli registrarju. Za CDN lahko uporabite tudi poddomeno, na primer nekaj podobnega cdn.domainname.com. Pravzaprav bomo v našem primeru storili prav to.

Kar zadeva naročanje strežnikov, jih je treba najeti v regijah in državah, kjer se nahaja vaša uporabniška publika. Če je projekt medcelinski, je primerno izbrati ponudnike gostovanja, ki ponujajo strežnike po vsem svetu hkrati. Primeri: OVH, zakup spleta и 100Tb - za namenske strežnike, Vultr и DigitalOcean — za virtualni oblak*.

Za naš zasebni CDN bomo naročili 3 virtualne strežnike na različnih celinah. pri Vultr na strežniku za 5 USD/mesec bomo dobili 25GB SSD mesta in 1TB prometa. Pri namestitvi izberite najnovejši Debian. Naši strežniki:

Gradnja in konfiguracija vašega CDN Frankfurt, ip: 199.247.18.199

Gradnja in konfiguracija vašega CDN Chicago, ip: 149.28.121.123

Gradnja in konfiguracija vašega CDN Slovenija, ip: 157.230.240.216

* Vultr in DigitalOcean obljubljata 100 $ kredita uporabnikom, ki se registrirajo prek povezav v članku takoj po dodajanju načina plačila. Avtor je s tem deležen tudi majhnega komplimenta, ki je zanj sedaj zelo pomenljiv. Prosim za razumevanje.

Nastavitev geoDNS

Da bo uporabnik pri dostopu do domene ali poddomene CDN usmerjen na želeni (najbližji) strežnik, potrebujemo DNS strežnik s funkcijo geoDNS.

Načelo in delovanje geoDNS je naslednje:

  1. Podaja IP odjemalca, ki je poslal zahtevo DNS, ali IP rekurzivnega strežnika DNS, ki se uporablja pri obdelavi zahteve odjemalca. Takšni rekurzivni strežniki so običajno DNS-ji ponudnikov.
  2. IP odjemalca prepozna njegovo državo ali regijo. Za to se uporabljajo baze podatkov GeoIP, ki jih je danes zelo veliko. Obstajajo dobri brezplačne možnosti.
  3. Odvisno od lokacije odjemalca mu da IP naslov najbližjega CDN strežnika.

Strežnik DNS s funkcijo geoDNS je lahko sestavite sami, vendar je bolje uporabiti že pripravljene rešitve z mrežo strežnikov DNS po vsem svetu in Anycast iz škatle:

  • CloudDNS od 9.95 USD/mesec, tarifa GeoDNS, privzeto je en DNS Failover
  • Zilore od 25 USD/mesec, DNS Failover omogočen
  • Amazonska pot 53 od 35 USD/mesec za neto 50 milijonov geografskih zahtev. DNS Failover se zaračuna posebej
  • DNS je preprost od 125 USD/mesec, obstaja 10 preklopov DNS
  • Cloudflare, funkcija »Geo Steering« je na voljo v paketih Enterprise

Pri naročanju geoDNS bodite pozorni na število zahtev, vključenih v tarifo, in upoštevajte, da lahko dejansko število zahtev do domene večkrat preseže pričakovanja. Milijoni pajkov, skenerjev, pošiljateljev neželene pošte in drugih zlih duhov neutrudno delajo.

Skoraj vse storitve DNS vključujejo nepogrešljivo storitev za gradnjo CDN - DNS Failover. Z njegovo pomočjo lahko nastavite nadzor nad delovanjem svojih strežnikov in v odsotnosti znakov življenja samodejno zamenjate naslov nedelujočega strežnika z rezervnim v odgovorih DNS.

Za izgradnjo našega CDN bomo uporabili CloudDNS, tarifa GeoDNS.

V vaš osebni račun dodamo novo cono DNS in navedemo vašo domeno. Če gradimo CDN na poddomeni in je glavna domena že v uporabi, potem takoj po dodajanju cone ne pozabite dodati obstoječih delujočih DNS zapisov. Naslednji korak je ustvariti več A-zapisov za domeno/poddomeno CDN, od katerih bo vsak uporabljen za regijo, ki smo jo določili. Kot regije lahko določite celine ali države, podregije so na voljo za ZDA in Kanado.

V našem primeru bo CDN dvignjen na poddomeni cdn.sayt.in. Z dodajanjem cone sayt.in, ustvarite prvi A-zapis za poddomeno in usmerite vso Severno Ameriko na strežnik v Chicagu:

Gradnja in konfiguracija vašega CDN
Ponovimo dejanje za druge regije, pri čemer ne pozabimo ustvariti enega vnosa za privzete regije. Evo, kaj se zgodi na koncu:

Gradnja in konfiguracija vašega CDN

Zadnji privzeti vnos na posnetku zaslona pomeni, da bodo vse nedoločene regije (in to so Evropa, Afrika, uporabniki satelitskega interneta itd.) poslane na strežnik v Frankfurtu.

S tem je osnovna nastavitev DNS končana. Preostalo je, da obiščete spletno mesto registrarja domene in zamenjate trenutne NS domene s tistimi, ki jih izda ClouDNS. Medtem ko se bodo NS posodabljali, bomo pripravljali strežnike.

Namestitev SSL certifikatov

Naš CDN bo deloval prek HTTPS, tako da če že imate SSL certifikate za domeno ali poddomeno, jih naložite na vse strežnike, na primer v imenik /etc/ssl/vašadomena/

Če certifikatov ni, lahko dobite brezplačnega pri Let's Encrypt. Kot nalašč za to ACME Shellscript. Odjemalec je priročen in enostaven za nastavitev, in kar je najpomembnejše, omogoča preverjanje domene/poddomene z DNS prek API-ja ClouDNS.

Acme.sh bomo namestili samo na enega od strežnikov - evropski 199.247.18.199, s katerega se bodo certifikati kopirali na vse ostale. Za namestitev zaženite:

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

Med namestitvijo skripte bo ustvarjeno opravilo CRON za nadaljnje obnavljanje certifikatov brez našega sodelovanja.

Ob izdaji potrdila bo domena preverjena s pomočjo DNS z uporabo API-ja, zato morate v osebnem računu ClouDNS v meniju Reseller API ustvariti nov uporabniški API in zanj nastaviti geslo. Dobljeni auth-id z geslom bo zapisan v datoteki ~/.acme.sh/dnsapi/dns_cloudns.sh (ne zamenjujte z datoteko dns_clouddns.sh). Tukaj so vrstice, ki jih je treba odkomentirati in urediti:

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

Zdaj bomo zahtevali potrdilo SSL za cdn.sayt.in

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

V možnostih smo za naprej določili ukaz za samodejno ponovno nalaganje konfiguracije spletnega strežnika po vsaki obnovitvi obdobja veljavnosti certifikata v prihodnosti.

Celoten postopek pridobitve potrdila lahko traja do 2 minuti, ne prekinjajte ga. Če pride do napake pri preverjanju domene, poskusite znova zagnati ukaz. Na koncu bomo videli, kam so bili certifikati naloženi:

Gradnja in konfiguracija vašega CDN

Zapomnite si te poti, navesti jih boste morali pri kopiranju potrdila na druge strežnike, pa tudi v nastavitvah spletnega strežnika. Ne posvečamo pozornosti napaki pri ponovnem nalaganju konfiguracij Nginx - pri posodabljanju potrdil ne bo na popolnoma konfiguriranem strežniku.

Vse, kar nam preostane za SSL, je, da prejeto potrdilo kopiramo na dva druga strežnika in pri tem ohranimo pot do datotek. Ustvarimo iste imenike na vsakem od njih in naredimo kopijo:

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/

Za redno posodabljanje potrdil ustvarite dnevno opravilo CRON na obeh strežnikih z ukazom:

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

V tem primeru mora biti konfiguriran dostop do oddaljenega izvornega strežnika po ključu, tj. brez vnosa gesla. Ne pozabite tega narediti.

Namestitev in konfiguracija Nginx

Za strežbo statične vsebine bomo uporabili Nginx, konfiguriran kot predpomnjen proxy strežnik. Posodobite sezname paketov in ga namestite na vse tri strežnike:

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

Namesto privzete uporabljamo konfiguracijo iz spodnjega spojlerja:
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;
    }
  }
}

Uredi v konfiguraciji:

  • max_size — velikost predpomnilnika, ki ne presega razpoložljivega prostora na disku
  • neaktiven - čas shranjevanja predpomnjenih podatkov, do katerih nihče ni dostopal
  • ssl_certificate и ssl_certificate_key — poti do potrdila SSL in datotek ključev
  • proxy_cache_valid - čas shranjevanja predpomnjenih podatkov
  • proxy_pass — naslov prvotnega strežnika, od katerega bo CDN zahteval datoteke za predpomnjenje. V našem primeru to sayt.in

Kot lahko vidite, je vse preprosto. Težave lahko nastanejo le pri nastavitvi časa predpomnjenja zaradi podobnosti direktiv neaktiven и proxy_cache_valid. Analizirajmo jih z našim primerom. Evo, kaj se zgodi, ko neaktiven=7d и proxy_cache_valid 90d:

  • če zahteve ne ponovite v 7 dneh, bodo podatki po tem obdobju izbrisani iz predpomnilnika
  • če se zahteva ponovi vsaj enkrat vsakih 7 dni, se bodo podatki v predpomnilniku po 90 dneh šteli za zastarele in Nginx jih bo posodobil z naslednjo zahtevo in jih vzel iz prvotnega strežnika

Urejanje končano nginx.conf, znova naložite konfiguracijo:

root@cdn:~# service nginx reload

Naš CDN je pripravljen. Za 15 $/mesec. prejeli smo točke prisotnosti na treh celinah in 3 TB prometa: 1 TB na vsaki lokaciji.

Preverjanje dela CDN

Poglejmo pinge do našega CDN z različnih geografskih lokacij. Vsaka storitev ping bo delovala za to.

Začetna točka
Voditelj
IP
Povprečni čas, ms

Nemčija Berlin
cdn.sayt.in
199.247.18.199
9.6

Nizozemska, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francija Pariz
cdn.sayt.in
199.247.18.199
16.3

Velika Britanija, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

ZDA, San Francisco
cdn.sayt.in
149.28.121.123
52.7

ZDA, Dallas
cdn.sayt.in
149.28.121.123
23.1

ZDA, Chicago
cdn.sayt.in
149.28.121.123
2.6

ZDA, New York
cdn.sayt.in
149.28.121.123
19.8

Slovenija
cdn.sayt.in
157.230.240.216
1.7

Japonska Tokio
cdn.sayt.in
157.230.240.216
74.8

Avstralija, Sydney
cdn.sayt.in
157.230.240.216
95.9

Rezultati so dobri. Zdaj bomo testno sliko postavili v koren glavnega mesta test.jpg in preveri njegovo hitrost prenosa prek CDN. Rečeno je - narejeno. Vsebina je dostavljena hitro.

Napišimo majhen skript, če želimo počistiti predpomnilnik na točki CDN.
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

Če želite izbrisati celoten predpomnilnik, ga samo zaženite, ločeno datoteko lahko očistite takole:

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

Namesto zaključkov

Za konec pa želim podati še nekaj koristnih nasvetov, da takoj stopim čez grablje, zaradi katerih me je takrat bolela glava:

  • Za povečanje tolerance napak CDN je priporočljivo konfigurirati DNS Failover, ki pomaga hitro spremeniti zapis A v primeru okvare strežnika. To se naredi v nadzorni plošči DNS zapisi domene.
  • Spletna mesta s široko geografsko pokritostjo brez dvoma zahtevajo veliko število CDN-jev, vendar ne bodimo fanatični. Najverjetneje uporabnik ne bo opazil bistvene razlike v primerjavi s plačanim CDN, če postavite strežnike na 6-7 lokacij: Evropa, Severna Amerika (vzhod), Severna Amerika (zahod), Singapur, Avstralija, Hong Kong ali Japonska
  • Včasih gostitelji ne dovolijo uporabe najetih strežnikov za namene CDN. Če se torej nenadoma odločite za uvedbo omrežja za dostavo vsebine kot storitve, ne pozabite vnaprej prebrati pravil določenega ponudnika gostovanja
  • Raziščite zemljevid podvodnih komunikacijpredstaviti, kako so celine povezane, in to upoštevati pri izgradnji omrežja za dostavo vsebin
  • Poskusite preveriti pingi iz različnih krajev na vaše strežnike. Tako lahko vidite regije, ki so najbližje točkam CDN, in pravilneje konfigurirate GeoDNS
  • Glede na naloge bo koristno natančno prilagoditi Nginx za posebne zahteve predpomnjenja in ob upoštevanju obremenitve strežnika. Pri tem so mi zelo pomagali članki o predpomnilniku Nginx - tukaj in pospeševanje dela pri velikih obremenitvah: tukaj и tukaj

Vir: www.habr.com