Как определить, какие "железные активы" пора "хоронить", а какие "эволюционно" заменить

В прошлый раз мы писали: "знай то, чем владеешь" и "оцени по критичности".

Основной камень преткновения — это бюджет, и его мы пока оставим за кадром.

1. Распределение активов по группам поддержки

Распределите собранные по критичности активы по следующим группам:

"Есть вендорская поддержка"
"Есть интеграторская поддержка"
"Есть какой-то ЗИП на складе"
"Нет ничего, всё горит оранжевым/красным"

Тут всё достаточно просто - всё "железо" старше 3–4 лет (за редким исключением) надо убирать из продакшена.

Важные технологические изменения последних 10 лет:

Процессоры: Мы шагнули от серверов по 4 ядра к тому, что сейчас на один юнит уже можно разместить 64–160 ядер.

Накопители: От SSD в 960 ГБ к SSD и NVMe в 15–30 ТБ на диск, и от HDD в 146 ГБ к 24–30 ТБ на диск.

Сеть: Если ранее гигабитная сеть считалась достаточной, то сейчас обычной считается 25 Гбит/с, а на развитие идут 100 Гбит/с.

2. Максимальная виртуализация

Определите, что можно виртуализировать, и максимально виртуализируйте всё, что можно. Если вендор софта не предполагает виртуализацию — рассмотрите замену вендора софта.

3. Замена оборудования на более высокоплотное

Вытекающее из первых двух пунктов: замена оборудования на более высокоплотное, с виртуализацией и/или гиперконвергенцией, позволит значительно освободить место в стойках. Если у вас свой собственный ЦОД, просто оцените затраты, как если бы вы этот объём арендовали в коммерческом ЦОДе, и всё встанет на свои места. Электроэнергия и стойко-места — не бесплатные.

4. Упрощение технологий и работы с ними

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

5. Сетевое оборудование — большой камень

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

Рецепт простой:

Оцените, какие вам скорости передачи данных нужны (25/100 Гбит/с), и действуйте.

Не забывайте, что сейчас хороший тон — это spine-leaf архитектура, разделение сегментов, "нормальные" NGFW и WAF.

Если у вас начали выгорать порты на свичах — вы уже опаздываете и надо поторопиться.



Главная мысль: простой работы ваших сервисов равно потере бизнесом денег.

Если вы хотите разобраться, что же вам делать и как избежать простоев — мы всегда готовы вам помочь.

Оценка важности IT-активов перед трансформацией.
Ранее мы обсуждали определение IT-активов по степени их "технологической старости". Сегодня мы предлагаем сосредоточиться на функциональности и важности IT-активов перед трансформацией.

1. Системы баз данных
Практически любой бизнес не может существовать без данных. Это могут быть автоматизированные банковские системы (АБС), системы планирования ресурсов предприятия (ERP), биллинговые системы и множество других вариантов.
Ключевые моменты для оценки:
• Отказоустойчивость и защита данных:
o Наличие механизмов отказоустойчивости (кластеризация, Active-Standby, разделение на инстансы и ноды).
o Соответствие мощности серверов Active и Standby.
o Исправное состояние Standby-серверов.
o Правильность сбора резервных копий и файлов журналирования логов.
• Приоритет миграции: При миграции на новое оборудование в первую очередь необходимо уделить внимание серверам баз данных.
• Подходы к базам данных:
o Bare-metal базы данных: Требуют более детального анализа актива. Если это программно-аппаратный комплекс от производителя, важно оценить, насколько он удовлетворяет текущим потребностям и соответствует ли текущему поколению технологий.
o Базы данных внутри виртуальных машин: Оценка здесь проще – достаточно определить, хватает ли мощностей на текущих хостах и выполнены ли меры по доступности данных на программном уровне.

2. Сети
Сеть — это нервная система вашего бизнеса, которую необходимо рассматривать целиком.
Ключевые моменты для оценки:
• Комплексный подход: Включайте не только коммутаторы Top-of-Rack или связки spine-leaf, но и все остальные элементы, такие как NGFW (файрволы нового поколения), CG-NAT, BG-роутеры, WAF (веб-приложенческие файрволы) и балансировщики.
• Офисные сети: Не забывайте об офисных сетях, если ваш бизнес предполагает такой рабочий процесс. Региональные филиалы должны быть подключены к основной сети или к отдельному сегменту так, чтобы это не вызывало проблем с прохождением трафика или безопасностью.
• Взаимодействие между дата-центрами: Если у вас несколько дата-центров, необходимо построить четкие сетевые механизмы для их взаимодействия.
• Избегайте "мультивендорности": Хотя мультивендорность звучит хорошо в теории, на практике она ведет к:
o Увеличению сложности проекта.
o Увеличению стоимости затрат на привлеченных специалистов.
o Увеличению количества контрактов на поддержку и лицензий.
o Некоторые производители предлагают комплексные решения, сочетающие несколько сетевых элементов в одном устройстве, что может сократить список отдельных закупок.

3. Системы виртуализации/гиперконвергенции
Наличие системы виртуализации — это большой плюс. Если её нет, её необходимо создавать.
Ключевые моменты для оценки:
• Состояние и "возраст" системы: Оцените состояние "железа" и вендора программного обеспечения (некоторые решения могли "устареть" за 10 лет).
• Потребности в ресурсах: Рассчитайте необходимый объем процессорных мощностей, оперативной памяти, места для хранения и тип сети для ваших приложений и/или служебных задач.
• Индивидуальные "треки" использования:
o Предоставление ресурсов в аренду: Если вы не только обслуживаете себя, но и сдаете ресурсы в аренду — это один путь.
o Высокая надежность и доступность: Если ваша структура требует высокой надежности и максимальной доступности — это другой путь.
o Оператор связи: Если вы оператор связи — это совершенно определенно третий, уникальный путь.
• Совместимость и выбор вендоров: Важно выписать все ваши "треки" и определить, возможно ли что-либо из этого совместить. Если да, то решите, каким путем двигаться, и на какого вендора (или вендоров) оборудования и виртуализации/гиперконвергенции ориентироваться.

Мы готовы помочь вам преобразовать множество системных задач в понятный и бюджетно-осязаемый механизм. Оценку других групп IT-активов мы продолжим в следующих публикациях.

Важность IT-актива перед трансформацией: Системы хранения данных (СХД)
Продолжаем углубляться в определение важности IT-актива перед трансформацией, уделяя особое внимание системам хранения данных.
1. Роль и значимость СХД
Системы хранения данных могут выступать как частью комплекса баз данных, так и частью подсистемы виртуализации с внешним хранением. К ним стоит относиться максимально внимательно, поскольку СХД также может быть составной частью системы резервного копирования.
Задача оценки СХД усложняется, поскольку зависит от множества факторов:
• Какие именно СХД и в каких подсистемах у вас установлены.
• Какой профиль нагрузки они имеют.
• Насколько они сейчас загружены.
• Имеется ли на них поддержка (вендорская и/или интеграторская).
2. Классификация СХД в современном подходе к бизнесу
В современном подходе к бизнесу мы можем условно разделить все СХД на три класса:
• All-NVMe: Самые быстрые СХД, которые постепенно захватывают рынок за счёт вариаций QLC, TLC, SLC и MLC дисков и, соответственно, разной их стоимости.
• Гибридные системы: Сочетают в себе различные полки с дисками (NVMe, SSD, HDD, NL-SAS HDD).
• HDD-based системы: Состоят исключительно из большого количества HDD.
Для владельца IT-актива важно понимать: классы СХД не взаимозаменяемы. Каждая существует под определённый круг задач, и одна другую может заместить только на очень узком промежутке.
3. Индивидуальные задачи и выбор СХД
Критически важно понимать специфику ваших задач:
• Реплицируемая ли у вас между ЦОДами СХД?
• Или вам нужно дедуплицируемое хранилище для логов, которые посмотрят раз в жизни?
Это всё индивидуальные задачи, которые определяют выбор. Также стоит задаться вопросами:
• Нужна ли вам двух- или четырёхконтроллерная СХД?
• Сколько у вас будет разных СХД под различные задачи?
Для владельца IT-актива нужно принять факт: СХД много не бывает. Лучше иметь несколько разных, пусть и одного вендора, но специализированных под различные задачи, и, как говорится, "не пытаться скрестить бульдога с носорогом". Обычно такие "франкенштейны" сложны в обслуживании, расширении, поддержке и в последующей замене (эра "франкенштейнов" постепенно уходит).
4. Специализированные СХД и Программно-определяемые хранилища (SDS)
Есть также немаловажный сектор – специальные СХД для скоростного бэкапирования/восстановления и/или защиты от Ransomware (шифровальщиков). Это могут быть как отдельные устройства отдельных производителей, так и устройства общего назначения СХД, действующие в паре со специальным софтом.
Будет не совсем правильным обойти вниманием программно-определяемые хранилища (SDS). В какой-то мере сейчас все новые СХД являются программно-определяемыми, так как в большинстве своём базируются на определённых серверных процессорах, общей оперативной памяти, а софт на них может быть вообще запущен виртуальной машиной.
Однако общепринято считать SDS решениями на базе стандартных x86 серверов, объединённых по производительной сети Ethernet в хранилище, доступное по протоколам NFS, S3, RBD, iSCSI. Это могут быть как программно-аппаратные комплексы на базе софта гиперконвергенции, так и условно "чистые" опенсорсные SDS.
Логика обновления/замены для SDS
Здесь логика обновления/замены упирается в смешанную логику серверного оборудования и СХД:
• Физическое устаревание оборудования.
• Программное устаревание (старая версия софта).
• Неактуальность "набивки" машин текущим потребностям в хранении.
Мы готовы помочь вам понять, какие трансформации необходимы для ваших СХД, и пройти с вами этот путь трансформации.

Часть 5: Системы резервного копирования – Недооцененный актив

Приветствую в пятой части нашего сериала об оценке IT-активов!

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

Объясняем, почему так делать нельзя:

а) Резервная копия (бэкап) – это ваш билет к спасению бизнеса. Она позволит не потерять его сразу и безвозвратно.

б) Бэкапов много не бывает. Чем больше копий, тем выше ваша безопасность.

в) Софт для бэкапа должен быть лицензирован. Важно, чтобы у вас была активная поддержка и лицензии на все необходимые функции (базы данных, виртуальные машины, разделы и т.д.).

г) Оборудование для бэкапов должно быть подходящим. Не используйте "что попало", оно должно соответствовать вашим требованиям.

Два сервера с NL-SAS дисками – это не бэкап. Не обманывайте себя, это не обеспечит полноценную защиту.

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

е) "Коробка с дедупликацией" – это не полноценный бэкап. Вы купили только устройство с функцией дедупликации, а не полноценную систему резервного копирования.

ж) RPO (Recovery Point Objective) и RTO (Recovery Time Objective) – важные метрики. За этими аббревиатурами стоит большая работа, которую никто не сделает за вас – ни поставщик оборудования, ни производитель софта, ни интегратор. Это совместная работа, требующая вашего активного участия.

з) Рабочая кассетная библиотека – это ценный актив. Если из трех приводов работает только один, считайте, что у вас нет библиотеки. К сожалению, это один из самых "презираемых" инструментов в нашем регионе, хотя он является одним из самых надежных и дешевых способов хранения значительных объемов данных. Планирование, поддержание в порядке и своевременная замена кассетной библиотеки должны быть вписаны в ваш регулярный план.

и) Off-site бэкап необходим крупным компаниям. Если у вас высокие риски потерь, организуйте хранение резервных копий на удаленной площадке.

к) Восстановление из бэкапа – это не только про оборудование. Это также про обученность персонала к таким действиям.

л) Учения по аварийному восстановлению (disaster recovery) должны быть плановыми и регулярными. Только так вы сможете убедиться в работоспособности вашей системы и готовности персонала к критическим ситуациям.

А мы в свою очередь готовы вам помочь с организацией систем резервного копирования.

Оценка IT-активов, Часть Шестая

6) Программно-аппаратные комплексы со специальной архитектурой

Яркими представителями являются:

а) Программно-аппаратные комплексы баз данных от производителя

Это продукты для реляционных баз данных, для Big Data, комплексы для баз данных попроще и аппаратные комплексы для "динозавров" (старого софта, где вендор зависит от старой архитектуры).

Критерий оценки актива здесь сложнее.

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

Во-вторых, понять, насколько ваш комплекс отстает по софту (как ни странно, на старое "железо" до сих пор выходят новые версии).

В-третьих, необходимо понять, покрывает ли ваш комплекс текущие задачи по вычислительным мощностям и месту хранения. Если ответ вас не удовлетворяет — добро пожаловать к расчету нового комплекса и планированию бюджета под него.

Комплекс для "динозавров архитектуры" требует еще дополнительных опций для изучения:

Выпустил ли ваш вендор софта версию под другую (нормальную) архитектуру, или же вам необходимо апгрейдить без апгрейда?
Не собираетесь ли вы переехать на другой прикладной софт и оставить "устарелую" архитектуру в прошлом?

б) Системы телефонии

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

Как правило, сейчас не существует чистых телефонных систем старого поколения (однако бывают и исключения, особенно ведомственные АТС). Достаточно давно работают гибридные системы.

Здесь опять же важно оценить три вещи:

Насколько старое "железо".
Насколько удовлетворяет пользователей связь и ее типы.
Насколько планируется вырасти/сократиться по размеру пользователей.
Немаловажным фактором является устаревание абонентских терминалов: телефонов, терминалов, спикеров и т.д.

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

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

Более того, на рынок вышло достаточно большое число новых игроков, а старые игроки телефонии наоборот — либо стали слишком дорогими, либо "умерли".

Мы, как и ранее, готовы помочь вам в оценке и трансформации ваших IT-активов в современную форму.

Оценка IT-активов: Часть 7 – Лицензии на ПО

Лицензионное программное обеспечение — это практически основа современного IT-бизнеса, поскольку ни одна компания не способна создать собственное ПО для всех внутренних нужд.

а) Лицензии на ОС (операционные системы)
Часто включают не только саму лицензию, но и поддержку вендора, обычно ограниченную временными периодами.
Необходимо ежегодно проводить ревизию наличия лицензий и поддержки, а при необходимости расширять, заменять лицензии или менять вендора ОС.
Экономия в этом пункте часто приводит к последствиям, которые сложно потом компенсировать за счет других IT-активов.

б) Лицензии на прикладное ПО
К ним относятся ERP-системы, системы проектирования, системы процессинга и т.д.
Недосмотр в этой области чреват серьезными последствиями для непрерывности бизнеса (business continuity), поэтому за ними необходим отдельный контроль.

в) Лицензии на продукты ИБ (информационной безопасности)
Как ни странно, это постоянно актуальный момент.
В процессе работы корпорации и крупные предприятия обрастают достаточно большим слоем продуктов ИБ.
Необходимо проводить регулярную проверку актуальности данного ПО для предприятия и/или расширять, уменьшать или заменять данный конкретный экземпляр ПО иным.

г) Лицензии на офисные/креативные продукты
Здесь также важно вести перечень и количество используемых лицензий.
Особенно важно отслеживать устаревание и переход на новые версии, чтобы, например, не платить параллельно за несколько версий одного и того же софта в разных отделах.

д) Лицензии, идущие в рамках инфраструктурных проектов
Это относится к виртуализации, гиперконвергенции, лицензиям на ядра БД и т.д.
В целом сейчас большей частью это не лицензии на сам продукт, а лицензии на право постоянно пользоваться возможностью поддержки от вендора.
Они также требуют учета и своевременного пересчета.

Мы готовы вам помочь в актуализации вашего лицензионного парка, равно как и в организации процесса отслеживания лицензий.

Оценка IT-активов: Часть 8 – Временно заключительная

Мы достаточно поверхностно рассмотрели различные IT-активы, которые могут составлять основу предприятия или бизнеса. Мы намеренно не стали оценивать специализированные телекоммуникационные комплексы (телевидения, радиовещания, мобильной связи), конечные станции пользователей, промышленные сети и станки, а также ЦОДы. Эти темы очень широки и требуют серьёзного погружения даже на первоначальном этапе.

Вопросы для оценки IT-активов

В рамках общей оценки IT-активов мы должны ответить себе на следующие вопросы:

Критичность: Насколько критичен данный актив для функционирования бизнеса?

Возраст/актуальность: Насколько устарел актив и соответствует ли он текущим требованиям?

Стоимость и масштаб замены: Какие затраты и усилия потребуются для замены актива?

Регулярность оценки: Как часто необходимо проводить переоценку данного актива?

Стратегии распределения бюджета

Для грамотного распределения существующего бюджета или планирования будущего необходимы не только прямые, но и гибридные стратегии. Иногда простое продление поддержки и лицензий в комплекте с покупкой дополнительного оборудования не является оптимальной стратегией. Разделение оборудования по критичности и актуальности также помогает в построении гибридной стратегии развития IT-активов.

Помощь в реализации IT-аудита

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

Мы начинаем цикл об инфраструктуре под AI/ML/DL Часть первая: что же такое AI/ML/DL
Давайте разберёмся, что представляют собой эти три понятия.

a) AI (Artificial Intelligence) — Искусственный интеллект
• AI — это самый широкий термин, охватывающий все системы, способные выполнять задачи, требующие человеческого интеллекта.
• Он является самым "хайповым" программным слоем последнего года и, вероятно, нескольких будущих лет.
• Функционал AI многогранен и включает в себя:
o Ответы на вопросы.
o Разбор и генерация текстов.
o Создание изображений, видео, музыки.
o Сборка и анализ статистических данных.
o Изучение множества источников данных.

б) ML (Machine Learning) — Машинное обучение
• ML — это подмножество AI, которое учит системы находить закономерности в данных, а не быть явно запрограммированными для каждой задачи.
• Оно составляет "предварительный" опыт системы AI, позволяя ей учиться на больших данных.
• Частью ML является:
o Обучение с учителем, без учителя и с подкреплением.
o Нахождение закономерностей, общего и различий.

в) DL (Deep Learning) — Глубокое обучение
• DL — это подмножество ML, использующее многослойные нейронные сети.
• Это самая энергозатратная и технически зависимая часть современного AI.
• Суть DL в послойном разложении данных для обучения и создании нейронно-слоистой структуры обработанных данных.

Важные замечания
• В случае с AI/ML/DL практически нет общих рецептов.
• Выбор программного и аппаратного обеспечения зависит от масштабов и сложности решаемой задачи.
• Задачи AI могут решаться как на условной Raspberry Pi, так и на кластере из десятков Nvidia DGX, при этом принципы AI/ML/DL будут общими.

Часть вторая: Истоки AI/ML/DL

Начало и "Зима AI"

История искусственного интеллекта (AI) в примитивной форме начинается с появлением первой электронно-вычислительной машины.
Сам термин "AI" появился в 1950-х. С появлением математического аппарата для нейронных сетей возникли большие надежды,
но они быстро угасли из-за недостаточного уровня технических средств.
• В 1980-х стали появляться более подходящие аппаратные средства.
Тогда же появились первые экспертные системы, которые работали в очень узких областях.
• После этого последовал спад на 10-15 лет, так называемая "зима AI".
Этот период был связан с перестройкой IT-рынка, а также с началом повсеместной автоматизации и информатизации,
которые полностью поглотили ресурсы индустрии.

Возрождение и революция GPU
В начале 2000-х, с ростом вычислительных мощностей, начались успешные разработки
в направлении ML (машинного обучения) для коммерческих продуктов.
Однако настоящая революция произошла позже:
• Эра GPU: С 2010-х началась эра мощных GPU (Graphic Processing Unit),
в том числе с появлением платформы CUDA от NVIDIA. GPU существовали и раньше,
но CUDA позволила использовать их для неграфических задач, написанных
на объектно-ориентированных языках программирования.
• AlexNet и специализированное оборудование: После создания глубокой
нейронной сети AlexNet на базе видеокарт NVIDIA стало очевидно,
что для таких задач требуется специализированное аппаратное обеспечение.
Это привело к появлению серии NVIDIA Tesla (сейчас это A-серия и H-серия),
предназначенной именно для вычислений AI.
• Тензорные ядра: С появлением архитектуры Volta в 2017 году
в GPU появились отдельные тензорные ядра, разработанные специально
для ускорения матричных операций — ключевых для глубокого обучения.
Эта эволюция от первых ЭВМ до специализированных GPU
с тензорными ядрами проложила путь для современного развития AI, ML и DL.

Часть третья: текущее состояние дел с инфраструктурой под AI.

На текущий момент инфраструктура под AI имеет совершенно сумасшедший разброс возможностей, осветим лишь некоторые из них.

Типы GPU-серверов

Текущие сервера с GPU зависят от масштаба и задач, а также от бюджета и направления деятельности компании.

Локальные решения (On-premise):

-Сверхкомпактные решения:

-Jetson Nano: Представляет собой недорогую, энергоэффективную платформу для разработки, идеально подходящую для хобби-проектов, обучения и прототипирования.

-Jetson Orin: Это новое семейство продуктов, созданное с нуля для более сложных задач AI на периферии, позволяет запускать большие языковые модели (LLM) и другие сложные нейросети, которые были недоступны для Nano.

-Google Coral Dev Board: Использует собственный Edge TPU (Tensor Processing Unit), который разработан специально для ускорения инференса моделей TensorFlow Lite. Оптимизация: Чрезвычайно высокая производительность для выполнения моделей TensorFlow.

-Компактные рабочие станции: Оснащены 1–2 GPU (например, NVIDIA RTX-серии). Идеально подходят для исследований, отладки кода и прототипирования небольших моделей.

-Мощные узлы: Серверные системы с 4–8 GPU (NVIDIA A100/H100). Часто используют специализированные архитектуры, такие как NVIDIA HGX, которые обеспечивают высокую пропускную способность между GPU через NVLink для параллельных вычислений.

-Облачные сервисы (Cloud):

-Платформы: AWS (инстансы P-series, G-series, Inf-series, Trn1-series, M-series, T-series and etc.), Azure (NC-series, ND-series, Exx-series, Dxx-series, NV-series, NC-series and etc.), Google Cloud (A2, A3, A4, A4X, G2, X4, M4, M3, M2, M1, N4, N2, N2D, N1, E2).

Преимущества: Быстрое развёртывание, гибкое масштабирование и оплата по факту использования (pay-as-you-go).

Недостатки: Высокие расходы при длительных и масштабных вычислениях, а также потенциальные задержки (latency) и вопросы безопасности данных.

Часть четвертая: Комплексная инфраструктура для AI

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

- Система хранения данных: Для эффективной работы с большими датасетами используются NVMe-накопители с прямым подключением к шине PCI Express. Их высокая пропускная способность позволяет минимизировать время простоя GPU, ожидающего загрузки данных, что является ключевым для ускорения этапов обучения моделей. При этом часто используется распределённая файловая система (например, Ceph или Lustre) или локальное хранилище с кэшированием.

Специализированные решения: Для AI-нагрузок, где требуется экстремально высокая пропускная способность, применяются специализированные системы. К примеру, компании, такие как Pure Storage FlashBlade или Weka, предлагают высокопроизводительные системы хранения, оптимизированные для работы с неструктурированными данными и обеспечивающие низкие задержки, необходимые для обучения больших моделей.

- Высокоскоростная сеть: Современные AI-кластеры требуют сетевых решений с пропускной способностью 100–400 Гбит/с.

InfiniBand: Эта технология является де-факто стандартом для высокопроизводительных вычислений (HPC) и AI-кластеров. InfiniBand обеспечивает крайне низкие задержки и высокую пропускную способность, что критически важно для распределённого обучения, где веса моделей синхронизируются между несколькими GPU на разных серверах.

Ethernet с RDMA (RoCE): Для тех, кто хочет остаться в экосистеме Ethernet, технологии RDMA over Converged Ethernet (RoCE) позволяют достичь схожей производительности по задержкам.

- GPU-соединения (NVLink): Для достижения максимальной производительности в рамках одного сервера с несколькими GPU используется технология NVIDIA NVLink. Она представляет собой высокоскоростное соединение между GPU, которое значительно превосходит по пропускной способности стандартные шины PCI Express. NVLink позволяет:

-Быстро передавать данные между GPU.

-Создавать единое адресное пространство памяти для всех GPU в сервере, что упрощает программирование и ускоряет вычисления.

Оперативная память (RAM): Большой объём ОЗУ необходим для кэширования и предварительной обработки датасетов (например, декодирования изображений или обработки текста) перед их отправкой в GPU.

Часть 22 и 1\2
Инфраструктурная маневренность и масштабируемость.
Итак, вы решили провести цифровую трансформацию,
заложить основы масштабируемости IT-активов бизнеса на будущие периоды.
Вы оценили текущие активы, выписали все плюсы и минусы. Что дальше?
Десять лет назад принципы построения IT-части бизнеса позволяли иметь только одну площадку и бекап на непредвиденный случай
Сейчас нагруженный бизнес не может позволить себе простоя, особенно цифровой бизнес.
Предварительный вывод? Надо искать варианты построения IT-инфраструктуры так, чтобы даже при потере одного ЦОДа бизнес не останавливался.
Какие здесь есть практики и инструменты?
Самый распространенный - второй ЦОД. Тут есть подводные камни недооценки важности этого ЦОДа.
Не секрет что в некоторых странах регуляторы от определенных секторов бизнеса требуют размещение в двух ЦОДах.
Иногда бизнес это делает для "галочки", иногда урезанно и достаточно редко - полноценно.
Вариант для "галочки" рассматривать не будем.
Урезанный вариант - имеем на второй площадке минимальный прод, отдельную копию основной БД, иногда копию ERP, иногда даже без дублирования сетевого оборудования и оборудования ИБ
Тут есть очевидные минусы: 1) часть процессов остановятся 2) резервная площадка так и остается резервной, бизнес остается зависимым от основной площадки и ждет ее восстановления
3) в случае недоступности части сервисов - страдает клиентский опыт
Полноценный вариант - построение полной копии инфраструктуры.
Почему это единственный правильный вариант? При правильном подходе и организации инфраструктуры, бизнес-процессы не остановятся, клиентский опыт не пострадает.
Один из вариантов организации резервируемой инфраструктуры - частное (приватное) облако.
В этом случае опираясь на общие принципы, можно иметь масштабируемую резервируемость, вплоть до полной копии в публичном облаке (AWS, Azure, GCP)
Наша команда готова помочь вам с построением подобной инфраструктуры.