ProHoster > Blog > Pangangasiwa > Pagbuo at pag-configure ng iyong CDN

Pagbuo at pag-configure ng iyong CDN

Ang Content Delivery Networks (CDNs) ay ginagamit sa mga website at application lalo na para mapabilis ang paglo-load ng mga static na elemento. Nangyayari ito dahil sa pag-cache ng mga file sa mga server ng CDN na matatagpuan sa iba't ibang mga heograpikal na rehiyon. Sa pamamagitan ng paghiling ng data sa pamamagitan ng CDN, natatanggap ito ng user mula sa pinakamalapit na server.

Ang prinsipyo ng pagpapatakbo at paggana ng lahat ng network ng paghahatid ng nilalaman ay halos pareho. Pagkatanggap ng kahilingang mag-download ng file, kinukuha ito ng CDN server nang isang beses mula sa orihinal na server at ibibigay ito sa user, kasabay ng pag-cache nito para sa isang tinukoy na tagal ng panahon. Lahat ng kasunod na kahilingan ay sinasagot mula sa cache. Ang lahat ng mga CDN ay may mga opsyon upang mag-preload ng mga file, i-clear ang cache, itakda ang petsa ng pag-expire, at higit pa.

Nangyayari na, para sa isang kadahilanan o iba pa, kailangan mong ayusin ang iyong sariling network ng paghahatid ng nilalaman, at pagkatapos - hayaan ang mga tagubilin para sa pag-assemble ng susunod na bike ay makakatulong sa amin.

Pagbuo at pag-configure ng iyong CDN
Pinagmulan: Infographic vector na nilikha ng pikisuperstar - www.freepik.com

Kapag kailangan mo ng sarili mong CDN

Isaalang-alang ang mga kaso kung saan ang pagpapatakbo ng iyong sariling CDN ay may katuturan:

  • kapag may pagnanais na makatipid ng pera, at mga gastos sa pagpapatakbo kahit na gumagamit ng murang mga CDN tulad ng BunnyCDN halaga ng ilang daang dolyar sa isang buwan
  • kung gusto naming makakuha ng permanenteng cache o cache na walang server at channel na mga kapitbahay
  • Ang mga serbisyo ng CDN ay walang mga punto ng presensya sa rehiyon na kailangan mo
  • anumang espesyal na setting ng paghahatid ng nilalaman na kinakailangan
  • gusto naming pabilisin ang paghahatid ng dynamic na content sa pamamagitan ng paglalagay ng production server na mas malapit sa mga user
  • may alalahanin na ang isang third-party na serbisyo ng CDN ay maaaring ilegal na mangolekta o gumamit ng impormasyon tungkol sa pag-uugali ng user (hello non-GDPR-compliant na mga serbisyo) o makisali sa iba pang ilegal na aktibidad

Sa karamihan ng iba pang mga kaso, mas angkop na gumamit ng mga umiiral nang handa na solusyon.

Ano ang kailangan mong simulan

Napakaganda kung mayroon kang sariling Autonomous System (AS). Gamit ito, maaari kang magtalaga ng parehong IP sa ilang mga server at ayon sa tagubiling ito sa antas ng network, idirekta ang mga user sa pinakamalapit. Ito ay nagkakahalaga na sabihin na kahit na may /24 address block, posible na bumuo ng isang network ng paghahatid ng nilalaman. Binibigyang-daan ka ng ilang provider ng server na gumawa ng anunsyo para magamit sa lahat ng rehiyong magagamit nila.

Kung hindi ka masaya na may-ari ng isang bloke ng mga IP address, para magpatakbo ng isang simpleng CDN kakailanganin mo:

  • domain name o subdomain
  • hindi bababa sa dalawang server sa magkaibang mga rehiyon. Ang server ay maaaring maging dedikado o virtual
  • tool ng geoDNS. Sa pamamagitan nito, ang gumagamit, na natugunan ang domain, ay ididirekta sa pinakamalapit na server

Magrehistro ng domain at mag-order ng mga server

Sa pagpaparehistro ng domain, ang lahat ay simple - nagrerehistro kami sa anumang zone sa anumang registrar. Maaari ka ring gumamit ng subdomain para sa isang CDN, halimbawa tulad ng cdn.domainname.com. Sa totoo lang, sa aming halimbawa, gagawin namin iyon.

Tulad ng para sa pag-order ng mga server, dapat na arkilahin ang mga ito sa mga rehiyon at bansa kung saan matatagpuan ang iyong madla ng gumagamit. Kung intercontinental ang proyekto, maginhawang pumili ng mga hosting provider na nag-aalok ng mga server sa buong mundo nang sabay-sabay. Mga halimbawa: OVH, lease web ΠΈ 100TB - para sa mga nakalaang server, Vultr ΠΈ DigitalOcean β€” para sa virtual na ulap*.

Para sa aming pribadong CDN, mag-o-order kami ng 3 virtual server sa iba't ibang kontinente. Sa Vultr sa server para sa $5/buwan kukunin namin 25GB SSD mga lugar at 1TB ng trapiko. Kapag nag-i-install, piliin ang pinakabagong Debian. Ang aming mga server:

Pagbuo at pag-configure ng iyong CDN Frankfurt, ip: 199.247.18.199

Pagbuo at pag-configure ng iyong CDN Tsikago, ip: 149.28.121.123

Pagbuo at pag-configure ng iyong CDN Singgapur, ip: 157.230.240.216

*Nangangako ang Vultr at DigitalOcean ng $100 na kredito sa mga user na nagparehistro sa pamamagitan ng mga link sa artikulo kaagad pagkatapos magdagdag ng paraan ng pagbabayad. Nakatanggap din ang may-akda ng isang maliit na papuri mula dito, na napakahalaga para sa kanya ngayon. Mangyaring maging maunawain.

Pagse-set up ng geoDNS

Upang maidirekta ang user sa gustong (pinakamalapit) na server kapag nag-a-access ng domain o CDN subdomain, kailangan namin ng DNS server na may geoDNS function.

Ang prinsipyo at pagpapatakbo ng geoDNS ay ang mga sumusunod:

  1. Tinutukoy ang IP ng client na nagpadala ng kahilingan sa DNS, o ang IP ng recursive DNS server na ginagamit kapag pinoproseso ang kahilingan ng kliyente. Ang ganitong mga recursive server ay karaniwang mga DNS-s ng mga provider.
  2. Kinikilala ng IP ng kliyente ang kanyang bansa o rehiyon. Para dito, ginagamit ang mga database ng GeoIP, kung saan napakarami na ngayon. May mga magaling libreng mga pagpipilian.
  3. Depende sa lokasyon ng kliyente, binibigyan siya ng IP address ng pinakamalapit na CDN server.

DNS server na may geoDNS function ay maaaring mag-ipon nang mag-isa, ngunit mas mainam na gumamit ng mga handa na solusyon sa isang network ng mga DNS server sa buong mundo at Anycast mula sa kahon:

  • CloudDNS mula sa $9.95/buwan, GeoDNS taripa, bilang default mayroong isang DNS Failover
  • Zilore mula sa $25/buwan, pinagana ang DNS Failover
  • Amazon Route 53 mula sa $35/buwan para sa isang netong 50M geo-request. Ang DNS Failover ay sinisingil nang hiwalay
  • Pinadali ang DNS mula sa $125/buwan, mayroong 10 DNS Failovers
  • CloudFlare, available ang feature na "Geo Steering" sa mga Enterprise plan

Kapag nag-order ng geoDNS, dapat mong bigyang pansin ang bilang ng mga kahilingan na kasama sa taripa at tandaan na ang aktwal na bilang ng mga kahilingan sa domain ay maaaring lumampas sa mga inaasahan nang ilang beses. Milyun-milyong spider, scanner, spammer at iba pang masasamang espiritu ang walang pagod na nagtatrabaho.

Halos lahat ng serbisyo ng DNS ay may kasamang kailangang-kailangan na serbisyo para sa pagbuo ng CDN - DNS Failover. Sa tulong nito, maaari mong i-set up ang pagsubaybay sa pagpapatakbo ng iyong mga server at, sa kawalan ng mga palatandaan ng buhay, awtomatikong palitan ang address ng isang hindi gumaganang server ng isang backup na isa sa mga tugon sa DNS.

Upang bumuo ng aming CDN, gagamitin namin CloudDNS, taripa ng GeoDNS.

Magdagdag tayo ng bagong DNS zone sa iyong personal na account, na tumutukoy sa iyong domain. Kung tayo ay nagtatayo ng CDN sa isang subdomain, at ang pangunahing domain ay ginagamit na, pagkatapos kaagad pagkatapos idagdag ang zone, huwag kalimutang idagdag ang umiiral na gumaganang mga tala ng DNS. Ang susunod na hakbang ay gumawa ng ilang A-record para sa CDN domain / subdomain, bawat isa ay ilalapat sa rehiyon na aming tinukoy. Maaari mong tukuyin ang mga kontinente o bansa bilang mga rehiyon, ang mga sub-rehiyon ay magagamit para sa USA at Canada.

Sa aming kaso, ang CDN ay itataas sa isang subdomain cdn.sayt.in. Sa pamamagitan ng pagdaragdag ng isang zone sayt.in, lumikha ng unang A-record para sa subdomain at ituro ang lahat ng North America sa server sa Chicago:

Pagbuo at pag-configure ng iyong CDN
Ulitin natin ang pagkilos para sa ibang mga rehiyon, na inaalala na gumawa ng isang entry para sa mga default na rehiyon. Narito kung ano ang mangyayari sa dulo:

Pagbuo at pag-configure ng iyong CDN

Ang huling default na entry sa screenshot ay nangangahulugan na ang lahat ng hindi natukoy na mga rehiyon (at ito ay Europe, Africa, satellite Internet user, atbp.) ay ipapadala sa server sa Frankfurt.

Kinukumpleto nito ang pangunahing pag-setup ng DNS. Nananatili itong pumunta sa website ng domain registrar at palitan ang kasalukuyang mga domain NS ng mga ibinigay ng ClouDNS. At habang ina-update ang mga NS, ihahanda namin ang mga server.

Pag-install ng mga SSL certificate

Ang aming CDN ay gagana sa HTTPS, kaya kung mayroon ka nang mga SSL certificate para sa isang domain o subdomain, i-upload ang mga ito sa lahat ng mga server, halimbawa, sa direktoryo /etc/ssl/yourdomain/

Kung walang mga sertipiko, maaari kang makakuha ng libre mula sa Let's Encrypt. Perpekto para dito ACME Shellscript. Ang kliyente ay maginhawa at madaling i-set up, at higit sa lahat, pinapayagan ka nitong patunayan ang isang domain/subdomain sa pamamagitan ng DNS sa pamamagitan ng ClouDNS API.

Mag-i-install kami ng acme.sh sa isa lang sa mga server - European 199.247.18.199, kung saan kokopyahin ang mga certificate sa lahat ng iba pa. Upang i-install, patakbuhin ang:

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

Sa panahon ng pag-install ng script, isang CRON na trabaho ang gagawin para sa karagdagang pag-renew ng mga sertipiko nang hindi kami nakikilahok.

Kapag nag-isyu ng certificate, susuriin ang domain gamit ang DNS gamit ang API, kaya sa personal na account ng ClouDNS sa menu ng Reseller API, kailangan mong lumikha ng bagong user API at magtakda ng password para dito. Ang magreresultang auth-id na may password ay isusulat sa file ~/.acme.sh/dnsapi/dns_cloudns.sh (hindi malito sa file dns_clouddns.sh). Narito ang mga linyang kailangang i-uncomment at i-edit:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<ΠΏΠ°Ρ€ΠΎΠ»ΡŒ>"

Ngayon ay hihingi kami ng SSL certificate para sa cdn.sayt.in

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

Sa mga opsyon, para sa hinaharap, tinukoy namin ang isang command na awtomatikong i-reload ang configuration ng web server pagkatapos ng bawat pag-renew ng panahon ng validity ng certificate sa hinaharap.

Ang buong proseso ng pagkuha ng sertipiko ay maaaring tumagal ng hanggang 2 minuto, huwag itong matakpan. Kung may nangyaring error sa pagpapatunay ng domain, subukang patakbuhin muli ang command. Sa dulo makikita natin kung saan na-upload ang mga sertipiko:

Pagbuo at pag-configure ng iyong CDN

Tandaan ang mga landas na ito, kakailanganin nilang tukuyin kapag kinokopya ang sertipiko sa iba pang mga server, pati na rin sa mga setting ng web server. Hindi namin binibigyang pansin ang error sa pag-reload ng mga config ng Nginx - hindi ito magiging ganap na naka-configure na server kapag nag-a-update ng mga sertipiko.

Ang natitira na lang namin para sa SSL ay kopyahin ang natanggap na sertipiko sa dalawang iba pang mga server habang pinapanatili ang landas sa mga file. Gumawa tayo ng parehong mga direktoryo sa bawat isa sa kanila at gumawa ng kopya:

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/

Para regular na mag-update ng mga certificate, gumawa ng pang-araw-araw na trabaho ng CRON sa parehong mga server gamit ang command:

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

Sa kasong ito, dapat na i-configure ang access sa remote source server sa pamamagitan ng susi, ibig sabihin. nang hindi naglalagay ng password. Huwag kalimutang gawin ito.

Pag-install at pag-configure ng Nginx

Upang maghatid ng static na nilalaman, gagamitin namin ang Nginx na na-configure bilang isang caching proxy server. I-update ang mga listahan ng package at i-install ito sa lahat ng tatlong server:

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

Sa halip na default, ginagamit namin ang config mula sa spoiler sa ibaba:
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;
    }
  }
}

I-edit sa config:

  • max_size β€” ang laki ng cache, hindi lalampas sa magagamit na espasyo sa disk
  • hindi aktibo - oras ng imbakan ng naka-cache na data na walang na-access
  • ssl_certificate ΠΈ ssl_certificate_key β€” mga landas sa SSL certificate at mga pangunahing file
  • proxy_cache_valid - oras ng imbakan ng naka-cache na data
  • proxy_pass β€” address ng orihinal na server kung saan hihingi ang CDN ng mga file para sa pag-cache. Sa aming halimbawa, ito sayt.in

Tulad ng nakikita mo, ang lahat ay simple. Ang kahirapan ay maaari lamang lumitaw sa pagtatakda ng oras ng pag-cache dahil sa pagkakapareho ng mga direktiba hindi aktibo ΠΈ proxy_cache_valid. Suriin natin ang mga ito sa ating halimbawa. Narito kung ano ang mangyayari kapag hindi aktibo=7d ΠΈ proxy_cache_valid 90d:

  • kung ang kahilingan ay hindi naulit sa loob ng 7 araw, ang data ay tatanggalin mula sa cache pagkatapos ng panahong ito
  • kung ang kahilingan ay paulit-ulit nang hindi bababa sa isang beses bawat 7 araw, ang data sa cache ay ituturing na lipas na pagkatapos ng 90 araw at ang Nginx ay ia-update ito sa susunod na kahilingan, na kukunin ito mula sa orihinal na server

Tapos na mag-edit nginx.conf, i-reload ang configuration:

root@cdn:~# service nginx reload

Ang aming CDN ay handa na. Para sa $15/buwan. nakatanggap kami ng mga punto ng presensya sa tatlong kontinente at 3 TB ng trapiko: 1 TB sa bawat lokasyon.

Sinusuri ang gawain ng CDN

Tingnan natin ang mga ping sa aming CDN mula sa iba't ibang heyograpikong lokasyon. Ang anumang serbisyo ng ping ay gagana para dito.

Punto ng paglulunsad
Host
IP
Avg na oras, ms

Alemanya Berlin
cdn.sayt.in
199.247.18.199
9.6

Netherlands, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

France Paris
cdn.sayt.in
199.247.18.199
16.3

Great Britain, London
cdn.sayt.in
199.247.18.199
14.9

Canada, 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

USA, New York
cdn.sayt.in
149.28.121.123
19.8

Singgapur
cdn.sayt.in
157.230.240.216
1.7

Japan Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Maganda ang mga resulta. Ngayon ay maglalagay kami ng isang pagsubok na imahe sa ugat ng pangunahing site test.jpg at suriin ang bilis ng pag-download nito sa pamamagitan ng CDN. Sinabi na - tapos na. Mabilis na naihatid ang nilalaman.

Sumulat tayo ng isang maliit na script kung sakaling gusto nating i-clear ang cache sa CDN point.
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

Upang tanggalin ang buong cache, patakbuhin lamang ito, maaaring linisin ang isang hiwalay na file tulad nito:

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

Sa halip na mga konklusyon

Sa wakas, gusto kong magbigay ng ilang kapaki-pakinabang na tip upang agad na matapakan ang kalaykay na nagpasakit ng aking ulo noong panahong iyon:

  • Upang mapataas ang fault tolerance ng CDN, inirerekumenda na i-configure ang DNS Failover, na tumutulong upang mabilis na baguhin ang A record kung sakaling magkaroon ng pagkasira ng server. Ginagawa ito sa control panel ng mga DNS record ng domain.
  • Ang mga site na may malawak na heyograpikong saklaw ay walang alinlangan na nangangailangan ng malaking bilang ng mga CDN, ngunit huwag tayong maging panatiko. Malamang na hindi mapapansin ng user ang isang makabuluhang pagkakaiba kumpara sa isang bayad na CDN kung maglalagay ka ng mga server sa 6-7 na lokasyon: Europe, North America (silangan), North America (west), Singapore, Australia, Hong Kong o Japan
  • Minsan hindi pinapayagan ng mga hoster ang paggamit ng mga inuupahang server para sa mga layunin ng CDN. Samakatuwid, kung bigla kang magpasya na mag-deploy ng network ng paghahatid ng nilalaman bilang isang serbisyo, huwag kalimutang basahin nang maaga ang mga panuntunan ng isang partikular na hosting provider.
  • Galugarin mapa ng komunikasyon sa ilalim ng dagatupang kumatawan kung paano konektado ang mga kontinente at isaalang-alang ito kapag bumubuo ng network ng paghahatid ng nilalaman
  • Subukan mong suriin mga ping mula sa iba't ibang lugar sa iyong mga server. Sa ganitong paraan makikita mo ang mga rehiyong pinakamalapit sa mga CDN point at mas maayos na i-configure ang GeoDNS
  • Depende sa mga gawain, magiging kapaki-pakinabang ang pag-fine-tune ng Nginx para sa mga partikular na kinakailangan sa pag-cache at isinasaalang-alang ang pagkarga sa server. Ang mga artikulo tungkol sa Nginx cache ay nakatulong sa akin ng malaki dito - dito at pagpapabilis ng trabaho sa ilalim ng mabibigat na karga: dito ΠΈ dito

Pinagmulan: www.habr.com