Меню

ghettovcb esxi 6 настройка

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 5090 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

Использование ghettoVCB для резервного копирования виртуальных машин VMware ESX / ESXi.

Использование ghettoVCB для резервного копирования виртуальных машин VMware ESX / ESXi.

Автор: Александр Прилепский
Дата: 28/02/2011

Реклама:

Копировать руками машину каждый раз, когда нужно внедрить какое-то оборудование, или просто для сохранения данных, это безумно неудобно. Вот для этого и была придумана технология автоматизированного бэкапа, написанная энтузиастами на скриптах perl: ghettoVCB.

Ниже выложен гайд по установке скриптов, а также приведены конфиги сохранения скриптов как локально, так и на удаленном сервере с использованием хранилища сетевой файловой системы (NFS).

В обоих вариантах нам необходимы программа для соединения с хостом VMware ESX по SSH, например Putty (http://www.chiark.greenend.org.uk/

Для начала, выкладываем файл ghettoVCB.tar.gz на Datastore, после чего заходим в Putty, коннектимся к серверу ESX и проделываем следующие действия:

# cd vmfs/volumes/
vmfs/volumes/ # сp ghettoVCB.tar.gz /
vmfs/volumes/ # cd /

# tar -zxvf ghettoVCB.tar.gz
ghettoVCB/
ghettoVCB/ghettoVCB.conf
ghettoVCB/ghettoVCB.sh
ghettoVCB/ghettoVCB-vm_backup_configuration_template

# cd ghettoVCB
ghettoVCB # vi vmlist

Откроется файлик (пока еще не созданный) со списком тех машин, которые нужно забэкапить (пока еще пустой :). Для ввода и редактирования информации жмем “a”, чтобы применить настройки Esc. Чтобы выйти с сохранениями :wq чтобы без :q!

Вводим имена машин, далее вводим vi log и, ничего не изменяя в пустом файле, жмем :wq. Далее следует отконфигурить файл ghettoVCB.conf. Зайдя в неко командой vi (vi ghettoVCB.conf), мы увидим следующее:

Не стоит пугаться обилия параметров, все они легко настраиваются и имеют особую важность. Итак, по порядку: Параметр, определяющий директорию создания бэкапов. В моем случае, я указал: /vmfs/volumes/Datastore. Определяет формат забэкапленного диска, возможны варианты: zeroedthick, eagerzeroedthick, thin, 2gbsparse (см. типы дисков).

Определяет количество бэкапов на одну машину (каждый последующий будет удаляться скриптом). Если, например, скрипт (рассказывается ниже) будет бэкапить машины каждый час, то при указании числа 24, мы получим бэкапы каждый час на протяжении одного дня.

Определяет, будет ли машина выключаться перед бэкапом (enabled=1 disabled=0) (скрипт поддерживает бэкап при включенной машине).

Отключение дисков на время бэкапа (enabled=1 disabled=0).

При включенном предыдущем параметре, определяет количество времени (1 единица=60 секунд), прежде чем скрипт выполнит принудительное отключение диска.

При включенном параметре POWER_VM_DOWN_BEFORE_BACKUP, определяет количество времени (1 единица=60 секунд), прежде чем скрипт выполнит жесткое выключение (без использования ShutDown Guest) .

Параметр, при включении которого забэкапленные файлы будут помещаться в архиве (enabled=1 disabled=0) (Внимание: это тестовый параметр для данной версии скрипта, мой совет его отключать, так как есть риск потери не только файлов бэкапа, но и файлов машины).

Формат диска машины (возможны: buslogic, lsilogic).

Параметры, отвечающие за снимки памяти, и если первый параметр “1”, то будет ли переведена машина на этот период в режим ожидания.

Все эти параметры нужны, если мы планируем создать директорию с бэкапами на удаленном сервере. Этими параметрами мы настраиваем доступ к NFS хранилищу (его местонахождение, директория на локально сервере и т.д.) Если создаем директорию бэкапа на том же DataStore, проигнорируем эти параметры.

Данный параметр отображает, сколько минут будет дано время на создания снапшота работающей машины, после чего скрипт будет отключен (если повременной, то только этот бэкап не будет создан, далее всё пойдет в штатном режиме). Данный параметр необходим, если по каким либо причинам машина не сделала снимок, прежде чем переходить в режим ожидания, для того, чтобы не потерять данные машины в режиме работы.

Следующие параметры будут отсылать логи на мэйл, при учете того, что в самом скрипте изначально прописаны данные smtp, pop и другие настройки.Данные параметры являются экспериментальными и не будут работать без дополнительных настроек. При желании отсылки логов на свой мэйл, требуется ознакомиться с основами perl и досконально изучить данную статью: http://www.waldrondigital.com/2010/05/11/ghettovcb-e-mail-rotate-logs-batch-file-for-vmware/

Мой совет – не заморачиваться.

Далее я привожу два вида настройки этих параметров без особых углублений (1 – локально, 2 – через сервер NFS)

Чтобы проверить данный скрипт можем запустить его разово. Для этого ознакомимся с параметрами запуска скрипта: Запустим, например, всё это со следующими параметрами: В логах, при правильно настроенном конфиге мы увидим примерно следующее:

Самое главное: это последние 3-4 строчки: ###### Final status: All VMs backed up OK! ######

Читайте также:  настройка человека на лучшее

Если видим такое, бэкап прошел успешно. Если видим крики об ошибках, читаем, где накосячили.

  • ВМ, которые нужно бэкапить, НЕ ДОЛЖНЫ содержать снапшотов (см. тут, почему снапшоты — это плохо).
  • Кривой путь к хранилищам.
  • При включенном NFS режиме кривая настройка записи данных на NFS.

После всего этого необходимо настроить режим создания бэкапов по времени. Для этого необходимо воспользоваться параметрами CronTab. Для этого проделываем следующее:

Откроется повременной запуск скриптов. На новой строчке впишем следующее:

Файл crontab состоит из строк, содержащих шесть полей. Поля разделяются пробелами или символами табуляции. Первые пять полей — целочисленные шаблоны, задающие:

  • минуту (0-59),
  • час (0-23),
  • день месяца (1-31),
  • месяц года (1-12),
  • день недели (0-6, причем 0=воскресенье).

Шестое поле в строке файла crontab — строка, выполняемая командным интерпретатором в указанные моменты времени. Символ % (процент) в этом поле, если он не замаскирован \ (обратной косой), преобразуется в символ новой строки.

Только первая строка (до символа % или до конца строки) поля команды выполняется командным интерпретатором. Другие строки передаются команде как стандартный входной поток. Любая строка, начинающаяся символом #, считается комментарием и игнорируется. Файл не должен содержать пустых строк.

Например, если мы хотим, чтобы бэкапы происходили, каждый день по будням в 2 часа 15 минут, наша строка должна выглядеть следующим образом:

Чтобы оставлять комментарии, вы должны быть зарегистрированы на сайте.

Зал Славы Рекламодателя Все сайты о виртуализации:

Вебинары VMC о виртуализации:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

источник

Резервное копирование виртуальных машин в VMware ESXi

В этой заметке будет рассмотрено, как создать резервную копию виртуальных машин с помощью скрипта ghettoVCB. Скрипт предназначен для создания бэкапов виртуальных машин в ESX(i) 3.x, 4.x, 5.x и 6.x. Данный способ резервного копирования в отличии от других программных продуктов является абсолютно бесплатным.

Для хранения резервных копий ВМ можно использовать накопители, поддерживающие следующие протоколы:

  • NFS (Network File System), с тем же диапазоном IP-адресов и физически расположеннй в той же сети, что и интерфейс управления VMware (Management Network VMkernel Port),
  • iSCSI (Internet Small Computer System Interface), с тем же диапазоном ардесов и физически расположенный в той же сети, что и интерфейс (iSCSI VMkernel).

Но ghettoVCB поддерживает только монтирование и размонтирование NFS-дисков. Для iSCSI следует заранее смонтировать Disk/LUN, а параметры ENABLE_NON_PERSISTENT_NFS и UNMOUNT_NFS установить в нулевое значение (см. ниже).

В данном примере буедем копировать на NFS с IP-адресом 192.168.3.200, тогда как интерефейс управления гипервизором (Management Network VMkernel) имеет адрес 192.168.0.222 и маску подсети 255.255.0.0.

Настройка резервного копирования.

Итак, первое, что нужно сделать — это включить доступ по SSH к консоли гипервизора: открываем VMware vSphere Client, выбираем хост, открываем вкладку ‘Configuration’ и, как показано на скриншоте:

Во-вторых, убедимся, что на вашем сервере NFS включена опция ‘ async’, существенно ускоряющая процесс копирования. Правда, за скорость приходится платить: есть риск потерять данные в случае крэша NFS-сервера. Если такая вероятность, все же, есть — используйте ‘sync’. В остальных случаях:

В третьих, скачиваем скрипт ghettoVCB с github по клику на ZIP-архив и заргужаем его на ESX/ESXi хост, используя scp, или WinSCP. Советую расположить подальше от корневой директории: на ваш datastore, в папку с виртуальными машинами — будет идеально. У меня это: /vmfs/volumes/datastore1.

Теперь логинимся по SSH в консоль гипервизора под учетной записью root, распаковываем архив и выставляем права:

Создать файл конфигурации необходимо непосредственно в самой консоли гипервизора, используя vi. Ни в коем случае не редактируйте конфигурационный файл в windows-приложениях (таких как: Notepad, Notepad+) с последующей заливкой на хост из-за разных комбинаций кодов перевода строк (CR+LF / LF). Так же во избежание ошибок в работе скрипта избегайте лишних пробелов в конце строк и пустых отступов.

Читайте также:  принтер canon pixma ip4200 установка

По окончанию редактирования последовательно нажмите: Esc, :, w, q, Enter.

Описание параметров следующее:

VM_BACKUP_VOLUME — путь на сервере ESXi, куда будет монтироваться NFS раздел (или где будет создана резервная копия виртуальных машин — см. параметр ENABLE_NON_PERSISTENT_NFS)

DISK_BACKUP_FORMAT — формат VMDK диска (zeroedthick, eagerzeroedthick, thin, 2gbsparse).

VM_BACKUP_ROTATION_COUNT=4 — количество хранимых бэкапов.

POWER_VM_DOWN_BEFORE_BACKUP=0 — отключать машину перед бэкапом (0=не отключать). Cкрипт может так же копировать и включенные ВМ.

ENABLE_HARD_POWER_OFF=0 — отключать жесткие диски перед бэкапом. Eсли не установлены VMware Tools, то “жесткое” отключение ВМ (hard power off).

ITER_TO_WAIT_SHUTDOWN=3 — если ENABLE_HARD_POWER_OFF=1, то количество минут, прежде, чем скрипт произведет “жесткое” отключение ВМ (hard power off).

POWER_DOWN_TIMEOUT=5 — количество минут, которые скрипт будет ждать при отключении ВМ, прежде, чем проигнорирует её состояние и приступит к резервному копированию.

SNAPSHOT_TIMEOUT=15 — количество минут, которое скрипт будет ждать при создании копии конкретной ВМ, прежде, чем проигнорирует её (в случае каких-либо сбоев в резервном копировании).

ENABLE_COMPRESSION=0 — включение компрессии (0=отключено и остается на zfs). В ESXi 3.x / 4.x / 5.x, существует ограничение максимального размера виртуальной машины для сжатия. При попытке восстановления ВМ свыше ограничений данные могут быть потеряны. Внимательно тестируйте процесс восстановления, прежде, чем перейти к производственным системам.

VM_SNAPSHOT_MEMORY=0 и VM_SNAPSHOT_QUIESCE=0 — используются только для снятия снапшотов с оперативной памяти. Eсли первый параметр “1”, то будет ли переведена машина на этот период в режим ожидания. Первоначально параметр добавлен с целью отладки, а сама опция никак не используется при восстановлении ВМ: любая виртуальная машина, будь то включенная (online), или выключенная (offline), при восстановлении из бэкапа окажется в сосотянии offline.

VMDK_FILES_TO_BACKUP=»my1.vmdk»,”my2.vmdk” — задает список VMDK с определенной VM. Если список пуст, то будут скопированы все VMDK (=all).

ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0 — определяет, будет ли создаваться бэкап ВМ со всеми снапшотами.

VM_SHUTDOWN_ORDER=vm1,vm2,vm3 — определяет в каком порядке будут выключены ВМ (если между ними есть какая-либо зависимость).

VM_STARTUP_ORDER=vm3,vm2,vm1 — определяет порядок запуска ВМ.

ENABLE_NON_PERSISTENT_NFS=1 — позволяет подключать NFS-диски (NFS share) для создания бэкапа. Если 0, то параметры UNMOUNT_NFS, NFS_SERVER, NFS_MOUNT, NFS_LOCAL_NAME и NFS_VM_BACKUP_DIR будут проигнорированы.

UNMOUNT_NFS=1 — определяет размонтировать ли NFS-диск по завершению создания бэкапов ВМ.

NFS_SERVER=192.168.3.200 — IP-адрес или имя хоста NFS-диска. Если на сервере ESXi уже есть подключенный NFS диск с такими же координатами (сервер/путь), то диск не подключится.

NFS_MOUNT — путь к NFS диску (NFS export path).

NFS_LOCAL_NAME — имя, которое будет присвоено подключенному диску (datastores ID);

NFS_VM_BACKUP_DIR — путь, где будут создаваться копии ВМ (относительно VM_BACKUP_VOLUME).

RSYNC_LINK=0 — предназначено для синхронизации бэкапов по Rsync. Подробности расписаны здесь.

EMAIL_LOG=1 — определяет, отправлять ли логи по почте.

EMAIL_DEBUG=1 — определяет, отправлять ли отладочные логи (debug logs) по почте.

EMAIL_SERVER, EMAIL_SERVER_PORT, EMAIL_TO, EMAIL_FROM — соответственно емейл сервер, порт, адрес отправки и отправителя (например, если потребуется определенная запись домена для отправителя в зависимости от конфигурации сервера электронной почты).

Продолжим настройку. Cмотрим список активных ВМ и добавляем необходимые в список:

Для отправки логов на почту необходимо разрешить исходящий трафик в firewall на сервере ESXi, добавив строчки в конце xml-файла:

Перечитываем правила фаервола и проверяем:

Для того, чтобы назначить резервное копирование по расписанию, необходимо добавить в cron строку с командой резервного копирования. Но в нашем случае строка содержит вычисление номера недели в текущем месяце (для того, чтобы не захламлять сервер). Если добавить это выражение сразу в cron, то его значение не вычислится. Поэтому сначала нужно создать отдельный shell-скрипт, вызывающий ghettoVCB с выражением для подсчета номера недели:

Если нет необходимости в понедельной ротации логов, или расписание будет настроено несколько иначе (например, бэкап раз в месяц), то выражение

из start.sh можно убрать. Разрешаем запуск:

Бэкапить будем каждую субботу в час ночи. Системное время задается в UTC, поэтому его нужно внести с учетом поправки на Ваш часовой пояс. В моем случае — это UTC+3, значит нужно внести время на три часа раньше, то есть в пятницу в 22:00. Но если мы добавим строчку в crontab следующим образом:

то все настройки потеряются при перезагрузке сервера ESXi. Поэтому команды на изменение настроек cron’a необходимо добавить в загрузочный скрипт:

Читайте также:  установка линукс на флешку из под windows

Аналогичная ситуация и с настройками firewall сервера ESXi: для их сохранения придется создать VIB-пакет с помощью утилиты VIBauthor и установить его на сервер ESXi. К сожалению, VIBauthor распространяется только для 32-х битных (нет поддержки 64 бит) RPM-based дистрибутивов Linux. Я буду использовать CentOS 6.7 i386 Minimal, вы можете использовать дистрибутив SUSE Linux Enterprise 11 SP2, рекомендованый в документации. Для того, чтобы не ругалось при устаеновке VIBauthor на зависимости (а точней, разрядность) используем ключ “nodeps” и далее подготавим дерево директорий для сборки пакета:

Фактически, то, что за папкой payload1 — это желаемый путь расположения пакета на сервере ESXi. Теперь создаем описание пакета:

и непосредственно само правило firewall’а:

Теперь можно собрать пакет:

скопировать его с помощью SCP на сервер ESXi:

установить и проверить, что получилось:

По желанию можно воспользоваться моим VIB-пакетом.

Для того, чтобы устанавливать подобные дополнения нужно, чтобы на сервере ESXi параметр Acceptance Level был выставлен в значение “Community Supported”. Для этого в клиенте vSphere открываем, как показано на скриншоте:

И финальный штрих: завершаем процесс настройки созданием бэкапа настроек сервера ESXi:

Файл настроек сервере ESXi хранится в /bootbank/state.tgz и предназначен для восстановления в случае внезапного завершения работы, или перезагрузки сервера ESXi (читайте здесь). Если настройки сервера не меняются, то можно скопировать этот файл вручную, в противном случае — настройки сервера ESXi (stage.tgz и папку ghettoVCB-master) будем так же бэкапить каждую неделю. Для этого добавим в конец start.sh перед строкой “exit 0” строки:

Создание резервных копий ВМ.

Проверить настройки и запустить тестовое создание бэкапа в ручную можно командой:

Для отдельной ВМ с именем ‘MyVirtualMachine’:

-a — создание бэкапа все ВМ хоста;
-f — укзать список ВМ;
-m — имя ВМ для бэкапа;
-c — конфигурация директории бэкапа;
-g — путь к файлу конфигурации;
-l — создание файла лога;
-w — рабочая директория скрипта;
-d — уровень детализации логов (debug level): info, debug, или dryrun (по умолчанию: info).

Бэкап виртуальной машины представляет из себя подкаталог — _ , содержащий .vmx (файл конфигурации ВМ), непосредственно сами .vmdk и status.ok, содержащий в себе сообщение об успешном завершении создания резервной копии.

Восстановление ВМ из резервных копий.

Следует понимать, что если бэкап ВМ производился во включенном состоянии, то после восстановления ВМ будет абсолютно так же, как было бы после крэша — не исключена потеря данных.

Подключаемся к серверу ESXi по SSH, монтируем NFS с бэкапами и проверяем результат. Формат команды для монтирования NFS следующий:

Для ESXi 3.x/4.x подробно расписано здесь. В моем примере NFS монтируется следующей строчкой:

Для указания путей при восстановлении ВМ нельзя использовать симлинки. Если в конфигурации использовать пути вида: /vmfs/volumes/datastore1/esxi/ … /VM_name/ , то при попытке восстановить ВМ получим ошибку:

Фактически, такое сообщение появляется тогда, когда скрипт не находит бэкап ВМ.

Для того, чтобы задать путь без использования симлинков необходимо узнать UUID устройств. Следующая команда выводит список каждого LUN, подключенного к серверу ESXi и его сопоставление vmfs (Volume Name) к UUID:

Таким образом вместо “backup” и “datastore1” можно использовать соответствующий UUID:

backup: 9108f6f9–353aeed8;
datastore1: 56b74f4f-85fc58fa-87fe-94de8066eda2.

Подробную информацию про идентификацию дисков и файловых систем в ESX(i) можно получить здесь.

где:
-c — путь к списку восстанавливаемых машин.
-l — путь расположения логов.

Поскольку резервная копия ВМ представляет из себя набор образов .vdmk и файл-конфигурации .vmx, то можно просто скопировать данные и исправить .vmx:

Через vSphere клиент открываем, как на скриншоте ниже:

на файле .vmx жмем правую кнопку мыши и выбираем “Add to inventory”.

Troubleshooting.

Для того, чтобы создать резервную копию с отладочной информацией необходимо вызвать ghettoVCB с ключем: -d debug

Для отладки процесса восстановления:

где: -d — уровень детализации при отладке (debug level) (1–2). При включении отладочной информации восстановление не произойдет.

Могут возникнуть ситуации, когда потребуется прервать выполнение ghettoVCB.sh, запущенного в ручном (интерактивном) режиме. Нажмите cntrl+C для остановки родительского процесса и далее:

Для остановки ghettoVCB, запущенного в неинтерактивном режиме:

и завершить оба дочерних процесса по их PID:

Если виртуальная машина находилась в процессе резервного копирования, то открыт дополнительный процесс — vmkfstools:

источник

Расскажите о нас

Добавить комментарий

Adblock
detector