Networkworld България - брой 2, 2007 г. /
Съдържание
Консолидацията на няколко физически сървъра с помощта на виртуални машини предявява нови изисквания към безотказната работа: спиране на физическия сървър засяга и работещите на него виртуални машини. Представяме различни възможности за комбиниране на виртуализация и клъстеризация, както и техния анализ по отношение на отказоустойчивостта.
Голяма част от използваните днес клъстери с висока степен на отказоустойчивост представляват клъстери от два възела: за да разполагат и двата с еднакъв набор от данни, той се съхранява или в съвместно използвана система за съхранение, или се тиражира между сървърите.
Досега клъстери с висока степен на работоспособност се базираха изключително на физически сървъри. Все пак с разпространение на технологията за виртуализация и в тази област възниква потребност от решения за обезпечаване на отказоустойчивост. В статията са описани базовите възможности за изграждане на клъстер с висока степен на готовност във виртуални среди, като за основа се взема подходът за организиране на активен/пасивен клъстер. На практика изборът на един или друг конкретен вариант зависи от използваната технология за виртуализация и наличните продукти.
Вариант 1
Виртуална машина - виртуална машина на един физически сървър. При този сценарий клъстерът с висока степен на отказоустойчивост се организира между две или повече виртуални машини на един единствен физически сървър (вж. Фигура 1). Мениджърът на клъстера работи на съответните виртуални машини, а физическият сървър служи само като база за тях.
Фигура 1. Организирането на клъстер между две виртуални машини, работещи на един физически сървър, има смисъл само в качеството на тестова платформа.
Целесъобразността на такъв подход е доста съмнителна, тъй като подобни клъстери не предоставят никаква защита при отказ на сървърния хардуер, а излизането от строя на физическия сървър може да доведе до отказ на цялата система (Single Point of Failure, SPOF). Тази концепция нарушава един от най-важните принципи в областта на отказоустойчивостта – отстраняване на всички потенциални точки на отказ. Освен това заради използването само на един физически сървър се налага да се откажете от редица предимства, които обикновено предлага клъстер с висока степен на готовност: например, ремонт или диагностика на клъстера без неговото спиране. Тази комбинация може да се ползва в качеството на тестова платформа за отказоустойчиви клъстери и едва ли има практическо приложение.
Вариант 2
Виртуална машина - виртуална машина, на няколко физически сървъри. Този модел предполага организиране на отказоустойчив клъстер между две или повече виртуални машини, работещи на различни физически сървъри (вж. Фигура 2). По този начин спирането на едната машина няма да доведе до общ отказ. Както и при предишното решение, мениджърът на клъстера работи непосредствено на виртуалната машина.
Фигура 2. Ако клъстерът е организиран между виртуални машини на различни физически сървъри, то при отказ на единия физически сървър потребителите могат да продължат да ползват приложенията.
В сравнение с класическата клъстеризация предимствата са преди всичко в областта на резервното копиране и възстановяване на данни - това са задачи, чието решение облекчава използването на виртуални машини. Все пак администраторът не трябва да забравя за операционната система на физическия сървър, служещ като основа за виртуалната машина. При това трябва да се обръща внимание на постоянното обезпечаване на сигурността на системата, както и на включените в процеса резервно копиране и възстановяване.
Освен това решението позволява да се изпълняват по няколко “екземпляра” от приложения, които обикновено не поддържат такава възможност в рамките на една операционна система. Това се постига чрез използване на няколко виртуални машини на един физически сървър.
Вариант 3
Физически сървър — виртуална машина. В този случай отказоустойчив клъстер се създава между физически сървър (активен възел) и виртуалната машина (пасивен възел) (вж. Фигура 3). Мениджърът на клъстера се изпълнява на физическия сървър непосредствено в операционната система и върху виртуалната машина на другия възел.
Фигура 3. Клъстер между физически сървър и виртуална машина дава възможност за икономии, ако пасивните възли на различни клъстери работят на един физически сървър.
Предимство на този варианта е, че администраторът може да обедини няколко резервни възела от различни клъстери на една физическа машина. В резултат се получава значителен потенциал за икономия в противовес с обичайното дублиране на хардуера чрез резервен сървър в клъстера. В зависимост от метода на реализация на виртуалните машини в сървъра може да се използват различни операционни системи. Например, резервният сървър с виртуални машини може да е част както от Windows клъстер, така и на клъстер Linux.
Недостатък на този подход е в това, че в случай на отказ на няколко възела от различни клъстери и тяхното пренасочване към резервния сървър производителността на машината може да се окаже недостатъчна. Администраторът е длъжен или съзнателно да поеме този риск, или по съответния начин да пресметне възможностите на резервния сървър.
В същото време процесите по обновяване на системата, а също резервното копиране и възстановяване на данните за отделните възли в клъстера могат значително да се отличават.
Вариант 4
Виртуална машина - физически сървър. Този подход представлява пълна противоположност на предишния: клъстерът се организира между виртуална машина (активен възел) и физически сървър (пасивен възел) (вж. Фигура 4). Както и в предишния вариант, мениджърът на клъстера работи от една страна на виртуалната машина, а от друга — непосредствено върху операционната система на физическия сървър.
Фигура 4. Високопроизводителният хардуер с няколко виртуални машини, функциониращ като активен възел, може да се използва в комбинация с евтини физически сървъри в качеството на пасивни възели.
Ползването на подобно решение е оправдано, ако на доста производителна хардуерна система със значителна резервираност се поместят няколко виртуални машини. Тогава в качеството на резервни сървъри могат да се използват евтини машини с по-малка резервираност на хардуера. Все пак трябва сериозно да помислим за това, дали действително такава икономия е уместна в случай на клъстер с висока степен на отказоустойчивост.
Вариант 5
Физически сървър - физически сървър, с пренос или превключване на виртуални машини. Ако се използва този сценарий клъстерът се организира по традиционния начин между два или няколко физически сървъра (вж. Фигура 5). Мениджърът на клъстера се стартира непосредствено върху операционната система на физическия клъстер. Програмното осигуряване за виртуализация е конфигурирано в клъстера в качеството на ресурс. Всъщност приложението работи не върху операционната система на физическия сървър, както обикновено, а на една или няколко виртуални машини. В случай на отказ клъстерният мениджър пуска програмата за виртуализация с всички виртуални машини на резервния възел.
Фигура 5. Клъстер между два физически сървъра е подходящ на първо място при използване на виртуализация на операционната система.
Даденият подход предоставя множество предимства. Едно от тях е опростяване конфигурирането на клъстера. Тъй като клъстерният мениджър трябва да управлява само софтуера за виртуализация, конфигурирането се осъществява просто и компактно. По този начин се избягва сложната и “податлива” на грешки интеграция на приложенията. В резултат напълно отпада необходимостта от “разделяне” или синхронизация на конфигурирането на приложенията на няколко клъстерни възела.
С други думи главното достойнство на този вариант е независимостта на приложенията и клъстерният мениджър. Приложенията могат да се обслужват по такъв начин, все едно са на отделна виртуална машина или отделен физически сървър. Те работят на виртуални машини, за които не е нужно никакво специфично адаптиране към клъстера.
Освен това без допълнителни разходи се осигурява висока степен на отказоустойчивост за няколко виртуални машини. Тази задача се решава с помощта на един клъстер. По този начин не е нужно организиране на няколко отделни клъстера. Достатъчно е в единствената клъстерна система да се консолидира необходимия брой виртуални машини.
За съжаление процесът по пренасяне или превключване може да продължи оста по-дълго, отколкото при традиционния клъстер. При този подход не е достатъчно да се пусне само приложението, тъй като в началото се налага да се рестартира цялата виртуална машина, което, естествено, отнема повече време. Понякога полезна се оказва виртуализацията на операционната система. В такъв случай съществено се намалява времето за зареждане на виртуалната машина, а допълнителните разходи се оказват пренебрежимо малки в сравнение с пускането на отделни приложения.
Възможни ограничения
Предлаганите сега на пазара продукти за реализация на отказоустойчиви клъстери предявяват различни изисквания към сървърите, мрежите и системите за съхранение на данни. Виртуалните среди не са подходящи за всички случаи. Например, трябва внимателно да се подхожда към “изолирането” (fencing). Тази технология предотвратява едновременния достъп до няколко клъстерни възела с важни ресурси (например, ако файловите системи не поддържат работа с клъстери).
Един от начините за постигане на целта е изолация на възела, като целият клъстерен възел се изключва от клъстера с помощта на технология за блокиране STONITH (Shoot The Other Node In The Head, или буквално: “Да застреляш другия възел в главата”). Този метод не е подходящ, ако от едната физическа хардуерна система се използват няколко виртуални машини от различни клъстери. В такава ситуация STONITH веднага би изключил от клъстера няколко “виртуални” клъстерни възела.
Друг начин е изолация на ресурсите. Методът гарантира ексклузивен достъп до важни ресурси и на практика често се реализира с помощта на резервиране SCSI-2/SCSI-3. Що се отнася до виртуализацията, администраторът трябва да следи тези резервирания действително да функционират във виртуалното пространство. Проблемите се появяват при изграждане на клъстер с клъстерен мениджър, който, от една страна работи върху ОС на виртуалната машина, а от друга, непосредствено върху физическия сървър.
Бъдещето
Комбинирането на висока степен на отказоустойчивсот и виртуализацията се намира едва в началото на своето развитие, и едва ли на пазара има готови решения.
Интерес предизвиква възможността за миграция в реално време, която предлагат все повече решения за виртуализация: една от виртуалните машини в определен момент се “замразява”, а след това, със запазване на всички данни, процеси и мрежови връзки, се активира на друг физически сървър. В идеалния случай клиентът въобще не забелязва каквито и да е изменения. Тази функция за миграция на виртуални машини в реално време е много интересна за ръчно превключване на отказоустойчив клъстер. Освен това си струва да помислим за миграция в реално време и прилагане на автоматичен пренос в случай на отказ.
Заключение
Виртуализацията предлага множество нови възможности за изграждане на отказоустойчиви клъстери. В много случаи те изглеждат доста съблазнителни, но потребителят трябва внимателно и критично да ги оцени. На първо място трябва да се постави максималната работоспособност на приложенията. Клъстер от такъв вид трябва да е много лесен за обслужване –това е един от най-важните принципи в областта на отказоустойчивостта, а използването на виртуализация нерядко го нарушава. Най-големите трудности възникват при изграждане на клъстер от виртуална машина и физически сървър. Потребителят трябва да помисли и за това, че виртуализацията въвежда още едно системно ниво, заради което могат да се появят нови грешки и проблеми.
(03.05.2007)