Мы запускали новые сервисы, трафик рос, заменяли сервера, подключали новые площадки и переделывали ЦОДы – а сейчас расскажем эту историю, с началом которой знакомили вас пять лет назад.
Пять лет – характерное время для подведения промежуточных итогов. Поэтому мы решили рассказать о развитии нашей инфраструктуры, которая за пятилетку прошла удивительно интересный путь развития, которым мы гордимся. Реализованные нами количественные изменения перешли в качественные, теперь инфраструктура может работать в режимах, которые в середине прошедшего десятилетия казались фантастикой.
Мы обеспечиваем работу сложнейших проектов с жесточайшими требованиями к надежности, и к нагрузкам, среди которых PREMIER и Матч ТВ. На спортивных трансляциях и на премьере популярных сериалов требуется отдача трафика в терабиты/с, мы это легко реализуем, причем так часто, что работа с такими скоростями давно стала для нас обыденностью. А пять лет назад самым тяжелым проектом, работающим на наших системах, был Rutube, который с тех пор развивался, наращивал объемы и трафик, что нужно было учитывать при планировании нагрузок.
Мы рассказывали о том, как развивали «железо» нашей инфраструктуры () и развивали систему, ответственную за отгрузку видео (), но с момента написания этих текстов прошло много времени, создано и внедрено множество других решений, результаты которых позволяют нам отвечать современным требованиям и быть достаточно эластичными, чтобы перестраиваться для новых задач.
Сетевое ядро постоянно развиваем. Мы перешли на оборудование Cisco в 2015 году, о чем упоминали еще в прошлой статье. Тогда это были всё те же 10/40G, но по понятной причине уже через несколько лет модернизировали существующие шасси, и теперь активно используем ещё и 25/100G.
Линки 100G уже давно не являются ни роскошью (скорее, это настоятельное требование времени в нашем сегменте), ни редкостью (всё больше операторов предоставляют подключение на таких скоростях). Однако, 10/40G сохраняет актуальность: через эти линки мы продолжаем подключать операторов с небольшим объёмом трафика, по которым на данный момент нецелесообразно задействовать более ёмкий порт.
Созданное нами сетевое ядро заслуживает отдельного рассмотрения и чуть позже станет темой отдельной статьи. Там мы углубимся в технические детали и рассмотрим логику наших действий при его создании. Но сейчас продолжим рисовать инфраструктуру более схематично, так как ваше внимание, уважаемые читатели, не беспредельно.
Серверы отдачи видео эволюционируют быстро, для чего мы предлагаем немало усилий. Если раньше мы использовали преимущественно 2U серверы с 4-5 сетевыми картами по два 10G-порта у каждой, то теперь большая часть трафика отдаётся с 1U серверов, в которых 2-3 карточки по два 25G-порта у каждой. Карты с 10G и с 25G практически сравнялись в стоимости, а более скоростные решения позволяют отдавать как по 10G, так и по 25G. Результатом стала очевидная экономия: меньше компонентов сервера и кабелей для подключения – меньше стоимость (и выше надежность), компоненты занимают меньше места в стойке – стало возможным размещение большего числа серверов на единицу площади и, следовательно, стала ниже стоимость аренды.
Но важнее выигрыш в скорости! Теперь мы с 1U можем отдавать более 100G! И это на фоне ситуации, когда некоторые крупные российские проекты называют «достижением» отдачу 40G с 2U. Нам бы их проблемы!
Заметим, что поколение сетевых карт, которые умеют работать только на 10G, мы по-прежнему используем. Это оборудование стабильно работает и прекрасно нам знакомо, поэтому мы его не выбросили, а нашли ему новое применение. Эти комплектующие мы установили в серверы хранения видео, которым уже для эффективной работы явно недостаточно одного-двух 1G-интерфейсов, тут 10G-карты оказались актуальными.
Системы хранения данных тоже растут. За прошедшую пятилетку они из двенадцатидисковых (12x HDD 2U) стали тридцатишестидисковыми (36х HDD 4U). Такие емкие «тушки» некоторые боятся использовать, так как в случае выхода из строя одного такого шасси может возникнуть угроза для производительности – а то и работоспособности! – для всей системы. Но у нас такого не случится: мы обеспечили резервирование на уровне геораспределенных копий данных. Мы разнесли шасси по разным дата-центрам – всего мы используем три – и это исключает возникновение проблем как при сбоях в шасси, так и при падении площадки.
Разумеется, такой подход сделал избыточным аппаратный RAID, от которого мы отказались. Избавившись от избыточности, мы одновременно повысили надежность системы, упростив решение и убрав одну из потенциальных точек отказа. Напомним, что СХД у нас – «самодельные». На это мы пошли совершенно сознательно и результат нас полностью устроил.
ЦОДы за прошедшие пять лет мы меняли несколько раз. Со времени написания предыдущей статьи мы не меняли только один ЦОД – DataLine – остальные потребовали замены по мере развития нашей инфраструктуры. Все переезды между площадками были плановые.
Два года назад мы мигрировали внутри ММТС-9, перейдя на площадку с качественным ремонтом, хорошей системой охлаждения, стабильным электропитанием и без пыли, которая раньше лежала толстыми слоями на всех поверхностях, а также обильно забивала внутренности нашего оборудования. Выбор в пользу качества услуг – и отсутствия пыли! – стал причиной для нашего переезда.
Почти всегда «один переезд равен двум пожарам», но проблемы при миграции каждый раз разные. На этот раз основная сложность переезда внутри одного ЦОДа «обеспечили» оптические кроссировки – их межэтажное обилие без сведения в единую кроссовую со стороны операторов связи. Процесс актуализации и перепрокладки кроссировок (в чем нам помогли инженеры ММТС-9), был, пожалуй, самым сложным этапом миграции.
Вторая миграция состоялась год назад, в 2019 году переезжали мы из не очень хорошего ЦОД в O2xygen. Причины переезда были схожие с рассмотренными выше, но к ним добавилась проблема с непривлекательностью исходного ЦОДа для операторов связи – многих провайдеров приходилось «догонять» до этой точки своими силами.
Миграция 13 стоек на качественную площадку в ММТС-9 позволило развивать эту локацию не только как операторскую (пара-тройка стоек и «пробросы» операторов), но и задействовать в качестве одной из основных. Это несколько упростило миграцию из не очень хорошего ЦОД – большинство оборудования из него мы перевезли на другую площадку, а O2xygen отвели роль развивающегося, отправив и туда 5 стоек с оборудованием.
Сегодня O2xygen уже полноценная площадка, куда «пришли» необходимые нам операторы и продолжают подключаться новые. Для операторов O2xygen оказался тоже привлекателен с точки зрения стратегического развития.
Основную фазу переезда мы обязательно проводим за одну ночь, и при миграции внутри ММТС-9 и на O2xygen придерживались этого правила. Подчеркнем, что правило «переезд за ночь» мы строго выполняем независимо от количества стоек! Был даже прецедент, когда мы перемещали 20 стоек и выполнили это тоже за одну ночь. Миграция достаточно нехитрый процесс, требующий аккуратности и последовательности, но и тут есть некоторые хитрости как в процессе подготовки, так и при переезде, и при развертывании на новой локации. О миграции в деталях мы готовы подробно рассказать, если у вас будет заинтересованность.
Результаты пятилетки развития нам нравятся. Мы завершили построение новой отказоустойчивой инфраструктуры, распределенной по трем центрам обработки данных. Резко повысили плотность отдачи трафика – если недавно радовались 40-80G с 2U, то сейчас для нас норма отдавать 100G с 1U. Теперь и терабит трафика воспринимается нами как обыденность. Мы готовы и дальше развивать нашу инфраструктуру, которая получилась гибкой масштабируемой.
Вопрос: о чем рассказать вам в следующих текстах, уважаемые читатели? О том, почему мы стали создавать самодельные системы хранения данных? Про сетевое ядро и его особенности? О хитростях и тонкостях миграции между дата-центрами? Об оптимизации решений по выдаче путем подбора компонент и тонкой настройки параметров? Про создание устойчивых решений благодаря многократному резервированию и горизонтальным возможностям масштабирования внутри дата-центра, которые реализованы в структуре из трех ЦОДов?
Автор: Петр Виноградов — Технический директор Uma.Tech
Источник: habr.com