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

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

В физическом мире USB-порт — дыра в периметре. Воткнул флешку — и у тебя либо данные утекли, либо малварь приехала, либо оба сценария одновременно. Stuxnet, обнаруженный в 2010-м (но активный с ~2007), пробил air gap завода в Натанзе — первоначально через завербованного агента, а дальше распространялся через USB-накопители. FIN7 в 2021-22 годах рассылали по почте подарочные коробки (от имени Amazon и HHS) с «флешками» — на деле это были Arduino ATMEGA32U4, эмулирующие клавиатуру и набивающие PowerShell-команды быстрее любого оператора. Конечная цель — Cobalt Strike, затем ransomware (BlackMatter, REvil). BadUSB, продемонстрированный на Black Hat 2014, показал, что любое USB-устройство может прикинуться клавиатурой и вводить команды — и VID/PID фильтрация тут не спасёт, потому что идентификаторы прошиты в firmware и перешиваются за минуту.

VDI в теории решает часть проблем: данные живут на сервере, а не на эндпоинте. Но USB-редиректор эту изоляцию пробивает — если разрешить проброс mass storage, пользователь утащит файлы на флешку ровно так же, как с физического ПК. А если не разрешить — придут люди со смарт-картами и принтерами, и скажут «нам нужно работать».

Вот тут начинается инженерный компромисс, который не решается одним галочкой в политике.

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

Со звуком всё иначе.

150 миллисекунд задержки — и собеседник начинает перебивать. 200 — и вы оба замолкаете, ждёте, потом говорите одновременно. 300 — созвон превращается в пытку. Это не абстрактные цифры из RFC, это реальность, которую каждый испытывал на плохом Zoom-звонке. (Кстати, порог в 150 мс — это ITU-T G.114, одна из самых цитируемых рекомендаций в телеком-индустрии. Не потому что магическое число, а потому что дальше начинаются перебивания.)

А теперь представьте: вы построили VDI, развернули 500 рабочих мест, люди довольны. И тут приходит запрос от call-центра: «Мы хотим работать через VDI тоже». Или от отдела продаж: «Нам нужен софтфон в виртуалке».

Вот тут начинается отдельная история.

Привет, Хабр! Меня зовут Артём, и я менеджер продукта РЕД ВРМ. Чуть ранее я размещал статью, в которой рассказал о разработке РЕД ВРМ, планах развития и технических особенностях продукта. В сегодняшнем материале я, как и обещал, расскажу о протоколе RED DIRECT и раскрою новые фичи, которые появятся в ближайшем релизе.

Для начала хотелось бы рассказать о том, как связан протокол RED DIRECT с VDI и Терминальным доступом.

Импортозамещение, уход вендоров, требования регуляторов, безопасность — причин переезжать с продуктов Microsoft и VMware сегодня хватает.
Но важно, чтобы это было осознанное инженерное решение, а не реакция по принципу «лишь бы уйти». Тем более что далеко не всегда есть смысл переплачивать за продукт, который для вашей инфраструктуры избыточен.

В статье разбираю, как собрать отказоустойчивую виртуализацию на базе Astra Linux:
DRBD + GFS2 + Pacemaker против Ceph.

Привет, Хабр!

Обычно мы, ИТ-инженеры, что-то создаём: вводим в эксплуатацию системы, ставим новое железо, настраиваем ПО, добавляем память в серверы и диски в СХД.
Но иногда жизнь подкидывает прямо-таки противоположные задачи — и тогда бывает нужно аккуратно разобрать то, что строилось годами. Или разделить монолитную инфраструктуру на части так, чтобы бизнес даже не заметил этого хирургического вмешательства без анестезии.

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

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

Глава 1. Постановка задачи

Однажды меня вызвали на разговор и поставили задачу: помочь ИТ-подразделению московского филиала международного финансового института отделиться от «материнской» компании.

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

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

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

Привет, Хабр! Меня зовут Даниил Киселёв, я специалист по техническому сопровождению Space. В этой статье я на практическом примере покажу, как в SpaceVM собрать программно-определяемое кластерное хранилище. Рассмотрим типовую конфигурацию, учитывая, что в реальном продакшене параметры и архитектурные решения могут отличаться.

Бизнес ожидает от СХД простых характеристик — чтобы данные были доступны всегда, а сбои и обслуживание не останавливали работу виртуальных машин и сервисов. Именно поэтому программно-определяемые хранилища становятся распространенным инструментом. На примере SpaceVM разбираем, как за считанные минуты собрать отказоустойчивое кластерное SDS, которое решает сразу несколько ключевых задач: снижает стоимость владения и обеспечивает стабильную работу в реальных условиях эксплуатации.

Вопрос о том, зачем вообще нужны программно-определяемые хранилища не лишен смысла. Объемы данных, которые приходится хранить бизнесам, постоянно растут, емкость хранилищ приходится постоянно наращивать, а многим компаниям приходится, к тому же, еще и обеспечивать соответствие требованиям регуляторов. Но стоимость аппаратных СХД и объем инвестиций в них перевешивают – и компании задумываются о переходе на SDS.

Они не только дешевле в принципе – экономия становится еще заметнее, если приходится иметь дело с неструктурированными данными. Есть и другие преимущества: можно абстрагироваться от аппаратной платформы и успешно побороть пресловутый vendor-lock. (это особенно важно в России), компании куда проще обеспечить независимость от вендорских санкций.

tl;dr:

Каждая операция INSERT несет фиксированный overhead (в наших тестах 64–99 ms), независимо от количества строк.

Формула: Total_time = N_statements * fixed_overhead + actual_write_time — подтверждена тестами.

1000 single-row INSERT = 64 секунды (Shared-data) или 100 секунд (Shared-Nothing).

Разница не в диске и не в Docker, а в протоколе commit: TxnLog + publish через BRPC против 2PC + publish_version.

В ANALYZE PROFILE commit overhead прячется в разнице TotalTime - ExecutionTime — это FE overhead.

Батчинг нивелирует разницу: при INSERT SELECT оба режима дают ~0.25 с на 1000 строк.

По оценкам iKS-Consulting, в 2018 году платформу VMware использовали 78,8% компаний, которые применяют виртуализацию. Весной 2025 года в аналогичном исследовании указано, что доля отечественных решений в ПО виртуализации достигла 60,2%, а доля VMware оценивается в ~39% (оценка по данным анализа 19 крупнейших российских облачных провайдеров). То есть VMware-решения все еще заметны, но уже не доминируют так, как несколькими годами ранее

За несколько лет VMware в России прошла путь от «платформы по умолчанию» среди тех, кто виртуализирует, до одной из заметных, но уже не ведущих опций. Рынок быстро перераспределяется в пользу отечественных платформ — ради доступности поддержки и обновлений, управляемости процессов и соответствия требованиям в российских контурах.

В этой статье разберемся, как выбрать платформу виртуализации. Для этого вспомним краткую историю VMware и сравним подходы и классы платформ (On-Prem и у провайдера) с точки зрения эксплуатации, безопасности и миграции. В конце вас ждет чек-лист требований (включая ИБ/комплаенс) и таблица выбора по сценариям, чтобы быстро отсеять неподходящие варианты и собрать план перехода без сюрпризов на согласованиях с ИБ.

Кому эта статья может быть полезна?

Многие сегодня припарковали свои проекты на виртуальных серверах типа vps/vds или физическом сервере. И вот, по каким-то причинам, вы не хотели бы показывать свой код напрямую.

Если вы уже знаете про GitLab runner, Docker и registry – то можно пройти мимо и сберечь свое время. А кто не знает - добро пожаловать. Постараюсь, чтобы было не сложно.

Какие могут быть причины?

Автоматизируем создание виртуальных машин в Proxmox с помощью Terraform: от подготовки единого образа и настройки провайдера до управления инфраструктурой как кодом и хранения state в GitLab.

В каждом офисе есть кладбище техники. У нас это были старые Mac mini — аккуратно сложенные, тихие, бесполезные. Когда-то на них работали, потом они перестали тянуть современные задачи, а дальше стандартный сценарий: «Давайте не выкидывать, вдруг пригодятся».

Как оказалось, пригодились.

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

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

Багбаунти (bug bounty) — это программа денежных вознаграждений за найденные уязвимости. В ноябре 2024 года мы в команде Orion soft запустили такую программу для нашей платформы виртуализации zVirt на площадке Standoff Bug Bounty.

Сегодня я расскажу о нашем опыте bugbounty, расскажу, какие уязвимости были найдены в ходе тестирования и как мы их исправляли.

Когда заходит речь о запуске виртуальных машин в Kubernetes через KubeVirt, первый вопрос, который возникает у инженеров: «А какой там оверхед?» Давайте разберём этот вопрос детально, рассмотрев каждую подсистему отдельно: вычисления, хранилище и сеть.

Статья основана на обсуждении в профессиональном сообществе.

Классическая бытовая дилемма: после ужина в раковине лежат две тарелки. Загружать посудомойку кажется избыточным оверхедом — быстрее сполоснуть руками. Но если вы только что приняли званный ужин на 10+ персон, ручная мойка уже покажется более утомительной.

В инфраструктурных задачах этот «парадокс посудомойки» преследует нас постоянно. Когда нужно мигрировать пару виртуальных машин, инженеру проще и быстрее сделать всё руками, чем настраивать сложные паплайны. Но сегодня, на фоне массового импортозамещения, смены гипервизоров (привет, VMware!) и курса на построение гибридных сред, масштаб задач изменился. В условиях миграции сотен ВМ привычка полагаться на ручной труд становится непозволительной роскошью.

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

Можно получить идеальные 60 FPS и зелёные метрики — и всё равно услышать от пользователей «невозможно работать». Потому что мозг прощает “мыло”, но не прощает задержку: курсор начинает жить своей жизнью, клики “не туда”, печать с запозданием.

В этой части разбираю Input Channel, Cursor Channel и round-trip latency: почему SPICE таскает курсор отдельным каналом, откуда берётся эффект «курсор на резинке», чем отличается server mouse mode от client mouse mode, и почему без usb-tablet / vdagent всё быстро превращается в квест.

Третья статья серии — про то, что реально определяет UX в VDI: не картинка, а отклик.

Парадокс: SPICE отлично справляется с рабочим столом, но спотыкается на видео. Статичный документ — чёткий, быстрый, экономный по трафику. Включили ролик на YouTube — и всё поплыло.

Display Channel — это два разных мира в одном канале. Image Mode: независимое сжатие каждой изменившейся области, умное кэширование, глобальный словарь для повторяющихся элементов интерфейса. Stream Mode: попытка поймать видеопоток и пережать его на лету.

Детекция видео по косвенным признакам. MJPEG из 2009 года как дефолт. GStreamer как путь к H.264. И вечный компромисс между «красиво» и «быстро».

Разбираю анатомию Display Channel — от QXL-команд до финального рендеринга. Вторая статья серии.

В 2007 году инженеры Qumranet приняли решение, которое определило судьбу протокола на следующие 17 лет: только TCP, никакого UDP. Простота победила производительность.

SPICE — протокол, который доставляет рабочий стол от виртуальной машины до пользователя. Открытый, бесплатный, дефолтный для всего Linux VDI. И при этом удивительно мало кто понимает, как он устроен внутри.

Почему курсор передаётся отдельным каналом? Зачем нужен глобальный словарь в GLZ? Как современные композитные менеджеры сломали красивую идею 2D-команд QXL?

Разбираю архитектуру SPICE — не список фич, а инженерные решения и их последствия. Первая статья серии.

Когда вы вводите в командную строку docker run nginx — кажется, что произошло какое-то волшебство: за считанные секунды появляется полностью изолированная среда. Но здесь нет никакой магии, а просто инженерия ядра Linux. Давайте подробнее разберём эту тему подробнее и изучим, что именно происходит внутри ядра, когда Docker создаёт контейнер.

Всем привет! Меня зовут Карина Кошева. Я тестирую совместимость СХД с системами виртуализации в YADRO. Мы проводим такое тестирование, потому что нам важно проверять, насколько успешно система будет работать в инфраструктуре заказчика.

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

Привет, Хабр! Меня зовут Павел Князькин, я системный архитектор в Orion soft, занимаюсь развитием платформы виртуализации zVirt. Сегодня мы поговорим о миграции виртуальной инфраструктуры. 

Миграция с иностранных платформ виртуализации, таких как VMware, HyperV, XEN, а иногда даже и с других отечественных систем виртуализации становится актуальной задачей для многих организаций. Но их останавливают трудности перехода: нужно каким-то образом переместить ВМ из одной платформы виртуализации в другую.

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