Сегодня рассмотрим новый актуальный подход к организации ЦОД

Предпосылки:

Дороговизна и сложность номенклатуры СКС
🔹 Унификация увеличивает среднюю стоимость порта (All SM DC)
🔹 Дифференциация усложняет проектирование, требует более сложного наполнения ЗИП и снижает гибкость при необходимости смены топологий

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

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

Специфика решения
🟦 Беспроводное подключение конечных устройств
🟦 Динамическое перестроение топологии без физической коммутации
🟦 Full mesh в рамках «ячейки»

Ключевые компоненты нового решения

Access level
Дополнения Wifi7 (IEEE 802.11be) для типового уровня доступа обеспечивают как достаточную локальную скорость для конечного клиента (46 Гбит/с), так и возможность прямого взаимодействия конечных устройств (FullMesh).

Для типового подключения вычислительного узла обычной интенсивности этого более чем достаточно (на данный момент стандарт — 10/25 Гбит). При этом в случае необходимости построения HPC систем высокой нагрузки, так же как и в традиционном проводном сценарии, могут быть задействованы решения, обычно используемые на Distribution-уровне и обеспечивающие скорости 100/400 Гбит на узел.

Distribution/Core level
Стандартная оптическая сеть — типичный вариант для переходного этапа, обычно используется на этапе тестирования, однако не позволяет в полной мере раскрыть ключевые преимущества концепции.

Динамическая магистраль DWLEoA «Dynamic Wavelength Laser Emitter over the Air» (OLEoAIR — Open Laser Emitter over the AIR — первичное название на этапе Оpen Source) — до 400 Гбит/с в текущей версии для отдельной длины волны («лямбда»). Базовые подходы на примере проводного прототипа можно изучить на сайте производителя.

Данные по беспроводному варианту предоставляются по отдельному запросу для авторизованных партнеров.

Типовые сценарии

📌 Гибридный — Half Cone approach: используется беспроводной вариант только на уровне доступа, при этом магистральный уровень базируется на классических проводных решениях. Данный подход типичен на этапе апробации либо для небольших инсталляций, для которых рационально использование существующей магистрали.

📌 Рациональный: беспроводной транспорт как на уровне доступа, так и как минимум на уровне распределения, динамическое перестроение топологий внутри POD и между POD, включая POD Slicing.

📌 Оптимальный: на данном этапе скорее как теоретический прототип, широко тестируется, но о продуктивных внедрениях достоверные данные отсутствуют, ключевое отличие — переход от плоской «двумерной» квадратичной схемы планирования ЦОД к пространственной трехмерной схеме, на базе гексагональных либо ортогональных POD. Данный подход позволяет в полной мере раскрыть потенциал динамического перестроения топологий в трех измерениях, но при этом требует радикальной перестройки схемы планирования ЦОД.

Подробнее об особенностях и перспективах

В 2022 году мы придумали рефакторинг сетевой инфраструктуры. За три года работы над проектами с заказчиками мы поняли, что для решения этой задачи не хватает еще одного элемента. Часто выбору стратегии в компаниях препятствуют перегруженность собственных технических специалистов и нехватка знаний о рынке решений. А у нас есть наработанный проектный опыт, сформированные функциональные требования к разнообразным техническим решениям и проведенные тесты десятков различных сетевых вендоров и продуктов. Так мы поняли, что бизнес-аудит отлично дополнит тестирование оборудования в нашей лаборатории Jet RuLab по задачам заказчика с подготовкой отчетов.

Что это дает? Прежде всего, оценку доступного оборудования и продуктов с точки зрения качества реализации и соответствия возможным проектным требованиям. Нередко обнаруживается, что по бумагам оборудование поддерживает тот или иной функционал, но есть нюанс.

Как мы проводим тестирование? Как обычно:
🔹 Если не подходят наши типовые требования, то вместе с заказчиком формируем технические требования к сетевым решениям (в соответствии с их текущей инфраструктурой и возможными планами по развитию).
🔹 Готовим ПМИ для проверки получившихся требований.
🔹 Определяем состав вендорских решений и схему лабораторного стенда.
🔹 Проводим тесты, готовим отчеты.

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

Честные вакансии: DevOps Middle 👀

Вместе с коллегами из команды инфраструктуры рассказали о специфике работы DevOps-специалистов в наших подразделениях на вебинарах учебного центра Слёрм.

Посмотреть записи эфиров можно в VK:
➡️ Эфир Jet Network Team с Сергеем Даниловым и Натальей Самороковой. Сергей в ИТ с 1996 года и использовал DevNetOps, когда он еще не был DevNetOps-ом.
➡️ Эфир Jet Infra Team с Дмитрием Гороховым и Дарьей Юрьевой. Дмитрий отвечает за направление DevOps с уклоном в Ops.

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

А если вам интересно разрабатывать решения для автоматизации больших сетей и вы хотите быть в команде с нами, откликайтесь на вакансии здесь!

Ломаем метрокластер! 😠

23 апреля наши коллеги из Jet Infra Team проводят ну о-о-о-чень технический митап «Метрокластер на отечественном».

Что в программе?
🔹Разбор архитектуры и нюансов технологии метрокластера, особенностей проектирования и реализации
🔹Live-demo работы решения на отечественном оборудовании и ПО

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

В составе стенда два набора оборудования:
🔹СХД Аэродиск
🔹Сервер виртуализации Aquarius под управлением zVirt
🔹Коммутатор Qtech

и один набор ПО:
🔹СУБД Postgres Pro под синтетической нагрузкой
🔹Платформа анализа данных Visiology с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных

Между двумя площадками эмулируется расстояние 60 км. Отслеживать состояние комплекса будет система мониторинга «Пульт».

🔜 Когда?

23 апреля, 16:00

📍 Где?

Offline в офисе «Инфосистемы Джет» в Москве или online

➡️ Регистрация

Как в космосе

Cреди компаний, с которыми мы работаем, уже более 90% приняли решение использовать ИТ-инфраструктуру с резервным ЦОДом. Как минимум он будет задействован для запуска наиболее критических сервисов в случае аварии на основной площадке. В некоторых случаях функции резервного ЦОДа можно реализовать, используя облачные сервисы и размещая серверное оборудование на сторонних площадках по схеме co-location.

Когда в компании планируется использование сразу нескольких ЦОДов, в особенности если они расположены на значительном расстоянии друг от друга (более 40 км), обеспечение отказоустойчивости ИТ-инфраструктуры становится более масштабной задачей.

В этом случае невозможно организовать растянутые L2-сети без ощутимых задержек, а отсутствие таких сетей не позволит переключить трафик с сохранением адресации в резервный ЦОД при возможной аварии. Изменение адресации может сильно увеличить срок восстановления работоспособности систем, которые тяжело переживают смену IР-адресов на ключевых компонентах. Это особенно характерно для legacy-систем, тем не менее многие российские компании продолжают их эксплуатировать. Итогом критической ситуации может стать отказ ПО.

Такой ситуации можно избежать, если выстроить инфраструктуру, состоящую из нескольких Active-Active-ЦОДов с растянутыми L2-сегментами, ресурсы которых различные приложения используют одновременно. В результате при выходе из строя одного из них единственным последствием станет снижение ресурсной базы, а все необходимые адреса, к которым обращаются приложения, останутся теми же.

О том, как можно добиться космической надежности в ИТ, Александр Кушнер рассказал в JETINFO 🚀

Частные LTE-сети: два подхода к выбору частот

Private LTE все чаще становятся альтернативой Wi-Fi и проводным сетям на крупных предприятиях благодаря надежности в условиях сложного покрытия, масштабируемости и высокой пропускной способности.

При внедрении частных сетей компании сталкиваются с выбором частот для них, и здесь есть два варианта: 3GPP- и non-3GPP-диапазоны. Сегодня расскажем о том, какие есть нюансы в каждом случае.

Использование частот 3GPP
Это стандартные частоты, на которых работают обычные сотовые сети, например 1800 МГц, 2600 МГц.

Плюсы:
🍀 большой выбор устройств — можно использовать обычные смартфоны, модемы и промышленное оборудование: датчики, планшеты для склада;
🍀 поддержка оператора — он берет на себя настройку и обслуживание радиосети: антенн, базовых станций.

Минусы:
🍀 зависимость от оператора — нужно согласовывать использование частот, а оператор не всегда готов идти навстречу;
🍀 возможные задержки — если сеть оператора перегружена или оборудование выходит из строя, то это может повлиять и на частную сеть.

Использование non-3GPP-частот
Это специальные выделенные частоты для предприятия, например в диапазоне 360 МГц, которые компания может получить напрямую через ГКРЧ (Государственную комиссию по радиочастотам).

Плюсы:
🍀 полная независимость — не нужно согласовывать с операторами, можно развернуть сеть точно под свои нужды;
🍀 гарантированная стабильность — нет риска, что оператор «приоритизирует» свою сеть в ущерб компании;
🍀 безопасность — можно настроить закрытую сеть без доступа извне.

Минусы:
🍀 мало готовых устройств — оборудование (модемы, датчики) под non-3GPP-частоты встречается реже и может быть дороже;
🍀 нужны свои специалисты или подрядчики, т.к. предприятие само настраивает и обслуживает сеть.

Сейчас компании чаще рассматривают вариант non-3GPP-решения, потому что именно оно дает им полный контроль над связью и обеспечивает закрытый контур при жестких требованиях к ИБ. При этом, если сеть нужно развернуть быстро и с минимумом затрат, вариант частот 3GPP гораздо проще, и оператор отвечает за качество связи.

От бородатых мужиков к сингулярности

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

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

Денис Непочатых:

«Пока что немногие операторы пользуются оркестраторами, но мы предлагаем этот элемент как часть решения Теlсо Cloud, поскольку видим в этом очевидные плюсы. Изначально оркестратор требует точной настройки и создания объемной конфигурации: необходимо расписать каждое действие и план под него, пороги функционирования системы, алгоритмы при превышении границ и т.д. Зато после этого умный оркестратор сможет сам управлять системой, в идеале обеспечивая бесперебойную работу без вмешательства человека».

В качестве оркестратора используется контейнерная платформа «Штурвал». Она позволяет создавать кластеры, настраивать их конфигурацию и управлять ими — централизованно, быстро и безопасно.

Рассказываем в Jet Info о развитии облачной инфраструктуры для операторов связи ☁️