Градење и конфигурирање на вашиот CDN

Мрежите за испорака на содржина (CDN) се користат во веб-локациите и апликациите првенствено за да се забрза вчитувањето на статичните елементи. Ова се случува поради кеширање на датотеки на CDN сервери лоцирани во различни географски региони. Со барање податоци преку CDN, корисникот ги добива од најблискиот сервер.

Принципот на работа и функционалност на сите мрежи за испорака на содржина е приближно ист. Откако доби барање за преземање датотека, серверот CDN ја зема еднаш од оригиналниот сервер и му ја дава на корисникот, во исто време кеширајќи ја за одреден временски период. Сите последователни барања се одговорени од кешот. Сите CDN имаат опции за претходно вчитување датотеки, чистење на кешот, поставување на датумот на истекување и многу повеќе.

Се случува, поради една или друга причина, да треба да организирате сопствена мрежа за испорака на содржини, а потоа - нека ни бидат од помош упатствата за склопување на следниот велосипед.

Извор: Инфографски вектор создаден од pikisuperstar - www.freepik.com

Кога ви треба сопствен CDN

Размислете за случаите кога има смисла да се има сопствен CDN:

• кога постои желба да се заштедат пари и тековни трошоци дури и кога се користат евтини CDN како BunnyCDN изнесуваат неколку стотици долари месечно
• ако сакаме да добиеме постојан кеш или кеш без соседи на сервер и канал
• ЦДН услугите немаат точки на присуство во регионот што ви треба
• потребни се какви било посебни поставки за испорака на содржина
• сакаме да ја забрзаме испораката на динамична содржина со поставување на серверот за производство поблиску до корисниците
• постои загриженост дека услугата CDN од трета страна може незаконски да собира или користи информации за однесувањето на корисниците (здраво услуги кои не се во согласност со GDPR) или да се вклучат во други нелегални активности

Во повеќето други случаи, посоодветно е да се користат постоечките готови решенија.

Што ви треба за да започнете

Прекрасно е ако имате сопствен автономен систем (AS). Со него, можете да доделите иста IP адреса на неколку сервери и според ова упатство на ниво на мрежа, насочете ги корисниците до најблискиот. Вреди да се каже дека дури и со блокот за адреси /24, можно е да се изгради мрежа за испорака на содржина. Некои провајдери на сервери ви дозволуваат да објавите најава за употреба во сите региони што им се достапни.

Ако не сте среќен сопственик на блок од IP адреси, тогаш за да извршите едноставен CDN ќе ви требаат:

• име на домен или поддомен
• најмалку два сервери во различни региони. Серверот може да биде посветен или виртуелен
• geoDNS алатка. Со него, корисникот, откако ќе се обрати до доменот, ќе биде насочен до најблискиот сервер

Регистрирајте домен и нарачајте сервери

Со регистрација на домен, сè е едноставно - се регистрираме во која било зона со кој било регистратор. Можете исто така да користите поддомен за CDN, на пример нешто слично cdn.domainname.com. Всушност, во нашиот пример, ние ќе го направиме токму тоа.

Што се однесува до нарачување сервери, тие треба да се изнајмуваат во регионите и земјите каде што се наоѓа вашата корисничка публика. Ако проектот е интерконтинентален, тогаш е погодно да се изберат хостинг провајдери кои нудат сервери низ целиот свет одеднаш. Примери: Ovh, закуп веб и 100Тб - за посветени сервери, Vultr и Дигитален океан — за виртуелен облак*.

За нашиот приватен CDN, ќе нарачаме 3 виртуелни сервери на различни континенти. На Vultr на серверот за 5 долари/месечно ќе добиеме 25GB SSD места и 1 ТБ сообраќај. Кога инсталирате, изберете го најновиот Debian. Нашите сервери:

Франкфурт, IP: 199.247.18.199

Чикаго, IP: 149.28.121.123

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

*Vultr и DigitalOcean ветуваат кредит од 100 долари на корисниците кои ќе се регистрираат преку линковите во статијата веднаш по додавањето на начин на плаќање. Од ова авторот добива и мал комплимент, кој сега за него е многу значаен. Ве молиме бидете со разбирање.

Поставување geoDNS

За да може корисникот да биде насочен кон саканиот (најблискиот) сервер при пристап до домен или CDN поддомен, потребен ни е DNS сервер со функцијата geoDNS.

Принципот и работата на geoDNS е како што следува:

1. Ја одредува IP адресата на клиентот што го испратил барањето DNS или IP на рекурзивниот DNS сервер што се користи при обработката на барањето на клиентот. Таквите рекурзивни сервери се обично DNS-и на провајдери.
2. IP на клиентот ја препознава неговата земја или регион. За ова се користат GeoIP бази на податоци, од кои денес има многу. Има добри бесплатни опции.
3. Во зависност од локацијата на клиентот, му ја дава IP адресата на најблискиот CDN сервер.

DNS сервер со geoDNS функција може да биде склопете сами, но подобро е да се користат готови решенија со мрежа на DNS сервери ширум светот и Ајкаст од кутијата:

• CloudDNS од 9.95 долари/месечно, GeoDNS тарифа, стандардно има еден DNS Failover
• Зилоре од 25 долари/месечно, DNS Failover е овозможен
• Амазон рута 53 од 35 долари/месечно за нето 50 милиони гео-барања. DNS Failover се наплаќа одделно
• DNS е лесно од 125 долари/месечно, има 10 DNS Failovers
• Cloudflare, функцијата „Geo Steering“ е достапна во плановите на Enterprise

Кога нарачувате geoDNS, треба да обрнете внимание на бројот на барања вклучени во тарифата и да имате на ум дека вистинскиот број на барања до доменот може да ги надмине очекувањата за неколку пати. Милиони пајаци, скенери, спамери и други зли духови работат неуморно.

Речиси сите DNS услуги вклучуваат неопходна услуга за изградба на CDN - DNS Failover. Со негова помош, можете да поставите следење на работата на вашите сервери и, во отсуство на знаци на живот, автоматски да ја замените адресата на неработен сервер со резервна копија во одговорите на DNS.

За да го изградиме нашиот CDN, ќе користиме CloudDNS, GeoDNS тарифа.

Ајде да додадеме нова DNS зона во вашата лична сметка, наведувајќи го вашиот домен. Ако градиме CDN на поддомен, а главниот домен е веќе во употреба, тогаш веднаш по додавањето на зоната, не заборавајте да ги додадете постоечките работни записи DNS. Следниот чекор е да креирате неколку А-записи за доменот / поддоменот CDN, од кои секоја ќе се примени во регионот што го наведовме. Можете да наведете континенти или земји како региони, под-региони се достапни за САД и Канада.

Во нашиот случај, CDN ќе се подигне на поддомен cdn.sayt.in. Со додавање зона рече.во, креирајте го првиот А-запис за поддоменот и посочете ја цела Северна Америка на серверот во Чикаго:

Ајде да го повториме дејството за другите региони, не заборавајте да создадеме еден запис за стандардните региони. Еве што се случува на крајот:

Последниот стандарден запис во скриншот значи дека сите неодредени региони (а тоа се Европа, Африка, сателитски интернет корисници итн.) ќе бидат испратени на серверот во Франкфурт.

Ова го комплетира основното поставување на DNS. Останува да отидете на веб-страницата на регистраторот на домен и да ги замените тековните NS на домени со оние издадени од ClouDNS. И додека НС ќе се ажурираат, ние ќе ги подготвиме серверите.

Инсталација на SSL сертификати

Нашиот CDN ќе работи преку HTTPS, па ако веќе имате SSL сертификати за домен или поддомен, прикачете ги на сите сервери, на пример, во директориумот /etc/ssl/yourdomain/

Ако нема сертификати, можете да добиете бесплатен од Let's Encrypt. Совршено за ова ACME Shellscript. Клиентот е удобен и лесен за поставување, и што е најважно, ви овозможува да потврдите домен/поддомен преку DNS преку ClouDNS API.

Ќе инсталираме acme.sh само на еден од серверите - European 199.247.18.199, од кој сертификатите ќе бидат копирани на сите други. За да инсталирате, стартувајте:

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

За време на инсталацијата на сценариото, ќе се создаде CRON работа за понатамошно обновување на сертификатите без наше учество.

При издавање на сертификат, доменот ќе се проверува со користење на DNS со помош на API, така што во личната сметка на ClouDNS во менито на Reseller API, треба да креирате нов кориснички 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 - време на складирање на кешираните податоци
• прокси_пропус — адреса на оригиналниот сервер од кој CDN ќе бара датотеки за кеширање. Во нашиот пример, ова рече.во

Како што можете да видите, сè е едноставно. Потешкотии може да се појават само при поставувањето на времето за кеширање поради сличноста на директивите неактивен и proxy_cache_valid. Ајде да ги анализираме со нашиот пример. Еве што се случува кога неактивен=7д и proxy_cache_valid 90d:

• ако барањето не се повтори во рок од 7 дена, тогаш податоците ќе бидат избришани од кешот по овој период
• ако барањето се повторува најмалку еднаш на секои 7 дена, тогаш податоците во кешот ќе се сметаат за застарени по 90 дена и Nginx ќе ги ажурира со следното барање, земајќи ги од оригиналниот сервер

Заврши со уредување nginx.conf, повторно вчитајте ја конфигурацијата:

root@cdn:~# service nginx reload

Нашиот ЦДН е подготвен. За 15 долари/месечно. добивме точки на присуство на три континенти и 3 ТБ сообраќај: 1 ТБ на секоја локација.

Проверка на работата на CDN

Ајде да ги погледнеме пинговите на нашиот CDN од различни географски локации. Секоја пинг услуга ќе работи за ова.

Точка за лансирање
Домаќин
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

Сингапур
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.
чистка.ш

#!/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 и поправилно да го конфигурирате GeoDNS
• Во зависност од задачите, ќе биде корисно да се прилагоди Nginx за специфични барања за кеширање и земајќи го предвид оптоварувањето на серверот. Во ова многу ми помогнаа написите за кешот Nginx - тука и забрзување на работата при тешки товари: тука и тука

Извор: www.habr.com