Как построить CDN (1/3): введение и базовые компоненты

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

Это первое в серии из трех статей и стремится представить вас с проблемой и описывать основные компоненты, которые составляют CDN ( сеть доставки контента ). Следующие две статьи будут описаны используемые технологии и их конфигурации, а также различные другие советы по эксплуатации, функциональности и мониторингу CDN.

Основная мотивация для использования CDN ясна — обеспечить быструю и надежную нагрузку на веб-сайт и его контент для всех посетителей по всему миру. Но если вы заботитесь о работе проектов с ежемесячным трафиком миллионов пользователей, и трафик только от файлов JS/CSS — это десятки Tb, то рано или поздно вы попадете в состояние, когда ваше интернет-соединение в 1 Гбилете просто останавливается быть достаточным.

Веб-сайты обычно состоят из динамического и статического контента. Динамическое содержание обычно включает генерируемый HTML-код и данные из различных API (обычно отдых или графакл). Статический контент состоит из таких файлов, как Javascripts, стили, изображения, шрифты или аудио/видео. Типичное соотношение наших проектов заключается в том, что динамическое содержание составляет 10% и статическими 90% от общего передачи данных.

Если у вас есть действительно большое количество посетителей, введение правила, которое статические файлы кэшируются в браузере, действительно в течение одного года, не помогут вам много. Изменение содержимого файла, требуется файл с новым именем или некоторой «версией» в параметре запросов, чтобы заставить браузер загрузить новый файл. Если вы делаете выпуск каждые несколько дней, даже если вы используете куски JS/CSS, по крайней мере, какая-то часть JS/CSS будет перекомпилирована, и каждый посетитель должен загрузить его.

Затем, когда вы достигаете гигабиты на вершине трафика, вы начинаете заниматься тем, что делать дальше и, таким образом, искать CDN.

Скорость для глобальных посетителей — Если у вас есть проект, размещенный на серверах только в одной конкретной стране, это увеличивает время загрузки страниц пропорционально расстоянию. Так что дальше всего мира, медленнее на экране. Причина является высокой задержкой и низкой скоростью передачи. Но будьте осторожны здесь — если у вас есть подавляющее большинство посетителей из местной страны (для нас это чешская Республика), убедитесь, что ваш поставщик CDN имеет серверы (POPS) в Чешской Республике. В противном случае скорость нагрузки для ваших основных пользователей может замедлить после развертывания CDN. Чешская Республика — это небольшая страна, но имеет высококачественные центры данных и поставщики подключений. Загрузка контента только из попсов зарубежных стран было бы невыгодным для чешских посетителей.
Скорость для местных посетителей — Все браузеры имеют ограничение на максимальное количество одновременных запросов на IP-адрес сервера. Если браузер может загрузить контент из нескольких разных доменов и IP-адресов ( Sharding домена ), он позволит больше распараллеливания и содержимое будет загружаться в браузер быстрее. Это особенно важно для JS/CSS/изображения и шрифтов, которые являются частью исходного рендеринга страницы. HTTP/2 с мультиплексированием помогает очень хорошо решить эту проблему, но только в определенной степени. Основываясь на реальных требованиях/рендерингах, мы заключаем, что даже с потоками HTTP/2, где существуют десятки файлов в одном потоке, полученное отображение страницы медленнее, чем с участием CDN на другой домен, чем сам сайт.
Уменьшите нагрузку на первичные серверы — Если у вас нет CDN, ваши основные серверы и их подключение должны обрабатывать как динамические запросы контента, так и относительно тривиальные статические запросы данных. Это неэффективно, потому что оптимальная конфигурация сервера для динамического контента немного отличается от обработки статических файлов.
Оптимизация контента — Хороший CDN также предоставляет инструменты для данных/двоичной оптимизации статического контента. В результате переносятся меньшие данные и нагрузки нагрузки быстрее (сжатие Brotli, WebP или AVIF изображения).
Экономия затрат — Несмотря на то, что давно можно было получить почти неограниченную «толстую» линию к вашим основным серверам, прыжки довольно резки — зачем платить 10 Гбит, когда 1 Гбит достаточно для нас 90% времени?
Упрощение жизни DevOps — Если конфигурации файловых/веб-серверов и серверов приложений для максимальной производительности и безопасности являются тонкой настройкой, то необходимо иметь все возможные метрики из реальной операции. Если трафик для динамического и статического контента строго разделен, то статистика является очистителем. Поэтому возможно, чтобы сделать лучшие решения и оптимизировать производительность и параметры безопасности, точно адаптированные к конкретной рабочей нагрузке.

Есть много коммерческих CDN на рынке, например, см. В CDNPERF Отказ Наиболее известные включают CloudFlare, Amazon Cloudfront, Google, быстро, akamai, keycdn или наш любимый и рекомендуемый Bunnycdn. или CDN77 Отказ

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

Потому что мы не хотим изобретать колесо в Сайт Мы сначала посмотрели, посмотрим ли какие-либо из вышеупомянутых поставщиков. Наши требования были:

100 тб Передача данных в месяц (большинство из Европы).
Низкая задержка И быстрые трансферы в Чешской Республике/Словакии.
Очень хорошо Охват Из всей Европы хорошее освещение Северной Америки и достаточного охвата других континентов.
Http/2 (и быстрое развертывание http/3 после того, как он более стандартизирован) .
Броти Сжатие, которое даже на 15% — на 30% более эффективно для текстовых файлов, чем GZIP (словарь LZ77 +).
Автоматический Jpg/png Conversion → WebP / Avif , если поддерживается браузером (уменьшает передачу данных без заметной потери качества на 30% до 1000% в зависимости от того, насколько уже оптимизирован источник jpg/png).
TLSV1.3 с 0-RTT (нулевая круглая поездка) значительно уменьшает время коммуникации в дрожание ручного встряхивания браузеров с серверами.
API для выборочных Кэш-аннулирование, используя регулярные выражения Отказ В идеале с поддержкой метки кэша от ответа HTTP-заголовок, как X-Cache-теги или X-ключ Отказ
Защита DDOS & Веб-приложение Брандмауэр ( WAF )
Доступ к журналам и статистика.
100 ГБ хранения (обычно для видео и больших библиотек изображений).
Пользовательские сертификаты HTTPS.

Поиск поставщика, который соответствует большинству требований, не был проблемой. Проблема была цена. Для прогрессивных игроков (например, Bunnycdn или CDN77 ) Вы можете купить услугу на 1 000 евро/месяц, для других лидеров на рынке CDN, затраты начинаются с 3-4 000 евро/месяц. и увеличить кратные. Если вы начнете работать с такими суммами в качестве бюджета для создания собственного CDN, возвращение инвестиций (ROI) станет более чем интересным. Конечно, на мировом рынке есть другие поставщики ценностей на мировом рынке, но обычно их охват в Чешской Республике/Словакии очень слабы, поэтому их нельзя рекомендовать для в первую очередь местных проектов.

Объединение вышеуказанных требований с нашим энтузиазмом для его проблем мы пришли к выводу, что мы построим наших собственных CDN. Полученный (но наш собственный) CDN не является почти надежным, так как у коммерческих поставщиков, но оно соответствует всем нашим требованиям. Большим преимуществом является тот факт, что мы можем очень быстро масштабироваться в соответствии с нашими реальными потребностями, по низкой цене.

Еще одним нашим мотивациям для нашего собственного CDN является то, что мы используем GraphQL для всех веб-проектов в последние годы. В отличие от отдыха, это не может быть просто кэшировано на обратном прокси или CDN, потому что все это запросы на одну конечную точку URL. Конечно, уже есть попытки в мире, однако, коммерческий CDN не предлагает сложный кэш пост-запросов. У нас есть типы проектов, в которых умная селективная кэширование почтовых запросов на уровне CDN (вероятно, написано в Lua ) может значительно облегчить серверы приложений. Для нас это еще одна полезная выгода, которую коммерческие CDN не будут предлагать долгое время.

В конце этой главы следует отметить, что наш CDN разработан в первую очередь для обработки статических файлов, а его развертывание в сети не требует никаких изменений в DNS-происхождении домена. Следовательно, наш CDN не служит прокси-серверу для абсолютно всех запросов на сайт (который является обычным способом развертывания коммерческих CDNS), только к статическим файлам. Чтобы развернуть наш CDN, необходимо префиксировать пути к файлам с нашим основным доменом CDN, который может быть очень легко решать, без необходимости вмешиваться в сам приложение, например. Использование выходного фильтра в Nginx ( sub_filter ).

Чтобы наш CDN для удовлетворения всех необходимых параметров мы сначала пришлось предоставить все компоненты и процессы, необходимые для управления качеством CDN. И, конечно, узнайте некоторые новые области. Поскольку мы управляем более 120 серверами для наших других проектов, у нас было все, что нам нужно было справиться с этим технически и процедурно.

Следующие главы более подробно описывают отдельные компоненты CDN, которые вам понадобится:

Домен — Используется в основном для настройки правил GOODNS и возможного ссылки на другие домены через CNAME.
Геоднс — Сетевой сервис, который направит посетителей ближайших серверах в соответствии с вашими настройками и требованиями.
Серверы — стратегически расположены по всему миру, чтобы минимизировать задержку для посетителей и максимизации скорости передачи.
Технологии и их конфигурации — Тонкая настроенная операционная система и обратный прокси с кешированием и оптимизацией контента (бротли сжатие, WebP, Avif).
Операционные инструменты — У вас будет много серверов и необходимо решить оркестровку, резервное копирование, мониторинг, метрики, журналы и многое другое.
Вспомогательные приложения — Фоновые процессы, которые обеспечивают, например, статическое сжатие броти или преобразование изображений в WebP/AVIF.

Во-первых, выберите и купите домен второго уровня, на котором вы запускаете CDN. Идеально выбрать домен, который вы достигаете запросов «Cookie-Men». Во время интенсивного движения каждый байт сохранен рассчитывается. В примерах статьи мы будем использовать «Company.com» и его поддомен «cdn.company.com».

Вы будете управлять файлом DNS-зоны для этого домена с провайдером (ыми) Geodns по вашему выбору.

Получите сертификат SSL/TLS для домена, будь то шифрование или коммерческий орган по сертификации (CA). Рассмотрим сертификат подстановки, который облегчает вашу жизнь, если вы используете более одного поддомена. Вы можете получить доверенные сертификаты подстановки от всего 40 долларов США в год. Рекомендую, например, ssl2buy.com И дать несколько секунд Google код скидки. Вы часто получаете идентичный сертификат от того же CA за 30-40% от цены, чем в другом месте.

Чтобы не дать злоумышленникам от подделки других IP-адресов для вашего домена, настроить DNSSEC для вашего домена. Проверьте правильную конфигурацию DNS сами с помощью Zonemaster Инструмент из CZ.nic. Нам пришлось временно отключить DNSSEC на нашем CDN, потому что мы используем два DNSS в первичном основном режиме (для каждого из них, правила геодна и отказов определяются по-разному). В этом режиме настройка DNSSEC на обоих провайдерах сложно, потому что они оба должны делиться одним и тем же закрытым ключом или каким-либо другим решением. До сих пор это ручное вмешательство сложно для провайдеров, но они обещали позволить этому в будущем.

Независимо от того, используете ли вы этот домен непосредственно в URL-адресах или именно в качестве имени хоста, чтобы вы могли навестить к CDN для других доменов через CNAME зависит от вас.

Что вам нужно GOODN для

Критический компонент реального CDN — это область интереса, давайте назовем это: Геоднс . Вы также можете найти его под именами IP Intelligence , Геоип , Геозащитная маршрутизация, маршрутизация на основе латентности , так далее.

Geodns — это сетевой сервис, который переводит доменное имя в IP-адрес (ES) с учетом местоположения/страны, из которого приходит посетитель. Если кто-то заинтересован в деталях, они могут изучать их в RFC 7871 (клиентская подсеть в DNS-запросах) Отказ

Мы, как в качестве администратора настроек нашего домена GOODNS нашего CDN, могут определить различные правила, из которых континенты/состояния следует направлять трафик, на который должны быть направлены на какие IP-адреса (POPS в конкретных состояниях). Чтобы быть точным — POP (точка присутствия) может технически означать только один сервер или несколько серверов, перед которыми является балансировщик нагрузки (обычно, например, haproxy).

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

На практике похоже, что наш статус URL контролируется каждую минуту на каждом поп. Когда он начинает сразу потерпеть неудачу из более чем одного места одновременно, сценарий Set Failover автоматически активируется автоматически, который, согласно нашему рассмотрению, имеет 2 основных формы:

Деактивация записи DNS — В таком случае он будет прямым движением только к второму вторичному выпуску в данной местности (если таковой имеется), или посетители начнут направлять поэтапные POPS (в нашем случае все в Чешской Республике).
Замена IP-адреса с другим — С этой настройкой вы можете сказать « Если поп в Париже выходит во Францию, пусть трафик ходит в соседнюю поп в Нидерландах вместо этого, и если это не произойдет случайно, чтобы поп в Германии «.

Благодаря минуту TTL, действительно нефункциональный поп деактивирован или заменяется другим, не позднее, чем через 2-3 минуты для всех посетителей. Однако, если у вас есть как минимум два попса, определенные для каждого местоположения (DNS решает до 2 IP-адресов), то браузеры смогут справиться с таким отключением, и посетители могут даже не знать критический 2-3 минуты, который Мы опишем в следующую главу. Если у вас есть только один поп, определенный для сайта, и у вас нет резервной копии, определяемого для него, то посетителей с этого сайта находятся в случае сбоя пути к выпуску по умолчанию, которые установлены по умолчанию для «остальных Мир».

Даже учитывая минуту TTL, необходимо подумать о скорости перевода DNS, это также оказывает существенное влияние на скорость нагрузки страницы. Поэтому мы рекомендуем вам выбрать поставщик DNS, который имеет Sancast NS (Servers name) по всему миру. CloudFlare ведет в скоростную лестницу, см. Ориентиры на Dnsperf.com. . С Global Provider DNS вы можете быть уверены, что ваш домен будет переведен на единицы до десятков миллисекунд по всему миру.

Браузеры также помогают с высокой доступностью

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

Отказ одного из IP-адресов/серверов/поставщиков не приведет к неисправности необходимого контента. Это займет всего немного дольше, чтобы загрузить страницу. Сегодняшние браузеры уже действительно умны и очень полезны с точки зрения обнаружения отключения, восстановления соединения и логики автоматической повторной попытки. Военная сила этой области в основном мобильные/портативные устройства, где есть частые мини-отключения из-за коммутации подключения между BTS в мобильных сетях, их чередование с сетью WiFi и т. Д.

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

Если вы изучали эту уникальную проблему, поделитесь информацией в обсуждении с нами:-)

Какой провайдер Geodns выбрать?

Есть много поставщиков Geodns на выбор — стоит упомянуть Amazon Manorebroceble 53, Cloudns , NS1, Constellix Geodns , Fastdns от Akamai, Easydns, Ultrandns от Neustar или DNS облегчали.

Из-за высокой доступности мы не рекомендуем полагаться только на один поставщик DNS, даже если он имеет NS-серверы по всему миру, с IP-адресами Anycast. Аналогичным образом, распределение изменений обычно решается одним «центральным мозгом», и раз в несколько лет возникают дефекты, которые в конечном итоге влияют на большее или все NS-серверы сразу (реальный опыт 2019 года). Поэтому мы решили пойти на маршрут избыточных первичных первичных настроек, где мы запускаем все настройки Geodns в двух полностью независимых поставщиках.

Это немного раздражает, потому что протокол AXFR для синхронизации DNS-зон Geodns не поддерживает проблему, поэтому мы должны управлять всем вручную с двумя независимыми поставщиками. Мы проверили шесть поставщиков Geodns и из-за их понимания «Моделирование правила Geodns» и мониторинга, мы не можем представить, что кто-то предложит единую спецификацию проблем геоДНН, чтобы синхронизировать зоны DNS.

Мы на Сайтон выбрали для Geodns как первые Cloudns Поставщик предлагает отличные варианты для настройки самих «Geo» и автоматическое отработка с несколькими вариантами поведения. Поставщик имеет защиту DDOS, имеет Anycast IP-адреса и низкую задержку из Чешской Республики/Словакии. Он также предоставляет статистику трафика и имеет очень достойные пределы и ценообразование из-за количества DNS-запросов (в базовом пакете Geodns в каждом месяце насчитывается 100 м).

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

Как второй поставщик DNS, мы выбрали компанию Constellix (Сестра DNS Make Preake), которая предлагает аналогичные варианты создания проблем, мониторинга и отработки геоднов, как Cloudns Отказ Сила CONTELLIX — это определение весов (распределение трафика) в некоторых ситуациях.

Сначала нам также понравился Microsoft Azure и его менеджер по трафикам, но в конце концов мы отдали его, потому что оно не дало нам возможность управлять трафиком в некоторых странах, как мы хотели. Тем не менее, Azure приятно удивил нас своей ценовой политикой в области DNS по сравнению с другими глобальными облачными поставщиками, такими как Amazon или Google.

Route53 от Amazon стоит учитывать, что является более рентабельно эффективным, если DNS разрешит к IP-адресам в AWS. Однако, если вы отправляете десятки туберкулеза или более от AWS в месяц, а затем ожидайте ежемесячных расходов в тысячах USD/EUR. Но у вас уже есть одинаковый или более дорогой, как будто вы удобно арендуете коммерческую CDN.

Однако для всех провайдеров Geodns цена зависит главным образом на количестве запросов DNS и количества и частоты проверки здоровья. Другими словами, от количества выпусков вы находитесь в CDN, или от того, сколько мест по всему миру у вас есть мониторинг, чтобы устранить ложные позитивы и, конечно же, частоту мониторинга, которая обычно может быть установлена от 30 секунд для десятков минут — наш по умолчанию стоит одна минута. Вы также можете снизить цену для DNS-запросов много раз, увеличивая TTL для отдельных записей DNS. Однако и, конечно, за счет скорости возможного автоматического переключения, потому что рекурсивный кэш NS будет сохранять переводы дольше в их кэше.

Для крупнейших пионеров также есть вариант для создания собственного сервиса Geodns со своими собственными серверами имени. Но для этого необходимо иметь смысл и реальную ценность, будут необходимы Anycast IP-адреса. Также ряд других надежных серверов по всему миру с защитой DDOS, а затем понять, выбирать и адаптировать, например, Edgedns или чешский Узел Днс (который также использует CloudFlare). Тем не менее, коммерческие услуги Geodns относительно дешевы и надежны, поэтому мы не можем представить себе ROI, который имел смысл с нашим собственным небольшим, некоммерческим решением DNS.

Гео на макет и выбор провайдера

Если вы собираетесь создать свой собственный CDN, а затем примите во внимание, что если это будет реальным CDN, вам понадобится 8-10 серверов по всему миру даже в самых маленьких настройках. В настоящее время у нас есть двадцать продукцию и три тестовых. У нас также есть два POPS для разработки, доступные только во внутренней сети, что разработчики могут использовать для развертывания CDN для доменов внутренней разработки.

Основная цель CDN состоит в том, чтобы предоставлять посетителям по всему миру с самой низкой возможной задержкой и максимальной скоростью передачи данных к данным, которые CDN кэширует локально.

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

В начале у вас не будет серверов в каждом штате, и, вероятно, не на каждом континенте, поэтому рассмотрите «водосборные районы». Однако на основе реальных задержек и измерений Traceroute вы часто удивляетесь, что задержка между провайдерами в каждом состоянии не соответствует географической близости. Взгляды между государствами и отдельными провайдерами различны, очень часто «сосед не соседа». Например. Из Финляндии вы можете значительно снизить задержку в Чешскую Республику, чем в Польшу для некоторых поставщиков. Если у вас еще нет серверов за границей, через которые вы можете выполнить измерения, Wondernetwork.com. Инструмент также может помочь вам. Этот инструмент показывает задержку между различными городами мира, наоборот. Конечно, это плата за провайдер, используемый в этом инструменте, но достаточно для ориентации.

Сделайте хорошее исследование рынка при выборе провайдера и подключения сервера. Конечно, цена не единственный или последний фактор, но он не должен быть первым. Мы сосредоточились на:

Качество и репутация поставщика — В каждом состоянии обычно выделяются 2-3 крепких провайдеров, которые должны быть самыми надежными. Их надежная инфраструктура должна быть лучше, чтобы противостоять потенциальным атакам DDOS. Мы не рекомендуем небольшим и непроверенным поставщикам.
Местное и глобальное подключение провайдера — Необходимо учитывать, что серверы будут обрабатывать большой трафик. Отчасти в своей собственной стране некоторые районы водосбора для других государств. Поэтому сосредоточиться на изучении и сравнении их подключения за рубежом. Поставщик качества описывает свое подключение к сети, потому что это обычно гордится этим. Сверхтория , который у нас есть часть нашей инфраструктуры в течение 15 лет, отлично подходит для нас.
Опора качества — Рано или поздно некоторые проблемы определенно возникают, и необходимо быстро реагировать. В качестве первого теста вы можете общаться с поддержкой о том, какую строку на самом деле будет доступно сервер (обычно 100 или 1000 Мбит/с), какая у него агрегация, а что они подразумевают под «неограниченным движением. «Если это включает ваши оценочные XY Terabytes в месяц, что сервер должен будет обрабатывать. Вы можете задать второй вопрос к возможностям и функционированию их защиты DDOS.
Ожидаемый трафик данных На данном сервере должен В идеале будет включен в цену или должен быть прозрачная политика ценообразования заранее.

Наш CDN в настоящее время считает, что 20 POPS и каждый из другого поставщика. До сих пор наши первичные чешские/словацкие посетители покрыты шестью попсами (4 × Прага, Брно и Братислава). Тогда Германия (два попса) и Польша (два попса) для части Восточной и Северной Европы. У нас также есть один поп во Франции, Италии, Англии и Венгрии. Два попса также покрывают Северную Америку. Южная Америка покрыта только одним поп в Сан-Паулу. Африка покрыта One Pop в Каире, Австралия на одном поп-Сиднее, Российской Федерации на одну поп в Москве и Азии на один поп в Мумбаи. Эти СОЗ также включают в себя выбранные соседние государства, где именно нам имеет смысл в соответствии с измеренными задержками.

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

Рекомендация : Выберите по крайней мере два независимых поставщика в каждом важном месте — в идеале с различным внешним подключением. Постарайтесь убедиться, что по крайней мере два независимых POPS (IP-адреса) решаются в каждом сайте DNS. В случае неудачи одного из попсов посетителей не придется ждать 2-3 минуты для отказа DNS, потому что браузеры обнаруживают это и немедленно переключите трафик на другой IP-адрес. В текущих версиях браузера вы увидите только « Connecting …» В течение 2-3 секунд и содержимое затем будет прочитано сразу со второго IP-адреса.

Совет: Вы можете проверить качество вашей топологии CDN (особенно в отношении задержек разных частей мира), используя онлайн-инструмент MapLatency.com . Это здорово в том, что он измеряет задержку с конечных точек на разных интернет-провайдеров, что означает, что она измеряет более реалистичные задержки посетителей к вашему CDN, а не только от серверов/центров данных. Для нас покрытие Европы является ключом, и у нас это очень хорошо для наших потребностей (см. Скриншот). Тест задержки CDN От CDNPERF выполняет ту же цель — но он измеряет задержки от центров обработки данных, а не от конечных устройств.

Использование коммерческого CDN для лучшего покрытия

В какой-то момент вы будете очень сожалеть (а также мы), что вы не дадите посетителей в удаленные уголки мира (для нас в основном в Африке, Азии, Австралии и Южной Америке) такой комфорт (задержка и скорость передачи) как в Европе. Но даже у этого есть собственное эффективное и простое решение.

Вы можете покрыть дистанционные углы мира с коммерческим поставщиком CDN, который имеет надежную инфраструктуру и сильное покрытие в этих местах. Поскольку это низкоэтажные вторичные объекты (сотни ГБ до единицы туберкулезом в месяц), вы можете воспользоваться поставщиком CDN Pay-As-You-CDN и стоить вам несколько десятков или сотни долларов в месяц. С одной стороны, это может показаться паразитизмом, но с другой стороны, когда мы рассмотрели IP-адреса коммерческих CDN в разных странах, мы обнаружили, что некоторые поставщики поделились своей собственной инфраструктурой в разных местах. Так что это не необычно. Мы все хотим доставить максимальное значение нашим клиентам, но в то же время мы должны думать об экономике и эксплуатационных расходах.

Как настроить?

Коммерческий CDN Будет ли обеспечить Вы с именем хоста , как правило, под доменом 3-го порядка управляемого в их геодене (например, « mycompany.cdn-provider.com »), к которому вы можете указать свой домен CDN через CNAME.
Для Коммерческий CDN, набор Это, чтобы «слушать» к вашему «cdn.company.com» Домен в Дополнение к имя хоста, упомянутого выше. Вам также нужно будет настроить сертификат SSL/TLS. Поставщик, вероятно, предложит вам возможность использовать, давайте шифрование, но мы рекомендуем использовать свой собственный сертификат SSL, приобретенный у публики CA, униформу для всех попсов. Если у вас есть разные сертификаты в разных местах и, кроме того, с коротким действительностью, нельзя использовать SSL-пиннинг, который вам может понадобиться в некоторых ситуациях.
Для вашего провайдера Geodns маршрут cname вашего домена во всех вторичных местах к имени имени хоста коммерческого CDN. Технически проиллюстрировано: установите его на » (Африка) cdn.company.com → cname mycompany.cdn-provider.com».
Вы должны избегать петлей Отказ Вы не должны сообщить коммерческому CDN слушать « CDN.company.com » и в то же время установите его как оригинальный домен. Африканский поп будет решен бы по себе DNS-происхождение. Чтобы предотвратить такой цикл, вы должны убедиться, что несколько крупных попсов будут слушать домен, например, cdn-src.company.com «(Он направляет записи, например, три главных попса в ЕС). Затем вы установите » cdn-src.company.com «Как происхождение, так что если бы поп-коммерческий CDN не имеет файла в его кэше, он скачал его из одного из главных попсов в ЕС через« ». cdn-src.company.com «.
Если со временем вы узнаете из Статистика и биллинг Чтобы вы будете более выгодны для того, чтобы вы охватывали местоположение с вашим попсом из-за увеличения трафика, то у вас всегда есть опция, и вы можете развернуть его без отключения.

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

Аппаратное обеспечение

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

Несколько наших проверенных рекомендаций

Виртуальный против физического сервера — Это довольно противоречивая тема, и не уместно обобщать его. Если экономика позволяет выбрать физические серверы для критических серверов, даже если только из базового меню. Избыточные диски являются обязательными, в идеале с резервным источником питания. С физическим сервером вы обычно получаете восходящую ссылку на 1 Гбит/с и прямую физическую связь непосредственно к переключанию TOR. Существует гораздо более низкая вероятность того, что вы будете бороться с обменом CPU и IO или подключением к физическому гипервизору, работающим сотням, или десятки виртуальных серверов в лучшем случае. Если вам повезет, у них есть общая «трубка» * × 10 Гбит или хуже, у них 1 Гбит. С аутентифицированными поставщиками вам даже не нужно беспокоиться о виртуальных серверах, просто посмотрите на агрегацию и производительность (например, ориентир жен ). Со временем собранные метрики также скажут вам много, особенно для избыточных попсов, которые будут обрабатывать ± тот же трафик (DNS Round-Robin). В результате мы очень быстро обнаружили очень агрессивный процессорный дросселинг или волатильный производительность IO у некоторых поставщиков.
ЦП — Если вы сделаете это умно и правильно затяните статическое сжатие GZIP и Brotli, вы сможете обрабатывать сотни Мбит/с даже с 1-2 сердечниками CPU. Тем не менее, если вы не предоставляете статическое сжатие и Ad-Hoc Compress каждый запрос, вам нужно не менее 4-8 ядер. Хорошо выбрать современный процессор с высокой часовой скоростью (Turbo на 3 ГГц +). Кстати, отсутствие статического сжатия — это то, что, согласно нашим тестам, коммерческие CDN часто отсутствуют, и в результате они отправляют текстовое содержание гораздо медленнее, чем с ним.
Рам — Минимум 1 ГБ, но чем больше, тем лучше. Это связано с тем, что файловая система кэша (PageCache) хранится в оперативной памяти. Обычно этот кеш будет содержать большинство маленьких, но наиболее загруженных файлов (обычно JS/CSS/fonts). Чем больше их вписывается в ОЗУ, тем ниже требования к IOPS, так что вы можете более безопасно позволить себе более широкий вращающийся жесткий диск вместо SSD. Когда у вас достаточно оперативной памяти, даже с сотнями Мбит/с, вы можете иметь почти нулевые IOPS на хранилище.
SSD/NVME против HDD — Конечно, мы рекомендуем SSD/NVME для обработки высоких IOPS. Но реальная потребность зависит от фактической операции. Мы предпочитали SSD на высокой емкости повсюду. 100-200 ГБ PER-Server достаточно для нас. Но также необходимо учитывать тот факт, что вам нужно войти в систему. Оптимально вращать журналы непрерывно, отправлять их в точку сбора для дальнейшей обработки и очистить их.
Подключение — Желательно иметь реалистичную идею о том, сколько трафика и особенно его пиков вы будете обращаться. Что касается менее важных поп, будет достаточно 100 Мбит/с. Тем не менее, когда дело доходит до POP в важном месте, предпочитайте 1 Гбит/с и распределите нагрузку между несколькими попсами (ROBIN DNS, когда возвращаются больше записей). Вы достигнете общей более высокой пропускной способности и более низкой нагрузки на определенные провайдеры, в дополнение к более высокой доступности CDN в целом. Кто бы ни был бюджет и реальная потребность в этом, конечно, может выбрать порт 10 Гбит/с, но необходимо рассчитывать на высокую цену.

Оркестровка

Поскольку вы будете управлять несколькими серверами по всему миру с идентичной конфигурацией 99%, вам необходимо обеспечить автоматическую установку, конфигурацию и массовую оркестровку.

Мы используем и рекомендуем Anbible Отказ Исторически мы также использовали кукольную, шеф-повар и SaltStack на некоторое время, но только однозначные встречи встречи с тем, что нам нужно много лет. За годы использования у нас в нем более 80 собственных ролей, поэтому при подготовке каждого дополнительного сервера самым трудоемким является заказы и ожидание электронной почты активации. Если у нас есть 10 или 50 серверов, это не имеет значения с точки зрения оркестрации.

Независимо от того, независимо от того, управляете ли вы серверами с любым инструментом Orchestration, мы рекомендуем несколько вещей, которые помогут вам устранить «глобальное отключение»:

Когда Развертывание изменений Для всех серверов навалом , будьте осторожны — развертывание отдельных серверов должно работать в серии, а не параллельно. Возможно, также параллельно, но например, после трех серверов одновременно одновременно (в Anisible Playbook это управляется директивой « Serial »). Если развертывание на одном из серверов не удается, заставляйте развертывание для прерваний (в неспособной директиве » max_fail_percentage «).
До Перезапуск/перезагрузка компонентов, Первый Проверьте достоверность конфигурации ( Configtest ). Устранить отключения, связанные с недействительной конфигурацией. Некоторые распределения и их сценарии init не делают этого автоматически. Идеально, Configtest Должно быть выполнено, прежде чем перезапустить службу, чтобы предотвратить остановку и запуск службы.
На конец развертывания на отдельный сервер, выполните Набор тестов функциональности CDN на этом конкретном сервере. Например. Призывая URL-адрес статуса и в идеале также, также позвонив некоторое функциональный URL из одного из оригиналов, который будет возвращен из кэша, а также один URL, который, напротив, не будет в кэше и должен быть загружен из оригинал. У нас также есть одна «сервисная» домен происхождения для этих целей. В сочетании с серийным развертыванием вы можете быть уверены, что вы не будете вызывать отключения на более чем 1 попс одновременно.

Если у вас уже есть подготовленные серверы, вас ждет действительно интересная и творческая часть — подготовка конфигураций отдельных компонентов SW, из которых состоит CDN.

В следующей статье (через 2-3 недели) мы сосредоточимся на настройках операционной системы (с реальными настройками для Debian Linux), обратный прокси ( nginx в качестве кеша) и другие аспекты, связанные с трафиком CDN — Оптимизация контента, безопасность, защита атаки или настройки, которые влияют на поведение поисковых систем. И, возможно, также течения кэширования и его недействительность на основе Лак (Мы работаем над этим в эти недели). Это очень полезная особенность, которую предлагают очень немногие поставщики CDN и только в их самых дорогих планах.

Спасибо за чтение, а если вам нравится статью, я буду счастлив, если вы поделитесь этим или оставьте комментарий. Хорошего дня:-)

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

Оригинал: «https://dev.to/janreges/how-to-build-a-cdn-1-3-introduction-and-basic-components-345o»