- Disponueshmëria e lartë në serverat e virtualizuar kombinon grupet, replikimin dhe ruajtjen e tepërt për të minimizuar kohën e ndërprerjes.
- Zgjidhjet RHEL, Hyper-V, HA-DAS dhe NAS si QNAP ofrojnë qasje të ndryshme HA në varësi të madhësisë, buxhetit dhe nevojave.
- Replikimi për DR nuk zëvendëson një HA të vërtetë: ndërprerja automatike dhe pothuajse e pandërprerë e funksionimit kërkon sinkronizim pothuajse në kohë reale.
- Projektimi i duhur i arkitekturës dhe respektimi i kërkesave të harduerit, rrjetit dhe softuerit është çelësi për të siguruar vazhdimësinë e shërbimit.
Disponueshmëria e lartë në serverat e virtualizuar është bërë një kërkesë themelore për çdo organizatë që nuk mund të përballojë ndërprerjet e shërbimit, qoftë edhe vetëm për pak minuta. Po flasim për sigurimin që makinat, aplikacionet dhe të dhënat tuaja virtuale të mbeten të arritshme edhe nëse një server fizik, disk, rrjet apo edhe një qendër e tërë të dhënash dështon. Nuk ka të bëjë vetëm me ruajtjen e kopjeve rezervë, por me mbajtjen e shërbimit në funksionim pavarësisht gjithçkaje.
Kur kombinojmë virtualizimin , klasterat, ruajtjen dhe rimëkëmbjen nga fatkeqësitë , dalin në pah shumë teknologji (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, kopje, etj.), dhe nuk është gjithmonë e qartë se cilën të zgjedhim ose si t'i kombinojmë të gjitha së bashku. Ky artikull ofron një shqyrtim të thelluar të opsioneve dhe qasjeve kryesore: nga klasterat tradicionalë me ruajtje të përbashkët deri te zgjidhjet moderne të bazuara në replikimin në kohë reale midis nyjeve, duke përfshirë shembuj specifikë me arkitekturat Red Hat, Microsoft Hyper-V, QNAP dhe HA-DAS.
Konceptet themelore të disponueshmërisë së lartë në mjedise të virtualizuara
Në një mjedis të virtualizuar, disponueshmëria e lartë (HA) do të thotë që VM-të mbeten të arritshme edhe nëse një ose më shumë komponentë të sistemit (servera, disqe, kontrollues, rrjet, furnizim me energji, etj.) dështojnë. Kjo nuk është e njëjtë me rimëkëmbjen nga fatkeqësitë (DR): HA synon një kohë ndërprerjeje minimale ose pothuajse zero, ndërsa DR zakonisht pranon një kohë ndërprerjeje për të rivendosur shërbimet nga një kopje rezervë.
Për të arritur këtë sjellje, kombinohen disa komponentë: redundanca e harduerit, softueri i klasterit, ruajtja tolerante ndaj defekteve dhe mekanizmat e monitorimit dhe të dështimit . Qëllimi është të shmangen pikat e vetme të dështimit: nëse një komponent prishet, një tjetër merr përsipër pa ndërhyrje manuale (ose me ndërhyrje minimale).
Në botën e virtualizimit, kjo zakonisht përkthehet në pasjen e shumë hosteve fizike që ndajnë ose replikojnë hapësirën e ruajtjes , dhe një sistemi që monitoron statusin e nyjeve dhe VM-ve. Kur një host dështon, makinat virtuale fillojnë në një host tjetër, idealisht pa e vënë re përdoruesi ose me një ndërprerje shumë të shkurtër.
Është gjithashtu e rëndësishme të bëhet dallimi midis zgjidhjeve të dizajnuara për mjedise elastike "të ngjashme me cloud-in" dhe platformave klasike HA. Disa produkte të klasterit kanë një konfigurim relativisht statik dhe një numër maksimal relativisht të ulët nyjesh, kështu që ato nuk janë të përshtatshme për krijimin e një cloud-i masiv, megjithëse janë të shkëlqyera për mbrojtjen e një grupi të mirëpërcaktuar shërbimesh kritike.
Në një mjedis cloud ose hibrid, këshillohet të rishikohen strategjitë specifike të migrimit dhe vazhdimësisë: për shembull, migrimi në cloud mund të jetë pjesë e strategjisë së rimëkëmbjes nga fatkeqësitë, por nuk zëvendëson HA lokale.
Disponueshmëri e lartë në platformat Red Hat Enterprise Linux dhe KVM/Xen
Ekosistemi Red Hat ofron disa mundësi për mbrojtjen e makinave virtuale duke përdorur grupe dhe shtesa me disponueshmëri të lartë . Versione si Red Hat Enterprise Linux 5 dhe 6 mbështesin kombinime të ndryshme të hipervizorëve dhe shtesave të grupeve.
RHEL 5 mbështet dy platforma virtualizimi: Xen (nga RHEL 5.0 e tutje) dhe KVM (nga RHEL 5.4 e tutje) . Shtesa e RHEL 5 Advanced Platform (AP) Cluster ju lejon të menaxhoni si VM-të Xen ashtu edhe KVM si burime të klasterit, kështu që infrastruktura me disponueshmëri të lartë e hostit kontrollon nisjen, mbylljen dhe ndërprerjen e funksionimit të makinave virtuale midis nyjeve.
Me RHEL 6, mbështetja për virtualizimin thjeshtohet: vetëm KVM mbështetet si hipervizor . Megjithatë, shtojca RHEL 6 High Availability ende lejon që makinat virtuale KVM të trajtohen si burime të klasterit të menaxhuara nga infrastruktura HA e hostit. Menaxheri i burimeve të klasterit (rgmanager në versionet klasike) është përgjegjës për monitorimin e nyjeve dhe lëvizjen e mysafirëve midis serverëve fizikë kur zbulohet një dështim.
Kjo qasje shpesh quhet " RHEL Cluster/HA që funksionon në hostë fizikë që veprojnë si një platformë virtualizimi ". Vetë klasteri RHEL menaxhon se ku funksionon secila VM dhe merr përsipër në rast të një dështimi të nyjes, duke siguruar që makinat virtuale të konfiguruara si kritike të rinisen në një host të shëndetshëm.
Një aspekt interesant është se, nga perspektiva e klasterit, sistemi operativ mysafir i VM-së është më pak i rëndësishëm . Çdo sistem operativ mysafir i pajtueshëm me Xen ose KVM në RHEL mund të trajtohet si një makinë virtuale me disponueshmëri të lartë: versione të ndryshme të RHEL (3, 4, 5, etj.) dhe botime të ndryshme të Microsoft Windows, për sa kohë që ato mbështeten nga hipervizori. Kjo ofron fleksibilitet të konsiderueshëm kur sigurohen mjedise të përziera.
Megjithatë, vetë Red Hat rekomandon kujdes kur zgjidhni midis përdorimit të RHEL High Availability Add-on ose platformave më gjithëpërfshirëse të virtualizimit si Red Hat Enterprise Virtualization (RHEV) për të siguruar disponueshmëri të lartë për VM-të. Të dyja ofrojnë funksionalitet me disponueshmëri të lartë, por rastet e përdorimit janë të ndryshme dhe duhet të merren në konsideratë madhësia e mjedisit dhe modeli operativ.
Kur të përdoret RHEL HA kundrejt RHEV për disponueshmëri të lartë
Kur vendosni nëse do të përdorni shtesën RHEL HA ose një platformë si RHEV për të mbrojtur makinat virtuale, një nga kriteret kryesore është numri i hosteve fizikë dhe lloji i përdorimit që do t'i jepet mjedisit të virtualizuar.
Shtesa me disponueshmëri të lartë e RHEL është projektuar për kllasterë relativisht të vegjël, të konfiguruar statikisht . Tradicionalisht, këto kllasterë kanë një limit maksimal prej rreth 16 nyjesh fizike, i cili është i mjaftueshëm për shumë mjedise korporatash, por nuk përshtatet mirë me arkitekturat e ngjashme me cloud-in me dhjetëra ose qindra hoste që ndryshojnë vazhdimisht.
Prandaj, dokumentacioni i vetë Red Hat tregon se përdorimi i RHEL HA ekskluzivisht për të ndërtuar infrastruktura të ngjashme me cloud-in nuk rekomandohet , pikërisht për shkak të natyrës së tij statike dhe limitit të numrit të nyjeve. Për skenarët e cloud-it, ka më shumë kuptim të përdoren platforma të projektuara posaçërisht për atë model, me menaxherë burimesh më elastikë dhe të shkallëzueshëm.
Nga ana tjetër, nëse qëllimi është mbrojtja e një numri të moderuar të VM-ve kritike në një grup hostësh të përcaktuar mirë , shtesa HA e RHEL është një zgjidhje e fuqishme: ajo integrohet mirë me sistemin operativ, mbështetet në teknologjitë e zhvilluara të grupimit dhe ofron logjikën e nevojshme për të monitoruar dhe lëvizur VM-të në rast të dështimit.
Sidoqoftë, këshillohet të rishikoni dokumentacionin më të fundit të RHEL mbi sistemet operative mysafire të mbështetura dhe kombinimet e hipervizorëve dhe klasterave , sepse mbështetja evoluon me çdo version dhe është e rëndësishme t'i përmbaheni matricave zyrtare.
Disponueshmëri e lartë në Hyper-V: grupe, kopje dhe migrim i drejtpërdrejtë
Në mjediset e Microsoft, disponueshmëria e lartë bazohet në thelb në aftësitë e Hyper-V të kombinuara me Windows Server Failover Clustering . Qëllimi është të kesh akses të vazhdueshëm në makinat virtuale edhe në rast të dështimeve të harduerit, problemeve të rrjetit ose gabimeve të softuerit.
Komponenti kryesor janë klasterët Hyper-V me ndërprerje të funksionimit . Një klaster i tillë është një grup serverash (nyjesh) që ndajnë hapësirën e ruajtjes dhe punojnë në një mënyrë të koordinuar: nëse një nyje dështon, makinat virtuale që po ekzekutonte rinisen automatikisht në një nyje tjetër në klaster. E gjithë kjo mbështetet nga teknologjitë e diskut të përbashkët dhe komunikimet specifike të brendshme.
Që kjo të funksionojë, nyjet zakonisht ndajnë hapësirën e ruajtjes nëpërmjet një SAN (Rrjeti i Zonës së Ruajtjes) ose një serveri skedarësh të shkallëzuar (SOFS) . Vëllimet e Ndarura të Grumbujve (CSV) krijohen më pas në krye të kësaj shtrese , duke u lejuar të gjitha nyjeve të qasen njëkohësisht në të njëjtat disqe ku ndodhen skedarët e makinës virtuale.
Nyjet komunikojnë gjithashtu nëpërmjet një rrjeti të dedikuar të njohur si rrahjet e zemrës së klasterit . Ky rrjet është i ndarë nga rrjeti i të dhënave të prodhimit dhe i lejon çdo serveri të raportojë se është aktiv. Nëse klasteri ndalon së marri rrahje zemre nga një nyje, ai konsiderohet se ka dështuar dhe nisin procedurat e ndërrimit të të dhënave.
Një element tjetër themelor është konfigurimi i kuorumit . Kuorumi përcakton se sa vota (nyje ose dëshmitarë të jashtëm) duhet të jenë aktive që klasteri të vazhdojë të funksionojë. Kjo parandalon skenarët e "traumës së ndarë", ku grupet e izoluara të nyjeve gabimisht besojnë se janë klasteri kryesor dhe shkaktojnë korruptim të të dhënave. Zgjedhja e modelit të duhur të kuorumit (nyje, dëshmitar disku, dëshmitar i ndarjes së skedarëve, etj.) është çelësi i stabilitetit.
Bazuar në këtë, Hyper-V shfrytëzon aftësitë e klasterit për të mundësuar migrime të drejtpërdrejta të makinave virtuale midis nyjeve me kohë minimale ndërprerjeje . Gjatë mirëmbajtjes ose balancimit të ngarkesës, një VM mund të zhvendoset nga një host në tjetrin pa ndërprerje të shërbimit, duke transferuar në mënyrë transparente memorien, gjendjen dhe lidhjet aktive.
Nëse, në vend të mirëmbajtjes së planifikuar, ndodh një dështim i vërtetë i harduerit ose softuerit në një nyje, klasteri kryen një ndërprerje automatike . Makinat virtuale që funksionojnë atje rikthehen në një host tjetër me qasje në të njëjtën hapësirë ruajtjeje të përbashkët. Ndërprerja është më e madhe sesa në një migrim të drejtpërdrejtë (VM-të duhet të fiken dhe ndizen), por vazhdimësia e shërbimit ruhet me ndërhyrje minimale njerëzore.
Përveç klasterit klasik SAN, Hyper-V përfshin teknologji të tjera të fokusuara si në disponueshmëri të lartë ashtu edhe në rikuperimin nga fatkeqësitë, veçanërisht Hyper-V Replica dhe migrimin e drejtpërdrejtë pa ruajtje të përbashkët.
Replikimi Hyper-V është një veçori replikimi asinkrone e makinave virtuale që replikon makinat virtuale midis një hosti primar dhe një ose më shumë hosteve replika, zakonisht të vendosura në një vend ose qendër të dhënash të ndryshme. Ndryshimet dërgohen në VM-në e synuar në intervale të rregullta, duke krijuar pika rikuperimi që lejojnë që VM të rikthehet në një gjendje të kohëve të fundit nëse faqja primare përjeton një fatkeqësi.
Ky mekanizëm përdor një agjent replikimi Hyper-V që koordinon trafikun e replikimit, menaxhon pikat e rikuperimit dhe centralizon operacionet e dështimit. Ai lejon si dështimet e planifikuara (për shembull, zhvendosjen e prodhimit në një vend tjetër) ashtu edhe dështimet e paplanifikuara (kur vendi kryesor bie papritur).
Për shkak të natyrës së saj asinkrone, replikimi është më i orientuar drejt rimëkëmbjes nga fatkeqësitë ( DR) sesa drejt disponueshmërisë së lartë (HA) me ndërprerje pothuajse zero . Pas një incidenti, duhet të iniciohet një dështim në VM-në replikë, dhe megjithëse procesi është mjaft i shkathët, ai përfshin disa ndërprerje dhe humbjen e mundshme të sekondave ose minutave të fundit të të dhënave, varësisht nga intervali i konfiguruar i replikimit.
Paralelisht, Hyper-V ofron migrimin e drejtpërdrejtë të Shared Nothing , i cili ju lejon të zhvendosni një VM midis hosteve që nuk ndajnë hapësirën e ruajtjes. Në këtë model, secili host ka hapësirën e vet të ruajtjes lokale, por migrimi i drejtpërdrejtë kopjon në mënyrë transparente disqet e makinës virtuale në destinacion ndërsa VM mbetet në linjë, dhe më pas e kalon ekzekutimin në serverin e ri.
Ky funksionalitet është veçanërisht i dobishëm në mjedise pa një SAN ose infrastrukturë të përbashkët ruajtjeje , duke zvogëluar koston fillestare për ndërmarrjet e vogla dhe të mesme ose skenarë ku mirëmbajtja e një rrjeti të dedikuar ruajtjeje është e padëshirueshme. Ai lejon, për shembull, riorganizimin e hosteve ose migrimin në harduer të ri me ndikim minimal, pa pasur nevojë të mbyllen makinat ekzistuese.
Kombinimi i këtyre teknologjive (grupimet e ndërrimit të të dhënave, CSV, migrimi i drejtpërdrejtë me ose pa ruajtje të përbashkët dhe replikimi Hyper-V) ofron një gamë të gjerë opsionesh për hartimin e strategjive të vazhdimësisë së biznesit dhe tolerancës ndaj gabimeve të përshtatura për buxhete dhe nivele të ndryshme kërkese.
Zgjidhje me disponueshmëri të lartë me HA-DAS dhe Windows Server
Përtej mjediseve me SAN të mëdha, ekzistojnë arkitektura të projektuara për disponueshmëri të lartë në sistemet e ruajtjes të lidhura direkt me serverat (HA-DAS) . Këto zgjidhje shfrytëzojnë Windows Server (p.sh., 2012) dhe kontrolluesit e përparuar RAID/HBA për të ofruar grupe me disponueshmëri të lartë pa pasur nevojë të konfiguroni një iSCSI ose FC SAN tradicional.
Kjo qasje përdor dy nyje klasteri HA me hapësirë ruajtjeje të përbashkët JBOD (vetëm një grumbull disqesh pa asnjë inteligjencë të integruar). JBOD lidhet me të dy serverat nëpërmjet kontrolluesve të tepërt Host RAID HBA, kështu që secila nyje sheh të njëjtin grup disqesh dhe mund të hyjë në të njëjtin grup RAID njëkohësisht.
Këto zgjidhje mund të arrijnë kapacitete deri në 180 TB në një shasi të përbashkët , duke punuar me disqe magnetike me ndërrim të shpejtë ose SSD në nivele të ndryshme RAID. Kontrolluesit RAID zakonisht përfshijnë 1 GB memorie të përkohshme secili, me memorien e përkohshme të pasqyruar në të gjithë kontrolluesit për të ruajtur qëndrueshmërinë dhe për të përmirësuar performancën, si dhe mbrojtjen e memories së përkohshme të bazuar në superkondensatorë në vend të baterive tradicionale.
Komunikimi midis kontrolluesve kryhet zakonisht nëpërmjet lidhjeve SAS , duke eliminuar nevojën për lidhje Ethernet me ritëm të shpejtë për sinkronizimin e gjendjes së diskut. Kjo siguron një rrugë komunikimi të drejtpërdrejtë dhe shumë të besueshme midis dy nyjeve të ruajtjes.
Një tjetër veçori e rëndësishme është se këto arkitektura zakonisht funksionojnë në modalitetin aktiv/aktiv në të njëjtin grup RAID . Kjo do të thotë që të dy nyjet ofrojnë shërbim njëkohësisht dhe shfrytëzojnë fuqinë llogaritëse të të dy serverave, në vend që ta lënë njërin "në pritje" derisa tjetri të dështojë. Kjo shmang humbjen e 50% të investimit në harduer që zakonisht ndodh në grupet aktive/pasive.
Duke u bazuar në Windows Server 2012 (ose versione më të reja), administratorët përfitojnë nga një mjedis menaxhimi i njohur: mjete, asistentë ndihmës, konsol menaxhimi dhe model lejesh të njohura. Koha e të mësuarit minimizohet, gjë që gjithashtu zvogëlon kostot operative dhe rreziqet gjatë zbatimit.
Këto zgjidhje HA-DAS janë të orientuara drejt përdorimeve të ndryshme: virtualizimi i serverit Hyper-V, Windows VDI, ruajtja SAN/NAS, bazat e të dhënave transaksionale (OLTP) , ruajtja e të dhënave dhe shërbimet web me disponueshmëri të lartë . E gjithë kjo arrihet duke shfrytëzuar një shasi të vetme ruajtëse të përbashkët, dy nyje të tepërta dhe logjikën e grumbullimit të Windows.
Disponueshmëri e lartë posaçërisht për vargjet QNAP NAS dhe Virtualization Station 4
Në sektorin e NAS, prodhues si QNAP kanë zhvilluar veçori të përparuara për të arritur disponueshmëri të lartë si për ruajtjen ashtu edhe për makinat virtuale të vendosura në pajisjet e tyre . Në mënyrë specifike, ata kombinojnë sistemin operativ QuTS hero (bazuar në ZFS) me Virtualization Station 4 për të ofruar replikim në kohë reale dhe ndërprerje midis dy pajisjeve NAS.
Nga njëra anë, sistemi hero QuTS integron teknologji me disponueshmëri të lartë (HA) në vetë NAS , duke lejuar që dy pajisje identike (ose të ngjashme) të konfigurohen si një çift me disponueshmëri të lartë. Nëse një NAS dështon, i dyti merr përsipër dhe shërbimet mbeten funksionale. Kjo mbron si ruajtjen ashtu edhe shërbimet kryesore të NAS.
Duke u bazuar në këtë themel, funksionaliteti i ri me disponueshmëri të lartë në Virtualization Station 4 (i disponueshëm në versionet beta në versionet e fundit) e çon atë një hap më tej: u lejon makinave virtuale që funksionojnë në NAS të kenë tolerancë të avancuar ndaj gabimeve përmes replikimit në kohë reale midis dy pajisjeve QNAP.
Kjo veçori është e disponueshme vetëm në pajisjet QNAP NAS me procesorë x86 që përdorin QuTS hero dhe versionin e duhur të Virtualization Station 4. Përdorimi i teknologjisë ZFS dhe SnapSync është thelbësor, pasi sinkronizon të dhënat e VM midis dy pajisjeve NAS në kohë reale, duke siguruar që VM-ja e replikuar të jetë gjithmonë e azhurnuar.
Skema operative bazohet në dy pajisje NAS që mbështesin njëra-tjetrën : NAS A dhe NAS B veprojnë si nyje rezervë për njëra-tjetrën, në mënyrë dypalëshe. Secila mund të ketë makinat e veta virtuale, dhe për ato të shënuara si të mbrojtura nga HA, krijohet një kopje në NAS-in tjetër. Në rast të dështimit të njërës prej pajisjeve, tjetra merr kontrollin dhe nis makinat virtuale të prekura.
Kjo mundëson ndërrimin pa probleme të serverit NAS . Mbrojtja me Disponueshmëri të Lartë (HA) mund të aktivizohet vetëm për makina virtuale specifike kritike pa ndikuar në shërbimet e tjera NAS (p.sh., kopjet rezervë, ndarjen e skedarëve, etj.). Çdo NAS mund të vazhdojë të kryejë funksionin e tij origjinal, duke mbrojtur njëkohësisht makinat virtuale të përcaktuara për disponueshmëri të lartë.
Sinkronizimi në kohë reale i bazuar në SnapSync siguron që, në rast të një incidenti, ndërprerja e funksionimit të sistemit ( failover) të jetë praktikisht e menjëhershme dhe pa humbje të të dhënave . Ndryshe nga arkitekturat tradicionale që mbështeten në një zonë qendrore të përbashkët ruajtjeje (SAN), kjo zgjidhje eliminon atë pikë të vetme dështimi: çdo NAS mban një kopje të plotë dhe të qëndrueshme të VM-ve që mbron.
Për më tepër, QNAP përcakton kushte të shumta dështimi që mund të shkaktojnë një ndërprerje të funksionimit : mbingarkesë e zgjatur e CPU-së (mbi një prag të caktuar, për shembull, 80% për një periudhë kohore), temperaturë e lartë e sistemit, dështim i diskut edhe në konfigurimet RAID, humbje e njërit prej furnizimeve me energji të tepërt, ndër të tjera. Sistemi i vlerëson këto kushte dhe, nëse NAS konsiderohet i pabesueshëm, e zhvendos ngarkesën në nyjen tjetër.
Sistemi ofron gjithashtu mundësinë e migrimeve manuale , të cilat janë shumë të dobishme kur ekipi teknik dëshiron të migrojë makinat virtuale në një NAS tjetër në një mënyrë të kontrolluar për detyra mirëmbajtjeje, të tilla si zëvendësimi i disqeve, përditësimi i firmware-it, ndryshimi i cilësimeve të avancuara, etj. Migrimi është shumë i shpejtë (rreth më pak se një sekondë), duke e bërë procesin praktikisht transparent për përdoruesit.
Një pikë tjetër interesante është se nuk ka kosto shtesë licencimi : funksionaliteti i disponueshmërisë së lartë në Virtualization Station 4 është pjesë e vetë aplikacionit dhe përfshihet në sistem, pa pagesa shtesë për nyje ose për VM. Kjo e bën atë veçanërisht tërheqës për ndërmarrjet e vogla dhe të mesme dhe mjediset që kërkojnë disponueshmëri të lartë me një kosto të arsyeshme.
Kërkesat dhe kufizimet e disponueshmërisë së lartë në QNAP
Për ta vendosur me sukses këtë zgjidhje në QNAP, është thelbësore të përmbushen kërkesa të caktuara për softuer, harduer dhe rrjet . Ato nuk janë jashtëzakonisht komplekse, por është e rëndësishme të jeni shumë të qartë rreth tyre përpara se të dizajnoni mjedisin.
Lidhur me softuerin, kërkohet versioni i heroit QuTS h5.3 ose më i lartë dhe Virtualization Station 4.1 ose më i ri. Vetëm këto versione përfshijnë funksionalitetin VM HA të bazuar në SnapSync. Kjo veçori nuk është e disponueshme në pajisjet NAS me QTS "klasike" ose versione më të hershme të Virtualization Station.
Në nivelin e harduerit, dy pajisjet NAS nuk është e thënë të jenë saktësisht të të njëjtit model, por ato duhet të përdorin procesorë të së njëjtës arkitekturë dhe markë (të dy Intel ose të dy AMD) . Kjo thjeshton përputhshmërinë dhe siguron që VM-të e replikuara të mund të funksionojnë pa probleme në secilën pajisje.
Lidhur me rrjetin, është thelbësore që të dy pajisjet NAS të jenë në të njëjtin segment rrjeti dhe të ketë një lidhje të drejtpërdrejtë midis tyre duke përdorur një kabllo të dedikuar rrjeti fizik për sinkronizimin e të dhënave të makinës virtuale. Kjo lidhje e dedikuar vepron si një kanal "jashtë brezit" për replikim, duke parandaluar ndërhyrjen në trafikun normal të përdoruesit.
Në praktikë, kërkesa aktuale për harduer reduktohet në këtë: e njëjta familje CPU dhe një lidhje e drejtpërdrejtë midis pajisjeve NAS . Çdo gjë tjetër (kapaciteti i diskut, RAM-i, etj.) shkallëzohet bazuar në numrin e VM-ve që duhen mbrojtur dhe performancën e pritur. Nëse plotësohen këto kushte, konfigurimi HA i QNAP është relativisht i thjeshtë dhe shumë i fuqishëm.
Dallimi midis disponueshmërisë së lartë dhe replikimit/DR të thjeshtë në VM-të
Zgjidhjet e replikimit të makinës virtuale si një mekanizëm rikuperimi nga fatkeqësitë shpesh ngatërrohen me disponueshmërinë e lartë të vërtetë me zero ndërprerje (ose ndërprerje minimale). Të dyja janë të rëndësishme, por zgjidhin probleme të ndryshme.
Për shembull, në mjediset VMware vSphere, është e zakonshme të konfigurohet replikimi i VM-së në një vend të rikuperimit nga fatkeqësitë (DR) , në mënyrë që imazhi i diskut të serverit kryesor të kopjohet në nyjen e rikuperimit nga fatkeqësitë. Kjo mbron nga humbja totale e vendit kryesor, por kur dështon, zakonisht është e nevojshme një rikuperim manual: ndezja e VM-ve në vendin e DR, rikonfigurimi i rrjeteve, validimi i integritetit të të dhënave e kështu me radhë.
Ky proces, ndonëse pjesërisht i automatizueshëm, përfshin kohë ndërprerjeje që mund të variojë nga minuta në orë, varësisht nga kompleksiteti i mjedisit dhe procedurat e brendshme. Është një strategji e shkëlqyer DR, por nuk përmbush qëllimin e disponueshmërisë pothuajse të vazhdueshme që pritet nga një zgjidhje strikte HA.
Disponueshmëria e lartë kërkon një mekanizëm automatik ose pothuajse automatik të dështimit të sistemit me kohë shumë të ulët ndërprerjeje dhe pa nevojë për operacione manuale komplekse kur një komponent dështon. Për më tepër, sinkronizimi i të dhënave midis nyjeve aktive dhe atyre rezervë duhet të jetë mjaftueshëm i ngushtë për të parandaluar ose minimizuar humbjen e informacionit të fundit.
Prandaj, kur hartoni një mjedis VM me disponueshmëri të lartë, është thelbësore të kombinoni siç duhet teknologjitë e grupimit, replikimin në kohë pothuajse reale, ruajtjen e tepërt dhe monitorimin proaktiv . Vetëm në këtë mënyrë përdoruesit mund të vazhdojnë të hyjnë në faqen e internetit, bazën e të dhënave ose aplikacionin e korporatës me ndërprerje minimale, edhe nëse një server i tërë ose një NAS fiket papritur.
Në praktikë, qasja më e zakonshme është plotësimi i disponueshmërisë së lartë lokale (për shembull, një klaster brenda të njëjtës qendër të dhënash) me një strategji rikuperimi nga fatkeqësitë në një vendndodhje tjetër . Në këtë mënyrë, mbulohen si dështimet e përditshme (disqet, serverat, furnizimet me energji, etj.) ashtu edhe ngjarjet më serioze (zjarret, ndërprerjet e zgjatura të energjisë, fatkeqësitë natyrore).
Kjo gamë e gjerë zgjidhjesh - grupet RHEL dhe Hyper-V, arkitekturat HA-DAS pa SAN, disponueshmëria e lartë e dedikuar në QNAP NAS me Virtualization Station dhe replikimi i përparuar i VM - demonstron se tani është e mundur të projektohen mjedise të virtualizuara me tolerancë të lartë ndaj gabimeve, të përshtatura për madhësi dhe buxhete të ndryshme të kompanive . Një kuptim i plotë i ndryshimeve midis secilës qasje, kufizimeve të tyre (si numri maksimal i nyjeve ose nevoja për ruajtje të përbashkët) dhe kërkesave të tyre teknike është çelësi për zgjedhjen e kombinimit të duhur dhe mbajtjen e shërbimeve kritike në funksionim pothuajse pa probleme.
