В зависимост от това колко мощно оборудване имаме и необходимите ресурси за нашите системи, ще имаме средно съотношение на виртуални машини на сървър.
Вземете например планираната поддръжка на сървър в компютърния център. Преди няколко години, ако това не беше част от клъстер, системата, съдържаща се в оборудването, щеше да бъде изключена, следователно потребителите също ще бъдат засегнати и / или персоналът, участващ в поддръжката, трябваше да работи в намалени времеви интервали (за да не кажем неудобно).
В случай на виртуализирана среда, виртуалните машини могат просто да бъдат „преместени или мигрирани“ към друг член на клъстер и оборудването може да бъде изключено, за да работи върху него. Проблема решен.
Нека започнем да виждаме ситуации, при които липсата на услуга не е програмирана.
Виртуална машина и мониторинг на приложения
Всеки път, когато създаваме виртуална машина, се препоръчва да инсталираме сборник от приложения и драйвери, които оптимизират поведението на виртуалния хардуер в неговата цялост (достъпно за Windows, Mac OS, Linux и други ОС). Тези инструменти, наречени VMTools, наред с други неща включват възможността хостът да наблюдава виртуалната машина (чрез сърдечен ритъм, както в клъстерите). Ако не отговори в рамките на определен период, той рестартира вашата операционна система.
Подобен случай се случва с мониторинга на приложения, но първо трябва да получите подходящ SDK (или да използвате приложение, което поддържа VMware Application Monitoring).
Но … какво ще стане, ако грешката е хардуерна?
Клъстерът, споменат по -горе, е първият слой на разтвора.
Споделено хранилищеКъдето всички членове на клъстера имат достъп до виртуални машини.
Мрежово обединяванеИзправени пред повредата на една дъска, останалите продължават да управляват трафика.
Множество пътища (многопътни)За съхранение те не само ще оптимизират достъпа, но и ще дадат съкращение.
Най -общо казано, тези три технологии смекчават времето, когато нашата информация е недостъпна. Сега, в зависимост от лицензирането, което имаме, можем да имаме и две много интересни функции: Висока наличност (HA) и Fault Tolerance (FT).
И в двата случая се нуждаем от клъстер със споделено хранилище. Без да е необходимо да се инсталира допълнителен софтуер, HA може да бъде активиран и конфигуриран по такъв начин, че ако сървър или виртуална машина се провали в клъстера, той автоматично ще стартира на друг член на клъстера. Струва си да се изясни, че HA не е предназначена за критично важни виртуални машини (виртуални машини). Така че очакваното време без услуга ще бъде: „Стартиране на операционната система + Стартиране на услугите“.
Брой грешки на хоста, поддържани от клъстера
Имаме X количество виртуални машини, разпределени в Y сървъри в клъстер.
Колко хостове могат да се провалят, без това да повлияе на наличността и производителността на нашата виртуална среда?
HA може да бъде конфигуриран да поддържа определен брой грешки в сървъра, като гарантира, че има достатъчно ресурси за възстановяване.
HA разрязва наличните ресурси на клъстер, като взема предвид CPU и RAM, конфигурирани и консумирани от нашите виртуални машини по много консервативен начин. Това отнема най -голямата конфигурирана резервация на процесора от всяка VM на всеки хост в клъстера и след това най -голямата резервация на памет и нейния излишък. Ако няма конфигурирана резервация, ще са необходими минимум 32 Mhz на виртуална машина за процесор и 0 Mb RAM + нейният излишък.
С тези числа се приема, че всяка използвана виртуална машина ще консумира този процесор и памет, след което генерира стойност, наречена размер на слота. С тази стойност се определя колко слотове са налични / използвани от всеки хост.
Проблемът възниква, когато например имаме една машина с голям процесор и запас от памет. Приемайки конфигурирани резервации, е много вероятно останалите наши виртуални машини да не се нуждаят наистина от тези ресурси, което води до по -малко слотове за нашия клъстер.
Процент на клъстерните ресурси като способност за неуспехи
За разлика от предишната опция, тази работи много добре, когато имате виртуални машини с много променливи конфигурации на процесора и паметта.
Възможно е да се конфигурират процентни стойности на процесора и паметта поотделно, като по този начин става още по -гъвкав и следователно се спестяват ресурси. Това обикновено е предпочитаният метод за конфигуриране на HA.
Хостове за отказ
Това е типичната конфигурация на клъстер в режим на готовност. Тази опция се дава главно, тъй като някои организации поддържат политики, които показват, че трябва да има сървъри в режим на готовност в случай на бедствие. Тъй като VMware прави добро управление на толерантността към грешки, може би това би бил вариантът, когато ресурсите са в изобилие … но определено не е най -добрият.
vMotion: Живи миграции
Миграцията на живо ви позволява да премествате работещи виртуални машини от един физически сървър на друг, като същевременно запазвате вашата мрежова връзка и идентичност. Активната памет (работещи процеси) се прехвърля по високоскоростната мрежа. Целият процес отнема по -малко от 5 секунди в гигабитова мрежа.
Възможно е да преместите виртуалната машина, файловете, които използва, или и двете, а процедурата може да се извърши с включено или изключено устройство. Във втория случай го наричаме „студена миграция“ и ако машината работи, го наричаме vMotion.
Използване и ползи от vMotion
- Реорганизация на VM, като по този начин се оптимизират ресурсите. Премахнете ги от сървъри, които са склонни към повреда или наситени.
- Автоматична оптимизация на наличните ресурси (Работя заедно с Dynamic Resource Scheduler или DRS).
- Направете поддръжка на основната инфраструктура няма нужда от график за поддръжка или прекъсване на дейността.
Всеки компонент на здравето на VM се обработва по различен начин по време на миграцията. Общата конфигурация е най-простата, не се движи, а се създава отново на целевия компютър.
Тъй като дискът не може да бъде създаден отново за толкова кратко време, е необходимо да има споделено хранилище. Текущото състояние на паметта постепенно се копира на целевия хост. В края на копирането се сравняват съществуващите разлики, възникнали по време на миграцията, състоянието на виртуалната виртуална машина е замразено и операционната система е активирана на дестинационната виртуална машина .
Тъй като в някои случаи опцията за рестартиране на машината не е идеална, за критична мисия имаме Толерантност към грешки. Това, което се желае в тези случаи, не спира да работи по всяко време, дори ако хостът му се провали. Единственият начин това да е възможно е, ако виртуалната машина работи на две места едновременно. Той е конфигуриран на ниво виртуална машина и ще генерира точно копие на виртуалната машина, като я поддържа 100% репликирана по всяко време на друг сървър, така че в случай на хардуерен отказ, неговият близнак просто ще продължи да функционира без загуба на информация. Интересно, нали?
Ако ставаше дума само за ресурси, щяхме да активираме FT във всички виртуални машини в нашия център за данни, но в предишните версии на vSphere срещнахме някои ограничения, най -важното: Не беше възможно да се активира FT в машини, които използват повече от един виртуален процесор. За щастие, в последната версия на продукта той поддържа до 4 виртуални процесора едновременно на защитена машина, но ще трябва да се има предвид лицензирането:
Броят на vCPU, поддържани от VM с FT, е ограничен от нивото на лицензиране, закупено за vSphere.
Толерантността към грешки се поддържа, както следва:
- vSphere Standard и Enterprise. Позволява до 2 vCPU.
- vSphere Enterprise Plus. Позволява до 4 vCPU.
Това не е единственото изискване на системата.
СъхранениеВиртуалните машини трябва да имат споделено хранилище. Не е възможно да се използва физически RDM (Raw Devide Mapping).
НетНеобходимо е да имате поне две виртуални карти (vmnics), едната за vMotion, а другата (10 gbps) за FT Logging. Това е ново изискване на версия 6 (преди това бяха необходими плочи от 1 gbps)
ПроцесорПроцесорите и операционните системи трябва да са съвместими с FT (и помежду си).
Ограничения
- Не е възможно да се правят снимки на виртуалните машини, които са защитени с FT и те трябва да бъдат изтрити, преди да разрешите тази функция.
- Виртуални дискове (VMDK) по -големи от 2 Tb.
- В документацията на VMware има списък със специфични устройства и функции.
Има и ограничение за броя на виртуалните машини на сървър: максимум 4 защитени машини на хост или 8 защитени vCPU (което от двете настъпи първо). Тези максимуми включват първичната и вторичната машина (и vCPU)
Разлики между FT наследство (предишно) и текущо
IPv6
Наследено FT = Не се поддържа от мрежови карти, конфигурирани за FT регистриране FT = Поддържа се
VStorage API - Архивиране със защита на данните
Наследено FT = Не се поддържа FT = Поддържа се
Виртуален диск
Наследено FT = EZT (Eager Zeroed Thick) FT = Всички видове, включително дебели и тънки
Резервиране на Vmdk (виртуален диск)
Наследена FT = Единично копие FT = Първичната и вторичната машини поддържат независими копия, което им позволява да се съхраняват в различни хранилища на данни и увеличават излишъка
Пропускателна способност на мрежовата платка
Наследена FT = препоръчителна 1-Gb NIC препоръчителна FT = препоръчителна 10-Gb NIC препоръчителна
Съвместимост на процесора и хоста
Legacy FT = Изисква един и същ модел процесор и семейство. Почти идентичните версии на vSphere FT = процесорите трябва да са съвместими с vSphere vMotion или EVC. Версията на VSphere трябва да е съвместима с vSphere vMotion
Активирайте / деактивирайте FT при работеща машина
Наследено FT = Не винаги се поддържа FT = Поддържа се
Не забравяйте, че FT предпазва от повреда на хардуерния сървър, а не от операционни системи или от сривове на приложения.
vCenter Server Watchdog това е вградена функционалност на версия 6.x. Той периодично проверява състоянието на услугите, които съставят vCenter, ще рестартира административните процеси или виртуалната машина, ако е необходимо.
