В сети OVHcloud 34 точки присутствия (PoP); расположены в Европе, Северной Америке и Азиатско-Тихоокеанском регионе. Обладая глобальной пропускной способностью около 21 Тбит/с, сеть OVHcloud может обрабатывать гораздо больше трафика, чем другие провайдеры.
В OVHcloud сетевой трафик постоянно растет, чтобы удовлетворить потребности миллионов пользователей Интернета, которые используют 31 центр обработки данных по всему миру.
В течение последних нескольких лет OVHcloud работал над улучшением инфраструктуры нашей всемирной магистральной сети.
Дальнейшее расширение нашей сети
За почти два года исследований и разработок команда разработчиков сети OVHcloud создала совершенно новую инфраструктуру. Каждый центр обработки данных подключен к нескольким PoP (Point of Presence). PoP разделяют трафик с различными другими центрами обработки данных OVHcloud, а также обмениваются трафиком с разными поставщиками (известными как Peers).
Текущая архитектура, известная внутри как «липкий маршрутизатор», основана на маршрутизаторе для маршрутизации и коммутаторе, который играет роль платы питания. В течение нескольких лет он работал достаточно хорошо (и при невысокой стоимости), но в конечном итоге метод достиг своего предела с точки зрения пропускной способности. Нам нужно было найти и разработать другую систему, которая могла бы справиться с растущим трафиком. Наши требования были простыми; нам нужна была недорогая, энергоэффективная и масштабируемая инфраструктура.
Обеспечение максимально возможной связи для наших клиентов по всему миру было движущей силой компании с момента ее создания Октавом Клаба. Для этого мы хотели быть максимально подключенными к местным провайдерам, для чего требовалось несколько портов со скоростью 10 или 100 Гбит/с.
Переосмысливая топологии PoP, мы рассмотрели новые масштабируемые технологии, в том числе:
- Пропускная способность порта: должна быть основана на портах 100 Гбит / с и 400 Гбит / с и иметь хорошую экономическую эффективность. Это поможет устранить любые узкие места в сети. Также необходимо было поддерживать каналы 10 Гбит / с для тех провайдеров, которые не были готовы к портам 100 Гбит / с.
- Легко обновлять: новую архитектуру нужно было легко модернизировать с точки зрения емкости. Частично это сделано для роста компании, но также для поддержания доступности, когда на PoP требуется обслуживание сети.
- Мощность: команде нужно было найти лучшее оборудование для максимального повышения эффективности энергопотребления; особенно в таких странах, как Сингапур, где это дорого.
- Безопасность: ключевым требованием будет работа с нашими группами безопасности, чтобы найти лучшее решение для защиты сети от угроз (массовых DDoS-атак).
После почти года исследований и испытаний команда дизайнеров разработала совершенно новую архитектуру; который был масштабируемым, энергоэффективным, простым в установке и надежным. Новая архитектура получила название SMAUG, в честь дракона из «Хоббита».
Обзор SMAUG
Чтобы быть адаптируемой, архитектура имеет несколько вариантов емкости в зависимости от того, насколько велик PoP. Это связано с тем, что в разных центрах обработки данных происходит обмен разным объемом трафика. Каждый вариант мощности имеет свою специфику, чтобы не было узких мест.
Инфраструктура Spine and Leaf
SMAUG — это инфраструктура «Spine and Leaf». Это означает, что «позвоночник» (называемый SBB от SuperBackBone) объединяет листья и соединяет каждый центр обработки данных. «Листовые» устройства (называемые PB для PeeringBox) используются для подключения провайдеров, а также внутренних служб, таких как оборудование xDSL или OVHcloud Connect.
Инфраструктура SMAUG также предоставляет другой способ подключения центра обработки данных, где есть как минимум два PoP, оба в другом месте. Например, в Сингапуре наш центр обработки данных подключен к двум точкам доступа, расстояние между которыми превышает 30 км — это соответствует правилу не использовать один и тот же источник питания для двух точек доступа.
Чтобы обеспечить избыточность, оба PoP должны быть подключены друг к другу с огромной пропускной способностью — в 100 Гбит / с или 400 Гбит / с, в зависимости от PoP. Группа по передаче электроэнергии также участвовала в разработке новой инфраструктуры под названием «ГАЛАКТИКА». GALAXY была основана на другом конструкторе — в сочетании с простой в развертывании, масштабируемой, операционной моделью с меньшим энергопотреблением.
Роль листа довольно проста и похожа на верх стойки в центре обработки данных. Он имеет огромную пропускную способность восходящего канала к шипам и имеет конфигурацию для подключения одноранговых узлов BGP; такие как транзитные провайдеры, частные межсетевые соединения (PNI) и Интернет-обмен.
Роль позвоночника более сложная и имеет дополнительные функции, в том числе:
- Соединения дальнего следования: он обеспечивает соединение каналов на основе 100 Гбит / с к центрам обработки данных и PoP.
- Маршрутизация: в нем есть вся таблица маршрутизации, чтобы выбрать лучший путь к центрам обработки данных OVHcloud или к внешним сетям.
- Защита: команда VAC участвовала в разработке нового инструмента защиты (для получения дополнительной информации: www.ovh.com/blog/using-fpgas-in-an-agile-development-workflow/) в порядке чтобы помочь защитить всю сеть OVHcloud от DDoS-атак.
- Смягчение: это также помогает системе обнаружения, используемой инфраструктурой VAC www.ovh.co.uk/anti-ddos/
Тестирование и развертывание
После того, как команда разработчиков и руководство убедились, что это лучшая архитектура для сети OVHcloud, мы начали тестирование различных брендов, обеспечивая правильную реализацию всех функций. После того, как все тесты были завершены в лаборатории и мы были уверены в жизнеспособности решения, мы начали развертывание инфраструктуры в Сингапуре. Этот регион был одним из самых важных по росту посещаемости. Это было также проще, потому что у нас уже были темные волокна для связи между центром обработки данных и точками доступа.
В январе мы заказали все устройства и трансиверы, а затем подготовили план миграции, чтобы запланировать все развертывание на конец марта. В конце февраля мы подготовили конфигурацию и протестировали новинки. Когда все было в порядке, мы отправили их всех в точки входа в Сингапур.
Вначале мы планировали провести эту миграцию в середине марта 2020 года и должны были отправить наших технических специалистов из Франции в Сингапур, но из-за COVID-19 нам пришлось изменить наши планы. Нам пришлось найти другое решение и попросить наших местных технических специалистов, работающих в нашем сингапурском центре обработки данных, выполнить эту работу. План миграции был более сложным из-за новой реорганизации, которую необходимо было провести в связи с пандемией.
После долгого обсуждения между руководством, сетевой командой и сингапурскими техниками OVHcloud было решено выполнить миграцию первого PoP в начале апреля, а второго — в конце апреля. Миграция началась с размещения новых устройств в двух новых стойках, подготовки проводки к миграции и выполнения некоторых проверок перед горячими заменами.
Переход на SMAUG
Давление на то, чтобы этот переход был успешным, был высоким, поскольку мы не хотели, чтобы он повлиял на наших клиентов. В первую ночь миграции — когда мы исчерпали трафик от первого PoP — мы попросили технических специалистов переместить все дальнемагистральные каналы в Сингапурский округ Колумбия, а для Австралии, Франции и США — на новые устройства. После некоторых тестов мы запустили новые устройства в производство. Первый шаг миграции прошел хорошо.
Следующий день был не таким уж и гладким, поскольку мы впервые запускали в производство наш новый Peering Box с нашей новой системой защиты границ, основанной на серверах FPGA. После того, как мы удалили трафик от наших пиров, трафик покидал сеть OVHcloud через второй PoP. Затем мы переместили волокна в новый Peering Box с помощью горячей замены от нашего поставщика центра обработки данных. После того, как мы все подключили к новому оборудованию, мы начали медленно возобновлять производство. Нам нужно было сделать это вместе с нашей командой безопасности, чтобы убедиться, что эта новая система защиты границ работает должным образом и не пропускает законный трафик.
В последний день миграции наша группа по передаче данных внедрила еще одну технологию. Целью здесь было увеличить пропускную способность между сингапурским центром обработки данных и точкой доступа, где мы установили эти новые устройства. После того, как мы изолировали трафик между обоими концами, мы переместили темное волокно в новую оптическую систему DWDM (Galaxy), чтобы добавить 400 Гбит / с пропускной способности центру обработки данных. Поскольку это было ново, у нас возникли проблемы с объяснением, как исправить некоторые проблемы с кабелями в системе. После того, как все было исправлено и готово, мы запустили 4 канала по 100 Гбит / с в производство.
После выполнения всех этих различных шагов мы проанализировали и исправили некоторые проблемы, чтобы ускорить второй PoP с тем же графиком.
Когда оба PoP были запущены в эксплуатацию, мы отслеживали, как он обрабатывает трафик и DDoS-атаки. Мы также связались с нашими близкими клиентами, чтобы убедиться в отсутствии проблем.
В заключение
Эта новая инфраструктура, SMAUG, обеспечивает значительные улучшения в области энергопотребления и экономии места, а также снижает сложность общей конструкции сети. Это также поможет OVHcloud не отставать от растущих требований к приложениям и услугам.
Забегая вперед, мы считаем, что гибкость конструкции SMAUG поможет OVHcloud увеличить пропускную способность сети и быть готовым к технологиям будущего.
Спасибо командам и отраслевым партнерам, которые помогли создать эту новую инфраструктуру.
