Комментарии 38
Спасибо за статью.
В принципе, перенос VM на другой хост ESXi можно было сделать следующим образом:
1. Поднять второй сервер с лицензией evaltuion
2. С помощью vCenter Converter перенести свои виртуальные машины на этот хост
3. Накатить стандратную лицензию после миграции
И если я правильно помню, vCenter converter умеет работать с тонкими дисками
В принципе, перенос VM на другой хост ESXi можно было сделать следующим образом:
1. Поднять второй сервер с лицензией evaltuion
2. С помощью vCenter Converter перенести свои виртуальные машины на этот хост
3. Накатить стандратную лицензию после миграции
И если я правильно помню, vCenter converter умеет работать с тонкими дисками
Интересно. Если подвести скромный итог — нормальных средств нет. Нет vCenter, нет счастья.
ghettoVCB намного удобнее использовать с MKSBackup в качестве фронтэнда — http://www.magikmon.com/mksbackup/ghettovcb.en.html
НЛО прилетело и опубликовало эту надпись здесь
К лицензиям ESXi понадобится лицензия на vCenter — он предлагает API для backup. Дешевле всего получается vSphere Essentials Plus, который можно дополнить Veeam Essentials.
Ну а дешевле всего — на Microsoft, конечно, если у вас VM — WIndows.
Ну а дешевле всего — на Microsoft, конечно, если у вас VM — WIndows.
vSphere Essentials Plus — $5,439.00. Как бы не очень дёшево…
Самый дешёвый вариант, это vSphere Essentials Kits — $560.00, в который включен vCenter Server Essentials. Backup API тут уже работает, так что вариантов становится много…
Самый дешёвый вариант, это vSphere Essentials Kits — $560.00, в который включен vCenter Server Essentials. Backup API тут уже работает, так что вариантов становится много…
Покупка Trilead VM Explorer может быть будет ещё дешевле?
Есть бесплатный VBR без инкрементальных бекапов (Bacula тоже их не умеет), есть полулегальная NFR для одного хоста и есть продукты для SMB: Altaro, Nakivo и даже Acronis дешевле Veeam.
Для VMWare это еще дешево, хе-хе-хе. В «не» Plus нет High Availability, а это как-то совсем скучно.
НЛО прилетело и опубликовало эту надпись здесь
Не нужен там vCenter и для бекапа достаточно vSphere Essentials за 40 тыр на три хоста.
vSphere Essentials подразумевает лицензию на vCenter. Юзать или нет, дело ваше, но глупо не использовать, если уж есть.
С одним хостом там полезны только шаблоны ценой 8 ГБ оперативки.
ммм. Ниче не понял. Платный Эссеншиал разрешает лицензию на 1 vCenter и 6 сокетов по 2 на каждый из трех хостов. Ты о чем?
Я о том, что для vCenter нужны ресурсы (2 vCPU, 8 GB), но в Essentials при одном хосте никаких важных фичей он не даёт.
Теперь понял. После развертывания vCenter можно порезать ему железо.
В шестёрке с этим не всё хорошо.
Может в 6.5 улучшат автонастройку в сторону уменьшения или вообще откроют API в бесплатной версии, раз Photon Controller не использует vCenter.
Может в 6.5 улучшат автонастройку в сторону уменьшения или вообще откроют API в бесплатной версии, раз Photon Controller не использует vCenter.
Вывод прост: ESXi вообще не предназначен для одиночных серверов виртуализации. Также плохо предназначен для их малого количества. Десять процессроных нод, отдельная СХД — пожалуйста, а один сервер — это боль. Не используйте ESXi.
Вывод неверный, ESXi прекрасно годится для одиночного сервера, но бесплатная версия скорее является демкой из-за ограничений API.
Ну это смотря какие цели…
С задачей просто крутить виртуалки ESXI прекрасно справляется и на одном хосте. У меня uptime — 2 года, и никаких проблем. И это немного…
С задачей просто крутить виртуалки ESXI прекрасно справляется и на одном хосте. У меня uptime — 2 года, и никаких проблем. И это немного…
Мне кажется с Вами очень многие не согласятся. И будут правы.
+1 Отвечаю именно вам, ESXi рулит. Надеюсь, они запилят когда-нибудь поддержку софт-рейда. nvme просится.
На данный момент — двое не согласились, двое согласились судя по количеству ±.
Вообще у меня есть опыт эксплуатации этого. Я очень сильно недоволен VMWare. Одиночные хосты на Proxmoх настолько удобнее администрировать, что тут даже говорить не о чём, выбор однозначен. Ну и небольшие кластеры тоже.
Вообще у меня есть опыт эксплуатации этого. Я очень сильно недоволен VMWare. Одиночные хосты на Proxmoх настолько удобнее администрировать, что тут даже говорить не о чём, выбор однозначен. Ну и небольшие кластеры тоже.
Некоторые просто не любят коммерческие продукты, а из ESXi давно выбросили весь Линукс и HCL надо принимать во внимание. С Proxmox не сталкивался, но у RHEV всё намного хуже при малом количестве хостов.
По вопросу на SO — экспорт в OVF прекрасно справится с задачей.
З.Ы. Под oVirt/RHEV есть какие-нибудь достойные продукты для РК, кроме CommVault и Acronis?
По вопросу на SO — экспорт в OVF прекрасно справится с задачей.
З.Ы. Под oVirt/RHEV есть какие-нибудь достойные продукты для РК, кроме CommVault и Acronis?
Много лет пользуюсь ghettoVCB. Решение очень надежное, всем однозначно рекомендую. Thin и ротацию бекапов умеет. Есть сжатие (zip) но в реальной работе не имеет смысла — бывает нужно из бекапа поднять виртуалку, а с заархивированной виртуалкой такое не выйдет. Бекапить можно на NFS. Есть возможность прикрутить оповещение по email. Если есть возможность использовать хранилище с дедупликацией — тогда вообще идеальное решение получится. В скрипте нужно допилить возможность бекапа для более высоких версий (достаточно вставить нужные версии ESX), это должно быть просто.
PS
любой бекап VMWare делается при помощи снапшотов
PS
любой бекап VMWare делается при помощи снапшотов
Можете ли поделиться опытом работы с ghettoVCB:
— умеет ли ghettoVCB делать инкрементальные бэкапы?
— если бэкапить на другой ESXI хост — будет ли по сети гоняться полный размер VM или только используемая часть тонких дисков?
— тот же вопрос для NFS — будет ли по сети гоняться полный?
— вы пишете про дедупликацию — но дедупликация обычно делается на стороне хранилища. Значит, сначала надо по сети отправить полный размер виртуалки, и только уже на хранилище оно дедуплицируется. Так?
— умеет ли ghettoVCB делать инкрементальные бэкапы?
— если бэкапить на другой ESXI хост — будет ли по сети гоняться полный размер VM или только используемая часть тонких дисков?
— тот же вопрос для NFS — будет ли по сети гоняться полный?
— вы пишете про дедупликацию — но дедупликация обычно делается на стороне хранилища. Значит, сначала надо по сети отправить полный размер виртуалки, и только уже на хранилище оно дедуплицируется. Так?
— Инкрементальные не умеет, но по сети гонятся только данные (т.е. thin файл).
— На другой хост нельзя бекапить, только на подмонтированное хранилище (то что можно указывать в путях бекапа утилите, т.е. это должен быть либо NFS сторадж, либо iscsi/das)
— Да, дедупликация на стороне хранилища (нужно какой нибудь ZFS использовать), потому как самый главный недостаток ghettoVCB невозможность делать инкрементальные бекапы, только полные либо thin.
Есть еще ряд недостатков:
— Бэкап делается при помощи снятия снапшота, т.е. изменения VM начинают писаться в дельта-файл, а основной файл диска VM замораживается и копируется на бекап сторадж, после копирования ESX сливает содержимое изменений дельта файла в основной файл VM — и тут могут наблюдаться серьезные тормоза, зависит от вашего железа, размера VM, количества изменений внесенных в дельта файл и сопутствующих параметров. В основном я ставлю бекап на периоды низкой активности (на ночь). В принципе, на сколько я знаю, все виды бекап систем работают именно таким способом, это ограничения API — иными словами ghettoVCB не лучше и не хуже в этом плане коммерческих систем.
— Потеря содержимого оперативной памяти. По идее в VMWare есть механизм работающий через VMWare Tools который позволяет минимизировать последствия (принудительный сброс дисковых буферов операционной системы и т.д., но не всегда корректно работает, нужно это учитывать). В этом плане думаю так же нет отличий от коммерческих систем.
— Думаю хорошей комбинацией является сочетание классического бекапа данных изнутри VM и ghettoVCB
— На другой хост нельзя бекапить, только на подмонтированное хранилище (то что можно указывать в путях бекапа утилите, т.е. это должен быть либо NFS сторадж, либо iscsi/das)
— Да, дедупликация на стороне хранилища (нужно какой нибудь ZFS использовать), потому как самый главный недостаток ghettoVCB невозможность делать инкрементальные бекапы, только полные либо thin.
Есть еще ряд недостатков:
— Бэкап делается при помощи снятия снапшота, т.е. изменения VM начинают писаться в дельта-файл, а основной файл диска VM замораживается и копируется на бекап сторадж, после копирования ESX сливает содержимое изменений дельта файла в основной файл VM — и тут могут наблюдаться серьезные тормоза, зависит от вашего железа, размера VM, количества изменений внесенных в дельта файл и сопутствующих параметров. В основном я ставлю бекап на периоды низкой активности (на ночь). В принципе, на сколько я знаю, все виды бекап систем работают именно таким способом, это ограничения API — иными словами ghettoVCB не лучше и не хуже в этом плане коммерческих систем.
— Потеря содержимого оперативной памяти. По идее в VMWare есть механизм работающий через VMWare Tools который позволяет минимизировать последствия (принудительный сброс дисковых буферов операционной системы и т.д., но не всегда корректно работает, нужно это учитывать). В этом плане думаю так же нет отличий от коммерческих систем.
— Думаю хорошей комбинацией является сочетание классического бекапа данных изнутри VM и ghettoVCB
ghettoVCB — отличный инструмент, но с версией ESXi 6 не хочет работать.
> В скрипте нужно допилить возможность бекапа для более высоких версий (достаточно вставить нужные версии ESX), это должно быть просто.
Не поделитесь как его просто допилить?
> В скрипте нужно допилить возможность бекапа для более высоких версий (достаточно вставить нужные версии ESX), это должно быть просто.
Не поделитесь как его просто допилить?
Я посмотрел версию которая сейчас актуальна и судя по содержимому скрипта, там появилась поддержка 6-й версии https://raw.githubusercontent.com/lamw/ghettoVCB/master/ghettoVCB.sh
Если хочется самому поправить, то нужно в исходном коде найти проверки версий, и добавить нужную версию. Например:
Если хочется самому поправить, то нужно в исходном коде найти проверки версий, и добавить нужную версию. Например:
if [[ "${VER}" == "4" ]] || [[ "${VER}" == "5" ]] ; then
if [[ "${VER}" == "4" ]] || [[ "${VER}" == "5" ]] || [[ "${VER}" == "6" ]] ; then
Наизобретали велосипедов…
Посчитайте TCO — стоимость времени админа на уставновку и настройку не популярного продукта, обслуживание системы год, поиск нового сотрудника, который знает продукт или затраты на обучение, передачи дел. Если не в 100%, то 99%, что это дороже покупки SBE VE за 50-55 000₽ с годовой поддержкой вендора.
И перенести можно и бэкапить с помощью агента на любом гипервизоре даже без API. Хоть из Amazon.
90 дней для тестирования бесплатно.
Посчитайте TCO — стоимость времени админа на уставновку и настройку не популярного продукта, обслуживание системы год, поиск нового сотрудника, который знает продукт или затраты на обучение, передачи дел. Если не в 100%, то 99%, что это дороже покупки SBE VE за 50-55 000₽ с годовой поддержкой вендора.
И перенести можно и бэкапить с помощью агента на любом гипервизоре даже без API. Хоть из Amazon.
90 дней для тестирования бесплатно.
Надо же, в 2016 году они всё же изобрели Instant Recovery.
https://habrahabr.ru/company/symantec/blog/267159/
Смотрим дату публикации и читаем
Всегда рад помочь в эффективном решении задач по серверам HP, виртуализации Vmware, бэкапу Symantec/Veritas/Veeam.
Смотрим дату публикации и читаем
можно создать в виртуальной среде клон физического сервера с возможностью его быстрого восстановления (Instant Recovery) буквально одной кнопкой. Именно это реализовано в Backup Exec 15.
Всегда рад помочь в эффективном решении задач по серверам HP, виртуализации Vmware, бэкапу Symantec/Veritas/Veeam.
Не знаю, что имел в виду маркетолог по той ссылке, но официальной документации я больше доверяю.
Возможно я нашел способ решить эту проблему https://habrahabr.ru/post/316056/
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Бесплатные утилиты для бэкапа с бесплатного ESXI