Привет, Хабр! Сегодня я, Евгений Мартынов, директор по информационным технологиям Рег.ру, расскажу, как мы выбирали ЦОД и открывали нашу новую локацию в технопарке «Жигулевская долина» в Самарской области. 

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

Навигация по тексту:

Сложности выбора площадки

Как выбирали

Наш финалист

Немного про Жигулевскую долину

И-и-и, поехали! Или нет?

Что у нас получилось

Сложности выбора площадки: на что смотрели и на чем остановились

Самарская область, а именно Тольятти, — далеко не первый кандидат на размещение новой локации. Коммерческие и продуктовые смыслы тянули в сторону площадки в Казахстане, и мы действительно довольно тщательно прорабатывали этот вопрос. Однако, в силу ограниченных возможностей по защите сети и привычной нам эксплуатации ЦОДов на должном уровне, еще больших проблемах с поставками оборудования и правовых вопросов использования площадки, которые неизбежно привели бы к серьезным задержкам запуска, мы решили изменить вектор. В том числе и для того, чтобы диверсифицировать собственные риски роста и возможные сложности разрастающихся локаций в Москве и Санкт-Петербурге. Ко всему прочему, ходили слухи о скором переезде площадки Санкт-Петербурга (и они оказались реальностью, но об этом в следующий раз). Все это переключило нас на поиск вариантов внутри страны.

Мы рассматривали площадки в Новосибирске, Екатеринбурге, Казани и других крупных городах РФ. Почти все время упирались либо в отсутствие мест (с возможным расширением, но непонятными сроками запуска), либо на несоответствие нашим критериям выбора.

Как выбирали

  • Собрали верхнеуровневые критерии.

  • Посмотрели референсы крупных провайдеров.

  • Главное — сконцентрировались на оптимальном балансе качества и скорости получения результата.

Критерии принятия решения по выбору локации были такие:

  • регион с плотным населением, обеспечение быстрого отклика близлежащих территорий, каналы связи с другими странами;

  • достаточная удаленность от двух столиц (катастрофоустойчивость);

  • технологичность площадки (Tier III, высокий uptime, широкие каналы связи);

  • стойки от 7кВт;

  • наличие места в рядах, машзалах;

  • дублированные крупные операторы связи, независимые оптоволоконные каналы связи;

  • отсутствие конкурентов в конкретном регионе.

Дополнительным фактором было наличие грамотных «рук» на площадке, услуг SmartHands. 

Наш финалист

Исходя из всех требований, в том числе необходимости быстрого запуска новой локации, посетив некоторые площадки, мы выбрали технопарк «Жигулевская долина». Локация в большей степени соответствовала всем нашим критериям (не без нюансов, о них расскажу чуть ниже). Предложение уникально на рынке, удовлетворяло нас в части технологичности, достаточно удалено от текущих площадок, но при этом находится довольно близко относительно зарубежных каналов до близлежащих стран (согласно карте связности).

Не последним фактором было и то, что Самара — практически малая родина Рег.ру, одно из тех мест, где мы активно нанимаем сотрудников и имеем собственный офис. В близкой транспортной доступности оказалась и часть наших собственных инженеров, готовых подстраховать инженеров ЦОДа. Они участвовали и непосредственно в монтаже.

Ну и конечно, там вкусное пиво!

Игорь Юрьевич оценил
Игорь Юрьевич оценил

Немного про Жигулевскую долину

Дата-центр «Жигулевская долина» находится на территории одноименного технопарка в Самарской области. ЦОД соответствует уровню отказоустойчивости Tier III Uptime Institute. Прошел сертификацию Uptime Institute о соответствии стандартам Tier Design и Tier Facility. И — что важно — здесь можно разместить собственное оборудование.

В ЦОДе шесть машинных залов общей площадью 843 кв.м, вмещающих 326 стоек мощностью от 7 до 20 кВт каждая. Сеть передачи данных построена с применением коммутаторов HP FlexFabric и Juniper QFabric. Система бесперебойного и гарантированного электроснабжения построена на дизель-динамических источниках бесперебойного питания. Если электроэнергия прекращает поступать, ротор вращается по инерции и электрическая установка продолжает вырабатывать ток еще несколько секунд. Этого времени хватает на запуск дизель-генератора. Таким образом, работа оборудования не прекращается ни на секунду.

Технопарк Жигулевская долина
Технопарк Жигулевская долина

И-и-и, поехали! Или нет? 

С какими мы столкнулись трудностями?

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

Второе: задержка поставки оборудования относительно планового заказа составила 8 месяцев. Если бы мы ждали изначально заказанное оборудование, вероятнее всего, не запустились бы до сих пор. Поэтому мы разместили параллельный заказ и получили оборудование от другого вендора за 3 месяца, что уже не так значительно повлияло на сроки, и мы смогли запуститься в рамках ранее анонсированных обещаний и не слишком выходя за границы roadmap.

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

Все трудности оказались преодолимы и мы запустились под песню Шуфутинского 3 сентября.

Что у нас получилось 

На текущий момент в «Долине» запущено несколько стоек с вычислительными (compute) узлами на базе платформ Gigabyte следующей конфигурации:

  • 2х AMD EPYC 7543;

  • 1024Gb RAM;

  • 4х SSD 7.68Tb NVME;

  • 2x 40G NICs.

Для управляющих узлов (control plane) мы использовали двухпроцессорные платформы на базе Intel Scalable Gold. 

Узел связи собран на основе оборудования Cisco и Juniper. Все ноды подключаются дублированным 40Gbit-ным подключением, весь сетевой стек продублирован и подключен 40Gbit-ой агрегацией.

Стойка в ЦОДе
Стойка в ЦОДе

Также продублированы каналы связи двумя независимыми поставщиками.

Пока мы запустили только IaaS на базе «производительной» тарифной линейки, однако уже скоро в регионе станут доступны к заказу и другие ключевые облачные сервисы (DBaaS, KaaS и S3). 

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

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

Комментарии (2)


  1. itGuevara
    06.09.2024 15:37

    дублирован .. дублирован .. дублирован

    К расчету надежности дублированной группы. Отказоустойчивые конфигурации (резервирование) – сложная штука и нормальный расчет коэффициента готовности реального отказоустойчивого сервера (например, реального кластера) еще не встречал (у кого есть – покажите). Там должен быть как минимум параметр «вероятность отказа, не обнаруженного внутренней системой контроля», т.к. идеальных систем нет. Состояние необнаруженного отказа - это например, когда узел поломан (не обрабатывает нагрузку), но keep-alive "исправлено" шлет остальным узлам (или резервные узлы не переключаются при отсутствии на входе сигнала "пока жив" от соседа). Даже один не обнаруженный из пятисот обнаруженных отказов изменит характер зависимости.

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

    Какие вообще точные модели переключения резервов при дублировании, троировании? Как "потрохов" внутри сервера, так и кластеров, включая геокластер. Может быть добавление дублированного узла снижает надежность системы (что ранее точно встречалось).


  1. anonymous
    06.09.2024 15:37

    НЛО прилетело и опубликовало эту надпись здесь