ProHoster > Blogs > Administrācija > CDN izveide un konfigurÄ“Å”ana

CDN izveide un konfigurēŔana

Satura piegādes tÄ«kli (CDN) tiek izmantoti vietnēs un lietojumprogrammās galvenokārt, lai paātrinātu statisko elementu ielādi. Tas notiek, pateicoties failu saglabāŔanai keÅ”atmiņā CDN serveros, kas atrodas dažādos Ä£eogrāfiskos reÄ£ionos. Pieprasot datus caur CDN, lietotājs tos saņem no tuvākā servera.

Visu satura piegādes tÄ«klu darbÄ«bas princips un funkcionalitāte ir aptuveni vienāda. Saņemot pieprasÄ«jumu lejupielādēt failu, CDN serveris to vienreiz paņem no sākotnējā servera un nodod lietotājam, vienlaikus saglabājot to keÅ”atmiņā uz noteiktu laiku. Uz visiem turpmākajiem pieprasÄ«jumiem tiek atbildēts no keÅ”atmiņas. Visiem CDN ir iespējas iepriekÅ” ielādēt failus, notÄ«rÄ«t keÅ”atmiņu, iestatÄ«t derÄ«guma termiņu un veikt citas darbÄ«bas.

Gadās, ka tā vai cita iemesla dēļ ir jāsakārto savs satura piegādes tÄ«kls un tad - lai mums noder nākamā velosipēda komplektÄ“Å”anas instrukcija.

CDN izveide un konfigurēŔana
Avots: Infografikas vektors, ko izveidojis pikisuperstar - www.freepik.com

Kad jums ir nepiecieŔams savs CDN

Apsveriet gadījumus, kad ir jēga vadīt savu CDN:

  • ja ir vēlme ietaupÄ«t naudu un ekspluatācijas izmaksas, pat izmantojot lētus CDN, piemēram BunnyCDN sastāda vairākus simtus dolāru mēnesÄ«
  • ja vēlamies iegÅ«t pastāvÄ«gu keÅ”atmiņu vai keÅ”atmiņu bez servera un kanāla kaimiņiem
  • CDN pakalpojumiem jums nepiecieÅ”amajā reÄ£ionā nav klātbÅ«tnes punktu
  • nepiecieÅ”ami Ä«paÅ”i satura piegādes iestatÄ«jumi
  • mēs vēlamies paātrināt dinamiska satura piegādi, novietojot ražoÅ”anas serveri tuvāk lietotājiem
  • pastāv bažas, ka treŔās puses CDN pakalpojums var nelikumÄ«gi vākt vai izmantot informāciju par lietotāju uzvedÄ«bu (sveicināti ar GDPR nesaderÄ«gie pakalpojumi) vai iesaistÄ«ties citās nelikumÄ«gās darbÄ«bās.

Vairumā citu gadījumu lietderīgāk ir izmantot esoŔos gatavos risinājumus.

Kas jums ir nepiecieŔams, lai sāktu

Tas ir lieliski, ja jums ir sava autonomā sistēma (AS). Ar to jÅ«s varat pieŔķirt vienu un to paÅ”u IP vairākiem serveriem un saskaņā ar Å”o instrukciju tÄ«kla lÄ«menÄ« novirzÄ«t lietotājus uz tuvāko. Ir vērts teikt, ka pat ar /24 adreÅ”u bloku ir iespējams izveidot satura piegādes tÄ«klu. Daži serveru nodroÅ”inātāji ļauj jums sniegt paziņojumu lietoÅ”anai visos tiem pieejamajos reÄ£ionos.

Ja neesat laimīgs IP adreŔu bloka īpaŔnieks, tad, lai palaistu vienkārŔu CDN, jums būs nepiecieŔams:

  • domēna vārds vai apakÅ”domēns
  • vismaz divi serveri dažādos reÄ£ionos. Serveris var bÅ«t gan veltÄ«ts, gan virtuāls
  • geoDNS rÄ«ks. Ar to lietotājs, uzrunājis domēnu, tiks novirzÄ«ts uz tuvāko serveri

Reģistrējiet domēnu un pasūtiet serverus

Ar domēna reÄ£istrāciju viss ir vienkārÅ”i ā€“ mēs reÄ£istrējamies jebkurā zonā pie jebkura reÄ£istratÅ«ras. Varat arÄ« izmantot CDN apakÅ”domēnu, piemēram, kaut ko lÄ«dzÄ«gu cdn.domainname.com. PatiesÄ«bā mÅ«su piemērā mēs to darÄ«sim.

Runājot par serveru pasÅ«tÄ«Å”anu, tie ir jānomā reÄ£ionos un valstÄ«s, kur atrodas jÅ«su lietotāju auditorija. Ja projekts ir starpkontinentāls, tad ērti izvēlēties hostinga pakalpojumu sniedzējus, kas piedāvā serverus uzreiz visā pasaulē. Piemēri: OVH, nomas tÄ«meklis Šø 100Tb - veltÄ«tiem serveriem, Vultr Šø DigitalOcean ā€” virtuālajam mākonim*.

MÅ«su privātajam CDN mēs pasÅ«tÄ«sim 3 virtuālos serverus dažādos kontinentos. Plkst Vultr serverÄ« priekÅ” 5 $/mēn mēs saņemsim 25GB SSD vietas un 1 TB trafika. InstalÄ“Å”anas laikā atlasiet jaunāko Debian versiju. MÅ«su serveri:

CDN izveide un konfigurēŔana Frankfurte, ip: 199.247.18.199

CDN izveide un konfigurēŔana Chicago, ip: 149.28.121.123

CDN izveide un konfigurēŔana Singapūra, ip: 157.230.240.216

* Vultr un DigitalOcean sola 100 USD kredÄ«tu lietotājiem, kuri reÄ£istrējas, izmantojot rakstā esoŔās saites, tÅ«lÄ«t pēc maksājuma veida pievienoÅ”anas. Autors no tā saņem arÄ« nelielu komplimentu, kas viņam Å”obrÄ«d ir ļoti nozÄ«mÄ«gs. LÅ«dzu, esiet saprotoÅ”i.

ĢeoDNS iestatīŔana

Lai lietotājs, piekļūstot domēnam vai CDN apakÅ”domēnam, tiktu novirzÄ«ts uz vēlamo (tuvāko) serveri, nepiecieÅ”ams DNS serveris ar geoDNS funkciju.

ĢeoDNS princips un darbība ir Ŕāda:

  1. Norāda DNS pieprasÄ«jumu nosÅ«tÄ«juŔā klienta IP vai rekursÄ«vā DNS servera IP, kas tiek izmantots, apstrādājot klienta pieprasÄ«jumu. Šādi rekursÄ«vie serveri parasti ir pakalpojumu sniedzēju DNS.
  2. Klienta IP atpazīst viņa valsti vai reģionu. Šim nolūkam tiek izmantotas GeoIP datu bāzes, kuru mūsdienās ir ļoti daudz. Ir labi bezmaksas iespējas.
  3. AtkarÄ«bā no klienta atraÅ”anās vietas pieŔķir viņam tuvākā CDN servera IP adresi.

DNS serveris ar geoDNS funkciju var bÅ«t salikt pats, bet labāk ir izmantot gatavus risinājumus ar DNS serveru tÄ«klu visā pasaulē un JebkurÅ” no kastes:

  • CloudDNS no 9.95 $/mēn, GeoDNS tarifs, pēc noklusējuma ir viens DNS kļūmjpārlēce
  • Zilore no 25 $/mēn, DNS kļūmjpārlēce ir iespējota
  • Amazon Route 53 no 35 $/mēn neto 50 miljoniem Ä£eogrāfisko pieprasÄ«jumu. DNS kļūmjpārlēce tiek iekasēta atseviŔķi
  • DNS ir viegli no 125 $/mēn, ir 10 DNS kļūmjpārlēces
  • Cloudflare, Funkcija "Ä¢eogrāfiskā vadÄ«ba" ir pieejama uzņēmuma plānos

PasÅ«tot geoDNS, jāpievērÅ” uzmanÄ«ba tarifā iekļauto pieprasÄ«jumu skaitam un jāpatur prātā, ka reālais pieprasÄ«jumu skaits domēnam var vairākas reizes pārsniegt cerēto. Miljoniem zirnekļu, skeneru, surogātpasta izplatÄ«tāju un citu ļauno garu nenogurstoÅ”i strādā.

GandrÄ«z visos DNS pakalpojumos ir iekļauts neaizstājams pakalpojums CDN izveidoÅ”anai - DNS kļūmjpārlēce. Ar tās palÄ«dzÄ«bu jÅ«s varat iestatÄ«t savu serveru darbÄ«bas uzraudzÄ«bu un, ja nav dzÄ«vÄ«bas pazÄ«mju, DNS atbildēs automātiski aizstāt nestrādājoÅ”a servera adresi ar rezerves adresi.

Lai izveidotu mūsu CDN, mēs izmantosim CloudDNS, GeoDNS tarifs.

Pievienosim jaunu DNS zonu jÅ«su personÄ«gajā kontā, norādot jÅ«su domēnu. Ja mēs veidojam CDN apakÅ”domēnā un galvenais domēns jau tiek izmantots, tad uzreiz pēc zonas pievienoÅ”anas neaizmirstiet pievienot esoÅ”os darba DNS ierakstus. Nākamais solis ir izveidot vairākus A ierakstus CDN domēnam/apakÅ”domēnam, no kuriem katrs tiks piemērots mÅ«su norādÄ«tajam reÄ£ionam. Kā reÄ£ionus varat norādÄ«t kontinentus vai valstis, ASV un Kanādai ir pieejami apakÅ”reÄ£ioni.

MÅ«su gadÄ«jumā CDN tiks paaugstināts apakÅ”domēnā cdn.sayt.in. Pievienojot zonu sayt.in, izveidojiet pirmo A ierakstu apakÅ”domēnam un norādiet visu Ziemeļameriku uz serveri Čikāgā:

CDN izveide un konfigurēŔana
Atkārtosim darbību citiem reģioniem, neaizmirstot izveidot vienu ierakstu noklusējuma reģioniem. Lūk, kas notiek beigās:

CDN izveide un konfigurēŔana

Pēdējais noklusējuma ieraksts ekrānuzņēmumā nozīmē, ka visi nenorādītie reģioni (un tie ir Eiropa, Āfrika, satelīta interneta lietotāji utt.) tiks nosūtīti uz serveri Frankfurtē.

Tas pabeidz pamata DNS iestatÄ«Å”anu. Atliek doties uz domēna reÄ£istratÅ«ras vietni un aizstāt paÅ”reizējos domēna NS ar tiem, ko izsniedz ClouDNS. Un kamēr tiks atjaunināti NS, mēs sagatavosim serverus.

SSL sertifikātu uzstādīŔana

MÅ«su CDN darbosies, izmantojot HTTPS, tādēļ, ja jums jau ir SSL sertifikāti domēnam vai apakÅ”domēnam, augÅ”upielādējiet tos visos serveros, piemēram, direktorijā. /etc/ssl/yourdomain/

Ja sertifikātu nav, varat saņemt bezmaksas sertifikātu vietnē Let's Encrypt. Ideāls Å”im ACME Shellscript. Klients ir ērti un viegli iestatāms, un, pats galvenais, tas ļauj apstiprināt domēnu/apakÅ”domēnu, izmantojot DNS, izmantojot ClouDNS API.

Mēs uzstādīsim acme.sh tikai vienā no serveriem - Eiropas 199.247.18.199, no kura sertifikāti tiks kopēti uz visiem pārējiem. Lai instalētu, palaidiet:

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

Skripta instalÄ“Å”anas laikā tiks izveidots CRON darbs turpmākai sertifikātu atjaunoÅ”anai bez mÅ«su lÄ«dzdalÄ«bas.

Izsniedzot sertifikātu, domēns tiks pārbaudīts, izmantojot DNS, izmantojot API, tāpēc ClouDNS personīgajā kontā tālākpārdevēja API izvēlnē ir jāizveido jauns lietotāja API un jāiestata tam parole. Iegūtais autentifikācijas ID ar paroli tiks ierakstīts failā ~/.acme.sh/dnsapi/dns_cloudns.sh (nejaukt ar failu dns_clouddns.sh). Tālāk ir norādītas rindas, kuras ir jāatbrīvo no komentāriem un jārediģē:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<ŠæŠ°Ń€Š¾Š»ŃŒ>"

Tagad mēs pieprasīsim SSL sertifikātu cdn.sayt.in

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

Nākotnes opcijās esam norādÄ«juÅ”i komandu automātiski pārlādēt tÄ«mekļa servera konfigurāciju pēc katras sertifikāta derÄ«guma perioda atjaunoÅ”anas nākotnē.

Viss sertifikāta iegÅ«Å”anas process var ilgt lÄ«dz 2 minÅ«tēm, nepārtrauciet to. Ja rodas domēna validācijas kļūda, mēģiniet palaist komandu vēlreiz. Beigās redzēsim, kur ir augÅ”upielādēti sertifikāti:

CDN izveide un konfigurēŔana

Atcerieties Å”os ceļus, tie bÅ«s jānorāda, kopējot sertifikātu uz citiem serveriem, kā arÄ« tÄ«mekļa servera iestatÄ«jumos. Mēs nepievērÅ”am uzmanÄ«bu kļūdai, pārlādējot Nginx konfigurācijas - tā nebÅ«s pilnÄ«bā konfigurētā serverÄ«, atjauninot sertifikātus.

Viss, kas mums atliek SSL, ir pārkopēt saņemto sertifikātu uz diviem citiem serveriem, vienlaikus saglabājot ceļu uz failiem. Izveidosim vienādus direktorijus katrā no tiem un izveidosim kopiju:

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/

Lai regulāri atjauninātu sertifikātus, izveidojiet ikdienas CRON darbu abos serveros ar komandu:

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

Šādā gadījumā ir jākonfigurē piekļuve attālā avota serverim pēc atslēgas, t.i. neievadot paroli. Neaizmirstiet to izdarīt.

Nginx instalēŔana un konfigurēŔana

Lai apkalpotu statisku saturu, mēs izmantosim Nginx, kas konfigurēts kā keÅ”atmiņas starpniekserveris. Atjauniniet pakotņu sarakstus un instalējiet to visos trÄ«s serveros:

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

Noklusējuma vietā mēs izmantojam tālāk esoŔā spoilera konfigurāciju:
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;
    }
  }
}

Rediģēt konfigurācijā:

  • max_size ā€” keÅ”atmiņas lielums, nepārsniedzot pieejamo diska vietu
  • neaktÄ«vs - keÅ”atmiņā saglabāto datu uzglabāŔanas laiks, kam neviens nav piekļuvis
  • ssl_certificate Šø ssl_certificate_key ā€” ceļi uz SSL sertifikātu un atslēgu failiem
  • proxy_cache_valid - keÅ”atmiņā saglabāto datu uzglabāŔanas laiks
  • starpniekserveris ā€” sākotnējā servera adrese, no kuras CDN pieprasÄ«s failus keÅ”atmiņā. MÅ«su piemērā Å”is sayt.in

Kā redzat, viss ir vienkārÅ”i. GrÅ«tÄ«bas var rasties tikai keÅ”atmiņas laika iestatÄ«Å”anā direktÄ«vu lÄ«dzÄ«bas dēļ neaktÄ«vs Šø proxy_cache_valid. Analizēsim tos ar mÅ«su piemēru. LÅ«k, kas notiek, kad neaktÄ«vs=7d Šø proxy_cache_valid 90d:

  • ja pieprasÄ«jums netiek atkārtots 7 dienu laikā, pēc Ŕī perioda dati no keÅ”atmiņas tiks dzēsti
  • ja pieprasÄ«jums tiek atkārtots vismaz reizi 7 dienās, keÅ”atmiņā esoÅ”ie dati tiks uzskatÄ«ti par novecojuÅ”iem pēc 90 dienām un Nginx tos atjauninās ar nākamo pieprasÄ«jumu, ņemot tos no sākotnējā servera

RediģēŔana pabeigta nginx.conf, atkārtoti ielādējiet konfigurāciju:

root@cdn:~# service nginx reload

MÅ«su CDN ir gatavs. Par USD 15 mēnesÄ«. mēs saņēmām klātbÅ«tnes punktus trÄ«s kontinentos un 3 TB satiksmes: 1 TB katrā vietā.

CDN darba pārbaude

Apskatīsim ping uz mūsu CDN no dažādām ģeogrāfiskām vietām. Šim nolūkam darbosies jebkurŔ ping pakalpojums.

PalaiŔanas punkts
Saimnieks
IP
Vidējais laiks, ms

Vācija Berlīne
cdn.sayt.in
199.247.18.199
9.6

NÄ«derlande, Amsterdama
cdn.sayt.in
199.247.18.199
10.1

Francija Parīze
cdn.sayt.in
199.247.18.199
16.3

Lielbritānija, Londona
cdn.sayt.in
199.247.18.199
14.9

Kanāda, Toronto
cdn.sayt.in
149.28.121.123
16.2

ASV, Sanfrancisko
cdn.sayt.in
149.28.121.123
52.7

ASV, Dalasa
cdn.sayt.in
149.28.121.123
23.1

ASV, Čikāga
cdn.sayt.in
149.28.121.123
2.6

ASV, Ņujorka
cdn.sayt.in
149.28.121.123
19.8

Singapūra
cdn.sayt.in
157.230.240.216
1.7

Japāna Tokija
cdn.sayt.in
157.230.240.216
74.8

Austrālija, Sidneja
cdn.sayt.in
157.230.240.216
95.9

Rezultāti ir labi. Tagad mēs ievietosim testa attēlu galvenās vietnes saknē test.jpg un pārbaudiet tā lejupielādes ātrumu, izmantojot CDN. Tas ir pateikts - izgatavots. Saturs tiek piegādāts ātri.

UzrakstÄ«sim nelielu skriptu, ja vēlamies notÄ«rÄ«t CDN punkta keÅ”atmiņu.
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

Lai izdzēstu visu keÅ”atmiņu, vienkārÅ”i palaidiet to, atseviŔķu failu var notÄ«rÄ«t Ŕādi:

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

Secinājumu vietā

Nobeigumā vēlos sniegt dažus noderīgus padomus, lai uzreiz pārkāptu pāri grābeklim, no kura tobrīd sāpēja galva:

  • Lai palielinātu CDN kļūdu toleranci, ieteicams konfigurēt DNS kļūmjpāreju, kas palÄ«dz ātri mainÄ«t A ierakstu servera bojājuma gadÄ«jumā. Tas tiek darÄ«ts domēna vadÄ«bas paneļa DNS ierakstos.
  • Vietnēm ar plaÅ”u Ä£eogrāfisko pārklājumu, bez Å”aubām, ir nepiecieÅ”ams liels skaits CDN, taču nebÅ«sim fanātiski. Visticamāk, lietotājs nepamanÄ«s bÅ«tisku atŔķirÄ«bu salÄ«dzinājumā ar maksas CDN, ja izvietosiet serverus 6-7 vietās: Eiropā, Ziemeļamerikā (austrumos), Ziemeļamerikā (rietumos), SingapÅ«rā, Austrālijā, Honkongā vai Japānā.
  • Dažreiz mitinātāji neļauj izmantot nomātos serverus CDN vajadzÄ«bām. Tāpēc, ja pēkŔņi nolemjat kā pakalpojumu izvietot satura piegādes tÄ«klu, neaizmirstiet iepriekÅ” izlasÄ«t konkrēta mitināŔanas pakalpojumu sniedzēja noteikumus.
  • IzpētÄ«t zemÅ«dens sakaru kartelai attēlotu kontinentu savienojumu un ņemtu to vērā, veidojot satura piegādes tÄ«klu
  • Mēģiniet pārbaudÄ«t ping no dažādām vietām uz jÅ«su serveriem. Tādā veidā jÅ«s varat redzēt CDN punktiem tuvākos reÄ£ionus un pareizāk konfigurēt GeoDNS
  • AtkarÄ«bā no uzdevumiem bÅ«s lietderÄ«gi precÄ«zi noregulēt Nginx, lai atbilstu Ä«paŔām keÅ”atmiņas prasÄ«bām un ņemot vērā servera slodzi. Raksti par Nginx keÅ”atmiņu man ļoti palÄ«dzēja Å”ajā - Å”eit un darba paātrināŔana lielās slodzēs: Å”eit Šø Å”eit

Avots: www.habr.com