Как бесплатно создать резервную копию виртуальных машин Citrix Xen с помощью Xen-pocalypse (Bash)

Вам когда-нибудь нужно было создавать резервные копии ваших виртуальных машин Citrix Xen (ВМ), но вы не хотели обанкротить банк? В HTG есть только сценарий bash для вас с Xen-pocalypse.

Изображение от h.koppdelaney, Застрял в Custom и Hotfortech.

Одна из приятных вещей в Citrix Xen заключается в том, что многие его функции являются бесплатными . С учетом вышесказанного, если вы хотите использовать функцию «Автоматическая защита и восстановление виртуальных машин», вам придется начать платить за «Предварительную» лицензию. Даже в этом случае вы платите только за резервные копии на уровне диска, которых недостаточно для многих типов рабочих нагрузок, таких как Active Directory, Базы данных и т. Д. Чтобы преодолеть это, вам может потребоваться «Снимок оперативной памяти и восстановление», который может сохранить все состояние машины, включая содержимое оперативной памяти. Однако эта функция является частью выпусков «Enterprise» и «Platinum», которые еще дороже. Дело не в том, что мы в HTG отвергаем ценность истинного программного обеспечения для резервного копирования, но если у вас ограниченный бюджет и вы не возражаете против простоя операции резервного копирования, вы можете счесть Xen-pocalypse вполне разумным решением. прежде чем сделать бюджетное обязательство.

Обзор

«Вариант использования»: у вас есть пара виртуальных машин, для которых требуется резервное копирование. «Выключение виртуальной машины и ее экспорт в виде файла» из «Xen Center» с помощью щелчка правой кнопкой мыши работает нормально, но вы хотите, чтобы этот процесс происходил автоматически и по расписанию. Этот скрипт Bash использует команду «XE» для выполнения своих обязанностей. XE – это интерфейс командной строки (CLI) Xen, автоматический эквивалент для «правых щелчков» в «Xen Center». Мы будем вызывать скрипт из Cron, который предоставит часть «планирования». В простейшем виде поток резервного копирования:

• Выключите целевую ВМ.
• Экспортируйте виртуальную машину как файл в папку резервной копии.
• Если виртуальная машина была включена, то до начала резервного копирования она будет включена снова.

Давайте взломать 🙂

Получить сценарий

Xen-pocalypse можно свободно получить из github, используя обычные методы git. С учетом сказанного, если вы еще не разбираетесь в git, вы можете получить zip-файл по этой ссылке. Поскольку сценарий должен запускаться на одном из ваших серверов Xen, вы должны извлечь его там, чтобы сохранить права на выполнение.

Wget https://github.com/aviadra/Xen-pocalypse/archive/master.zip
распаковать мастер

Хотя вышеперечисленное сработает, вам рекомендуется использовать метод GIT, чтобы вы могли извлечь выгоду из будущих обновлений.

Получить SendEmail (необязательно)

В прошлом мы писали о Perl-программе SendEmail, поэтому повторять здесь не нужно. Достаточно сказать, что в Linux он работает так же, как и в Windows.

Хотя включение электронной почты не является обязательным, настоятельно рекомендуется, потому что тогда сценарий сможет:

• Сообщите вам, когда он начал и закончил работу.
• Оповещать вас о любых ошибках, которые он смог обнаружить и обработать.
• Сообщить о дисквалификации резервных копий из-за нехватки места. (Это поведение может быть отключено, если не желательно)

Загрузите его на сервер Xen и распакуйте.

Wget http://caspian.dotconf.net/menu/Software/SendEmail/sendEmail-v1.56.tar.gz
tar xvzhf sendEmail-v1.56.tar.gz

Обратите внимание на место, где вы извлекли его. Он понадобится вам для файла настроек.

Определение тегов

Citrix Xen дает вам возможность настроить «Пользовательские поля» для возможностей фильтрации. Мы создадим поля и затем заполним их информацией, используемой Xen-pocalypse. Xen-pocalypse распознает 3 контрольных тега, которые обозначают имя тега для резервного копирования и отношения родитель-потомок. Если вы не собираетесь использовать метод ввода файла, вы ДОЛЖНЫ создать хотя бы поле имени резервного тега.

Для этого откройте свойства сервера или даже виртуальной машины. На панели навигации выберите «Пользовательские поля».

Если вы впервые определяете отношение (как в примере выше), у вас не будет полей для ввода данных, поэтому вам нужно их создать. Для этого нажмите «Изменить пользовательские поля» в появившемся диалоговом окне, нажмите «Добавить…»

Создайте три (3) поля типа «Текст». Один будет называться «BackupTAG», а другие – «Parent» и «Children».

Примечание: Имена пользовательских полей были «жестко запрограммированы» в скрипте, поэтому вы НЕ ДОЛЖНЫ отклоняться от написанного выше, если только вы не измените соответствующий код.

Как только все поля будут созданы, вы должны увидеть:

Закройте окно. Теперь вы должны заполнить поля «BackupTAG», «Parent» и «Children», как показано на рисунке ниже.

Теперь все, что вам нужно сделать, это указать, какие виртуальные машины принадлежат тому или иному «BackupTAG».
Например, в компании, где создавался сценарий, у нас были виртуальные машины, резервное копирование которых осуществлялось еженедельно в четверг и пятницу, расписание для наших виртуальных машин Atlassian, а некоторые – резервное копирование только ежемесячно. Итак, наш обзор выглядел так:

Где, например, «Weekly-Fri» – это текст, который мы ввели в «BackupTAG» «Custom Field». Аккуратно, а? 🙂

Родители и дети (необязательно)

Настоящая красота этого скрипта в том, что он поддерживает отношения «родитель» к «ребенку». Таким образом, можно установить список «дочерних» виртуальных машин, которые будут отключены и сохранены перед родительским, и что эти дочерние элементы будут включены только после того, как родитель закончит резервное копирование и будет возвращен обратно. на. Это полезно в тех случаях, когда отключение родительской виртуальной машины приведет к недоступности дочерней службы. Это означало бы, что служба на дочерней виртуальной машине будет недоступна дважды: один раз для процесса резервного копирования дочернего объекта и один раз для родительского. Создание этих отношений преодолевает эту проблему.

Например, все наши виртуальные машины Atlassian использовали одну виртуальную машину базы данных (DB), которая также была настроена для резервного копирования. Таким образом, отметив, что виртуальная машина БД является «родительской» для других виртуальных машин, можно обеспечить правильный порядок выключения -> резервное копирование -> запуск.

На момент написания этой статьи у этой функции было несколько предостережений:

1. Имена виртуальных машин, которые должны иметь такую ​​связь, не могут содержать пробелы. Вам придется удалить пробелы из имен виртуальных машин, поскольку они будут разделены пробелами, как в примере ниже.
2. Там может быть только один родитель. Обозначение более одного даже не планируется, не говоря уже о проверке.

Чтобы создать это отношение, перейдите в свойства виртуальной машины. Если это «родитель», напишите, кто его дети, а если это «ребенок», напишите, кто его родитель. Например:

Примечание. Если не назначить родителя для ребенка, это может привести к тому, что ребенок запустится до того, как его родитель будет готов, и может вызвать его резервное копирование дважды.

Метод FILE (Необязательно)

По историческим причинам Xen-pocalypse также поддерживает получение списка виртуальных машин для резервного копирования в виде текстового файла. Пока «код» все еще присутствует, функциональность значительно уступает методу TAG, и поэтому он не рекомендуется. С учетом вышесказанного, если вы по какой-либо причине предпочитаете использовать метод списка, применяются следующие ограничения:

1. Имена виртуальных машин не могут содержать пробелов или специальных символов.
2. В каждой строке может быть только одно имя виртуальной машины.
3. Пустые строки не допускаются.

Чтобы создать список, скопируйте имя виртуальной машины из центра Xen или выполните на хосте Xen:

xe vm-list | grep name-label | awk '{print $ 4}' | сортировать

Скопируйте приведенный выше список в обычный текстовый файл.

Местоположение резервной копии

Во время случайного поиска в Citrix Xen я обнаружил, что репозитории хранилищ (SR) доступны для использования в «/ var/run/sr-mount /% UUID%», где UUID – это уникальный идентификатор SR, который может быть полученный из GUI.

Это означает, что мы можем использовать обычный мастер «Далее -> Далее -> Готово», чтобы создать монтирование в нужное место резервной копии, а затем заставить скрипт использовать этот путь (в отличие от манипуляций с монтированием из командной строки), но делать так же выходит за рамки этого руководства.

Для создания нового «монтирования» щелкните правой кнопкой мыши имя сервера и выберите «Новый SR».

В этом примере мы укажем Xen на общий ресурс Windows, поэтому выберите «Общий доступ к файлам Windows (CIFS)»:

Завершите следующее -> Далее -> Готово.

Получите UUID SR

Чтобы получить UUID SR, просто нажмите на его имя в Центре Xen и перейдите на вкладку «Общие».

Чтобы скопировать UUID, просто щелкните по нему правой кнопкой мыши и выберите «Копировать».

Имея эту информацию под рукой, вы готовы редактировать файл настроек.

Настройте файл настроек.

Проект Xen-pocalypse поставляется в комплекте с шаблоном файла «settings». Этот шаблон должен быть отредактирован в соответствии с вашими настройками и передан в качестве первого аргумента скрипту. Файл настроек обозначает следующее:

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

Местоположение места назначения резервной копии. Если вы следовали этому руководству, вам нужно только заменить% UUID% на SR, как это было получено выше.

Расположение SendEmail . Если вы решили включить электронную почту, вам нужно указать, где вы извлекли исполняемый файл perl здесь.

Данные электронной почты – Опять же, если вы включили электронную почту, вам необходимо определить такие детали, как: Кому, От, Имя сервера/IP и т. д.

Сжатие . По умолчанию для этого параметра установлено значение «Нет», поскольку при его включении будет создаваться файл резервной копии меньшего размера, а также будет выполняться процедура резервного копирования в течение значительно более длительного периода времени.

Проверить наличие свободного места в месте назначения. Сценарий будет проверять, что создание резервной копии виртуальной машины не приведет к уменьшению свободного места в хранилище ниже 10 ГБ. Это сделано для того, чтобы обеспечить резервное копирование большинства виртуальных машин вместо одной очень большой виртуальной машины. Расчет выполняется с использованием общего размера диска всех жестких дисков, связанных с виртуальной машиной.

Отладка . По умолчанию отладка отключена со значением «0» (ноль). Вам не нужно включать это, но если вы это сделаете, дополнительная информация отмечена в разделе устранения неполадок.

Выполнение/Планирование

В простейшей форме вызов Xen-pocalypse будет выглядеть так:

./ Xen-backup.sh settings.cfg еженедельно в пятницу

Где в приведенном выше случае, мы находимся внутри каталога, в котором находится скрипт и файл настроек. «Тег», который будет искать скрипт, – «Weekly-Fri».

Как отмечалось выше, мы будем использовать Cron для планирования выполнения. Прежде чем мы перейдем к настройке, настоятельно рекомендуем настроить уже установленный пакет SSMTP на вашем сервере Xen. Хотя это необязательный шаг, это даст вам коллектор обратной промывки. Наличие такого «коллектора обратной промывки» может предупредить вас о том, что скрипт не в состоянии.

Войдите в редактирование cron больше, выполнив:

crontab -e

Если вы выполнили приведенные выше инструкции и хотите добавить резервную копию по расписанию на пятницу в 18:01 (6:01 PM), введите следующее:

01 18 * * пт /root/Xen-pocalypse-master/Xen_Backup.sh /root/Xen-pocalypse-master/settings.cfg еженедельно пт

Вышеприведенное верно, если ваш сценарий и файл настроек находятся в «/ root/Xen-pocalypse-master /».

Поиск проблемы

Хотя я приложил немало усилий, чтобы сделать сценарий максимально простым и надежным, «Мир – это большая лаборатория». Приведенная ниже информация может помочь вам определить источник ваших проблем.

Прогресс

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

while [-e/dev/null]; do для VM в "$ (xe task-list | grep uuid | awk '{print $ 5}')"; do xe task-param-get param-name = progress uuid = $ VM; сон 1; сделанный; сделано

Чтобы остановить просмотр, используйте Ctrl + C, чтобы затормозить «цикл».

Вход

Вся «регистрация» собирается хостом Xen, выполняющим скрипт в механизме системного журнала. Это, конечно, можно просмотреть с помощью:

less + F/var/log/messages

Вы ищете ключевое слово «Xen-pocalypse».

Примечание. Citrix установил двухдневную политику хранения для системного журнала своих серверов. Вы можете иметь это в виду для посмертных.

Отладка

Как отмечено в сегменте файла настроек, есть директива для включения отладки. Включение отладки приведет к тому, что сценарий будет выводить подробное ведение журнала на консоль и кастрировать его из отправки электронных писем и фактического выполнения экспорта, если только не установлены соответствующие флаги. Возможные флаги отмечены в шаблоне файла настроек, и они позволяют вам детально определить, что вы хотите отлаживать.

Я надеюсь, что вам не понадобилась отладка, и вы пожинаете плоды моего труда 🙂

Тяга, мой человек, ты собираешься стать десептиконом номер один …