🥇 CDNиңизди чогултуу жана орнотуу

Контент жеткирүү тармактары (CDNs) веб-сайттар жана тиркемелер тарабынан биринчи кезекте статикалык элементтердин жүктөлүшүн тездетүү үчүн колдонулат. Бул ар кандай географиялык аймактарда жайгашкан CDN серверлериндеги файлдарды кэштөө аркылуу болот. CDN аркылуу маалыматтарды суроо менен, колдонуучу аны жакынкы серверден алат.

Бардык мазмун жеткирүү тармактарынын иштөө принциби жана функционалдуулугу болжол менен бирдей. Файлды жүктөп алуу өтүнүчүн алгандан кийин, CDN сервери аны баштапкы серверден бир жолу алып, колдонуучуга берет, ошол эле учурда аны белгилүү бир убакытка кэштейт. Бардык кийинки суроо-талаптарга кэштен жооп берилет. Бардык CDN'лерде файлдарды алдын ала жүктөө, кэшти тазалоо, кэштин мөөнөтүн орнотуу жана башка көптөгөн нерселер бар.

Тигил же бул себептерден улам өзүңүздүн мазмунду жеткирүү тармагын уюштуруу керек болуп калат, андан кийин - кийинки велосипедди чогултуу боюнча нускамалар бизге жардам бере алат.

Source: pikisuperstar тарабынан түзүлгөн инфографикалык вектор — www.freepik.com

Качан сизге жеке CDN керек болот?

Келгиле, өз CDNиңизди иштетүү мааниси бар учурларды карап көрөлү:

сиз акчаны үнөмдөөнү кааласаңыз, ошондой эле арзан CDNдерди колдонуп жатканда да иштеп жаткан чыгымдар BunnyCDN айына бир нече жүз долларды түзөт
эгерде биз серверде жана каналда кошуналары жок туруктуу кэш же кэш алууну кааласак
CDN кызматтарында сизге керектүү аймакта болуу пункттары жок
Ар кандай атайын мазмун жеткирүү жөндөөлөрү талап кылынат
биз өндүрүш серверлерин колдонуучуларга жакыныраак жайгаштыруу менен динамикалык мазмунду жеткирүүнү тездеткибиз келет
Үчүнчү тараптын CDN кызматы колдонуучунун жүрүм-туруму (GDPRга жооп бербеген кызматтарга салам) жөнүндө маалыматты туура эмес чогултушу же колдонуусу же башка мыйзамсыз аракеттерге барышы мүмкүн деген кооптонуу бар.

Көпчүлүк башка учурларда, бар болгон даяр чечимдерди колдонуу ылайыктуу.

Эмнеден баштоо керек

Эгер сиздин өзүңүздүн автономдуу системаңыз (АС) болсо, бул эң сонун. Анын жардамы менен бир эле IPди бир нече серверге дайындай аласыз жана бул көрсөтмөлөргө ылайык тармак деңгээлинде колдонуучуларды жакынкы бирине багыттаңыз. Ал тургай, /24 дарек блогу менен мазмун жеткирүү тармагын курууга болот деп айтууга болот. Кээ бир сервер провайдерлери аларга жеткиликтүү болгон бардык аймактарда колдонуу үчүн жарнамалоого мүмкүнчүлүк берет.

Эгерде сиз IP даректер блогунун бактылуу ээси болбосоңуз, анда жөнөкөй CDNди ишке киргизүү үчүн сизге керек болот:

домен аты же субдомен
ар кайсы аймактарда жок дегенде эки сервер. Сервер атайын же виртуалдык болушу мүмкүн
geoDNS куралы. Анын жардамы менен доменге кирген колдонуучу жакынкы серверге багытталат

Доменди каттаңыз жана серверлерге заказ бериңиз

Доменди каттоо менен баары жөнөкөй - биз каалаган зонада каалаган регистрден каттайбыз. Сиз ошондой эле CDN үчүн субдоменди колдоно аласыз, мисалы, бир нерсе cdn.domainname.com. Чынында, биздин мисалда биз дал ушундай кылабыз.

Серверлерге буйрутма берүү үчүн, алар сиздин колдонуучу аудиторияңыз жайгашкан аймактарда жана өлкөлөрдө ижарага алынышы керек. Эгерде долбоор континенттер аралык болсо, анда бүткүл дүйнө жүзү боюнча серверлерди сунуштаган хостинг провайдерлерин тандоо ыңгайлуу. Мисалдар: OVH, Leaseweb и 100Тб - арналган серверлер үчүн, Vultr и DigitalOcean — виртуалдык булут үчүн*.

Жеке CDN үчүн биз ар кайсы континенттерде 3 виртуалдык серверге заказ беребиз. У Vultr үчүн серверде $5/ай Биз алабыз 25GB SSD жерлер жана 1TB трафик. Орнотуу учурунда биз акыркы Debianды тандайбыз. Биздин серверлер:

Майне, ip: 199.247.18.199

Чикаго, ip: 149.28.121.123

Сингапур, ip: 157.230.240.216

*Vultr жана DigitalOcean төлөм ыкмасын кошкондон кийин бул макаладагы шилтемелер аркылуу катталган колдонуучуларга 100 доллар насыя убада кылууда. Автор да мындан кичине комплимент алат, бул азыр ал үчүн абдан маанилүү. Сураныч, түшүнүктүү болуңуз.

geoDNS орнотулууда

Колдонуучу CDN доменине же субдоменине киргенде, ал каалаган (эң жакын) серверге багытталышын камсыз кылуу үчүн бизге geoDNS функциясы менен DNS сервери керек болот.

geoDNS принциби жана иштөө тартиби төмөнкүдөй:

DNS суроо-талапты жөнөткөн кардардын IP дарегин же кардардын суроо-талабын иштеп чыгууда колдонулган рекурсивдүү DNS серверинин IP дарегин аныктайт. Мындай рекурсивдүү серверлер көбүнчө DNS провайдерлери болуп саналат.
Кардардын IP дареги анын өлкөсүн же аймагын аныктайт. Бул үчүн, GeoIP маалымат базалары колдонулат, алардын бүгүнкү күндө абдан көп. Жакшылары бар бекер опциялар.
Кардардын жайгашкан жерине жараша, ал ага жакынкы CDN серверинин IP дарегин берет.

geoDNS функциясы менен DNS сервер болушу мүмкүн аны өзүң чогулт, бирок дүйнө жүзү боюнча DNS серверлеринин тармагы менен даяр чечимдерди колдонуу жакшы жана Anycast кутудан:

CloudDNS от $9.95/ай, GeoDNS тарифи, демейки боюнча бир DNS Failover бар
Зилор от $25/ай, DNS Failover иштетилди
Amazon маршруту 53 от $35/ай таза 50M геосуроолор үчүн. DNS Failover өзүнчө төлөнөт
DNS оңой от $125/ай, 10 DNS Failovers бар
Cloudflare, "Geo Steering" функциясы Enterprise тарифтеринде жеткиликтүү

GeoDNS заказ берүүдө сиз тарифке киргизилген суроо-талаптардын санына көңүл бурушуңуз керек жана доменге болгон суроо-талаптардын иш жүзүндөгү саны күтүлгөндөн бир нече эсе көп болушу мүмкүн экенин эске алуу керек. Миллиондогон жөргөмүштөр, сканерлер, спамчылар жана башка каардуу рухтар талыкпай иштешет.

Дээрлик бардык DNS кызматтары баага CDN - DNS Failover куруу үчүн алмаштырылгыс кызматты камтыйт. Анын жардамы менен сиз серверлериңиздин иштешине мониторингди орното аласыз жана эгер жашоонун белгилери жок болсо, DNS жоопторундагы иштебеген сервердин дарегин резервдик көчүрмөгө автоматтык түрдө алмаштыра аласыз.

Биздин CDNди куруу үчүн биз колдонобуз CloudDNS, GeoDNS тарифи.

Домениңизди көрсөтүү менен жеке аккаунтуңузга жаңы DNS аймагын кошолу. Эгерде биз субдоменде CDN куруп жатсак жана негизги домен колдонууда болсо, анда зонаны кошкондон кийин дароо иштеп жаткан DNS жазууларын кошууну унутпаңыз. Кийинки кадам - CDN домени/субдомени үчүн бир нече A-жазмаларын түзүү, алардын ар бири биз белгилеген аймак үчүн колдонулат. Сиз континенттерди же өлкөлөрдү аймактар катары көрсөтө аласыз; субрегиондор АКШ жана Канада үчүн жеткиликтүү.

Биздин учурда, CDN субдоменде көтөрүлөт cdn.sayt.in. Аймакты кошуу менен sayt.in, келгиле, субдомен үчүн биринчи А рекордун түзөлү жана бүт Түндүк Американы Чикагодогу серверге багыттайлы:

Демейки аймактар үчүн бир жазууну түзүүнү унутпай, башка аймактар үчүн аракетти кайталайлы. Бул жерде сиз аягында эмне аласыз:

Скриншоттогу акыркы демейки жазуу бардык такталбаган аймактар (жана булар Европа, Африка, спутниктик интернет колдонуучулар ж.б.) Франкфурттагы серверге жөнөтүлөт дегенди билдирет.

Бул негизги DNS орнотууну аяктайт. Болгону домен регистринин веб-сайтына кирип, учурдагы NS домендерин ClouDNS тарабынан чыгарылгандар менен алмаштыруу гана калды. Ал эми NS жаңыланып жатканда, биз серверлерди даярдайбыз.

SSL сертификаттарын орнотуу

Биздин CDN HTTPS аркылуу иштейт, андыктан домен же субдомен үчүн SSL сертификаттарыңыз болсо, аларды бардык серверлерге, мисалы каталогго жүктөңүз /etc/ssl/yourdomain/

Эгер сизде сертификаттар жок болсо, Let's Encrypt'тен бекер сертификат ала аласыз. Бул үчүн идеалдуу ACME Shell сценарийи. Кардар ыңгайлуу жана конфигурациялоо оңой, эң негизгиси, ClouDNS'тен API аркылуу DNS аркылуу доменди/субдоменди текшерүүгө мүмкүндүк берет.

Биз acme.shти серверлердин бирине гана орнотобуз - европалык 199.247.18.199, андан сертификаттар башкаларга көчүрүлөт. Орнотуу үчүн:

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

Сценарийди орнотуу учурунда биздин катышуубузсуз сертификаттарды андан ары жаңылоо үчүн CRON тапшырмасы түзүлөт.

Сертификат берүү учурунда доменди текшерүү API аркылуу DNS аркылуу ишке ашырылат, ошондуктан Reseller API менюсундагы ClouDNS жеке аккаунтуңузда жаңы API колдонуучусун түзүп, ага сырсөз коюшуңуз керек. Алынган аутентификацияны сырсөз менен файлга жазабыз ~/.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 [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Сертификаттарды үзгүлтүксүз жаңыртуу үчүн, биз эки серверде күнүмдүк CRON тапшырмасын команда менен түзөбүз:

scp -r [email protected]:/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;
    }
  }
}

Конфигурацияда биз түзөтөбүз:

максималдуу_өлчөм — дисктин жеткиликтүү мейкиндигинен ашпаган кэштин көлөмү
жигердүү эмес — кирүүгө мүмкүн болбогон кэштелген маалыматтарды сактоо убактысы
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ге пингдерди карап көрөлү. Бул үчүн ар кандай пинг кызматтары ылайыктуу.

Башталгыч чекит
Host
IP
Орточо убакыт, мс

Германия Берлин
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

Сингапур
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 чекитиндеги кэшти тазалагыбыз келсе, кичинекей скрипт жазалы.
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

Кэшти толугу менен жок кылуу үчүн, жөн гана аны иштетиңиз; сиз бул сыяктуу өзүнчө файлды тазалай аласыз:

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

Корутундунун ордуна

Акырында, бир жолу башымды ооруткан тырмоодон дароо өтүү үчүн пайдалуу кеңештерди бергим келет:

CDN катачылыкка чыдамдуулугун жогорулатуу үчүн DNS Failover конфигурациялоо сунушталат, ал сервер иштебей калган учурда A жазуусун тез өзгөртүүгө жардам берет. Бул домендин DNS жазууларын башкаруу панелинде жасалат
Кең географиялык чөйрөсү бар сайттар, албетте, көп сандагы CDN чекиттерин талап кылат, бирок фанатизмге барбайлы. Эгер сиз серверлерди 6-7 жерге жайгаштырсаңыз: Европа, Түндүк Америка (чыгыш), Түндүк Америка (батыш), Сингапур, Австралия, Гонконг же Япония, колдонуучу акы төлөнүүчү CDNге салыштырмалуу олуттуу айырмачылыкты байкабайт.
Кээде хостерлер CDN максаттары үчүн ижарага алынган серверлерди колдонууга уруксат бербейт. Ошондуктан, эгер сиз күтүлбөгөн жерден контентти жеткирүү тармагын кызмат катары жайылтууну чечсеңиз, атайын хостинг провайдериңиздин эрежелерин алдын ала окуп чыгууну унутпаңыз.
Изилдөө суу астындагы байланыш картасыконтиненттердин кандайча байланышканын элестетүү жана мазмун жеткирүү тармагын курууда муну эске алуу
Текшерип көрүңүз ар кайсы жерден pings серверлериңизге. Ушундай жол менен сиз CDN чекиттерине эң жакын аймактарды көрүп, GeoDNSти туурараак конфигурациялай аласыз
Милдеттерге жараша, Nginxти кэштөөнүн конкреттүү талаптарына ылайыкташтыруу жана сервердеги жүктү эске алуу пайдалуу болмок. Nginx кэши жөнүндө макалалар мага бул жагынан абдан жардам берди - бул жерде жана оор жүктөрдүн астында ишти тездетүү: бул жерде и бул жерде

Source: www.habr.com