Сегодня Selectel объединяет шесть собственных дата-центров в Москве, Санкт-Петербурге и Ленинградской области. И еще два партнерских — в Новосибирске и Ташкенте.

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

В статье рассказываем, с какими проблемами мы столкнулись во время открытия новых дата-центров и как пришли к современным схемам резервирования.

Несколько дата-центров, один маршрутизатор и минимум резервирования

В 2009 году у Selectel было всего два дата-центра — «Цветочная-1» и арендованный «Технодом» на Васильевском острове.

Мы предоставляли доступ по стандартной схеме, когда через коммутаторы доступа и агрегации серверы подключены к маршрутизатору. Но уже тогда была проблема: дата-центров несколько, а маршрутизатор один — он был расположен на «Цветочной-1». К ней от «Технодома» были протянуты оптические линии связи по разным маршрутам — тогда это было минимальное резервирование, которое мы могли обеспечить.

Схема сети нас не устраивала: перебои в работе дата-центра «Цветочная-1» могли отразиться на клиентах «Технодома».

Открытие новых дата-центров

Ситуация с отсутствием резервных маршрутизаторов усугубилась, когда в 2009-2010 годах мы запустили три здания с машинными залами в Ленинградской области, поселке Дубровка. С появлением последнего «Технодом» закрыли — оттуда мы полностью выехали. «ВКонтакте» также переехал в новый дата-центр.

Даже с открытием первого московского дата-центра на Берзарина маршрутизатор был только на «Цветочной-1». Итог — задержки по 10-12 мс между Москвой и Санкт-Петербургом, а также сильная «зависимость» между регионами.

Резервирование коммутаторов агрегации и линков

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

От сбоев полностью избавиться не удалось: Stack мог упасть даже из-за обновления ПО на коммутаторах. Также у этой технологии были и другие проблемы — о них подробней рассказали в прошлой статье.

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


Схема сети, 2010 год.

Между Москвой и Санкт-Петербургом подключили две арендованные лямбды по 10 Гб — такая схема сети существовала до 2016 года. Но проблема «зависимости» между регионами никуда не делась.

Включение резервных маршрутизаторов

С открытием в 2015 году дата-центра «Цветочная-2» потребность в резервном маршрутизаторе достигла своего пика. И устройство уже лежало на складе, но мы не знали, как его поставить и настроить, чтобы добиться нужного уровня отказоустойчивости. Рассматривали несколько вариантов.

Вариант 1. Разместить маршрутизатор на Цветочной-2.


На первый взгляд все хорошо: на «Цветочной-1» и «Цветочной-2» появляются свои точки выхода в интернет. Между первым и вторым зданиями есть собственная оптика, а от Дубровки — кабели вдоль верхней и нижней железных дорог. Но, присмотревшись, мы нашли минусы.

• На «Цветочной-2» нет альтернативных операторов связи — большинство их оптических кабелей заходит на «Цветочную-1». И получалось, что данные от маршрутизатора на «Цветочной-2» все равно передавались через «Цветочную-1».
• Схема подчиняется метеоритному фактору. Маршрутизаторы расположены географически близко. Если в районе «Цветочной-1» отключится электричество или «упадет метеорит», последствия затронут «Цветочную-2» и, как следствие, Дубровку.

Вариант 2. Разместить маршрутизатор на удаленной операторской площадке.

Так мы впоследствии и поступили: установили резервный маршрутизатор на Кантемировской, 12.


Между Цветочной и Дубровкой у нас было два оптических кабеля. Один от «Цветочной-1» в сторону Кантемировской и Дубровки, а второй — сразу в Дубровку, через нижнюю железную дорогу. Ранее с помощью этих кабелей обеспечивалось резервирование на уровне агрегированного канала связи, теперь же их подключили к независимым пограничным маршрутизаторам.

Схема сети в Москве

С увеличением количества стоек в Москве мы перешли на схему, аналогичную Санкт-Петербургу: на втором и четвертом этажах Берзарина установили по маршрутизатору. К ним подключили и дата-центр DataPro на Авиамоторной, в котором арендуем стойки по настоящее время.


До сих пор мы придерживаемся этой схемы сети. Но в планах на ближайшие несколько лет — повторить опыт Санкт-Петербурга. И при строительстве нового дата-центра в Москве разнести пограничные маршрутизаторы так, чтобы свести метеоритный фактор к минимуму.

Возможно, эти тексты тоже вас заинтересуют:

→ Спутник NaaS: как мы хотели улететь в космос и в итоге связали облако с «железными» серверами через глобальный роутер
→ Как мы разочаровались в Haskell и научились запускать регионы за несколько дней
→ Сетевое резервирование в дата-центрах: решаем задачку про двух велосипедистов

Схема сети в других регионах

В 2018-1019 годах мы начали открывать дата-центры в других регионах. Решили, что сразу сделаем их независимыми от Москвы и Санкт-Петербурга: организовали типовую схему сети и установили по два маршрутизатора в каждом из дата-центров.


Сегодня по такой схеме построены Ташкент и Новосибирск.

Независимость регионов позволяет разделить сетевые плоскости и обеспечить стабильный выход в интернет большему числу заказчиков. Например, когда маршрутизаторы стояли только на «Цветочной-1», мы могли поддерживать около 2500 клиентов из Москвы и Санкт-Петербурга. Теперь — столько же, но уже в каждом из дата-центров.

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

Мы используем только один коммутатор доступа и линк для соединения с сервером. Это оправдано экономией портов: в каждом сервере установлено по три сетевых карты. Первая отвечает за включение IPMI, вторая — за подключение к интернету, а третья — за подключение к локальной сети. В выделенных серверах с готовой конфигурацией данная схема уже «расшита» и активна с момента установки устройств в стойку. Так клиенты не переплачивают за лишние сетевые карты.

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

Разграничения между проектами

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


Наверху расположены два пограничных маршрутизатора — «Цветочная-1» и Кантемировская, 12. К ним протянуты линки от маршрутизаторов доступа, которые обеспечивают выход в интернет для конкретных проектов. С помощью подобной схемы удалось разделить плоскости сети таким образом, чтобы вероятность одновременного падения нескольких проектов была минимальной.

Какие планы на будущее?

Кирилл Малеванов, технический директор Selectel

Мы начинали с дата-центров по 200-250 стоек. Сейчас строим машинные залы по 500-600 стоек, в планах — по 2000. Соответственно, если сегодня выделенными серверами могут пользоваться до 2500 клиентов в каждой локации, то в будущем хотим увеличить это число минимум в 10 раз.

Также после ввода нового дата-центра на Юрловском проезде мы планируем установить там один из пограничных маршрутизаторов — и запустить новую независимую точку доступа в интернет.