Høy tilgjengelighet på virtualiserte servere: en komplett guide

Informatec Digital » Ressurser » Høy tilgjengelighet på virtualiserte servere: en komplett guide

Høy tilgjengelighet på virtualiserte servere har blitt et grunnleggende krav for enhver organisasjon som ikke har råd til tjenesteavbrudd, selv ikke i noen få minutter. Vi snakker om å sikre at virtuelle maskiner, applikasjoner og data forblir tilgjengelige selv om en fysisk server, disk, nettverk eller til og med et helt datasenter svikter. Det handler ikke bare om å ha sikkerhetskopier, men om å holde tjenesten i gang uansett hva.

Når vi kombinerer virtualisering , klynger, lagring og katastrofegjenoppretting , dukker det opp mange teknologier (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, replikaer osv.), og det er ikke alltid klart hvilken man skal velge eller hvordan man skal få alt sammen. Denne artikkelen gir en grundig gjennomgang av de viktigste alternativene og tilnærmingene: fra tradisjonelle klynger med delt lagring til moderne løsninger basert på sanntidsreplikasjon mellom noder, inkludert spesifikke eksempler med Red Hat-, Microsoft Hyper-V-, QNAP- og HA-DAS-arkitekturer.

Grunnleggende konsepter for høy tilgjengelighet i virtualiserte miljøer

I et virtualisert miljø betyr høy tilgjengelighet (HA) at virtuelle maskiner forblir tilgjengelige selv om én eller flere systemkomponenter (servere, disker, kontrollere, nettverk, strømforsyning osv.) svikter. Dette er ikke det samme som katastrofegjenoppretting (DR): HA tar sikte på minimal eller nesten null nedetid, mens DR vanligvis aksepterer noe nedetid for å gjenopprette tjenester fra en sikkerhetskopi.

For å oppnå denne oppførselen kombineres flere komponenter: maskinvareredundans, klyngeprogramvare, feiltolerant lagring og overvåkings- og failover-mekanismer . Målet er å unngå enkeltstående feilpunkter: hvis én komponent går i stykker, tar en annen over uten manuell inngripen (eller med minimal inngripen).

I virtualiseringens verden betyr dette vanligvis at man har flere fysiske verter som deler eller replikerer lagring , og et system som overvåker statusen til nodene og de virtuelle maskinene. Når én vert svikter, starter de virtuelle maskinene opp på en annen vert, ideelt sett uten at brukeren merker det, eller med et veldig kort avbrudd.

Det er også viktig å skille mellom løsninger designet for elastiske «skylignende» miljøer og klassiske HA-plattformer. Enkelte klyngeprodukter har en relativt statisk konfigurasjon og et relativt lavt maksimalt antall noder, så de er ikke egnet for å sette opp en massiv sky, selv om de er utmerkede for å beskytte et veldefinert sett med kritiske tjenester.

I et sky- eller hybridmiljø er det lurt å gjennomgå spesifikke migrerings- og kontinuitetsstrategier: for eksempel kan skymigrering være en del av strategien for katastrofegjenoppretting, men den erstatter ikke lokal HA.

Høy tilgjengelighet på Red Hat Enterprise Linux og KVM/Xen-plattformer

Red Hat-økosystemet tilbyr flere alternativer for å beskytte virtuelle maskiner ved hjelp av klynger og tilleggsprogrammer med høy tilgjengelighet . Versjoner som Red Hat Enterprise Linux 5 og 6 støtter ulike kombinasjoner av hypervisorer og klyngetillegg.

RHEL 5 støtter to virtualiseringsplattformer: Xen (fra RHEL 5.0 og utover) og KVM (fra RHEL 5.4 og utover) . RHEL 5 Advanced Platform (AP) Cluster-tillegget lar deg administrere både Xen- og KVM-VM-er som klyngeressurser, slik at vertens infrastruktur med høy tilgjengelighet kontrollerer oppstart, avstengning og failover av virtuelle maskiner mellom noder.

Med RHEL 6 er virtualiseringsstøtten forenklet: bare KVM støttes som hypervisor . RHEL 6 High Availability-pluginen tillater imidlertid fortsatt at virtuelle KVM-maskiner behandles som klyngeressurser som administreres av vertens HA-infrastruktur. Klyngeressursbehandleren (rgmanager i klassiske versjoner) er ansvarlig for å overvåke nodene og flytte gjester mellom fysiske servere når en feil oppdages.

Denne tilnærmingen blir ofte referert til som « RHEL-klynge/HA som kjører på fysiske verter og fungerer som en virtualiseringsplattform ». RHEL-klyngen administrerer selv hvor hver virtuelle maskin kjører og tar over i tilfelle nodefeil, slik at virtuelle maskiner som er konfigurert som kritiske, startes på nytt på en fungerende vert.

Et interessant aspekt er at den virtuelle maskinens gjesteoperativsystem er mindre viktig fra klyngens perspektiv . Ethvert Xen- eller KVM-kompatibelt gjesteoperativsystem i RHEL kan behandles som en svært tilgjengelig virtuell maskin: forskjellige versjoner av RHEL (3, 4, 5 osv.) og forskjellige utgaver av Microsoft Windows, så lenge de støttes av hypervisoren. Dette gir betydelig fleksibilitet når man sikrer blandede miljøer.

Red Hat anbefaler imidlertid selv at man er forsiktig når man velger mellom å bruke RHEL High Availability Add-on eller mer omfattende virtualiseringsplattformer som Red Hat Enterprise Virtualization (RHEV) for å gi høy tilgjengelighet for virtuelle maskiner. Begge tilbyr funksjonalitet med høy tilgjengelighet, men brukstilfellene er forskjellige, og størrelsen på miljøet og driftsmodellen må vurderes.

Når man skal bruke RHEL HA kontra RHEV for høy tilgjengelighet

Når man skal bestemme seg for om man skal bruke RHEL HA Add-on eller en plattform som RHEV for å beskytte virtuelle maskiner, er et av hovedkriteriene antall fysiske verter og hvilken type bruk det virtualiserte miljøet skal gis til.

RHELs tilleggsfunksjon for høy tilgjengelighet er utviklet for relativt små, statisk konfigurerte klynger . Tradisjonelt har disse klyngene en maksimal grense på omtrent 16 fysiske noder, noe som er tilstrekkelig for mange bedriftsmiljøer, men passer ikke godt sammen med skylignende arkitekturer med titalls eller hundrevis av verter som stadig skifter.

Derfor indikerer Red Hats egen dokumentasjon at det ikke anbefales å bruke RHEL HA utelukkende til å bygge skylignende infrastrukturer , nettopp på grunn av dens statiske natur og grensen for antall noder. For skyscenarier er det mer fornuftig å bruke plattformer som er spesielt utviklet for den modellen, med mer elastiske og skalerbare ressursforvaltere.

På den annen side, hvis målet er å beskytte et moderat antall kritiske virtuelle maskiner på et veldefinert sett med verter , er RHELs HA-tillegg en robust løsning: det integreres godt med operativsystemet, er avhengig av modne klyngeteknologier og gir den nødvendige logikken for å overvåke og flytte virtuelle maskiner i tilfelle feil.

Uansett anbefales det å gjennomgå den nyeste RHEL-dokumentasjonen om støttede gjesteoperativsystemer og hypervisor- og klyngekombinasjoner , fordi støtten utvikler seg med hver utgivelse, og det er viktig å holde seg til de offisielle matrisene.

Høy tilgjengelighet i Hyper-V: klynger, replikaer og live-migrering

I Microsoft-miljøer er høy tilgjengelighet fundamentalt basert på funksjonene til Hyper-V kombinert med Windows Server Failover Clustering . Målet er å ha konsekvent tilgang til virtuelle maskiner selv i tilfelle maskinvarefeil, nettverksproblemer eller programvarefeil.

Kjernekomponenten er Hyper-V failover-klynger . En slik klynge er et sett med servere (noder) som deler lagring og jobber på en koordinert måte: hvis én node feiler, startes de virtuelle maskinene den kjørte automatisk på nytt på en annen node i klyngen. Alt dette støttes av delte diskteknologier og spesifikk intern kommunikasjon.

For at dette skal fungere, deler noder vanligvis lagring via et SAN (Storage Area Network) eller en skalerbar filserver (SOFS) . Cluster Shared Volumes (CSV-er) opprettes deretter på toppen av dette laget , slik at alle noder samtidig får tilgang til de samme diskene der de virtuelle maskinfilene ligger.

Nodene kommuniserer også via et dedikert nettverk kjent som klyngens hjerteslag . Dette nettverket er atskilt fra produksjonsdatanettverket og lar hver server rapportere at den er aktiv. Hvis klyngen slutter å motta hjerteslag fra en node, anses den å ha feilet, og failover-prosedyrer igangsettes.

Et annet grunnleggende element er quorumkonfigurasjonen . Quorumet definerer hvor mange stemmer (noder eller eksterne vitner) som må være aktive for at klyngen skal fortsette å fungere. Dette forhindrer "split brain"-scenarier, der isolerte grupper av noder feilaktig tror at de er hovedklyngen og forårsaker datakorrupsjon. Å velge riktig quorummodell (noder, diskvitne, fildelingsvitne osv.) er nøkkelen til stabilitet.

Basert på dette utnytter Hyper-V klyngefunksjoner for å muliggjøre live-migrering av virtuelle maskiner mellom noder med minimal nedetid . Under vedlikehold eller lastbalansering kan en virtuell maskin flyttes fra en vert til en annen uten avbrudd i tjenesten, og overføre minne, tilstand og aktive tilkoblinger transparent.

Hvis det i stedet for planlagt vedlikehold oppstår en faktisk maskinvare- eller programvarefeil på en node, utfører klyngen en automatisk failover . De virtuelle maskinene som kjører der, startes på en annen vert med tilgang til samme delte lagring. Forstyrrelsen er større enn ved en live-migrering (de virtuelle maskinene må slås av og på), men tjenestekontinuiteten opprettholdes med minimal menneskelig inngripen.

Hyper-V-replika og live-migrering «delte ingenting»

I tillegg til den klassiske SAN-klyngen, inkluderer Hyper-V andre teknologier fokusert på både høy tilgjengelighet og katastrofegjenoppretting, særlig Hyper-V Replica og live-migrering uten delt lagring.

Hyper-V-replikering er en asynkron replikeringsfunksjon for virtuelle maskiner som replikerer virtuelle maskiner mellom en primær vert og én eller flere replikaverter, vanligvis plassert på et annet sted eller datasenter. Endringer sendes til den virtuelle målmaskinen med jevne mellomrom, og oppretter dermed gjenopprettingspunkter som gjør at den virtuelle maskinen kan gjenopprettes til en nylig tilstand hvis primærstedet opplever en katastrofe.

Denne mekanismen bruker en Hyper-V-replikasjonsagent som koordinerer replikasjonstrafikk, administrerer gjenopprettingspunkter og sentraliserer failover-operasjoner. Den tillater både planlagte failovers (for eksempel å flytte produksjon til et annet sted) og uplanlagte failovers (når det primære stedet går uventet ned).

På grunn av sin asynkrone natur er replikering mer orientert mot katastrofegjenoppretting ( DR) enn nær null nedetid med høy tilgjengelighet (HA) . Etter en hendelse må en failover startes på den virtuelle replikaen, og selv om prosessen er ganske smidig, innebærer den noe nedetid og potensielt tap av de siste sekundene eller minuttene med data, avhengig av det konfigurerte replikeringsintervallet.

Parallelt tilbyr Hyper-V Shared Nothing live migration , som lar deg flytte en virtuell maskin mellom verter som ikke deler lagring. I denne modellen har hver vert sin egen lokale lagring, men live migration kopierer transparent den virtuelle maskinens disker til destinasjonen mens den virtuelle maskinen forblir online, og bytter deretter kjøring til den nye serveren.

Denne funksjonaliteten er spesielt nyttig i miljøer uten SAN eller delt lagringsinfrastruktur , og reduserer startkostnadene for små og mellomstore bedrifter eller scenarier der det ikke er ønskelig å opprettholde et dedikert lagringsnettverk. Den tillater for eksempel omorganisering av verter eller migrering til ny maskinvare med minimal innvirkning, uten å måtte slå av eksisterende maskiner.

Kombinasjonen av disse teknologiene (failover-klynger, CSV, live-migrering med eller uten delt lagring og Hyper-V-replikering) gir et bredt spekter av alternativer for å utforme strategier for forretningskontinuitet og feiltoleranse, skreddersydd for ulike budsjetter og etterspørselsnivåer.

Løsninger med høy tilgjengelighet med HA-DAS og Windows Server

Utover miljøer med store SAN-er finnes det arkitekturer designet for høy tilgjengelighet i lagringssystemer som er direkte koblet til servere (HA-DAS) . Disse løsningene utnytter Windows Server (f.eks. 2012) og avanserte RAID/HBA-kontrollere for å levere klynger med høy tilgjengelighet uten behov for å sette opp et tradisjonelt iSCSI- eller FC-SAN.

Denne tilnærmingen bruker to HA-klyngenoder med delt JBOD-lagring (bare en haug med disker uten innebygd intelligens). JBOD-en kobles til begge serverne via redundante Host RAID HBA-kontrollere, slik at hver node ser det samme settet med disker og kan få tilgang til det samme RAID-arrayet samtidig.

Disse løsningene kan oppnå kapasiteter på opptil 180 TB i et delt kabinett , og fungerer med hot-swap magnetiske disker eller SSD-disker i forskjellige RAID-nivåer. RAID-kontrollerne har vanligvis 1 GB hurtigbuffer hver, med hurtigbufferen speilet på tvers av kontrollere for å opprettholde konsistens og forbedre ytelsen, og hurtigbufferbeskyttelse basert på superkondensatorer i stedet for tradisjonelle batterier.

Kommunikasjon mellom kontrollere utføres vanligvis via SAS-koblinger , noe som eliminerer behovet for hjerteslags-Ethernet-koblinger for synkronisering av disktilstand. Dette gir en direkte og svært pålitelig kommunikasjonsbane mellom de to lagringsnodene.

En annen viktig funksjon er at disse arkitekturene vanligvis opererer i aktiv/aktiv-modus på samme RAID-array . Dette betyr at begge nodene tilbyr tjenester samtidig og utnytter datakraften til begge serverne, i stedet for å la den ene være "på standby" til den andre svikter. Dette unngår å kaste bort 50 % av maskinvareinvesteringen som vanligvis skjer i aktive/passive klynger.

Ved å bygge på Windows Server 2012 (eller senere versjoner) drar administratorer nytte av et kjent administrasjonsmiljø: kjente verktøy, veivisere, administrasjonskonsoll og tillatelsesmodell. Læringstiden minimeres, noe som også reduserer driftskostnader og risikoer under implementeringen.

Disse HA-DAS-løsningene er rettet mot ulike bruksområder: Hyper-V-servervirtualisering, Windows VDI, SAN/NAS-lagring, transaksjonsdatabaser (OLTP) , datavarehus og webtjenester med høy tilgjengelighet . Alt dette oppnås ved å utnytte et enkelt delt lagringskabinett, to redundante noder og Windows-klyngelogikk.

Høy tilgjengelighet spesielt for QNAP NAS-arrayer og Virtualization Station 4

Innen NAS-sektoren har produsenter som QNAP utviklet avanserte funksjoner for å oppnå høy tilgjengelighet for både lagring og de virtuelle maskinene som ligger på enhetene deres . Mer spesifikt kombinerer de operativsystemet QuTS hero (basert på ZFS) med Virtualization Station 4 for å tilby replikering og failover i sanntid mellom to NAS-enheter.

På den ene siden integrerer QuTS Hero-systemet teknologier for høy tilgjengelighet (HA) i selve NAS-en , slik at to identiske (eller lignende) enheter kan konfigureres som et par med høy tilgjengelighet. Hvis én NAS svikter, tar den andre over, og tjenestene forblir i drift. Dette beskytter både lagringen og NAS-ens kjernetjenester.

Byggende på dette fundamentet tar den nye funksjonaliteten med høy tilgjengelighet i Virtualization Station 4 (tilgjengelig i beta i nyere versjoner) det et skritt videre: den lar virtuelle maskiner som kjører på NAS-en ha avansert feiltoleranse gjennom sanntidsreplikering mellom to QNAP-enheter.

Denne funksjonen er bare tilgjengelig på QNAP NAS-enheter med x86-prosessorer som kjører QuTS hero og riktig versjon av Virtualization Station 4. Bruk av ZFS- og SnapSync-teknologi er viktig, ettersom den synkroniserer VM-data mellom de to NAS-enhetene i sanntid, noe som sikrer at den replikerte VM alltid er oppdatert.

Driftsskjemaet er basert på to NAS-enheter som sikkerhetskopierer hverandre : NAS A og NAS B fungerer som backup-noder for hverandre, toveis. Hver av dem kan ha sine egne virtuelle maskiner, og for de som er merket som HA-beskyttet, opprettes en replika på den andre NAS-en. Ved feil på en av enhetene tar den andre kontrollen og starter de berørte virtuelle maskinene.

Dette muliggjør sømløs bytte av NAS-server . Høy tilgjengelighet (HA)-beskyttelse kan bare aktiveres for spesifikke kritiske virtuelle maskiner uten å påvirke andre NAS-tjenester (f.eks. sikkerhetskopiering, fildeling osv.). Hver NAS kan fortsette å utføre sin opprinnelige funksjon samtidig som den beskytter de virtuelle maskinene som er utpekt for høy tilgjengelighet.

SnapSync-basert sanntidssynkronisering sikrer at failover skjer så å si øyeblikkelig og uten datatap i tilfelle en hendelse . I motsetning til tradisjonelle arkitekturer som er avhengige av et sentralt delt lagringsområde (SAN), eliminerer denne løsningen det ene feilpunktet: hver NAS opprettholder en komplett og konsistent kopi av de virtuelle maskinene den beskytter.

Videre definerer QNAP flere feiltilstander som kan utløse en failover : langvarig CPU-overbelastning (over en viss terskel, for eksempel 80 % over en periode), for høy systemtemperatur, diskfeil selv i RAID-konfigurasjoner, tap av en av de redundante strømforsyningene, blant annet. Systemet evaluerer disse tilstandene, og hvis NAS-en anses som upålitelig, flytter den belastningen til den andre noden.

Systemet tilbyr også muligheten for manuelle migreringer , noe som er svært nyttig når det tekniske teamet ønsker å migrere virtuelle maskiner til en annen NAS på en kontrollert måte for vedlikeholdsoppgaver som å bytte ut disker, oppdatere fastvare, endre avanserte innstillinger osv. Migreringen er svært rask (i størrelsesorden under et sekund), noe som gjør prosessen praktisk talt transparent for brukerne.

Et annet interessant poeng er at det ikke er noen ekstra lisenskostnader : funksjonaliteten for høy tilgjengelighet i Virtualization Station 4 er en del av selve applikasjonen og er inkludert i systemet, uten ekstra betalinger per node eller per VM. Dette gjør det spesielt attraktivt for små og mellomstore bedrifter og miljøer som ønsker høy tilgjengelighet til en rimelig pris.

Krav og begrensninger for høy tilgjengelighet i QNAP

For å kunne distribuere denne løsningen på QNAP, er det viktig å oppfylle visse krav til programvare, maskinvare og nettverk . De er ikke ekstremt komplekse, men det er viktig å være veldig tydelig på dem før man designer miljøet.

Når det gjelder programvare, kreves QuTS hero versjon h5.3 eller høyere og Virtualization Station 4.1 eller nyere. Bare disse versjonene inkluderer SnapSync-basert VM HA-funksjonalitet. Denne funksjonen er ikke tilgjengelig på NAS-enheter med "klassisk" QTS eller tidligere versjoner av Virtualization Station.

På maskinvarenivå trenger ikke de to NAS-enhetene å være nøyaktig samme modell, men de må bruke prosessorer med samme arkitektur og merke (enten begge Intel eller begge AMD) . Dette forenkler kompatibilitet og sikrer at replikerte virtuelle maskiner kan kjøre problemfritt på begge enhetene.

Når det gjelder nettverket, er det viktig at begge NAS-enhetene er på samme nettverkssegment , og at det er en direkte forbindelse mellom dem ved hjelp av en dedikert fysisk nettverkskabel for synkronisering av virtuelle maskiners data. Denne dedikerte lenken fungerer som en "utenfor båndet"-kanal for replikering, og forhindrer forstyrrelser med normal brukertrafikk.

I praksis koker det faktiske maskinvarekravet ned til dette: samme CPU-familie og en direkte kobling mellom NAS-enheter . Alt annet (diskkapasitet, RAM osv.) skaleres basert på antall virtuelle maskiner som skal beskyttes og forventet ytelse. Hvis disse betingelsene er oppfylt, er QNAPs HA-oppsett relativt enkelt og svært robust.

Forskjellen mellom høy tilgjengelighet og enkel replikering/DR i virtuelle maskiner

Løsninger for replikering av virtuelle maskiner som en mekanisme for gjenoppretting etter katastrofer forveksles ofte med ekte høy tilgjengelighet med null nedetid (eller minimal nedetid). Begge er viktige, men de løser forskjellige problemer.

I VMware vSphere-miljøer er det for eksempel vanlig å konfigurere VM-replikering til et katastrofegjenopprettingssted (DR) , slik at den primære serverens diskavbildning kopieres til katastrofegjenopprettingsnoden. Dette beskytter mot totalt tap av det primære stedet, men når det mislykkes, er en manuell gjenoppretting vanligvis nødvendig: slå på de virtuelle maskinene på DR-stedet, konfigurere nettverk på nytt, validere dataintegritet og så videre.

Denne prosessen, selv om den delvis kan automatiseres, innebærer nedetid som kan variere fra minutter til timer, avhengig av miljøets kompleksitet og interne prosedyrer. Det er en utmerket DR-strategi, men den oppfyller ikke det nærmest kontinuerlige tilgjengelighetsmålet som forventes av en streng HA-løsning.

Ekte høy tilgjengelighet krever en automatisk eller nesten automatisk failover-mekanisme med svært lav nedetid og uten behov for komplekse manuelle operasjoner når en komponent svikter. Videre må datasynkroniseringen mellom de aktive nodene og backupnodene være tett nok til å forhindre eller minimere tap av nylig informasjon.

Derfor er det viktig å kombinere klyngeteknologier, replikering i nær sanntid, redundant lagring og proaktiv overvåking på riktig måte når man designer et VM-miljø med høy tilgjengelighet . Bare på denne måten kan brukere fortsette å få tilgang til nettstedet, databasen eller bedriftsapplikasjonen med minimal avbrudd, selv om en hel server eller NAS plutselig slår seg av.

I praksis er den vanligste tilnærmingen å supplere lokal høy tilgjengelighet (for eksempel en klynge innenfor samme datasenter) med en strategi for katastrofegjenoppretting på et annet sted . På denne måten dekkes både hverdagslige feil (disker, servere, strømforsyninger osv.) og mer alvorlige hendelser (branner, langvarige strømbrudd, naturkatastrofer).

Dette brede spekteret av løsninger – RHEL- og Hyper-V-klynger, SAN-frie HA-DAS-arkitekturer, dedikert høy tilgjengelighet på QNAP NAS med Virtualization Station og avansert VM-replikering – demonstrerer at det nå er mulig å designe svært feiltolerante virtualiserte miljøer skreddersydd for ulike bedriftsstørrelser og budsjetter . En grundig forståelse av forskjellene mellom hver tilnærming, deres begrensninger (som maksimalt antall noder eller behovet for delt lagring) og deres tekniske krav er nøkkelen til å velge riktig kombinasjon og holde kritiske tjenester i gang nesten sømløst.