HimeraSearchDB
Carding_EbayThief
triada
CrackerTuch
d-shop

НОВОСТИ Собираем и настраиваем свой CDN

BDFpromo
Оффлайн

BDFpromo

.
.
Регистрация
23.09.18
Сообщения
12.347
Реакции
176
Репутация
0
Сети доставки контента (CDN) используются на сайтах и в приложениях в основном для ускорения загрузки статических элементов. Происходит это за счет кеширования файлов на CDN-серверах, расположенных в разных географических регионах. Запросив данные через CDN, пользователь получает их с ближайшего сервера.

Принцип работы и функционал у всех сетей доставки контента примерно одинаков. Получив запрос на загрузку файла, CDN сервер единоразово берет его с оригинального сервера и отдает пользователю, вместе с тем кешируя у себя на заданный промежуток времени. На все последующие запросы ответ отдается из кеша. У всех CDN есть опции предварительной загрузки файлов, очистки кеша, настройки срока его хранения, и многое другое.

Бывает, что в силу тех или иных причин требуется организовать собственную сеть доставки контента, и тогда — да будет в помощь нам инструкция по сборке очередного велосипеда.

qfrwss0k86-bdbbbpztdh3d0nkq.jpeg

[SUP]Источник:
You must be registered for see links
[/SUP]


Когда нужен собственный CDN


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

  • когда есть желание сэкономить, а текущие расходы даже при использовании недорогих CDN вроде
    You must be registered for see links
    составляют несколько сотен долларов в месяц
  • если хотим получить постоянный кеш или кеш без соседей по серверу и каналу
  • в нужном вам регионе у CDN сервисов нет точек присутствия
  • требуются какие-либо особые настройки доставки контента
  • хотим ускорить доставку динамического контента, разместив ближе к пользователям продакшн сервера
  • есть опасение, что сторонний CDN сервис может неправомерно собирать или использовать информацию о поведении пользователей (привет сервисам без GDPR-compliant) или заниматься другими неправомерными действиями

В большинстве остальных случаев целесообразнее использовать существующие готовые решения.


Что нужно для запуска


Чудно, если у вас есть своя автономная система (AS). С ней можно назначить одинаковый IP нескольким серверам и
You must be registered for see links
на уровне сети направлять пользователей к ближайшему. Cтоит сказать, что даже с блоком адресов /24 есть возможность построить сеть доставки контента. Некоторые сервер-провайдеры позволяют сделать анонс для использования во всех доступных у них регионах.

Если же вы не счастливый обладатель блока IP адресов, то для запуска простого CDN вам понадобятся:

  • доменное имя или субдомен
  • минимум два сервера в разных регионах. Сервер может быть как выделенный, так и виртуальный
  • geoDNS инструмент. С его помощью пользователь, обратившись к домену, будет направлен на ближайший сервер


Регистрируем домен и заказываем сервера


С регистрацией домена все просто — регистрируем в любой зоне у любого регистратора. Также для CDN можно использовать субдомен, например что-то вроде cdn.имядомена.com. Собственно в нашем примере мы так и поступим.

Что касается заказа серверов — их стоит арендовать в регионах и странах, где находится ваша пользовательская аудитория. Если проект интерконтинентальный, то удобно выбирать хостинг-провайдеров, предлагающих сразу сервера по всему миру. Примеры:
You must be registered for see links
,
You must be registered for see links
и
You must be registered for see links
— для выделенных серверов,
You must be registered for see links
и
You must be registered for see links
— для виртуальных облачных*.

Для нашего частного CDN закажем 3 виртуальных сервера на разных континентах. У Vultr на сервере за $5/мес мы получим 25GB SSD места и 1TB трафика. При установке выберем последний Debian. Наши сервера:

jydif1phgm45zpwjbety-fw_d-g.png
Франкфурт, ip: 199.247.18.199

ukwhv1lwwsr8snoiqc_yyzquo5s.png
Чикаго, ip: 149.28.121.123

3fqk6endcgzeybs-yjlkkphep50.png
Сингапур, ip: 157.230.240.216

[SUP]* Vultr и DigitalOcean обещают $100 кредита пользователям, зарегистрированным по ссылкам в статье, сразу после добавления способа оплаты. Автор также от подобного получает небольшой комплимент, что для него сейчас весьма значимо. Пожалуйста, отнеситесь с пониманием.[/SUP]


Настраиваем geoDNS


Чтобы пользователь при обращении к домену или субдомену CDN направлялся на нужный (ближайший к нему) сервер, нам понадобится DNS сервер с функцией geoDNS.

Принцип и порядок работы geoDNS следующий:

  1. Определяет IP клиента, пославшего DNS запрос, или IP рекурсивного DNS-сервера, который используется при обработке клиентского запроса. Такими рекурсивными серверами обычно являются DNS-ы провайдеров.
  2. По IP клиента узнает его страну или регион. Для этого используются базы GeoIP, коих сегодня превеликое множество. Есть неплохие
    You must be registered for see links
    .
  3. В зависимости от местоположения клиента отдает ему IP-адрес ближайшего CDN сервера.

DNS сервер с функцией geoDNS можно
You must be registered for see links
, но лучше использовать готовые решения с сетью DNS-серверов по всему миру и
You must be registered for see links
из коробки:

  • You must be registered for see links
    от $9.95/мес, тариф GeoDNS, по умолчанию есть один DNS Failover
  • You must be registered for see links
    от $25/мес, включен DNS Failover
  • You must be registered for see links
    от $35/мес за чистых 50М гео-запросов. DNS Failover тарифицируется отдельно
  • You must be registered for see links
    от $125/мес, есть 10 DNS Failover
  • You must be registered for see links
    , функция «Geo Steering» доступна в Enterprise тарифах

При заказе geoDNS следует обращать внимание на количество включенных в тариф запросов и учитывать, что реальное число обращений к домену может в разы превзойти ожидания. Миллионы пауков, сканнеров, спамеров и прочей нечисти работают безустанно.

Практически у всех DNS-сервисов в стоимость включена незаменимая для построения CDN услуга — DNS Failover. С ее помощью можно настроить мониторинг работы своих серверов и в случае отсутствия признаков жизни автоматически заменять в DNS-ответах адрес нерабочего сервера на резервный.

Для построения нашего CDN воспользуемся
You must be registered for see links
, тариф GeoDNS.

Добавим в личном кабинете новую DNS-зону, указав свой домен. Если CDN будем строить на субдомене, а главный домен уже используется, то сразу после добавления зоны не забудьте добавить существующие рабочие DNS-записи. Следующее действие — создание для CDN домена/субдомена нескольких A-записей, каждая из которых будет применяться для заданного нами региона. В качестве регионов можно указать континенты или страны, для США и Канады доступны субрегионы.

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

0xz_ztazcrmz8wqlruylrz4iqh4.png


Повторим действие для других регионов, не забыв создать одну запись для регионов по умолчанию. Вот что получится в итоге:

iojszykgez_pu7wf3mzd8lvmffa.jpeg



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

На этом базовая настройка DNS завершена. Осталось зайти на сайт регистратора домена и заменить текущие NS-ы домена на те, что выдал ClouDNS. И пока NS-ы будут обновляться мы подготовим сервера.


Установка SSL сертификатов


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

Если сертификатов нет, можно получить бесплатный от Let's Encrypt. Для этого отлично подойдет
You must be registered for see links
. Клиент удобен и прост в настройке, а главное — позволяет проводить валидацию домена/субдомена по DNS через API от ClouDNS.

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


root@cdn:~# wget -O -
You must be registered for see links
| bash; source ~/.bashrc

В ходе установки скрипта будет создано CRON задание для дальнейшего обновления сертификатов без нашего участия.

Проверка домена при выдаче сертификата будет проводиться по DNS с использованием API, поэтому в личном кабинете ClouDNS в меню Reseller API нужно создать нового API пользователя и задать для него пароль. Полученный auth-id с паролем пропишем в файле ~/.acme.sh/dnsapi/dns_cloudns.sh (не путать с файлом dns_clouddns.sh). Вот строки, которые требуется раскомментировать и отредактировать:


CLOUDNS_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 минут, не прерывайте его. Если возникнет ошибка валидации домена, попробуйте запустить команду еще раз. В конце мы увидим, куда были загружены сертификаты:

l6qv16mchqhhaokxuvbwmnnw6xu.png


Запомним эти пути, их нужно будет указать при копировании сертификата на другие сервера, а также в настройках веб-сервера. На ошибку перезагрузки конфигов 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​

При этом доступ к удаленному серверу-источнику должен быть настроен
You must be registered for see links
, т.е. без ввода пароля. Не забудьте сделать это.


Установка и настройка 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;
}
}
}


В конфиге отредактируем:

  • max_size — размер кеша, не превышающий доступное на диске место
  • inactive — время хранения закешированых данных, к которым никто не обращался
  • ssl_certificate и ssl_certificate_key — пути к файлам SSL сертификата и ключа
  • proxy_cache_valid — время хранения закешированых данных
  • proxy_pass — адрес оригинального сервера, с которого CDN будет запрашивать файлы для кеширования. В нашем примере это sayt.in

Как видим, всё просто. Сложность лишь может возникнуть в настройке времени кеширования из-за схожести директив inactive и 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
Результаты хорошие. Разместим теперь в корне основного сайта тестовую картинку test.jpg и проверим скорость ее загрузки через CDN. Сказано, —
You must be registered for see links
. Контент отдается быстро.

Напишем небольшой скрипт на случай, если захотим на 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. Поэтому, если вы вдруг решите развернуть сеть доставки контента как сервис, не забудьте заранее прочитать правила конкретного хостинг-провайдера
  • Изучите
    You must be registered for see links
    , чтобы представлять, как связаны континенты и учитывать это при построении сети доставки контента
  • Попробуйте проверить
    You must be registered for see links
    к вашим серверам. Так можно увидеть ближайшие к CDN-точкам регионы и правильнее настроить GeoDNS
  • В зависимости от задач нелишним будет донастроить Nginx под конкретные требования кеширования и с учетом нагрузки на сервер. В этом мне очень помогли статьи о кеше Nginx —
    You must be registered for see links
    и ускорении работы при больших нагрузках:
    You must be registered for see links
    и
    You must be registered for see links
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу