Недавно ко мне в руки попал мини-пк Junibox K3+ и решил из него сделать домашний мини-сервер. Однако мне было лень тянуть новый провод для него, поэтому было решено подключить его с помощью WiFi. Оказалось, это не такая и тривиальная задача, как тыкнуть пару раз по нужным кнопкам, так как proxmox из коробки не приспособлен для работы беспровода. Я прочитал пару гайдов и готов поделиться полученными знаниями с такими же изыскателями.
Зачем эмулировать то, что можно купить за копейки? Тратить месяцы на создание виртуальной модели микроконтроллера, если реальная отладочная плата на базе GD32F303 стоит как пара чашек кофе? Ответ прост: хороший физический стенд — это не просто плата. Это проектирование, сборка, место в стойке, электропитание, обжиг кабелей и поддержка в рабочем состоянии. А самое главное — его часто нельзя раздать каждому разработчику. Но что, если можно запустить ту же прошивку, что и на реальном железе, в эмуляторе?
В этой статье я представляю результат работы нашей команды из отдела разработки встраиваемого ПО в YADRO. Наиболее полную на сегодняшний день модель SoC GD32F30X в QEMU и набор интерфейсов, которые делают взаимодействие с эмулируемой периферией «прозрачным» для хостовой системы.
Привет, Хабр! Я Виктор, в Хайстекс руковожу отделом разработки. Сегодня расскажу про фичу, которая снимает ложную дилемму «API или универсальность», потому что оба сценария можно применять параллельно.
При переносе виртуальных машин между облаками и частными контурами API-интеграция обычно даёт максимум автоматизации. Но как только целевых площадок становится больше одной-двух или появляется «собранная на коленке» платформа, выясняется, что у этой автоматизации есть цена. Миграция через API превращается в отдельный проект на недели разработки и тестирования. Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку.
Под катом — как сделать целевую сторону миграции воспроизводимой без зависимости от API конкретного облака и без ожидания поддержки со стороны платформы.
В Yandex Cloud наблюдается сетевая недоступность многих узлов в одной из зон.
Проблемы начались в 19:00 по Москве, по информации поддержки восстановление ожидается около 03:00.
Привет, Хабр!
В последнее время меня часто спрашивают (интересно, и кто эти люди) про Kubernetes и виртуализацию, точнее про разные варианты совмещения того и другого, и можно без хлеба в одном флаконе. Проще говоря, что лучше, интереснее и эффективнее: прикрутить к Kubernetes дополнительную фичу, например, KubeVirt, чтобы можно было с помощью оркестратора Kubernetes управлять не только контейнерами, но и виртуальными машинами, или же взять классическую среду виртуализации, управляющую виртуальными машинами, и добавить в нее Kubernetes для управления контейнеризированными приложениями. Вопрос непраздный, да к тому же непростой, поэтому давайте разбираться по порядку. За подробностями добро пожаловать под кат.
В какой момент логично перейти на выделенный сервер и что вы получите взамен? Рассказываем о реальных цифрах, архитектуре и плюсах перехода.
Как я построил полностью изолированную пентест-лабораторию и почему ИИ нельзя доверять
Уже месяц я изучаю создание пентест-инструментов (назовем это так, чтобы с модерацией проблем не было :-)) по книге "Black Hat Go", и до недавних пор я тестировал малварь на своём хосте, ибо в них нет ничего опасного, это простейшие утилиты по типу TCP-сканера.
Значит, нужно построить свою виртуальную и изолированную лабу. В них должно быть минимум 3 машины: Windows 11 в роли жертвы, Ubuntu server lts в роли C2 сервака, и, конечно, классический Metasploitable2 опять же в роли жертвы.
Zabbix — отличный универсальный инструмент. Но как только виртуалок становится не 20, а 200, всё превращается в бесконечный тюнинг: поднял лимит PHP, подкинул кэш, вырубил логирование — и надеешься, что доживёт до утра. Мы проверили, где эта грань на самом деле проходит и как себя ведёт альтернатива — zVirt Metrics. В статье — архитектура, производительность и честные цифры из тестов. Материал будет полезен инженерам, которые держат на себе мониторинг виртуализации и хотят, чтобы всё работало из коробки и без плясок с бубном при росте числа инсталляций zVirt.
Привет, Хабр! Меня зовут Евгений Морогов, я руководитель центра продуктовой акселерации в «Газпром ЦПС». Я работаю в проекте по внедрению VR-технологий, и сегодня я расскажу о том, как мы создавали VR-тренажер по ликвидации инцидента газоводонефтепроявления (ГПНВ) на буровой.
ГНВП — один из самых опасных инцидентов на буровой. Отработка подобных ситуаций на полигонах и на физических тренажерах «вживую» осложняется рядом факторов, которые не позволяют закрыть все потребности в практической подготовке cпециалистов. Среди них высокая стоимость, сложное масштабирование, отсутствие обновлений и возможностей для совместной подготовки, высокие логистические затраты и ограниченность сценариев. Мы решили эти проблемы с помощью VR-тренажера, создав детальную цифровую копию буровой установки.
Если у вас есть похожие задачи, вам интересно, как VR-технологии могут помочь бизнесу или в обучении — этот материал для вас. В статье подробно расскажу, как устроен наш VR-тренажер, как он создавался, какие технические решения мы использовали и как работает наша математическая модель. А также поделюсь, какими были наши первые успехи «в полях».
Выполнение множества задач резервного копирования одновременно приводит к резкому росту потребления ресурсов процессора, памяти, дисковой подсистемы на хосте виртуализации. В статье рассмотрим, как использование аппаратных моментальных снимков СХД снижает влияние резервного копирования на производительность хоста виртуализации VMware и помогает не терять в производительности рабочих виртуальных машин.
Hypersphere OS делает ставку на другое: на простую и разнесённую по логическим функциональным слоям структуру, где системные компоненты, библиотеки, окружения и AI-модели работают как части одного набора инструментов и в согласии между собой.
Я — Алексей Веснин, системный архитектор, создатель HyperSphere — децентрализованной экосистемы для безопасного и цензуроустойчивого пространства. В IT с начала 90-х. Занимаюсь системным администрированием с уклоном в сети, безопасность и построение информационных систем, которые управляли собой сами и преподавал собственный курс в ЦКО «Специалист» при МГТУ им. Баумана и в других местах.
В этой статье, по мотивам выступления на DevOps Conf, расскажу, что мне пришлось переизобрести, чтобы сборка нового типа заработала, почему старые подходы не справились, и как выглядит дистрибутив, который не мешает сам себе.
«Администраторы делятся на три категории — тех, кто еще не делает бекапы, тех, кто уже делает, и тех, кто уже проверяет бекапы.»
Когда речь заходит о необходимости защиты данных сервисов и приложений, на ум в первую очередь приходит резервное копирование и репликация. Наличие копии вселяет ложное чувство уверенности: «у нас есть копия = мы в безопасности».
Здесь кроется ловушка: резервное копирование позволяет восстановиться после сбоев, которые легко распознать, например, от физических отказов — выхода из строя диска, случайного удаления тома, сбоя узла.
Этот гайд поможет быстро и без проблем развернуть 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 пользователей.
