ProHoster > Блог > 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 root@199.247.18.199:/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 root@199.247.18.199:/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