Недавно сделал заметку про выделение памяти для VM, кратной 512Мб, а так же чётное количество процессоров. Оказывается этому есть вполне осмысленное обоснование и отражено оно в блоге vmware - https://blogs.vmware.com/performance/2017/03/virtual-machine-vcpu-and-vnuma-rightsizing-rules-of-thumb.html
Материал большой и насыщенный. Приведу только конечные выводы по оптимальному распределению RAM и CPU между виртуалками. Там есть нюансы, о которых лично я не знал. Рассматривается в том числе вопрос с сокетами. Части вижу вопросы на тему того, как распределить процессоры и сокеты в VM.
На основе статьи рекомендации будут следующие. Для примера взят хост:
▪ 2 сокета
▪ 10 ядер на сокет
▪ 40 логических процессоров
▪ 256 GB памяти, по 128 GB на сокет
Разбираем сначала виртуалки с количеством памяти меньше 128 GB. В
этом случае мы добавляем 1 сокет и максимум 10 vCPU. Как только процессоров нужно больше, чем есть на одном сокете, дальше мы добавляем только по чётным числам и делим на 2 сокета поровну. То есть должно быть 2 сокета, 6 vCPU на сокет, в сумме 12. Это будет оптимальная конфигурация для 12 vCPU. И так дальше до 20 ядер добавляем, деля их поровну между сокетами. Напоминаю, что это для виртуалок с памятью меньше чем 128 GB.
Если в виртуальную машину надо выделить более 128 GB памяти, арифметика будет другая. Нечётное количество ядер не используем вообще. Сокетов всегда добавляем два. То есть надо виртуалке 2 vCPU и 192 GB памяти. Делаем два сокета, в каждом по ядру и сколько надо памяти, кратно числу ядер.
Я не знаю, актуально ли это для всех систем виртуализации или только для vmware. Специально не узнавал, но подозреваю, что актуально везде, так как исходит из архитектуры самой платформы хоста.
Краткий вывод такой. Если на одну виртуальную машину условно приходится ресурсов не более, чем в рамках одного сокета (vNUMA, cpu + ram), то процессоров ставим любое число, сокет всегда один. Если на vm уходит больше ресурсов одного сокета, то надо делить процессоры равномерно по сокетам. Причем даже если процессоров всего 2, а памяти больше, чем достанется сокету, все равно vCPU разделяем на сокеты.
Такая вот арифметика. Спасибо читателю за ссылку. Сам я не знал таких подробностей и неизвестно когда узнал бы. А тут реклама заказывается, деньги платятся, посты пишутся. Никуда не деться 😁 Приходится учиться.
Заметку имеет смысл сохранить, чтобы потом не вспоминать, как оптимально выделять ресурсы большой vm.
#виртуализация
Материал большой и насыщенный. Приведу только конечные выводы по оптимальному распределению RAM и CPU между виртуалками. Там есть нюансы, о которых лично я не знал. Рассматривается в том числе вопрос с сокетами. Части вижу вопросы на тему того, как распределить процессоры и сокеты в VM.
На основе статьи рекомендации будут следующие. Для примера взят хост:
▪ 2 сокета
▪ 10 ядер на сокет
▪ 40 логических процессоров
▪ 256 GB памяти, по 128 GB на сокет
Разбираем сначала виртуалки с количеством памяти меньше 128 GB. В
этом случае мы добавляем 1 сокет и максимум 10 vCPU. Как только процессоров нужно больше, чем есть на одном сокете, дальше мы добавляем только по чётным числам и делим на 2 сокета поровну. То есть должно быть 2 сокета, 6 vCPU на сокет, в сумме 12. Это будет оптимальная конфигурация для 12 vCPU. И так дальше до 20 ядер добавляем, деля их поровну между сокетами. Напоминаю, что это для виртуалок с памятью меньше чем 128 GB.
Если в виртуальную машину надо выделить более 128 GB памяти, арифметика будет другая. Нечётное количество ядер не используем вообще. Сокетов всегда добавляем два. То есть надо виртуалке 2 vCPU и 192 GB памяти. Делаем два сокета, в каждом по ядру и сколько надо памяти, кратно числу ядер.
Я не знаю, актуально ли это для всех систем виртуализации или только для vmware. Специально не узнавал, но подозреваю, что актуально везде, так как исходит из архитектуры самой платформы хоста.
Краткий вывод такой. Если на одну виртуальную машину условно приходится ресурсов не более, чем в рамках одного сокета (vNUMA, cpu + ram), то процессоров ставим любое число, сокет всегда один. Если на vm уходит больше ресурсов одного сокета, то надо делить процессоры равномерно по сокетам. Причем даже если процессоров всего 2, а памяти больше, чем достанется сокету, все равно vCPU разделяем на сокеты.
Такая вот арифметика. Спасибо читателю за ссылку. Сам я не знал таких подробностей и неизвестно когда узнал бы. А тут реклама заказывается, деньги платятся, посты пишутся. Никуда не деться 😁 Приходится учиться.
Заметку имеет смысл сохранить, чтобы потом не вспоминать, как оптимально выделять ресурсы большой vm.
#виртуализация
Вчерашняя заметка про Proxmox вызвала бурные обсуждения в комментариях на тему использования различных гипервизоров. Звучали мнения, что Proxmox нафиг не нужен, так как есть бесплатный esxi.
Мне лично Proxmox нравится больше всего тем, что его можно установить на софтовый рейд mdadm. Это основное преимущество для меня. Кто-то любит zfs и поэтому использует Proxmox. Esxi, к примеру, вообще не поддерживает софтовые рейды, только железные и то не все. Но лично мне больше нравятся именно софтовые рейды, в частности mdadm. С ним меньше всего хлопот, у него очень предсказуемое и надежное поведение. Никогда не было с ним проблем.
Таким образом, Proxmox можно установить на любой самосбор с двумя дисками и получить вполне надежное решение, особенно если подобных самосборов будет несколько и они объединены в кластер. Удобно, когда и прод и тестовые машины одинаковые, а на тест можно что-то дешманское купить. Я активно эксплуатирую бюджетные двухдисковые сервера от Selectel и ставлю туда Proxmox на mdadm из готового шаблона. Ничего настраивать не надо. Заказал сервер и получил готовый Proxmox на софтовом RAID1.
Кстати, когда XenServer можно было тоже установить на mdadm, я использовал его. Мне очень нравился этот гипервизор за его удобное приложение под Windows для управления виртуалками. Прекратил использовать Xenserver с выходом 7-й версии, когда он перестал нормально устанавливаться и обновляться на mdadm. После этого перешёл на Proxmox. А сейчас с выходом Proxmox Backup Server у него вообще нет бесплатных альтернатив.
Иногда ставлю бесплатный Hyper-V Server, если предполагается использование виндовых серверов. У меня есть ни на чём не основанное мнение, что виндовые сервера лучше запускать на Hyper-V. Да и просто хлопот меньше с драйверами. Все сразу работает и поддерживается.
#виртуализация
Мне лично Proxmox нравится больше всего тем, что его можно установить на софтовый рейд mdadm. Это основное преимущество для меня. Кто-то любит zfs и поэтому использует Proxmox. Esxi, к примеру, вообще не поддерживает софтовые рейды, только железные и то не все. Но лично мне больше нравятся именно софтовые рейды, в частности mdadm. С ним меньше всего хлопот, у него очень предсказуемое и надежное поведение. Никогда не было с ним проблем.
Таким образом, Proxmox можно установить на любой самосбор с двумя дисками и получить вполне надежное решение, особенно если подобных самосборов будет несколько и они объединены в кластер. Удобно, когда и прод и тестовые машины одинаковые, а на тест можно что-то дешманское купить. Я активно эксплуатирую бюджетные двухдисковые сервера от Selectel и ставлю туда Proxmox на mdadm из готового шаблона. Ничего настраивать не надо. Заказал сервер и получил готовый Proxmox на софтовом RAID1.
Кстати, когда XenServer можно было тоже установить на mdadm, я использовал его. Мне очень нравился этот гипервизор за его удобное приложение под Windows для управления виртуалками. Прекратил использовать Xenserver с выходом 7-й версии, когда он перестал нормально устанавливаться и обновляться на mdadm. После этого перешёл на Proxmox. А сейчас с выходом Proxmox Backup Server у него вообще нет бесплатных альтернатив.
Иногда ставлю бесплатный Hyper-V Server, если предполагается использование виндовых серверов. У меня есть ни на чём не основанное мнение, что виндовые сервера лучше запускать на Hyper-V. Да и просто хлопот меньше с драйверами. Все сразу работает и поддерживается.
#виртуализация
У меня на днях спросили, как лучше организовать сеть на гипервизоре с одним внешним ip адресом для работы сайтов на виртуальной машине. Проблема тут очевидна, если адрес только один. Вам надо как-то управлять самим гипервизором и прочие службы сделать доступными по внешнему ip. Вариантов тут 2. Я в равной степени использую оба в зависимости от задач.
1️⃣ Более простой случай, особенно если у вас гипервизор на Linux. Сам гипервизор становится маршрутизатором для виртуальных машин. Настраиваете на нём firewall, nat и проброс нужных портов в виртуальные машины. В этом случае вообще не нужно трогать сетевые настройки на гипервизоре. Достаточно будет добавить один виртуальный интерфейс и подключать его виртуалкам. Через него они будут взаимодействовать с хостом.
Плюс тут очевиден - нет лишних сущностей, быстрая настройка. Есть значительный минус - у вас настройки хранятся на гипервизоре, что неудобно. Лучше, когда вся инфраструктура полностью в виртуалках, которые можно забэкапить и потом восстановить в том же виде на другом гипервизоре и всё сразу заработает. В этом же случае, придётся отдельно настраивать гипервизор.
2️⃣ Шлюзом для гипервизора и виртуальных машин выступает одна из виртуалок. Для подобной настройки на первое время понадобится прямой доступ через ip-kvm к консоли гипервизора, так как велика вероятность потери связи с хостом во время настройки. Когда я часто настраивал подобную схему, получалось всё провернуть быстро без потери связи, если нигде не ошибиться.
Для реализации вы делаете на хосте сетевой bridge, включая туда внешний интерфейс, на который приходит внешний ip. На самом гипервизоре настройки этого ip вообще не делаете. Также добавляете один виртуальный интерфейс.
Создаёте виртуалку, которая будет шлюзом. К ней подключаете бридж и виртуальный интерфейс. На бридже настраиваете внешний ip. На виртуалке какую-то локальную сеть для связи виртуальных машин и гипервизора. Далее настраиваете всё, что нужно обычному шлюзу - firewall, nat, проброс портов. Я обычно здесь же настраиваю vpn и proxy-nginx. По необходимости dhcp и dns.
Далее эту виртуальную машину делаете шлюзом по умолчанию для самого гипервизора и остальных виртуалок, используя адрес из локальной сети, настроенной на виртуальном интерфейсе. Важно не забыть добавить виртуалку со шлюзом в автозагрузку, чтобы после перезагрузки хоста не терять с ним связь.
В итоге у вас все важные настройки инфраструктуры окажутся на виртуальной машине и успешно забэкапятся. Потом всё разом можно настроить в любом другом месте. Достаточно будет только поменять сетевые настройки на новом гипервизоре.
3️⃣ Заказываете дополнительные адреса и не тратите время на сетевые настройки. Но если у вас инфраструктура будет состоять из нескольких гипервизоров и вам захочется их объединить по vpn, то отдельный шлюз все равно пригодится, даже если адресов в избытке.
Если реально заинтересовались второй схемой, то почитайте более подробное описание в статье. Я там прям на конкретном примере с реального гипервизора показываю, как это на практике выглядит.
#виртуализация
1️⃣ Более простой случай, особенно если у вас гипервизор на Linux. Сам гипервизор становится маршрутизатором для виртуальных машин. Настраиваете на нём firewall, nat и проброс нужных портов в виртуальные машины. В этом случае вообще не нужно трогать сетевые настройки на гипервизоре. Достаточно будет добавить один виртуальный интерфейс и подключать его виртуалкам. Через него они будут взаимодействовать с хостом.
Плюс тут очевиден - нет лишних сущностей, быстрая настройка. Есть значительный минус - у вас настройки хранятся на гипервизоре, что неудобно. Лучше, когда вся инфраструктура полностью в виртуалках, которые можно забэкапить и потом восстановить в том же виде на другом гипервизоре и всё сразу заработает. В этом же случае, придётся отдельно настраивать гипервизор.
2️⃣ Шлюзом для гипервизора и виртуальных машин выступает одна из виртуалок. Для подобной настройки на первое время понадобится прямой доступ через ip-kvm к консоли гипервизора, так как велика вероятность потери связи с хостом во время настройки. Когда я часто настраивал подобную схему, получалось всё провернуть быстро без потери связи, если нигде не ошибиться.
Для реализации вы делаете на хосте сетевой bridge, включая туда внешний интерфейс, на который приходит внешний ip. На самом гипервизоре настройки этого ip вообще не делаете. Также добавляете один виртуальный интерфейс.
Создаёте виртуалку, которая будет шлюзом. К ней подключаете бридж и виртуальный интерфейс. На бридже настраиваете внешний ip. На виртуалке какую-то локальную сеть для связи виртуальных машин и гипервизора. Далее настраиваете всё, что нужно обычному шлюзу - firewall, nat, проброс портов. Я обычно здесь же настраиваю vpn и proxy-nginx. По необходимости dhcp и dns.
Далее эту виртуальную машину делаете шлюзом по умолчанию для самого гипервизора и остальных виртуалок, используя адрес из локальной сети, настроенной на виртуальном интерфейсе. Важно не забыть добавить виртуалку со шлюзом в автозагрузку, чтобы после перезагрузки хоста не терять с ним связь.
В итоге у вас все важные настройки инфраструктуры окажутся на виртуальной машине и успешно забэкапятся. Потом всё разом можно настроить в любом другом месте. Достаточно будет только поменять сетевые настройки на новом гипервизоре.
3️⃣ Заказываете дополнительные адреса и не тратите время на сетевые настройки. Но если у вас инфраструктура будет состоять из нескольких гипервизоров и вам захочется их объединить по vpn, то отдельный шлюз все равно пригодится, даже если адресов в избытке.
Если реально заинтересовались второй схемой, то почитайте более подробное описание в статье. Я там прям на конкретном примере с реального гипервизора показываю, как это на практике выглядит.
#виртуализация
На днях в комментариях к заметке о KVM зашла речь об очень интересном продукте для виртуализации - Nutanix Community Edition. Я давно о нём знаю, ещё с 2014 года, когда впервые увидел статью на хабре про неё от одного из разработчиков. Правда в то время ещё не было бесплатной CE версии, поэтому можно было только почитать, но не попробовать. Продукт стоил немалых денег.
Я узнал, что оказывается есть бесплатная Community версия, которую можно поставить у себя и попробовать. Объясню своими словами, что такое Nutanix. Это гиперконвергентное (не понимаю значение этого слова) решение, которое объединяет в себе вычислительные мощности и общее хранилище для построения распределённой системы виртуализации.
На пальцах это выглядит так. Вы берёте 4 сервера под 4 ноды. Разворачиваете на них кластер Nutanix с выбранным фактором репликации. Он объединяет все процессоры, память и диски в единое пространство. И вы в рамках этого кластера создаёте виртуальные машины, не привязываясь к конкретной ноде. Если у вас выходит из строя один из серверов, вам достаточно будет перезапустить виртуальные машины, которые на нём жили, и они будут подняты на оставшихся нодах кластера. Всё управление происходит через единую панель.
На практике установка Nutanix выглядит следующим образом. Вам нужно зарегистрироваться у них на сайте. При этом почтовые ящики публичных сервисов не принимаются (gmail, msn и т.д.), нужно использовать корпоративный. После регистрации получаете ссылки на ISO образы. Их можно установить на железо, либо виртуальные машины других гипервизоров. Далее создаёте кластер или используете в режиме одиночной ноды. Так тоже можно.
Nutanix использует свой гипервизор AHV. Причём этот гипервиpор поддерживает Veeam. Вы можете использовать его для бэкапа кластера Nutanix. Важной особенностью бесплатной версии является то, что она должна иметь доступ через интернет к серверам разработчиков. Если она 30 дней их не видит, то доступ к панели управления блокируется. Виртуальные машины при этом остаются работать. Подобное ограничение не только в современных, но и любых условиях делает использование этой системы очень спорным.
Я как-то раз столкнулся с неприятной ситуацией с XenServer. В версии до 6-й и 7-й в бесплатной версии гипервизора нужно было раз в год продлевать лицензию запросом специального файла. Это было бесплатно. Но в определённый момент Citrix решили, что людей пора согнать со старых версий, и они просто закрыли этот сервис по продлению лицензий. Пришлось срочно мигрировать. С тех пор моё доверие к XenServer сильно упало и я постепенно отказался от него.
Я видел в комментариях отзывы тех, кто использует Nutanix CE в проде. Мне интересно, вам не стрёмно с такими условиями им пользоваться? По функционалу всё выглядит очень круто, причём не только на бумаге, но и на практике. Продукт уже известный и проверенный.
#виртуализация
Я узнал, что оказывается есть бесплатная Community версия, которую можно поставить у себя и попробовать. Объясню своими словами, что такое Nutanix. Это гиперконвергентное (не понимаю значение этого слова) решение, которое объединяет в себе вычислительные мощности и общее хранилище для построения распределённой системы виртуализации.
На пальцах это выглядит так. Вы берёте 4 сервера под 4 ноды. Разворачиваете на них кластер Nutanix с выбранным фактором репликации. Он объединяет все процессоры, память и диски в единое пространство. И вы в рамках этого кластера создаёте виртуальные машины, не привязываясь к конкретной ноде. Если у вас выходит из строя один из серверов, вам достаточно будет перезапустить виртуальные машины, которые на нём жили, и они будут подняты на оставшихся нодах кластера. Всё управление происходит через единую панель.
На практике установка Nutanix выглядит следующим образом. Вам нужно зарегистрироваться у них на сайте. При этом почтовые ящики публичных сервисов не принимаются (gmail, msn и т.д.), нужно использовать корпоративный. После регистрации получаете ссылки на ISO образы. Их можно установить на железо, либо виртуальные машины других гипервизоров. Далее создаёте кластер или используете в режиме одиночной ноды. Так тоже можно.
Nutanix использует свой гипервизор AHV. Причём этот гипервиpор поддерживает Veeam. Вы можете использовать его для бэкапа кластера Nutanix. Важной особенностью бесплатной версии является то, что она должна иметь доступ через интернет к серверам разработчиков. Если она 30 дней их не видит, то доступ к панели управления блокируется. Виртуальные машины при этом остаются работать. Подобное ограничение не только в современных, но и любых условиях делает использование этой системы очень спорным.
Я как-то раз столкнулся с неприятной ситуацией с XenServer. В версии до 6-й и 7-й в бесплатной версии гипервизора нужно было раз в год продлевать лицензию запросом специального файла. Это было бесплатно. Но в определённый момент Citrix решили, что людей пора согнать со старых версий, и они просто закрыли этот сервис по продлению лицензий. Пришлось срочно мигрировать. С тех пор моё доверие к XenServer сильно упало и я постепенно отказался от него.
Я видел в комментариях отзывы тех, кто использует Nutanix CE в проде. Мне интересно, вам не стрёмно с такими условиями им пользоваться? По функционалу всё выглядит очень круто, причём не только на бумаге, но и на практике. Продукт уже известный и проверенный.
#виртуализация
На днях упоминал про систему организации виртуальных рабочих мест Termidesk. Сегодня расскажу о ней подробнее. Это российское программное обеспечение, включённое в реестр отечественного ПО. С его помощью реализуется функционал диспетчера удалённых подключений к виртуальным машинам под управлением операционных систем Linux и Windows.
Termidesk поддерживает следующие системы виртуализации: ПК СВ «Брест», zVirt, VMware, Aerodisk vAir, oVirt, Openstack и некоторые другие. То есть это универсальный продукт под разные системы виртуализации, с которыми он работает через плагины расширения.
В качестве гостевых систем для рабочих мест могут использоваться Windows 7,8,10, Windows Server, Astra Linux, Alt Linux, Debian, Ubuntu, CentOS. Для взаимодействия с Termidesk в операционные системы устанавливается агент.
Подключение к рабочим местам может осуществляться через различные протоколы. Если в системе есть RDP, то можно через него. Также поддерживается протокол SPICE, через который можно подключаться к экрану виртуальной машины. Этот протокол взаимодействия напрямую с гипервизором. Через него в том числе работает проброс usb устройств, работа мультимедиа (usb камер и микрофонов). То есть удалённое рабочее место можно использовать для полноценного общения.
Ещё один вариант подключения - через termidesk viewer. Если я правильно понял, то он использует взаимодействие с установленным агентом. Все эти подключения можно устанавливать как через браузер, так и через клиент, который представляет из себя приложение для операционной системы.
В качестве авторизации поддерживается множество популярных механизмов: локальная БД, MS Active Directory, LDAP/OpenLDAP, FreeIPA, Astra Linux Directory, IP адреса. Устанавливается Termidesk просто. Это обычный deb пакет для бесплатной ОС Astra Linux Common Edition, либо платной Astra Linux Special Edition. После установки из пакета, управление и настройка осуществляются через браузер.
В настоящее время Termidesk предлагает бесплатно лицензию на 4 конкурентных соединения с пользовательских рабочих станций. Получить её можно только вручную, отправив запрос через специальную форму на сайте. Платная версия лицензируется либо по количеству пользователей, либо по количеству одновременных соединений. Стоит от 5000 р. за пользователя, и от 9000 р. за соединение. Это стоимость за год. Цены смотрел в softline.
Посмотреть, как Termidesk работает на практике со стороны пользователя можно с помощью demo - https://termidesk.ru/vdi-demo, учётка termidesk1 / termidesk1. Можно как через браузер заходить, так и клиент себе поствить.
❗️Обращаю внимание, что через demo доступны несколько версий полноценных операционных систем с выходом в интернет. Там есть в том числе и браузеры. Можно использовать их в различных целях. Только не надо заниматься каким-то вредительством. Наверняка все подключения логируются. Если какие-то вредители начнут гадости делать, то демо скорее всего закроют. После завершения сеанса все изменения удаляются. Заново подключается уже эталонный образ.
Сайт - https://termidesk.ru/
Реестр ПО - https://reestr.digital.gov.ru/reestr/306667/
#vdi #отечественное #виртуализация
Termidesk поддерживает следующие системы виртуализации: ПК СВ «Брест», zVirt, VMware, Aerodisk vAir, oVirt, Openstack и некоторые другие. То есть это универсальный продукт под разные системы виртуализации, с которыми он работает через плагины расширения.
В качестве гостевых систем для рабочих мест могут использоваться Windows 7,8,10, Windows Server, Astra Linux, Alt Linux, Debian, Ubuntu, CentOS. Для взаимодействия с Termidesk в операционные системы устанавливается агент.
Подключение к рабочим местам может осуществляться через различные протоколы. Если в системе есть RDP, то можно через него. Также поддерживается протокол SPICE, через который можно подключаться к экрану виртуальной машины. Этот протокол взаимодействия напрямую с гипервизором. Через него в том числе работает проброс usb устройств, работа мультимедиа (usb камер и микрофонов). То есть удалённое рабочее место можно использовать для полноценного общения.
Ещё один вариант подключения - через termidesk viewer. Если я правильно понял, то он использует взаимодействие с установленным агентом. Все эти подключения можно устанавливать как через браузер, так и через клиент, который представляет из себя приложение для операционной системы.
В качестве авторизации поддерживается множество популярных механизмов: локальная БД, MS Active Directory, LDAP/OpenLDAP, FreeIPA, Astra Linux Directory, IP адреса. Устанавливается Termidesk просто. Это обычный deb пакет для бесплатной ОС Astra Linux Common Edition, либо платной Astra Linux Special Edition. После установки из пакета, управление и настройка осуществляются через браузер.
В настоящее время Termidesk предлагает бесплатно лицензию на 4 конкурентных соединения с пользовательских рабочих станций. Получить её можно только вручную, отправив запрос через специальную форму на сайте. Платная версия лицензируется либо по количеству пользователей, либо по количеству одновременных соединений. Стоит от 5000 р. за пользователя, и от 9000 р. за соединение. Это стоимость за год. Цены смотрел в softline.
Посмотреть, как Termidesk работает на практике со стороны пользователя можно с помощью demo - https://termidesk.ru/vdi-demo, учётка termidesk1 / termidesk1. Можно как через браузер заходить, так и клиент себе поствить.
❗️Обращаю внимание, что через demo доступны несколько версий полноценных операционных систем с выходом в интернет. Там есть в том числе и браузеры. Можно использовать их в различных целях. Только не надо заниматься каким-то вредительством. Наверняка все подключения логируются. Если какие-то вредители начнут гадости делать, то демо скорее всего закроют. После завершения сеанса все изменения удаляются. Заново подключается уже эталонный образ.
Сайт - https://termidesk.ru/
Реестр ПО - https://reestr.digital.gov.ru/reestr/306667/
#vdi #отечественное #виртуализация
В комментариях в заметке про VDI со мной поделились классным софтом - PVE-VDIClient. Это простой клиент на Python, с помощью которого можно напрямую подключаться к виртуальным машинам PVE по протоколу SPICE. Не нужен никакой дополнительный софт, типа RDP или VNC. Вы напрямую подключаетесь к консоли виртуальной машины.
Для чего это может понадобиться? Например, у вас есть Raspberry Pi и вы хотите сделать тонкий клиент для работы в ОС Windows с пробросом микрофона, камеры и звука. Вот подробное видео реализации:
⇨ https://www.youtube.com/watch?v=TuDrmq4RQzU
Я вчера потратил несколько часов, пока не разобрался полностью как это работает. В итоге запустил PVE-VDIClient на Windows 10 и 11. Рассказываю по шагам, что нужно сделать.
1️⃣ Добавляем в PVE новых пользователей и отдельную группу для них. Назначаем этой группе права доступа: VM.PowerMgmt, VM.Console, VM.Audit. Можно на конкретные виртуальные машины или на все сразу.
2️⃣ Виртуальным машинам, к которым будем подключаться по SPICE, в настройках указываем Display: SPICE и добавляем ещё один USB Device: Spice Port.
3️⃣ На ОС Windows, с которой будем подключаться, устанавливаем Python 3.10. Я установил через Microsoft Store. Далее идём в репозиторий, скачиваем файл requirements.bat и запускаем его. Либо просто вручную установите pip пакеты, которые там указаны.
4️⃣ Далее скачиваем virt-viewer под Windows и устанавливаем. После этого идём в releases и скачиваем последнюю версию PVE VDI client, устанавливаем.
5️⃣ В директорию C:\Program Files\VDIClient кладём файл vdiclient.ini, образец которого есть в репозитории под именем vdiclient.ini.example (example удаляем). Тут важно сделать несколько настроек, без которых у меня ничего не работало.
В разделе [Hosts] пишем адрес своего гипервизора и его порт 8006:
В разделе [SpiceProxyRedirect] редактируем параметр:
prox.zeroxzed.ru - имя хоста, которое можно посмотреть в веб интерфейсе, в разделе System ⇨ Hosts. В инструкции нигде не указано, что нужно это сделать, а дефолтная запись выглядит вот так:
Попробуй тут догадайся, что надо написать.
В разделе [Authentication] есть параметр auth_backend. По умолчанию он имеет значение:
Если поменять его на
Сможете подключаться дефолтной учёткой root, под которой заходите в веб интерфейс. Если это ваш тестовый гипервзиор, то логичнее поступить именно так и не создавать отдельных пользователей.
6️⃣ Теперь можно запускать VDI клиент, подключаться к гипервизору под созданной учётной записью и запускать виртуальную машину. Для увеличения быстродействия и лучшей работы с видео, в гостевые ОС рекомендуется установить SPICE guest tools. Но и без них всё будет работать.
Получилась готовая инструкция, которой в сети нет. Так что если вам интересна эта тема, сохраните к себе. Мне лично очень понравилось. Работать с виртуальными машинами так гораздо удобнее, чем по SSH или RDP. Можно спокойно добавить к машине несколько мониторов и переключаться между ними. В видео, которое я показал выше, автор демонстрирует такую возможность.
Полезные ссылки, которые пригодились в процессе настройки:
Исходники - https://github.com/joshpatten/PVE-VDIClient
Virt-manager - https://virt-manager.org/download/
Spice-guest-tools - https://www.spice-space.org/download.html
PVE SPICE - https://pve.proxmox.com/wiki/SPICE
Raspberry Pi THIN CLIENT for Proxmox VMs -
https://www.youtube.com/watch?v=TuDrmq4RQzU
#vdi #proxmox #виртуализация
Для чего это может понадобиться? Например, у вас есть Raspberry Pi и вы хотите сделать тонкий клиент для работы в ОС Windows с пробросом микрофона, камеры и звука. Вот подробное видео реализации:
⇨ https://www.youtube.com/watch?v=TuDrmq4RQzU
Я вчера потратил несколько часов, пока не разобрался полностью как это работает. В итоге запустил PVE-VDIClient на Windows 10 и 11. Рассказываю по шагам, что нужно сделать.
1️⃣ Добавляем в PVE новых пользователей и отдельную группу для них. Назначаем этой группе права доступа: VM.PowerMgmt, VM.Console, VM.Audit. Можно на конкретные виртуальные машины или на все сразу.
2️⃣ Виртуальным машинам, к которым будем подключаться по SPICE, в настройках указываем Display: SPICE и добавляем ещё один USB Device: Spice Port.
3️⃣ На ОС Windows, с которой будем подключаться, устанавливаем Python 3.10. Я установил через Microsoft Store. Далее идём в репозиторий, скачиваем файл requirements.bat и запускаем его. Либо просто вручную установите pip пакеты, которые там указаны.
4️⃣ Далее скачиваем virt-viewer под Windows и устанавливаем. После этого идём в releases и скачиваем последнюю версию PVE VDI client, устанавливаем.
5️⃣ В директорию C:\Program Files\VDIClient кладём файл vdiclient.ini, образец которого есть в репозитории под именем vdiclient.ini.example (example удаляем). Тут важно сделать несколько настроек, без которых у меня ничего не работало.
В разделе [Hosts] пишем адрес своего гипервизора и его порт 8006:
10.20.1.2 = 8006В разделе [SpiceProxyRedirect] редактируем параметр:
prox.zeroxzed.ru:3128 = 10.20.1.2:3128prox.zeroxzed.ru - имя хоста, которое можно посмотреть в веб интерфейсе, в разделе System ⇨ Hosts. В инструкции нигде не указано, что нужно это сделать, а дефолтная запись выглядит вот так:
pve1.example.com:3128 = 123.123.123.123:6000Попробуй тут догадайся, что надо написать.
В разделе [Authentication] есть параметр auth_backend. По умолчанию он имеет значение:
auth_backend = pveЕсли поменять его на
auth_backend = pamСможете подключаться дефолтной учёткой root, под которой заходите в веб интерфейс. Если это ваш тестовый гипервзиор, то логичнее поступить именно так и не создавать отдельных пользователей.
6️⃣ Теперь можно запускать VDI клиент, подключаться к гипервизору под созданной учётной записью и запускать виртуальную машину. Для увеличения быстродействия и лучшей работы с видео, в гостевые ОС рекомендуется установить SPICE guest tools. Но и без них всё будет работать.
Получилась готовая инструкция, которой в сети нет. Так что если вам интересна эта тема, сохраните к себе. Мне лично очень понравилось. Работать с виртуальными машинами так гораздо удобнее, чем по SSH или RDP. Можно спокойно добавить к машине несколько мониторов и переключаться между ними. В видео, которое я показал выше, автор демонстрирует такую возможность.
Полезные ссылки, которые пригодились в процессе настройки:
Исходники - https://github.com/joshpatten/PVE-VDIClient
Virt-manager - https://virt-manager.org/download/
Spice-guest-tools - https://www.spice-space.org/download.html
PVE SPICE - https://pve.proxmox.com/wiki/SPICE
Raspberry Pi THIN CLIENT for Proxmox VMs -
https://www.youtube.com/watch?v=TuDrmq4RQzU
#vdi #proxmox #виртуализация
Последние заметки про VDI (Virtual Desktop Infrastructure,) породили много вопросов в комментариях на тему того, зачем всё это нужно, если есть протокол RDP для удалённой работы. Во-первых, системы VDI не противопоставляют себя каким-то другим доступам. Более того, они чаще всего включают в себя поддержку и RDP соединений и многих других (VNC, SPICE). Во-вторых, если и сравнивать VDI, то с Remote Desktop Services (RDS) в составе Windows Server.
Например, есть бесплатное решение OpenUDS для организации VDI. Вот его основные возможности:
◽ Поддержка open source платформ виртуализации: oVirt, OpenNebula, Open Stack, XCP-ng, Proxmox, а также платных: Citrix Hypervisor, Microsoft Hyper-V, Nutanix Acropolis, VMware.
◽ Поддержка протоколов доставки рабочего стола: RDP (в том числе через HTML5), X2Go, SPICE (только для QEMU).
◽ Поддержка аутентификации: LDAP (в том числе MS AD), IP/mac-адреса, внутренняя БД, Radius.
◽ Клиенты Linux и Windows для подключений.
Как это выглядит на практике. Вы берёте гипервизоры Proxmox, можно кластер. Настраиваете OpenUDS и подключаете через провайдера гипервизоры к системе. Настраиваете ту или иную аутентификацию пользователей, создаёте их. Готовите шаблоны операционных систем. Настраиваете поведение тех или иных систем. Например, при отключении пользователя система может уничтожаться, а при подключении разворачиваться заново из шаблона. Либо сделать постоянные рабочие места с сохранением состояния.
Далее создаёте транспорт в виде различных протоколов доступа к системам и связываете из с пользователями. Кто-то будет подключаться по RDP, кто-то по X2Go, кто-то по SPICE. Пользователю на компьютер устанавливается openuds-client, с помощью которого он подключается к системам, к которым имеет доступ. Это объяснение на пальцах, как принципе всё работает.
❓Зачем может пригодиться подключение по SPICE, если есть RDP? Во первых, SPICE работает на уровне гипервизора. У вас всегда будет доступ к VM. В теории SPICE умеет работать с видеокартами на хосте, он умеет адекватно обрабатывать видео, прокидывать видеокамеру, микрофон. С его помощью можно организовать полноценное удалённое рабочее место того же дизайнера или проектировщика. Это в теории, на практике там наверняка много нюансов и надо разбираться. Скорее всего не всё и не везде поддерживается. Разработчики Termidesk рассказывали, что они дорабатывали SPICE самостоятельно, чтобы он нормально работал c видеокартами и жал видеопоток от камеры. По умолчанию он этого не делает, поэтому нужен широкий канал для нормальной картинки.
Очень подробное описание и настройка OpenUDS:
⇨ https://www.altlinux.org/VDI/OpenUDS
Я изучил инструкцию. На вид всё довольно просто и логично настраивается. В основном через веб интерфейс. Есть возможность поднять HA кластер:
⇨ https://www.altlinux.org/OpenUDS_HA
Хочу отметить, что у команды altlinux очень хорошие подробные руководства, по которым зачастую копипастом можно настроить.
Для бесплатного продукта очень приличный функционал. Первое, что приходит в голову, где это точно пригодится, даже если нет больших масштабов - учебные классы. Понятно, что обычных офисных сотрудников проще на RDS посадить, но не забываем, что это стоит приличных денег, если мы работаем в белую.
#vdi #виртуализация
Например, есть бесплатное решение OpenUDS для организации VDI. Вот его основные возможности:
◽ Поддержка open source платформ виртуализации: oVirt, OpenNebula, Open Stack, XCP-ng, Proxmox, а также платных: Citrix Hypervisor, Microsoft Hyper-V, Nutanix Acropolis, VMware.
◽ Поддержка протоколов доставки рабочего стола: RDP (в том числе через HTML5), X2Go, SPICE (только для QEMU).
◽ Поддержка аутентификации: LDAP (в том числе MS AD), IP/mac-адреса, внутренняя БД, Radius.
◽ Клиенты Linux и Windows для подключений.
Как это выглядит на практике. Вы берёте гипервизоры Proxmox, можно кластер. Настраиваете OpenUDS и подключаете через провайдера гипервизоры к системе. Настраиваете ту или иную аутентификацию пользователей, создаёте их. Готовите шаблоны операционных систем. Настраиваете поведение тех или иных систем. Например, при отключении пользователя система может уничтожаться, а при подключении разворачиваться заново из шаблона. Либо сделать постоянные рабочие места с сохранением состояния.
Далее создаёте транспорт в виде различных протоколов доступа к системам и связываете из с пользователями. Кто-то будет подключаться по RDP, кто-то по X2Go, кто-то по SPICE. Пользователю на компьютер устанавливается openuds-client, с помощью которого он подключается к системам, к которым имеет доступ. Это объяснение на пальцах, как принципе всё работает.
❓Зачем может пригодиться подключение по SPICE, если есть RDP? Во первых, SPICE работает на уровне гипервизора. У вас всегда будет доступ к VM. В теории SPICE умеет работать с видеокартами на хосте, он умеет адекватно обрабатывать видео, прокидывать видеокамеру, микрофон. С его помощью можно организовать полноценное удалённое рабочее место того же дизайнера или проектировщика. Это в теории, на практике там наверняка много нюансов и надо разбираться. Скорее всего не всё и не везде поддерживается. Разработчики Termidesk рассказывали, что они дорабатывали SPICE самостоятельно, чтобы он нормально работал c видеокартами и жал видеопоток от камеры. По умолчанию он этого не делает, поэтому нужен широкий канал для нормальной картинки.
Очень подробное описание и настройка OpenUDS:
⇨ https://www.altlinux.org/VDI/OpenUDS
Я изучил инструкцию. На вид всё довольно просто и логично настраивается. В основном через веб интерфейс. Есть возможность поднять HA кластер:
⇨ https://www.altlinux.org/OpenUDS_HA
Хочу отметить, что у команды altlinux очень хорошие подробные руководства, по которым зачастую копипастом можно настроить.
Для бесплатного продукта очень приличный функционал. Первое, что приходит в голову, где это точно пригодится, даже если нет больших масштабов - учебные классы. Понятно, что обычных офисных сотрудников проще на RDS посадить, но не забываем, что это стоит приличных денег, если мы работаем в белую.
#vdi #виртуализация
Не раз получал просьбу кратко описать современные гипервизоры. Просьба логична и понятна. Если плотно с этим не работаешь, то не очевидно, как выбрать подходящую виртуализацию. А выбирать есть из чего. Расскажу своими словами на основе опыта, что есть у меня. Это будет полностью субъективный текст в масштабах малого и среднего бизнеса, не претендующий на истину.
📌 VMware. Начну с явного и очевидного лидера, с которым у меня опыта не так много. Гипервизор от этой компании наиболее функционален и распространён в крупном бизнесе. Я видел и в среднем крякнутые версии. Есть бесплатная версия гипервизора, у которой в разное время были разные ограничения, но в любом случае она всегда была только для одиночного хоста.
➖ Главный минус VMware для меня - нельзя установить на программный рейд. И для железных рейдов надо проверять поддержку, как и для некоторого вида железа. Под капотом там модифицированный Linux, так что есть некоторые неудобства по сравнению с гипервизорами, где используется стандартный Linux дистрибутив в основе.
➕ Плюс - можно бэкапить с помощью Veeam, но только платную версию.
📌 Hyper-V. Лично мне всегда нравился и нравится этот гипервизор. В основе бесплатной версии лежит стандартный Windows Server Core. Работать с ним удобно и понятно, хотя есть некоторые нюансы, связанные с установкой оснасток на системы для управления. Частично этот вопрос закрывает Windows Admin Center, который позволяет управлять гипервизором через браузер.
➖ Cущественных минусов я даже не припомню, кроме невозможности пробросить USB устройство.
➕ Из плюсов, как я у же сказал - стандартная Windows система. Надо передать какой-то iso или файл на гипервизор - расшариваем папку и кладём файл. То же самое, если надо забрать что-то, например виртуальный диск. Поддерживает софтовые рейды, а также встроенные от intel. Хотя надёжность там так себе, я бы не советовал. Можно бэкапить с помощью Veeam.
📌 KVM. Важная ремарка, чтобы предупредить комментарии на эту тему. KVM - это модуль ядра Linux, который обеспечивает аппаратную виртуализацию и сам по себе гипервизором не является, но для простоты его так называют. Чаще всего он является частью готовых систем виртуализации, таких как RHV, oVirt, Proxmox, Qemu и т.д. Я использовал KVM с управлением через консоль с помощью virsh, с помощью графического интерфейса virt-manager. А последние года 3-4 в составе гипервизора Proxmox, когда он полностью созрел и завоевал популярность. На заре моего использования KVM это было не так.
Про плюсы и минусы KVM скажу в контексте Proxmox VE, так как использую его только в таком виде.
➕ Из плюсов это полная бесплатность и возможность собрать кластер даже в бесплатной версии. Есть встроенные средства для бэкапов, причём довольно функциональные, с инкрементными бэкапами. Под капотом почти обычный Linux, так что вы не ограничены в управлении, мониторинге, установке на mdadm и т.д. Поддерживается всё железо, которое поддерживает Linux.
➖ Из минусов лично мне больше всего не нравится, что в Veeam нет поддержки KVM.
📌 XenServer. Использовал этот бесплатный гипервизор очень плотно, пока не набрал популярность Proxmox VE. Он был один из первых с хорошим функционалом и простой настройкой.
➕ Из плюсов то, что под капотом был почти стандартный Centos со всеми вытекающими преимуществами. Также очень удобная консоль управления под Windows. Лично мне она даже сейчас кажется максимально удобной для управления среди всех известных гипервизоров. На момент использования (2010-2015 г) был бесплатный софт для бэкапа Xen с поддержкой дедупликации и инкрементных бэкапов.
➖ Минус в лицензии, которую нужно было получать отдельно. В какой-то момент поддержку старых версий бесплатных гипервизоров отключили просто закрыв этот сервис. Я с тех пор с XenServer и попрощался. Также в одной из версий пропала возможность поставить гипервизор на mdadm, что тоже отбило желание использовать этот гипервизор. Сейчас я знаю, что на базе Xen есть XCP-ng, но мне уже особо не нужно. Пробовал его, но пользоваться не стал. Устраивает Proxmox VE.
#виртуализация
📌 VMware. Начну с явного и очевидного лидера, с которым у меня опыта не так много. Гипервизор от этой компании наиболее функционален и распространён в крупном бизнесе. Я видел и в среднем крякнутые версии. Есть бесплатная версия гипервизора, у которой в разное время были разные ограничения, но в любом случае она всегда была только для одиночного хоста.
➖ Главный минус VMware для меня - нельзя установить на программный рейд. И для железных рейдов надо проверять поддержку, как и для некоторого вида железа. Под капотом там модифицированный Linux, так что есть некоторые неудобства по сравнению с гипервизорами, где используется стандартный Linux дистрибутив в основе.
➕ Плюс - можно бэкапить с помощью Veeam, но только платную версию.
📌 Hyper-V. Лично мне всегда нравился и нравится этот гипервизор. В основе бесплатной версии лежит стандартный Windows Server Core. Работать с ним удобно и понятно, хотя есть некоторые нюансы, связанные с установкой оснасток на системы для управления. Частично этот вопрос закрывает Windows Admin Center, который позволяет управлять гипервизором через браузер.
➖ Cущественных минусов я даже не припомню, кроме невозможности пробросить USB устройство.
➕ Из плюсов, как я у же сказал - стандартная Windows система. Надо передать какой-то iso или файл на гипервизор - расшариваем папку и кладём файл. То же самое, если надо забрать что-то, например виртуальный диск. Поддерживает софтовые рейды, а также встроенные от intel. Хотя надёжность там так себе, я бы не советовал. Можно бэкапить с помощью Veeam.
📌 KVM. Важная ремарка, чтобы предупредить комментарии на эту тему. KVM - это модуль ядра Linux, который обеспечивает аппаратную виртуализацию и сам по себе гипервизором не является, но для простоты его так называют. Чаще всего он является частью готовых систем виртуализации, таких как RHV, oVirt, Proxmox, Qemu и т.д. Я использовал KVM с управлением через консоль с помощью virsh, с помощью графического интерфейса virt-manager. А последние года 3-4 в составе гипервизора Proxmox, когда он полностью созрел и завоевал популярность. На заре моего использования KVM это было не так.
Про плюсы и минусы KVM скажу в контексте Proxmox VE, так как использую его только в таком виде.
➕ Из плюсов это полная бесплатность и возможность собрать кластер даже в бесплатной версии. Есть встроенные средства для бэкапов, причём довольно функциональные, с инкрементными бэкапами. Под капотом почти обычный Linux, так что вы не ограничены в управлении, мониторинге, установке на mdadm и т.д. Поддерживается всё железо, которое поддерживает Linux.
➖ Из минусов лично мне больше всего не нравится, что в Veeam нет поддержки KVM.
📌 XenServer. Использовал этот бесплатный гипервизор очень плотно, пока не набрал популярность Proxmox VE. Он был один из первых с хорошим функционалом и простой настройкой.
➕ Из плюсов то, что под капотом был почти стандартный Centos со всеми вытекающими преимуществами. Также очень удобная консоль управления под Windows. Лично мне она даже сейчас кажется максимально удобной для управления среди всех известных гипервизоров. На момент использования (2010-2015 г) был бесплатный софт для бэкапа Xen с поддержкой дедупликации и инкрементных бэкапов.
➖ Минус в лицензии, которую нужно было получать отдельно. В какой-то момент поддержку старых версий бесплатных гипервизоров отключили просто закрыв этот сервис. Я с тех пор с XenServer и попрощался. Также в одной из версий пропала возможность поставить гипервизор на mdadm, что тоже отбило желание использовать этот гипервизор. Сейчас я знаю, что на базе Xen есть XCP-ng, но мне уже особо не нужно. Пробовал его, но пользоваться не стал. Устраивает Proxmox VE.
#виртуализация
Ко мне недавно поступило необычное предложение. Китайские представители компании Vinchin захотели опубликовать на сайте обзор их продукта Vinchin Backup & Recovery. Ранее я ничего о нём не слышал и не знал. Стало любопытно, что это вообще такое. Оказывается, это решение для бэкапа мультивендорной виртуализации.
Обычно я пишу статьи сам, но тут впервые пришлось общаться с китайцами, для которых русский явно не родной, а общение было судя по всему через переводчик. Поэтому решил не рисковать и попросил готовый текст, чтобы понять, что они вообще хотят получить в статье. Статья получилось вот такая:
⇨ https://serveradmin.ru/vinchin-backup-recovery-rezervnoe-kopirovanie-ovirt-i-xenserver-v-multi-hypervisor-srede/
Я выполнил только редактуру и адаптацию на русский язык, исправив явные несоответствия с русской лексикой. Но если прочитать статью, становится понятно, что её писал не русскоязычный человек.
А теперь непосредственно о Vinchin Backup & Recovery. Как можно догадаться из названия, продукт метит в ту же категорию, где находится Veeam Backup & Replication. И он действительно на него похож в общих чертах. Это тоже единый сервер для бэкапа виртуальных сред. Вот только список поддерживаемых гипервизоров у него значительно шире:
◽ VMware
◽ Hyper-V
◽ Citrix Hypervisor, XenServer и XCP-ng
◽ Red Hat Virtualization и oVirt
◽ OpenStack
◽ Sangfor HCI, Huawei FusionCompute (KVM), H3C CAS
К сожалению, чистого KVM или Proxmox в списке поддерживаемых платформ нет.
Vinchin Backup & Recovery поставляется в виде ISO образа на базе Centos 7. Установщик 1 в 1 от Centos, и ставится всё так же, как стандартная система. После установки всё управление и настройка выполняется через веб интерфейс.
Есть бесплатная версия, к сожалению, только для бэкапа 3 VM. Так что для практической эксплуатации вряд ли подойдёт, только для теста. Я решил посмотреть своими глазами, как всё это работает, хоть меня и не просили об этом. Установка никаких вопросов не вызвала. Развернул систему из образа и зашел через браузер.
Дальше тоже всё просто. Добавляем хранилище для бэкапов. Поддерживаются следующие типы: раздел диска, весь диск, локальная директория, lvm том, fibre channel, iscsi, nfs и cifs share. Я добавил локальную директорию. Далее добавляем хост виртуализации. У меня под рукой был Hyper-V, поэтому тестировал на нём. На гипервизор надо установить плагин, а потом добавить его в панель управления. Для этого достаточно указать адрес и админскую учётку.
А дальше получаем список VM и настраиваем задания бэкапа. Понравилась при создании задания карта загруженности хранилища по времени, чтобы было удобно расписание выбрать. В целом, всё просто и понятно. Даже в документацию лазить не пришлось, только дефолтную учётку посмотрел. Хотя уже потом заметил, что она была указана ещё в письме, которое прилетело со ссылкой для загрузки ISO.
Я сначала когда статью прочитал, подумал, что какой-то неполный кусок инструкции подготовили и решили опубликовать. А когда сам поставил и настроил, понял, что там реально почти ничего делать не надо. Всё сделано максимально просто и понятно. Даже удивился. Не ожидал от китайского продукта такой простоты.
Vinchin Backup & Recovery реально интересный продукт. Аналогов с поддержкой такого количества гипервизоров я не знаю. Они все популярные охватили. Причём можно сделать бэкап VM с одного гипервизора, а восстановить на другом. Насколько всё это надёжно работает, судить не могу. По ценам тоже не понятно. Их нет на сайте. Указано только, что есть бессрочные лицензии, а есть по подписке.
Есть русскоязычная версия сайта. Видел информацию в их группе VK, что они хотят работать на рынке РФ и СНГ, поэтому пишут поддержку российских систем виртуализации. Уже заявлена поддержка zVirt.
Чтобы попробовать, можно скачать либо 60-ти дневный триал, либо Free Edition. Если у кого-то есть опыт использования этого продукта, дайте обратную связь.
#backup #виртуализация
Обычно я пишу статьи сам, но тут впервые пришлось общаться с китайцами, для которых русский явно не родной, а общение было судя по всему через переводчик. Поэтому решил не рисковать и попросил готовый текст, чтобы понять, что они вообще хотят получить в статье. Статья получилось вот такая:
⇨ https://serveradmin.ru/vinchin-backup-recovery-rezervnoe-kopirovanie-ovirt-i-xenserver-v-multi-hypervisor-srede/
Я выполнил только редактуру и адаптацию на русский язык, исправив явные несоответствия с русской лексикой. Но если прочитать статью, становится понятно, что её писал не русскоязычный человек.
А теперь непосредственно о Vinchin Backup & Recovery. Как можно догадаться из названия, продукт метит в ту же категорию, где находится Veeam Backup & Replication. И он действительно на него похож в общих чертах. Это тоже единый сервер для бэкапа виртуальных сред. Вот только список поддерживаемых гипервизоров у него значительно шире:
◽ VMware
◽ Hyper-V
◽ Citrix Hypervisor, XenServer и XCP-ng
◽ Red Hat Virtualization и oVirt
◽ OpenStack
◽ Sangfor HCI, Huawei FusionCompute (KVM), H3C CAS
К сожалению, чистого KVM или Proxmox в списке поддерживаемых платформ нет.
Vinchin Backup & Recovery поставляется в виде ISO образа на базе Centos 7. Установщик 1 в 1 от Centos, и ставится всё так же, как стандартная система. После установки всё управление и настройка выполняется через веб интерфейс.
Есть бесплатная версия, к сожалению, только для бэкапа 3 VM. Так что для практической эксплуатации вряд ли подойдёт, только для теста. Я решил посмотреть своими глазами, как всё это работает, хоть меня и не просили об этом. Установка никаких вопросов не вызвала. Развернул систему из образа и зашел через браузер.
Дальше тоже всё просто. Добавляем хранилище для бэкапов. Поддерживаются следующие типы: раздел диска, весь диск, локальная директория, lvm том, fibre channel, iscsi, nfs и cifs share. Я добавил локальную директорию. Далее добавляем хост виртуализации. У меня под рукой был Hyper-V, поэтому тестировал на нём. На гипервизор надо установить плагин, а потом добавить его в панель управления. Для этого достаточно указать адрес и админскую учётку.
А дальше получаем список VM и настраиваем задания бэкапа. Понравилась при создании задания карта загруженности хранилища по времени, чтобы было удобно расписание выбрать. В целом, всё просто и понятно. Даже в документацию лазить не пришлось, только дефолтную учётку посмотрел. Хотя уже потом заметил, что она была указана ещё в письме, которое прилетело со ссылкой для загрузки ISO.
Я сначала когда статью прочитал, подумал, что какой-то неполный кусок инструкции подготовили и решили опубликовать. А когда сам поставил и настроил, понял, что там реально почти ничего делать не надо. Всё сделано максимально просто и понятно. Даже удивился. Не ожидал от китайского продукта такой простоты.
Vinchin Backup & Recovery реально интересный продукт. Аналогов с поддержкой такого количества гипервизоров я не знаю. Они все популярные охватили. Причём можно сделать бэкап VM с одного гипервизора, а восстановить на другом. Насколько всё это надёжно работает, судить не могу. По ценам тоже не понятно. Их нет на сайте. Указано только, что есть бессрочные лицензии, а есть по подписке.
Есть русскоязычная версия сайта. Видел информацию в их группе VK, что они хотят работать на рынке РФ и СНГ, поэтому пишут поддержку российских систем виртуализации. Уже заявлена поддержка zVirt.
Чтобы попробовать, можно скачать либо 60-ти дневный триал, либо Free Edition. Если у кого-то есть опыт использования этого продукта, дайте обратную связь.
#backup #виртуализация
Я давно слышал информацию об Альт Сервер Виртуализации, но до конца не понимал, что это такое. Решил разобраться. Из описания не совсем понятно, что на практике из себя представляет этот продукт. В описании видно, что он почти полностью состоит из open source компонентов и это не скрывается. Но при этом продаётся за деньги, хоть и относительно небольшие.
Я решил развернуть его у себя в редакции кластер виртуализации PVE. Помимо него есть ещё три:
◽базовый гипервизор KVM;
◽облачная виртуализация OpenNebula;
◽контейнерная виртуализация (LXC/LXD, Docker/Podman).
Установщик полностью на русском языке. Используется один ISO образ для всех редакций, которые можно выбирать в процессе установки. Помимо основных пакетов, можно выбрать дополнительные. Например, сразу установить агент мониторинга различных систем, или, к примеру, nginx сервер для проксирования, rsyslog, HAProxy для отказоустойчивого веб интерфейса и некоторый другой популярный софт.
У установщика есть широкие возможности по разбивке диска, что встречается не так часто. Можно установить систему на одиночный диск, на mdadm массив, на LVM, на BTRF. ZFS почему-то в списке не было. На разделы, соответственно, тоже можно вручную разбить.
После установки я увидел обычный Proxmox. В последней версии alt-server-v-10.1 версия PVE 7.2. Из примечательного, в alt используется пакетный менеджер apt-get, а пакеты rpm. Подключены только репозитории alt. То есть привязки к инфраструктуре компании Proxmox нет. Я так понял, что все пакеты в репозитории alt собираются разработчиками дистрибутива.
Отдельно отмечу хорошую документацию по продукту на русском языке. Если вы хотите посмотреть документацию на русском языке по Proxmox или OpenNebula, можно воспользоваться этой.
Собственно, становится понятно, за что нужно будет заплатить в коммерческом использовании (для физических лиц всё бесплатно). Если вам нужен Proxmox или OpenNebula с возможностью использования там, где можно брать только отечественное ПО, то Альт Сервер Виртуализации — это ваш случай. Он есть в реестре отечественного ПО, он привязан к репозиториям alt и по идее устойчив ко всяким санкциям, ограничениям и т.д. Также можно купить техподдержку.
⇨ Сайт / Загрузка / Обзор (кластер)
#виртуализация #отечественное #proxmox
Я решил развернуть его у себя в редакции кластер виртуализации PVE. Помимо него есть ещё три:
◽базовый гипервизор KVM;
◽облачная виртуализация OpenNebula;
◽контейнерная виртуализация (LXC/LXD, Docker/Podman).
Установщик полностью на русском языке. Используется один ISO образ для всех редакций, которые можно выбирать в процессе установки. Помимо основных пакетов, можно выбрать дополнительные. Например, сразу установить агент мониторинга различных систем, или, к примеру, nginx сервер для проксирования, rsyslog, HAProxy для отказоустойчивого веб интерфейса и некоторый другой популярный софт.
У установщика есть широкие возможности по разбивке диска, что встречается не так часто. Можно установить систему на одиночный диск, на mdadm массив, на LVM, на BTRF. ZFS почему-то в списке не было. На разделы, соответственно, тоже можно вручную разбить.
После установки я увидел обычный Proxmox. В последней версии alt-server-v-10.1 версия PVE 7.2. Из примечательного, в alt используется пакетный менеджер apt-get, а пакеты rpm. Подключены только репозитории alt. То есть привязки к инфраструктуре компании Proxmox нет. Я так понял, что все пакеты в репозитории alt собираются разработчиками дистрибутива.
Отдельно отмечу хорошую документацию по продукту на русском языке. Если вы хотите посмотреть документацию на русском языке по Proxmox или OpenNebula, можно воспользоваться этой.
Собственно, становится понятно, за что нужно будет заплатить в коммерческом использовании (для физических лиц всё бесплатно). Если вам нужен Proxmox или OpenNebula с возможностью использования там, где можно брать только отечественное ПО, то Альт Сервер Виртуализации — это ваш случай. Он есть в реестре отечественного ПО, он привязан к репозиториям alt и по идее устойчив ко всяким санкциям, ограничениям и т.д. Также можно купить техподдержку.
⇨ Сайт / Загрузка / Обзор (кластер)
#виртуализация #отечественное #proxmox
Перенос VM с Hyper-V на Proxmox
На днях стояла задача перенести виртуальные машины Linux (Debian 11) с Hyper-V на KVM (Proxmox). Помучался изрядно, но в итоге всё получилось. Если VM первого поколения без EFI раздела, то проблем вообще никаких. Просто переносим диск виртуальной машины, конвертируем и подключаем к VM. Вообще ничего перенастраивать не надо, все имена дисков и сетевых адаптеров будут те же, что и на Hyper-V. А вот если машины второго поколения с загрузкой по EFI, то начинаются танцы с бубном. Причём у каждого свои, судя по информации из интернета.
Рассказываю, как в итоге сделал я, чтобы всё заработало. Перенос делал следующим образом:
1️⃣ Завершаю работу VM на Hyper-V.
2️⃣ Копирую файл диска vhdx на хост Proxmox.
3️⃣ Создаю в Proxmox новую виртуальную машину и обязательно указываю Bios: OVMF (UEFI), SCSI Controller: VirtIO SCSI. Остальное не принципиально. Диски можно никакие не добавлять. Но при этом у вас будет автоматически подключен EFI Disk, с какими-то своими параметрами, из которых я выбрал только формат - qcow2.
4️⃣ В консоли Proxmox конвертируем vhdx диск в диск виртуальной машины:
Формат команды следующий:
5️⃣ После импорта диск цепляется к VM в отключенном виде. Подключаем его как SCSI и настраиваем с него загрузку.
6️⃣ Загружаем VM с этого диска. Тут по многим руководствам из инета виртуалка уже запускается и нормально работает. Но не у меня. Я проваливался в uefi interactive shell v2.2 proxmox.
7️⃣ Заходим в bios этой виртуалки и отключаем там Secure Boot. Делается это в разделе Device Manager ⇨ Secure Boot Configuration. После этого у некоторых VM начинает загружаться, но опять не у меня.
8️⃣ Опять иду в bios, в раздел Boot Maintenance Manager ⇨ Boot Options ⇨ Add Boot Option. Выбираю импортированный диск VM. Там кроме него будет только CD-ROM, так что легко понять, что надо выбрать. Открывается обзор файловой системы EFI раздела от нашей системы. Перемещаемся там по директориям
А я сначала пробовал разные настройки VM, загружался с LiveCD и проверял разделы диска, загрузчик. Там всё ОК, данные нормально переезжают. Проблема именно в настройке загрузки через EFI раздел. Почему-то автоматом он не подхватывался. Может это была особенность Debian 11. Я переносил именно их.
❗️Сразу добавлю полезную информацию по поводу Centos 7. Может это будет актуально и для каких-то других система. Когда я переносил виртуалки с этой системой между гипервизорами, они не загружались, пока не пересоберёшь initramfs под конкретным гипервизором. Если просто перенести, то загрузка не ехала дальше из-за проблем с определением дисков на этапе загрузки. Пересборка initramfs решала эту проблему.
❗️И ещё один нюанс с переездами между гипервизорами, с которым сталкивался. Иногда система не грузится, потому что в fstab были прописаны имена дисков, которые на новом гипервизоре получили другие названия. Тогда грузимся с LiveCD и меняем диски в fstab и возможно в grub.
Тема переезда между разными типами гипервизоров непростая. Иногда проще воспользоваться какой-то системой, типа Veeam Agent For Linux или Rescuezilla. Так как я более ли менее теорию понимаю по этой теме, то переношу обычно вручную.
#linux #hyperv #виртуализация
На днях стояла задача перенести виртуальные машины Linux (Debian 11) с Hyper-V на KVM (Proxmox). Помучался изрядно, но в итоге всё получилось. Если VM первого поколения без EFI раздела, то проблем вообще никаких. Просто переносим диск виртуальной машины, конвертируем и подключаем к VM. Вообще ничего перенастраивать не надо, все имена дисков и сетевых адаптеров будут те же, что и на Hyper-V. А вот если машины второго поколения с загрузкой по EFI, то начинаются танцы с бубном. Причём у каждого свои, судя по информации из интернета.
Рассказываю, как в итоге сделал я, чтобы всё заработало. Перенос делал следующим образом:
1️⃣ Завершаю работу VM на Hyper-V.
2️⃣ Копирую файл диска vhdx на хост Proxmox.
3️⃣ Создаю в Proxmox новую виртуальную машину и обязательно указываю Bios: OVMF (UEFI), SCSI Controller: VirtIO SCSI. Остальное не принципиально. Диски можно никакие не добавлять. Но при этом у вас будет автоматически подключен EFI Disk, с какими-то своими параметрами, из которых я выбрал только формат - qcow2.
4️⃣ В консоли Proxmox конвертируем vhdx диск в диск виртуальной машины:
# qm importdisk 102 /mnt/500G/Debian11.vhdx local-500GФормат команды следующий:
# qm importdisk <vmid> <source> <storage>5️⃣ После импорта диск цепляется к VM в отключенном виде. Подключаем его как SCSI и настраиваем с него загрузку.
6️⃣ Загружаем VM с этого диска. Тут по многим руководствам из инета виртуалка уже запускается и нормально работает. Но не у меня. Я проваливался в uefi interactive shell v2.2 proxmox.
7️⃣ Заходим в bios этой виртуалки и отключаем там Secure Boot. Делается это в разделе Device Manager ⇨ Secure Boot Configuration. После этого у некоторых VM начинает загружаться, но опять не у меня.
8️⃣ Опять иду в bios, в раздел Boot Maintenance Manager ⇨ Boot Options ⇨ Add Boot Option. Выбираю импортированный диск VM. Там кроме него будет только CD-ROM, так что легко понять, что надо выбрать. Открывается обзор файловой системы EFI раздела от нашей системы. Перемещаемся там по директориям
/EFI/debian, выбираем файл grubx64.efi. То есть мы создаём новый вариант загрузки системы, выбрав этот файл. Там же пишем какое-то название для этой загрузки, чтобы отличить от остальных вариантов. Далее идём в раздел Boot Maintenance Manager ⇨ Boot Options ⇨ Change Boot Order и назначаем первым номером только что созданный вариант для загрузки. Сохраняем изменения и загружаемся. Теперь всё ОК, система загрузилась. А я сначала пробовал разные настройки VM, загружался с LiveCD и проверял разделы диска, загрузчик. Там всё ОК, данные нормально переезжают. Проблема именно в настройке загрузки через EFI раздел. Почему-то автоматом он не подхватывался. Может это была особенность Debian 11. Я переносил именно их.
❗️Сразу добавлю полезную информацию по поводу Centos 7. Может это будет актуально и для каких-то других система. Когда я переносил виртуалки с этой системой между гипервизорами, они не загружались, пока не пересоберёшь initramfs под конкретным гипервизором. Если просто перенести, то загрузка не ехала дальше из-за проблем с определением дисков на этапе загрузки. Пересборка initramfs решала эту проблему.
❗️И ещё один нюанс с переездами между гипервизорами, с которым сталкивался. Иногда система не грузится, потому что в fstab были прописаны имена дисков, которые на новом гипервизоре получили другие названия. Тогда грузимся с LiveCD и меняем диски в fstab и возможно в grub.
Тема переезда между разными типами гипервизоров непростая. Иногда проще воспользоваться какой-то системой, типа Veeam Agent For Linux или Rescuezilla. Так как я более ли менее теорию понимаю по этой теме, то переношу обычно вручную.
#linux #hyperv #виртуализация
