Разделяй и властвуй: как развивалась сеть Selectel

ljzaalufavuwnyewkwjdf6lhmam.png


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

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

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

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


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

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

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

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


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

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


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


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

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

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

80yaj5coves1r2qwzsopeyfyv6k.png


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

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

ljlv2ddyf3kyafemrh6jgm3tkuw.png


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


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

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

k4ypei80ljddgwewthreb3d4ky4.png


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

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


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

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

bca2esnvpnoxlg_ssp314j3jmow.png


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

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


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

kbmgd-4oqcqnqinkyrjji-4qdw4.png


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

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

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


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


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

ew4v1upvnw3cavzpznydmkt-dae.png


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

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


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


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

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


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


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

lcsg3zbumgz0xh8ovcewphtt_ck.png


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

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


bzaryn3b-mvqo-cha0nhrzqadts.png


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

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

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

© Habrahabr.ru