G-Core Labs Хостинг

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



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

С динамическим контентом всё сложней, так как он уникален для каждого пользователя и его нельзя кешировать. Значит, и ускорить доставку не получится? Получится: если CDN отвечает ряду критериев, то она справится и с ускорением динамики.

1. Отличная связность
Быстрая доставка контента во многом зависит от связности сети. Чем больше у CDN пиринг-партнёров, тем лучше связность и тем более короткий маршрут от источника до пользователя может быть построен. А чем короче маршрут, тем быстрее данные будут доставлены. На это обязательно нужно обращать внимание при выборе сети доставки контента, идёт речь о статике или динамике.


2. Поддержка HTTP/2
HTTP/2 — это последняя версия протокола HTTP. Использование этой версии во многом помогает ускорить отдачу контента — главным образом за счёт мультиплексирования, то есть передачи нескольких потоков данных по одному каналу.

Чтобы отправить информацию, HTTP сначала должен установить TCP-соединение. Для этого требуется «тройное рукопожатие»:

• Отправитель посылает запрос на установку соединения — сообщение SYN и порядковый номер переданного байта.
• Получатель в ответ посылает сообщение SYN, подтверждает получение данных сообщением ACK и отправляет номер байта, который должен быть получен следующим.
• Отправитель тоже подтверждает, что получил информацию, и посылает номер следующего ожидаемого байта.

После этих трёх шагов соединение считается установленным.


В предыдущих версиях HTTP для передачи каждого элемента (JаvaScript, CSS, изображений и других данных) открывалось отдельное TCP-соединение. «Тройное рукопожатие» нужно было проводить каждый раз, и это сильно замедляло доставку.

В HTTP/2 для всех этих данных устанавливается единое TCP-соединение. При этом разные типы информации могут отдаваться параллельно. Это значительно экономит время на передачу контента.


HTTP/2 помогает ускорить доставку и по другим причинам:

• Это бинарный протокол. Использование бинарного формата вместо текстового значительно облегчает выполнение команд. В таких протоколах меньше ошибок, меньше нагрузка на сеть и, как следствие, меньше задержек.
• Умеет сжимать заголовки. Заголовок — это тоже данные. А чем больше данных передаётся, тем медленнее они доходят до пользователя. HTTP/2 сжимает заголовки по алгоритму Хаффмана и опускает повторяющиеся.
• Доступна приоритезация запросов. Определённую информацию можно назначить приоритетной — тогда она будут отдаваться в самом начале и загружаться быстрее. В первом приоритете можно отдавать самые важные элементы страницы, которые должны отобразиться у пользователя в первую очередь.
• Есть функция Server Push. Она позволяет предугадывать, какие данные понадобятся клиенту, и отправлять их ещё до того, как поступил запрос. Это ускоряет загрузку, снижает количество запросов, а значит, уменьшает нагрузку на источник.

Мы заботимся не только о скорости доставки, но и о безопасности. Поэтому в G-Core Labs CDN есть функция принудительного редиректа на HTTPS. Это значит, что даже если передача по HTTPS не настроена на источнике, вы всё равно можете доставлять контент безопасно. Благодаря использованию HTTP/2 и TLS 1.3 безопасное подключение не будет замедлять отдачу контента, а то есть приложение будет работать быстро и безопасно.

3. Поддержка WebSocket
WebSocket — это независимый протокол на основе TCP. Он даёт возможность обмениваться сообщениями между клиентом и сервером в режиме реального времени.

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

Возьмём для примера чат. Чтобы клиент узнал, что ему пришло новое сообщение, браузер должен периодически отправлять запросы на сервер и узнавать, нет ли новой информации.

Минусы такого подхода:

• Увеличивается количество запросов к серверу. Из-за этого растёт нагрузка и падает скорость обработки запросов.
• Данные обновляются медленнее. Так как браузер посылает запросы с определённой периодичностью, передать новое сообщение клиенту он может не сразу. Это создаёт задержки при доставке контента.

WebSocket же устанавливает постоянное соединение. И когда появится новое сообщение, сервер сразу отправит его клиенту.


Это сокращает количество запросов и увеличивает скорость отдачи данных.

Если вы хотите быстро доставлять часто меняющийся динамический контент (сообщения в чатах, push-уведомления и любые другие данные, которые постоянно обновляются на сайте), без WebSocket не обойтись.

4. Использование IPV6
IPv6 — более современная версия протокола IP. Он был разработан главным образом для того, чтобы решить проблему нехватки IP-адресов. Если в IPv4 для создания адреса используется 32-битная система, то в IPv6 — 128-битная.

Адрес IPv6 — это восемь 16-битных блоков, разделённых двоеточием. И общее количество IP-адресов, которые можно создать, составляет 2128 — это более 300 млн адресов на каждого жителя планеты. Такого количества должно хватить каждому устройству.

Но, кроме записи IP-адресов, в обновлённую версию протокола внесли и другие изменения, сделав его более эффективным для передачи информации.

• Меньшая нагрузка на сетевое оборудование. Эта версия протокола не использует NAT — технологию для преобразования приватных адресов в публичные.
• NAT был нужен в IPv4, так как там существовала проблема нехватки адресов. Внутри локальной сети у каждого устройства был приватный IP-адрес, который использовался для локальной передачи данных, например между устройствами внутри одной компании. Но для взаимодействия с другими ресурсами через глобальный интернет нужен был публичный, общедоступный адрес.
• NAT преобразовывал приватный адрес в публичный — этот процесс называется трансляцией. При этом нужно было не только преобразовывать адреса, но и хранить информацию об установленных соединениях. Это увеличивало нагрузку на оборудование, и во время пиковых скачков трафика скорость падала. В IPv6 нет необходимости в трансляции, не нужно хранить информацию о соединениях, а значит, нагрузка на оборудование меньше и скорость остаётся стабильной.
• Более простые заголовки пакетов. В новой версии из них убрали несущественные элементы. Это упростило обработку, снизило нагрузку на маршрутизаторы и в целом сократило объём передаваемых данных.
• Более быстрая маршрутизация. Структура адреса IPv6 устроена так, что маршрутизаторы на каждом уровне сети (крупные провайдеры, подсети, сети организаций) обрабатывают не весь адрес, а его часть. Это уменьшает размер таблицы маршрутизации, а значит, сокращает время на обработку.
• Определяет чувствительные к задержкам пакеты и передаёт их в первую очередь. Такую возможность даёт функция QoS (Quality of Service). Это специальная технология, которая умеет определять тип трафика и приоритизировать его на основании этого.

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

5. Сжатие на лету
Чем меньше весит контент, тем быстрее он будет доставлен пользователям. Но жертвовать важными элементами в угоду размеру — не лучшая идея. Эту проблему решает использование современных алгоритмов сжатия: Gzip, Brotli и WebP.

• Gzip предназначен для сжатия текстового контента. Он находит в файлах одинаковые строки и объединяет их. За счёт этого размер данных уменьшается на 60–70%.
• Brotli уменьшает размер любого контента. Для сжатия он использует уже встроенный в браузеры пользователей словарь из более чем 100 000 самых часто встречающихся в интернете элементов. Алгоритм находит эти элементы в передаваемых данных, вычисляет уникальные фрагменты и передаёт только их, а неуникальные добавляет из словаря. Brotli на 20–25% эффективнее Gzip.
• WebP — новый алгоритм для сжатия изображений. Он на 26% лучше PNG сжимает изображения без потерь и на 25–34% эффективнее JPG при сжатии изображений с потерями.

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


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

7. Функции аутентификации на стороне провайдера
Если вам нужно предоставлять ограниченный доступ к контенту, вы можете перенести функции аутентификации на CDN. Это позволит избавить сервер от дополнительной нагрузки, а значит, и увеличить скорость. В нашей CDN для этого доступна опция Secure Token. Она позволяет создавать временные ссылки, которые содержат специальный хеш-ключ, и контент получается загрузить только по запросам, содержащим этот ключ.

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

8. Облачное объектное хранилище
Контент важно не только эффективно доставлять, но и хранить. Возьмём, например, интернет-магазин. Чтобы отобразить покупателю индивидуальную подборку рекомендуемых товаров, вместе с остальными данными нужно загрузить и фото товаров. Для хранения такого контента требуются большие объёмы памяти. А при запросе клиента нужно быстро извлечь нужные файлы, сформировать ответ и отдать в нужном виде.

Хранение контента — это большая нагрузка и крупные затраты на вычислительные мощности. Поэтому эффективнее будет не размещать файлы на своих серверах, а арендовать облачное объектное хранилище.

В отличие от других типов, в объектных хранилищах нет иерархии — файлы извлекаются напрямую, за счёт чего сокращается время на их отдачу.

Как это относится к CDN? У G-Core Labs есть объектное хранилище, в которое можно поместить данные практически любого объёма, максимально быстро извлекать и доставлять их. Хранилище оптимизировано под работу с динамическими веб-ресурсами. Подключить его можно вместе с CDN и управлять ими через единую панель.

Подведём итоги

• Есть мнение, что CDN может ускорить доставку только статического контента и плохо работает с динамикой. Но на самом деле, если сеть поддерживает определённые функции, она отлично справится и с ускорением динамики.
• Чтобы CDN могла построить лучший маршрут для доставки данных, у неё должно быть отличная связность. У G-Core Labs CDN больше 6 000 пиринг-партнёров, поэтому она позволяет передавать данные максимально быстро.
• CDN должна поддерживать HTTP/2, так как он намного эффективнее предыдущих версий HTTP. Его главный плюс в том, что для передачи любых типов файлов он устанавливает только одно TCP-соединение.
• В CDN должна быть поддержка WebSocket — этот протокол для передачи данных в реальном времени упрощает доставку часто меняющегося динамического контента, поэтому без него не обойтись.
• Чтобы быстрее доставлять контент, CDN важно поддерживать протокол IPv6. Желательно, чтобы сеть позволяла использовать эту версию протокола, даже если её ещё не поддерживает оборудование пользователя.
• Важно, чтобы провайдер умел сжимать контент на лету прямо на стороне CDN, в процессе доставки с помощью алгоритмов Brotli, Gzip и WebP.
• У CDN должны быть гибкие настройки кеширования. Желательно, чтобы провайдер мог взять функции аутентификации пользователей на себя, чтобы снизить нагрузку на ваши ресурсы.
• Вместе с CDN можно подключить объектное хранилище, чтобы эффективно доставлять и хранить данные.

G-Core Labs CDN отвечает всем этим критериям, поэтому доставляет динамику так же быстро, как и статику. За производительность сети отвечают технологии Intel: в апреле 2021 мы одними из первых в мире начали интеграцию процессоров Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих сервисов. Убедиться в высокой скорости доставки динамического контента с помощью нашей CDN вы можете бесплатно — для этого у нас предусмотрен бесплатный тариф, а также бесплатный пробный период на любом тарифном плане.
gcorelabs.com/ru/cdn/

Наш клиент планирует стримить видео празднования Нового года на всех своих пользователей. Транслировать контент предстоит на сотни тысяч человек с минимальными задержками — так, чтобы зрители встретили 2022 год не позже соседей. Мы сравнили решения для быстрой доставки видео и делимся результатами: рассказываем, как организовать дешёвый стриминг медиаданных на большую аудиторию.



В прошлом году при трансляции Суперкубка представители видеоплатформ ожидали задержек вплоть до минуты. Это плохо сказывается на пользовательском опыте: крики более удачливых соседей и другие спойлеры портят игру болельщикам. Мы придумали, как решить ту же проблему в новогодние праздники. Для нашего клиента мы подобрали протокол для дешёвой realtime-трансляции видео на большую аудиторию. Это позволит зрителям встретить 2022 год в реальном времени — не позже, чем их соседи.

Выбираем протокол: WebRTC, HLS, MPEG-DASH
Для стриминга видео есть три ключевых протокола: HLS, MPEG-DASH и WebRTC. Наша инфраструктура поддерживает все эти технологии, но есть вопрос: какой протокол лучше подходит для дешёвого и быстрого стриминга видео на сотни тысяч или миллионы пользователей?

Быстро: WebRTC
С помощью RTMP видео до конечного зрителя не доставляется уже много лет, так что мы сразу перешли к WebRTC. Большой плюс: видео по этому протоколу передаётся быстро, хоть и без сохранения высокого качества. Однако, технология не подошла по другим причинам: для масштабирования она требует установки серверов по всему миру, а так как клиенту нужно транслировать видео на большую аудиторию, это приведёт к дополнительным тратам. Мы рассмотрели другие варианты.

Дёшево: HLS и MPEG-DASH
Чтобы клиент уложился в бюджет, мы обдумали ещё два решения: HLS и MPEG-DASH. Эти технологии отлично подходят для недорогого стриминга на сотни тысяч и даже миллионы пользователей. Но у клиента было важное требование: задержки должны быть минимальными. Скорость передачи данных с помощью этих технологий оказалась недостаточной, чтобы проводить интерактивное мероприятие и стримить праздник в режиме реального времени.

Дёшево и быстро: ?
Нам нужно было как-то объединить возможности первых двух вариантов — сделать всё и дёшево, и быстро. Для этого потребовалось новое решение.

Что такое HESP и чем он отличается от других протоколов
HESP — новый протокол для стриминга с низкими задержками. Как заявляют создатели, он легко масштабируется и позволяет недорого транслировать медиаконтент хоть на миллионную аудиторию. Мы разобрались, правда ли это и сравнили его с другими технологиями.

1. Передача данных в два потока
В отличие от других протоколов, стриминг с помощью HESP происходит в два потока:

• Поток инициализации может запрашивать изображения в любой момент для начала воспроизведения.
• «Поток продолжения» может продолжить воспроизведение после любого изображения потока инициализации.

Это позволяет быстро и беспрерывно транслировать и воспроизводить видео в плеере пользователя. Пока один поток запрашивает изображения для начала воспроизведения, второй позволяет продолжать воспроизведение. Посмотрим, как это работает.

1. Сначала включается поток инициализации.

2. Затем в работу включается поток продолжения.

3. Это обеспечивает беспрерывное воспроизведение видео.

4. Потоки дополняют друг друга и работают один за другим.


2. HESP основан на HTTP и передаётся через CDN
HESP поддерживает передачу данных по протоколам HTTP/1.1 и HTTP/2. Это значит, что стримить видео с его помощью можно дёшево — по CDN. Это также относится и к HLS с MPEG-DASH, но с HESP задержки оказываются меньше: до 2 секунд даже при трансляции на миллионную аудиторию.

Что касается WebRTC, он не подходит для трансляций через CDN, поэтому стриминг на большую аудиторию с его помощью оказывается в 2–5 раз дороже, чем по HESP.

3. Низкие требования к полосе пропускания
Новому протоколу нужно на 10–20% меньше полосы пропускания, чем другим решениям с низкими задержками: LL-HLS, Chunked CMAF, WebRTC.

4. Поддержка адаптивного битрейта (ABR)
HESP совместим с технологией адаптивного битрейта. Это значит, что стримы доступны без буферизации на любых устройствах и при любом качестве интернета у пользователей.

… и другие отличия
Все отличия HESP от других технологий мы собрали в простую сравнительную таблицу:


В результате этих отличий новый протокол получил реальные преимущества перед другими технологиями:

• Позволяет доставлять видео с задержками 0,4–2 секунды.
• Требует меньшую полосу пропускания для передачи стрима.
• Может передаваться через CDN миллионам зрителей на любые устройства, в любую точку мира и с сохранением качества хоть 8К.
• Гарантирует минимальную стоимость трансляции в сравнении с WebRTC.

Где выгодно применять HESP
Трансляцией Нового года или спортивных событий всё не ограничивается: сократить задержки и бюджеты на стриминг важно многим. Вот пара возможных областей применения HESP:

• Киберспорт и гейминг. Аудитории здесь большие, а высокие задержки в трансляциях быстро уводят пользователей к конкурентам. HESP помогает удерживать аудиторию и не тратить лишнее на стриминг.
• Онлайн-образование и телемедицина. В MedTech и e-learning для трансляций с учениками и пациентами часто используют дорогие внешние решения. HESP позволяет отказаться от них и самостоятельно организовать стриминг с минимальными задержками.
• Аукционы и онлайн-казино. В этих сферах видео нужно транслировать быстро и в высоком качестве. HESP даёт эту возможность.
• Спорт и медиа. С новым протоколом трансляция спортивных и других мероприятий максимально приближается к реальному времени. При этом видео через интернет передаётся даже быстрее, чем по ТВ.
• OTT и ТВ-вещание. HESP позволяет объединить IPTV- и OTT-решения для создания трансляций высшего качества. С его помощью издатели могут дёшево транслировать контент на самую крупную аудиторию.

Этот список можно продолжать долго: дешёвые и быстрые решения любят все. Нужно только разобраться с интеграцией протокола в процесс создания и доставки видео до пользователей.

Как перейти на HESP
Чтобы подключить новый протокол, мы вступили в HESP Alliance. Теперь наша инфраструктура поддерживает стриминг с низкими задержками с помощью этой технологии. Для перехода на неё клиентам достаточно подключиться к нашей сети доставки контента с поддержкой HESP. Эта инфраструктура включает больше 140 точек присутствия в 100 городах и гарантирует высокую производительность: в апреле 2021 мы одними из первых в мире начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих сервисов.


Помимо CDN для подключения HESP достаточно внедрить ещё два элемента: HESP-упаковщик для кодирования видео перед передачей (есть у партнёров HESP Alliance) и плеер с поддержкой протокола — например, THEOplayer.
www.hespalliance.org/members

Как бы хороша ни была ваша CDN, часть пользователей будет мучаться с её настройкой. Нам, как одному из топ-3 европейских CDN-провайдеров, очень хотелось сократить число таких пользователей до минимума. Для этого пришлось повозиться с интерфейсом личного кабинета, разработать плагины для CMS и, что самое главное, интегрировать CDN с DNS-хостингом. Теперь пользователи в no-code режиме подключают сеть доставки контента к своим сайтам за несколько минут. Рассказываем, как мы это сделали.

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

Обычно ссылки на файлы выглядят так:

https://gcorelabs.com/image.jpg 
https://gcorelabs.com/style.css 
https://gcorelabs.com/script.js

Если же ссылки ведут на кеш-сервер, они выглядят примерно так:

https://cdn.gcorelabs.com/image.jpg 
https://cdn.gcorelabs.com/style.css 
https://cdn.gcorelabs.com/script.js

Тут у пользователей и возникает проблема: многие не знают, как именно заменить все ссылки на статический контент. Мы решили упростить этот процесс.

Возможности глобальной CDN без погружения в код сайта
С нашей CDN работают многие: Lamoda, Утконос, Wargaming и десятки других крупных компаний. Как правило, у бизнеса проблем с интеграцией не возникает — подключением сети доставки контента там занимаются специализированные отделы. Совсем иначе обстоят дела у владельцев частных веб-ресурсов, особенно если они не разбираются в коде. Они нередко управляют высокопосещаемыми сайтами с пользователями из разных стран, и CDN бы им пришлась как нельзя кстати, но при подключении возникают проблемы.

Первым делом для таких пользователей мы разработали плагины для популярных CMS: WordPress и Битрикс. С их помощью подключить CDN к ресурсу можно без ручного изменения ссылок на контент в коде сайта. Это избавило от сложностей весомую долю веб-мастеров, но этим всё не ограничилось. Как минимум, потому что в нашу экосистему сервисов входит ещё и один из самых быстрых DNS-хостингов в мире, с помощью которого на поиск IP для запрошенного домена уходит менее 20 мс. Мы решили интегрировать его с CDN таким образом, чтобы наши NS-серверы могли использоваться для направления трафика клиента через сеть доставки контента. Результатом стали сразу несколько новых преимуществ для клиентов.

Используем DNS-хостинг для быстрого подключения CDN
В первую очередь новое решение упростило настройку CDN. Теперь владельцам сайтов не нужно вручную изменять ссылки на кешируемый контент или искать необходимый плагин для CMS при настройке CDN для своих сайтов. Весь процесс подключения веб-ресурса к сети выполняется в несколько простых шагов.


Пользователю достаточно кликнуть по кнопке создания ресурса и в визарде выполнить несколько простых действий:

• Выбрать «ускорение и защиту всего сайта». Тогда ресурс будет интегрирован с нашим DNS-хостингом — для этого пользователю нужно только поменять настройки NS-серверов у своего доменного регистратора.
• Ввести домен сайта.
• Подтвердить DNS-записи своего домена, предложенные визардом (может потребоваться указать A-запись).

Всё остальное система сделает автоматически. Сначала она создаст CDN-ресурс, где в качестве персонального домена используется указанный домен, а в качестве origin — IP-адрес, подтверждённый или указанный пользователем в A-записи.

Затем создаст DNS-зону, через которую будет работать созданный CDN-ресурс, и добавит в неё подтверждённые или указанные пользователем DNS-записи. Для созданной A-записи система выполнит интеграцию CDN и в качестве домена укажет cl-hash зону клиента.

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

• Кешироваться и доставляться быстрее будут все компоненты сайта: не только статический, но и динамический контент.
• Статический и динамический контент сайта будет защищен от DDoS-атак благодаря нашей сети кэширующих серверов (на уровне L3, L4)

Помимо того, благодаря возможностям нашей сети посетители ресурса будут получать к нему доступ по протоколу HTTP/2 и защищенному SSL-соединению. Причём, это будет возможно даже если веб-сервер не будет иметь установленного SSL-сертификата и поддерживать HTTP/2.


Так интеграция с DNS-хостингом позволила нам не только предложить владельцам веб-ресурсов самый простой способ подключения CDN к сайтам, но и дать им дополнительные преимущества от её использования. Чтобы не верить нам на слово, все преимущества нашей CDN вы можете опробовать самостоятельно. Тем более, что это можно сделать бесплатно gcorelabs.com/ru/cdn/

Помимо сети доставки контента, мы предлагаем пользователям и другие решения, в числе которых хранилище, защита от DDoS и облако с виртуальными машинами и серверами bare metal. В их развитии нам помогают технологии Intel: в 2021 году мы одними из первых в мире начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих облачных сервисов. Ознакомиться с полный списком наших решений можно gcorelabs.com/ru/cloud/

Качественный BGP-пиринг — одна из главных причин хорошей связности глобальной сети G-Core Labs, охватывающей пять континентов. Мы присутствуем уже на 102 точках обмена трафиком, работаем с 5000 партнёрами по пирингу и входим в топ-10 сетей мира по количеству прямых пирингов. О том, как нам это удаётся — под катом.



Что такое BGP-пиринг
BGP-пиринг — это обмен интернет-трафиком между автономными системами (AS) напрямую, в обход вышестоящих операторов связи (аплинков).

Он помогает участникам точки обмена трафиком (IX, Internet Exchange) сокращать маршруты передачи данных между сетями, снижать затраты на трафик, а также в большинстве случаев и время отклика (RTT). Через точку обмена трафиком проще соединиться сразу c несколькими участниками: вместо отдельного коннекта к каждому достаточно одного соединения с IX, где все эти участники присутствуют.

Каждый участник IX выигрывает за счёт экономии на каналах и закупке трафика у аплинков. Это выгодно и для конечного пользователя: сокращаются сетевые задержки и время отклика до ресурсов.

Таким образом, чем больше точек обмена трафиком, тем лучше связность интернета и тем он доступнее.

Первые точки обмена трафиком начали появляться с 1994 года в крупных европейских городах: Лондоне (LINX), Франкфурте (DE-CIX), Амстердаме (AMS-IX), Москве (MSK-IX). Сейчас во всём мире работает более 500 IX



Как мы выбираем дата-центры и точки обмена трафиком
Мы подбираем дата-центры по количеству операторов первого (Tier1) и второго (Tier2) уровней и локальных IX.

• Публичный пиринг. Выбираем ведущих интернет-провайдеров в каждом регионе и стыкуемся с ними в крупнейших точках обмена трафиком.
• Приватный пиринг. У нас более 5000 партнёров по пирингу по всему миру. Это позволяет сохранять локальность трафика в разных регионах, сокращая задержки доставки контента между сетями.

Почему пиринг требует нестандартных решений
BGP-пиринг — это не просто наше присутствие на отдельно взятой точке обмена трафика. Здесь требуются комплексный подход и слаженная работа всех команд.

Быть участником IX недостаточно, так как многие eyeball-операторы связи имеют закрытую пиринговую политику (например, Selective или Restrictive). Это означает, что оператор не отдаёт свои сети на Route Server (сетевой сервис, позволяющий упростить пиринговое взаимодействие между участниками IX и сократить количество индивидуальных администрируемых пиринговых сессий).

Поднятие пирингов с такими операторами — это результат долгих переговоров между пиринг-менеджерами, в результате которых появляется сам BGP-пиринг и обмен трафиком происходит напрямую.

Немалую роль здесь играет и автоматизация самого процесса по конфигурации. Когда количество точек обмена трафиком переваливает за 15, а общее количество пиров за 1000, управлять этим вручную силами инженеров становится невозможно. Поэтому мы разработали полностью автоматизированный цикл настройки и управления BGP-сессиями без участия человека. Сетевому инженеру остаётся лишь согласовать пиринг, остальное делает автоматика.

Почему мы не стали использовать готовые решения по автоматизации пиринга
Подходы к автоматизации пиринга от большой четвёрки глобальных операторов (Google, Microsoft, AWS, Cloudflare) нам не подошли.

Google и Microsoft используют Web Peering Portal, к которому непросто получить доступ. К тому же в случае Microsoft надо оформить минимальную подписку на Azure.

После получения доступа вам нужно заполнить информацию о себе (как об операторе), пройти верификацию и только потом получить возможность создавать запросы на пиринг. Для каждого запроса обычно создаётся отдельная задача, где также требуется заполнить информацию и внести (выбрать) параметры для BGP-сессии.

Как правило, на создание одного запроса может уходить до 10 минут. Теперь представим, что нам нужно сделать 200 таких запросов, чтобы поднять все нужные нам сессии по всему миру. И это только для одного оператора. Можно легко посчитать, сколько времени нужно затратить на такую задачу. И это без учёта времени ответа на письма, в которых могут быть дополнительные вопросы. Куда проще послать одно письмо из нескольких слов и в течение суток получить ответ уже с преднастроенной конфигурацией.

С какими проблемами пришлось столкнуться:

• Человеческий фактор. Управлять конфигурацией в ручном режиме не представлялось возможным — одной из главных проблем стал бы человеческий фактор. Поскольку как бы ни был хорош сетевой инженер, в таких глобальных масштабах и он может допускать ошибки, которые могут приводить к простою сервиса.
• Автоматизация. Мы разработали собственную систему автоматизации с нуля и постоянно её дорабатываем. Ведь важно не только настроить BGP-сессию, но и поддерживать дальнейшее оперирование. Например, по статистике ежедневно мы поднимаем более 40 сессий, а удаляем примерно 20. Если смотреть за месяц, то это примерно 1200 новых сессий и 600–800 удалённых.

Как автоматизирован наш пиринг сегодня
Достаточно послать запрос на noc@gcore.lu с темой Peering и номером ASN, отличным от нашей (199524).

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

Мы предпочитаем настраивать пиринг на всех точках обмена трафиком, где у нас есть совпадения с оператором, который запросил пиринг. Такой подход экономит время и для нашего пиринг-партнёра, позволяя добиваться максимальной эффективности. По мере роста сети этот подход оказался самым удобным и для нас, и для партнёров.

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

Как мы оцениваем целесообразность пиринга:

• В первую очередь оценивается количество indirect-трафика (то есть трафика через наши upstream-каналы) за последние 30 дней.
• Если значение выше порогового, то в оценку идут другие параметры, например, есть ли сети данного оператора на Route Server в полном составе.
• Затем идёт выбор точек обмена трафика наиболее эффективных для нас.

Какие данные мы анализируем
Мы анализируем данные, которые собираются с наших пограничных маршрутизаторов посредством NetFlow/JFlow. Имея эти данные, мы знаем о своём трафике всё до последнего байта.

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

Основные метрики, которые мы берём в расчёт со стороны сети, — это Packet Loss и Round-Trip Time до конечного пользователя.

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


Как мы планируем улучшать связность сети
Сейчас в приоритете страны Латинской Америки, Африки и Азии. Это потенциально очень большой и перспективный рынок, над которым мы работаем и будем продолжать работать.

Приглашаем к бесплатному пирингу
G-Core Labs — быстро развивающийся контент-оператор с собственной экосистемой облачных сервисов и глобальной инфраструктурой. В её развитии нам помогают технологии Intel: в апреле 2021 мы одними из первых начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих облачных сервисов.

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

Преимущественно мы заинтересованы в пиринге с крупными операторами широкополосного доступа, а также с мобильными операторами. Для получения более детальной информации посетите нашу страницу на PeeringDB или напишите нам по адресу noc@gcore.lu. Подробней о пиринге можно узнать на этой странице. gcorelabs.com/ru/internet-peering/

Вы и без нас знаете, что у WordPress есть проблемы. Да, при создании сайтов им пользуются в 40% случаев — на то он и простой, как трёхколёсный велосипед. Но проблема в том, что при желании из этого велосипеда легко можно собрать хоть Франкенштейна социальную сеть с экосистемой встроенных сервисов — достаточно установить десяток-другой, а то и всю сотню плагинов на сайт. В результате возникают проблемы с безопасностью, совместимостью и скоростью загрузки сайта. Хорошая новость в том, что есть как минимум пять способов заставить WordPress работать лучше — подробней о них в нашей подборке плагинов. О большинстве из них вы уже наверняка слышали, но в списке есть и одна новинка — вместе с другими решениями она позволит вашим пользователям забыть об ожидании загрузки контента на сайте.


Шаг 1: устанавливаем дополнительные меры защиты
Зачем вам спорткар, если у него не закрываются двери? Так же всё обстоит и с WordPress-сайтами, на которые по разным оценкам приходится около 80% всех атак на CMS: как бы привлекательна ни была высокая скорость работы, сначала нужно позаботиться о безопасности. Мы не будем останавливаться на очевидных советах вроде важности регулярного обновления системы и плагинов до актуальных версий — об этом вы наверняка знаете и без нас, — но расскажем об одном из лучших способов обеспечить сайт на WordPress дополнительными мерами защиты. Плагин iThemes Security, ранее известный как Better WP Security, — это комплексное решение, которое разом справляется с рядом задач:

• Распознаёт уязвимости других плагинов и определяет устаревшие версии ПО;
• Обнаруживает и сообщает администратору об изменениях в файлах;
• Сравнивает файлы ядра с текущей версией WordPress;
• Предупреждает об использовании старых паролей;
• Определяет и блокирует вредоносных пользователей;
• Обеспечивает резервное копирование баз данных;
• Позволяет настроить двухфакторную аутентификацию.

Всего в плагине предусмотрено более 30 мер защиты. Недостаток лишь в том, что многие из них доступны в платной версии плагина iThemes Security Pro. Последняя обойдётся в $48 за годовую лицензию на один сайт, $77 — за 10 сайтов или $120 — за любое количество.

Шаг 2: настраиваем кеширование
Долгосрочное хранение постраничного или транзитного кеша в WordPress по умолчанию не предусмотрено. А жаль: кеширование в разы ускоряет передачу пользователям запрашиваемых данных. Очевидно, это хорошо сказывается и на отношении к сайту поисковиков, и на поведенческих факторах. Помимо того, оно снижает нагрузку на сервер, так как ему не приходится больше раз за разом выполнять одни и те же операции. Простой способ добавить эту технологию на WordPress-сайт — установить плагин WP Super Cache. Он заменяет динамический HTML сайта статической версией и затем выдаёт её пользователям, что и сокращает время загрузки контента. В плагине предусмотрено всё нужное для повышения скорости работы сайта, в том числе разные механизмы обработки данных на выбор пользователя — так, например, Apache mod_rewrite обходит стороной все медленные и требовательные к ресурсам PHP-скрипты.

Помимо того, что плагин совершенно бесплатный, у него есть и другое важное преимущество — наличие поддержки CDN на выбор пользователя благодаря интеграции с OSSDL CDN off-linker. Для этого достаточно изменить URL-адреса файлов (кроме .php) в папках wp-content и wp-includes на сервере таким образом, чтобы они указывали на другое имя хоста.

Шаг 3: подключаем CDN
Если WP Super Cache позволяет кешировать файлы WordPress-сайта, то сеть доставки контента ускоряет их передачу до пользователей. Это происходит благодаря тому, что с помощью CDN статические данные передаются не с основного сервера, а с кеш-серверов, распределённых по миру. Таким образом, нужные файлы пользователи получают с ближайших к ним точек присутствия сети CDN-провайдера, что ускоряет загрузку сайта, уменьшает нагрузку на сервер и сокращает количество расходуемого трафика.

Подключить CDN можно как с помощью OSSDL CDN off-linker, встроенного в WP Super Cache, так и другим простым способом — установив плагин G-Core Labs CDN. Детальная настройка работы сети доставки контента с его помощью займёт 15 минут. Для этого после установки достаточно указать персональный домен из личного кабинета G-Core Labs в настройках плагина, а затем выбрать типы файлов и папок, которые вы хотите раздавать через сеть доставки контента. Расширение автоматически настроит замену существующих статических ссылок на CDN и эффективно ускорит доставку контента: для этого в сети используются решения на основе процессоров Intel Xeon Scalable второго и третьего поколения, а точки её присутствия расположены более чем в 100 городах по всему миру, что обеспечивает время загрузки сайта в пределах 20–30 миллисекунд.

Шаг 4: отключаем лишние опции WordPress
После того, как кеширование всего, что можно кешировать, настроено, а всё, что можно доставлять через CDN, через неё и доставляется, хорошо бы избавиться от всего лишнего. Для решения этой задачи предназначен плагин Perfmatters, который позволяет оптимизировать работу WordPress без изменения кода и файла functions.php.

В настройках плагина предусмотрен длинный перечень возможностей CMS, которые можно включать и отключать одним кликом. Скажем, если вы не добавляете на страницы сайта emojis, то к чему вам их поддержка — отключите её, чтобы сократить общее количество HTTP-запросов и размер страницы. А если вам не нужны редакции страниц трёхлетней давности, то и хранить их нет смысла — сократите их число до нужного количества с помощью Perfmatters. Подобных настроек в плагине предусмотрены десятки: от изменения интервалов автосохранений до отключения комментариев и поддержки Google Maps на страницах, где их нет.

Шаг 5: настраиваем резервное копирование
Что бы ни произошло с сайтом, если у вас есть бэкап — всё поправимо. Желательно только, чтобы бэкап был не годичной давности. Как раз таки для избежания таких проблем и предусмотрены плагины для настройки резервного копирования. Понятно, что справиться с этой задачей можно и вручную или средствами хостинг-провайдера. Однако, плагины — простое решение, которое позволяет автоматизировать весь процесс копирования за несколько минут. Одним из лучших среди них считается UpdraftPlus, это расширение установлено на трёх с лишним миллионах сайтов, а среди его пользователей такие компании и организации, как Cisco, Microsoft и NASA.

Бесплатная версия плагина позволяет сохранять полные копии ресурса и затем выгружать их на локальный диск или в удобное облачное хранилище — для этого в нём предусмотрена поддержка Dropbox, Google Drive и других сервисов. Также резервные копии можно отправлять по FTP и SFTP, а настройка расписания позволяет автоматизировать не только процесс резервного копирования, но и сохранение копий в удобное хранилище. Платная версия плагина — UpdraftPremium — обойдётся в $70 за лицензию на два сайта, но разработчики предлагают и другие планы с «оптовыми» ценами.

Хоть мы тогда и сами об этом не знали, но создавать сервис для аренды выделенных серверов мы начали два года назад. При запуске новых регионов публичного облака нам требовалось оперативно развернуть множество серверов разных конфигураций по всему миру, но целыми днями заниматься этим вручную никто не хотел. Вместо людей со стальными нервами мы нашли более изящное решение в лице Ironic — сервиса OpenStack для провижининга «голого железа». Совместно с другими инструментами он позволял и раскатывать образ, и настраивать систему, и на тот момент этого уже было достаточно. Позже в Ironic появились такие возможности, что это решение начало закрывать вообще все наши задачи по управлению инфраструктурой в облаке. А раз уж мы справились с этим, то почему бы не сделать на основе служебного инструмента публичный сервис с автоматической подготовкой выделенных серверов?

Шёл 2014 год…
Серверы мы деплоили на коленке через PXE boot и kickstart. Это решение хоть и работало, но имело недостатки:

• Сети переключались вручную;
• Выбор сервера и его перевод в загрузку по PXE выполнялся вручную;
• Сборка рейда и обновление прошивок — тоже manual mode.

Сначала для решения проблемы мы хотели просто написать свой bash-скрипт, который и будет всё делать. К счастью, руки до этого так и не дошли, и мы рассмотрели все существующие на тот момент варианты:

• MaaS — предлагался как коробочное решение от одной очень солидной компании за не менее солидную сумму;
• Cobbler — тут нам сказать особо нечего, так как в команде не нашлось инженеров с необходимым знанием технологии;
• Foreman — казался неплохим решением, тем более что мы использовали Puppet;
• OpenStack Ironic — хоть инженеров с опытом по этому продукту в команде тогда и не нашлось, но у нас уже был опыт работы с Openstack по виртуализации. Так что ставка была сделана на то, что в будущем мы сможем красиво всё собрать в один OpenStack. Понятное дело, в этом мы глубоко заблуждались, но об этом позже.

В итоге автоматизировать деплой серверов мы решили с помощью Ironic, а эти работы в дальнейшем положили начало куда более масштабному проекту. Рассказываем, как так вышло.

Шаг 1: автоматизируем управление внутренней инфраструктурой облака
Наши решения работают на основе разных технологий Intel: облачные сервисы — на процессорах Intel Xeon Gold 6152, 6252 и 5220, кеш-серверы CDN — на Intel Xeon Platinum, а в апреле 2021 мы также одними из первых в мире начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих облачных сервисов. Чтобы вручную управлять всем этим пулом железа для сервисных целей облака, ежедневно разворачивать по всему миру серверы с разными конфигурациями и всё это ещё и как-то поддерживать, нам требовался либо целый штат специалистов, либо инструменты автоматизации, которые бы обеспечили высокий темп экспансии в регионы и облегчили жизнь нашим админам. Как уже говорилось, для этих целей мы решили использовать Ironic. На момент внедрения — два года назад — это был уже достаточно зрелый сервис со следующими возможностями:

• Удалённое управление серверами;
• Сбор информации о конфигурациях и коммутации ещё не запущенных серверов;
• Установка ОС на произвольном сервере;
• Настройка сети с использованием протоколов 802.1q и 802.3ad.

Нас такое решение вполне устраивало, поэтому на нём мы и остановились, а для настройки операционной системы на сервере решили использовать cloud-init. Рабочий процесс был простым и прозрачным:

• Сначала формировался загрузочный ISO-диск с информацией о настройках сервера, пакетах и сетевых интерфейсах.
• На физическом сервере запускался процесс исследования с помощью компонента Ironic Inspect.
• Затем этот сервер Ironic загружал с конфигурационным образом.
• Начинался процесс автоматической установки CentOS, настраивались сетевые интерфейсы, ставились пакеты.

Подробней весь жизненный цикл можно увидеть на следующей схеме:


Так всё и продолжалось, пока Ironic становился более зрелым продуктом. Со скрипом, но всё же в нём появились новые возможности, в том числе и всё необходимое для автоматизированного управления RAID-контроллерами, обновления прошивок и развёртывания образов системы с произвольных HTTP-ресурсов через интернет. Так что со временем у нас появилось полноценное решение для автоматизации вообще всех задач по управлению инфраструктурой в облаке — им стала связка Ironic с cloud-init и используемой нами CI/CD. Чем не задел на что-то большее?

Шаг 2: планируем создание новой услуги из андерклауда
Сначала мы использовали инструмент только для служебных целей. Он хорошо справлялся с автоматизацией задач по управлению инфраструктурой облака, но этим наши планы не ограничивались: нам также требовалось подготовить решение для провижининга арендуемых заказчиками выделенных серверов. Оно бы пришлось как нельзя кстати, так как упрощало аренду серверов bare metal для потенциальных клиентов, а сомнений в их наличии у нас не было. На тот момент пользователи и без того часто заказывали у нас выделенные серверы — обычно они разворачивали на них продакшн-среды для высоконагруженных приложений, так как «голое железо» оказывалось производительней и безопасней виртуальных машин, к тому же на нём не было «шумных соседей». Вот только времени на подготовку каждого физического сервера у нас уходило в разы больше, ведь для этого всё требовалось делать вручную:

• Сначала выбирать из пула доступных наиболее подходящий сервер;
• Затем применять определённую конфигурацию для оборудования (настроить сетевые интерфейсы, RAID-контроллеры);
• Постоянно поддерживать в актуальной версии системное ПО (firmware или версию BIOS);
• Загружать и устанавливать операционную систему, выполнять пост-инстал скрипты.

Автоматический провижининг избавил бы нас от лишних сложностей. К тому же его потенциал не ограничивался упрощением подготовки серверов: он вполне мог лечь в основу полноценного облачного сервиса, с помощью которого пользователи будут за несколько минут разворачивать узлы bare metal, а арендовать выделенный сервер будет не сложней виртуального. Так из внутреннего компонента мы решили развивать новую услугу для пользователей облака — Bare-Metal-as-a-Service.

Шаг 3: автоматизируем провижининг выделенных серверов в публичном облаке
С помощью автоматизации мы планировали решить несколько задач: ускорить подготовку выделенных серверов, сделать возможной одновременную работу сразу с несколькими из них, сократить простой между операциями и исключить человеческий фактор. Добиться этого нам удалось с помощью общедоступных инструментов и пары собственных доработок. Объяснить, как всё работает, проще всего на конкретном примере — теперь для того, чтобы сервер стал доступен для заказа клиентом, мы выполняем следующие действия:

• Заносим сервер в CMDB (сейчас для этого у нас уже есть NetBox).
• Через Redfish выполняем преднастройку BIOS — активируем загрузку по PXE и настраиваем её режимы, — а также создаём пользователей для удалённого управления.
• Проверяем работоспособность сервера и передаём управление Ironic.
• Инженер добавляет сервер в нужную плайсмент-группу.
• Убеждаемся, что данные в CMDB и Ironic совпадают — в противном случае на этом этапе требуется ручное вмешательство оператора.
• После успешной проверки данных Ironic выполняет настройку RAID и BIOS, а также первоначальную очистку сервера с помощью ATA Secure Erase или shred в зависимости от того, что поддерживает RAID-контроллер.

Вот и всё, сервер попадает в пул доступных для заказа. Решение обеспечивает все наши текущие потребности и реализовано на общедоступных инструментах, так что нам не нужно ежемесячно платить за сторонний продукт и мы ни с кем не связаны лицензионными обязательствами. С поставленными задачами оно справляется на все сто — пользователи с помощью этого решения создают узлы bare metal почти так же быстро, как и виртуальные машины.

Шаг 4: добавляем новую услугу в облачную экосистему
Сейчас пользователи часто используют услугу Bare-Metal-as-a-Service в сочетании с другими нашими сервисами. Это позволяет им быстро получить готовую и гибкую инфраструктуру с простым управлением выделенными серверами и виртуальными машинами, приватными и публичными сетями, а также другими облачными решениями. Заказчикам такой подход помогает эффективно и экономично использовать ресурсы, а мы в результате успешно развиваем собственную экосистему сервисов, так как клиенты пользуются сразу комплексом наших решений. Помимо прочего, это открывает для заказчиков новые сценарии использования публичного облака — например, можно держать продакшн-среды на выделенных серверах, а при всплесках нагрузки за минуту разворачивать дополнительные мощности на виртуальных машинах, которые затем можно легко удалить. Чтобы новая услуга стала такой важной частью нашей экосистемы сервисов, после работ над автоматическим провижинингом нам предстояло решить ещё много задач.

Для начала, чтобы пользоваться новым сервисом было просто, заказ выделенных серверов мы сделали схожим с деплоем виртуальных машин — теперь для этого достаточно выбрать нужные характеристики, подключить публичную, приватную или сразу несколько сетей и через несколько минут получить готовый к работе сервер. Это решение уже прошло испытание боем: когда одному нашему клиенту не хватало виртуальных машин, он в тот же день оформил заказ и без проблем переехал на bare metal. С некоторыми другими задачами всё оказалось не так просто — остановимся на паре из них.

Избавляемся от «шумных соседей»
Главное отличие публичного сервиса от внутреннего компонента — наличие уникальных пользователей. Несмотря на то что все серверы живут в одном пуле, заказчикам как-то нужно обеспечить их изолированность друг от друга. Мы добились этого с помощью механизма мультитенантности. Готовые SDN-решения для этого не подходили, так как из-за них нам потребовалось бы ответвляться от существующей инфраструктуры. Нам также нужно было предусмотреть мультиплатформенность, поскольку наши облака распределены по всему миру и сетевое оборудование может варьироваться от региона к региону. В поисках подходящих решений нам пришлось досконально изучить вопрос, оптимальным вариантом оказался Networking-Ansible ML2 Driver. Правда, без ложки дёгтя в нём не обошлось — драйвер не умел объединять порты в MLAG, чего нам очень хотелось. Тогда мы сами научили его нужным образом агрегировать каналы на наших коммутаторах, но тут же столкнулись с другой проблемой при настройке интерфейсов внутри самого физического сервера.

Мы ожидали от cloud-init, что при выборе пользователем нескольких сетей они будут настроены с помощью сабинтерфейсов, но этого почему-то не происходило. Как оказалось, проблема была в том, что cloud-init недополучает из config-drive информацию о VLAN-ах, если порт настраивается транком. К счастью, на просторах opendev мы нашли патч, который мог бы исправить эту проблему. Сложность была в том, что он ещё находился в разработке, так что тут нам опять пришлось поработать напильником, чтобы самим довести патч до ума.

Теперь всё работает следующим образом:

• Сетевые интерфейсы по умолчанию автоматически агрегируются и в транк перебрасываются как публичные, так и приватные сети. Пользователи же могут сконфигурировать свой ландшафт любым удобным образом, объединяя публичные и приватные сети в своём проекте — это позволяет им максимально эффективно использовать ресурсы;
• По умолчанию все порты сервера находятся в несуществующей сети, но мы уже знаем в какой коммутатор воткнут каждый из них. Когда пользователь заказывает сервер, портам открывается доступ к PXE-серверам, запускается загрузчик, заливается образ, а дальше порты конфигурируются в целевую схему и сервер отдаётся клиенту.

Получается следующая схема потоков трафика:


Ну и заодно мы не забываем про VXLAN для bare metal и сейчас ведём разработку решения, позволяющего работать с сетью, используя эту технологию.

Пишем драйвер консоли для iDRAC
Без serial console траблшутинг bare metal был бы неполным, так как для пользователя она остаётся единственным способом подключения к серверу, если привычные варианты — SSH и RDP — вдруг оказываются недоступны. Проблема возникла при имплементации сервиса, когда стало понятно, что в Ironic отсутствует поддержка виртуальной консоли iDRAC. Чтобы всё же получить к ней доступ, нам пришлось самим написать драйвер. Для этого мы изучили имеющиеся драйверы в Ironic для работы с консолями iLo и IPMI, а затем написали собственное решение по схожему принципу. Получившийся драйвер отлично справляется со своими задачами, но только в тех случаях, когда образ пользователя умеет отдавать диагностику в COM-порт — к счастью, в современных версиях Linux и Windows проблем с этим не возникает даже из коробки. Вот только с виртуальной консолью проблемы на этом не кончились.

Следующая сложность возникла с проксированием портов самой консоли. За их работу отвечает компонент Nova — nova-serialproxy — принцип работы которого слегка отличается, но в целом схож с компонентом nova-novncproxy. Проблема обнаружилась на одном из этапов работы serial console, который организован следующим образом:

• Пользователь запрашивает serial console в личном кабинете — создаётся запрос посредством REST API.
• Компонент nova-api обращается к nova-compute для получения URL с валидным токеном и открытием веб-сокета на подключение.
• API нашего личного кабинета получает этот URL и делает по нему обращение уже непосредственно в nova-serialproxy.
• Затем происходит проксирование запроса nova-serialproxy к ironic-conductor на порт физического сервера для подключения к его виртуальной консоли.

Вот наглядное описание этой цепочки действий:


Проблема возникала на четвёртом этапе — иногда в этот момент пользователи в течение непродолжительного времени получали ошибку «Address already in use». Мы не сразу поняли, с чем связано такое поведение, так как обнаружить порт консоли занятым каким-то другим процессом в списке прослушиваемых портов нам никак не удавалось. Первым делом мы решили изучить socat, с помощью которого осуществлялось взаимодействие с виртуальной консолью от контроллера. Однако, найти корень проблемы так и не получалось, в том числе из-за того, что на момент обращения пользователей в службу поддержки ошибки уже не возникало. Но однажды нам повезло: в тот раз проблема никак не решилась сама собой и ещё была актуальна, когда клиент о ней сообщил.

Тогда нам удалось обнаружить, что HAproxy на контроллерах проксирует соединение к БД, где ему для инициализации подключения назначался порт консоли. Решение оказалось довольно простым: мы стали резервировать порты с помощью параметра ядра net.ipv4.ip_local_reserved_ports и выбрали диапазон в плоскости 48 тысяч, где конечный порт для консоли в момент подготовки сервера для аренды автоматически указывался в соответствии с последним октетом iDRAC-адреса.

Шаг 5: запускаем bare metal во всех регионах публичного облака
В результате этих работ из служебного компонента нам удалось сделать полноценный сервис в составе публичного облака. Останавливаться на этом мы не планируем и первым делом расширяем географию присутствия облака: теперь, помимо виртуальных машин, во всех новых регионах мы сразу будем предоставлять и выделенные серверы. Развиваться будет и сам сервис: в ближайшие полтора года мы планируем создать решения на базе серверов bare metal для работы с большими данными и CaaS-сервисами, в том числе с Managed Kubernetes, а также внедрить возможность разворачивать приложения из нашего маркетплейса на выделенных серверах. Подробней обо всём этом мы ещё расскажем отдельно — stay tuned.
gcorelabs.com/ru/cloud/marketplace/

Вебинар будет полезен

• разработчикам игр и SaaS‑приложений
• техническим директорам и специалистам E‑commerce
• финтеха
• ритейла
• онлайн-медиа
• индустрии развлечений и других сфер

www.webinar.gcorelabs.com/#registration

Разработкой платформы мы занялись… случайно. Всё началось с пандемии, из-за которой правительство Люксембурга и распорядилось создать сервис онлайн-консультаций с врачами. Чтобы выжать из платформы максимум пользы, в неё решили добавить всё, что только нужно для полноценной работы врачей с пациентами. Обмен всевозможными медицинскими документами и даже выдача рецептов на лекарства исключениями не стали — старый вендор всё и сразу заложил в сервис. А затем, чтобы всё добро было в сохранности, к нам и обратились с уже готовым продуктом — нам всего-то и требовалось, что развернуть платформу в защищённой точке присутствия облака.

Через полтора месяца сервис успешно работал в люксембургском дата-центре EDH Tier IV, но ещё при первом знакомстве мы признали в нём слабое звено всего проекта: в отличие от точки присутствия, платформа защищённостью похвастаться не могла и обладала десятком других недостатков. Решение было очевидным — сервис нужно было делать с нуля. Оставалась убедить в этом правительство Люксембурга.



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

1. Систему разрабатывали без фреймворка
Из-за этого проблем в платформе было немыслимое количество. Если бы для создания сервиса использовался какой-нибудь популярный фреймворк — Symfony, Laravel, Yii или что-то ещё, — то даже посредственные разработчики избежали бы большинства проблем безопасности, ведь ORM умеют подготавливать запросы к базе, шаблонизаторы — эндкодить полученный от пользователя контент, а формы по умолчанию защищены CSRF-токенами, да и авторизация и аутентификация, как правило, доступны практически из коробки. В этом же случае платформа заставила нашего разработчика ностальгировать по студенческим временам — код выглядел почти так же, как его первая лабораторная работа в университете.

Вот, например, как было реализовано подключение к базе данных. Учётные данные для подключения были захардкожены выше в том же файле.

if (!isset($db)) {
	$db = new mysqli($db_info['host'], $db_info['user'], $db_info['pass'], $db_info['db']);
	if ($db->connect_errno) {
		die("Failed to connect to MySQL: " . $db->connect_errno);
	}
	if (!$db->set_charset("utf8")) {
		die("Error loading character set utf8 for MySQL: " . $db->connect_errno);
	}
	$db->autocommit(false);
}

2. В платформе было множество проблем безопасности
После аудита мы поняли, что с такими недоработками выходить в production нельзя даже с простым блогом, не то что с платформой с конфиденциальными данными. Приведём некоторые из них.

SQL-инъекции. В 90% запросов попадали введенные пользователями данные без их предварительной подготовки.

$sql = "
	UPDATE user
	SET firstname='%s', lastname='%s', born='%s', prefix='%s', phone='%s', country_res='%s', extra=%s
	WHERE id=%d
;";
$result = $db->query(sprintf($sql,
	$_POST['firstname'],
	$_POST['lastname'],
	$_POST['born'],
	$_POST['prefix'],
	$_POST['phone'],
	$_POST['country'],
	isset($_POST['extra']) ? "'".$_POST['extra']."'" : "NULL",
	$_SESSION['user']['id']
));

XSS-уязвимости. Пользовательский код никак не фильтровался перед выводом:

<button id="btn-doc-password" class="btn btn-primary btn-large pull-right" data-action="<?= $_GET['action'] ?>"><i class="fas fa-check"></i> <?= _e("Valider") ?></button>

Кроме того, попавшая в БД информация, вроде причины консультации с врачом, не фильтровалась ни перед записью в базу, ни перед рендерингом на странице.
Отсутствие проверки прав доступа. Достаточно было иметь аккаунт пациента и подобрать автоинкрементный ID другого пациента, чтобы без труда получить список приёмов и другой информации из профиля. Те же проблемы были и на стороне приложения доктора. Более того, зная ID врача не составляло проблем получить доступ к его приёмам.
Отсутствие проверки загружаемых файлов. Через форму добавления документов можно было загрузить какой угодно файл в любую из папок, доступных для записи пользователям веб-сервера. Помимо того, поиграв с quеry-string запроса на загрузку документа можно было даже скачать файлы с исходным кодом.

$file_dir = $settings['documents']['dir'] . $_SESSION['client']['id'] . DIRECTORY_SEPARATOR . $_GET['id_user'];

Устаревшие сторонние библиотеки. У старого вендора никто не следил за версиями сторонних библиотек, которые, кстати, вместо использования того же Composer просто копировались в проект. Более того, в некоторые из таких сторонних зависимостей вносились изменения «под себя».
Небезопасное хранение паролей пользователей. Для хранения паролей использовались ненадёжные криптографические функции.

$sql = "
	SELECT id, firstname, lastname
	FROM user
	WHERE id=%d AND password=PASSWORD('%s')
;";
$result = $db->query(sprintf($sql, $_SESSION['user']['id'], $_POST['pass']));

Уязвимость CSRF. Ни одна форма не была защищена CSRF-токеном.
Отсутствие защиты от brute-force атак. Её просто не было. Никакой.

Тут можно было бы продолжить и дальше, но уже этих проблем достаточно, чтобы понять: либо у системы были серьёзные проблемы, либо она сама была серьёзной проблемой.

3. Код было сложно поддерживать и расширять
Проблемами безопасности всё не ограничилось. К нашему удивлению, на проекте отсутствовала система контроля версий. Код был совершенно не структурирован. В root-директории web-сервера находились файлы вроде ajax-new.php, ajax2.php и все они использовались в коде. Отсутствовало и чёткое разграничение на слои (presentation, application, data). В подавляющем большинстве случаев файл с кодом представлял собой смешение PHP, HTML и JavaScript.

Всё это привело к тому, что когда нас попросили сделать примитивный backoffice для этой системы, лучшим решением стало развернуть рядом Symfony 4 в связке с Sonata Admin и вообще не касаться существующего кода. Понятно, что если бы нас попросили добавить новые возможности для врачей или пациентов, это отняло бы у нас кучу сил и времени. А поскольку об автоматических тестах речи не шло, вероятность сломать при этом что-нибудь была бы крайне велика.

Всего перечисленного правительству Люксембурга оказалось достаточно — нам дали зелёный свет на разработку новой платформы.

Доктор едет-едет: как мы разрабатывали новую платформу

Готовиться к разработке новой платформы мы начали с самого начала — ещё когда увидели детище старого вендора. Поэтому, когда нам дали добро на разработку новой платформу, мы сразу приступили к созданию её MVP-версии. С этой задачей команда из четырёх PHP- и трёх фронтенд-разработчиков справилась за какие-то три с половиной недели. Все работы велись на Symfony 5, а делегировать удалось только видеозвонки и чаты — их реализовали с помощью нашего сервиса G-Core Meet. Пригодился и backoffice для старой системы: его удалось адаптировать к МVP всего за пару дней. В результате MVP-версия системы на 80% закрывала функционал старой платформы. Сейчас она, кстати, используется и для ещё одной задачи — в один момент мы клонировали MVP для хелпдеска агентства электронного здравоохранения Люксембурга, чтобы администраторы там могли созваниваться с пользователями.

Когда MVP был готов, мы приступили к разработке полноценной новой платформы. В качестве основы для API использовали API Platform и ReactJS в связке с Next.js для client-side. Без интересных задач не обошлось.

1. Реализуем уведомления
Одна из сложностей возникла с уведомлениями. Поскольку клиентами API могли быть как мобильный приложения, так и наши SPA, требовалось комбинированное решение.
Сначала мы выбрали Mercure Hub, с которым клиенты взаимодействуют через SSE (Server Sent Event). Но как бы это решение не пиарили сами создатели API Platform, наша мобильная команда его забраковала, так как с ним получать уведомления приложение могло только в активном состоянии.

Так мы пришли к Firebase, с помощью которого удалось добиться поддержки нативных пушей на мобильных устройствах, а для браузерных приложений оставили Mercure Hub. Теперь, когда в системе происходило какое-то событие, мы уведомляли пользователя об этом через нужный нам private-канал в Mercure Hub и, помимо этого, отправляли пуш ещё и на Firebase для мобильного устройства.

Почему мы сразу не реализовали всё на Firebase? Тут всё просто: несмотря на поддержку web-клиентов, браузеры без Push API — тот же Safari и большинство мобильных браузеров — с ним не работают. Однако, мы ещё планируем реализовать пуш-уведомления от Firebase для тех пользователей, которые используют поддерживаемые браузеры.

2. Функциональные тесты
Другая интересная ситуация возникла, когда мы занимались функциональными тестами для API. Как известно, каждый из них должен работать в чистом окружении. Но каждый раз поднимать базу и заполнять в ней базовые fixtures + fixtures, необходимые для тестирования, оказалось накладно с точки зрения производительности. Чтобы этого избежать, мы решили на начальном этапе поднимать базу данных на основании маппинга сущностей (bin/console doctrine:schema:create) и уже затем добавлять базовые fixtures (bin/console doctrine:fixtures:load).

Затем с помощью расширения dama/doctrine-test-bundle мы добились того, чтобы выполнение каждого теста оборачивалось в транзакцию и в конце тест-кейса откатывало её без фиксации. Благодаря этому, даже если в ходе тестирования в базу вносятся изменения, они не фиксируются, а база после прогона остаётся в том же состоянии, что и до запуска PHPUnit.
Чтобы на каждый эндпоинт был написан хотя бы один тест, мы сделали auto review тест. Он обнаруживает все зарегистрированные роуты и проверяет наличие тестов для них. Так, например, для роута app_appointment_create он проверяет, есть ли в папке tests/Functional/App/Appointment файл CreateTest.php.

Дополнительно за качеством кода следят PHP-CS-Fixer, php-cpd и PHPStan c расширениями типа phpstan-strict-rules.

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

Такой подход позволяет в одном пул-реквесте создать фичу (библиотеку) и интегрировать её во все нужные приложения. Это преимущество и привело к использованию монорепозитория вместо реализации фич в отдельных npm-библиотеках и проектов в разных репозиториях.
Для конфигурации монорепозитория используется библиотека ns.js, которая с коробки позволяет собирать библиотеки и приложения React и Next.js, а именно этот стек и используется в проекте. Чтобы следить за качеством кода, мы используем ESLint и Prettier, для написания unit-тестов — Jest, а для тестирования компонентов React — React Testing Library.

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

Вот уже как 4 месяца сервис позволяет пациентам получать онлайн-консультации докторов и стоматологов. Они могут проходить как в аудио, так и видеоформате. В результате врачи выписывают рецепты и безопасно обмениваются медицинскими документами и результатами анализов с пациентами.

Платформа доступна для всех медицинских профессионалов, жителей и работников Люксембурга. Сейчас она работает в 2-х крупнейших учреждениях здравоохранения страны — в Больнице им. Роберта Шумана (Hôpitaux Robert Schuman) и Больничном центре им. Эмиля Мэйриша (Centre Hospitalier Emile Mayrisch). Сервис развёрнут в защищённой точке присутствия облака G-Core Labs в люксембургском дата-центре EDH Tier IV, где для него настроена виртуальная среда в соответствии с нужными спецификациями.

https://gcorelabs.com

Вебинар будет полезен разработчикам игр и приложений, техническим руководителям, финансовым директорам и специалистам из финтеха, ретейла, СМИ, финансового сектора и других сфер.




www.webinar.gcorelabs.com

Как интегрировать видеозвонки в платформу для офлайн- и онлайн-мероприятий: опыт Momento Solutions
gcorelabs.com/ru/cases/momentosolutions

Новый регион G-Core Labs Cloud: Хабаровск
Точки присутствия G‑Core Labs Cloud уже открыты в Люксембурге, Москве, Манассасе и Сингапуре.
Мы запускаем новую edge-локацию нашего облака в Хабаровске.
Новая точка поможет развивать бизнес на Дальнем Востоке России и в азиатском регионе в целом, сократить задержки для конечных пользователей.
Масштабируйте IT-инфраструктуру, ускоряйте процессы разработки, тестирования и вывода новых продуктов на рынок с помощью наших сервисов.


БЛИЖАЙШИЕ ПЛАНЫ
Скоро мы добавим автоматическое развёртывание Kubernetes-кластеров для оркестрации контейнеров.

Следующую edge-локацию мы планируем запустить в Амстердаме.

https://gcorelabs.com