Как-то появилось у меня несколько персональных проектов, которые требовали относительно много дискового места — около 2TB. Подходящих VPS не нашлось (мало кто предлагает много HDD места), поэтому я взял выделенный сервер у OVH, поставил там ESXI 5.5 с бесплатной лицензией и всё работало.
Через некоторое время, с развитем проектов, я стал настраивать админские фишки — мониторинг, бэкап, и выяснил, что оказывается сервер, в котором мне обещали Soft RAID, и на который хостер (OVH) накатил свой образ ESXI — без RAID! То есть просто 2 диска. Ну да, теперь вот я знаю, что ESXI не поддерживает Soft RAID, только Hard. Стало неуютно. Да и 2TB стало не хватать. В общем взял я себе сервер побольше, с аппаратным RAID и поставил туда ESXI 6.0.
И возникло две задачи, решение которых я тут опишу:
Скажу сразу, что обе эти задачи легко решаются, если есть хотя бы минимальная платная лицензия ESXI. Дело в том, что «родной» Backup API в бесплатной версии ESXI выключен. Поэтому приходится находить другие пути.
С платной лицензией есть вариант миграции через vCenter. Ещё есть бесплатная версия Veeam Backup, которая позволяет делать бэкапы и переносить виртуальные машины с одной системы на другую и при этом не требуется их останавливать. Но с бесплатной лицензией ESXI, текущая версия — Veeam 9 — не работает вообще.
Ещё есть решение от HP — VM Explorer, у которого есть бесплатный Free Edition.
VM Explorer 6.2 умеет работать с free ESXI, но:
Другое популярное решение — это open source проект ghettoVCB, но мне он показался несколько сложным для использования, да и документация выглядит немного устаревшей. Про этот проект уже писали здесь на Хабре.
Уверен, что есть и много других вариантов. Будет интересно почитать комментарии опытных админов. Хотя подозреваю, что опытные работают там, где купили нужные лицензии и не парятся…
Здесь можно просто упомянуть:
Если у вас есть опыт использование этих продуктов — поделитесь в комментариях.
Я в конечном итоге решил использовать 2 инструмента:
До версии 4.4 Xsibackup был на Github, но сейчас (версия 6.0.7) с Github'а Xsibackup убрали, теперь инсталлировать надо с сайта авторов.
В бесплатной версии:
» Полный список опций (на английском)
Локально, то есть на одном хосте, всё работает отлично: бэкапы делаются с помощью нативной утилиты 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 между хостами выглядит у меня так:
Таким же образом пока выглядит и бэкап VM от хостера к себе домой. Для этого у меня дома крутится ESXI — чтобы ovftool мог по сети передавать только полезную нагрузку.
На форумах пишут, что вроде бы есть способ копировать файлы на NFS с опцией sparse так, чтобы передавать только существующие данные, но я пока ещё не разобрался.
Способа делать инкрементальный бэкап я не нашёл.
Пока я это всё делаю вручную из консоли — переношу на другой хост, делаю первый бэкап, но со временем думаю всё настроить через крон. Может позже допишу здесь пару параграфов о том, как настраивать крон. Оригинальные инструкции вот здесь: 33hops.com/xsibackup-cron-how-to.html
Таким образом сейчас у меня первая копия лежит рядом, на том же сервере, и доступна для довольно быстрого восстановления.
Вторая копия — у меня дома, то есть, как и рекомендуют — в физически другом месте. Для восстановления придётся заливать по сети, что существенно медленнее. Но вероятность нужды в этом тоже довольно низкая.
Полное руководство на английском здесь, там же можно и скачать. Ovftool можно ставить к себе на любой компьютер, и управлять гипервизором с него. А можно и поставить прямо на ESXI хост, хотя это и не поддерживаемая возможность.
Ovftool не умеет копировать VM в горячем режиме, то есть требует, чтобы виртуальная машина была выключена. Поэтому — необходимость в Xsibackup выше.
Несколько особенностей работы Ovftool:
Ещё несколько особенностей Ovftool, только при запуске на ESXI:
Примеры использования ovftool:
Через некоторое время, с развитем проектов, я стал настраивать админские фишки — мониторинг, бэкап, и выяснил, что оказывается сервер, в котором мне обещали 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
Эта же инструкция на английском — 33hops.com/blog_xsibackup-quickstart.html
Инсталлируется Xsibackup на ESXI хост, с которого нужно делать бэкапы.
На ESXI должен быть включена служба SSH.
Регистрируетесь на сайте авторов — Download xsibackup — 33hops.com/xsibackup-vmware-esxi-backup.html
Вам на email придёт бесплатный ключ и скрипт для инсталлирования на ESXI:
secretKey у вас будет свой.
Если datastore у вас называется по другому — то надо прописать свой путь.
Увидев wget, кто-то может покачать головой, и сказать, что ставить чужой софт на ESXI хост — это несекьюрно и т.д. Однако при любом бэкапе, вы будете отдавать root пароль программе для бэкапа, то есть кому-то доверять вы будете в любом случае. При локальном копировании Xsibackup использует только shell скрипты, которые можно посмотреть и проверить…
Затем создаёте папку, куда будем складывать бэкапы — локально, или на другом сервере:
Если копировать бэкапы будет между хостами, то делимся SSH ключами:
Если хотим, чтоб был бэкапы запускались через крон, то:
Тестируем, что всё работает локально:
Чтобы протестировать работу между хостами, меняем:
Если SMTP требует TLS, то поддерживается --smtp-sec=TLS
Инсталлируется 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 хост, хотя это и не поддерживаемая возможность.
Инсталляция Ovftool на ESXI
В общем, процесс такой: сначала Ovftool ставится на Linux x64 (я делал на Ubuntu 16), а затем файлы переносятся на 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/"
