Изграждане и конфигуриране на вашия CDN

Мрежите за доставка на съдържание (CDN) се използват в уебсайтове и приложения предимно за ускоряване на зареждането на статични елементи. Това се случва поради кеширането на файлове на CDN сървъри, разположени в различни географски региони. Заявявайки данни чрез CDN, потребителят ги получава от най-близкия сървър.

Принципът на работа и функционалността на всички мрежи за доставка на съдържание е приблизително еднакъв. След като получи заявка за изтегляне на файл, CDN сървърът го взема еднократно от оригиналния сървър и го предоставя на потребителя, като в същото време го кешира за определен период от време. На всички следващи заявки се отговаря от кеша. Всички CDN имат опции за предварително зареждане на файлове, изчистване на кеша, задаване на дата на изтичане и др.

Случва се по една или друга причина да трябва да организирате собствена мрежа за доставка на съдържание и тогава - нека инструкциите за сглобяване на следващия велосипед да ни бъдат полезни.

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

Когато имате нужда от собствен CDN

Обмислете случаите, в които има смисъл да управлявате свой собствен CDN:

• когато има желание да се спестят пари и текущи разходи, дори когато се използват евтини CDN като BunnyCDN възлизат на няколкостотин долара на месец
• ако искаме да получим постоянен кеш или кеш без съседи на сървър и канал
• CDN услугите нямат точки на присъствие в региона, от който се нуждаете
• всички необходими специални настройки за доставка на съдържание
• искаме да ускорим доставката на динамично съдържание, като поставим производствения сървър по-близо до потребителите
• има опасения, че CDN услуга на трета страна може незаконно да събира или използва информация за поведението на потребителя (здравейте услуги, които не са съвместими с GDPR) или да участва в други незаконни дейности

В повечето други случаи е по-подходящо да се използват съществуващи готови решения.

Какво ви трябва, за да започнете

Чудесно е, ако имате собствена автономна система (AS). С него можете да зададете един и същ IP на няколко сървъра и съгласно тази инструкция на мрежово ниво насочва потребителите към най-близкия. Струва си да се каже, че дори с адресния блок /24 е възможно да се изгради мрежа за доставка на съдържание. Някои доставчици на сървъри ви позволяват да направите съобщение за използване във всички региони, достъпни за тях.

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

• име на домейн или поддомейн
• поне два сървъра в различни региони. Сървърът може да бъде специализиран или виртуален
• geoDNS инструмент. С него потребителят, адресирал домейна, ще бъде насочен към най-близкия сървър

Регистрирайте домейн и поръчайте сървъри

С регистрацията на домейн всичко е просто - регистрираме се във всяка зона с всеки регистратор. Можете също да използвате поддомейн за CDN, например нещо подобно cdn.име на домейн.com. Всъщност в нашия пример ще направим точно това.

Що се отнася до поръчката на сървъри, те трябва да бъдат наети в регионите и страните, където се намира вашата потребителска аудитория. Ако проектът е междуконтинентален, тогава е удобно да изберете хостинг доставчици, които предлагат сървъри по целия свят наведнъж. Примери: OVH, лизинг уеб и 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 е както следва:

1. Указва IP на клиента, изпратил DNS заявката, или IP на рекурсивния DNS сървър, който се използва при обработката на клиентската заявка. Такива рекурсивни сървъри обикновено са DNS-и на доставчици.
2. IP на клиента разпознава неговата държава или регион. За това се използват GeoIP бази данни, които днес има много. Има добри безплатни опции.
3. В зависимост от местоположението на клиента, дава му IP адреса на най-близкия CDN сървър.

DNS сървър с функция geoDNS може да бъде сглобете сами, но е по-добре да използвате готови решения с мрежа от DNS сървъри по целия свят и Anycast от кутията:

• CloudDNS от $9.95/месец, GeoDNS тарифа, по подразбиране има един DNS Failover
• Зилоре от $25/месец, DNS Failover е активиран
• Път 53 Амазонка от $35/месец за нетни 50 милиона гео-заявки. DNS Failover се таксува отделно
• DNS стана лесен от $125/месец, има 10 DNS Failovers
• Cloudflare, функцията „Географско управление“ е налична в корпоративните планове

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

Почти всички DNS услуги включват незаменима услуга за изграждане на CDN - DNS Failover. С негова помощ можете да настроите наблюдение на работата на вашите сървъри и при липса на признаци на живот автоматично да замените адреса на неработещ сървър с резервен в DNS отговорите.

За да изградим нашия CDN, ще използваме CloudDNS, GeoDNS тарифа.

Нека добавим нова DNS зона в личния ви акаунт, като посочите вашия домейн. Ако изграждаме CDN на поддомейн и основният домейн вече се използва, тогава веднага след добавяне на зоната не забравяйте да добавите съществуващите работещи DNS записи. Следващата стъпка е да създадете няколко A-записа за CDN домейна / поддомейна, всеки от които ще бъде приложен към региона, който посочихме. Можете да посочите континенти или държави като региони, подрегионите са налични за САЩ и Канада.

В нашия случай CDN ще бъде повдигнат на поддомейн cdn.sayt.in. Чрез добавяне на зона sayt.in, създайте първия A-запис за поддомейна и насочете цяла Северна Америка към сървъра в Чикаго:

Нека повторим действието за други региони, като не забравяме да създадем един запис за регионите по подразбиране. Ето какво се получава накрая:

Последният запис по подразбиране в екранната снимка означава, че всички неуточнени региони (и това са Европа, Африка, сателитни интернет потребители и т.н.) ще бъдат изпратени до сървъра във Франкфурт.

Това завършва основната настройка на DNS. Остава да отидете на сайта на регистратора на домейни и да замените текущите NS на домейни с тези, издадени от ClouDNS. И докато се актуализират НС, ние ще подготвим сървърите.

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

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

Ако няма сертификати, можете да получите безплатен от 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, така че в личния акаунт на ClouDNS в менюто 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 [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_сертификат_ключ — пътища до 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 TB трафик: 1 TB на всяко място.

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

Нека да разгледаме пинговете към нашия CDN от различни географски местоположения. Всяка услуга за пинг ще работи за това.

Стартова точка
Водещ
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 точката.
чистка.ш

#!/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 ми помогнаха много в това - тук и ускоряване на работата при големи натоварвания: тук и тук

Източник: www.habr.com