Виртуализация *

В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин.

Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM — собственная система управления виртуализацией.

Завершение процесса обучения модели — это, как правило, не конец проблемы, а только её начало.

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

Большинство команд вкладывают значительные средства в инфраструктуру для обучения: быстрые диски, сети с поддержкой RDMA, специализированные коммутаторы. Однако этап передачи данных зачастую по-прежнему выполняется вручную: копирование через scp, открытие доступа к общей папке на GPU-сервере и опора на устные договоренности о том, в какой именно директории лежит верная версия. Если практиковать такой подход достаточно долго, каждая из этих привычек обрастает собственным набором проблем.

Функция S3 Compatible Share, доступная начиная с версии QSM 4.3.1, призвана устранить именно этот пробел. Она позволяет использовать один и тот же общий файловый ресурс одновременно для работы с объектным API (S3) и файловыми протоколами (NFS/SMB). Никаких дублирующих наборов данных или фоновой синхронизации — только один комплект файлов с двумя способами доступа к ним.

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

Технология RAID уже настолько старая, что порой кажется, что она была всегда. И, несмотря на почтенный возраст, основные ее принципы работы остаются неизменными на протяжении многих десятилетий. И это при том, что как минимум дважды индустрия хранения меняла носители информации HDD → SSD → NVMe. Разумеется, все эти типы накопителей по‑прежнему актуальны, но именно с точки зрения прогресса и происходит обозначенный переход.

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

Самым очевидным кандидатом на эту роль выступает механизм QEMU Dirty Bitmaps — это хорошо изученный в экосистеме KVM/QEMU способ отслеживания измененных блоков (CBT). Однако его использование в OpenStack упиралось в отсутствие штатного API на уровне управляющего слоя. Из-за этого приходилось выбирать между двумя крайностями: строить инфраструктуру исключительно на Ceph или ставить агенты внутрь каждой гостевой ОС.

Ниже расскажу, с какими ограничениями сталкивались наши пользователи раньше, как мы переписали логику работы с инкрементальными данными на уровне гипервизора и что еще полезного появилось в релизе «Хайстекс Акура 4.6».

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

Большинство таких проблем можно предсказать и предотвратить ещё на этапе проектирования — об этом статья: как выбрать архитектуру для кластеров MIND uStor, посчитать ресурсы сервера, спроектировать сеть и настроить кластер так, чтобы он держал нагрузку предсказуемо и переживал отказы без драмы. Материал написан для инженеров, которые проектируют или сопровождают такие кластеры.

Привет, Хабр! Это снова Евгений Шилкин и Степан Татауров, эксперты дивизиона инфраструктуры Группы Rubytech. В прошлой статье мы разобрали подходы к миграции, посмотрели, какие есть альтернативные решения, и обмолвились парой фраз про MIND Migrate Guest. 

В этой статье — практическая часть, проверим MIND в деле и протестируем его. Что из себя представляет процесс миграции с точки зрения алгоритма и чем он отличается от простого переноса между серверами? В процессе обнаружили несколько интересных находок. Давайте разбираться.

Привет, Хабр! В целом, про миграцию и импортозамещение высказался уже практически каждый утюг нашей необъятной родины. Почему мы вообще снова хотим подсветить эту тему? Потому что прошло уже достаточно времени, чтобы осознать: миграция — это не просто оперативное решение проблемы, а новый подход к созданию и поддержанию ИТ-инфраструктуры. Мы в компании работаем в такой парадигме довольно давно, начали задолго до 2022 и роста популярности подобных решений, так что успели накопить достаточно опыта.

Статья носит обзщепознавательный характер и будет полезна тем, кому в целом интересны механизмы миграции ИТ-систем — и их ключевые отличия у разных вендоров в разных странах. В следующих статьях цикла мы разберем типы миграции, их алгоритмы и посмотрим на результаты тестирования, чтобы оценить их работу в реальных условиях. А пока…

До AVM виртуализацией управляла сторонняя платформа. Иногда она зависала и переставала принимать задачи. Нагрузку распределили между несколькими экземплярами платформы, но зависания продолжились. До вмешательства операции клиентов не шли.

Привет, Хабр! Понадобилось мне в 2026 году установить XPEnology на ESXi, но актуальных инструкций я не нашёл. Восполняем этот пробел.

Инструкция будет полезна администраторам или DevOps, начинающим своё знакомство с XPEnology.

Внимание: в статье очень много картинок.

Для чего это может потребоваться

Например, можно:

- Ознакомиться с функционалом NAS Synology перед покупкой дорогостоящего оборудования.
- Протестировать установку или настройку новых пакетов.
- Протестировать сценарии перед их реализацией на реальном железе. Например, замену, дисков меньшего объёма на больший. Или обновление DSM 7.2 на 7.3

Сегодня даже для небольшого бизнеса или образовательного учреждения «сервер» редко представляет собой одну физическую машину. Чаще в эту сущность упаковывают понятийно сразу несколько сервисов: файловое хранилище, веб‑сервер, базу данных и пр. Потому что запускать каждую службу на отдельном «железе» дорого, неэффективно и сложно в обслуживании. В этом случае на помощь приходит виртуализация — технология, позволяющая создать несколько изолированных виртуальных машин (ВМ) на одном физическом сервере.

Как выбрать правильную платформу, особенно когда у вас нет отдельного штата ИТ‑инженеров и огромного бюджета?

В нашей статье мы разберём ключевые критерии, на которые стоит обратить внимание при выборе системы виртуализации.

Речь пойдёт про VDI-портал: систему, которая клонирует виртуалки из шаблона, выдаёт их пользователям и гасит простаивающие. Но статья не о нём как о продукте, а об одном вопросе, который на входе выглядит тривиальным: этой машиной ещё пользуются? Ссылка на код будет в конце, одна.

Нужен был пул виртуалок под технический отдел. Много. Держать их все включёнными не на чем: одновременно работает хорошо если четверть, а ресурсы гипервизора кончаются сразу и у всех.

Первое решение было очевидным — скрипт по таймауту. Никто не подключён N минут — машина гасится. Понадобилась — поднимается.

Скрипт я написал за вечер, и он даже работал, но по итогу я изобрёл VDI. Только не так, что посмотрел готовые решения и они меня не устроили, — я вообще не формулировал свою задачу как «нужен VDI» и потому не искал. Я решал «пусть виртуалки сами гасятся», а всё остальное наросло само, вопрос за вопросом. Когда стало очевидно, во что это превратилось, переезжать на готовое было уже и поздно, и незачем.

Дальше разбираю вопросы, которые нарастали.

Как дать узлам внутри GNS3 доступ в интернет, не используя встроенный NAT Hyper-V?

В этой статье превратим Ubuntu 26.04 в маршрутизатор лабораторного стенда. Настроим NAT, DHCP и DNS только средствами Linux.

В результате Alpine получит сетевые параметры по DHCP, выйдет в интернет и мы установим на него клиент OpenSSH.

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

Безусловно, главной функцией в работе любой системы хранения данных является сохранность этих самых данных. Следующим пунктом уже идет обеспечение доступа к ним. А применение различных технологий, многие из которых уже давно стали стандартом де‑факто, позволяет объединить эти важнейшие вехи. В данной статье мы поговорим об одной из таких технологий — метро‑кластере, поддержка которого появится в СХД Qsan начиная с FW 4.3.0.

Привет! Меня зовут Денис Молодяков, я — тимлид команды графики в KasperskyOS. Мы отвечаем за разработку графического стека полного цикла для микроядерной ОС: от создания низкоуровневых графических драйверов до всего необходимого для фреймворков.

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

Вышел Cozystack v1.6.0. Релиз опубликован 22 июля 2026 года и включает все исправления, ранее вышедшие в патч-релизах v1.5.1–v1.5.3. Ниже — перевод официального анонса, дополненный главными исправлениями из патч-релиза v1.6.1 от 5 августа.

В этом выпуске изменилось несколько важных частей платформы. Рабочие узлы тенантных кластеров Kubernetes теперь работают на Talos Linux вместо Ubuntu, тенанты могут включать аутентификацию OIDC для Kubernetes и Grafana, а новый API SecurityGroup даёт более безопасный интерфейс для управления сетевыми политиками приложений.

Обзоров VPS на Хабре хватает, но почти все сделаны Windows-утилитами и сводятся к тому, какой диск показал «отличный результат». Мне же нужна была батарея, которую можно прогнать по SSH на любой машине, и понимание, что конкретно означает каждое число.

Второй пункт оказался неожиданно объёмным. Я трижды получал красивые результаты, которые не имели отношения к тому, что я думал измерить: скорость оперативки вместо диска, кэш гипервизора вместо носителя, конфиг лимитера вместо производительности. Каждый раз цифры выглядели совершенно правдоподобно, и я бы их спокойно опубликовал.

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

Что на самом деле защищает наши данные? Снапшоты, которые создаются за секунды и позволяют мгновенно откатиться к предыдущему состоянию? Регулярные резервные копии, которые хранятся на отдельном хранилище? Или репликация, которая обеспечивает непрерывность работы даже при сбое площадки?

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

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

Короткая история про то, как штатная замена ноды оставила quorum-очереди с двумя членами вместо трёх, и почему cluster_status этого не показывает.

Стенд: OpenStack Caracal (2024.1), развёрнут kolla-ansible. RabbitMQ — кластер из трёх нод, quorum-очереди.

Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущей части мы поговорили о принципиальных причинах неудач и проблем открытого провайдера terraform-provider-ovirt, сделали выводы. Пятая статья цикла будет посвящена ключевым решениям, принятым в ходе разработки собственного закрытого провайдера инфраструктуры zVirt для Terraform. Эта статья может быть полезна всем, кому предстоит разработка провайдера под специфичный API, слабо совместимый с концепциями Terraform. Мы разберем основные архитектурные решения, обозначим сознательные концептуальные ограничения и приведем пример построения не самой тривиальной «системы поверх системы» для улучшения пользовательского опыта.

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

Так появился внутренний dev cloud на KubeVirt. Разработчик сам создаёт VM из поддерживаемого шаблона, управляет lifecycle и портами, меняет ресурсы, смотрит Events, метрики и serial-консоль. Платформа сохраняет контроль над доступами, шаблонами, бюджетами команд и ёмкостью нод.

В статье показано как на базе KubeVirt получился цельный внутренний продукт с минимальными трудозатратами, в котором разработчик действует самостоятельно, а платформа сохраняет контроль над dev-контуром и блокирует создание VM сверх бюджета команды.