В тази част ще обсъдим някои важни моменти, свързани с нашата серия RHEV. В Част 2 от тази поредица, ние сме обсъждали Разполагане и инсталиране на RHEV Hypervisor. В тази част ще обсъдим други начини за инсталиране на RHEV Hypervisor.
Първият начин беше направен с помощта на специален RHEVH който е персонализиран от самия RedHat без никакви модификации или промени от страна на администратора. От друга страна, ще използваме нормален RHEL сървър [Минимална инсталация], който ще действа като RHEV хипервизор.
1. Инсталирайте абониран RHEL6 сървър [Минимална инсталация]. Можете да увеличите виртуалната си среда, като добавите допълнителен абониран RHEL6 сървър [Минимална инсталация] действа като хипервизор.
Операционна система: RHEL6.6 x86_64. Брой процесори: 2. Брой ядра: 1. Памет: 3G. Мрежа: vmnet3. I/O контролер: LSI Logic SAS. Виртуален диск: SCSI. Размер на диска: 20G. IP: 11.0.0.7. Име на хост: rhel.mydomain.org.
и се уверете, че сте проверили виртуализация опция в vm настройките на процесора.
Подсказка: Уверете се, че вашата система е абонирана за каналите redhat и актуална, ако не знаете как да се абонирате за абонаментния канал redhat, можете да прочетете статията Активирайте абонаментния канал на Red Hat.
Бакшиш: За да спестите ресурсите си, можете да изключите един от двете работещи и работещи хипервизори.
2. За да превърнете сървъра си в хипервизор {използвайте го като хипервизор} може да се наложи да инсталирате агента RHEVM върху него.
# yum инсталирайте vdsm.
След като инсталацията на пакетите приключи, отидете на RHEVM уеб интерфейс, за да го добавите.
3. Против на RHEVH hypervisor, можете да добавите RHEL хипервизор от един начин от RHEM, като използвате коренните идентификационни данни на RHEL хипервизора. И така, от РЕВМ WUI преминат към Домакини раздел и щракнете нов.
След това предоставете информация за вашия хост, както е показано.
След това игнорирайте Power mgmt предупреждение и завършете, след това изчакайте няколко минути и проверете състоянието на новодобавения хост.
За повече подробности относно добавянето на RHEL базиран хост, проверете официалния представител на RedHat RHEV документация.
Групирането в RHEV описва група от хостове от същия тип процесор, които споделят същото хранилище [напр. по мрежа] и се използват за изпълнение на конкретна задача [напр. Висока наличност ]
Клъстерирането като цяло има много допълнителни задачи, можете да разгледате статията, която обяснява Какво е групиране и предимства/недостатъци от него.
Основното предимство на групирането в RHEV е да активирате и управлявате миграцията на виртуални машини между хостове, които принадлежат към същия клъстер.
RHEV има две стратегии:
1. Жива миграция
2. Висока наличност
Жива миграция използвани в некритична ситуация, което означава, че като цяло всичко работи добре, но трябва да извършите някои задачи за балансиране на натоварването (например открихте, че хостът се зарежда от виртуална машина над друга. Така че можете да мигрирате на живо виртуална машина от хост на друга, за да постигнете балансиране на натоварването).
Забележка: Няма прекъсване на услугите, приложенията или потребителите, работещи във ВМ по време на миграция на живо. Живата миграция, наричана още преразпределение на ресурси.
Живата миграция може да се обработва ръчно или автоматично според предварително дефинираната политика:
Преминат към Клъстери раздела и изберете Клъстер 1 щракването върху редактиране.
От разделите на прозореца превключете на Клъстерна политика раздел.
Изберете равномерно разпределен политика. Това правило ви позволява да конфигурирате максималния праг за използване на процесора на хоста и разрешеното време за зареждане преди стартиране на миграция на живо.
Подсказка
Както е показано, конфигурирах максималния праг да бъде 50%, а продължителността - 1 мин.
Тогава Добре и преминете към раздела на VM.
Изберете Linux vm [Предишно създадено], след което щракнете редактиране и проверете тези точки.
1. От раздела Host: Проверете Ръководство и Автоматично Живата миграция е разрешена за тази виртуална машина.
2. От раздела HA: Проверете Приоритет степен на вашата виртуална машина. В нашия случай това не е много важно, тъй като играем само с един vm. Но ще бъде важно да определите приоритети за вашите VMS в голяма среда.
След това стартирайте Linux VM.
Първо, ще използваме Ръчна миграция на живо. Linux VM сега работи rhel.mydomain.org.
Нека стартираме следната команда през vm конзолата, преди да започнем миграцията.
# ls -lRZ /
След това изберете Linux VM и щракнете Мигрирайте.
Ако изберете автоматично, системата ще провери най -отговорния хост за дестинация съгласно политиката на клъстера. Ще тестваме това без никаква намеса от администратора.
Така че, след като изберете ръчно и изберете дестинацията, щракнете върху OK и отидете на конзолата и наблюдавайте изпълняваната команда. Можете също да проверите състоянието на vm.
Може да се наложи да наблюдавате събитията в Task.
След няколко секунди ще намерите промяна в името на хоста.
Вашият VM е ръчно мигриран на живо успешно !!
Нека опитаме автоматично Жива миграция, нашата цел е да накараме натоварването на процесора на хоста rhevhn1 да е надхвърлено 50%. Ще направим това, като увеличим натоварването на самия vm, така че от конзолата напишете тази команда:
# dd if =/dev/urandom на =/dev/null.
и следете натоварването на Host.
След няколко минути натоварването на Host ще надхвърли 50%.
Просто изчакайте още няколко минути, след което миграцията на живо ще започне автоматично, както е показано.
Можете също да проверите раздела със задачи и след малко изчакване вашата виртуална машина автоматично се прехвърля на живо в rhel Host.
Важно: Уверете се, че един от вашите хостове има ресурси повече от другия. Ако двата хоста са идентични по ресурси. VM няма да се мигрира, защото няма да има разлика !!
Подсказка: Поставяне на Host в режим на поддръжка автоматично ще мигрира на живо и ще стартира виртуални машини към други хостове в същия клъстер.
За повече информация относно VM Migrations, прочетете Мигриране на виртуални машини между хостове.
Подсказка: Миграцията на живо между различни клъстери не се поддържа официално, очаквайте един случай, в който можете да го проверите тук.
В противоположност на Жива миграция, ХА се използва за покриване на критични ситуации, а не само за задачи за балансиране на натоварването. Общият раздел, който вашата виртуална машина ще мигрира към друг хост, но с време за рестартиране.
Ако имате неуспешен, неработещ или неотзивчив хост във вашия клъстер, миграцията на живо не може да ви помогне. HA ще изключи виртуалната машина и ще я рестартира на друг работещ хост в същия клъстер.
Да се Активиране на HA във вашата среда трябва да имате поне едно устройство за управление на захранването [напр. превключвател на захранването] във вашата среда.
За съжаление не можем да направим това в нашата виртуална среда. Така че за повече информация относно HA в RHEV, моля, проверете Подобряване на времето за работа с VM High Availability.
Помня: Live Migration и High Availability работят с хостове в един и същ клъстер със същия тип процесор и свързани към споделено хранилище.
Достигнахме връхната точка в нашата серия, когато обсъждахме една от важните характеристики в RHEV Clustering, както я описвахме, и нейното значение. Също така обсъдихме втория тип [метод] за разполагане на RHEV хипервизори, които на базата на RHEL [поне 6.6 x86_64].
В следващата статия ще можем да извършим някои операции на виртуални машини като снимки, запечатване, клониране, експортиране и пулове.