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

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

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

В этой статье расскажем, почему снапшот — это вообще не бэкап, почему репликация не заменяет резервное копирование, какие требования предъявляются к современной системе защиты данных, и покажем, как эти принципы реализованы в связке 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 сверх бюджета команды.

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

В эфире -  команда из центра компетенций VMware. Недавно мы разбирали  интересное поведение в работе ПО у одного из наших заказчиков — облачного провайдера.

 Вы знали, что в vCloud Director с NSX‑V добавление новой внешней сети на шлюз может тихо отключить уже существующую? Система предательски завершит задачу без ошибок, а заказчик заметит пропажу только по упавшим ВМ. Мы воспроизвели это в тестовом контуре и проследили всю цепочку — от галочек в интерфейсе до delete-запроса в PostgreSQL.

Статья — для тех, кто сопровождает vCD с NSX‑V в продакшне. Если вы хоть раз правили внешние сети через UI, вы в группе риска. Покажем, как именно это происходит, и дадим два рабочих обхода — без танцев с БД и перехода на NSX‑T.

Что такое гиперскейлер и в чем его неотъемлемая связь с облачными вычислениями и советскими НИИ?

Сегодня мы попробуем ответить на этот вопрос, а также рассказать, как развитие технологий позволило AWS, Google Cloud, MS Azure и российским Yandex Cloud и Cloud.ru стать крупнейшими облачными провайдерами. 

Продолжение первой статьи цикла, в котором мы собираем полноценный стенд для изучения компьютерных сетей на базе Hyper-V, Ubuntu и GNS3.

Ранее мы уже собрали стенд для изучения сетей на Hyper-V.

Теперь мы изменим топологию стенда и уйдем от Default Switch в Hyper-V. Затем мы скачаем и настроим шаблон Alpine через Docker, установленный внутри GNS3 VM.

В результате получим отдельный сетевой сегмент для устройств GNS3 и заменим ограниченный VPCS на полноценный Alpine Linux.

В мире корпоративной ИТ-инфраструктуры уже много лет существует дискуссия. На одном полюсе — проверенная временем классическая трёхуровневая архитектура (серверы, сеть, внешняя СХД). На другом — гиперконвергентная инфраструктура (HCI), которая объединяет все компоненты в единую программно-определяемую систему. Выбор между ними — это не просто вопрос "что новее", а стратегическое решение, влияющее на управляемость, масштабируемость, отказоустойчивость и совокупную стоимость владения .

Сегодня мне хотелось бы поделиться решением проблемы, с которой гарантированно сталкиваются владельцы современных процессоров Intel (архитектуры Alder Lake, Raptor Lake и новее) под управлением Windows 11, если они пытаются “крутить” тяжелые локальные модели (LLM) или использовать виртуализацию.

Речь пойдет о принудительной изоляции «тяжелого» софта от энергоэффективных ядер (E-cores) и полной передаче вычислений производительным ядрам (P-cores) со стороны излишне навязчивой в этом плане Windows 11.

Кратко о сути проблемы на примере моего ноутбука.
В моём ноутбуке установлен процессор Intel Core i7-13850HX. У этого процессора вполне себе отличная конфигурация: 8 производительных ядер (16 потоков) и 12 энергоэффективных ядер (12 потоков). Всего 28 логических процессоров.

По задумке Intel и Microsoft, встроенный контроллер Thread Director должен сам понимать, какую задачу и на какие ядра (логические процессоры) ему нужно отправлять, но на практике, например, тот же гибридный режим работы (CPU + GPU) локальных нейросетей буквально вводит Windows 11 в полный ступор с “раcкидыванием” процессов на ядра.

Когда я, например, запускаю тяжелую локальную модель (Qwen 72B весом 47 ГБ) в LM Studio и настраиваю частичный перенос слоев на дискретную видеокарту (в моем случае это “скромная” RTX 2000 ADA 8GB), вычисления делятся между VRAM и оперативной памятью (RAM).

В такой ситуации работа LLM делится на две очевидные фазы:

Привет, Хабр! Мы протестировали zVirt 5.0 с функциональностью, которой нет в ванильном oVirt. Главное, что нужно знать: в 5.0 на каждом узле меняется гипервизорная операционная система, фактически выполняется переустановка хостов и системы управления. В статье подробно разберу, почему переход на новую версию – это не рядовое обновление пакетов, а отдельный проект со своими особенностями и подводными камнями.

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

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

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

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

Но кому-то этого оказалось мало. Так появились эмуляторы вымышленных платформ, никогда не существовавших в реальности — явление, известное под названием «Fantasy Console» или «Fantasy Platform». Сегодня углубимся в эту тему: что это за платформы, откуда взялись, кому нужны, и что с ними делают. А по пути разберёмся с интересной терминологической запутанностью.

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

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

Меня зовут Алексей Баранов, я — руководитель направления Data Storage Systems в MWS Cloud Platform, и в этой статье я расскажу, как строим блочное хранилище в нашем облаке, с какими вызовами встречаемся и как их решаем.

Как дать админу доступ к виртуальным машинам на удалённом хосте без агента внутри гостевой ОС — на примере VirtualBox и Hyper-V. Один RDP-движок на оба гипервизора, три бага VirtualBox по дороге и таймаут, который переписал всю архитектуру.

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

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

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

Привет, Хабр! Меня зовут Дмитрий Гоголев, я занимаюсь развитием платформы управления виртуальной и облачной инфраструктурой Cloudlink и направлением частного облака Orion Private Cloud (OPC) в Orion soft. Многое в ИТ-инфраструктуре можно сделать своими руками. Чем больше вы занимаетесь этим, тем лучше понимаете, как это сделать… но иногда легче все-таки с автоматизацией. 

В большинстве случаев у DevOps уже есть набор инструментов автоматизации. Практически все используют Ansible и Terraform или их аналоги для создания окружений. Многие переходят на IaC. Проблемы начинаются в крупных, иногда распределенных инфраструктурах. При отсутствии централизованной платформы, которой могут пользоваться не только сами инженеры, приходится тратить значительное время на согласования, ручные операции и разбор инфраструктурных ограничений. При отсутствии единого каталога типовых сервисов, включающего ВМ, Kubernetes-кластеры, namespaces, хранилища, сети, шаблоны окружений, создание окружения может занимать дни или недели, потому что требует ручных согласований.

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

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

VK Cloud активно использует РЕД ОС от РЕД СОФТ — в том числе в VK Secure Cloud, аттестованном контуре для значимых объектов критической информационной инфраструктуры (ЗОКИИ). На ее примере покажу, как поднять производительность гипервизора, просто обновив легаси и не трогая железо. Вместе с дистрибутивом на ноду приезжает свежий стек целиком: ядро, эмулятор, клиент хранилища, системные библиотеки. Каждый слой подтягивает свой кусок. А для тех, кто застрял на CentOS, ушедшем в EOL, у истории есть вторая часть: обновление закрывает технический разрыв и регуляторику одним движением. Ниже разберу механику по слоям с командами, которые можно выполнить на своей системе.

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

Каждый разработчик давно знает обо всех преимуществах Docker: мы привыкли воспринимать его как универсальный ответ на любые вопросы инфраструктуры. Некогда революционная парадигма разработки стала чем‑то обыденным и сегодня часто принимается как no‑brainer решение при разработке очередного проекта на локальной машине. Но давайте на минуту остановимся и зададимся вопросом: всегда ли эта избыточная изоляция оправдана? Действительно ли мы нуждаемся в «мини‑сервере» на каждом этапе написания кода, или мы просто следуем моде, жертвуя скоростью и комфортом.