Content Delivery Networks (CDN) -verkkoja käytetään verkkosivustoissa ja sovelluksissa ensisijaisesti staattisten elementtien lataamisen nopeuttamiseen. Tämä johtuu tiedostojen tallentamisesta välimuistiin eri maantieteellisillä alueilla sijaitsevilla CDN-palvelimilla. Pyydettäessä tietoja CDN:n kautta käyttäjä saa ne lähimmältä palvelimelta.
Kaikkien sisällönjakeluverkostojen toimintaperiaate ja toimivuus ovat suunnilleen samat. Saatuaan tiedoston latauspyynnön CDN-palvelin ottaa sen kerran alkuperäiseltä palvelimelta ja antaa sen käyttäjälle samalla tallentaen sen välimuistiin tietyn ajan. Kaikkiin myöhemmiin pyyntöihin vastataan välimuistista. Kaikilla CDN-verkoilla on mahdollisuus esiladata tiedostoja, tyhjentää välimuisti, asettaa viimeinen voimassaolopäivä ja paljon muuta.
Tapahtuu, että syystä tai toisesta joutuu organisoimaan oman sisällönjakeluverkoston, ja sitten - olkoon seuraavan pyörän kokoamisohjeet meille avuksi.

Lähde:
Kun tarvitset oman CDN:n
Harkitse tapauksia, joissa oman CDN:n käyttäminen on järkevää:
- kun halutaan säästää rahaa ja käyttökustannuksia myös käytettäessä edullisia CDN-verkkoja, kuten on useita satoja dollareita kuukaudessa
- jos haluamme saada pysyvän välimuistin tai välimuistin ilman palvelin- ja kanavanaapureita
- CDN-palveluilla ei ole läsnäolopisteitä tarvitsemallasi alueella
- tarvittavat erityiset sisällön toimitusasetukset
- Haluamme nopeuttaa dynaamisen sisällön toimittamista sijoittamalla tuotantopalvelimen lähemmäs käyttäjiä
- on huoli siitä, että kolmannen osapuolen CDN-palvelu saattaa laittomasti kerätä tai käyttää tietoja käyttäjien käyttäytymisestä (hei ei-GDPR-yhteensopivia palveluja) tai osallistua muuhun laittomaan toimintaan
Useimmissa muissa tapauksissa on tarkoituksenmukaisempaa käyttää olemassa olevia valmiita ratkaisuja.
Mitä tarvitset aloittamiseen
On hienoa, jos sinulla on oma autonominen järjestelmä (AS). Sen avulla voit määrittää saman IP-osoitteen useille palvelimille ja verkkotasolla ohjaa käyttäjät lähimpään verkkoon. On syytä sanoa, että jopa /24-osoitelohkolla on mahdollista rakentaa sisällönjakeluverkko. Jotkin palvelintoimittajat antavat sinun tehdä ilmoituksen käytettäväksi kaikilla heidän käytettävissään olevilla alueilla.
Jos et ole onnellinen IP-osoitelohkon omistaja, tarvitset yksinkertaisen CDN:n suorittamiseen:
- verkkotunnuksen nimi tai aliverkkotunnus
- vähintään kaksi palvelinta eri alueilla. Palvelin voi olla joko omistettu tai virtuaalinen
- geoDNS-työkalu. Sen avulla käyttäjä, joka on osoittanut verkkotunnuksen, ohjataan lähimmälle palvelimelle
Rekisteröi verkkotunnus ja tilaa palvelimia
Verkkotunnuksen rekisteröinnissä kaikki on yksinkertaista - rekisteröimme millä tahansa vyöhykkeellä minkä tahansa rekisteröijän kanssa. Voit myös käyttää aliverkkotunnusta CDN:lle, esimerkiksi jotain vastaavaa cdn.domainname.com. Itse asiassa teemme esimerkissämme juuri niin.
Mitä tulee palvelimien tilaamiseen, ne tulee vuokrata niiltä alueilta ja maista, joissa käyttäjäyleisösi sijaitsee. Jos projekti on mannertenvälinen, on kätevää valita isännöintipalveluntarjoajat, jotka tarjoavat palvelimia kaikkialla maailmassa kerralla. Esimerkkejä: , и - omistetuille palvelimille, и — virtuaaliselle pilvelle*.
Yksityiselle CDN:llemme tilaamme 3 virtuaalipalvelinta eri mantereille. klo Vultr palvelimella varten 5 dollaria/kk me tulemme saamaan 25GB SSD paikat ja 1 Tt liikennettä. Kun asennat, valitse uusin Debian. Palvelimemme:
Frankfurt, ip: 199.247.18.199
Chicago, ip: 149.28.121.123
Singapore, ip: 157.230.240.216
* Vultr ja DigitalOcean lupaavat 100 dollarin luottoa käyttäjille, jotka rekisteröityvät artikkelin linkkien kautta heti maksutavan lisäämisen jälkeen. Kirjoittaja saa tästä myös pienen kohteliaisuuden, joka on hänelle nyt erittäin tärkeä. Ole ymmärtäväinen.
GeoDNS:n määrittäminen
Jotta käyttäjä ohjataan halutulle (lähimmälle) palvelimelle, kun hän käyttää verkkotunnusta tai CDN-aliverkkotunnusta, tarvitsemme DNS-palvelimen, jossa on geoDNS-toiminto.
GeoDNS:n periaate ja toiminta on seuraava:
- Määrittää DNS-pyynnön lähettäneen asiakkaan IP-osoitteen tai asiakaspyynnön käsittelyssä käytettävän rekursiivisen DNS-palvelimen IP-osoitteen. Tällaiset rekursiiviset palvelimet ovat yleensä palveluntarjoajien DNS-palvelimet.
- Asiakkaan IP tunnistaa hänen maansa tai alueensa. Tätä varten käytetään GeoIP-tietokantoja, joita on nykyään paljon. Hyviä on .
- Riippuen asiakkaan sijainnista, anna hänelle lähimmän CDN-palvelimen IP-osoite.
DNS-palvelin geoDNS-toiminnolla voi olla , mutta on parempi käyttää valmiita ratkaisuja DNS-palvelinverkon kanssa ympäri maailmaa ja laatikosta:
- alkaen 9.95 dollaria/kk, GeoDNS-tariffi, oletuksena on yksi DNS-varansiirto
- alkaen 25 dollaria/kk, DNS Failover käytössä
- alkaen 35 dollaria/kk netto 50 miljoonan maantieteellisen pyynnön osalta. DNS Failover laskutetaan erikseen
- alkaen 125 dollaria/kk, DNS-virheitä on 10
- , "Geo Steering" -ominaisuus on saatavilla yrityssuunnitelmissa
GeoDNS:ää tilattaessa kannattaa kiinnittää huomiota tariffiin sisältyvien pyyntöjen määrään ja muistaa, että verkkotunnukseen saapuvien pyyntöjen todellinen määrä voi moninkertaisesti ylittää odotukset. Miljoonat hämähäkit, skannerit, roskapostittajat ja muut pahat henget työskentelevät väsymättä.
Melkein kaikki DNS-palvelut sisältävät välttämättömän palvelun CDN:n rakentamiseen - DNS Failover. Sen avulla voit asettaa palvelintesi toiminnan valvonnan ja elämänmerkkien puuttuessa korvata automaattisesti ei-toimivan palvelimen osoitteen DNS-vastauksissa varmuuskopiolla.
Käytämme CDN:n rakentamiseen , GeoDNS-tariffi.
Lisätään uusi DNS-vyöhyke henkilökohtaiseen tiliisi määrittämällä verkkotunnuksesi. Jos rakennamme CDN:ää aliverkkotunnukselle ja päätoimialue on jo käytössä, älä unohda lisätä olemassa olevia toimivia DNS-tietueita heti vyöhykkeen lisäämisen jälkeen. Seuraava vaihe on luoda useita A-tietueita CDN-alueelle/aliverkkotunnukselle, joista kutakin sovelletaan määrittämäämme alueeseen. Voit määrittää maanosat tai maat alueiksi, osa-alueet ovat saatavilla USA:lle ja Kanadalle.
Meidän tapauksessamme CDN nostetaan aliverkkotunnukselle cdn.sayt.in. Lisäämällä vyöhykkeen sanot.in, luo ensimmäinen A-tietue aliverkkotunnukselle ja osoita koko Pohjois-Amerikka Chicagossa olevalle palvelimelle:

Toistetaan toiminto muille alueille, muistaen luoda yksi merkintä oletusalueille. Tässä on mitä tapahtuu lopussa:

Viimeinen oletusarvo kuvakaappauksessa tarkoittaa, että kaikki määrittelemättömät alueet (ja nämä ovat Eurooppa, Afrikka, satelliitti-Internetin käyttäjät jne.) lähetetään Frankfurtin palvelimelle.
Tämä päättää DNS-perusasetukset. On vielä siirryttävä verkkotunnuksen rekisteröijän verkkosivustolle ja korvattava nykyiset verkkotunnuksen NS:t ClouDNS:n myöntämillä. Ja samalla kun NS:itä päivitetään, valmistelemme palvelimia.
SSL-varmenteiden asennus
CDN toimii HTTPS:n yli, joten jos sinulla on jo SSL-varmenteita verkkotunnukselle tai aliverkkotunnukselle, lataa ne kaikille palvelimille, esimerkiksi hakemistoon. /etc/ssl/yourdomain/
Jos varmenteita ei ole, voit saada ilmaisen Let's Encryptin. Täydellinen tähän . Asiakas on kätevä ja helppo asentaa, ja mikä tärkeintä, sen avulla voit vahvistaa verkkotunnuksen/aliverkkotunnuksen DNS:n avulla ClouDNS API:n kautta.
Asennamme acme.sh:n vain yhdelle palvelimista - European 199.247.18.199, josta varmenteet kopioidaan kaikille muille. Asenna suorittamalla:
root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrcSkriptin asennuksen aikana luodaan CRON-työ, jolla varmenteet voidaan uusia ilman osallistumistamme.
Varmennetta myönnettäessä verkkotunnus tarkistetaan DNS:n avulla API:n avulla, joten CloudDNS-henkilökohtaisessa tilissä Jälleenmyyjän API-valikossa on luotava uusi käyttäjäsovellusliittymä ja asetettava sille salasana. Tuloksena oleva auth-id ja salasana kirjoitetaan tiedostoon ~/.acme.sh/dnsapi/dns_cloudns.sh (ei pidä sekoittaa tiedostoon dns_clouddns.sh). Tässä ovat rivit, jotka on poistettava kommenteista ja joita on muokattava:
CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"
Nyt pyydämme SSL-varmennetta cdn.sayt.in
root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"Vaihtoehtoihin olemme jatkossa määrittäneet komennon, joka lataa verkkopalvelimen asetukset automaattisesti uudelleen jokaisen varmenteen voimassaoloajan uusimisen jälkeen.
Koko varmenteen hankintaprosessi voi kestää jopa 2 minuuttia, älä keskeytä sitä. Jos tapahtuu toimialueen vahvistusvirhe, yritä suorittaa komento uudelleen. Lopussa näemme, mihin varmenteet on ladattu:

Muista nämä polut, ne on määritettävä kopioitaessa varmennetta muille palvelimille sekä verkkopalvelimen asetuksissa. Emme kiinnitä huomiota virheeseen Nginx-asetusten uudelleenlatauksessa - se ei ole täysin määritetyllä palvelimella varmenteita päivitettäessä.
SSL:lle ei jää muuta kuin kopioida vastaanotettu varmenne kahdelle muulle palvelimelle säilyttäen tiedostojen polun. Luodaan samat hakemistot jokaiselle niistä ja kopioidaan:
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/
Päivitä varmenteet säännöllisesti luomalla päivittäinen CRON-työ molemmille palvelimille komennolla:
scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload
Tässä tapauksessa pääsy etälähdepalvelimeen on määritettävä , eli ilman salasanaa. Älä unohda tehdä sitä.
Nginxin asennus ja konfigurointi
Staattisen sisällön palvelemiseen käytämme välimuistipalvelimeksi määritettyä Nginxiä. Päivitä pakettiluettelot ja asenna se kaikkiin kolmeen palvelimeen:
root@cdn:~# apt update
root@cdn:~# apt install nginxOletusasetuksen sijaan käytämme alla olevan spoilerin konfiguraatiota:
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;
}
}
}Muokkaa asetuksissa:
- max_size — välimuistin koko, joka ei ylitä käytettävissä olevaa levytilaa
- toimeton - välimuistissa olevien tietojen säilytysaika, jota kukaan ei käyttänyt
- ssl_certificate и ssl_certificate_key — polut SSL-varmenteeseen ja avaintiedostoihin
- proxy_cache_valid - välimuistissa olevien tietojen säilytysaika
- proxy_pass — alkuperäisen palvelimen osoite, josta CDN pyytää tiedostoja välimuistiin tallennettavaksi. Esimerkissämme tämä sanot.in
Kuten näet, kaikki on yksinkertaista. Vaikeuksia voi syntyä vain välimuistiajan asettamisessa, koska direktiivit ovat samankaltaisia toimeton и proxy_cache_valid. Analysoidaan niitä esimerkillämme. Tässä on mitä tapahtuu, kun ei-aktiivinen=7pv и proxy_cache_valid 90d:
- jos pyyntöä ei toisteta 7 päivän kuluessa, tiedot poistetaan välimuistista tämän ajanjakson jälkeen
- jos pyyntö toistetaan vähintään kerran 7 päivässä, välimuistin tiedot katsotaan vanhentuneiksi 90 päivän kuluttua ja Nginx päivittää ne seuraavalla pyynnöllä ottamalla ne alkuperäiseltä palvelimelta
Muokkaus valmis nginx.conf, lataa asetukset uudelleen:
root@cdn:~# service nginx reloadCDN on valmis. Hinta 15 dollaria/kk. saimme läsnäolopisteitä kolmella mantereella ja 3 TB liikennettä: 1 TB jokaisessa paikassa.
CDN:n toiminnan tarkistaminen
Tarkastellaan eri maantieteellisistä paikoista saapuvia ping-viestejä CDN:ään. Mikä tahansa ping-palvelu toimii tähän.
Käynnistyspiste
isäntä
IP
Keskimääräinen aika, ms
Saksa Berliini
cdn.sayt.in
199.247.18.199
9.6
Alankomaat, Amsterdam
cdn.sayt.in
199.247.18.199
10.1
Ranska Pariisi
cdn.sayt.in
199.247.18.199
16.3
Iso-Britannia, Lontoo
cdn.sayt.in
199.247.18.199
14.9
Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2
USA, San Francisco
cdn.sayt.in
149.28.121.123
52.7
USA, Dallas
cdn.sayt.in
149.28.121.123
23.1
USA, Chicago
cdn.sayt.in
149.28.121.123
2.6
Yhdysvallat, New York
cdn.sayt.in
149.28.121.123
19.8
Singapore
cdn.sayt.in
157.230.240.216
1.7
Japani Tokio
cdn.sayt.in
157.230.240.216
74.8
Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9
Tulokset ovat hyviä. Nyt laitamme testikuvan pääsivuston juureen testi.jpg ja tarkista sen latausnopeus CDN:n kautta. On sanottu - . Sisältö toimitetaan nopeasti.
Kirjoita pieni komentosarja siltä varalta, että haluamme tyhjentää CDN-pisteen välimuistin.
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
Jos haluat poistaa koko välimuistin, suorita se, erillinen tiedosto voidaan puhdistaa seuraavasti:
root@cdn:~# ./purge.sh /test.jpgPäätelmien sijasta
Lopuksi haluan antaa hyödyllisiä vinkkejä, jotta voin astua välittömästi sen haravan yli, joka sai tuolloin päätäni kipeäksi:
- CDN:n vikasietoisuuden lisäämiseksi on suositeltavaa määrittää DNS Failover, joka auttaa nopeasti muuttamaan A-tietuetta palvelimen rikkoutuessa. Tämä tehdään toimialueen ohjauspaneelin DNS-tietueissa.
- Laajan maantieteellisen kattavuuden omaavat sivustot vaativat epäilemättä suuren määrän CDN-verkkoja, mutta älkäämme olko fanaattisia. Todennäköisesti käyttäjä ei huomaa merkittävää eroa maksulliseen CDN:ään verrattuna, jos sijoitat palvelimia 6-7 paikkaan: Eurooppa, Pohjois-Amerikka (itä), Pohjois-Amerikka (länsi), Singapore, Australia, Hong Kong tai Japani
- Joskus isännöitsijät eivät salli vuokrattujen palvelimien käyttöä CDN-tarkoituksiin. Siksi, jos päätät yhtäkkiä ottaa sisällönjakeluverkon käyttöön palveluna, älä unohda lukea tietyn isännöintipalveluntarjoajan säännöt etukäteen
- Tutkia edustaa maanosien yhteyttä ja ottaa tämä huomioon sisällönjakeluverkostoa rakentaessaan
- Yritä tarkistaa palvelimillesi. Näin näet CDN-pisteitä lähinnä olevat alueet ja määrität GeoDNS:n paremmin
- Tehtävistä riippuen on hyödyllistä hienosäätää Nginx tiettyjä välimuistivaatimuksia varten ja ottaa huomioon palvelimen kuormitus. Nginx-välimuistia koskevat artikkelit auttoivat minua paljon tässä - ja työn nopeuttaminen raskaan kuorman alla: и
Lähde: will.com
