Висока доступност на виртуелизованим серверима: комплетан водич

Информатек Дигитал » Средства » Висока доступност на виртуелизованим серверима: комплетан водич

Висока доступност на виртуелизованим серверима постала је основни захтев за сваку организацију која не може себи да приушти прекиде у раду, чак ни на само неколико минута. Говоримо о осигуравању да ваше виртуелне машине, апликације и подаци остану доступни чак и ако физички сервер, диск, мрежа или чак цео центар података откаже. Не ради се само о прављењу резервних копија, већ о одржавању услуге у раду без обзира на све.

Када комбинујемо виртуелизацију , кластере, складиштење и опоравак од катастрофе , појављују се многе технологије (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, реплике итд.) и није увек јасно коју одабрати или како све то уклопити. Овај чланак пружа детаљан преглед главних опција и приступа: од традиционалних кластера са дељеним складиштем до модерних решења заснованих на репликацији у реалном времену између чворова, укључујући конкретне примере са архитектурама Red Hat, Microsoft Hyper-V, QNAP и HA-DAS.

Основни концепти високе доступности у виртуелизованим окружењима

У виртуелизованом окружењу, висока доступност (HA) значи да виртуелне машине остају доступне чак и ако једна или више системских компоненти (сервери, дискови, контролери, мрежа, напајање итд.) откажу. Ово није исто што и опоравак од катастрофе (DR): HA циља на минимално или готово нулто време застоја, док DR обично прихвата извесно време застоја како би обновио услуге из резервне копије.

Да би се постигло ово понашање, комбинује се неколико компоненти: редундантност хардверса, кластер софтвер, складиштење отпорно на грешке и механизми за праћење и пребацивање у случају отказа . Циљ је избећи појединачне тачке отказа: ако једна компонента откаже, друга преузима без ручне интервенције (или уз минималну интервенцију).

У свету виртуелизације, ово се обично преводи на поседовање више физичких хостова који деле или реплицирају складиште , и систем који прати статус чворова и виртуелних машина. Када један хост откаже, виртуелне машине се покрећу на другом хосту, идеално без приметивања корисника или са веома кратким прекидом.

Такође је важно разликовати решења дизајнирана за еластична окружења „слична облаку“ и класичне HA платформе. Одређени кластер производи имају релативно статичну конфигурацију и релативно мали максимални број чворова, тако да нису погодни за подешавање масивног облака, иако су одлични за заштиту добро дефинисаног скупа критичних услуга.

У облаку или хибридном окружењу, препоручљиво је преиспитати специфичне стратегије миграције и континуитета: на пример, миграција у облак може бити део стратегије опоравка од катастрофе, али не замењује локалну високу доступност.

Висока доступност на Red Hat Enterprise Linux и KVM/Xen платформама

Ред Хат екосистем нуди неколико опција за заштиту виртуелних машина коришћењем кластера и додатака за високу доступност . Верзије попут Ред Хат Ентерпрајз Линукса 5 и 6 подржавају различите комбинације хипервизора и додатака за кластере.

RHEL 5 подржава две платформе за виртуелизацију: Xen (од RHEL 5.0 па надаље) и KVM (од RHEL 5.4 па надаље) . Додатак RHEL 5 Advanced Platform (AP) Cluster вам омогућава да управљате и Xen и KVM виртуелним машинама као ресурсима кластера, тако да инфраструктура високе доступности хоста контролише покретање, искључивање и прелазак на резервни режим виртуелних машина између чворова.

Са RHEL 6, подршка за виртуелизацију је поједностављена: само KVM је подржан као хипервизор . Међутим, RHEL 6 додатак за високу доступност и даље омогућава да се KVM виртуелне машине третирају као ресурси кластера којима управља HA инфраструктура хоста. Менаџер ресурса кластера (rgmanager у класичним верзијама) је одговоран за праћење чворова и премештање гостујућих система између физичких сервера када се открије квар.

Овај приступ се често назива „ RHEL кластер/HA који ради на физичким хостовима и делује као платформа за виртуелизацију “. Сам RHEL кластер управља где се свака виртуелна машина покреће и преузима контролу у случају квара чвора, осигуравајући да се виртуелне машине конфигурисане као критичне поново покрећу на здравом хосту.

Занимљив аспект је да је, из перспективе кластера, гостујући оперативни систем виртуелне машине мање важан . Било који гостујући оперативни систем компатибилан са Xen или KVM у RHEL-у може се третирати као високо доступна виртуелна машина: различите верзије RHEL-а (3, 4, 5, итд.) и различита издања Microsoft Windows-а, све док их хипервизор подржава. Ово пружа значајну флексибилност приликом обезбеђивања мешовитих окружења.

Међутим, сам Red Hat препоручује опрез при избору између коришћења RHEL High Availability додатка или свеобухватнијих платформи за виртуелизацију као што је Red Hat Enterprise Virtualization (RHEV) за обезбеђивање високе доступности виртуелних машина. Обе нуде функционалност високе доступности, али су случајеви употребе различити и морају се узети у обзир величина окружења и оперативни модел.

Када користити RHEL HA у односу на RHEV за високу доступност

Приликом одлучивања да ли да се користи RHEL HA додатак или платформа попут RHEV-а ​​за заштиту виртуелних машина, један од кључних критеријума је број физичких хостова и врста употребе која ће бити дата виртуелизованом окружењу.

RHEL-ов додатак за високу доступност је дизајниран за релативно мале, статички конфигурисане кластере . Традиционално, ови кластери имају максимално ограничење од око 16 физичких чворова, што је довољно за многа корпоративна окружења, али се не уклапа добро са архитектурама сличним облаку са десетинама или стотинама стално променљивих хостова.

Стога, сопствена документација компаније Red Hat указује да се коришћење RHEL HA искључиво за изградњу инфраструктуре сличне облаку не препоручује , управо због његове статичке природе и ограничења броја чворова. За сценарије у облаку, има више смисла користити платформе посебно дизајниране за тај модел, са еластичнијим и скалабилнијим менаџерима ресурса.

С друге стране, ако је циљ заштита умереног броја критичних виртуелних машина на добро дефинисаном скупу хостова , RHEL-ов додатак за високу доступност је робусно решење: добро се интегрише са оперативним системом, ослања се на зреле технологије кластеровања и пружа неопходну логику за праћење и премештање виртуелних машина у случају квара.

У сваком случају, препоручљиво је прегледати најновију RHEL документацију о подржаним гостујућим оперативним системима и комбинацијама хипервизора и кластера , јер се подршка развија са сваким издањем и важно је придржавати се званичних матрица.

Висока доступност у Hyper-V: кластери, реплике и миграција уживо

У Microsoft окружењима, висока доступност је фундаментално заснована на могућностима Hyper-V-а у комбинацији са Windows Server Failover Clustering-ом . Циљ је имати константан приступ виртуелним машинама чак и у случају кварова хардвера, проблема са мрежом или софтверских грешака.

Основна компонента су Hyper-V кластери за преузимање отказа . Такав кластер је скуп сервера (чворова) који деле складиште и раде на координисан начин: ако један чвор откаже, виртуелне машине које је покретао се аутоматски поново покрећу на другом чвору у кластеру. Све ово је подржано технологијама дељених дискова и специфичним интерним комуникацијама.

Да би ово функционисало, чворови обично деле складиште путем SAN-а (Storage Area Network) или скалираног фајл сервера (SOFS) . Кластерски дељени томови (CSV) се затим креирају на врху овог слоја , омогућавајући свим чворовима да истовремено приступе истим дисковима где се налазе датотеке виртуелне машине.

Чворови такође комуницирају путем наменске мреже познате као „откуцај срца“ кластера . Ова мрежа је одвојена од продукцијске мреже података и омогућава сваком серверу да пријави да је активан. Ако кластер престане да прима откуцаје са чвора, сматра се да је дошло до отказа и покрећу се процедуре пребацивања на резервни систем.

Још један фундаментални елемент је конфигурација кворума . Кворум дефинише колико гласова (чворова или спољних сведока) мора бити активно да би кластер наставио да функционише. Ово спречава сценарије „подељеног мозга“, где изоловане групе чворова погрешно верују да су главни кластер и узрокују оштећење података. Избор правог модела кворума (чворови, сведок диска, сведок дељења датотека итд.) је кључан за стабилност.

На основу овога, Hyper-V користи могућности кластера како би омогућио миграције виртуелних машина између чворова уз минимално време застоја . Током одржавања или балансирања оптерећења, виртуелна машина се може преместити са једног хоста на други без прекида услуге, транспарентно преносећи меморију, стање и активне везе.

Ако се, уместо планираног одржавања, деси стварни квар хардвера или софтвера на чвору, кластер врши аутоматско пребацивање у случају отказа . Виртуелне машине које тамо раде се покрећу на другом хосту са приступом истом дељеном складишту. Прекид је већи него код живе миграције (виртуелне машине морају бити искључене и укључене), али се континуитет услуге одржава уз минималну људску интервенцију.

Hyper-V реплика и миграција уживо „Ништа дељено“

Поред класичног SAN кластера, Hyper-V укључује и друге технологије усмерене на високу доступност и опоравак од катастрофе, посебно Hyper-V Replica и миграцију уживо без дељеног складишта.

Hyper-V репликација је асинхрона функција репликације виртуелне машине која реплицира виртуелне машине између примарног хоста и једног или више реплика хостова, обично смештених на другој локацији или у дата центру. Промене се шаљу циљној виртуелној машини у редовним интервалима, креирајући тачке опоравка које омогућавају враћање виртуелне машине у недавно стање ако примарна локација доживи катастрофу.

Овај механизам користи Hyper-V агент за репликацију који координира саобраћај репликације, управља тачкама опоравка и централизује операције пребацивања у случају отказа. Омогућава и планирана пребацивања у случају отказа (на пример, премештање производње на другу локацију) и непланирана пребацивања у случају отказа (када примарна локација неочекивано престане да ради).

Због своје асинхроне природе, репликација је више оријентисана ка опоравку од катастрофе ( DR) него ка високој доступности (HA) са скоро нултим застојем . Након инцидента, на реплици виртуелне машине мора се покренути прелазак у функцију услед отказа, и иако је процес прилично агилан, он подразумева извесно време застоја и потенцијални губитак последњих неколико секунди или минута података, у зависности од конфигурисаног интервала репликације.

Паралелно, Hyper-V нуди миграцију уживо „Shared Nothing“ , која вам омогућава да премештате виртуелну машину између хостова који не деле складишни простор. У овом моделу, сваки хост има свој локални складишни простор, али миграција уживо транспарентно копира дискове виртуелне машине на одредиште док виртуелна машина остаје онлајн, а затим пребацује извршавање на нови сервер.

Ова функционалност је посебно корисна у окружењима без SAN или инфраструктуре за дељено складиштење , смањујући почетне трошкове за мала и средња предузећа или сценарије где је одржавање наменске мреже за складиштење непожељно. Омогућава, на пример, реорганизацију хостова или миграцију на нови хардвер уз минималан утицај, без потребе за искључивањем постојећих машина.

Комбинација ових технологија (кластери за преузимање отказа, CSV, миграција уживо са или без дељеног складиштења и Hyper-V репликација) пружа широк спектар опција за дизајнирање стратегија за континуитет пословања и толеранцију на грешке прилагођених различитим буџетима и нивоима потражње.

Решења високе доступности са HA-DAS-ом и Windows Server-ом

Поред окружења са великим SAN мрежама, постоје архитектуре дизајниране за високу доступност у системима за складиштење података директно повезаним са серверима (HA-DAS) . Ова решења користе Windows Server (нпр. 2012) и напредне RAID/HBA контролере за пружање кластера високе доступности без потребе за подешавањем традиционалне iSCSI или FC SAN мреже.

Овај приступ користи два HA кластер чвора са дељеним JBOD складиштем (само гомила дискова без икакве уграђене интелигенције). JBOD се повезује са оба сервера преко редундантних Host RAID HBA контролера, тако да сваки чвор види исти скуп дискова и може истовремено да приступи истом RAID низу.

Ова решења могу постићи капацитет до 180 TB у дељеној кућишту , радећи са магнетним или SSD дисковима са могућношћу брзе замене у различитим RAID нивоима. RAID контролери обично укључују по 1 GB кеш меморије, при чему се кеш меморија пресликава на све контролере ради одржавања конзистентности и побољшања перформанси, а заштита кеша је заснована на суперкондензаторима уместо традиционалних батерија.

Комуникација између контролера се обично обавља путем SAS линкова , елиминишући потребу за Ethernet линковима за синхронизацију стања диска. Ово обезбеђује директан и веома поуздан комуникациони пут између два чвора за складиштење података.

Још једна важна карактеристика је да ове архитектуре обично раде у активном/активном режиму на истом RAID низу . То значи да оба чвора пружају услугу истовремено и користе рачунарску снагу оба сервера, уместо да један оставе „у стању приправности“ док други не откаже. Ово избегава губљење 50% инвестиције у хардвер што се обично дешава код активно/пасивних кластера.

Надоградњом на Windows Server 2012 (или новије верзије), администратори имају користи од познатог окружења за управљање: познатих алата, чаробњака, конзоле за управљање и модела дозвола. Време учења је минимизирано, што такође смањује оперативне трошкове и ризике током имплементације.

Ова HA-DAS решења су усмерена ка различитим употребама: виртуелизација Hyper-V сервера, Windows VDI, SAN/NAS складиштење, трансакционе базе података (OLTP) , складиштење података и веб сервиси високе доступности . Све се ово постиже коришћењем једног дељеног шасије за складиштење, два редундантна чвора и Windows логике кластеровања.

Висока доступност посебно за QNAP NAS низове и Virtualization Station 4

У NAS сектору, произвођачи попут QNAP-а развили су напредне функције како би постигли високу доступност и за складиштење и за виртуелне машине које се налазе на њиховим уређајима . Конкретно, они комбинују QuTS hero оперативни систем (базиран на ZFS-у) са Virtualization Station 4 како би понудили репликацију у реалном времену и пребацивање између два NAS уређаја.

С једне стране, QuTS hero систем интегрише технологије високе доступности (HA) у сам NAS , омогућавајући да се два идентична (или слична) уређаја конфигуришу као пар високе доступности. Ако један NAS откаже, други преузима контролу, а сервиси остају оперативни. Ово штити и складиште и основне сервисе NAS-а.

На темељу тих принципа, нова функционалност високе доступности у Virtualization Station 4 (доступна у бета верзији у новијим верзијама) иде корак даље: омогућава виртуелним машинама које раде на NAS-у да имају напредну толеранцију на грешке кроз репликацију у реалном времену између два QNAP уређаја.

Ова функција је доступна само на QNAP NAS уређајима са x86 процесорима који покрећу QuTS hero и одговарајућу верзију Virtualization Station 4. Употреба ZFS и SnapSync технологије је неопходна, јер синхронизује податке виртуелне машине између два NAS уређаја у реалном времену, осигуравајући да је реплицирана виртуелна машина увек ажурирана.

Шема рада је заснована на два NAS уређаја који међусобно праве резервне копије : NAS A и NAS B делују као резервни чворови један за другог, двосмерно. Сваки може имати своје виртуелне машине, а за оне које су означене као HA заштићене, реплика се креира на другом NAS-у. У случају квара једног од уређаја, други преузима контролу и покреће погођене виртуелне машине.

Ово омогућава беспрекорно пребацивање NAS сервера . Заштита високе доступности (HA) може се активирати само за одређене критичне виртуелне машине без утицаја на друге NAS сервисе (нпр. резервне копије, дељење датотека итд.). Сваки NAS може наставити да обавља своју оригиналну функцију, а истовремено штити виртуелне машине одређене за високу доступност.

Синхронизација у реалном времену заснована на SnapSync-у осигурава да је, у случају инцидента, прелазак на резервни систем практично тренутан и без губитка података . За разлику од традиционалних архитектура које се ослањају на централни дељени простор за складиштење података (SAN), ово решење елиминише ту јединствену тачку отказа: сваки NAS одржава комплетну и конзистентну копију виртуелних машина које штити.

Штавише, QNAP дефинише више услова отказа који могу покренути пребацивање у случају отказа : продужено преоптерећење процесора (изнад одређеног прага, на пример, 80% током одређеног временског периода), прекомерна температура система, квар диска чак и у RAID конфигурацијама, губитак једног од редундантних извора напајања, између осталог. Систем процењује ове услове и, ако се NAS сматра непоузданим, пребацује оптерећење на други чвор.

Систем такође нуди могућност ручних миграција , што је веома корисно када технички тим жели да мигрира виртуелне машине на други NAS на контролисан начин за задатке одржавања као што су замена дискова, ажурирање фирмвера, промена напредних подешавања итд. Миграција је веома брза (мање од секунде), што процес чини практично транспарентним за кориснике.

Још једна занимљива ствар је да нема додатних трошкова лиценцирања : функционалност високе доступности у Virtualization Station 4 је део саме апликације и укључена је у систем, без додатних плаћања по чвору или по виртуелној машини. Ово је чини посебно атрактивном за мала и средња предузећа и окружења која траже високу доступност по разумној цени.

Захтеви и ограничења високе доступности у QNAP-у

Да би се ово решење успешно применило на QNAP-у, неопходно је испунити одређене софтверске, хардверске и мрежне захтеве . Они нису изузетно сложени, али је важно бити веома јасан у вези са њима пре дизајнирања окружења.

Што се тиче софтвера, потребни су QuTS hero верзија h5.3 или новија и Virtualization Station 4.1 или новија. Само ове верзије укључују VM HA функционалност засновану на SnapSync-у. Ова функција није доступна на NAS уређајима са „класичним“ QTS-ом или старијим верзијама Virtualization Station-а.

На нивоу хардвера, два NAS уређаја не морају бити потпуно истог модела, али морају користити процесоре исте архитектуре и марке (или оба Intel или оба AMD) . Ово поједностављује компатибилност и осигурава да реплициране виртуелне машине могу глатко да раде на било ком уређају.

Што се тиче мреже, неопходно је да оба NAS уређаја буду на истом сегменту мреже и да постоји директна веза између њих помоћу наменског физичког мрежног кабла за синхронизацију података виртуелне машине. Ова наменска веза делује као „ванпојасни“ канал за репликацију, спречавајући ометање нормалног корисничког саобраћаја.

У пракси, стварни хардверски захтеви се своде на ово: иста фамилија процесора и директна веза између NAS уређаја . Све остало (капацитет диска, RAM меморија итд.) се скалира на основу броја виртуелних машина које треба заштитити и очекиваних перформанси. Ако су ови услови испуњени, подешавање високе доступности QNAP-а је релативно једноставно и веома робусно.

Разлика између високе доступности и једноставне репликације/DR у виртуелним машинама

Решења за репликацију виртуелних машина као механизам за опоравак од катастрофе често се мешају са истинском високом доступношћу без застоја (или минималним застојем). Оба су важна, али решавају различите проблеме.

На пример, у VMware vSphere окружењима, уобичајено је конфигурисати репликацију виртуелних машина на локацију за опоравак од катастрофе (DR) , тако да се слика диска примарног сервера копира на чвор за опоравак од катастрофе. Ово штити од потпуног губитка примарне локације, али када дође до отказа, обично је неопходан ручни опоравак: укључивање виртуелних машина на DR локацији, реконфигурација мрежа, валидација интегритета података и тако даље.

Овај процес, иако делимично аутоматизован, подразумева застој који може да траје од неколико минута до неколико сати, у зависности од сложености окружења и интерних процедура. То је одлична DR стратегија, али не испуњава циљ готово континуиране доступности који се очекује од строгог HA решења.

Права висока доступност захтева аутоматски или скоро аутоматски механизам за прелазак у случају отказа са веома малим временом застоја и без потребе за сложеним ручним операцијама када компонента откаже. Штавише, синхронизација података између активних и резервних чворова мора бити довољно чврста да би се спречио или минимизирао губитак скорашњих информација.

Стога је, приликом пројектовања високо доступног виртуелног окружења, неопходно правилно комбиновати технологије кластеровања, репликацију у скоро реалном времену, редундантно складиштење и проактивно праћење . Само на овај начин корисници могу да наставе да приступају веб локацији, бази података или корпоративној апликацији уз минималне прекиде, чак и ако се цео сервер или NAS изненада искључи.

У пракси, најчешћи приступ је допуњавање локалне високе доступности (на пример, кластер унутар истог дата центра) стратегијом опоравка од катастрофе на другој локацији . На овај начин, покривени су и свакодневни кварови (дискови, сервери, напајања итд.) и озбиљнији догађаји (пожари, дуготрајни нестанци струје, природне катастрофе).

Овај широк спектар решења — RHEL и Hyper-V кластери, HA-DAS архитектуре без SAN мреже, наменска висока доступност на QNAP NAS-у са Virtualization Station-ом и напредна репликација виртуелних машина — показује да је сада могуће дизајнирати виртуелизована окружења са високом отпорношћу на грешке, прилагођена различитим величинама и буџетима компанија . Темељно разумевање разлика између сваког приступа, њихових ограничења (као што су максималан број чворова или потреба за дељеним складиштем) и њихових техничких захтева је кључно за избор праве комбинације и одржавање критичних сервиса готово беспрекорним.