Бэкап данных – это не восстановление

Бэкап и аварийное восстановление решают разные задачи. Бэкап хранит копии данных, а аварийное восстановление возвращает приложения в работу.

Разберём механику. Бэкап сохраняет копии файлов и баз. Чтобы вернуть сервис в строй, эти копии нужно найти, развернуть, запустить операционные системы и приложения и заново связать их между собой. Пока идёт развёртывание, сервис остаётся недоступным. Данные при этом не теряются, но и работу не выполняют.

DRaaS (Disaster Recovery as a Service) строит процесс по-другому. Сервис заранее реплицирует данные в виртуальные машины на резервной площадке, и при отказе основного контура переносит на неё нагрузку в полуавтоматическом режиме.

Поэтому DRaaS закрывает три задачи, которые один бэкап не покрывает:

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

На этапе планирования и при тестировании команда отвечает на вопрос: за какое время сервис снова заработает после сбоя. Этот срок задают заранее, двумя параметрами: RTO и RPO. К ним и переходим.

RTO и RPO – две метрики, от которых всё зависит

Восстановление настраивают вокруг двух параметров, которые важно согласовать с бизнесом, а лучше от него и получить: RPO и RTO.

RTO (Recovery Time Objective) отвечает на вопрос «за какое время сервис должен быть поднят». Это срок, за который системы должны вернуться в работу после отказа. RTO в один час и RTO в одни сутки задают разный сценарий восстановления и разную стоимость.

RPO (Recovery Point Objective) отвечает на вопрос «сколько данных допустимо потерять». Это объём изменений между последней синхронизацией и моментом сбоя. RPO в пять минут означает, что при аварии теряются данные за последние пять минут работы. RPO в сутки означает потерю данных за последние сутки.

RTO определяет простой системы, RPO определяет потерю данных. Команда выбирает значения под конкретный сервис: платёжный шлюз и внутренний справочник переживают простой по-разному, поэтому и параметры у них разные.

RTO и RPO зависят не только от провайдера сервиса Аварийного восстановления. На них влияют обе стороны:

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

Поэтому целевые значения проверяют на практике. Команда задаёт RTO и RPO, прогоняет переключение и сверяет результат с планом. Если сервис поднимается дольше расчётного времени, параметры пересматривают или меняют схему репликации. Как именно работает само переключение, разберём дальше.

Как это работает организационно-технически

Примечание: Ниже описываем реализацию нашего сервиса Аварийное восстановление (DRaaS), которой подходит только клиентам с VMware на основной площадке. При этом подход используется и другими облачными сервисами с другим ПО.

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

Шаг 1. Настройка сетей. Для того, чтобы сервисы при запуске требовали минимальной донастройки, важно чтобы они запускались в сети максимально похожей на продуктивную. Поэтому в идеале на резервной площадке сделать серые сети с такой же адресацией, а также повторить правила FireWall и NAT.

Шаг 2. Репликация. Виртуальные машины основной площадки реплицируются на площадку Linx через VMware Cloud Director Availability. Инструмент делает копию виртуальных машин и поддерживает их в актуальном состоянии.

При этом можно настроить множество параметров, главные из которых:

• На каких типах дисков будут хранится данные. Чем более быстрые, тем дороже хранение.
• В каких сетях (из шага 1) и с какой адресацией будет запускаться сервер.

• Target RPO: чем чаще идёт синхронизация, тем меньше данных теряется при аварии. RPO задают индивидуально под каждую систему. Чем меньше, тем лучше, но можно уткнуться в ограничение канала связи или в рост нагрузки на СХД, поэтому нужен баланс.
• Retention policy: позволяет задать количество возможных точек восстановления и глубину их хранения. Чем больше больше таких точек, тем больше шанса, восстановить не повреждённые/не зашифрованные данные, но это увеличивает занимаемое на хранилище место. Поэтому тоже нужен баланс.

Шаг 3. Тестовое восстановление каждой ВМ.

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

Шаг 4. Настройка очерёдности восстановления.

Инфраструктура обычно состоит из большого количества ВМ. Часто их надо запускать в определённом порядке, да ещё и иметь возможность делать промежуточные ручные проверки. Эту очерёдность можно заранее записать в специальный скрипт, называемый Recovery Plan. Это позволит ускорить процесс восстановления, а также минимизировать ошибки при ручном запуске.

Шаг 5. Переключение (failover и failback). При аварии на основной площадке, представитель Клиента ответственный за запуск плана восстановления заходит на консоль управления Cloud Director Availability и инициирует преднастроенный Recovery Plan (делает failover). ВМ восстанавливаются, инженеры проверяют работоспособность ИТ сервисов, а бизнес пользователи проверяют и подтверждают восстановление Информационных систем.

Если авария на основной площадке устранена, можно запустить reverse replication, чтобы новые данные начали реплицировать с резервной площадки обратно. А потом в спокойном режиме (например в час наименьшей нагрузки) провести failback и переключить нагрузку обратно на основную площадку.

План аварийного восстановления, который реально сработает

План аварийного восстановления (DRP) задаёт последовательность действий при сбое: какие системы поднимать, в каком порядке и с какими параметрами. План фиксирует логику переключения заранее, чтобы в момент аварии команда выполняла настроенный сценарий, а не собирала его на ходу.

Сам по себе план ничего не гарантирует. Гарантию даёт тест. Команда проверяет, что системы стартуют на резервной площадке и поднимаются в нужном порядке, и только после этого считает план рабочим.

Тестирование строят в несколько этапов:

1. Тестовый запуск. Команда проверяет, что системы стартуют на резервной площадке сразу после репликации и настройки плана. VMware Cloud Director Availability запускает реплику в тестовом режиме, поэтому проверка идёт без влияния на основную площадку.
2. Первое реальное переключение. После теста команда планирует реальный переезд на резервную площадку. Его проводят в нерабочий день или в час наименьшей нагрузки и подключают к проверке как можно больше ролей в компании.
3. Регулярные прогоны. Тестовое переключение проводят раз в месяц, реальное – раз в полгода-год. Регулярность подтверждает, что план продолжает отрабатывать по мере изменений в инфраструктуре.

План устаревает вместе с инфраструктурой. Любое изменение в критичных системах либо не затрагивает план, либо требует обновить его сразу. Чтобы шаг не терялся, пункт про обновление DRP добавляют в стандартный шаблон Change request. Тогда план обновляется в момент изменения, а не задним числом после сбоя.

Где всё это разворачивать

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

В случае с услугой Аварийное восстановление (DRaaS) от Linx Cloud Клиент получает резервную площадку в облаке, а также получает инструмент для репликации и восстановления VMware Cloud Director Availability. RPO задаётся под каждую систему, переключение запускается с веб-портала. Подключение идёт по анкете: команда указывает количество виртуальных машин, объём данных и ресурсы (CPU, RAM), получает доступ к порталу и инструкции. Сервис работает в двух сценариях:

• Стандартный – репликация и запуск виртуальных машин по заранее настроенному плану на резервной площадке;
• Расширенный – аудит инфраструктуры, подготовка плана восстановления, настройка сетей и круглосуточная поддержка.

Проверить схему можно до оплаты: Linx даёт бесплатный тест-драйв на 14 дней, чтобы прогнать тестовое переключение и сверить результат с целевыми параметрами. Условия и подключение на странице DRaaS Linx Cloud.

Итого

Аварийное восстановление настраивают до сбоя, а не во время него. Бэкап сохраняет данные, но не возвращает сервис в работу. Для этого нужна реплика на резервной площадке и заранее настроенное переключение. Параметры RTO и RPO задают рамку: за какое время поднять сервис и сколько данных допустимо потерять. Репликация держит копию инфраструктуры в актуальном состоянии, план фиксирует порядок подъёма систем, регулярный тест подтверждает, что план срабатывает.

Главный показатель готовности – не наличие плана, а дата его последнего прогона. План, который не проверяли полгода, отстаёт от инфраструктуры и в момент аварии работает не так, как записано. Проверьте, когда вы в последний раз запускали тестовое переключение. Если ответа нет, это и есть первая задача.

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

В этой подборке мы собрали сервисы для облачной аренды — то есть платформы, которые позволяют:

1. запускать модели прямо в облаке, без локальной инфраструктуры;
2. платить исключительно за те вычислительные ресурсы, которые реально используете;
3. легко наращивать мощности по мере роста нагрузки.

1. Hostkey — сервера с GPU на все случаи жизни

Hostkey — один из проверенных хостинг-провайдеров на российском рынке, который сдаёт в аренду виртуальные и физические серверы с новыми видеокартами. У Hostkey гибкая почасовая оплата — значит, что вы используете мощность ровно столько, сколько нужно, без лишних трат.

Задачи, для которых GPU-решения от Hostkey подойдут

Современные GPU дают скорость для обучения нейросетей. Для изображений — сверточные сети (CNN). Для последовательностей — рекуррентные, как RNN, LSTM или GRU. Для больших моделей вроде GPT или BERT — архитектуры Transformer. Параллельная обработка позволяет запускать несколько моделей сразу, чтобы подбирать гиперпараметры. Интеграция с фреймворками TensorFlow, PyTorch, JAX и HuggingFace Transformers работает без проблем.

Генеративные модели для текстов — GPT, LLaMA или Falcon, чтобы генерировать контент, чат-боты, копирайтинг или переводы. Для изображений — Stable Diffusion, DALL·E или Midjourney, включая стилизацию. Аудио: TTS вроде Tacotron или VITS, плюс клонирование голоса. Видео: генерация анимации или upscaling с Topaz. Код: автогенерация через Codex, Code LLaMA или StarCoder.

Инференс: онлайн для быстрых ответов в чат-ботах, поиске или персонализации; батч для больших объёмов, как генерация изображений по текстам. Библиотеки ONNX, TensorRT и DeepSpeed оптимизируют скорость.

В обработке естественного языка: извлечение информации, семантический поиск с векторами, суммаризация или перевод. Для изображений и видео: обнаружение объектов, сегментация, inpainting или аналитика видеопотоков в реальном времени.

Параметры аренды: модели, цены и варианты

HOSTKEY предлагает выбор GPU-решений — от выделенных серверов с индивидуальными конфигурациями до виртуальных машин с гарантированным доступом к выделенной видеокарте, ресурсы которой не разделяются с другими пользователями. По задачам и бюджету: игровые модели вроде NVIDIA RTX 4090 или 5090; профессиональные вроде Tesla A100 и H100 — для крупных ИИ-проектов и расчётов.

Аренда помесячная с большой скидкой или почасовая. Серверы в России, Исландии, Франции, Нидерландах, Германии, Финляндии или США.

Цены от 7000 рублей в месяц или от 10 рублей в час — это базовые тарифы. Аренда оборудования оформляется через российскую компанию, даже для зарубежных дата-центров: оплата простая, без международных переводов.

Примеры использования GPU-серверов клиентами HOSTKEY

Один из примеров применения — наложение рекламных объектов на элементы видеопотока во время прямых трансляций спортивных событий. Благодаря мощности GPU, обработка происходит в реальном времени, без задержек и с высоким качеством. Этот кейс описан в блоге на сайте компании.

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

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

Как быстро арендовать вычислительные ресурсы

Заказать сервер можно на сайте или в личном кабинете, предварительно зарегистрировавшись. С момента заказа до предоставления доступов к серверу проходит от 5 до 60 минут, в зависимости от выбранного ПО. Если нужна индивидуальная конфигурация с ручной сборкой, то 1–3 рабочих дня. Доступ через веб-панель управления, API для автоматического заказа, управления и расформирования сервера, или консоль.

Также HOSTKEY предлагает предустановленное программное обеспечение из Маркетплейса. Подборка приложений для GPU серверов находится в разделе AI-платформа.

Лимиты на данные и тесты

Исходящий трафик 50 Тб в месяц бесплатно на скорости 1 или 10 Гбит/с.

Для крупных корпоративных клиентов — тестовый период по запросу. Бесплатного пробного баланса нет, но короткая аренда заменяет тест.

HOSTKEY предлагает серверы с картами последнего поколения Nvidia RTX PRO 6000 Blackwell с объемом видеопамяти 96 ГБ. RTX PRO 6000 предоставляет в 3 раза больше памяти, чем RTX 5090, и в 4 раза больше, чем RTX 4090, что делает ее уникальным решением, способным работать с моделями ИИ и наборами данных корпоративного уровня.

Поддержка

Поддержка круглосуточная, ответ на обращение — не дольше 15 минут. Связаться можно через онлайн-чат на сайте, мессенджеры WhatsApp или Telegram, по e-mail.

Сейчас у HOSTKEY действуют дополнительные скидки до 25% на долгосрочную аренду серверов.

2. ITGLOBAL.COM GPU Cloud — облачные ускорители для AI, ML, HPC и сложной графики

ITGLOBAL.COM предлагает сервис GPU Cloud, который позволяет арендовать виртуальные серверы с графическими ускорителями. Услуга актуальна для тех компаний, которым требуется быстрый доступ к мощным GPU без необходимости инвестировать в покупку собственного дорогостоящего оборудования. Сервис построен на базе платформы виртуализации VMware, виртуальные машины оснащены графическими ускорителями NVIDIA.

Сценарии применения: где работают облачные ускорители

ITGLOBAL.COM перечисляет четыре ключевых сценария, где облачные GPU приносят максимальный эффект:

1. Машинное обучение и ИИ. Модели обучаются быстрее благодаря параллельным вычислениям.
2. Высокопроизводительные вычисления. Ускорители позволяют специалистам быстрее решать математические задачи и проводить научные расчёты.
3. Научное моделирование и CUDA‑вычисления. Графические процессоры ускоряют выполнение сложных вычислений и симуляций.
4. Дизайн и графика. Дизайнеры используют облако для визуализации, анимации и рендеринга больших объёмов данных.

Аппаратные возможности и базовые тарифы

Клиентам предлагают несколько поколений профессиональных видеокарт NVIDIA: A16, A800, A100, H100 и H200. Минимальная конфигурация виртуальной машины включает 1 vCPU, 1 ГБ RAM, 30 ГБ SSD и 4 ГБ памяти GPU на базе A16. Стоимость такой конфигурации начинается от 5 000 рублей с НДС, при этом минимальный срок аренды — один месяц.

Типичные кейсы: обучение моделей и создание контента

Мы нашли два наглядных примера, как используют сервис ITGLOBAL.COM:

1. Тренировка и запуск моделей. Data Scientist или ML‑инженер развёртывает в облаке GPU‑сервер для обучения нейросетей (к примеру, для распознавания изображений или обработки текста). Преимущество в том, что не нужно покупать дорогое оборудование; ресурсы удобно масштабировать под задачу и менять тип видеокарты.
2. Видеорендеринг и 3D‑графика. Видеостудия или дизайнер отправляет сложные сцены на рендер в облако. Это избавляет от необходимости содержать мощные рабочие станции и даёт доступ к современному железу с высокой производительностью, позволяя легко обновлять конфигурацию по мере роста проектов.

Быстрый старт и тестовый период

Сервис ориентирован на длительную аренду, но при этом позволяет быстро приступить к работе: стандартные конфигурации выдаются в течение одного дня. Для оценки возможностей предлагается бесплатный тестовый период на 30 дней, который заменяет собой традиционный «пробный баланс» и даёт время проверить, подходит ли производительность GPU‑клауда под ваши задачи.

Как получить поддержку и консультацию

Тем, кто ещё не является клиентом, ITGLOBAL.COM предлагает оставить заявку на сайте, написать на почту sales@itglobal.com или позвонить по указанному на сайте номеру. Действующие клиенты получают доступ к личному кабинету с системой тикетов, могут обращаться по e‑mail, телефону, в онлайн‑чат и даже через каналы экстренной поддержки 24/7 для решения срочных вопросов.

3. immers.cloud — виртуальные и выделенные GPU с посекундной тарификацией

immers.cloud — облачный провайдер, который сдаёт в аренду виртуальные и выделенные серверы с GPU на базе OpenStack. Главное отличие от других провайдеров — каждая виртуальная машина получает GPU целиком, без разделения ресурсов с другими пользователями и без оверселлинга.

Задачи, для которых подойдут GPU-решения immers.cloud

Ресурсы платформы используются для инференса и обучения нейросетей, файнтюнинга LLM, 3D-рендеринга, научного моделирования и обработки видео. Помимо самих серверов, доступны частные инстансы с Immers Foundation Models, программно-определяемое S3-хранилище и маркетплейс образов с популярным ПО — Windows, Ubuntu, Debian и другими дистрибутивами Linux.

Параметры аренды: модели, цены и варианты

Immers.cloud предлагает 13 моделей GPU — от дата-центровых H200, H100 NVL, H100 и A100 до игровых RTX 5090, RTX 4090, RTX 3090 и RTX 3080, а также промежуточные варианты RTX A5000, A10, RTX 2080 Ti, A2, T4 и V100.

Тарификация посекундная — платите ровно за то время, что сервер реально работал. Цены стартуют от 20 рублей в час, минимальная конфигурация — teslat4-1.4.8.60.

На платформе можно арендовать виртуальные серверы с GPU и CPU (NVMe/SSD/HDD), выделенные серверы с GPU и CPU, а также подключать несколько видеокарт сразу: до 8 GPU на один виртуальный сервер и до 10 — на выделенный.

Примеры использования GPU-серверов клиентами immers.cloud

Команда «КС Авто» развернула автономную AI-систему для круглосуточной модерации контента — спама, фото и текстов. Мультимодальные модели работают через Ollama на трёх облачных RTX 4090 с NVMe, потоки изолированы по видеокартам, без Kubernetes. Система фильтрует сотни спам-атак ежедневно и полностью заменяет штат из 15 модераторов.

Команда IBS построила на платформе единую R&D-песочницу для быстрых AI-экспериментов. Смешанная нагрузка — LLM, NLP, VLM — управляется через GPUStack и vLLM на пуле облачных видеокарт (A100, RTX 3090, RTX 4090) с гибридным сетевым доступом через VPN и прокси. Сейчас в работе 11 активных инстансов для 14 моделей, что позволяет тестировать новые гипотезы за часы, не разворачивая новые серверы.

Как быстро арендовать вычислительные ресурсы

Одно из главных преимуществ immers.cloud — быстрый онбординг: чтобы начать работу, достаточно зарегистрироваться и пополнить баланс от 100 рублей. Доступ к ресурсам — через API OpenStack (релиз Zed), причём используется немодифицированный native OpenStack, поэтому подходят любые стандартные клиенты и библиотеки для работы с API.

Лимиты на данные и тесты

Лимитов на загрузку и выгрузку данных нет. Для новых пользователей действуют квоты по умолчанию: 16 ядер vCPU, 128 ГБ RAM, до 10 томов, до 20 снимков, 1600 ГБ суммарного объёма хранения и 4 виртуальные машины. Квоты можно увеличить запросом в поддержку.

Бесплатный тестовый период до 30 дней или можно запросить индивидуальные тестовые сроки под задачу.

Поддержка

Техподдержка круглосуточная — через чат на сайте, Telegram (или Мах) и по электронной почте, плюс персональный менеджер.

4. Yandex Cloud — виртуальные машины с почасовой тарификацией

Публичная облачная платформа Яндекс.Облако предлагает виртуальные машины с графическими ускорителями NVIDIA Tesla V100 (32 ГБ HBM2), Ampere A100 (80 ГБ HBM2e) и Tesla T4 (16 ГБ GDDR6). GPU предоставляются целиком (без шаринга между клиентами) и доступны конфигурации до 8 GPU на ВМ, включая кластерный режим с объединением нескольких ВМ через высокоскоростную сеть (InfiniBand) для распределенного обучения моделей.

Сценарии использования

Сервис ориентирован на задачи машинного обучения, ИИ и высокопроизводительных вычислений. GPU-ускорители подходят для ускорения обучения нейросетей и инференса, анализа больших данных, а также для ресурсоёмкого 3D-рендеринга и работы с графикой. Пользователи могут разворачивать как одиночные экземпляры для отладки моделей, так и целые кластеры GPU для масштабных экспериментов. Яндекс.Облако интегрировано с экосистемой инструментов (например, платформой DataSphere для ML), упрощающих разработку и деплой решений ИИ.

Формат аренды

Ресурсы предоставляются по модели IaaS с поминутной тарификацией. После подключения GPU-квоты (по умолчанию изначально равна нулю) достаточно создать ВМ нужной конфигурации через веб-консоль, CLI или API. Минимальная конфигурация — 1 GPU (например, Tesla T4) с 4 vCPU и 16 ГБ RAM. Оплата почасовая (с поминутным биллингом), при длительных резервациях ресурсов действуют скидки. Например, доступна бесплатная квота (грант) на тестирование — для юридических лиц до 10 000 руб. на первые два месяца использования облака.

Поддержка и особенности

Инфраструктура Яндекс.Облака размещена в дата-центрах в РФ (соответствие 152‑ФЗ) и предлагает SLA на уровне 99,95%. Имеется круглосуточная техническая поддержка (чат, тикеты) с различными тарифами поддержки под потребности бизнеса. Все операции — от управления ВМ до мониторинга — доступны через удобный веб-интерфейс и API.

VK Cloud — облачные ВМ с GPU и выделенные серверы

VK Cloud (ранее Mail.Ru Cloud Solutions) сдаёт облачные GPU-ресурсы для B2B-заказчиков. В 2024 году платформа добавила графические процессоры NVIDIA L4 (24 ГБ, архитектура Ada Lovelace), которые на 2,5 раза производительнее предыдущего поколения и подходят для ускорения видео и графических приложений. Также доступны тензорные GPU NVIDIA Tesla V100 16ГБ/32ГБ и A100 40ГБ/80ГБ.

Кому подойдет и для каких задач

Сервис рассчитан на задачи ИИ/ML, обработку видео и графики, 3D-моделирование, рендеринг и другие сценарии, требующие высокопроизводительных вычислений. Например, GPU L4 ориентированы на медиаданные (трансляции, кодирование видео, графические рендеры) с поддержкой аппаратного ускорения AI, тогда как A100/V100 используются для обучения крупных моделей глубокого обучения и аналитики данных.

Условия аренды и конфигурации

Облако VK Cloud предлагает как виртуальные машины с GPU, так и выделенные физические серверы. Аренда возможна по модели pay-as-you-go (с помесячной оплатой фактического потребления ресурсов). Минимальная конфигурация — 1 GPU (например, Tesla V100 или L4) на виртуальной машине с выделенными vCPU и RAM; более мощные конфигурации могут включать несколько GPU на одну ВМ. Стоимость использования зависит от выбранной карты и конфигурации; публично тарифы не раскрываются, расчёт производится через персонального менеджера.

Поддержка B2B клиентов и интеграция с платформами

Каждому клиенту назначается персональный менеджер, который консультирует по выбору оптимальной конфигурации и обеспечивает сопровождение. Техподдержка VK Cloud работает 24/7. Возможна интеграция облачных GPU с другими сервисами VK Cloud — например, объектным хранилищем, управляемыми базами данных и инструментами для ML (AutoML, готовые окружения и пр.).

5. Cloud.ru (СберCloud) — широкая линейка GPU до H100

Cloud.ru — облачная платформа, над которой работает компания «Сбер», — предлагают NVIDIA H100 80ГБ (HBM2e/HBM3), а также A100 40/80ГБ, предыдущие Tesla V100 16/32ГБ и графические ускорители NVIDIA A40 48ГБ. Флагманские H100/A100 поддерживают объединение через NVLink и InfiniBand для горизонтального масштабирования — вплоть до связки 8 GPU в одной ноде или распределенного кластера из нескольких узлов (например, решение HGX 8×H100).

Для чего можно использовать

Платформа используется для обучения больших языковых моделей и генеративных сетей — самые требовательные из них эффективно работают на кластерах H100/A100 с высокоскоростным обменом данными. Также облако подходит для научных расчётов и моделирования (HPC) — исследователи могут запускать симуляции на GPU без очередей на доступ к суперкомпьютерам. Для рендеринга видео, обработки медицинских снимков, геологических вычислений и других специализированных сценариев предлагаются конфигурации на основе V100 или A40.

Формат аренды

СберCloud предоставляет несколько моделей аренды: виртуальные машины с GPU (на базе облачной платформы «Advanced»), выделенные физические серверы с GPU (помесячная аренда), а также специализированный ML Space — сервис кластеров GPU с почасовой/поминутной тарификацией.

Виртуальные машины доступны для запуска через консоль (необходим запрос на повышение квоты GPU, после чего ресурс выдаётся в течение минут) — оплата почасовая в рублях.

Выделенные же серверы или мощные конфигурации (например, 8× H100) предоставляются по заявке через менеджера, с минимальным сроком аренды от 1 месяца.

Поддержка и особенности

Cloud.ru ориентирован на корпоративных клиентов, поэтому процесс аренды крупных ресурсов сопровождается персональным менеджером и архитектурной поддержкой. Заявки на GPU рассматриваются оперативно, типовые конфигурации ВМ активируются в течение ~15 минут, нестандартные — до 1 рабочего дня.

Техподдержка работает 24/7, доступна по телефону и через портал, SLA 99,95%. Облачная платформа сертифицирована по требованиям 152‑ФЗ для работы с персональными данными. Также доступны смежные сервисы (облачное хранилище S3, системы контейнеризации, виртуальные рабочие места и пр.).

Как выбирать сервис: несколько ориентиров

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

1. Тип задач и необходимая гибкость. Для экспериментов и краткосрочных проектов подойдут сервисы с почасовой тарификацией и быстрым стартом. Для длительных расчётов и стабильных нагрузок разумнее выбирать помесячные тарифы и более мощные карты.
2. Доступные модели GPU. Если нужен трансформер с миллиардами параметров, выбирайте провайдера, у которого есть Tesla H100/H200; для инференса хватит А‑серии или потребительских карт.
3. География и сеть. Расположение дата‑центров влияет на задержки и требования по хранению данных. Продумайте, нужно ли вам европейское присутствие или достаточно российских площадок.
4. Управление и поддержка. Наличие API, быстрая выдача ресурсов и понятная панель управления экономят время. Поддержка 24/7 и тестовый период помогут избежать сюрпризов.
5. Тестовый доступ и трафик. Бесплатный тестовый период или пробный запуск на несколько минут помогает оценить производительность и стабильность, а квоты на трафик — планировать бюджеты.

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

Почему так? В 2024–2025 годах США ужесточили ограничения: VMware NSX и Cisco ACI официально заблокированы. Казалось бы, идеальный момент для отечественных решений вроде Basis SDN от «Базиса». Но сегодня их доля на рынке — не выше 3%.

Выясним, почему российские SDN, несмотря на импортозамещение, пока так и не стали массовыми, и что мешает бизнесу переходить на отечественные продукты — от дефицита специалистов до проблем с legacy-инфраструктурой. Только факты, кейсы внедрений и прогнозы на 2026–2030 годы с опорой на отчеты Ростелекома, аналитику 6Wresearch и документы OFAC.

SDN в России-2025: почему мир перешел на «сети из кода», а мы настраиваем маршрутизаторы вручную

SDN (Software-defined networking) — это когда сетью управляют не железки, а код. Представьте, что вместо того, чтобы вручную прописывать правила на каждом коммутаторе, вы просто пишете скрипт, и сеть мгновенно перестраивается под ваши задачи. Контроллер SDN решает, куда направить трафик, как распределить нагрузку и какие политики безопасности применить. Все это — без манипуляций с командной строкой и конфигурационных файлов.

Мировой контекст: SDN как новая норма

Глобальный рынок SDN к 2025 году оценивается в $12+ млрд, а темпы роста превышают 18% в год. Причины просты:

• Облака и гибридные инфраструктуры требуют гибкости, которую традиционные сети дать не могут.
• Киберугрозы теперь атакуют не отдельные устройства, а всю сеть. SDN позволяет изолировать зараженные сегменты за секунды — например, отрезать атакованный филиал до того, как он заразит головной офис.
• 5G и IoT без SDN просто не работают. Виртуальные срезы сети (network slicing) — единственный способ гарантировать приоритет критичному трафику, будь то телемедицина или беспилотники.

Но главный драйвер — экономика. Компании устали переплачивать за «умное» железо Cisco и Juniper, когда всю логику можно перенести в софт. К 2025 году 70% корпоративных сетей в ЕС и США управляются через SDN-контроллеры — просто потому, что это дешевле и быстрее.

Россия: технологический суверенитет vs. реальность

В 2024–2025 годах санкции добили то, что не успели в 2022-м:

• VMware NSX официально заблокирован для российских компаний.
• Cisco ACI и Huawei CloudFabric доступны только через «серые» схемы, но их поддержка практически не работает.
• Оборудование попало под прямые ограничения: даже нейтральные производители вроде Arista отказываются поставлять коммутаторы из-за риска вторичных санкций.

Казалось бы, идеальный момент для российских SDN-решений. Но доля отечественных продуктов на рынке — единицы. Причины такой ситуации вполне объективны:

• «Железная» зависимость. Большинство российских SDN работают только с оборудованием конкретных вендоров — YADRO, Aquarius, «Бифорком». Если у компании инфраструктура на старых Cisco или Huawei, миграция потребует полной замены «железа».
• Функциональные пробелы. Тот же Basis SDN декларирует 80% функционала VMware NSX, но ключевые фичи вроде автоматического восстановления после сбоев (self-healing) или глубокой аналитики трафика через ИИ пока в разработке.
• Дефицит экспертов. В России менее 1000 сертифицированных специалистов по SDN — против 25 000 в США и ЕС. Обучение нового инженера с нуля занимает 1.5–2 года — бизнес не готов ждать.

Спрос есть, но внедрять некому

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

При этом Basis SDN — единственное решение, которое хоть как-то закрывает дыру. Его пилоты запустили Ростелеком, СберТех и несколько госструктур. Но даже они признают: продукту не хватает открытости API и поддержки мультивендорных сред.

Вывод: мир уже живет в эпоху «сетей как кода», а Россия только учится настраивать контроллеры. Без массовых инвестиций в R&D (Research and Development, научные исследования и разработки) и образование разрыв будет расти. К 2030 году мы рискуем остаться с SDN «на бумаге», пока глобальные игроки перейдут на следующую ступень — IBN (intent-based networking) — сеть, основанную на намерениях с полной автономией ИИ.

Свои SDN: роскошь или необходимость?

Блокировки лишили российские компании доступа к обновлениям и техподдержке. Санкции против YADRO и других производителей сетевого оборудования усугубили проблему: даже если «железо» физически есть, его нельзя масштабировать без лицензий. Сложность в том, что технологический суверенитет нельзя купить — его нужно строить.

Технологический суверенитет — не лозунг, а вынужденная мера

В 2025 году термин «импортозамещение» уже не вызывает иронии. Сегодня российский бизнес столкнулся с простым фактом: зарубежные SDN-решения либо недоступны, либо работают с перебоями.

Компании, которые в 2024-м надеялись на «серые» поставки VMware NSX, теперь тратят на 40% больше на поддержку устаревших версий.

Basis SDN — пока единственная рабочая альтернатива. Разработка «Базиса» и Angie Software изначально создавалась под санкционные реалии:

• полная независимость от зарубежного ПО — даже гипервизор работает на KVM;
• поддержка российского «железа» (YADRO, Aquarius) без необходимости доработок;
• цена ниже VMware NSX до его ухода с рынка.

Но главное — это не просто клон VMware, а адаптация под российские условия. Например, здесь изначально заложена поддержка требований ФСТЭК к шифрованию трафика, что для госсектора критично.

Преимущества, которые оценит даже скептик

Рассмотрим подробно плюсы перехода на отечественные программно-определяемые сети.

Централизованное управление: оптимизация времени и расходов

Вместо настройки каждого коммутатора вручную вы управляете всей сетью через одну веб-панель. Нужно изменить политику безопасности для филиала? Все делается элементарно: не надо ехать на место или объяснять по телефону — правила применяются мгновенно.

Так работает Basis SDN:

• единый контроллер заменяет десятки разрозненных консолей Cisco Prime или Huawei eSight;
• автоматизация рутинных задач — например, выделение VLAN под новый отдел занимает минуты вместо часов;
• мониторинг в реальном времени — аномалии трафика (DDoS, утечки) система обнаруживает сама и предлагает решения.

Микросегментация: безопасность без головной боли

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

SDN позволяет изолировать критичные сегменты без физического разделения:

• финансовые системы можно отрезать от общего трафика, даже если они используют те же коммутаторы;
• доступ к данным регулируется не только логинами, но и контекстными правилами (например, запрет копирования файлов после 18:00);
• в случае атаки зараженный сегмент автоматически блокируется — без остановки всей сети.

Совместимость: работает здесь и сейчас

Типичная претензия к российскому ПО — «а вот у Cisco…». Но Basis SDN уже сегодня поддерживает:

• Astra Linux и «Альт» — без костылей в виде дополнительных драйверов;
• оборудование YADRO, БСТ, Aquarius — с гарантией обновлений;
• облачные платформы на базе KVM и отечественных гипервизоров.

При этом система не требует полного отказа от legacy-инфраструктуры. Например, можно оставить старые коммутаторы Cisco, но управлять ими через SDN-контроллер — это вдвое дешевле, чем менять все железо.

Рыночные перспективы: куда движется отрасль

Объем рынка SDN в России пока относительно невелик, но к 2031-му прогнозируют его рост до 32 млрд.

Основные драйверы:

• Госсектор: с 2024 года все госкомпании обязаны использовать «третьи ключи шифрования» — без SDN это нереализуемо.
• Телеком: Ростелеком и МТС тестируют SDN для 5G-сетей — ручное управление таким трафиком уже невозможно.
• Средний бизнес: облачные CRM и ERP требуют гибких сетей, а аренда VMware NSX теперь недоступна.

Вывод: свои SDN — это про выживание

В 2025 году вопрос уже не в том, «зачем свои SDN», а в том, как быстро компании смогут перейти на них. Ожидать возвращения VMware бессмысленно и нерационально.

При этом:

• Basis SDN — не идеален, но это практически единственное рабочее решение;
• без микросегментации скоро не получится пройти даже базовый аудит ФСТЭК;
• гибридные облака без SDN превращаются в кошмар админа.

Те, кто внедрит российские SDN сейчас, через 2–3 года получат снижение затрат на 25–40% по сравнению с теми, кто цепляется за «серые» Cisco и Huawei. Остальные рискуют остаться с сетью, которую некому и нечем администрировать.

Проблемы отечественных SDN: почему российские «сети из кода» пока не взлетели

Однако в 2025 году российские SDN-решения пока далеки от совершенства. Basis SDN от «Базиса» и аналоги от VK Tech («Спрут») — первые ласточки, но их внедрение сталкивается с тремя группами проблем: технологическими, экономическими и рыночными. Разберем каждую.

Технологические вызовы: когда железа много, а экспертов нет

Эта группа проблем наиболее показательна для отечественных решений.

Дефицит экспертизы. Для разработки конкурентоспособного SDN нужны специалисты высшего уровня, которых в РФ катастрофически не хватает.

Функциональные пробелы. Basis SDN декларирует 80% функционала VMware NSX, но критичные фичи вроде автономного восстановления после сбоев или глубокой аналитики трафика через ИИ появятся не раньше 2026 года. Для корпоративных клиентов это риск: например, без self-healing атака на один сегмент может парализовать всю сеть.

Совместимость с legacy-инфраструктурой. Большинство российских SDN работают с оборудованием YADRO, Aquarius или «Бифорком». Если у компании стоят старые Cisco или Huawei, миграция потребует полной замены «железа» — а это +30–50% к бюджету проекта.

Пример: В 2024 году Ростелеком-ЦОД пытался интегрировать Basis SDN с унаследованными коммутаторами Juniper. Проект забуксовал — пришлось докупать российские аналоги, что увеличило сроки внедрения на 4 месяца.

Экономические и регуляторные барьеры: санкции vs. окупаемость

Высокая стоимость разработки. Создание Basis SDN обошлось в сотни миллионов рублей. Для сравнения: бюджет VMware NSX превышает $1 млрд, но его распределяют на глобальный рынок. Российским вендорам приходится компенсировать затраты за счет узкой локальной аудитории.

Давление санкций. С июня 2024 года США запретили ИТ-консалтинг и облачные услуги для российских компаний. Это ударило по поддержке гибридных инфраструктур. Стало невозможно заказывать аудит сети у зарубежных вендоров, а облачные платформы вроде VMware Cloud Foundation недоступны даже через «серые» схемы.

Долгая окупаемость. По прогнозам «Базиса», Basis SDN окупится за 2–3 года. Но малый бизнес не готов ждать — ему нужны решения здесь и сейчас.

Рыночное недоверие: почему бизнес не верит в свои SDN

Культ «проверенных» зарубежных решений. Даже санкционные Cisco ACI и VMware NSX остаются в топе запросов у российских интеграторов.

Причины:

• Документация. У Cisco — 500+ страниц детальных мануалов, у Basis SDN — 80, и половина на уровне «как включить контроллер».
• Сообщество. Для VMware NSX есть 1000+ готовых скриптов на GitHub, для Basis SDN — меньше 50.

Низкая осведомленность малого бизнеса. Опрос бизнес-лаборатории «КРОК» показал: 60% компаний с оборотом до 1 млрд руб. считают SDN «дорогой игрушкой для корпораций». При этом они не знают, что микросегментация в Basis SDN снижает риски утечек на 40% — но об этом не пишут в СМИ.

Российские SDN не смогут конкурировать с зарубежными, пока:

• не сократится разрыв в экспертизе — нужны образовательные программы уровня Cisco Networking Academy;
• не появятся гарантии долгосрочной поддержки — например, госсубсидий на 5–10 лет;
• не изменится восприятие рынка — тут нужны кейсы уровня «Сбербанк полностью перешел на Basis SDN».

Сейчас Basis SDN остается нишевым продуктом для госсектора и Ростелекома.

Кейсы и перспективы: где российские SDN уже работают и куда движутся

В 2025 году российские SDN-решения перестали быть лабораторными проектами — они постепенно внедряются в реальную инфраструктуру. Но масштабы пока несопоставимы с зарубежными аналогами.

Разберем, где Basis SDN и другие решения уже доказали свою жизнеспособность, какие рынки могут стать для них перспективными и что мешает ускорить развитие.

Basis SDN: первый крупный кейс — «Ростелеком-ЦОД»

В мае 2025 года «Базис» завершил пилотное внедрение своего SDN-решения в дата-центрах Ростелекома.

Проект показал:

• Сокращение времени настройки VLAN с 4 часов до 15 минут за счет централизованного управления.
• Микросегментация финансовых сервисов — изоляция платежных систем снизила риски атак на 40% по данным внутреннего аудита.
• Совместимость с оборудованием: 70% старых коммутаторов Cisco удалось интегрировать через шлюзы на базе KVM, хотя изначально Basis SDN разрабатывался для российского «железа» YADRO и Aquarius.

Потенциальные рынки: где российские SDN могут закрепиться

В июне 2025 года «Базис» анонсировал партнерство с телеком-оператором в ЮАР.

Причины интереса:

• Цена: $15 000 за контроллер против $30 000 у VMware NSX.
• Санкционная нейтральность: в Африке нет давления на использование российского ПО, а китайские аналоги (например, ZTE SDN) проигрывают в функционале.

Планируются поставки в Бразилию (интеграция с облачной платформой на базе OpenStack) и Казахстан (совместный проект с «Казтелеком»).

Согласно прогнозам, к 2031 году объем рынка SDN в РФ вырастет в 2-3 раза, но 80% спроса будет приходиться на госсектор и госкомпании.

Малый бизнес пока остается в стороне. Проблема в том, что Basis SDN ориентирован на крупные внедрения. Для малого бизнеса нет «облегченных» версий — аналогов Cisco ACI Essentials.

Рекомендации: как сделать российские SDN массовыми

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

Кадры — основа всего. Чтобы ускорить подготовку специалистов, нужно:

• ввести грантовые программы по типу «Цифровых профессий», но с фокусом на сетевые технологии;
• интегрировать модули по SDN в вузовские программы — пока лишь единицы технических университетов включают их в учебные планы.

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

Госсектор стал основным драйвером спроса на отечественные SDN, но для массового внедрения нужны меры, стимулирующие переход коммерческих компаний. Опыт Китая показывает, что субсидии на 50% затрат при миграции с VMware/Cisco резко увеличивают долю локальных решений.

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

Одна из главных претензий к Basis SDN — слабая интеграция со сторонними платформами. Для сравнения: VMware NSX поддерживал свыше 200 приложений, а у российского аналога их на порядки меньше.

Без этого Basis SDN так и останется «закрытым» продуктом для узкого круга заказчиков. Российские SDN не станут массовыми сами по себе — нужна скоординированная работа бизнеса, образовательных учреждений и регуляторов.

Итоги: отечественные SDN требуют долгосрочной стратегии

Российские решения вроде Basis SDN доказали, что могут работать в реальных условиях. Но чтобы конкурировать глобально, нужно:

• увеличить долю рынка внутри страны — пока она менее 5%;
• снизить порог входа для малого бизнеса;
• выйти за пределы госзаказов — иначе продукт останется нишевым.

Жизнеспособность у проекта есть. Basis SDN закрывает 80% базовых потребностей бизнеса: микросегментация, централизованное управление, совместимость с российским «железом». Но критичные функции вроде автономного восстановления сетей появятся только к 2026 году.

Аналитики предсказывают рост рынка SDN в России, но это произойдет только если появятся новые фичи: например, интеграция с ИИ для прогнозирования сетевых аномалий, снизится порог входа и вырастет число специалистов.

Что может сделать каждый:

• Тестировать. «Базис» активно привлекает IT-комьюнити к доработке Basis SDN. Участие в пилотах — способ повлиять на развитие продукта.
• Развивать open-source. Проекты вроде OpenDaylight и OpenStack — основа для российских SDN. Чем больше контрибьюторов, тем быстрее сократится разрыв с зарубежными аналогами.
• Требовать документирования. Одна из главных претензий к Basis SDN — скудные мануалы. Если разработчики увидят запрос от сообщества на детальные гайды, они быстрее их выпустят

Главный вывод: SDN — не просто технология, а новая сетевая парадигма. Россия может занять в ней свое место, но для этого нужны не точечные успехи, а системные изменения.

Больше инфоповодов — в нашем тг-канале.

Рассмотрим, что представляет собой MFA и как помогает избежать утечек.

Проблемы с паролями и принципы MFA

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

MFA противостоит этому, требуя не менее двух факторов аутентификации. Основные типы:

• То, что известно пользователю: пароль или PIN-код — наиболее распространенный, но и самый слабый фактор.
• То, что есть у пользователя: устройство вроде смартфона, USB-токена или аппаратного ключа.
• То, кем выступает пользователь: биометрия типа отпечатка пальца, распознавание лица или сканирование сетчатки.

От двухфакторной аутентификации (2FA) MFA отличается гибкостью: 2FA обычно ограничивается паролем плюс одноразовым кодом (например, из SMS), в то время как MFA позволяет добавлять третий фактор для критических систем.

С MFA часто интегрируют связанные технологии. Единый вход (SSO) упрощает доступ: пользователь авторизуется один раз и получает права на несколько сервисов. Модель нулевого доверия (Zero Trust) проверяет каждый запрос заново, учитывает IP, время и устройство, независимо от источника. Вместе они создают многоуровневую защиту, идеальную для распределенных команд.

Общие принципы работы MFA-систем

MFA-системы обычно развертываются как облачные сервисы (SaaS) или on-premise решения, с акцентом на совместимость с существующими инфраструктурами. Они поддерживают протоколы вроде RADIUS, LDAP, SAML и OpenID Connect/OAuth, что позволяет интегрировать их с VPN, VDI, RDP, SSH, межсетевыми экранами (например, Check Point, Cisco, UserGate), облачными платформами (VMware, Huawei Cloud) и приложениями (G Suite, Salesforce).

При выборе MFA стоит обратить внимание на:

• Методы доставки факторов: SMS/звонки, push-уведомления в мобильных приложениях, боты в мессенджерах (например, Telegram), OTP-токены (аппаратные или программные), U2F/FIDO-ключи и биометрия. Разнообразие методов повышает удобство и адаптивность.
• Политики доступа: Возможность задавать правила на основе IP, времени суток, дней недели или групп пользователей. Это помогает ограничить доступ, например, только из офисной сети или в рабочее время.
• Инфраструктура и надежность: Размещение в сертифицированных дата-центрах с защитой от DDoS, высоким уровнем доступности (SLA не ниже 99.9%) и резервированием данных.
• Интеграция и развертывание: Минимальные требования к аппаратным ресурсам (например, 4 ядра CPU и 4 ГБ RAM для агентов), открытый код для прозрачности и быстрая настройка (от нескольких часов).
• Аудит и мониторинг: Журналы событий с фиксацией IP, страны, результатов аутентификации и алертами на подозрительную активность.
• Самообслуживание: Порталы, где пользователи самостоятельно настраивают факторы или сбрасывают пароли.
• API для кастомизации: Для встраивания MFA в собственные приложения, с поддержкой регистрации пользователей и генерации токенов.

Важно учитывать конфиденциальность: системы должны маскировать чувствительные данные в уведомлениях и соответствовать регуляциям, по типу GDPR или российским законам о защите ПДн.

MULTIFACTOR как пример MFA-решения

В качестве практического примера можно рассмотреть российскую систему MULTIFACTOR, которая применяется для защиты удалённых подключений — RDP, VPN, VDI и SSH.

Решение разворачивается в гибридной модели: часть компонентов работает в облаке, часть устанавливается у заказчика. Облачная часть расположена в российских дата-центрах (Selectel, LinxCloud), сертифицированных по стандартам PCI DSS и ISO 27001. В инфраструктуру встроена защита от DDoS-атак, SLA по доступности заявлен на уровне 99,99%, состояние сервисов можно отслеживать на публичной статус-странице.

Что требуется со стороны клиента:

• служба каталогов (Active Directory или аналог);
• RADIUS-адаптер для обработки запросов;
• портал самообслуживания для пользователей.

Адаптер проверяет первый фактор (логин/пароль) локально, а второй передаёт в облако. Для работы необходима базовая конфигурация (4 ядра CPU, 4 ГБ RAM на Windows Server), а портал самообслуживания требует ещё меньше ресурсов. Ключевые компоненты системы доступны в открытом коде.

Интеграция занимает от нескольких часов: установка агентов и настройка по документации. Поддерживаются стандартные протоколы RADIUS, LDAP, SAML, OpenID Connect/OAuth, что позволяет встроить решение в большинство инфраструктур — файрволы (Check Point, Cisco, UserGate), облачные платформы (VMware, Huawei Cloud), VDI (Citrix, VMware Horizon), RDP/SSH, а также в приложения вроде G Suite, Salesforce и Slack.

Совместимость охватывает Windows (включая Outlook Web Access, Remote Desktop Gateway), Linux (SSH, PAM-модули, sudo), а также российские дистрибутивы (ALT Linux, Astra Linux, РЕД ОС). MULTIFACTOR внесён в реестр отечественного ПО, имеет лицензию ФСТЭК и может использоваться в проектах импортозамещения.

Методы аутентификации:

• мобильное приложение (iOS/Android) с push-уведомлениями и QR-регистрацией;
• Telegram-бот;
• SMS и телефонные звонки;
• OTP-токены (аппаратные и программные, включая Rutoken и ЯКлюч);
• U2F/FIDO-ключи;
• биометрия (Face ID, отпечаток пальца) — при этом приватные ключи остаются на устройстве.

Политики доступа можно задавать так: по IP-диапазону, времени суток, дню недели или группам пользователей. Внедрён единый вход (SSO), портал самообслуживания для настройки 2FA и сброса паролей, а также журнал событий с алертами на подозрительные попытки входа.

Для разработчиков предусмотрен REST API — регистрация пользователей, вызовы на аутентификацию, интеграция MFA в сторонние продукты. Это позволяет адаптировать систему под SaaS-сценарии и корпоративные приложения.

Кейс MULTIFACTOR демонстрирует, как можно построить MFA с поддержкой разных факторов, протоколов и сценариев использования в российском контексте. Перед внедрением важно протестировать совместимость с инфраструктурой и оценить удобство для сотрудников — от этого зависит реальная эффективность защиты.

Рекомендации по выбору и внедрению MFA

При внедрении MFA оценивайте совместимость с вашей инфраструктурой, удобство для пользователей и стоимость владения. Начните с анализа рисков: определите критичные ресурсы (серверы, облачные приложения) и протестируйте решение в пилотном режиме. Обратите внимание на поддержку биометрии и токенов для сценариев с высокой безопасностью, а также на инструменты аудита для оперативного реагирования на инциденты.

MFA — не панацея, но в сочетании с Zero Trust и SSO значительно повышает устойчивость к атакам. Выбирайте системы с гибкими политиками и открытой документацией, чтобы минимизировать зависимость от вендора и облегчить масштабирование.

Какие именно слова под запретом?

Список нежелательных терминов состоит из таких выражений как whitelist, blacklist, master и slave. Их предлагается заменить на более нейтральные allowlist, denylist, control plane, сontroller, doer, primary, replica, secondary, leader, follower, parent, child, main, original и source.

Но ведь заменить придётся огромное количество кода

Да, именно так оно и есть. Например, в списке, подготовленном компанией Red Hat, было отмечено 337 тыс упоминаний слова «master», 105 тыс раз упоминалось слово «slave», 10 тыс раз встречалось слово «whitelist» и 17 тыс — «blacklist». Для того, чтобы выявить все случаи использования неприемлемых терминов, будет разработан специальный фреймворк.