Content Delivery Networks (CDN's) word hoofsaaklik in webwerwe en toepassings gebruik om die laai van statiese elemente te bespoedig. Dit gebeur as gevolg van die kas van lêers op CDN-bedieners wat in verskillende geografiese streke geleë is. Deur data via CDN aan te vra, ontvang die gebruiker dit vanaf die naaste bediener.
Die beginsel van werking en funksionaliteit van alle inhoudafleweringsnetwerke is ongeveer dieselfde. Nadat 'n versoek ontvang is om 'n lêer af te laai, neem die CDN-bediener dit eenmalig van die oorspronklike bediener af en gee dit aan die gebruiker, en kas dit terselfdertyd vir 'n bepaalde tydperk. Alle daaropvolgende versoeke word vanuit die kas beantwoord. Alle CDN's het opsies om lêers vooraf te laai, die kas skoon te maak, die vervaldatum in te stel, en meer.
Dit gebeur dat u om een of ander rede u eie inhoudafleweringsnetwerk moet organiseer, en dan - laat die instruksies vir die samestelling van die volgende fiets vir ons van hulp wees.
Bron:
Wanneer jy jou eie CDN nodig het
Oorweeg die gevalle waar die bestuur van jou eie CDN sin maak:
- wanneer daar 'n begeerte is om geld te spaar, en bedryfskoste selfs wanneer goedkoop CDN's soos gebruik word 'n paar honderd dollar per maand beloop
- as ons 'n permanente kas of 'n kas sonder bediener- en kanaalbure wil kry
- CDN-dienste het nie punte van teenwoordigheid in die streek wat u benodig nie
- enige spesiale inhoud aflewering instellings vereis
- ons wil die lewering van dinamiese inhoud bespoedig deur die produksiebediener nader aan gebruikers te plaas
- daar is 'n kommer dat 'n derdeparty CDN-diens onwettig inligting oor gebruikersgedrag kan insamel of gebruik (hallo dienste wat nie aan die GDPR voldoen) of betrokke kan raak by ander onwettige aktiwiteite
In die meeste ander gevalle is dit meer gepas om bestaande klaargemaakte oplossings te gebruik.
Wat het jy nodig om te begin
Dit is wonderlik as jy jou eie outonome stelsel (AS) het. Daarmee kan u dieselfde IP aan verskeie bedieners toewys en op netwerkvlak, rig gebruikers na die naaste een. Dit is die moeite werd om te sê dat dit selfs met die /24-adresblok moontlik is om 'n inhoudafleweringsnetwerk te bou. Sommige bedienerverskaffers laat jou toe om 'n aankondiging te maak vir gebruik in alle streke wat aan hulle beskikbaar is.
As jy nie 'n gelukkige eienaar van 'n blok IP-adresse is nie, sal jy nodig hê om 'n eenvoudige CDN uit te voer:
- domeinnaam of subdomein
- ten minste twee bedieners in verskillende streke. Die bediener kan óf toegewyd óf virtueel wees
- geoDNS-instrument. Daarmee sal die gebruiker, wat die domein aangespreek het, na die naaste bediener verwys word
Registreer 'n domein en bestel bedieners
Met domeinregistrasie is alles eenvoudig - ons registreer in enige sone by enige registrateur. U kan ook 'n subdomein vir 'n CDN gebruik, byvoorbeeld iets soos cdn.domainname.com. Eintlik, in ons voorbeeld, sal ons dit doen.
Wat die bestel van bedieners betref, moet dit gehuur word in die streke en lande waar u gebruikersgehoor geleë is. As die projek interkontinentaal is, is dit gerieflik om gasheerverskaffers te kies wat gelyktydig bedieners oor die hele wêreld aanbied. Voorbeelde: , и - vir toegewyde bedieners, и - vir virtuele wolk*.
Vir ons private CDN sal ons 3 virtuele bedieners op verskillende kontinente bestel. By Vultr op die bediener vir $5/maand ons sal kry 25GB SSD plekke en 1TB verkeer. Wanneer jy installeer, kies die nuutste Debian. Ons bedieners:
Frankfurt, IP: 199.247.18.199
Chicago, IP: 149.28.121.123
Singapoer, IP: 157.230.240.216
* Vultr en DigitalOcean beloof $100-krediet aan gebruikers wat deur die skakels in die artikel registreer onmiddellik nadat 'n betaalmetode bygevoeg is. Die skrywer kry ook 'n klein kompliment hieruit, wat nou vir hom baie betekenisvol is. Wees asseblief begripvol.
Stel geoDNS op
Om die gebruiker na die verlangde (naaste) bediener te stuur wanneer hy toegang tot 'n domein of CDN-subdomein kry, benodig ons 'n DNS-bediener met die geoDNS-funksie.
Die beginsel en werking van geoDNS is soos volg:
- Spesifiseer die IP van die kliënt wat die DNS-versoek gestuur het, of die IP van die rekursiewe DNS-bediener wat gebruik word wanneer die kliëntversoek verwerk word. Sulke rekursiewe bedieners is gewoonlik DNS-s van verskaffers.
- Die IP van die kliënt erken sy land of streek. Hiervoor word GeoIP-databasisse gebruik, waarvan daar vandag baie is. Daar is goeie .
- Gee hom die IP-adres van die naaste CDN-bediener, afhangende van die ligging van die kliënt.
DNS-bediener met geoDNS-funksie kan wees , maar dit is beter om klaargemaakte oplossings te gebruik met 'n netwerk van DNS-bedieners regoor die wêreld en uit die boks:
- van $9.95/maand, GeoDNS-tarief, by verstek is daar een DNS Failover
- van $25/maand, DNS Failover geaktiveer
- van $35/maand vir 'n netto 50M geo-versoeke. DNS Failover word afsonderlik gefaktureer
- van $125/maand, daar is 10 DNS-failovers
- , "Geo Steering" funksie is beskikbaar in Enterprise planne
Wanneer u geoDNS bestel, moet u aandag gee aan die aantal versoeke wat by die tarief ingesluit is en in gedagte hou dat die werklike aantal versoeke na die domein die verwagtinge verskeie kere kan oorskry. Miljoene spinnekoppe, skandeerders, spammers en ander bose geeste werk onvermoeid.
Byna alle DNS-dienste bevat 'n onontbeerlike diens vir die bou van 'n CDN - DNS Failover. Met sy hulp kan u die monitering van die werking van u bedieners opstel en, in die afwesigheid van tekens van lewe, outomaties die adres van 'n nie-werkende bediener vervang met 'n rugsteun-een in DNS-antwoorde.
Om ons CDN te bou, sal ons gebruik , GeoDNS-tarief.
Kom ons voeg 'n nuwe DNS-sone by jou persoonlike rekening, wat jou domein spesifiseer. As ons 'n CDN op 'n subdomein bou, en die hoofdomein is reeds in gebruik, moet u nie vergeet om die bestaande werkende DNS-rekords onmiddellik na die byvoeging van die sone by te voeg nie. Die volgende stap is om verskeie A-rekords vir die CDN-domein / subdomein te skep, wat elkeen toegepas sal word op die streek wat ons gespesifiseer het. U kan kontinente of lande as streke spesifiseer, substreke is beskikbaar vir die VSA en Kanada.
In ons geval sal die CDN op 'n subdomein verhoog word cdn.sayt.in. Deur 'n sone by te voeg sê.in, skep die eerste A-rekord vir die subdomein en wys die hele Noord-Amerika na die bediener in Chicago:
Kom ons herhaal die aksie vir ander streke, en onthou om een inskrywing vir die verstekstreke te skep. Hier is wat op die ou end gebeur:
Die laaste verstekinskrywing in die skermkiekie beteken dat alle ongespesifiseerde streke (en dit is Europa, Afrika, satelliet-internetgebruikers, ens.) na die bediener in Frankfurt gestuur sal word.
Dit voltooi die basiese DNS-opstelling. Dit bly om na die webwerf van die domeinregistrateur te gaan en die huidige domein-NS'e te vervang met dié wat deur ClouDNS uitgereik is. En terwyl die NS'e opgedateer sal word, sal ons die bedieners voorberei.
Installasie van SSL-sertifikate
Ons CDN sal oor HTTPS werk, so as jy reeds SSL-sertifikate vir 'n domein of subdomein het, laai dit op na alle bedieners, byvoorbeeld na die gids /etc/ssl/joudomein/
As daar geen sertifikate is nie, kan jy 'n gratis een by Let's Encrypt kry. Perfek hiervoor . Die kliënt is gerieflik en maklik om op te stel, en bowenal, dit laat jou toe om 'n domein/subdomein deur DNS via die ClouDNS API te valideer.
Ons sal acme.sh op slegs een van die bedieners installeer - Europese 199.247.18.199, waarvandaan sertifikate na al die ander gekopieer sal word. Om te installeer, hardloop:
root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrcTydens die installering van die skrif sal 'n CRON-werk geskep word vir verdere hernuwing van sertifikate sonder ons deelname.
Wanneer 'n sertifikaat uitgereik word, sal die domein nagegaan word met behulp van DNS met behulp van die API, dus in die ClouDNS persoonlike rekening in die Reseller API-kieslys, moet jy 'n nuwe gebruikers-API skep en 'n wagwoord daarvoor instel. Die gevolglike outoriteit-ID met 'n wagwoord sal in die lêer geskryf word ~/.acme.sh/dnsapi/dns_cloudns.sh (moet nie verwar word met lêer nie dns_clouddns.sh). Hier is die reëls wat nie kommentaar gelewer en geredigeer moet word nie:
CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"
Nou sal ons 'n SSL-sertifikaat vir cdn.sayt.in
root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"In die opsies, vir die toekoms, het ons 'n opdrag gespesifiseer om die webbedienerkonfigurasie outomaties te herlaai na elke hernuwing van die sertifikaatgeldigheidstydperk in die toekoms.
Die hele proses om 'n sertifikaat te bekom kan tot 2 minute neem, moenie dit onderbreek nie. As 'n domeinvalideringsfout voorkom, probeer weer om die opdrag uit te voer. Aan die einde sal ons sien waar die sertifikate opgelaai is:
Onthou hierdie paaie, hulle sal gespesifiseer moet word wanneer die sertifikaat na ander bedieners gekopieer word, sowel as in die webbedienerinstellings. Ons gee nie aandag aan die fout om Nginx-konfigurasies te herlaai nie - dit sal nie op 'n volledig gekonfigureerde bediener wees wanneer sertifikate opgedateer word nie.
Al wat ons oor het vir SSL is om die ontvangde sertifikaat na twee ander bedieners te kopieer terwyl die pad na die lêers behou word. Kom ons skep dieselfde dopgehou op elkeen van hulle en maak 'n kopie:
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/
Om sertifikate gereeld op te dateer, skep 'n daaglikse CRON-taak op beide bedieners met die opdrag:
scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload
In hierdie geval moet toegang tot die afgeleë bronbediener gekonfigureer word , d.w.s. sonder om 'n wagwoord in te voer. Moenie vergeet om dit te doen nie.
Installeer en konfigureer Nginx
Om statiese inhoud te bedien, sal ons Nginx gebruik wat as 'n kasinstaanbediener gekonfigureer is. Dateer die pakketlyste op en installeer dit op al drie bedieners:
root@cdn:~# apt update
root@cdn:~# apt install nginxIn plaas van die verstek, gebruik ons die konfigurasie vanaf die bederf hieronder:
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;
}
}
}Wysig in die konfigurasie:
- maksimum_grootte — die grootte van die kas, wat nie die beskikbare skyfspasie oorskry nie
- onaktiewe - bergingstyd van data in die kas waartoe niemand toegang het nie
- ssl_sertifikaat и ssl_sertifikaat_sleutel - paaie na SSL-sertifikaat en sleutellêers
- proxy_cache_valid - stoor tyd van gekas data
- proxy_pass - adres van die oorspronklike bediener waarvandaan die CDN lêers vir kas sal versoek. In ons voorbeeld, dit sê.in
Soos u kan sien, is alles eenvoudig. Moeilikheid kan slegs ontstaan om die kastyd in te stel as gevolg van die ooreenkomste van die riglyne onaktiewe и proxy_cache_valid. Kom ons ontleed hulle met ons voorbeeld. Hier is wat wanneer gebeur onaktief=7d и proxy_cache_valid 90d:
- as die versoek nie binne 7 dae herhaal word nie, sal die data na hierdie tydperk uit die kas verwyder word
- as die versoek ten minste een keer elke 7 dae herhaal word, sal die data in die kas na 90 dae as verouderd beskou word en met die volgende versoek sal Nginx dit opdateer en dit van die oorspronklike bediener af neem
Klaar om te wysig nginx.conf, herlaai die konfigurasie:
root@cdn:~# service nginx reloadOns CDN is gereed. Vir $15/maand. ons het punte van teenwoordigheid op drie vastelande ontvang en 3 TB verkeer: 1 TB op elke plek.
Kontroleer die werk van CDN
Kom ons kyk na die pings na ons CDN vanaf verskillende geografiese liggings. Enige ping-diens sal hiervoor werk.
Beginpunt
Gasheer
IP
Gem. tyd, me
Duitsland Berlyn
cdn.sayt.in
199.247.18.199
9.6
Nederland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1
Frankryk Parys
cdn.sayt.in
199.247.18.199
16.3
Groot-Brittanje, Londen
cdn.sayt.in
199.247.18.199
14.9
Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2
VSA, San Francisco
cdn.sayt.in
149.28.121.123
52.7
VSA, Dallas
cdn.sayt.in
149.28.121.123
23.1
VSA, Chicago
cdn.sayt.in
149.28.121.123
2.6
VSA, New York
cdn.sayt.in
149.28.121.123
19.8
Singapoer
cdn.sayt.in
157.230.240.216
1.7
Japan Tokio
cdn.sayt.in
157.230.240.216
74.8
Australië, Sydney
cdn.sayt.in
157.230.240.216
95.9
Die resultate is goed. Nou sal ons 'n toetsbeeld in die wortel van die hoofwebwerf plaas toets.jpg en kontroleer die aflaaispoed daarvan via CDN. Daar word gesê - . Inhoud word vinnig afgelewer.
Kom ons skryf 'n klein skrif vir ingeval ons die kas op die CDN-punt wil skoonmaak.
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
Om die hele kas uit te vee, hardloop dit net, 'n aparte lêer kan soos volg skoongemaak word:
root@cdn:~# ./purge.sh /test.jpgIn plaas van gevolgtrekkings
Ten slotte wil ek 'n paar nuttige wenke gee om dadelik oor die hark te trap wat my kop destyds seer gemaak het:
- Om die fouttoleransie van die CDN te verhoog, word dit aanbeveel om DNS Failover op te stel, wat help om die A-rekord vinnig te verander in die geval van 'n bedieneronderbreking. Dit word gedoen in die DNS-rekords van die beheerpaneel van die domein.
- Werwe met wye geografiese dekking benodig ongetwyfeld 'n groot aantal CDN's, maar laat ons nie fanaties wees nie. Heel waarskynlik sal die gebruiker nie 'n beduidende verskil sien in vergelyking met 'n betaalde CDN as jy bedieners op 6-7 plekke plaas nie: Europa, Noord-Amerika (oos), Noord-Amerika (wes), Singapoer, Australië, Hong Kong of Japan
- Soms laat gashere nie die gebruik van gehuurde bedieners vir CDN-doeleindes toe nie. Daarom, as u skielik besluit om 'n inhoudafleweringsnetwerk as 'n diens te ontplooi, moenie vergeet om vooraf die reëls van 'n spesifieke gasheerverskaffer te lees nie
- Verken om voor te stel hoe die vastelande verbind is en dit in ag te neem wanneer 'n inhoudafleweringsnetwerk gebou word
- Probeer om te kontroleer na jou bedieners. Op hierdie manier kan u die streke naaste aan die CDN-punte sien en GeoDNS meer korrek opstel
- Afhangende van die take, sal dit nuttig wees om Nginx te verfyn vir spesifieke kasvereistes en met inagneming van die las op die bediener. Die artikels oor Nginx-kas het my baie hierin gehelp - en versnelling van werk onder swaar vragte: и
Bron: will.com
