Migratie Hyper-V standalone servers naar failover cluster

[Pinocheckio]

Hoi,

Bij een klant gaan we een nieuwe SAN installeren.
Nu leek het ons evident om van de huidige setup een failover cluster te maken.

Momenteel hebben ze 4 standalone (local storage) Hyper-V servers (1x 2008 R2 en 3x 2012 R2 DC , DC licenties) Op deze 4 servers draaien samen 42 VM's.

De vraag is nu, hoe doen we de migratie van standalone naar cluster? Direct op deze 4 servers dus, we kunnen geen migratie doen naar een lege cluster. (Al lijkt het mij eventueel wel mogelijk om 1 vd 4 vrij te maken)
Ik heb behoorlijk wat ervaring met VMware, maar helemaal geen kaas gegeten van Hyper-V...

Na wat rondzoeken kwam ik uit op volgende guide:
https://araihan.wordpress...o-clustered-hyper-v-host/

Scenario 1: In-place migration of two standalone Windows Servers (Hyper-v role installed) into clustered Windows Servers (Hyper-v role installed).

Steps involved in this scenario. There will be downtime in this scenario.

1. Delete all snapshots from VMs
2. Update Windows Server to latest patches and hotfixes
3. Reboot hosts
4. Install Failover Clustering Windows Feature in both hosts
5. Connect hosts with shared storage infrastructure either iSCSI or fibre channel
6. Present shared storage (5GB for Quorum disk and additional disk for VMs store) to Hyper-v Hosts.
7. Run Failover cluster Wizard, create cluster.
8. From the failover cluster manager, Click Disk, select virtual machine storage and convert the disk to clustered share volume
9. Open Hyper-v Manager from Server Manager, run storage migration and migrate all VM data to single location which is shared storage.
10. Now use Configure Role Wizard from Failover Cluster Manager, Select Virtual Machine from drop down list, Select one or More VMs and migrate those VMs to Failover cluster node.
11. Test Live migration.

Tot stap 8 ben ik mee, maar dan staat daar om disken te converteren naar CSV.
Wat gebeurt hier concreet mee? Is de storage dan nog beschikbaar voor de host?

Waarom moet in stap 10 nog eens migratie van VM's gebeuren, die staan toch op hosts die al deel zijn van de cluster?

Is er buiten het rebooten van de host downtime waarmee we rekening moeten houden?

Zijn er nog andere zaken waaraan we moeten denken?

Ik hoor graag jullie feedback!!

[Dennism]

Een van de eerste waar je aan moet denken bij zo'n verandering is het bekijken van eventuele compliance inzake licenties. Alle nodes zullen in een failover cluster opzet een 2012 R2 DC licentie moeten hebben in deze situatie, tenzij je allemaal waarborgen gaat inbouwen dat het technisch niet mogelijk is dat een 2012 R2 VM op de host terecht komt die de 2008 R2 licentie toegewezen heeft.

Kijk verder ook of alle andere licenties in overeenstemming zijn voor gebruik in een cluster met Failover Migratie mogelijkheden. Heb je bijv. servers draaien met Oracle of MS SQL Server zonder SA kan het zijn dat je andere licentie's moet kopen om compliant te zijn en te blijven na bijv. migraties na uitval van een node of migraties ivm onderhoud. En zo kunnen er meer pakketten zijn die op een cluster met migratie mogelijkheden andere of extra licenties nodig hebben om compliant te blijven.

[Pinocheckio]

Bedankt voor de tip!

Upgrade naar 2012 R2 was sowieso wel het plan, dat was ik vergeten zeggen.

Wat overige licenties betreft, zal ik even moeten bekijken met de klant.
Het is wel zo dat dat helemaal voor hun rekening is, hier trekken wij ons eigenlijk weinig van aan.
Het is enkel het technische verhaal dat we moeten verzorgen.

[Dennism]

Pinocheckio schreef op dinsdag 10 mei 2016 @ 19:30:
Bedankt voor de tip!

Upgrade naar 2012 R2 was sowieso wel het plan, dat was ik vergeten zeggen.

Wat overige licenties betreft, zal ik even moeten bekijken met de klant.
Het is wel zo dat dat helemaal voor hun rekening is, hier trekken wij ons eigenlijk weinig van aan.
Het is enkel het technische verhaal dat we moeten verzorgen.

Dat het voor hun rekening is lijkt me vrij logisch Ik kan me echter voorstellen dat jullie als (mogelijk hun vaste) IT partner er echter ook niet om staan te springen om een omgeving op te leveren die niet compliant is qua licentie's.

Stel dat ze een audit krijgen en ze blijken niet compliant met (hoge) kosten tot gevolg zal dit vrijwel altijd terugkomen als discussie punt waar geen van beide partijen iets aan heeft. Als uitvoerend technisch persoon heb je er vaak niet veel mee van doen. Maar dit soort zaken werd bijv. bij mijn vorig werkgever wel altijd goed uitgeplozen in het (pre) sales tracject bij migraties, juist om gedoe achteraf voor te zijn, en misschien voor jullie een mooie sales kans om eventueel ontbrekende licenties te mogen leveren.

[Linke Loe]

Stap 1: Zorg voor een goede backup van je VM's. Die zou je kunnen maken met Veeam, hier is ook een gratis variant van. Zie https://www.veeam.com/nl/...backup-solution-free.html

Stap 2: Kijk even goed naar je netwerkdesign. Je laat niks los over wat voor SAN er is aangeschaft en hoe je hosts er hardwarematig uit zien. Als dit verder OK is, is er natuurlijk niks aan de hand.

Daarna is het inderdaad een kwestie van de failover cluster role toevoegen op je hosts en een cluster bouwen, zoals je in je start topic al aangaf. Als je zelf al tot stap 8 gekomen bent, ga ik er van uit dat het bouwen van het cluster al gelukt is en dat je LUN's vanaf je storage hebt gepresenteerd aan je hosts en deze als cluster disk hebt toegevoegd aan het cluster. Dit maakt dat de volumes weliswaar voor iedere node zichtbaar zijn, maar als de owner node er uit ligt zal het volume niet automatisch op een andere node online komen. Hiervoor zul je ze moeten converteren naar CSV (Cluster Shared Volume). Dit doet niets met de data die er op staat, maar als het goed is zijn deze volumes nog leeg.

Na het converteren naar CSV, ga je een storage migratie doen, waarbij je de VM's gaat verplaatsen van local storage naar shared storage. De VHD- en configuratie files van de VM's worden hier dus daadwerkelijk op je SAN geplaatst.

Stap 10 is inderdaad niet nodig als je van de huidige hosts een cluster gaat bouwen. Hier gaan ze er van uit dat je een cluster gaat bouwen met nieuwe hosts. Wat wel nog moet gebeuren is het clusteren van de VM's. Hiervoor ga je naar failover cluster manager, klik je met rechts op Roles om een nieuwe role toe te voegen aan het cluster. Als je vervolgens kiest voor Virtual Machine, moet je een lijst met VM's te zien krijgen, die beschikbaar zijn om te clusteren. Pas dan zullen je VM's highly available zijn en kun je met zaken als live migration aan de slag.

[Question Mark]

Pinocheckio schreef op dinsdag 10 mei 2016 @ 15:40:
Waarom moet in stap 10 nog eens migratie van VM's gebeuren, die staan toch op hosts die al deel zijn van de cluster?

Klopt, maar daarmee zijn het nog geen "cluster-resources". Je kunt deze stap vergelijken met VMware, in die zin dat het overeen komt met simpelweg opnemen van de VM in de inventory van het cluster (ipv de local inventory van de host).

[Pinocheckio]

Dennism schreef op dinsdag 10 mei 2016 @ 21:01:
[...]


Dat het voor hun rekening is lijkt me vrij logisch Ik kan me echter voorstellen dat jullie als (mogelijk hun vaste) IT partner er echter ook niet om staan te springen om een omgeving op te leveren die niet compliant is qua licentie's.

Stel dat ze een audit krijgen en ze blijken niet compliant met (hoge) kosten tot gevolg zal dit vrijwel altijd terugkomen als discussie punt waar geen van beide partijen iets aan heeft. Als uitvoerend technisch persoon heb je er vaak niet veel mee van doen. Maar dit soort zaken werd bijv. bij mijn vorig werkgever wel altijd goed uitgeplozen in het (pre) sales tracject bij migraties, juist om gedoe achteraf voor te zijn, en misschien voor jullie een mooie sales kans om eventueel ontbrekende licenties te mogen leveren.

Krijg je niet vooral problemen met licenties als je op applicatie niveau gaat clusteren?
We zijn initieel niet van plan om hier iets aan te wijzigen. De VM's zullen blijven zoals ze nu zijn.

Linke Loe schreef op woensdag 11 mei 2016 @ 10:40:
Stap 1: Zorg voor een goede backup van je VM's. Die zou je kunnen maken met Veeam, hier is ook een gratis variant van. Zie https://www.veeam.com/nl/...backup-solution-free.html

Stap 2: Kijk even goed naar je netwerkdesign. Je laat niks los over wat voor SAN er is aangeschaft en hoe je hosts er hardwarematig uit zien. Als dit verder OK is, is er natuurlijk niks aan de hand.

Momenteel hebben ze Veeam al draaien, dus die backups zouden ok moeten zijn.

SAN is model van Nimble Storage. Wij voorzien ook de Cisco switches voor het iSCSI netwerk. Dit komt in een volledig nieuw netwerk dat nergens gebruikt wordt, dus dat gedeelte hebben we zelf in de hand en daar maak ik mij minder zorgen in. Zal vooral moeten zien hoe de netwerk kant in Hyper-V ineen zit.
Het huidige data netwerk zou behouden blijven, al staan nu alle adapters apart en is er geen teaming. Dit zou nog wel moeten veranderen.

Daarna is het inderdaad een kwestie van de failover cluster role toevoegen op je hosts en een cluster bouwen, zoals je in je start topic al aangaf. Als je zelf al tot stap 8 gekomen bent, ga ik er van uit dat het bouwen van het cluster al gelukt is en dat je LUN's vanaf je storage hebt gepresenteerd aan je hosts en deze als cluster disk hebt toegevoegd aan het cluster. Dit maakt dat de volumes weliswaar voor iedere node zichtbaar zijn, maar als de owner node er uit ligt zal het volume niet automatisch op een andere node online komen. Hiervoor zul je ze moeten converteren naar CSV (Cluster Shared Volume). Dit doet niets met de data die er op staat, maar als het goed is zijn deze volumes nog leeg.

Na het converteren naar CSV, ga je een storage migratie doen, waarbij je de VM's gaat verplaatsen van local storage naar shared storage. De VHD- en configuratie files van de VM's worden hier dus daadwerkelijk op je SAN geplaatst.

Voor alle duidelijkheid: er is momenteel nog niets uitgevoerd, we zitten nog in planningsfase.

In stap 8 was ik verward over welke storage het nu ging. Ik dacht dat er met de lokale storage iets moest gebeuren. Op de SAN zullen de volumes inderdaad leeg zijn.

Kan die storage migration live gebeuren, zonder downtime?

Stap 10 is inderdaad niet nodig als je van de huidige hosts een cluster gaat bouwen. Hier gaan ze er van uit dat je een cluster gaat bouwen met nieuwe hosts. Wat wel nog moet gebeuren is het clusteren van de VM's. Hiervoor ga je naar failover cluster manager, klik je met rechts op Roles om een nieuwe role toe te voegen aan het cluster. Als je vervolgens kiest voor Virtual Machine, moet je een lijst met VM's te zien krijgen, die beschikbaar zijn om te clusteren. Pas dan zullen je VM's highly available zijn en kun je met zaken als live migration aan de slag.

Question Mark schreef op woensdag 11 mei 2016 @ 16:29:
[...]

Klopt, maar daarmee zijn het nog geen "cluster-resources". Je kunt deze stap vergelijken met VMware, in die zin dat het overeen komt met simpelweg opnemen van de VM in de inventory van het cluster (ipv de local inventory van de host).

OK, makes sense! Thanks!

[Dennism]

Pinocheckio schreef op vrijdag 13 mei 2016 @ 19:10:
[...]


Krijg je niet vooral problemen met licenties als je op applicatie niveau gaat clusteren?
We zijn initieel niet van plan om hier iets aan te wijzigen. De VM's zullen blijven zoals ze nu zijn.

Dat hangt volledig af van de gebruikte software, bijv MS SQL 2012 en hoger (uit mijn hoofd) server mag licentie technisch wanneer je geen SA hebt maar 1x per 90 dagen van host gemigreerd worden. Heb je dus nu 4 losse hosts zonder migratie mogelijkheden zal je altijd aan de licentie voldoen, ga je ineens over op een cluster met migratie mogelijkheden dan kan het dus zijn dat wanneer SQL vandaag op host A staat, je na de cluster migratie deze op Host B zet tijdens een patch window en deze na het onderhoud weer op Host A zet je al niet meer compliant bent qua licensing wanneer je geen SA hebt. Hetzelfde is voor zover ik weet van toepassing op Exchange 2013 en hoger en ook enkele andere MS producten.

Stel dat je bijv. een Oracle product draait dan moet je in de regel alle hosts in het cluster volledig afdekken met licenties, heb je dus bijv. geen cluster dan dek je de host af waar Oracle nu op draait, ga je die host later toevoegen aan een cluster met migration mogelijkheden, dan kan het dus goed zijn dat je flink de portemonnee moet trekken.

En zo zijn er nog wel wat software vendors waar je bij zaken als server migratie binnen een virtualisatie cluster licentie aanpassingen moet doen.

Het is iig niet zo klip en klaar dat je zomaar van een niet geclusterde omgeving met losse hosts zonder migratie mogelijkheden kan overstappen op een volledig geclusterde omgeving met migratie mogelijkheden en zonder meer compliant blijft qua licensing.

Als je het goed wil doen, maak dan een volledige inventarisatie van alle server software die de partij draait, met de licenties die ze nu hebben en laat iemand met certificeringen op licentie gebied dit goed doorlichten. De kans is namelijk zeer groot dat er zaken naar voren komen die aangepast moeten worden wil de klant op licentie gebied geen risico's lopen.

[ Voor 4% gewijzigd door Dennism op 13-05-2016 22:49 ]

[Gijs007]

Misschien is het de moeite waard om het boek "Windows Server 2012 Hyper-v Installation and Configuration Guide" te kopen?

Staan tips in over licenties zoals van af hoeveel VM's je beter datacenter kan gebruiken en ook heel veel tips over configuratie en optimalisatie van een Hyper-V omgeving + achtergrond informatie.
Inclusief een apart hoofdstuk over het opzetten van een cluster omgeving en een apart hoofdstuk over het opzetten van een cloud omgeving.

[Linke Loe]

Dennism schreef op vrijdag 13 mei 2016 @ 22:10:
[...]

Stel dat je bijv. een Oracle product draait dan moet je in de regel alle hosts in het cluster volledig afdekken met licenties, heb je dus bijv. geen cluster dan dek je de host af waar Oracle nu op draait, ga je die host later toevoegen aan een cluster met migration mogelijkheden, dan kan het dus goed zijn dat je flink de portemonnee moet trekken.

En dit kun je weer afdichten, door gebruik te maken van host affinity. Daarmee geef je aan op welke host een bepaalde VM uberhaupt actief mag zijn. Als je dan twee hosts uit je cluster licenseert, ben je compliant en kun je je Oracle VM migreren naar een andere host, zonder dat je een bak licenties betaalt.

TS heeft het over 42 VM's op vier nodes. Dan is het in mijn ogen altijd interessant om Windows datacenter licenties aan te schaffen. Hoeveel CPU's zitten er in de nodes?

[Question Mark]

Gijs007 schreef op vrijdag 13 mei 2016 @ 22:18:
Misschien is het de moeite waard om het boek "Windows Server 2012 Hyper-v Installation and Configuration Guide" te kopen?

Daar hoef je geen boek voor te kopen hoor... MS heeft een ontzettend uitgebreide whitepaper online staan over het licenseren van gevirtualiseerde software.

Licensing brief: Licensing Microsoft server products for use in virtual environments

[Dennism]

Linke Loe schreef op zaterdag 14 mei 2016 @ 09:17:
[...]

En dit kun je weer afdichten, door gebruik te maken van host affinity. Daarmee geef je aan op welke host een bepaalde VM uberhaupt actief mag zijn. Als je dan twee hosts uit je cluster licenseert, ben je compliant en kun je je Oracle VM migreren naar een andere host, zonder dat je een bak licenties betaalt.

TS heeft het over 42 VM's op vier nodes. Dan is het in mijn ogen altijd interessant om Windows datacenter licenties aan te schaffen. Hoeveel CPU's zitten er in de nodes?

Data center licenties heeft ie geeft ie aan in de OP. Dus dat is al geregeld. Het kantelpunt ligt officieel uit mijn hoofd op 14VM's per host bij de huidige prijzen in NL (Promo's daargelaten), maar als je ook maar enigzins in de buurt van dat aantal komt zou ik vanwege de flexibiliteit die datacenter licenties geven altijd voor Datacenter kiezen, ook als je (nog) niet de 14 VM's per host haalt. Het aantal CPU's per host maakt trouwens niet uit voor dit kantelpunt. Bij 14 VM's heb je bijv. op een 2 CPU host 7 standaard licenties nodig of 1 Datacenter licentie, bij 4 CPU's in de host is dit 14 standaard licenties of 2 Datacenter licenties.

M.b.t. tot Oracle, is dat inmiddels al een uitgemaakte zaak? In de laatste documentatie die ik heb van Oracle sluiten ze softpartitioning op basis van VMware DRS namelijk nog steeds uit. Ik weet dat er een PDF van VMware is, die zegt dat het wel mag, maar Oracle erkent het document van Vmware bijvoorbeeld niet. Ik denk dat totdat daar een keer een explicite uitspraak over komt het geen uitgemaakte zaak is of zaken als DRS host affinity voldoen aan Oracles Licentie voorwaarden of niet. ie bijv. deze PDF van Oracle: http://www.oracle.com/us/...g/partitioning-070609.pdf

Nu gaat dit in dit topic misschien wel enigzins offtopic qua diepgang, omdat niet duidelijk is of de klant van TS oracle draait.

Soft Partitioning:
Soft partitioning segments the operating system using OS resource managers. The operating
system limits the number of CPUs where an Oracle database is running by creating areas where
CPU resources are allocated to applications within the same operating system. This is a flexible
way of managing data processing resources since the CPU capacity can be changed fairly easily,
as additional resource is needed.

Examples of such partitioning type include: Solaris 9 Resource Containers, AIX Workload
Manager, HP Process Resource Manager, Affinity Management, Oracle VM, and VMware.

Unless explicitly stated elsewhere in this document, soft partitioning (including
features/functionality of any technologies listed as examples above) is not permitted as a
means to determine or limit the number of software licenses required for any given server or
cluster of servers.

[ Voor 4% gewijzigd door Dennism op 14-05-2016 10:50 ]

[Pinocheckio]

De klant gebruikt geen Oracle, dus dat maakt het license gewijs iets gemakkelijker.

Ze gaan dit verder bekijken met hun partner die de licenties verzorgt of hier nog aanpassingen moeten gebeuren.

Wat het technisch stuk betreft: Het is mij nog altijd niet duidelijk wat de impact is van de eigenlijke storage migration tussen lokaal en SAN (stap 9). Dit kan zonder downtime of niet? Moet de VM helemaal afstaan?

[Dennism]

Pinocheckio schreef op vrijdag 20 mei 2016 @ 13:57:
De klant gebruikt geen Oracle, dus dat maakt het license gewijs iets gemakkelijker.

Ze gaan dit verder bekijken met hun partner die de licenties verzorgt of hier nog aanpassingen moeten gebeuren.

Wat het technisch stuk betreft: Het is mij nog altijd niet duidelijk wat de impact is van de eigenlijke storage migration tussen lokaal en SAN (stap 9). Dit kan zonder downtime of niet? Moet de VM helemaal afstaan?

Storage migration moet live kunnen, iig van shared naar shared, dit heb ik al meerdere malen gedaan al was dit al wel op een bestaand cluster. Ik zie zo geen beperkingen waarbij dit van local naar shared niet zou kunnen.

Daar het hier een nieuw cluster betreft zou ik dit wel eerst testen in een test opstelling, of wanneer dit niet mogelijk is een nieuwe VM in de lucht schieten en het daar mee testen.

[A_De2]

Even een subtiel schopje in dit topic.

Gaat er gebruik gemaakt worden van SCVMM? Bij kleine omgevingen kun je ook goed werken met de failover clustermanager en hyper-v manager maar als de software al voorhanden is, biedt deze een aantal voordelen voor de migratie en daarna het beheer:
- Bare metal deployment van nieuwe of bestaande hosts. Zeker als je niet voor een big-bang migratie gaat en een van je 4 hosts leeg kunt spelen, kun je van de eerste host je baseline maken en inrichten in je 1-node failover cluster. Daarna migreer je de VM's vanaf je stand alone 2012 hosts via "share nothing live migration" naar je nieuwe cluster. Die nu lege hosts kun je vanuit SCVMM dan automagisch opnemen in je nieuwe cluster met het juiste OS en configuratie.

Ik geloof niet dat dit werkt voor je 2008 host maar daar kun je de VM's down brengen en de VHD's kopiëren naar je CSV's en opbrengen. Wel downtime en manual labor.

Iets wat ik nog mis in het verhaal (of ben er overheen gelezen) is je netwerk layout. Denk van te voren goed na over hoe je je heartbeat, live-migration en datanetwerk gaat opzetten. (QoS, Netwerk teams, Vlans etc) Storage in ieder geval scheiden van de rest. Je wilt voorkomen dat een livemigration actie je storage traffic wegduwt) Imho is een 1x10Gb nic beter dan 10x1Gb nic in verband met doorvoersnelheid met name bij Live Migration tussen hosts en naar je storage. Wel geldt 1=geen, dus 2x10Gb nic. Wordt wel gelijk een stuk duurder. Keuzes keuzes

Voordeel van deze aanpak is dat je kunt spelen met je nieuwe configuratie voordat je deze daadwerkelijk in productie zet (je geeft aan met name VMware kennis te hebben). Dan begin je met een test VM om ook daar gevoel bij te krijgen. Daarna start je de bulk migratie en is het wachten tot de klant met gebak en champagne je komt bedanken...

Succes!

[Pinocheckio]

A_De2 schreef op donderdag 02 juni 2016 @ 11:03:
Even een subtiel schopje in dit topic.

Gaat er gebruik gemaakt worden van SCVMM? Bij kleine omgevingen kun je ook goed werken met de failover clustermanager en hyper-v manager maar als de software al voorhanden is, biedt deze een aantal voordelen voor de migratie en daarna het beheer:
- Bare metal deployment van nieuwe of bestaande hosts. Zeker als je niet voor een big-bang migratie gaat en een van je 4 hosts leeg kunt spelen, kun je van de eerste host je baseline maken en inrichten in je 1-node failover cluster. Daarna migreer je de VM's vanaf je stand alone 2012 hosts via "share nothing live migration" naar je nieuwe cluster. Die nu lege hosts kun je vanuit SCVMM dan automagisch opnemen in je nieuwe cluster met het juiste OS en configuratie.

Ik geloof niet dat dit werkt voor je 2008 host maar daar kun je de VM's down brengen en de VHD's kopiëren naar je CSV's en opbrengen. Wel downtime en manual labor.

Iets wat ik nog mis in het verhaal (of ben er overheen gelezen) is je netwerk layout. Denk van te voren goed na over hoe je je heartbeat, live-migration en datanetwerk gaat opzetten. (QoS, Netwerk teams, Vlans etc) Storage in ieder geval scheiden van de rest. Je wilt voorkomen dat een livemigration actie je storage traffic wegduwt) Imho is een 1x10Gb nic beter dan 10x1Gb nic in verband met doorvoersnelheid met name bij Live Migration tussen hosts en naar je storage. Wel geldt 1=geen, dus 2x10Gb nic. Wordt wel gelijk een stuk duurder. Keuzes keuzes

Voordeel van deze aanpak is dat je kunt spelen met je nieuwe configuratie voordat je deze daadwerkelijk in productie zet (je geeft aan met name VMware kennis te hebben). Dan begin je met een test VM om ook daar gevoel bij te krijgen. Daarna start je de bulk migratie en is het wachten tot de klant met gebak en champagne je komt bedanken...

Succes!

Ik hoop inderdaad dat dat het resultaat zal zijn!

Ik vermoed dat er inderdaad SCVMM gebruikt wordt. Door omstandigheden is het project even on hold gezet, maar ik vraag dit nog na.

De 2008R2 host staat sowieso gepland om geupgrade te worden naar 2012R2. Als die server op dat moment toch vrijgemaakt moet worden, zou die als eerste node in de cluster kunnen dienen.

Voor de 'share nothing live migration' moeten de standalone hosts en de 1-node-cluster enkel elkaar zien via het bestaande datanetwerk? Pas als de andere hosts leeg zijn, moeten we daar failover cluster role en netwerk voor storage aanmaken?

Wat het netwerk betreft, er zijn 8x1Gb nics op de servers. Momenteel worden die allemaal als datanetwerk gebruikt en is er zelfs geen teaming voorzien. VM's krijgen nu een dedicated nic toegewezen, verre van ideaal natuurlijk. 4 zouden we behouden voor het bestaande datanetwerk, 4 voor storage (opgesplitst in 2 keer 2 links naar 2 iSCSI switchen, op een volledig apart netwerk, voor failover/multipathing).
10Gb is jammer genoeg nog geen optie op dit moment.

Voor heartbeat en live-migration is dedicated nic aangewezen of kan dit mee op het datanetwerk?

[Jazzy]

Nog even los van wat je nu had en of dat goed is, networking is sinds Server 2012 compleet anders. Lees je even in op Hyper-V converged networking.

[A_De2]

Pinocheckio schreef op vrijdag 03 juni 2016 @ 12:28:
[...]
Voor de 'share nothing live migration' moeten de standalone hosts en de 1-node-cluster enkel elkaar zien via het bestaande datanetwerk? Pas als de andere hosts leeg zijn, moeten we daar failover cluster role en netwerk voor storage aanmaken?

Wat het netwerk betreft, er zijn 8x1Gb nics op de servers. Momenteel worden die allemaal als datanetwerk gebruikt en is er zelfs geen teaming voorzien. VM's krijgen nu een dedicated nic toegewezen, verre van ideaal natuurlijk. 4 zouden we behouden voor het bestaande datanetwerk, 4 voor storage (opgesplitst in 2 keer 2 links naar 2 iSCSI switchen, op een volledig apart netwerk, voor failover/multipathing).
10Gb is jammer genoeg nog geen optie op dit moment.

Voor heartbeat en live-migration is dedicated nic aangewezen of kan dit mee op het datanetwerk?

Share nothing live migration gaat volledig over het datanetwerk. Als je de andere host kunt zien (ping) gaat het goed. Wel moet je dezelfde processorarchtitectuur hebben (Niet getest maar AMD->Intel of andersom zou dus niet werken)
En ja, de hosts die je leeg speelt, voorzie je van het juiste OS, failovercluster & hyper-v role en correcte netwerk configuratie.

Simpelheidshalve zou ik in jouw geval de 8x1Gb nics opdelen in 3 teams:
- 2x1Gb iScsi1
- 2x1Gb iScsi2
- 4x1Gb Network

Vervolgens maak je een V-Switch1 o.i.d. aan en 3x VMNetworkAdapter die je koppelt aan de V-Switch1:
- Management
- LiveMigration
- HeartBeat

Aan die VMNetworkAdapters kun je ook zaken als VlanID's en QoS knopen. Voor het Netwerkgedeelte heb ik ook een simpel&mooi PowerShell script om e.e.a. in 1x goed neer te zetten. Als je die wilt, DM me even want ik wil hem niet met de hele wereld delen

Nadeel is wel dat als je 4x1Gb teamed je per VM max 1Gbps kunt verzenden, ook al laat je trunk 4Gbps zien. Dus met 4 VM's kun je de trunk wel volblazen. In een kleine omgeving zie ik echt maar weinig verkeer dat echt de volle trunk nodig zou hebben.

[Jazzy]

A_De2 schreef op vrijdag 03 juni 2016 @ 15:07:
[...]
Simpelheidshalve zou ik in jouw geval de 8x1Gb nics opdelen in 3 teams:

In dat geval ook aan jou het advies om je in te lezen over converged networking.

[A_De2]

Jazzy schreef op vrijdag 03 juni 2016 @ 16:30:
[...]
In dat geval ook aan jou het advies om je in te lezen over converged networking.

En ik raad jou aan om je auto te wassen, omdat ananas...
Je zal het ongetwijfeld goed bedoelen; maar zomaar roepen dat mensen zich even in gaan lezen zonder verder aan te geven waarom, daar kan ik weinig mee. Komt behoorlijk ongefundeerd over, nofi

Zoals je kunt lezen zie je dat Team3 met 4 nics wordt gebruikt voor converged networking:
-management
-livemigration
-heartbeat

Alleen iScsi verkeer wordt fysiek gescheiden d.m.v. totaal 4 nics en 2 teams en aparte switches voor het iScsi netwerk.

[ Voor 3% gewijzigd door A_De2 op 03-06-2016 17:32 ]