🥇Ձեր CDN-ի հավաքում և կարգավորում

Բովանդակության առաքման ցանցերը (CDN) օգտագործվում են կայքերում և հավելվածներում հիմնականում ստատիկ տարրերի բեռնումն արագացնելու համար: Դա տեղի է ունենում տարբեր աշխարհագրական տարածաշրջաններում տեղակայված CDN սերվերների վրա ֆայլերի քեշավորման պատճառով: CDN-ի միջոցով տվյալներ պահանջելով՝ օգտատերը դրանք ստանում է մոտակա սերվերից։

Բոլոր բովանդակության առաքման ցանցերի շահագործման և ֆունկցիոնալության սկզբունքը մոտավորապես նույնն է: Ստանալով ֆայլ ներբեռնելու հարցում՝ CDN սերվերը այն վերցնում է մեկ անգամ սկզբնական սերվերից և տալիս օգտվողին, միևնույն ժամանակ պահում է այն որոշակի ժամանակահատվածում: Բոլոր հետագա հարցումները պատասխանվում են քեշից: Բոլոր CDN-ներն ունեն ֆայլեր նախապես բեռնելու, քեշը մաքրելու, պիտանելիության ժամկետը սահմանելու և այլնի տարբերակներ:

Պատահում է, որ այս կամ այն պատճառով, դուք պետք է կազմակերպեք ձեր սեփական բովանդակության առաքման ցանցը, այնուհետև՝ թող հաջորդ հեծանիվը հավաքելու հրահանգները մեզ օգնեն:

Source: Ինֆոգրաֆիկ վեկտոր, որը ստեղծվել է pikisuperstar-ի կողմից - www.freepik.com

Երբ ձեզ անհրաժեշտ է ձեր սեփական CDN-ն

Հաշվի առեք այն դեպքերը, երբ ձեր սեփական CDN գործարկելը իմաստ ունի.

երբ կա գումար խնայելու ցանկություն և գործառնական ծախսեր, նույնիսկ երբ օգտագործվում են էժան CDN-ներ, ինչպիսիք են BunnyCDN կազմում է ամսական մի քանի հարյուր դոլար
եթե մենք ցանկանում ենք ստանալ մշտական քեշ կամ քեշ առանց սերվերի և ալիքի հարևանների
CDN ծառայությունները չունեն ներկայության կետեր ձեզ անհրաժեշտ տարածաշրջանում
պահանջվում է բովանդակության առաքման հատուկ կարգավորումներ
մենք ցանկանում ենք արագացնել դինամիկ բովանդակության առաքումը` սերվերը ավելի մոտ դնելով օգտվողներին
Մտահոգություն կա, որ երրորդ կողմի CDN ծառայությունը կարող է անօրինական կերպով հավաքել կամ օգտագործել օգտատերերի վարքագծի մասին տեղեկատվություն (բարև, GDPR-ին չհամապատասխանող ծառայություններ) կամ ներգրավվել այլ անօրինական գործողությունների մեջ:

Շատ այլ դեպքերում ավելի նպատակահարմար է օգտագործել առկա պատրաստի լուծումները:

Ինչ է անհրաժեշտ սկսելու համար

Հրաշալի է, եթե ունեք ձեր սեփական Ինքնավար Համակարգը (AS): Դրանով դուք կարող եք նույն IP-ն նշանակել մի քանի սերվերների և այս հրահանգի համաձայն ցանցի մակարդակով օգտվողներին ուղղորդեք դեպի մոտակա մեկը: Արժե ասել, որ նույնիսկ /24 հասցեների բլոկով հնարավոր է կառուցել բովանդակության առաքման ցանց։ Որոշ սերվերների մատակարարներ թույլ են տալիս հայտարարություն անել իրենց հասանելի բոլոր տարածաշրջաններում օգտագործելու համար:

Եթե դուք IP հասցեների բլոկի երջանիկ սեփականատեր չեք, ապա պարզ CDN գործարկելու համար ձեզ հարկավոր է.

տիրույթի անուն կամ ենթադոմեյն
առնվազն երկու սերվեր տարբեր տարածաշրջաններում: Սերվերը կարող է լինել կամ նվիրված կամ վիրտուալ
geoDNS գործիք: Դրանով օգտատերը, դիմելով տիրույթին, կուղղվի դեպի մոտակա սերվեր

Գրանցեք տիրույթ և պատվիրեք սերվերներ

Դոմենի գրանցման դեպքում ամեն ինչ պարզ է. մենք գրանցվում ենք ցանկացած գոտում ցանկացած ռեգիստրատորով: Դուք կարող եք նաև օգտագործել ենթադոմեյն CDN-ի համար, օրինակ՝ նման բան cdn.domainname.com. Իրականում, մեր օրինակում մենք հենց դա կանենք։

Ինչ վերաբերում է սերվերներ պատվիրելուն, ապա դրանք պետք է վարձակալվեն այն տարածաշրջաններում և երկրներում, որտեղ գտնվում է ձեր օգտվողի լսարանը: Եթե նախագիծը միջմայրցամաքային է, ապա հարմար է ընտրել հոսթինգ պրովայդերներ, որոնք միանգամից սերվերներ են առաջարկում ամբողջ աշխարհում։ Օրինակներ. OVH, վարձակալության վեբ и 100 Թբ - նվիրված սերվերների համար, Vultr и DigitalOcean- ը — վիրտուալ ամպի համար*:

Մեր մասնավոր CDN-ի համար մենք կպատվիրենք 3 վիրտուալ սերվեր տարբեր մայրցամաքներում: ժամը Vultr համար սերվերի վրա $5/ամսական մենք կստանանք 25GB SSD վայրեր և 1 ՏԲ տրաֆիկ. Տեղադրելիս ընտրեք վերջին Debian-ը: Մեր սերվերները.

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapore, ip: 157.230.240.216

*Vultr-ը և DigitalOcean-ը $100 վարկ են խոստանում այն օգտատերերին, ովքեր գրանցվել են հոդվածի հղումների միջոցով վճարման եղանակ ավելացնելուց անմիջապես հետո: Հեղինակը սրանից նաեւ մի փոքրիկ հաճոյախոսություն է ստանում, որն այժմ իր համար շատ հատկանշական է։ Խնդրում եմ ըմբռնումով մոտենալ։

geoDNS-ի կարգավորում

Որպեսզի դոմեն կամ CDN ենթադոմեյն մուտք գործելիս օգտվողը ուղղորդվի դեպի ցանկալի (ամենամոտ) սերվերը, մեզ անհրաժեշտ է DNS սերվեր՝ geoDNS ֆունկցիայով։

geoDNS-ի սկզբունքը և աշխատանքը հետևյալն է.

Նշում է հաճախորդի IP-ն, որն ուղարկել է DNS հարցումը կամ ռեկուրսիվ DNS սերվերի IP-ն, որն օգտագործվում է հաճախորդի հարցումը մշակելիս: Նման ռեկուրսիվ սերվերները սովորաբար պրովայդերների DNS-ներ են:
Հաճախորդի IP-ն ճանաչում է իր երկիրը կամ տարածաշրջանը: Դրա համար օգտագործվում են GeoIP տվյալների բազաները, որոնք այսօր շատ են: Կան լավ անվճար ընտրանքներ.
Կախված հաճախորդի գտնվելու վայրից, նրան տալիս է մոտակա CDN սերվերի IP հասցեն:

DNS սերվերը geoDNS ֆունկցիայով կարող է լինել հավաքեք ինքներդ, բայց ավելի լավ է օգտագործել պատրաստի լուծումներ DNS սերվերների ցանցով ամբողջ աշխարհում և Anycast տուփից.

CloudDNS - ից $9.95/ամսական, GeoDNS սակագին, լռելյայն կա մեկ DNS Failover
Զիլոր - ից $25/ամսական, DNS Failover-ը միացված է
Amazon Route 53 - ից $35/ամսական զուտ 50 միլիոն աշխարհագրական հարցումների համար: DNS Failover-ը գանձվում է առանձին
DNS-ը դարձել է հեշտ - ից $125/ամսական, կա 10 DNS Failover
CloudFlare, «Geo Steering» ֆունկցիան հասանելի է Enterprise պլաններում

GeoDNS պատվիրելիս պետք է ուշադրություն դարձնել սակագնում ներառված հարցումների քանակին և նկատի ունենալ, որ տիրույթի հարցումների իրական թիվը կարող է մի քանի անգամ գերազանցել սպասելիքները։ Միլիոնավոր սարդեր, սկաներներ, սպամերներ և այլ չար ոգիներ անխոնջ աշխատում են:

Գրեթե բոլոր DNS ծառայությունները ներառում են անփոխարինելի ծառայություն CDN ստեղծելու համար՝ DNS Failover: Նրա օգնությամբ դուք կարող եք կարգավորել ձեր սերվերների աշխատանքի մոնիտորինգը և, կյանքի նշանների բացակայության դեպքում, ավտոմատ կերպով փոխարինել չաշխատող սերվերի հասցեն կրկնօրինակով DNS-ի պատասխաններում:

Մեր CDN-ը կառուցելու համար մենք կօգտագործենք CloudDNS, GeoDNS սակագին.

Եկեք ավելացնենք նոր DNS գոտի ձեր անձնական հաշվի մեջ՝ նշելով ձեր տիրույթը։ Եթե մենք CDN ենք կառուցում ենթադոմեյնի վրա, և հիմնական տիրույթն արդեն օգտագործվում է, ապա գոտին ավելացնելուց անմիջապես հետո մի մոռացեք ավելացնել առկա աշխատանքային DNS գրառումները։ Հաջորդ քայլը CDN տիրույթի / ենթադոմեյնի համար մի քանի A-գրառումներ ստեղծելն է, որոնցից յուրաքանչյուրը կկիրառվի մեր նշած տարածաշրջանում: Դուք կարող եք նշել մայրցամաքները կամ երկրները որպես տարածաշրջաններ, ենթատարածքները հասանելի են ԱՄՆ-ի և Կանադայի համար:

Մեր դեպքում, CDN-ը կբարձրացվի ենթադոմեյնի վրա cdn.sayt.in. Գոտի ավելացնելով sayt.in, ստեղծեք ենթադոմեյնի առաջին A-գրառումը և ուղղեք ամբողջ Հյուսիսային Ամերիկան Չիկագոյի սերվերին.

Եկեք կրկնենք գործողությունը այլ տարածաշրջանների համար՝ հիշելով ստեղծել մեկ մուտք լռելյայն շրջանների համար: Ահա թե ինչ է տեղի ունենում վերջում.

Սքրինշոթի վերջին լռելյայն մուտքը նշանակում է, որ բոլոր չճշտված շրջանները (և դրանք Եվրոպան, Աֆրիկան, արբանյակային ինտերնետ օգտագործողներն են և այլն) կուղարկվեն Ֆրանկֆուրտի սերվերին:

Սա ավարտում է հիմնական DNS կարգավորումը: Մնում է գնալ տիրույթի ռեգիստրատորի կայք և փոխարինել ներկայիս տիրույթի NS-ները ClouDNS-ի կողմից թողարկվածներով: Եվ մինչ ԱԱ-ները թարմացվեն, մենք կպատրաստենք սերվերները:

SSL վկայագրերի տեղադրում

Մեր CDN-ն կաշխատի HTTPS-ով, այնպես որ, եթե դուք արդեն ունեք SSL վկայագրեր տիրույթի կամ ենթադոմեյնի համար, վերբեռնեք դրանք բոլոր սերվերներում, օրինակ՝ գրացուցակում: /etc/ssl/yourdomain/

Եթե վկայականներ չկան, կարող եք անվճար ստանալ Let's Encrypt-ից: Կատարյալ դրա համար ACME Shellscript. Հաճախորդը հարմար և հեշտ է կարգավորվում, և ամենակարևորը, այն թույլ է տալիս վավերացնել տիրույթը/ենթադոմեյնը DNS-ի միջոցով ClouDNS API-ի միջոցով:

Մենք կտեղադրենք acme.sh սերվերներից միայն մեկի վրա՝ Եվրոպական 199.247.18.199, որից սերտիֆիկատները կպատճենվեն բոլոր մյուսներին։ Տեղադրելու համար գործարկեք՝

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

Սցենարի տեղադրման ժամանակ կստեղծվի CRON աշխատատեղ՝ առանց մեր մասնակցության վկայականների հետագա թարմացման համար:

Հավաստագիր տրամադրելիս տիրույթը կստուգվի DNS-ի միջոցով՝ օգտագործելով API-ն, ուստի Reseller API ընտրացանկում գտնվող ClouDNS անձնական հաշվում դուք պետք է ստեղծեք նոր օգտվողի API և դրա համար սահմանեք գաղտնաբառ: Արդյունքում գաղտնաբառով auth-id-ը կգրվի ֆայլում ~/.acme.sh/dnsapi/dns_cloudns.sh (չշփոթել ֆայլի հետ dns_clouddns.sh) Ահա այն տողերը, որոնք պետք է չմեկնաբանվեն և խմբագրվեն.

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

Այժմ մենք կպահանջենք SSL վկայագիր cdn.sayt.in

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

Ապագայի համար ընտրանքներում մենք նշել ենք հրաման՝ վեբ սերվերի կոնֆիգուրացիան ավտոմատ կերպով վերաբեռնելու համար ապագա վկայագրի վավերականության ժամկետի յուրաքանչյուր նորացումից հետո:

Վկայական ստանալու ողջ գործընթացը կարող է տևել մինչև 2 րոպե, մի ընդհատեք այն։ Եթե տիրույթի վավերացման սխալ է տեղի ունենում, փորձեք նորից գործարկել հրամանը: Վերջում մենք կտեսնենք, թե որտեղ են վերբեռնվել վկայականները.

Հիշեք այս ուղիները, դրանք պետք է նշվեն վկայագիրը այլ սերվերների վրա պատճենելիս, ինչպես նաև վեբ սերվերի կարգավորումներում: Մենք ուշադրություն չենք դարձնում Nginx կոնֆիգուրացիաների վերաբեռնման սխալի վրա. այն չի լինի լիովին կազմաձևված սերվերի վրա, երբ թարմացվում է վկայականները:

SSL-ին մեզ մնում է միայն պատճենել ստացված վկայականը երկու այլ սերվերների վրա՝ պահպանելով ֆայլերի ուղին։ Եկեք ստեղծենք նույն գրացուցակները դրանցից յուրաքանչյուրի վրա և պատճենենք.

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/

Հավաստագրերը պարբերաբար թարմացնելու համար ստեղծեք ամենօրյա CRON աշխատանք երկու սերվերների վրա՝ հրամանով.

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Այս դեպքում, մուտքը հեռավոր աղբյուրի սերվերին պետք է կազմաձևվի բանալիով, այսինքն. առանց գաղտնաբառ մուտքագրելու: Մի մոռացեք դա անել:

Nginx-ի տեղադրում և կարգավորում

Ստատիկ բովանդակություն սպասարկելու համար մենք կօգտագործենք Nginx-ը, որը կազմաձևված է որպես քեշավորման վստահված սերվեր: Թարմացրեք փաթեթների ցուցակները և տեղադրեք այն բոլոր երեք սերվերների վրա.

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

Կանխադրվածի փոխարեն մենք օգտագործում ենք ստորև բերված սփոյլերից կազմաձևումը.
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;
    }
  }
}

Խմբագրել կազմաձևում.

max_size - քեշի չափը, որը չի գերազանցում սկավառակի առկա տարածքը
ակտիվ - պահված տվյալների պահպանման ժամանակը, որին ոչ ոք մուտք չի գործել
ssl_certificate и ssl_certificate_key — ճանապարհներ դեպի SSL վկայագիր և հիմնական ֆայլեր
proxy_cache_valid - պահված տվյալների պահպանման ժամանակը
proxy_pass — սկզբնական սերվերի հասցեն, որից CDN-ն ֆայլեր կպահանջի քեշավորման համար: Մեր օրինակում սա sayt.in

Ինչպես տեսնում եք, ամեն ինչ պարզ է. Դժվարություն կարող է առաջանալ միայն քեշավորման ժամանակի սահմանման մեջ՝ հրահանգների նմանության պատճառով ակտիվ и proxy_cache_valid. Եկեք դրանք վերլուծենք մեր օրինակով։ Ահա թե ինչ է տեղի ունենում, երբ ոչ ակտիվ=7դ и proxy_cache_valid 90d:

եթե հարցումը չկրկնվի 7 օրվա ընթացքում, ապա այս ժամկետից հետո տվյալները կջնջվեն քեշից
եթե հարցումը կրկնվում է առնվազն 7 օրը մեկ, ապա քեշի տվյալները կհամարվեն հնացած 90 օր հետո, և Nginx-ը կթարմացնի այն հաջորդ հարցումով՝ վերցնելով այն սկզբնական սերվերից։

Ավարտվեց խմբագրումը nginx.conf, վերաբեռնեք կազմաձևը՝

root@cdn:~# service nginx reload

Մեր CDN-ն պատրաստ է: $15/ամսական համար։ մենք ստացանք ներկայության կետեր երեք մայրցամաքներում և 3 ՏԲ երթևեկություն՝ 1 ՏԲ յուրաքանչյուր վայրում:

CDN-ի աշխատանքի ստուգում

Եկեք նայենք մեր CDN-ի պինգերին տարբեր աշխարհագրական վայրերից: Ցանկացած ping ծառայություն կաշխատի դրա համար:

Գործարկման կետ
Հյուրընկալող
IP
Միջին ժամանակը, ms

Գերմանիա Բեռլին
cdn.sayt.in
199.247.18.199
9.6

Նիդեռլանդներ, Ամստերդամ
cdn.sayt.in
199.247.18.199
10.1

Ֆրանսիա Փարիզ
cdn.sayt.in
199.247.18.199
16.3

Մեծ Բրիտանիա, Լոնդոն
cdn.sayt.in
199.247.18.199
14.9

Կանադա, Տորոնտո
cdn.sayt.in
149.28.121.123
16.2

ԱՄՆ, Սան Ֆրանցիսկո
cdn.sayt.in
149.28.121.123
52.7

ԱՄՆ, Դալլաս
cdn.sayt.in
149.28.121.123
23.1

ԱՄՆ, Չիկագո
cdn.sayt.in
149.28.121.123
2.6

ԱՄՆ, Նյու Յորք
cdn.sayt.in
149.28.121.123
19.8

Singapore
cdn.sayt.in
157.230.240.216
1.7

Ճապոնիա Տոկիո
cdn.sayt.in
157.230.240.216
74.8

Ավստրալիա, Սիդնեյ
cdn.sayt.in
157.230.240.216
95.9

Արդյունքները լավ են: Այժմ մենք կտեղադրենք թեստային պատկեր հիմնական կայքի արմատում test.jpg և ստուգեք դրա ներբեռնման արագությունը CDN-ի միջոցով: Ասում են - պատրաստված. Բովանդակությունը առաքվում է արագ:

Եկեք գրենք մի փոքրիկ սցենար, եթե ցանկանում ենք մաքրել քեշը CDN կետում:
մաքրել.շ

#!/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

Ամբողջ քեշը ջնջելու համար պարզապես գործարկեք այն, առանձին ֆայլ կարելի է մաքրել այսպես.

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

Եզրակացությունների փոխարեն

Ի վերջո, ես ուզում եմ մի քանի օգտակար խորհուրդ տալ, որպեսզի անմիջապես անցնեմ այն փոցխի վրայով, որն այդ պահին ցավում էր իմ գլուխը.

CDN-ի սխալների հանդուրժողականությունը բարձրացնելու համար խորհուրդ է տրվում կարգավորել DNS Failover-ը, որն օգնում է արագ փոխել A գրառումը սերվերի խափանման դեպքում: Դա արվում է տիրույթի կառավարման վահանակի DNS գրառումներում:
Լայն աշխարհագրական ծածկույթ ունեցող կայքերը, անկասկած, պահանջում են մեծ թվով CDN-ներ, բայց եկեք մոլեռանդ չլինենք: Ամենայն հավանականությամբ, օգտվողը զգալի տարբերություն չի նկատի վճարովի CDN-ի համեմատ, եթե դուք սերվերներ տեղադրեք 6-7 վայրերում՝ Եվրոպա, Հյուսիսային Ամերիկա (արևելք), Հյուսիսային Ամերիկա (արևմուտք), Սինգապուր, Ավստրալիա, Հոնկոնգ կամ Ճապոնիա:
Երբեմն հոսթերները թույլ չեն տալիս օգտագործել վարձակալված սերվերները CDN-ի նպատակներով: Հետևաբար, եթե հանկարծ որոշեք տեղակայել բովանդակության առաքման ցանցը որպես ծառայություն, մի մոռացեք նախօրոք կարդալ որոշակի հոսթինգ մատակարարի կանոնները:
Հետազոտել ստորջրյա հաղորդակցության քարտեզներկայացնել, թե ինչպես են մայրցամաքները միացված և դա հաշվի առնել բովանդակության առաքման ցանց կառուցելիս
Փորձեք ստուգել պինգեր տարբեր վայրերից ձեր սերվերներին: Այս կերպ դուք կարող եք տեսնել CDN կետերին ամենամոտ շրջանները և ավելի ճիշտ կարգավորել GeoDNS-ը
Կախված առաջադրանքներից, օգտակար կլինի կարգավորել Nginx-ը հատուկ քեշավորման պահանջների համար և հաշվի առնելով սերվերի ծանրաբեռնվածությունը: Այս հարցում ինձ շատ օգնեցին Nginx քեշի մասին հոդվածները. այստեղ և ծանր բեռների տակ աշխատանքի արագացում. այստեղ и այստեղ