Через некоторое время, с развитем проектов, я стал настраивать админские фишки — мониторинг, бэкап, и выяснил, что оказывается сервер, в котором мне обещали Soft RAID, и на который хостер (OVH) накатил свой образ ESXI — без RAID! То есть просто 2 диска. Ну да, теперь вот я знаю, что ESXI не поддерживает Soft RAID, только Hard. Стало неуютно. Да и 2TB стало не хватать. В общем взял я себе сервер побольше, с аппаратным RAID и поставил туда ESXI 6.0.
И возникло две задачи, решение которых я тут опишу:
- Перенести виртуальные машины (некоторые из которых около 1TB) с одного сервера на другой с минимальным оффлайном
- Делать регулярные бэкапы
Скажу сразу, что обе эти задачи легко решаются, если есть хотя бы минимальная платная лицензия ESXI. Дело в том, что «родной» Backup API в бесплатной версии ESXI выключен. Поэтому приходится находить другие пути.
С платной лицензией есть вариант миграции через vCenter. Ещё есть бесплатная версия Veeam Backup, которая позволяет делать бэкапы и переносить виртуальные машины с одной системы на другую и при этом не требуется их останавливать. Но с бесплатной лицензией ESXI, текущая версия — Veeam 9 — не работает вообще.
Ещё есть решение от HP — VM Explorer, у которого есть бесплатный Free Edition.
VM Explorer 6.2 умеет работать с free ESXI, но:
- При создании бэкапа — с сервера копируется полный размер образа, даже если диск там тонкий (thin). То есть если диск у виртуальной машины на 500GB, а записано там только 50GB, то копироваться будут 500GB. И так — каждый раз. Режим инкрементального бэкапа (только на локальный компьютер) есть в платной версии, я его не тестировал — на знаю, насколько оно эффективно.
- Бесплатная лицензия позволяет делать бэкап только на локальные диски. То есть, чтобы копировать на другой ESXI хост нужна уже платная лицензия.
- В бесплатной версии нет планировщика, то есть запускать бэкапы нужно вручную.
Другое популярное решение — это open source проект ghettoVCB, но мне он показался несколько сложным для использования, да и документация выглядит немного устаревшей. Про этот проект уже писали здесь на Хабре.
Уверен, что есть и много других вариантов. Будет интересно почитать комментарии опытных админов. Хотя подозреваю, что опытные работают там, где купили нужные лицензии и не парятся…
Здесь можно просто упомянуть:
- Nakivo, у которой в бесплатной версии ограничение на 2 VM.
- Unitrends, у которой в бесплатной версии ограничение — 1TB.
- Thinware
Если у вас есть опыт использование этих продуктов — поделитесь в комментариях.
Я в конечном итоге решил использовать 2 инструмента:
- Xsibackup, у которого есть бесплатная версия
- Ovftool
Xsibackup
До версии 4.4 Xsibackup был на Github, но сейчас (версия 6.0.7) с Github'а Xsibackup убрали, теперь инсталлировать надо с сайта авторов.
В бесплатной версии:
- «Горячие» бэкапы, без остановки виртуальных машин. Делается это с помощью снепшота (snapshot)
- Конфигурирование крона (cron) в ESXI
- Отчёты по email
- Ротация бэкапов
- Бэкап на другой ESXI хост. В бесплатной версии — с помощью rsync, заточенного под ESXI. В платной версии ещё есть инкрементальные бэкапы (OneDiff) через создание промежуточных снэпшотов (как по мне — то не очень удачное решение) и дедупликация с помощью их NAS (XSINAS)
Инсталлируется Xsibackup на ESXI хост, с которого нужно делать бэкапы.
На ESXI должен быть включена служба SSH.
Регистрируетесь на сайте авторов — Download xsibackup — 33hops.com/xsibackup-vmware-esxi-backup.html
Вам на email придёт бесплатный ключ и скрипт для инсталлирования на ESXI:
cd /vmfs/volumes/datastore1/xsi-dir 2>/dev/null || mkdir /vmfs/volumes/datastore1/xsi-dir && cd /vmfs/volumes/datastore1/xsi-dir && esxcli network firewall unload && wget http://a.33hops.com/downloads/?key=64cG...secretKey -O xsibackup.zip && unzip -o xsibackup.zip || cat xsibackup.zip && echo "" && chmod 0700 xsibackup* && rm -rf xsibackup.zip && esxcli network firewall load
secretKey у вас будет свой.
Если datastore у вас называется по другому — то надо прописать свой путь.
Увидев wget, кто-то может покачать головой, и сказать, что ставить чужой софт на ESXI хост — это несекьюрно и т.д. Однако при любом бэкапе, вы будете отдавать root пароль программе для бэкапа, то есть кому-то доверять вы будете в любом случае. При локальном копировании Xsibackup использует только shell скрипты, которые можно посмотреть и проверить…
Затем создаёте папку, куда будем складывать бэкапы — локально, или на другом сервере:
mkdir /vmfs/volume1/datastore1/backupЕсли копировать бэкапы будет между хостами, то делимся SSH ключами:
./xsibackup --link-srv=[second.esxi.system.ip]Если хотим, чтоб был бэкапы запускались через крон, то:
./xsibackup --install-cronТестируем, что всё работает локально:
./xsibackup --backup-point=/vmfs/volumes/datastore1/backup --backup-type=running --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.yourserver.com --smtp-port=25 --smtp-usr=username --smtp-pwd=password --test-mode=trueЧтобы протестировать работу между хостами, меняем:
--backup-point="IP-OF-ESXI:22:/vmfs/volumes/datastore1", где 22 - это SSH порт.Если SMTP требует TLS, то поддерживается --smtp-sec=TLS
» Полный список опций (на английском)
Локально, то есть на одном хосте, всё работает отлично: бэкапы делаются с помощью нативной утилиты ESXI — vmkfstools. Всё быстро, и тонкие диски остаются тонкими. С жёсткими дисками, у меня получилась скорость около 60MB/s
Однако при копирование на удалённый хост я обнаружил, ту же проблему, что и с HP VM Explorer — копируется полный размер VM, даже если диск тонкий, и используется только меньшая часть.
Когда я спросил авторов, в чём причина, то они написали, что для копирования между хостами используется rsync, а он недостаточно «умён», чтобы пропускать невыделенные блоки тонких дисков.
При тестировании, я обнаружил, что при повторных бэкапах, rsync практически не сокращает время копирования — по сети опять уходит полный размер VM.
Авторы написали, что в планах у них запилить собственную утилиту вместо rsync, которая будет намного быстрей. Планируют выпустить до конца года.
В моём случае, хостер гарантирует скорость сети в 250Mb/s (~31MB/s), но реально между двумя хостами в одном датацентре бэкап у меня работал на 10-20MB/s. Не знаю в чём тут дело, — тормозит ли это сеть, rsync или что ещё, — но процесс растягивается слишком надолго.
Update: нашёл статью, — по их бенчмаркам выходит, что дело в тормознутом SSH (поверх которого работает rsync), по NFS было бы быстрее.
Радует, что в результате диски таки остаются тонкими.
Процесс переноса и бэкапа VMs
Процесс переноса VMs между хостами выглядит у меня так:
- Сначала, я делаю локальные бэкапы с помощью Xsibackup.
- Регистрирую новую VM — копию из предыдущего шага.
- Необязательно: Можно «почистить» VM от удалённых файлов коммандой:
vmkfstools --punchzero VMname.vmdk
указывать основной файл, а не тот, который -flat. - Затем с помощью Ovftool (см.ниже) копирую на другой хост. Ovftool умеет слать тонкие диски так, что отсылается только используемая часть.
- После этого VM на первом хосте выключается, а новом — запускается.
Таким же образом пока выглядит и бэкап VM от хостера к себе домой. Для этого у меня дома крутится ESXI — чтобы ovftool мог по сети передавать только полезную нагрузку.
На форумах пишут, что вроде бы есть способ копировать файлы на NFS с опцией sparse так, чтобы передавать только существующие данные, но я пока ещё не разобрался.
Способа делать инкрементальный бэкап я не нашёл.
Пока я это всё делаю вручную из консоли — переношу на другой хост, делаю первый бэкап, но со временем думаю всё настроить через крон. Может позже допишу здесь пару параграфов о том, как настраивать крон. Оригинальные инструкции вот здесь: 33hops.com/xsibackup-cron-how-to.html
Таким образом сейчас у меня первая копия лежит рядом, на том же сервере, и доступна для довольно быстрого восстановления.
Вторая копия — у меня дома, то есть, как и рекомендуют — в физически другом месте. Для восстановления придётся заливать по сети, что существенно медленнее. Но вероятность нужды в этом тоже довольно низкая.
Ovftool
Полное руководство на английском здесь, там же можно и скачать. Ovftool можно ставить к себе на любой компьютер, и управлять гипервизором с него. А можно и поставить прямо на ESXI хост, хотя это и не поддерживаемая возможность.
Вот по шагам:
- Регистрируетесь с VMware и скачиваете «VMware OVF Tool for Linux 64-bit»
- Запускаете скачанный файл на Linux и затем копируете получившиеся файлы на ESXI:
sudo /bin/sh VMware-ovftool-4.1.0-2459827-lin.x86_64.bundle scp -r /usr/lib/vmware-ovftool/ root@esx.com:/vmfs/volumes/datastore1 - Потом уже на самом хосте, необходимо отредактировать один файл — /vmfs/volumes/datastore1/vmware-ovftool/ovftool и в нём заменить #!/bin/bash на #!/bin/sh
Ovftool не умеет копировать VM в горячем режиме, то есть требует, чтобы виртуальная машина была выключена. Поэтому — необходимость в Xsibackup выше.
Несколько особенностей работы Ovftool:
- У меня бывало выскакивали ошибки: «The task was canceled by a user» или «Error: vim.fault.FileNotFound». Причина обоих ошибок оказалось в том, что CDROM на оригинальной машине указывал на ISO, которого не было на целевом хосте. Попробуйте догадаться об этом по тексту ошибки… Решилось удалением CDROM устройства (оно использовалось только для инсталяции OS).
- Я сам не проверял, но вроде бы ovftool не сохраняет snapshots.
Ещё несколько особенностей Ovftool, только при запуске на ESXI:
- Хоть ovftool запускается локально, путь к хосту надо прописывать полностью, вместе с пользователем и паролём.
- Не умеет интерактивно читать пароль с консоли, а требует, чтобы он был передан параметром в командной строке.
- В пароле можно использовать только буквы, цифры и `-`. При попытке использовать другие символы, типа `#` — пароль не принимался.
Примеры использования ovftool:
- Вывести список всех зарегистрированных виртуальных машин в датасторе:
ovftool -ds=datastore1 "vi://root:password@esx1.com/" - Копирование виртуальной машины (она должна быть зарегистрированной):
ovftool -ds=datastore1 -dm=thin "vi://root:password@esx1.com/vmName" "vi://root:password@esx2.com/"
Комментарии (37)
gotch
10.10.2016 08:55+2Интересно. Если подвести скромный итог — нормальных средств нет. Нет vCenter, нет счастья.
Ethril
10.10.2016 09:27+1ghettoVCB намного удобнее использовать с MKSBackup в качестве фронтэнда — http://www.magikmon.com/mksbackup/ghettovcb.en.html
NLO
10.10.2016 09:31НЛО прилетело и опубликовало эту надпись здесь
gotch
10.10.2016 10:02К лицензиям ESXi понадобится лицензия на vCenter — он предлагает API для backup. Дешевле всего получается vSphere Essentials Plus, который можно дополнить Veeam Essentials.
Ну а дешевле всего — на Microsoft, конечно, если у вас VM — WIndows.
SlavikF
10.10.2016 10:08+2vSphere Essentials Plus — $5,439.00. Как бы не очень дёшево…
Самый дешёвый вариант, это vSphere Essentials Kits — $560.00, в который включен vCenter Server Essentials. Backup API тут уже работает, так что вариантов становится много…
navion
10.10.2016 13:12Есть бесплатный VBR без инкрементальных бекапов (Bacula тоже их не умеет), есть полулегальная NFR для одного хоста и есть продукты для SMB: Altaro, Nakivo и даже Acronis дешевле Veeam.
gotch
11.10.2016 13:07Для VMWare это еще дешево, хе-хе-хе. В «не» Plus нет High Availability, а это как-то совсем скучно.
navion
10.10.2016 13:05Не нужен там vCenter и для бекапа достаточно vSphere Essentials за 40 тыр на три хоста.
merlin-vrn
10.10.2016 14:46Вывод прост: ESXi вообще не предназначен для одиночных серверов виртуализации. Также плохо предназначен для их малого количества. Десять процессроных нод, отдельная СХД — пожалуйста, а один сервер — это боль. Не используйте ESXi.
navion
10.10.2016 18:05Вывод неверный, ESXi прекрасно годится для одиночного сервера, но бесплатная версия скорее является демкой из-за ограничений API.
SlavikF
10.10.2016 18:25Ну это смотря какие цели…
С задачей просто крутить виртуалки ESXI прекрасно справляется и на одном хосте. У меня uptime — 2 года, и никаких проблем. И это немного…Sn0WLi9ht
12.10.2016 16:04По хорошему нужно обновляться. В новых версиях исправления уязвимостей. Например была крупная уязвимость Heartbleed. Если вы хосты 2 года не перезагружали очевидно вы так-же не обновлялись.
leninxxx
10.10.2016 23:01Мне кажется с Вами очень многие не согласятся. И будут правы.
yosemity
11.10.2016 01:34+1 Отвечаю именно вам, ESXi рулит. Надеюсь, они запилят когда-нибудь поддержку софт-рейда. nvme просится.
Sn0WLi9ht
12.10.2016 15:57Поддержку софт-рейда выпилили по моему в 5 версии — это не энтерпрайзно, низкий уровень надежности, VMWare надоело разбираться с проблемами кастомеров.
yosemity
13.10.2016 18:27Софт-рейд имеет право на жизнь в том числе в энтерпрайзе. Флеш-решения на NVMe было бы не плохо отзеркалить и cофт-рейд 1 из какой-нибудь парочки p3600 — быстро, надежно и не дорого…
merlin-vrn
11.10.2016 10:38На данный момент — двое не согласились, двое согласились судя по количеству ±.
Вообще у меня есть опыт эксплуатации этого. Я очень сильно недоволен VMWare. Одиночные хосты на Proxmoх настолько удобнее администрировать, что тут даже говорить не о чём, выбор однозначен. Ну и небольшие кластеры тоже.navion
11.10.2016 12:24Некоторые просто не любят коммерческие продукты, а из ESXi давно выбросили весь Линукс и HCL надо принимать во внимание. С Proxmox не сталкивался, но у RHEV всё намного хуже при малом количестве хостов.
По вопросу на SO — экспорт в OVF прекрасно справится с задачей.
З.Ы. Под oVirt/RHEV есть какие-нибудь достойные продукты для РК, кроме CommVault и Acronis?
Sn0WLi9ht
10.10.2016 18:16Много лет пользуюсь ghettoVCB. Решение очень надежное, всем однозначно рекомендую. Thin и ротацию бекапов умеет. Есть сжатие (zip) но в реальной работе не имеет смысла — бывает нужно из бекапа поднять виртуалку, а с заархивированной виртуалкой такое не выйдет. Бекапить можно на NFS. Есть возможность прикрутить оповещение по email. Если есть возможность использовать хранилище с дедупликацией — тогда вообще идеальное решение получится. В скрипте нужно допилить возможность бекапа для более высоких версий (достаточно вставить нужные версии ESX), это должно быть просто.
PS
любой бекап VMWare делается при помощи снапшотовSlavikF
10.10.2016 18:22Можете ли поделиться опытом работы с ghettoVCB:
— умеет ли ghettoVCB делать инкрементальные бэкапы?
— если бэкапить на другой ESXI хост — будет ли по сети гоняться полный размер VM или только используемая часть тонких дисков?
— тот же вопрос для NFS — будет ли по сети гоняться полный?
— вы пишете про дедупликацию — но дедупликация обычно делается на стороне хранилища. Значит, сначала надо по сети отправить полный размер виртуалки, и только уже на хранилище оно дедуплицируется. Так?Sn0WLi9ht
10.10.2016 18:48+1— Инкрементальные не умеет, но по сети гонятся только данные (т.е. thin файл).
— На другой хост нельзя бекапить, только на подмонтированное хранилище (то что можно указывать в путях бекапа утилите, т.е. это должен быть либо NFS сторадж, либо iscsi/das)
— Да, дедупликация на стороне хранилища (нужно какой нибудь ZFS использовать), потому как самый главный недостаток ghettoVCB невозможность делать инкрементальные бекапы, только полные либо thin.
Есть еще ряд недостатков:
— Бэкап делается при помощи снятия снапшота, т.е. изменения VM начинают писаться в дельта-файл, а основной файл диска VM замораживается и копируется на бекап сторадж, после копирования ESX сливает содержимое изменений дельта файла в основной файл VM — и тут могут наблюдаться серьезные тормоза, зависит от вашего железа, размера VM, количества изменений внесенных в дельта файл и сопутствующих параметров. В основном я ставлю бекап на периоды низкой активности (на ночь). В принципе, на сколько я знаю, все виды бекап систем работают именно таким способом, это ограничения API — иными словами ghettoVCB не лучше и не хуже в этом плане коммерческих систем.
— Потеря содержимого оперативной памяти. По идее в VMWare есть механизм работающий через VMWare Tools который позволяет минимизировать последствия (принудительный сброс дисковых буферов операционной системы и т.д., но не всегда корректно работает, нужно это учитывать). В этом плане думаю так же нет отличий от коммерческих систем.
— Думаю хорошей комбинацией является сочетание классического бекапа данных изнутри VM и ghettoVCB
BrSlava
11.10.2016 19:51ghettoVCB — отличный инструмент, но с версией ESXi 6 не хочет работать.
> В скрипте нужно допилить возможность бекапа для более высоких версий (достаточно вставить нужные версии ESX), это должно быть просто.
Не поделитесь как его просто допилить?Sn0WLi9ht
12.10.2016 11:48Я посмотрел версию которая сейчас актуальна и судя по содержимому скрипта, там появилась поддержка 6-й версии https://raw.githubusercontent.com/lamw/ghettoVCB/master/ghettoVCB.sh
Если хочется самому поправить, то нужно в исходном коде найти проверки версий, и добавить нужную версию. Например:
заменить наif [[ "${VER}" == "4" ]] || [[ "${VER}" == "5" ]] ; then
и т.д.if [[ "${VER}" == "4" ]] || [[ "${VER}" == "5" ]] || [[ "${VER}" == "6" ]] ; then
ruslanmatrix
11.10.2016 10:14Наизобретали велосипедов…
Посчитайте TCO — стоимость времени админа на уставновку и настройку не популярного продукта, обслуживание системы год, поиск нового сотрудника, который знает продукт или затраты на обучение, передачи дел. Если не в 100%, то 99%, что это дороже покупки SBE VE за 50-55 000? с годовой поддержкой вендора.
И перенести можно и бэкапить с помощью агента на любом гипервизоре даже без API. Хоть из Amazon.
90 дней для тестирования бесплатно.
ruslanmatrix
11.10.2016 22:27https://habrahabr.ru/company/symantec/blog/267159/
Смотрим дату публикации и читаем
можно создать в виртуальной среде клон физического сервера с возможностью его быстрого восстановления (Instant Recovery) буквально одной кнопкой. Именно это реализовано в Backup Exec 15.
Всегда рад помочь в эффективном решении задач по серверам HP, виртуализации Vmware, бэкапу Symantec/Veritas/Veeam.navion
11.10.2016 23:56Не знаю, что имел в виду маркетолог по той ссылке, но официальной документации я больше доверяю.
mikkisse
Спасибо за статью.
В принципе, перенос VM на другой хост ESXi можно было сделать следующим образом:
1. Поднять второй сервер с лицензией evaltuion
2. С помощью vCenter Converter перенести свои виртуальные машины на этот хост
3. Накатить стандратную лицензию после миграции
И если я правильно помню, vCenter converter умеет работать с тонкими дисками