ProHoster > blog > Utawala > Inakusanya na kusanidi CDN yako

Inakusanya na kusanidi CDN yako

Mitandao ya uwasilishaji wa yaliyomo (CDNs) hutumiwa na tovuti na programu kimsingi kuharakisha upakiaji wa vitu tuli. Hii hutokea kwa kuakibisha faili kwenye seva za CDN zilizo katika maeneo tofauti ya kijiografia. Kwa kuomba data kupitia CDN, mtumiaji huipokea kutoka kwa seva iliyo karibu zaidi.

Kanuni ya uendeshaji na utendakazi wa mitandao yote ya utoaji maudhui ni takriban sawa. Baada ya kupokea ombi la kupakua faili, seva ya CDN inachukua mara moja kutoka kwa seva asili na kumpa mtumiaji, wakati huo huo ikihifadhi kwa muda maalum. Maombi yote yanayofuata yanajibiwa kutoka kwa kache. CDN zote zina chaguzi za kupakia faili mapema, kufuta kache, kuweka muda wa kuisha kwa akiba, na mengi zaidi.

Inatokea kwamba kwa sababu moja au nyingine ni muhimu kuandaa mtandao wako wa uwasilishaji wa yaliyomo, na kisha - maagizo ya kukusanya baiskeli inayofuata yatusaidie.

Inakusanya na kusanidi CDN yako
Chanzo: Vekta ya habari iliyoundwa na pikisuperstar - www.freepik.com

Unahitaji CDN yako mwenyewe lini?

Wacha tuangalie kesi ambapo kuendesha CDN yako mwenyewe kunaeleweka:

  • unapotaka kuokoa pesa, na gharama za uendeshaji hata unapotumia CDN za bei nafuu kama BunnyCDN kiasi cha dola mia kadhaa kwa mwezi
  • ikiwa tunataka kupata kashe ya kudumu au kache bila majirani kwenye seva na kituo
  • Huduma za CDN hazina pointi za kuwepo katika eneo unalohitaji
  • Mipangilio yoyote maalum ya utoaji wa maudhui inahitajika
  • tunataka kuharakisha uwasilishaji wa maudhui yanayobadilika kwa kuweka seva za uzalishaji karibu na watumiaji
  • kuna wasiwasi kwamba huduma ya CDN ya wahusika wengine inaweza kukusanya au kutumia isivyofaa taarifa kuhusu tabia ya mtumiaji (hujambo kwa huduma zisizotii GDPR) au kushiriki katika shughuli nyingine haramu.

Katika hali nyingine nyingi, ni sahihi zaidi kutumia ufumbuzi ulio tayari.

Unachohitaji kuanza

Ni vizuri ikiwa una mfumo wako wa uhuru (AS). Kwa hiyo unaweza kugawa IP sawa kwa seva kadhaa na kulingana na maagizo haya katika kiwango cha mtandao, waelekeze watumiaji kwa walio karibu zaidi. Inafaa kusema kwamba hata kwa kizuizi cha anwani / 24 inawezekana kujenga mtandao wa utoaji wa maudhui. Baadhi ya watoa huduma za seva hukuruhusu kutangaza kwa matumizi katika maeneo yote yanayopatikana kwao.

Ikiwa wewe sio mmiliki wa bahati ya kizuizi cha anwani za IP, basi kuzindua CDN rahisi utahitaji:

  • jina la kikoa au kikoa kidogo
  • angalau seva mbili katika mikoa tofauti. Seva inaweza kuwa ya kujitolea au ya mtandaoni
  • zana ya geoDNS. Kwa msaada wake, mtumiaji anayepata kikoa ataelekezwa kwa seva iliyo karibu

Sajili kikoa na uamuru seva

Kwa usajili wa kikoa, kila kitu ni rahisi - tunajiandikisha katika eneo lolote na msajili yeyote. Unaweza pia kutumia kikoa kidogo kwa CDN, kwa mfano kitu kama cdn.domainname.com. Kwa kweli, katika mfano wetu tutafanya hivyo.

Kuhusu kuagiza seva, zinapaswa kukodishwa katika maeneo na nchi ambapo hadhira yako ya watumiaji iko. Ikiwa mradi ni wa mabara, basi ni rahisi kuchagua watoa huduma wa kukaribisha ambao hutoa seva kote ulimwenguni. Mifano: OVH, Leaseweb ΠΈ 100Tb - kwa seva zilizojitolea, Vultr ΠΈ DigitalOcean - kwa wingu pepe*.

Kwa CDN yetu ya kibinafsi, tutaagiza seva 3 pepe kwenye mabara tofauti. U Vultr kwenye seva kwa $5/mwezi tutapata 25GB SSD maeneo na Trafiki 1TB. Wakati wa ufungaji, tutachagua Debian ya hivi karibuni. Seva zetu:

Inakusanya na kusanidi CDN yako Frankfurt, ip: 199.247.18.199

Inakusanya na kusanidi CDN yako Chicago, ip: 149.28.121.123

Inakusanya na kusanidi CDN yako Singapore, ip: 157.230.240.216

*Vultr na DigitalOcean zinaahidi mkopo wa $100 kwa watumiaji wanaojisajili kwa kutumia viungo vilivyo katika makala haya pindi tu wanapoongeza njia ya kulipa. Mwandishi pia anapokea pongezi ndogo kutoka kwa hii, ambayo ni muhimu sana kwake sasa. Tafadhali kuwa muelewa.

Inasanidi geoDNS

Ili kuhakikisha kuwa mtumiaji anapofikia kikoa cha CDN au kikoa kidogo, anaelekezwa kwa seva inayohitajika (iliyo karibu zaidi), tutahitaji seva ya DNS yenye chaguo la kukokotoa la geoDNS.

Kanuni na utaratibu wa uendeshaji wa geoDNS ni kama ifuatavyo:

  1. Inafafanua IP ya mteja aliyetuma ombi la DNS, au IP ya seva ya DNS inayojirudia ambayo inatumika wakati wa kuchakata ombi la mteja. Seva za kujirudia kama hizo kawaida ni watoa huduma wa DNS.
  2. IP ya mteja hutambulisha nchi au eneo lake. Kwa hili, hifadhidata za GeoIP hutumiwa, ambazo kuna nyingi sana leo. Kuna wengine wazuri chaguzi za bure.
  3. Kulingana na eneo la mteja, huipa anwani ya IP ya seva ya karibu ya CDN.

Seva ya DNS iliyo na kazi ya geoDNS inaweza kuwa kusanya mwenyewe, lakini ni bora kutumia ufumbuzi tayari na mtandao wa seva za DNS duniani kote na Mtu yeyote kutoka kwa sanduku:

  • CloudDNS kutoka $9.95/mwezi, ushuru wa GeoDNS, kwa chaguo-msingi kuna DNS Failover moja
  • Zilore kutoka $25/mwezi, DNS Failover imewashwa
  • Njia ya Amazon 53 kutoka $35/mwezi kwa maswali safi ya jiografia ya 50M. DNS Failover inachajiwa tofauti
  • DNS Imefanywa Rahisi kutoka $125/mwezi, kuna Washindi 10 wa DNS
  • cloudflare, kipengele cha "Geo Steering" kinapatikana katika ushuru wa Biashara

Wakati wa kuagiza geoDNS, unapaswa kuzingatia idadi ya maombi yaliyojumuishwa kwenye ushuru na kuzingatia kwamba idadi halisi ya maombi kwenye kikoa inaweza kuwa mara nyingi zaidi kuliko inavyotarajiwa. Mamilioni ya buibui, scanner, spammers na pepo wengine wabaya hufanya kazi bila kuchoka.

Karibu huduma zote za DNS zinajumuisha kwa bei huduma ya lazima kwa ajili ya kujenga CDN - DNS Failover. Kwa msaada wake, unaweza kuanzisha ufuatiliaji wa uendeshaji wa seva zako na, ikiwa hakuna dalili za uzima, ubadilishe kiotomati anwani ya seva isiyofanya kazi katika majibu ya DNS na chelezo.

Kujenga CDN yetu tutatumia CloudDNS, ushuru wa GeoDNS.

Hebu tuongeze eneo jipya la DNS katika akaunti yako ya kibinafsi, ikionyesha kikoa chako. Ikiwa tunajenga CDN kwenye subdomain, na kikoa kikuu tayari kinatumika, basi mara baada ya kuongeza eneo, usisahau kuongeza rekodi zilizopo za DNS zinazofanya kazi. Hatua inayofuata ni kuunda rekodi A kadhaa za kikoa/kikoa kidogo cha CDN, ambazo kila moja itatumika kwa eneo ambalo tumebainisha. Unaweza kubainisha mabara au nchi kama maeneo; maeneo madogo yanapatikana Marekani na Kanada.

Kwa upande wetu, CDN itafufuliwa kwenye subdomain cdn.sayt.in. Kwa kuongeza eneo sema.katika, hebu tuunde rekodi ya kwanza ya A kwa kikoa kidogo na tuelekeze Amerika Kaskazini yote kwa seva iliyoko Chicago:

Inakusanya na kusanidi CDN yako
Wacha turudie kitendo kwa mikoa mingine, bila kusahau kuunda kiingilio kimoja kwa mikoa chaguo-msingi. Hapa ndio utapata mwisho:

Inakusanya na kusanidi CDN yako

Ingizo chaguomsingi la mwisho katika picha ya skrini linamaanisha kuwa maeneo yote ambayo hayajabainishwa (na haya ni Ulaya, Afrika, watumiaji wa mtandao wa setilaiti, n.k.) yatatumwa kwa seva huko Frankfurt.

Hii inakamilisha usanidi msingi wa DNS. Kilichobaki ni kwenda kwenye tovuti ya msajili wa kikoa na kubadilisha NS za sasa za kikoa na zile zilizotolewa na CloudDNS. Na wakati NS inasasishwa, tutatayarisha seva.

Inasakinisha vyeti vya SSL

CDN yetu itafanya kazi kupitia HTTPS, kwa hivyo ikiwa tayari una cheti cha SSL cha kikoa au kikoa kidogo, pakia kwenye seva zote, kwa mfano kwenye saraka. /etc/ssl/yourdomain/

Ikiwa huna vyeti, unaweza kupata cha bila malipo kutoka kwa Let's Encrypt. Kamili kwa hili Hati ya Shell ya ACME. Mteja ni rahisi na rahisi kusanidi, na muhimu zaidi, inakuwezesha kuthibitisha kikoa/kikoa kidogo kwa kutumia DNS kupitia API kutoka kwa CloudDNS.

Tutasakinisha acme.sh kwenye seva moja tu - European 199.247.18.199, ambayo vyeti vitanakiliwa kwa wengine wote. Ili kusakinisha, fanya:

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

Wakati wa usakinishaji wa hati, kazi ya CRON itaundwa kwa uppdatering zaidi wa vyeti bila ushiriki wetu.

Uthibitishaji wa kikoa wakati wa kutoa cheti utafanywa kupitia DNS kwa kutumia API, kwa hivyo katika akaunti yako ya kibinafsi ya ClouDNS kwenye menyu ya Reseller API unahitaji kuunda mtumiaji mpya wa API na kuweka nenosiri lake. Tutaandika kitambulisho kinachotokana na nenosiri katika faili ~/.acme.sh/dnsapi/dns_cloudns.sh (sio kuchanganyikiwa na faili dns_clouddns.sh) Hapa kuna mistari ambayo inahitaji kutolewa maoni na kuhaririwa:

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

Sasa hebu tuombe cheti cha SSL cha cdn.sayt.in

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

Katika vigezo, kwa siku zijazo, tulibainisha amri ya kupakia upya kiotomatiki usanidi wa seva ya wavuti baada ya kila sasisho la uhalali wa cheti katika siku zijazo.

Mchakato mzima wa kupata cheti unaweza kuchukua hadi dakika 2, usiisumbue. Ikiwa hitilafu ya uthibitishaji wa kikoa hutokea, jaribu kuendesha amri tena. Mwishoni tutaona ambapo vyeti vilipakuliwa:

Inakusanya na kusanidi CDN yako

Wacha tukumbuke njia hizi; zitahitaji kubainishwa wakati wa kunakili cheti kwa seva zingine, na vile vile katika mipangilio ya seva ya wavuti. Hatuzingatii hitilafu ya kupakia upya mipangilio ya Nginx - kwenye seva iliyosanidiwa kikamilifu, haitaonekana wakati wa kusasisha vyeti.

Kinachobaki kwetu na SSL ni kunakili cheti kilichopokelewa kwa seva zingine mbili, kuhifadhi njia ya faili. Wacha tuunde saraka sawa kwenye kila moja yao na tufanye nakala:

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/

Ili kusasisha vyeti mara kwa mara, tutaunda kazi ya kila siku ya CRON kwenye seva zote mbili kwa amri:

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

Katika kesi hii, ufikiaji wa seva ya chanzo cha mbali lazima usanidiwe kwa ufunguo, i.e. bila kuingiza nenosiri. Usisahau kufanya hivi.

Kufunga na kusanidi Nginx

Ili kuhudumia maudhui tuli, tutatumia Nginx iliyosanidiwa kama seva ya proksi ya kache. Wacha tusasishe orodha za kifurushi na tusakinishe kwenye seva zote tatu:

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

Badala ya chaguo-msingi, tunatumia usanidi kutoka kwa kiharibu hapa chini:
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;
    }
  }
}

Katika usanidi tunahariri:

  • ukubwa_wa_upeo β€” saizi ya kache isiyozidi nafasi ya diski inayopatikana
  • haitumiki β€” muda wa kuhifadhi kwa data iliyohifadhiwa ambayo haijafikiwa
  • ssl_cheti ΠΈ ssl_certificate_key β€” njia za cheti cha SSL na faili muhimu
  • kache_ya_proksi ni halali - muda wa kuhifadhi data iliyohifadhiwa
  • pasi_ya_wakala β€” anwani ya seva asili ambayo CDN itaomba faili kwa akiba. Katika mfano wetu hii ni sema.katika

Kama unaweza kuona, kila kitu ni rahisi. Ugumu pekee unaweza kutokea katika kuweka muda wa caching kutokana na kufanana kwa maagizo haitumiki ΠΈ kache_ya_proksi ni halali. Wacha tuwaangalie kwa kutumia mfano wetu. Hiki ndicho kinachotokea wakati isiyotumika=siku 7 ΠΈ proxy_cache_valid 90d:

  • ikiwa ombi halirudiwi ndani ya siku 7, data itafutwa kutoka kwa akiba baada ya kipindi hiki
  • ikiwa ombi linarudiwa angalau mara moja kila siku 7, basi data iliyo kwenye kashe itazingatiwa kuwa ya zamani baada ya siku 90 na kwa ombi linalofuata Nginx itaisasisha, ikichukua kutoka kwa seva asili.

Baada ya kumaliza kuhariri nginx.conf, pakia upya usanidi:

root@cdn:~# service nginx reload

CDN yetu iko tayari kabisa. Kwa $15/mwezi. tulipokea pointi za kuwepo katika mabara matatu na 3 TB ya trafiki: 1 TB katika kila eneo.

Kuangalia uendeshaji wa CDN

Wacha tuangalie pings kwa CDN yetu kutoka maeneo tofauti ya kijiografia. Huduma zozote za ping zinafaa kwa hili.

Hatua ya kuanzia
Mwenyeji
IP
Muda wa wastani, Bi

Ujerumani Berlin
cdn.sayt.in
199.247.18.199
9.6

Uholanzi, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Ufaransa Paris
cdn.sayt.in
199.247.18.199
16.3

Uingereza, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

Marekani, San Francisco
cdn.sayt.in
149.28.121.123
52.7

Marekani, Dallas
cdn.sayt.in
149.28.121.123
23.1

Marekani, Chicago
cdn.sayt.in
149.28.121.123
2.6

Marekani, New York
cdn.sayt.in
149.28.121.123
19.8

Singapore
cdn.sayt.in
157.230.240.216
1.7

Japani Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Matokeo ni mazuri. Sasa hebu tuweke picha ya jaribio kwenye mzizi wa tovuti kuu test.jpg na angalia kasi yake ya upakuaji kupitia CDN. Inasemekana - imetengenezwa. Maudhui hutolewa haraka.

Wacha tuandike hati ndogo ikiwa tunataka kufuta kashe kwenye sehemu ya CDN.
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

Ili kufuta kashe nzima, iendeshe tu; unaweza kufuta faili tofauti kama hii:

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

Badala ya hitimisho

Hatimaye, nataka kutoa vidokezo muhimu ili kuvuka mara moja juu ya reki ambayo mara moja iliniumiza kichwa:

  • Ili kuongeza uvumilivu wa kosa la CDN, inashauriwa kusanidi DNS Failover, ambayo husaidia kubadilisha haraka rekodi A ikiwa seva itashindwa. Hii inafanywa katika paneli ya kudhibiti rekodi za kikoa za DNS
  • Tovuti zilizo na ufikiaji mpana wa kijiografia bila shaka zitahitaji idadi kubwa ya alama za CDN, lakini tusiwe washabiki. Uwezekano mkubwa zaidi, mtumiaji hatatambua tofauti kubwa ikilinganishwa na CDN inayolipwa ikiwa utaweka seva katika maeneo 6-7: Ulaya, Amerika Kaskazini (mashariki), Amerika Kaskazini (magharibi), Singapore, Australia, Hong Kong au Japani.
  • Wakati mwingine wapangishaji hawaruhusu matumizi ya seva zilizokodishwa kwa madhumuni ya CDN. Kwa hivyo, ikiwa utaamua ghafla kupeleka mtandao wa uwasilishaji wa yaliyomo kama huduma, usisahau kusoma sheria za mtoaji wako maalum wa mwenyeji mapema.
  • Chunguza ramani ya mawasiliano chini ya majikufikiria jinsi mabara yameunganishwa na kuzingatia hili wakati wa kujenga mtandao wa utoaji wa maudhui
  • Jaribu kuangalia pings kutoka sehemu mbalimbali kwa seva zako. Kwa njia hii unaweza kuona maeneo yaliyo karibu na alama za CDN na usanidi GeoDNS kwa usahihi zaidi
  • Kulingana na kazi, itakuwa muhimu kubinafsisha Nginx kwa mahitaji maalum ya kache na kuzingatia mzigo kwenye seva. Nakala kuhusu kache ya Nginx ilinisaidia sana na hii - hapa na kuongeza kasi ya kazi chini ya mizigo nzito: hapa ΠΈ hapa

Chanzo: mapenzi.com