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

“Администраторы делятся на три категории - тех, кто еще не делает бекапы, тех, кто уже делает, и тех, кто уже проверяет бекапы.”

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

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

Этот гайд поможет быстро и без проблем развернуть Proxmox VE 9. Разбираем все шаги: от первого входа и настройки сети до запуска VM, LXC и автоматических бэкапов. Четкие инструкции, практические советы и решения частых проблем.

Пожар в ЦОДе, авария на подстанции, разорванный во время ремонта кабель между площадками — таких инцидентов за последние годы хватает. Например, в конце этого сентября пожар в государственном дата-центре Южной Кореи парализовал сотни госсервисов и уничтожил свыше 800 терабайтов данных без резервных копий. 

Единственная реальная защита от таких сценариев — геораспределенные инсталляции с Disaster Recovery (DR). Система автоматически перекидывает нагрузку на резервную, если основная упала. Большинство российских ИТ-инфраструктур виртуализированы, сервисы работают в виртуальных машинах, и заказчикам нужны DR-сценарии именно для виртуализации. Поэтому мы в Orion soft разработали модуль DR для собственной платформы виртуализации zVirt. Он обеспечивает программную репликацию на уровне гипервизора (без агентов внутри гостевых ОС) и аппаратную на уровне СХД. 

Я Александр Гавриленко, директор технического пресейла zVirt. В этой статье расскажу, как мы воспроизвели привычную функциональность VMware и что адаптировали в решении под специфику российского рынка.

Статей про Docker много не бывает.

В этом материале мы разберём базу: что такое Docker, как он работает и зачем нужен, а затем пошагово пройдём путь от установки до запуска первого контейнера.

В моих предыдущих статьях я так или иначе сравнивал систему виртуальных машины МФ и подобные виртуальные системы на платформе х86-64. В одной из них я доказывал (безуспешно — статью заминусовали. Правда сколько было плюсов не известно) что хорошая ОС с классическим разделением времени и ресурсов, плюс встроенный в железо микро‑, или милликод для представления сервера набором разделов** аналогичным по всем параметрам всему серверу делают ненужным виртуальные системы.

Вспомнил свой опыт работы с ОС 7 ЕС и несколько изменил свое мнение. Правда при этом вскрылся еще один недостаток виртуальных систем на х86-64, который не позволяет ей считаться настоящей (полной, классической).

Давайте разбираться.

Разрабатываете Ansible роли на macOS с процессорами M1/M2/M3/M4? Тогда вы знаете проблему локального тестирования роли: molecule + vagrant + virtualbox не работает, molecule + vagrant + VMWare через "костыли", а Docker не подходит для тестирования системных компонентов. Я написал драйвер molecule-lima, который использует нативную виртуализацию macOS через Lima и полностью интегрируется со стандартным Molecule workflow. Драйвер реализован на Ansible playbooks, работает на macOS (ARM/Intel) и Linux, устанавливается одной командой pip install molecule-lima.

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

Рассказываем о своем опыте ее внедрения в нашу платформу виртуализации SpaceVM.

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

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

Но общий доступ — это не только вопрос архитектуры, но и способа взаимодействия с данными. Файловые протоколы (NFS, SMB и др.) дают возможность работать с файлами на уровне операционной системы, но вносят дополнительные задержки и ограничения. Блочные протоколы (iSCSI, Fibre Channel) предоставляют более низкоуровневый доступ — сервер видит удаленное устройство как локальный диск. Однако при этом возникает другая проблема: как синхронизировать работу нескольких узлов с одним и тем же блочным устройством, не разрушив файловую систему?

Ответ на этот вызов дают кластерные файловые системы, специально разработанные для совместного блочного доступа. Одна из самых зрелых и функциональных среди них — GFS2 (Global File System 2). В нашем опыте ее интеграция в собственный продукт - платформу виртуализации SpaceVM - позволила приблизиться к созданию устойчивой, масштабируемой и по-настоящему отказоустойчивой среды.

Привет, Хабр! В статье поговорим о том, почему традиционные методы оценки производительности серверов для 1С не работают в облачной инфраструктуре и как мы нашли решение этой проблемы.

А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск, где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. 

Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей. 

Регистрация здесь

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

С одной стороны, программные ЦОДы значительно ускоряют бизнес-процессы и упрощают управление инфраструктурой. С другой стороны, российские регуляторы (ФСТЭК России, ФСБ и Росстандарт) предъявляют жесткие требования к обеспечению безопасности, надежности и соответствия национальным стандартам, особенно в сферах, затрагивающих критическую информационную инфраструктуру и обработку персональных данных.

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

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

Какие именно ошибки деплоя в Kubernetes встречаются чаще всего и как их устранять? Будь то CrashLoopBackOff, зависшие поды, проблемы в синтаксисе YAML — рассмотрим 10 распространенных проблем и к каждой приложим простые и проверенные советы, как избежать их появления в будущем.

Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов, больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает.

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

Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов.

Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.

Я задал это вопрос ИИ (Google) и получил ответ:

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

Основные причины, зачем нужны виртуальные машины:

Запуск нескольких ОС: Позволяют использовать Windows на Mac или, наоборот, запускать различные операционные системы в отдельных окнах на вашем компьютере.

Тестирование: Можно безопасно тестировать новое или подозрительное программное обеспечение, не боясь навредить основной системе. Это особенно актуально для тестирования приложений на разных платформах (например, на Windows и Linux).

Изоляция и безопасность: ВМ создают изолированную среду. Если в виртуальной машине произойдет сбой или она заразится вирусом, это не повлияет на работу основной операционной системы.

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

Гибкость и масштабируемость: ВМ легко создать, настроить и перенести. Это позволяет компаниям быстро адаптироваться к меняющимся нагрузкам и легко масштабировать свои ресурсы.

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

Разберемся с каждым пунктом по отдельности.

В комментариях к одной из моих первых статей на Хабре мне было предложено написать статью про виртуальные машины.

Долго думал об этом, было много дел не располагающих к писательству, и вот собрался наконец.

Начну с остренького. В ИТ есть только одна настоящая система виртуальных машин. Это zVM. Всё остальное претендующее на это название на самом деле является системами виртуальных ... систем.

Давайте разбираться с котлетами и мухами.

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

Рынок серверных процессоров эволюционировал от универсальных решений первых поколений Intel Xeon Scalable до современных специализированных CPU пятого и шестого поколений с встроенными ускорителями. Понимание этой эволюции и правильная интерпретация характеристик процессоров становится критически важным навыком при построении облачной инфраструктуры.

Привет, Хабр! Сегодня познакомимся с Кибер Бэкапом 18 — новой версией нашей системы резервного копирования. Релиз у нас получился «увесистый» — мы обеспечили дальнейший рост производительности и масштабируемости системы, защиту новых и развитие возможностей защиты уже поддерживаемых источников данных, реализовали открытый API управления планами защиты, выполнили доработки в части интерфейса и управления системой, а также выпустили ознакомительную MVP‑версию Кибер Медиасервера.

Новая версия Debian 13 и релиз Proxmox VE 9.0 пришли почти одновременно, вызвав ажиотаж у клиентов. В статье рассказываем, как команда HOSTKEY адаптировала свои процессы, автоматизировала деплой и подготовила инфраструктуру под свежие релизы.

Случается, что виртуальной машине необходимо предоставить доступ к RAW сетевой карте с тегированным трафиком, не разделяя его на VLAN на уровне гипервизора. Например, такое требование есть у OPNsense(firewall и routing) и у контроллеров для отечественной виртуализации Basis Dynamix.

Расскажу, как сделать такой доступ.

486-й в кармане: как оживить MS-DOS на QEMU
Полный контроль над железом, цветной промпт и настройка Sound Blaster 16 — всё, что вы хотели знать о ретровиртуализации

Источник обложки (ужас как трудно подобрать хорошую обложку! так что не судите строго)

Если в качестве основной (или единственной) операционной системы используется Windows, самым быстрым и удобным способом начать пользоваться Ubuntu является использование встроенного ядра Linux прямо внутри Windows.
Эта функция, доступная в составе Windows, позволяет обойтись без гипервизора виртуальных машин и без настройки мультизагрузки (dual-boot, multi-boot). Ядро Linux запускается в лёгкой служебной виртуальной среде, основанной на компонентах Hyper-V, что обеспечивает минимальные накладные расходы и высокую производительность.
После установки выбранный дистрибутив Linux полностью интегрируется в систему Windows, позволяя разработчику пользоваться преимуществами обеих ОС с минимальными затратами — как аппаратными, так и временными.