🥇Збіраем і наладжваем свой CDN

Сеткі дастаўкі кантэнту (CDN) выкарыстоўваюцца на сайтах і ў дадатках у асноўным для паскарэння загрузкі статычных элементаў. Адбываецца гэта за кошт кэшавання файлаў на CDN-серверах, размешчаных у розных геаграфічных рэгіёнах. Запытаўшы дадзеныя праз CDN, карыстач атрымлівае іх з найблізкага сервера.

Прынцып працы і функцыянал ва ўсіх сетак дастаўкі кантэнту прыкладна аднолькавы. Атрымаўшы запыт на загрузку файла, CDN сервер аднаразова бярэ яго з арыгінальнага сервера і аддае карыстачу, разам з тым кэшуючы ў сябе на зададзены прамежак часу. На ўсе наступныя запыты адказ аддаецца з кэша. Ва ўсіх CDN ёсць опцыі папярэдняй загрузкі файлаў, ачысткі кэша, налады тэрміна яго захоўвання, і шматлікае іншае.

Бывае, што ў сілу тых ці іншых чыннікаў патрабуецца арганізаваць уласную сетку дастаўкі кантэнту, і тады - хай будзе ў дапамогу нам інструкцыя па зборцы чарговага ровара.

Крыніца: Infographic vector created by pikisuperstar - www.freepik.com

Калі патрэбен уласны CDN

Разгледзім выпадкі, калі запуск уласнага CDN мае сэнс:

калі ёсць жаданне зэканоміць, а бягучыя выдаткі нават пры выкарыстанні недарагіх CDN накшталт BunnyCDN складаюць некалькі сотняў даляраў у месяц
калі жадаем атрымаць сталы кэш ці кэш без суседзяў па серверы і каналу
у патрэбным вам рэгіёне ў CDN сэрвісаў няма кропак прысутнасці
патрабуюцца якія-небудзь адмысловыя налады дастаўкі кантэнту
жадаем паскорыць дастаўку дынамічнага кантэнту, размясціўшы бліжэй да карыстачоў прадакшн сервера
ёсць асцярога, што іншы CDN сэрвіс можа неправамерна збіраць або выкарыстоўваць інфармацыю аб паводзінах карыстальнікаў (прывітанне сэрвісам без GDPR-compliant) або займацца іншымі неправамернымі дзеяннямі

У большасці астатніх выпадкаў больш мэтазгодна выкарыстоўваць існуючыя гатовыя рашэнні.

Што трэба для запуску

Дзіўна, калі ў вас ёсць свая аўтаномная сістэма (AS). З ёй можна прызначыць аднолькавы IP некалькім серверам і па гэтай інструкцыі на ўзроўні сеткі накіроўваць карыстальнікаў да бліжэйшага. Варта сказаць, што нават з блокам адрасоў /24 ёсць магчымасць пабудаваць сетку дастаўкі кантэнту. Некаторыя сервер-правайдэры дазваляюць зрабіць анонс для выкарыстання ва ўсіх даступных у іх рэгіёнах.

Калі ж вы не шчаслівы ўладальнік блока IP адрасоў, то для запуску простага CDN вам спатрэбяцца:

даменнае імя або субдамен
мінімум два серверы ў розных рэгіёнах. Сервер можа быць як выдзелены, так і віртуальны.
geoDNS інструмент. З яго дапамогай карыстач, звярнуўшыся да дамена, будзе накіраваны на найблізкі сервер.

Рэгіструем дамен і заказваем сервера

З рэгістрацыяй дамена ўсё проста - які рэгіструецца ў любой зоне ў любога рэгістратара. Таксама для CDN можна выкарыстоўваць субдамен, напрыклад нешта накшталт cdn.імядамена.com. Уласна ў нашым прыкладзе мы так і зробім.

Што тычыцца замовы сервераў - іх варта арандаваць у рэгіёнах і краінах, дзе знаходзіцца ваша карыстацкая аўдыторыя. Калі праект інтэркантынентальны, то зручна выбіраць хостынг-правайдэраў, якія прапануюць адразу сервера па ўсім свеце. Прыклады: OVH, Leaseweb и 100Tb - для выдзеленых сервераў, 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 накіроўваўся на патрэбны (бліжэйшы да яго) сервер, нам спатрэбіцца DNS сервер з функцыяй geoDNS.

Прынцып і парадак працы geoDNS наступны:

Вызначае IP кліента, які даслаў DNS запыт, або IP рэкурсіўнага DNS-сервера, які выкарыстоўваецца пры апрацоўцы кліенцкага запыту. Такімі рэкурсіўнымі серверамі звычайна з'яўляюцца DNS-ы правайдэраў.
Па IP кліента даведаецца яго краіну ці рэгіён. Для гэтага ўжываюцца базы GeoIP, якіх сёння найвялікшае мноства. Ёсць нядрэнныя бясплатныя варыянты.
У залежнасці ад месцазнаходжання кліента аддае яму IP-адрас найблізкага CDN сервера.

DNS сервер з функцыяй geoDNS можна сабраць самастойна, але лепш выкарыстоўваць гатовыя рашэнні з сеткай DNS-сервераў па ўсім свеце і У любым плане са скрынкі:

СlouDNS ад $9.95/мес, тарыф GeoDNS, па змаўчанні ёсць адзін DNS Failover
Зіларэ ад $25/мес, уключаны DNS Failover
Маршрут Amazon 53 ад $35/мес за чыстых 50м гео-запытаў. DNS Failover тарыфікуецца асобна
DNS Made Easy ад $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. І пакуль NS-ы будуць абнаўляцца, мы падрыхтуем сервера.

Устаноўка SSL сертыфікатаў

Наш CDN будзе працаваць па HTTPS, таму калі ў вас ужо маюцца SSL сертыфікаты для дамена ці субдамена, - загрузіце іх на ўсе серверы, напрыклад у дырэкторыю /etc/ssl/вашдамен/

Калі сертыфікатаў няма, можна атрымаць бясплатны ад Let's Encrypt. Для гэтага выдатна падыдзе ACME Shell script. Кліент зручны і просты ў наладзе, а галоўнае - дазваляе праводзіць валідацыю дамена/субдамена па DNS праз API ад ClouDNS.

Мы паставім acme.sh толькі на адным з сервераў – еўрапейскім 199.247.18.199, з яго сертыфікаты будуць капіявацца на ўсе астатнія. Для ўстаноўкі выканаем:

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

У ходзе ўстаноўкі скрыпту будзе створана CRON заданне для далейшага абнаўлення сертыфікатаў без нашага ўдзелу.

Праверка дамена пры выдачы сертыфіката будзе праводзіцца па DNS з выкарыстаннем API, таму ў асабістым кабінеце ClouDNS у меню Reseller API трэба стварыць новага 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, сканфігураваны ў рэжыме які кешыруе proxy-сервера. Абновім спісы пакетаў і ўсталюем яго на ўсіх трох серверах:

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_сертыфікат и ssl_certificate_key - шляхі да файлаў SSL сертыфіката і ключа
proxy_cache_valid - час захоўвання закэшаваных дадзеных
проксі_пас - адрас арыгінальнага сервера, з якога CDN будзе запытваць файлы для кэшавання. У нашым прыкладзе гэта sayt.in

Як бачым, усё проста. Складанасць толькі можа паўстаць у наладзе часу кэшавання з-за падабенства дырэктыў неактыўны и proxy_cache_valid. Разбяром іх на нашым прыкладзе. Вось што адбываецца пры inactive=7d и proxy_cache_valid 90d:

калі запыт не паўторыцца на працягу 7 дзён, то дадзеныя выдаляцца з кэша па заканчэнні гэтага перыяду
калі запыт будзе паўтарацца хаця б раз у 7 дзён, то дадзеныя ў кэшы будуць лічыцца састарэлымі па заканчэнні 90 дзён і пры чарговым запыце Nginx абновіць іх, узяўшы з арыгінальнага сервера

Скончыўшы правіць nginx.conf, перазагрузім канфігурацыю:

root@cdn:~# service nginx reload

Наш CDN цалкам готаў. За $15/мес. мы атрымалі кропкі прысутнасці на трох кантынентах і 3 Тб трафіку: па 1 Тб у кожнай лакацыі.

Правяраем працу CDN

Паглядзім на пінгі да нашага CDN з розных геаграфічных лакацый. Для гэтага падыдуць любыя пінг-сэрвісы.

Кропка запуску
Хост
IP
Avg time, мсек

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

Вынікі добрыя. Размесцім зараз у корані асноўнага сайта тэставую карцінку тэст.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, але давайце без фанатызму. Хутчэй за ўсё карыстач не заўважыць істотнай розніцы ў параўнанні з платным CDN, калі вы размясціце сервера ў 6-7 месцах: Еўропа, Паўночная Амерыка (усход), Паўночная Амерыка (захад), Сінгапур, Аўстралія, Ганконг ці Японія
Часам хосцеры не дазваляюць выкарыстоўваць арандаваныя сервера для мэт CDN. Таму, калі вы раптам вырашыце разгарнуць сетку дастаўкі кантэнту як сэрвіс, не забудзьцеся загадзя прачытаць правілы канкрэтнага хостынг-правайдэра
Вывучыце карту падводных камунікацый, каб прадстаўляць, як звязаны кантыненты і ўлічваць гэта пры пабудове сеткі дастаўкі кантэнту
Паспрабуйце праверыць пінг з розных месцаў да вашых сервераў. Так можна ўбачыць бліжэйшыя да CDN-кропак рэгіёны і правільней наладзіць GeoDNS
У залежнасці ад задач нялішнім будзе даналадзіць Nginx пад пэўныя патрабаванні кэшавання і з улікам нагрузкі на сервер. У гэтым мне вельмі дапамаглі артыкулы пра кэш Nginx. тут і паскарэнні працы пры вялікіх нагрузках: тут и тут