Dela via

Hyper-V:n käyttöönotossa huomioitavat asiat ja parhaat käytännöt. Hyper-V ja korkea käytettävyys

  • Artikel

Microsoft Hyper-V:n käyttöönotossa huomioitavat asiat ja parhaat käytännöt.

Osa 2: Hyper-V ja korkea käytettävyys

Palvelinten virtualisointi nosti mukavasti palvelinraudan käyttöastetta antamalla mahdollisuuden ajaa useita virtuaalisia palvelimia yhdellä fyysisellä palvelinraudalla. Samalla se tarkoitti myös sitä, että fyysisen palvelimen vikaannuttua kaikki sillä olevat virtuaalikoneet menivät alas, ellei käytössä ollut jotain ratkaisua joka siirtää tai käynnistää työkuormat toisella fyysisellä palvelimella. Ensimmäisessä Technet TV lähetyksessä ja blogikirjoituksessa käsittelimme Hyper-V:n käyttöönottoon liittyviä asioita verkon vaatimusten kautta. Seuraava vaihe on suunnitella korkea käytettävyys kyseisen ympäristön vaatimusten mukaisesti. Pienessä testiympäristössä voidaan yleensä toimia yksittäisillä alustakoneilla, jolloin korkean käytettävyyden suunnitteluun ei vaadita paljoa panostusta. Mikäli alustaa ollaan rakentamassa tuotannolliseen käyttöön, tulee heti miettiä isäntäkoneiden kahdentaminen.

Hyper-V hyödyntää alustassa olevia Windows palvelimen palveluita tuottaakseen korkean käytettävyyden isäntäkoneille. Käytännössä siis Hyper-V on rooli Windows Clustering palvelussa ja se huolehtii Hyper-V:n työkuormien eli virtuaalikoneiden korkeasta käytettävyydestä klusterin sisällä. Aiemmin Windows Clustering on toiminut niin, että yksittäinen palvelin on toiminut aktiivisena jäsenenä ja muut passiivisena odottamassa aktiivijäsenen vikaantumistilannetta. Vikatilanteessa passiivijäsen on siirtynyt aktiiviseen rooliin. Päällimmäisin syy miksi Windows Clustering on aiemmin toteutettu näin, tulee alla olevan tiedostojärjestelmän vaatimuksista. NTFS tiedostojärjestelmä ei salli että NTFS levyalue liitetään paikallisesti useampaan kuin yhteen käyttöjärjestelmäympäristöön. NTFS levy on kyllä voitu kyllä jakaa palvelimelta verkkoon SMB rajapinnan kautta, jolloin sille kirjoittaminen onnistuu useasta lähteestä. Windows Clustering palvelu ei ole kuitenkaan hyväksynyt SMB:n kautta näkyvää levytilaa resurssikseen. Käytännössä aiemmin Windows Server 2008 ja sitä vanhemmissa toteutuksissa Windows Clustering palvelun isäntäkoneet eli klusterin noodit ovat joutuneet asettamaan levyalueen offline tilaan lähdenoodilta ja nostamaan se online tilaan kohdenoodilta siirrettäessä työkuormaa klusterin sisällä. Tämä oli myös päällimmäisin syy miksi virtuaalikonetta ei ollut mahdollista siirtää katkottomasti noodilta toiselle ensimmäisessä Windows Server 2008 Hyper-V versiossa. Noodien tuli siis tehdä näitä levyoperaatioita, jotka vaativat kuitenkin pienen katkon siirron aikana.

Kohta on kuitenkin jo kulunut 6 vuotta ensimmäisen Hyper-V version julkistuksesta ja tämä aika on tuonut paljon uutta myös Windows Clustering palveluun. Yksi suurimmista parannuksista joka mahdollisti myös Live Migration toiminnallisuuden, eli katkottoman virtuaalikoneiden siirron klusterin noodien välillä, oli CSVFS eli klusterin käyttämä jaettu tiedostojärjestelmä. CSVFS mahdollistaa useamman klusterin noodin kirjoittamisen samalle levyalueelle yhtä aikaa. Tämä muutti myös klusterin sisäisen verkkoliikenteen laajentumisen pelkästä noodien terveydentilan valvonnasta levyalueen metatietojen synkronointiin ja tietyissä tilanteissa myös levy IO liikenteeseen. Toinen suuri parannus oli SMB 3 protokolla ja sen tuomat uudistukset. Windows Clustering palvelu antaa nyt mahdollisuuden klusteroitujen resurssien ajamisen suoraan SMB 3 rajapinnan kautta. Käytännössä Windows Server 2012 tiedostopalvelin tai kolmannen osapuolen SMB 3 rajapinnan omaava levyjärjestelmä (Esim. NetApp DataOntap 8.2 ja uudemmat) voi tuottaa levypalvelut Hyper-V klusterin käyttöön ilman, että sillä on omaa paikallista levyä.

Tallennusratkaisut klusterissa

Klusterissa käytettävä tallennusratkaisu on yksi keskeisimpiä korkean käytettävyyden komponentteja sekä mahdollisesti myös suurin yksittäinen kustannus virtualisointikokonaisuudessa. Tallennusratkaisuihin Windows Server 2012 toi mukanaan toiminnon nimeltä Storage Spaces. Yksinkertaistettuna se mahdollistaa tallennusratkaisun toteuttamisen niin, että käyttöjärjestelmä voi rakentaa siihen suoraan liitetyistä fyysisistä levyistä vikasietoisen levyalueen. Levyalue voidaan myös klusteroida Windows Clustering palvelun avulla. Klusteroituun Storage Spaces tallennusratkaisuun tulee kuitenkin hankkia siihen tarkoitettu levyhylly (Esim. DataOn tai Fujitsu), joka voidaan kytkeä useampaan fyysiseen palvelimeen. Windows Server 2012 R2 toi Storage Spaces palveluun myös Storage Tiering toiminnon jonka avulla Storage Spaces levypalvelussa voidaan käyttää eri nopeusluokan levyjä, kuten SAS tai SSD. Storage Tiering palvelu mittaa käytetyimmät tiedostojen palaset 1mb blokeissa ja siirtää ne SSD levypinnalle, sekä vähemmän käytetyt blokit se voi vastaavasti siirtää hitaammalle levypinnalle. Näiden ansiosta Windows Server voi siis nykyisin toimia vikasietoisena levypalveluna, jota voi laajentaa lisäämällä siihen levyhyllyjä, fyysisiä palvelimia tai erityyppisiä levyjä.

Klusterin Quorum äänestys

Käytettävän tallennusratkaisun lisäksi on hyvä käydä läpi myös klusterin tapaa varmistaa palveluiden käytettävyys eri noodien vikaantuessa tai verkkoyhteyden katketessa. Klusterin tulee voida tunnistaa kuinka jäljelle jääneiden noodien tulee toimia, jos osa noodeista häviää tavoittamattomaan tilaan. Riskinä tässä siis voi olla esimerkiksi se, että mikäli usean noodin klusterista puolet jää verkkokatkoksen toiselle puolelle ja puolet toiselle puolelle, vain toinen puoli voi jatkaa, jotta klusteroitujen palveluiden eheys säilyy. Windows Clustering tarvitsee käynnistyäkseen äänienemmistön klusterin noodien sisäisessä ”quorum äänestyksessä”. Oletuksena jokaisella klusterin noodilla on yksi quorum ääni. Mikäli klusterissa on parillinen määrä noodeja, käytetään lisäksi Quorum Wittness levyä tai levyjakoa jolla myös on käytettävissä yksi ääni. Aiemmin quorum määrittely on ollut ylläpitäjän vastuulla, mutta nyt Windows Server 2012 R2 muuttaa tämän helpommaksi hallitsemalla itse dynaamisesti Quorum äänien määritystä. Käytännössä siis Windows Server 2012 R2 klusterille tulee määritellä aina Quorum levy tai levyjako. Klusteri palvelu määrittää onko quorum levyllä äänestysoikeutta, perustuen siihen onko klusterissa pariton vai parillinen määrä quorum ääniä. Mikäli siis osa klusterin jäsenistä joutuu eristykseen toisista (split cluster tai split brain), klusterin palvelut pidetään käynnissä vain niillä noodeilla joilla on enemmistö quorum äänistä, lopuilta noodeilta pysäytetään klusteroidut palvelut. Edellä on kuvattuna siis yleisesti klusterin quorum toiminnallisuus ja poikkeustapauksissa Quorum äänien määräytymistä voidaan määritellä myös manuaalisesti. Mikäli on tarvetta käydä läpi monimutkaisempaa Quorum toteutusta usean toimipisteen ratkaisuun, suosittelen käymään läpi seuraavan luennon TechEd 2013 tapahtumasta:

https://channel9.msdn.com/Events/TechEd/Europe/2013/MDC-B403#fbid=XcO2_HDrFIk

 

Esimerkkejä Hyper-V klusterista

Seuraavassa katsomme paria esimerkkiä toteuttaa Hyper-V klusterin tallennusratkaisu.

1. Hyper-V klusteri perinteisessä levyjärjestelmässä.

    1. Kaksi tai useampi Hyper-V palvelin liitettynä levyjärjestelmään iSCSI, Fibre Channel, SAS tai FCoE liittymän kautta.
    2. Yksi vähintään 512mb kokoinen levyalue klusterin Quorum levyksi ja yksi tai useampi levyalue virtuaalikoneiden virtuaalilevyille, konfiguraatiotiedostoille ja pikakopioille.
      1. Virtuaalikoneiden levyalue määritellään CSV levyksi
      2. armistetaan, että klusteri palvelu on varannut p512mb kokoisen levyn Disk Wittness toiminnolle.
    3. Perinteinen ja käytetyin malli toteuttaa klusteri ja sen tallennusratkaisu.
    4. Levypalvelu / levyjärjestelmä vastaa fyysisten levyjen vikasietoisuudesta.
    5. Kaikkien noodien tulee saada suora blokkitason pääsy jaetuille levyille.
    6. Suositellaan vähintään kolmea verkkoa, yksi klusterin heartbeat toimintaan, levyalueen metatietojen synkronointiin sekä mahdollisesti levy IO uudelleenohjaukseen, yksi verkko isäntäkoneen hallintaan sekä yksi dedikoitu virtuaalikoneille. Lisäksi käytettäessä jotain Ethernet verkkoa hyödyntävää tallennusratkaisua, tulee sille olla oma verkkoliittymä tai liittymät.

 

2. Hyper-V klusteri sekä SMB 3 tallennusratkaisu.

    1. Kaksi tai useampi Hyper-V palvelinta ajaa suoraan SMB 3 rajapinnan kautta klusterissa olevia virtuaalikoneita.
      1. Hyper-V isäntäkoneista luodaan oma klusteri. Tässä vaihtoehdossa Hyper-V klusterin noodeilla ei ole käytössä jaettua blokkitason levyä, jolloin se ei luonnin aikana pysty ottamaan käyttöön Disk Wittness toimintoa. Klusterin luonnin jälkeen sille tulee manuaalisesti määritellä File Share Wittness, jotta klusterin dynaaminen Wittness toiminnallisuus saadaan käyttöön
    2. Mikäli tallennusratkaisuna käytetään levyjärjestelmää joka kykenee tarjoamaan SMB 3 rajapinnan kuten esimerkiksi NetApp, levyjärjestelmä vastaa levyjen korkeasta käytettävyydestä ja suorituskyvystä.
    3. Mikäli tallennusratkaisuna käytetään Windows Serverin omaa Storage Spaces palvelua, tarvitaan siihen sertifioitu laitteisto (palvelimet ja levylaajennusyksiköt). Levymääritykset tulee toteuttaa kuten kohdassa 1, eli erillinen vähintään 512mb kokoinen levyalue klusterin Quorum levyksi, sekä tarvittava määrä datalevyjä, joita tarjotaan SMB 3 rajapinnan kautta Hyper-V klusterille.
      1. Windows Clustering palvelusta jaettu levyalue määritellään CSV levyksi ja varmistetaan, että Klusteri palvelu on varannut pienen osion Disk Wittness toiminnolle.
      2. Mikäli Storage Spaces klusterin levyhyllyssä on käytettävissä erityyppisiä levyjä (SAS, SSD tms.) voidaan kytkeä päälle Storage Tiering, joka optimoi käytetyimmän datan nopeimmalle levypinnalle.
      3. Kaikkien Storage Spaces klusterin noodien tulee saada blokkitason suora pääsy levyille. Kaikki Hyper-V klusterin noodit käyttävät Storage Spaces klusterin tarjoamaa SMB 3 rajapintaa.
      4. Storage Spaces klusterille suositellaan vähintään kolmea verkkoa. Yksi klusterin heartbeat toimintaan, levyalueen metatietojen synkronointiin sekä mahdollisesti levy IO uudelleenohjaukseen, toinen verkko isäntäkoneen hallintaan sekä kolmas SMB 3 liikenteelle.
      5. Tässä vaihtoehdossa on siis kaksi erillistä Windows klusteria, yksi tallennusratkaisuun ja toinen virtuaalikoneiden ajoalustaksi.

Työkuormien sijoitus klusterin sisällä

Klusteroitaessa virtuaalikoneita tulee myös miettiä niiden hajautusta klusterin eri noodeille. Työkuorma eri virtuaalikoneiden sisällä voi vaihdella paljonkin ja tätä kautta aiheuttaa tilanteen jossa yksi isäntäkone on suurella rasituksella ja toinen taas saattaa olla erittäin kevyellä kuormalla. Kuormaa on mahdollista tasata automaattisesti, tähän on olemassa ratkaisu Microsoftin System Center Virtual Machine Managerissa nimeltään Dynamic Optimization tai DO. DO:n avulla voidaan antaa sääntöjä sille, kuinka ”agressiivisesti” kuormaa tasataan klusterissa. Lisäksi noodeille voidaan antaa raja-arvoja, joiden ylittyessä yritetään kuormaa tasata pienemmällä kuormalla oleville noodeille.

Toinen näkökulma virtuaalikoneiden sijoitukselle voi olla ajettava työkuorma. Käytännössä on tilanteita, jolloin tietyt virtuaalikoneet tulee olla aina samalla fyysisellä palvelimella, tai vastaavasti ne eivät saa missään tapauksessa olla samalla fyysisellä palvelimella. Tämän tyyppisiä sijoitussääntöjä voidaan toteuttaa klusterin tasolla käyttäen Failover Cluster Manager konsolia tai System Center Virtual Machine Managerin avulla keskitetysti useille klustereille.

Korkea käytettävyys virtuaalikoneiden sisällä

Isäntäkoneiden klusteroinnilla saadaan korkeaa käytettävyyttä siten, että Hyper-V klusterin noodin vikaantuessa siirretään sillä ajettavat virtuaalikoneet toiselle klusterin noodille. Tämä siirto on täysin riippumaton siitä, mitä virtuaalikoneen sisällä ajetaan. Virtuaalikoneissa tulee myös huolehtia siitä, että ajettava työkuorma on käytettävissä ja varmistettu kyseisen työkuorman vaatimusten mukaisesti. Samaa Windows Clustering palvelua voidaan käyttää myös virtuaalikoneiden sisällä tuomaan korkeaa käytettävyyttä ajettavalle työkuormalle. Esimerkkinä voi olla tiedostopalvelu, joka voisi sijaita kahdesta virtuaalikoneesta koostuvassa klusterissa. Virtuaalikoneisiin rakennettavassa klusterissa tallennusratkaisuna voi olla perinteisistä teknologioista iSCSI tai Fiber Channel, sekä uutena ratkaisuna kaksi virtuaalikonetta voivat jakaa yhteisen VHDX virtuaalilevyn.

Jaetun VHDX virtuaalilevyn avulla on helppo toteuttaa esimerkiksi korkeasti käytettävä tiedostopalvelu tuotannolliseen käyttöön. Sen avulla on helppo myös testata uutta klusteroitua Windows Storage Spaces tallennusratkaisua. Jaetut VHDX levyt tällaisessa klusterissa voidaan merkitä SSD tai SATA levyiksi, jolloin Storage Spaces testiklusteriin voidaan kytkeä päälle Storage Tiering. Testattaessa Storage Tiering toiminnallisuutta edellä kuvatulla tavalla, tulee eri virtuaalilevyt siirtää eri nopeuksisille levypinnoille, jotta Storage Tiering toiminnon optimointi toimii suunnitellulla tavalla. Samalla ratkaisulla on helppo testata ja tutustua tarkemmin myös muihin Windows Clusteringin uusiin toiminnallisuuksiin, kuten esimerkiksi dynaamiseen Quorum äänestykseen. Edellä kuvattu virtuaalinen Storage Spaces ratkaisu ei ole tuettu tuotannollisessa käytössä.

Virtuaalikoneiden asynkroninen replikointi

Klusterointi isäntäkonetasolla tuo korkeaa käytettävyyttä fyysisen palvelimen tasolla ja toimipistetasolla. Kun halutaan varautua keskitetyn tallennusratkaisun vikaantumiseen tai jostain muusta syystä kuljettaa virtuaalikoneet paikkaan, joka ei ole millään tavalla riippuvainen yhteisistä komponenteista, voidaan hyödyntää Hyper-V:n tarjoamaa replikointipalvelua.

Hyper-V Replican avulla on mahdollista asynkronisesti replikoida käynnissä olevat virtuaalikoneet toiseen (Toimipiste A – Toimipiste B), sekä kolmanteen Hyper-V isäntäkoneeseen (Toimipiste A – Toimipiste B – Toimipiste C). Replikoinnin kohteena oleva Hyper-V isäntäkone voi olla yksittäinen palvelin, tai toinen klusteri fyysisesti toisessa tilassa. Replikoinnissa käynnistyessä tehdään täydellinen synkronointi, jolloin koko virtuaalikone kopioidaan replikointikohteeseen. Haastavissa verkkoympäristöissä ensimmäinen kopio voidaan toimittaa myös ulkoisella medialla. Ensimmäisen kopion jälkeen muuttuneita tietoja synkronoidaan niin, että toimipisteiden A ja B välillä replikointitiheydeksi voidaan valita 30 sekuntia, 5 minuuttia tai 15 minuuttia, ja toimipisteiden B ja C välillä 5 minuuttia tai 15 minuuttia. Tietoliikenteen kannalta replikointi vaatii ainoastaan TCP:443 liikenteen avaamisen eri palvelinten välillä.

Replikoidulle virtuaalikoneelle on mahdollista tehdä suunniteltu tai suunnittelematon palautus. Suunnitellussa palautuksessa (Planned Failover) lähteenä oleva virtuaalikone sammutetaan ja sille tehdään manuaalisesti Planned Failover toiminto, jolloin seuraava replika saa aktiivisen roolin ja aiemmin aktiivisena ollut replika siirtyy passiiviseksi. Suunnittelemattomassa tilanteessa, esimerkiksi lähdekoneen hävitessä, voidaan virtuaalikone käynnistää toiselta fyysiseltä palvelimelta käyttäen haluttua replikoitua ajankohtaa.

Hyper-V:n korkean käytettävyyden ratkaisuja voidaan laajentaa julkiseen pilveen, integroimalla edellä kuvattuja palveluita myös Windows Azuren palveluihin. Näitä mahdollisuuksia käyn tarkemmin läpi TechNet TV:ssä ja siihen liittyvässä blogikirjoituksessa 11.12., jolloin käsitellään hybridipilviratkaisuja.

Technet TV tallenne, Hyper-V ja korkea käytettävyys, löytyy seuraavasta osoitteesta:

https://youtu.be/O-sHErexZUo

Esitykset löytyy PDF ja PPTX muodoissa seuraavasta osoitteesta:

https://sdrv.ms/1iostG4

Terveisin,

Antti Alila

Tuotepäällikkö

Server & Cloud, Microsoft Oy

Comments

  • Anonymous
    October 27, 2013
    Kiitos hyvästä esityksestä. Tuleeko Anssi Putkosen esitys jakoon jonnekkin?

  • Anonymous
    October 28, 2013
    Kiitos, Linkki esityksiin löytyy nyt tuon blogikirjoituksen lopusta, Antti

  • Anonymous
    October 28, 2013
    Kiitos paljon!