Изображение от h.koppdelaney, Stuck в Custom и Hotfortech.
Едно от хубавите неща в Citrix Xen е, че много от неговите функции са Безплатно на такса. С това казано, ако искате функцията "Автоматизирана защита и възстановяване на ВМ", ще трябва да започнете да плащате за лиценза "Advance". Дори и тогава плащате само резервни копия на ниво диск, които не са достатъчни за много видове натоварвания като Active Directory, Databases & Etc. За да преодолеете това, може да искате "Live memory snapshot and revert", което може да спести цялата състоянието на машината, включително съдържанието на RAM. Тази функция обаче е част от изданията "Enterprise" и "Platinum", които са още по-скъпи. Не че ние в HTG отхвърляме стойността на истински софтуер за архивиране, но ако сте с ограничен бюджет и нямате нищо против прекъсване на операцията за архивиране, може да откриете, че Xen-pocalypse е напълно разумно решение преди да направите бюджетния ангажимент.
Преглед
"Случай на използване": Имате няколко VM, които изискват резервно копие. "Изключването на VM и експортирането му като файл" от "Xen Center" с десния клик работи добре, но искате този процес да се осъществи автоматично и по график. Този Bash скрипт използва командата "XE", за да изпълнява задълженията си. XE е интерфейсът на командния ред на Xen (CLI), автоматичен еквивалент за издаване на "десния клик" в "Xen Center". Ще се обадим на сценария от Cron, който ще достави част "планиране". В най-простата си форма резервът е:
- Изключете целевия VM.
- Експортирайте VM като файл в резервното копие.
- Ако устройството за управление на връзката е включено, преди да започне резервното копие, то ще бъде включено отново.
Позволявам да се счупим:)
Получете скрипта
Xen-pocalypse може да бъде свободно получен от github, използвайки обичайните git методи. С това казано, ако все още не сте запознати с git, можете да вземете zip файла с тази връзка. Тъй като скриптът трябва да работи на един от вашите Xen сървъри, трябва да го извлечете там, за да се запазят разрешенията за изпълнение.
wget https://github.com/aviadra/Xen-pocalypse/archive/master.zip unzip master
Докато горните ще работят, препоръчваме ви да използвате метода GIT, така че да се възползвате от бъдещи актуализации.
Получаване на SendEmail (по избор)
Ние писахме за програмата Perl SendEmail в миналото, така че няма нужда да се повтаря тук. Достатъчно е да кажем, че работи по същия начин на Linux, както при Windows.
Докато активирането на електронната поща е по избор, тя е силно препоръчителна, защото тогава скриптът ще може:
- Ще ви информирам, когато започна и стартира.
- Сигнализирайте за всякакви грешки, които е в състояние да открие и да се справи.
- Информирайте за резервните дисквалификации, дължащи се на космически въпроси. (Това поведение може да бъде деактивирано, ако не е желано)
Изтеглете го на сървъра на Xen и извлечете.
wget https://caspian.dotconf.net/menu/Software/SendEmail/sendEmail-v1.56.tar.gz tar xvzhf sendEmail-v1.56.tar.gz
Обърнете внимание на местоположението, в което сте го извлекли. Вие ще имате нужда от него за файла с настройки.
Дефиниране на маркери
Citrix Xen ви дава възможност да конфигурирате "Custom Fields" за филтриране. Ще създадем Полетата и ще ги попълним с информацията, използвана от Xen-pocalypse. Xen-pocalypse разпознава 3 контролни TAG, които обозначават името на маркера за архивиране и връзката родител с дете. Ако не възнамерявате да използвате метода за въвеждане на файл, трябва да създадете поне полето за име на резервен маркер.
За да направите това, отворете свойствата на сървъра или дори VM. В навигационния екран изберете "Персонализирани полета".
Забележка: Имената на потребителските полета са "твърди кодирани" в скрипта, така че не трябва да се отклонявате от горния правопис, освен ако не промените съответния код.
След като всички полета бъдат създадени, трябва да видите:
Сега само трябва да определите кои ВМ принадлежат към това "BackupTAG". Например в компанията, в която се е развивала сценария, имахме VM, които трябваше да бъдат подкрепени ежеседмично в четвъртък и петък, график за нашите ВМ от продукта Atlassian и някои, които трябваше да бъдат подкрепени само месечно. Така че нашият преглед изглеждаше така:
Там, където например "weekly-fri" е текстът, който сме въвели в "Custom Backup" на "BackupTAG". Чудесно?:)
Родители и деца (по избор)
Истинската красота на този скрипт е, че той поддържа "родител" на "дете" взаимоотношения. Това означава, че е възможно да се зададе списък с "детски" ВМ, които да бъдат изключени и архивирани преди родителя, и че тези деца ще се включат отново само след като родителят е приключил архива си и е бил обратно нататък.Това е полезно в случаите, когато изключването на основния VM ще доведе до недостъпността на услугата в детето. Такова нещо би означавало, че услугата на детето ще бъде недостъпна два пъти, веднъж за процеса на архивиране на детето и веднъж за родителското. Създаването на тази връзка преодолява този проблем.
Например, всички наши Atlassian VMs са използвали една DataBase (DB) VM, която също е била настроена да бъде архивирана. Така че, като отбелязваме, че DB VM е "родител" на другите VM, може да бъде осигурена правилна линия за изключване -> backup -> startup.
По време на това писане тази функция има няколко предупреждения:
- Имената на ВМ, които трябва да имат такава връзка, не могат да съдържат интервали. Ще трябва да премахнете интервали от вашите VM имена, тъй като те ще бъдат ограничени от пространството, както в примера по-долу.
- Може да има само един родител. Определянето на повече от един дори не е планирано за, да не говорим за тестване.
За да създадете тази връзка, отидете в свойствата на VM. Ако това е "родител", пишете кои са неговите деца и ако това е "дете", пишете кой е родителят му. Например:
Методът FILE (незадължително)
По исторически причини Xen-pocalypse също така поддържа създаването на резервен списък на виртуалните компютри като текстов файл. Докато "кодът" все още е там, функционалността е силно по-ниска от метода TAGs и затова не се препоръчва. С това казано, ако предпочитате да използвате метода на списъка по някаква причина, важат следните ограничения:
- Имената на ВМ не могат да съдържат интервали или специални знаци.
- На всяка линия може да има само едно VM име.
- Празните линии не се допускат.
За да генерирате списъка, копирайте името на VM от центъра на Xen или изпълнете го на Xen хост:
xe vm-list | grep name-label | awk
'{ print $4 }' | sort
Копирайте горепосочения списък в обикновен текстов файл.
Местоположението за архивиране
Докато разбърквах на случаен принцип в Citrix Xen, установих, че Storage Depots (SRs) са налични за използване под "/ var / run / sr-mount /% UUID%". получени от GUI.
Това означава, че можем да използваме обикновения съветник "Next -> Next -> Finish", за да създадем монтажа на желаното място за архивиране, а после да използваме този скрипт (според случая, за да сменим с монтаж от командния ред). така е извън обхвата на това ръководство.
За да създадете нова "mount", щракнете с десния бутон върху името на сървъра и изберете New SR.
Получете UUID на SR
За да получите UUID на SR, просто кликнете върху името му в Xen Center и отворете раздела "Общи".
Конфигурирайте файла с настройки.
Проектът Xen-pocalypse идва заедно с шаблон за настройки на файла. Този шаблон трябва да бъде редактиран, за да отрази настройката ви и да бъде приет като първи аргумент за скрипта. Файлът с настройки обозначава следното:
Методът за получаване на резервни копия на виртуализации - Методът по подразбиране е TAG. Можете да промените това на ФАЙЛ, но това не се препоръчва.
Локацията на резервната дестинация - Ако сте проследили ръководството до тази точка, трябва само да смените% UUID% със SR, както е получено от по-горе.
Местоположението на SendEmail - Ако сте избрали да активирате имейл, трябва да въведете къде сте извадили изпълнимия файл тук.
Данни за електронната поща -Отново, ако сте активирали имейлите, трябва да дефинирате подробности като: To, From, Servername / IP & etc '.
компресия - Това е зададено по подразбиране "Не", защото, докато го разрешава, ще генерира по-малък архивен файл, това ще доведе и до забавянето на процедурата за архивиране за значително по-дълго време.
Проверете за свободно място на местоназначението - Това ще даде на скрипта проверка, че създаването на резервно копие на VM няма да доведе до спад на свободното място на резервното копие под 10GB. Това се прави, за да се гарантира, че най-много виртуални машини се архивират вместо само един много голям VM. Изчислението се извършва, като се използва общият размер на общия размер на всички HD дискове, свързани с VM.
Отстраняване на грешки - По подразбиране е деактивирането да бъде изключено със стойността "0" (нула). Не е нужно да включите това, но ако го направите, ще забележите повече информация в сегмента за отстраняване на неизправности.
Изпълнение / График
В най-простата си форма, призивът на Xen-pocalypse би изглеждал така:
./Xen-backup.sh settings.cfg weekly-fri
Където в горния случай се намираме в директорията, която съдържа скрипта и файла с настройки. "Етикетът", който скриптът ще търси е "седмично-фри".
Както бе отбелязано по-горе, ще използваме Cron, за да насрочим изпълнението. Преди да влезем в конфигурацията, това е така силно препоръчително че конфигурирате вече инсталирания SSMTP пакет на вашия Xen сървър. Макар че това е незадължителна стъпка, това ще ви даде колектор за обратно промиване. Да имате такъв "колектор за обратно промиване" може да ви предупреди за неща, които скриптът не е в състояние да направи.
Влезте в редактирането на cron още, като:
crontab -e
Ако сте изпълнили указанията по-горе и искате да добавите насрочено резервно копие за петък в 18:01 (6:01 ч.), Въведете следното:
01 18 * * fri /root/Xen-pocalypse-master/Xen_Backup.sh /root/Xen-pocalypse-master/settings.cfg weekly-fri
Горното е правилно, ако вашият скрипт и файлът с настройки са под "/ root / Xen-pocalypse-master /".
Отстраняване на проблеми
Докато съм положил много усилия, за да направя сценария толкова лесен за употреба и колкото е възможно по-неуверен, "Светът е по-голяма лаборатория". Информацията по-долу може да ви помогне да установите какъв е източникът на вашите проблеми.
прогрес
Може да искате да използвате тази линия, за да "бързо" гледате всички изпълнявани задачи, да видите дали те всъщност се развиват или всъщност са залепени.
while [ -e /dev/null ]; do for VM in '$( xe task-list | grep uuid | awk '{print $5}' )'; do xe task-param-get param-name=progress uuid=$VM;sleep 1; done; done
За да спрете да гледате, използвайте Ctrl + C, за да спрете "while loop".
Влизане
Всички "регистрации" се събират от хоста на Xen, който изпълнява скрипта в механизма syslog. Това, разбира се, може да се види с:
less +F /var/log/messages
Търсите ключовата дума "Xen-pocalypse".
Забележка: Citrix е определила политика за съхранение на два (2) дни за syslog на сървърите си. Може да искате да имате това предвид за погребения.
Отстраняване на грешки
Както е отбелязано в сегмента на файловете с настройки, има директиви, които дават възможност за отстраняване на грешки. Активирането на отстраняването на грешки ще доведе до извеждането на сложния запис в конзолата и ще я кастрира от изпращането на имейли и действителното извършване на износа, освен ако не са зададени съответните знамена. Възможните флагове се отбелязват в шаблона на файловете с настройки и те ви позволяват да определите подробно какво искате да отстраните.
Надявам се, че не сте имали нужда от отстраняване на грешки и жънете плодовете на моя труд:)
Тръгнете, мой човек, вие сте на път да станете номер едно дефектик …
