ProHoster > Блог > Administrado > Konstruante kaj agordante vian CDN

Konstruante kaj agordante vian CDN

Enhavaj Liveraj Retoj (CDN) estas uzataj en retejoj kaj aplikoj ĉefe por akceli la ŝarĝon de senmovaj elementoj. Ĉi tio okazas pro la kaŝmemoro de dosieroj sur CDN-serviloj situantaj en malsamaj geografiaj regionoj. Petante datumojn per CDN, la uzanto ricevas ĝin de la plej proksima servilo.

La principo de funkciado kaj funkcieco de ĉiuj enhavo-liveraj retoj estas proksimume la sama. Ricevinte peton elŝuti dosieron, la CDN-servilo prenas ĝin unufoje de la origina servilo kaj donas ĝin al la uzanto, samtempe konservante ĝin dum difinita tempodaŭro. Ĉiuj postaj petoj estas responditaj el la kaŝmemoro. Ĉiuj CDN-oj havas eblojn por antaŭŝargi dosierojn, forigi la kaŝmemoron, agordi la limdaton kaj pli.

Okazas, ke, ial aŭ alia, vi devas organizi vian propran enhavan liveran reton, kaj poste - la instrukcioj por kunmeti la sekvan biciklon helpi nin.

Konstruante kaj agordante vian CDN
fonto: Infografia vektoro kreita de pikisuperstar - www.freepik.com

Kiam vi bezonas vian propran CDN

Konsideru la kazojn kie ruli vian propran CDN havas sencon:

  • kiam estas deziro ŝpari monon, kaj kurantaj kostoj eĉ kiam oni uzas malmultekostajn CDNojn kiel KunikletoCDN sumo al kelkcent dolaroj monate
  • se ni volas akiri konstantan kaŝmemoron aŭ kaŝmemoron sen servilo kaj kanalo najbaroj
  • CDN-servoj ne havas punktojn de ĉeesto en la regiono, kiun vi bezonas
  • ajna speciala enhavo livero agordojn necesas
  • ni volas akceli la liveron de dinamika enhavo metante la produktan servilon pli proksime al uzantoj
  • estas zorgo, ke triaparta CDN-servo povas kontraŭleĝe kolekti aŭ uzi informojn pri uzantkonduto (saluton ne-konformaj al GDPR-servoj) aŭ okupiĝi pri aliaj kontraŭleĝaj agadoj.

En la plej multaj aliaj kazoj, estas pli konvene uzi ekzistantajn pretajn solvojn.

Kion vi bezonas por komenci

Estas mirinde se vi havas vian propran Aŭtonoman Sistemon (AS). Per ĝi, vi povas atribui la saman IP al pluraj serviloj kaj laŭ ĉi tiu instrukcio ĉe la retonivelo, direktu uzantojn al la plej proksima. Indas diri, ke eĉ kun la adresbloko /24, eblas konstrui enhavan liveran reton. Iuj servilprovizantoj permesas vin fari anoncon por uzo en ĉiuj regionoj disponeblaj al ili.

Se vi ne estas feliĉa posedanto de bloko de IP-adresoj, tiam por ruli simplan CDN vi bezonos:

  • domajna nomo aŭ subdomajno
  • almenaŭ du serviloj en malsamaj regionoj. La servilo povas esti aŭ dediĉita aŭ virtuala
  • geoDNS-ilo. Per ĝi, la uzanto, adresinte la domajnon, estos direktita al la plej proksima servilo

Registri domajnon kaj mendi servilojn

Kun domajna registrado, ĉio estas simpla - ni registras en iu ajn zono ĉe iu registristo. Vi ankaŭ povas uzi subdomajnon por CDN, ekzemple ion similan cdn.domainname.com. Efektive, en nia ekzemplo, ni faros ĝuste tion.

Koncerne mendi servilojn, ili devus esti luitaj en la regionoj kaj landoj, kie troviĝas via uzantspektantaro. Se la projekto estas interkontinenta, tiam estas oportune elekti gastigantajn provizantojn, kiuj ofertas servilojn tra la tuta mondo samtempe. Ekzemploj: OVH, luo retejo и 100Tb - por dediĉitaj serviloj, Vultr и Digitalulocean — por virtuala nubo*.

Por nia privata CDN, ni mendos 3 virtualajn servilojn sur malsamaj kontinentoj. Ĉe Vultr sur la servilo por $ 5/monato ni ricevos 25GB SSD lokoj kaj 1TB da trafiko. Kiam vi instalas, elektu la plej novan Debianon. Niaj serviloj:

Konstruante kaj agordante vian CDN Frankfurto, ip: 199.247.18.199

Konstruante kaj agordante vian CDN Ĉikago, ip: 149.28.121.123

Konstruante kaj agordante vian CDN Сингапур, ip: 157.230.240.216

* Vultr kaj DigitalOcean promesas $100-krediton al uzantoj, kiuj registras per la ligiloj en la artikolo tuj post aldoni pagmetodon. La aŭtoro ricevas ankaŭ de ĉi tio komplimenton, kiu nun estas tre signifa por li. Bonvolu esti komprenema.

Agordi geoDNS

Por ke la uzanto estu direktita al la dezirata (plej proksima) servilo dum aliro al domajno aŭ CDN-subdomajno, ni bezonas DNS-servilon kun la funkcio geoDNS.

La principo kaj operacio de geoDNS estas kiel sekvas:

  1. Specifas la IP de la kliento kiu sendis la DNS-peton, aŭ la IP de la rekursiva DNS-servilo kiu estas uzata dum prilaborado de la kliento-peto. Tiaj rekursiaj serviloj estas kutime DNS-oj de provizantoj.
  2. La IP de la kliento rekonas lian landon aŭ regionon. Por tio, GeoIP-datumbazoj estas uzataj, el kiuj estas multaj hodiaŭ. Estas bonaj senpagaj elektoj.
  3. Depende de la loko de la kliento, donas al li la IP-adreson de la plej proksima CDN-servilo.

DNS-servilo kun geoDNS-funkcio povas esti kunveni mem, sed estas pli bone uzi pretajn solvojn kun reto de DNS-serviloj tra la mondo kaj Anycast el la skatolo:

  • CloudDNS el $ 9.95/monato, GeoDNS tarifo, defaŭlte ekzistas unu DNS-malsukceso
  • Zilore el $ 25/monato, DNS-malsukceso ebligita
  • Amazona Itinero 53 el $ 35/monato por netaj 50M geo-petoj. DNS-malsukceso estas fakturita aparte
  • DNS Facila el $ 125/monato, estas 10 DNS-malsukcesigoj
  • cloudflare, "Geo-Stirado" funkcio estas havebla en Enterprise-planoj

Mendante geoDNS, vi devas atenti la nombron da petoj inkluzivitaj en la tarifo kaj memoru, ke la reala nombro da petoj al la domajno povas plurfoje superi atendojn. Milionoj da araneoj, skaniloj, spamistoj kaj aliaj malbonaj spiritoj laboras senlace.

Preskaŭ ĉiuj DNS-servoj inkluzivas nemalhaveblan servon por konstrui CDN - DNS Failover. Kun ĝia helpo, vi povas agordi monitoradon de la funkciado de viaj serviloj kaj, en foresto de signoj de vivo, aŭtomate anstataŭigi la adreson de nefunkcianta servilo per rezerva en DNS-respondoj.

Por konstrui nian CDN, ni uzos CloudDNS, GeoDNS tarifo.

Ni aldonu novan DNS-zonon en via persona konto, specifante vian domajnon. Se ni konstruas CDN sur subdomajno, kaj la ĉefa domajno jam estas uzata, tuj post aldoni la zonon, ne forgesu aldoni la ekzistantajn funkciajn DNS-rekordojn. La sekva paŝo estas krei plurajn A-rekordojn por la CDN-domajno / subdomajno, ĉiu el kiuj estos aplikita al la regiono, kiun ni specifis. Vi povas specifi kontinentojn aŭ landojn kiel regionojn, subregionoj disponeblas por Usono kaj Kanado.

En nia kazo, la CDN estos levita sur subdomajno cdn.sayt.in. Aldonante zonon sayt.in, kreu la unuan A-rekordon por la subdomajno kaj direktu la tutan Nordamerikon al la servilo en Ĉikago:

Konstruante kaj agordante vian CDN
Ni ripetu la agon por aliaj regionoj, memorante krei unu eniron por la defaŭltaj regionoj. Jen kio okazas finfine:

Konstruante kaj agordante vian CDN

La lasta defaŭlta eniro en la ekrankopio signifas, ke ĉiuj nespecifitaj regionoj (kaj ĉi tiuj estas Eŭropo, Afriko, satelitaj retuzantoj, ktp.) estos senditaj al la servilo en Frankfurto.

Ĉi tio kompletigas la bazan DNS-agordon. Restas iri al la retejo de la domajna registristo kaj anstataŭigi la nunajn domajnan NS-ojn per tiuj eldonitaj de ClouDNS. Kaj dum la NS-oj estos ĝisdatigitaj, ni preparos la servilojn.

Instalado de SSL-atestiloj

Nia CDN funkcios per HTTPS, do se vi jam havas SSL-atestilojn por domajno aŭ subdomajno, alŝutu ilin al ĉiuj serviloj, ekzemple, al la dosierujo. /etc/ssl/via domajno/

Se ne ekzistas atestiloj, vi povas ricevi senpagan de Let's Encrypt. Perfekte por ĉi tio ACME Shellscript. La kliento estas oportuna kaj facile instalebla, kaj plej grave, ĝi permesas vin validigi domajnon/subdomajnon per DNS per la API de ClouDNS.

Ni instalos acme.sh sur nur unu el la serviloj - Eŭropa 199.247.18.199, de kiu atestiloj estos kopiitaj al ĉiuj aliaj. Por instali, rulu:

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

Dum la instalado de la skripto, CRON-laboro estos kreita por plua renovigo de atestiloj sen nia partopreno.

Eldonante atestilon, la domajno estos kontrolita per DNS per la API, do en la persona konto de ClouDNS en la Reseller API-menuo, vi devas krei novan uzantan API kaj agordi pasvorton por ĝi. La rezulta aŭt-id kun pasvorto estos skribita en la dosiero ~/.acme.sh/dnsapi/dns_cloudns.sh (ne konfuzu kun dosiero dns_clouddns.sh). Jen la linioj kiuj devas esti nekomentitaj kaj redaktitaj:

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

Nun ni petos SSL-atestilon por cdn.sayt.in

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

En la ebloj, por la estonteco, ni specifis komandon por aŭtomate reŝargi la agordon de la retservilo post ĉiu renovigo de la validecperiodo de atestilo en la estonteco.

La tuta procezo por akiri atestilon povas daŭri ĝis 2 minutojn, ne interrompu ĝin. Se okazas eraro pri validado de domajna, provu ruli la komandon denove. Je la fino ni vidos kie la atestiloj estis alŝutitaj:

Konstruante kaj agordante vian CDN

Memoru ĉi tiujn vojojn, ili devos esti specifitaj dum kopiado de la atestilo al aliaj serviloj, same kiel en la agordoj de la retservilo. Ni ne atentas la eraron de reŝargi Nginx-agordojn - ĝi ne estos sur plene agordita servilo dum ĝisdatigo de atestiloj.

Restas nur por SSL kopii la ricevitan atestilon al du aliaj serviloj konservante la vojon al la dosieroj. Ni kreu la samajn dosierujojn sur ĉiu el ili kaj faru kopion:

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/

Por ĝisdatigi atestojn regule, kreu ĉiutagan CRON-laboron en ambaŭ serviloj per la komando:

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

En ĉi tiu kazo, aliro al la fora fontservilo devas esti agordita per ŝlosilo, t.e. sen enigi pasvorton. Ne forgesu fari ĝin.

Instalado kaj agordo de Nginx

Por servi statikan enhavon, ni uzos Nginx agorditan kiel kaŝmemoran prokurilon. Ĝisdatigu la paklistojn kaj instalu ĝin sur ĉiuj tri serviloj:

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

Anstataŭ la defaŭlta, ni uzas la agordon de la suba spoiler:
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;
    }
  }
}

Redaktu en la agordo:

  • maksimuma_grandeco — la grandeco de la kaŝmemoro, ne superante la disponeblan diskspacon
  • neaktiva - konservada tempo de kaŝmemoritaj datumoj, kiujn neniu aliris
  • ssl_atestilo и ssl_certificate_key — vojoj al SSL-atestilo kaj ŝlosilaj dosieroj
  • proxy_cache_valid - konservada tempo de kaŝmemoritaj datumoj
  • prokura_paso — adreso de la origina servilo de kiu la CDN petos dosierojn por kaŝmemoro. En nia ekzemplo, ĉi tio sayt.in

Kiel vi povas vidi, ĉio estas simpla. Malfacilo povas ekesti nur en agordo de la kaŝmemortempo pro la simileco de la direktivoj neaktiva и proxy_cache_valid. Ni analizu ilin per nia ekzemplo. Jen kio okazas kiam neaktiva=7d и proxy_cache_valid 90d:

  • se la peto ne ripetas ene de 7 tagoj, tiam la datumoj estos forigitaj el la kaŝmemoro post ĉi tiu periodo
  • se la peto ripetiĝas almenaŭ unufoje ĉiun 7 tagojn, tiam la datumoj en la kaŝmemoro estos konsiderataj malnoviĝintaj post 90 tagoj kaj Nginx ĝisdatigos ĝin kun la sekva peto, prenante ĝin de la origina servilo.

Finis redakti nginx.conf, reŝargu la agordon:

root@cdn:~# service nginx reload

Nia CDN estas preta. Por $15/monato. ni ricevis punktojn de ĉeesto sur tri kontinentoj kaj 3 TB de trafiko: 1 TB en ĉiu loko.

Kontrolante la laboron de CDN

Ni rigardu la pingojn al nia CDN de malsamaj geografiaj lokoj. Ajna ping-servo funkcios por tio.

Lanĉpunkto
Gastiganto
IP
Meza tempo, ms

Germanio Berlino
cdn.sayt.in
199.247.18.199
9.6

Nederlando, Amsterdamo
cdn.sayt.in
199.247.18.199
10.1

Francio Parizo
cdn.sayt.in
199.247.18.199
16.3

Unuiĝinta Reĝlando, Londono
cdn.sayt.in
199.247.18.199
14.9

Kanado, Toronto
cdn.sayt.in
149.28.121.123
16.2

Usono, San Francisco
cdn.sayt.in
149.28.121.123
52.7

Usono, Dallas
cdn.sayt.in
149.28.121.123
23.1

Usono, Ĉikago
cdn.sayt.in
149.28.121.123
2.6

Usono, Novjorko
cdn.sayt.in
149.28.121.123
19.8

Сингапур
cdn.sayt.in
157.230.240.216
1.7

Japanio Tokio
cdn.sayt.in
157.230.240.216
74.8

Aŭstralio, Sidnejo
cdn.sayt.in
157.230.240.216
95.9

La rezultoj estas bonaj. Nun ni metos testan bildon en la radikon de la ĉefa retejo testo.jpg kaj kontrolu ĝian elŝutan rapidon per CDN. Oni diras - farita. Enhavo estas liverita rapide.

Ni skribu malgrandan skripton, se ni volas forigi la kaŝmemoron sur la CDN-punkto.
purigi.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

Por forigi la tutan kaŝmemoron, simple rulu ĝin, aparta dosiero povas esti purigita jene:

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

Anstataŭ konkludoj

Fine, mi volas doni kelkajn utilajn konsiletojn por tuj transpaŝi la rastilon, kiu tiam dolorigis mian kapon:

  • Por pliigi la misfunkciadon de la CDN, oni rekomendas agordi DNS Failover, kiu helpas rapide ŝanĝi la A-rekordon en kazo de paneo de servilo. Ĉi tio estas farita en la kontrolpanelo DNS-rekordoj de la domajno.
  • Retejoj kun larĝa geografia kovrado sendube postulas grandan nombron da CDN-oj, sed ni ne estu fanatikaj. Plej verŝajne, la uzanto ne rimarkos gravan diferencon kompare kun pagita CDN, se vi metas servilojn en 6-7 lokoj: Eŭropo, Nordameriko (oriente), Nordameriko (okcidente), Singapuro, Aŭstralio, Honkongo aŭ Japanio.
  • Foje gastigantoj ne permesas la uzon de luitaj serviloj por CDN-celoj. Tial, se vi subite decidas disfaldi enhavan liveran reton kiel servon, ne forgesu legi la regulojn de aparta gastiganta provizanto anticipe.
  • Esploru subakva komunika maporeprezenti kiel la kontinentoj estas konektitaj kaj konsideri tion dum konstruado de enhavo-livera reto
  • Provu kontroli pings el diversaj lokoj al viaj serviloj. Tiel vi povas vidi la plej proksimajn regionojn al la CDN-punktoj kaj agordi GeoDNS pli ĝuste
  • Depende de la taskoj, estos utile agordi Nginx por specifaj kaŝmemorpostuloj kaj konsiderante la ŝarĝon sur la servilo. La artikoloj pri Nginx-kaŝmemoro multe helpis min en ĉi tio - tie kaj akcelo de laboro sub pezaj ŝarĝoj: tie и tie

fonto: www.habr.com