Клъстер в proxmox

Искам да разкажа за това как използваме при Proxmox виртуална среда.

Няма да описвам конфигурацията на монтиране и първоначално - Proxmox е много проста и приятна и за инсталиране и конфигуриране. Аз ще ви кажа за това как използваме системата в среда с клъстери.

За завършване на работата на клъстера е необходимо да се контролира виртуалната машина може бързо да достигне различни домакини в клъстера. Това виртуално добре, когато тя не трябва да се копира навсякъде. Това означава, че всички хостове в клъстера трябва да имат достъп до данните на дадена машина, или, с други думи, всички хостове в клъстера трябва да работят с едно хранилище на данни, в която работи специфичен набор от виртуални машини.

Proxmox работи с два вида виртуализация: нивото на операционната система, на базата на OpenVZ и хардуер, базиран на KVM. В тези два вида използва различен подход към използването на пространство за съхранение. Ако в случай на OpenVZ съдове, работещи работа с диск на виртуалната машина на нивото на файловата система на хоста, в случай на KVM-машина с помощта на изображението диск, който съдържа родния файловата система на виртуалната машина. хост операционната система не се интересува от местоположението на данни в рамките на KVM-ROM. Това се занимава с хипервайзора. Организацията на работата на опцията за клъстер от образа на диска се осъществява по-лесно, отколкото да работи с файловата система. Тези KVM машини от гледна точка на операционната система на може просто да бъде "някъде" в хранилището. Тази концепция се намира в прекрасна схема LVM работа. когато изображението на KVM-ROM е вътре в логически обем.

В случай на OpenVZ, ние се занимаваме с файловата система, а не само с площта на данни за съхранение, споделено. Имаме нужда от пълен клъстер файлова система.

На клъстеризирано файлова система, тя отива в тази част на статията. На работа с KVM - също. Сега нека да поговорим за подготовката на работата на клъстера споделено съхранение.

Бързам да кажа, че търговският натоварването на клъстера, че не даваме и не планират да. Системата се използва за битови нужди, които имаме изобилие. Както написах в предишната статия. търговско натоварване постепенно се движи в vCloud. и на освободените съоръжения, разширяване Proxmox.

В нашия случай, проблемът за организиране на споделеното хранилище се свежда до два аспекта:

1. Имаме блок устройство, като се има на разстояние от мрежата, които ще имат достъп до множество хостове едновременно. За тези хостовете не са се борили за място на устройството, ние се нуждаем CLVM - Клъстер Logical Volume Manager. Това е същото като LVM. Само с клъстери. Поради CLVM всеки хост има най-новата информация (и то спокойно може да променя, без риск от застрашаване целостта) на състоянието на LVM -Tom на Shared Storage. Логическите обеми в CLVM живеят по същия начин, както при нормално LVM. Логическите обемите са или KVM-изображения или клъстер FS.
2. В случай на OpenVZ имаме логично обем на която е разположена на файловата система. Едновременна работа на няколко машини с не-клъстерирани файлова система води до неизбежни грешки в работата на всички - това е лебед, раци и щука, но по-лошо. Файловата система трябва да е наясно с факта, че тя живее на споделен ресурс, както и да могат да работят в този режим.

Създаване на клъстер и свързан с възел Няма да описвам. Това може да се чете, например, на интернет страницата на разработчиците. Между другото, от тях знание е доста обширна и информативни.

Ние работим с Proxmox 2.2. Предполагаме, че ние имаме един клъстер е конфигуриран и работи.

Ние сме за създаване на заем ограден-демона

Спецификата на клъстер среда изисква възли касетъчни следват определени правила на поведение. Не може просто да се вдигне и да започнете да пишете на устройството. Първо, трябва да поиска разрешение. Контролирайте това отнема няколко касетъчни възли - CMAN (Cluster мениджър), DLM (Distributed мениджър заключване) и ограден. Ограден -demon служи като бияч. Ако условията на клъстера някои възел започва да се държи лошо - комуникация със съхранението в замръзва клъстерите и оградени опитва да провали изключете възел от клъстера.

Фехтовка - е процес на отстраняване на възли с групирана съхранение. Тъй като машината е неадекватна и не може да отговаря на исканията да напусне в добри отношения, отлъчване възли се извършва с помощта на външни за групата от сили. За да общува с тези сили се използват от специално обучени свещеници ограда агенти. Като правило, фехтовка се свежда до изключвайте захранването на възела и след това превежда духа на клъстера, и отново се задейства.

В ролята на външни сили, може да бъде всяко оборудване, способно да муцуната затвори сигнал за прекъсване на връзката или изолиране на машината от мрежата. Най-често, ролята на тези устройства са индустриалната захранването или сървърът Конзолата за управление. Ние сме на използване на HP оборудване. Фехтовка се произвежда като се използва ILO -kartochek.

Докато ограден -demon не получи потвърждение от агента този възел безопасно "ограден" - всички входно-изходни операции в клъстера ще бъде спрян. Това се прави с цел да се намали риска от увреждане на данни в хранилището. Така че, както се разби възел е престанал да спазва общоприетите правила за поведение от него, можете да очаквате нищо. Например, неоторизирани опити (и не на сеч) се записва на диск. Ето защо, всяка комуникация с хранилището в тази ситуация увеличава риска от увреждане на данните.

Ако възелът не е конфигурирана за -agent ограда, ограден, че няма да бъде в състояние да го рита в случай на проблеми, както и на клъстера ще бъдат замразени, докато ситуацията не бъде решен. Има няколко сценария за по-нататъшното развитие:

1. Нода може да се възстанови и да се върне в клъстера и да кажа, че това няма да е по-така. Тя ще стартира и работата на клъстера ще бъде възобновено.
2. Нода може да се рестартира (или някой презарежда), и да поиска клъстера. Фактът, че нов опит да се свърже с клъстера се счита за сигнал, че възелът работи, и можете да продължите работа.
3. Нода може да умре. Тази ситуация изисква ръчна намеса. Необходимо е да стане ясно, ограден -demonu, че възелът вече не е заплаха за клъстера. И като цяло, това не може да се върне. За тази цел има една програма "fence_ack_manual". Операторът поема отговорността за вземане на решение за възобновяване на работата на клъстера.

Ако домакинът е изключен в нормален режим - той просто иска да се изтрие от оградата след -Къща губи способността да се общува с хранилището.

Наличието на множество в ограда -Domains на е предпоставка за всяка работа, на споделеното хранилище използване групиране софтуер.

Помислете агент настройка ограден с помощта на "ограда-МОТ" (настройка се извършва на всеки възел на клъстера)

В файл / и т.н. / по подразбиране / RedHat-клъстер-PVE излагайте

Сега, в началния възел на системата ще се свърже с ограда-домейн. Ние не искаме да се рестартира, така че ние добавите възел към домейна ръчно:

ограден -demona възможно толкова Вижте състояние:

Изпитвания на ограда агент

За различни версии на МОТ има различни агенти:

Да започнем с това - анкета МОТ статут на възлите, представляващи интерес за нас:

Статус: ON. Може да замени "-o статус" каже "-o рестартиране". Експериментален автомобил ще получите нулиране разливане.

По същия начин ние се провери ефективността на всички МОТ nodah.

В този пример, възел "tpve03" не е конфигуриран ограда агент, и с това проблемите на конфликта трябва да разреши ръчно.

Да не светят в паролите конфигурационните от МОТ. парола в настройките на консултанта включва опцията

Това е пътят към сценария, който дава паролата. Primitive скрипт:

Тези скриптове трябва да съществуват на всички клъстер nodah.

След всички промени, направени в конфигурацията на клъстера и otvalidirovany - използвайте нашата конфигурация. В Proxmox ХК влезем и да каже: "Активиране" Configuration Web интерфейс. Ако това се случи, без каквито и да било грешки, както и серийния номер на конфигурацията на клъстер е увеличен, промените ще влязат в сила, и можете да се опитате povypinyvat възли. Като цяло, се препоръчва да се организира fensing всеки възел на клъстера за да се уверите, че тя наистина работи.

За да започнете възел пън ръце:

Нода дума за нулиране.

Сега се опитват да симулират проблема. На един от възли, ние добавяме мрежов интерфейс, върху които се осъществява комуникацията между възлите на клъстера са:

След известно време на заявка статус възел живо ограден -demona показва следното:

"Чакай състояние фехтовка", казва, че сега има изключение проблемни възли на клъстера и ограден -demon чака да чуе от -agent ограда.

След получаване на потвърждение от страна на потребителя:

Нода убит работим.

Когато възелът се издига, той ще се свърже с клъстера.

Нашата клъстер вече е готов да работи с обща памет.