Hyper-V lab best practice

[Yodocus]

Ik ga mijn Windows 2012R2 lab omgeving upgraden naar 2016 en wil meteen van de gelegenheid gebruik maken om een nieuw ontwerp toe te passen.

Het huidige Hyper-V cluster bestaat uit twee hosts, 1 SAN voor shared storage en een domain controller buiten het cluster.
Nu wil ik de nieuwe opzet flink vereenvoudigen door een minimale setup toe te passen.

Mijn streven is om het slechts bij twee fysieke servers te houden maar wel beschikking te hebben over live migration en failover. Met shared-nothing migration moet dat kunnen

Ik ben het volgende van plan:
Op beide servers:
- Windows Server 2016 Standard
- Hyper-V rol
- Scale Out file server rol
- één gezamenlijke SMB share m.b.v. Storage Spaces voor de VM's

De DC wordt virtueel gehost, een cluster heeft sinds 2012 geen DC nodig om te starten.

Graag hoor ik of dit een handige setup is of dat er bezwaren zijn of hoe het handiger kan. Let wel, dit is geen productie omgeving. Het is dus niet erg om een best practice te missen.

[MAX3400]

Waarom SMB? En welke versie? Waarom geen iSCSI? Beiden hebben voor- en nadelen zoals beschreven in https://technet.microsoft...ry/dn550728(v=ws.11).aspx maar ik zie geen directe aanleiding in de startpost om SMB als shared storage te gebruiken?

[CH4OS]

Waarom de keuze voor SMB? Lijkt me dat inmiddels toch wel handigere dingen zijn dan SMB?

EDIT:
Ben dus niet de enige, hahaha

[ Voor 19% gewijzigd door CH4OS op 04-07-2017 11:07 ]

[Yodocus]

SMB omdat het simpel is. Hyper-V i.c.m. SMB3 wordt hartstikke ondersteund in SRV2016. Anders zou ik een iSCSI software target op beide machines moeten installeren.

[CH4OS]

SMB is echter wel oud en gezien recente berichten, zou ik het eigenlijk uit mijn hoofd laten om SMB te gebruiken, aangezien het duidelijk zijn beste tijd gehad heeft.

[MAX3400]

Yodocus schreef op dinsdag 4 juli 2017 @ 11:12:
SMB omdat het simpel is. Hyper-V i.c.m. SMB3 wordt hartstikke ondersteund in SRV2016. Anders zou ik een iSCSI software target op beide machines moeten installeren.

Dus omdat het is meegeleverd in Roles & Features, klik je het maar niet aan? Wel vreemd omdat iSCSI onder dezelfde Services valt als je SOFS en die klik je wel aan?

Ik snap nog steeds de overweging niet?

[CH4OS]

Het gaat niet zo zeer om installatie, maar configuratie. Wat dat betreft is een SMB-share immers sneller opgezet dan een iSCSI target. Niet dat ik SMB nog wil gebruiken, als ik iets nieuws opzet.

[ Voor 6% gewijzigd door CH4OS op 04-07-2017 11:25 ]

[Yodocus]

De belangrijkste reden is toch wel dat iSCSI niet wordt ondersteund op een Scale Out file server en SMB wel.

[ Voor 5% gewijzigd door Yodocus op 04-07-2017 11:26 ]

[MAX3400]

Yodocus schreef op dinsdag 4 juli 2017 @ 11:26:
De belangrijkste reden is toch wel dat iSCSI niet wordt ondersteund op een Scale Out file server en SMB wel.

?

SOFS kan je wel tegen SMB laten praten (maar ook tegen iSCSI) maar ik vroeg me meer af waarom je je SMB share m.b.v. Storage Spaces voor de VM's niet op iSCSI wil optuigen.

Maar ik denk dat we langs elkaar heen praten?

It is not necessary to deploy new storage in your organization to support Scale-Out File Server. You can use existing storage that may already be deployed within your organization. Some supported storage configurations that can be used as the storage subsystem for Scale-Out File Server include:

Storage Spaces Storage Spaces was introduced in Windows Server 2012.

For more information, see Storage Spaces Overview.

iSCSI Storage Area Network

For more information about iSCSI, see iSCSI Target Server Overview.

Fibre Channel Storage Area Network

For more information about using a Fibre Channel SAN, see Failover Clustering Hardware Requirements and Storage Options.

Clustered RAID controller

For more information, see Enable Support for Clustered Windows Servers using clustered RAID controllers.

En dat geldt als sinds Server 2012

[ Voor 50% gewijzigd door MAX3400 op 04-07-2017 11:30 ]

[Yodocus]

Eigenlijk alleen omdat ik er het voordeel niet van inzie. Let op, het streven is om de hele boel op twee bakken te laten draaien dus is hou het graag zo simpel mogelijk. Maar ik laat me graag overtuigen.

[ Voor 38% gewijzigd door Yodocus op 04-07-2017 11:33 ]

[Deveon]

Verdiep je anders is in Hyper-converged. Alles lokaal, met de voordelen van een cluster.

[Yodocus]

Bedankt voor de tip! Komt sterk overeen met wat ik zoek.

[Jazzy]

CH40S schreef op dinsdag 4 juli 2017 @ 11:15:
SMB is echter wel oud en gezien recente berichten, zou ik het eigenlijk uit mijn hoofd laten om SMB te gebruiken, aangezien het duidelijk zijn beste tijd gehad heeft.

Dat is echt onzin, ik denk dat je in de war bent met SMBv1. Microsoft heeft enorm geïnvesteerd in SMBv3 en zou ik voor Hyper-V zeker gebruiken, tenzij je een specifieke reden hebt om iSCSI te kiezen. Met SMB heb je een hogere doorvoer, minder latency en het is veel makkelijker te configureren.

Dit is een mooie samenvatting: https://blogs.technet.mic...rect-which-one-is-better/

[ Voor 10% gewijzigd door Jazzy op 04-07-2017 11:40 ]

[Yodocus]

Goed punt. Sinds SRV2016 mag MS er graag mee adverteren. Vooral omdat je software defined storage er zo flexibel van wordt. En omdat het een non-productie omgeving betreft ben ik niet geïnteresseerd in super-performance of 1000% availability.

[DennusB]

Tijd een cluster gedraait (op werk) met Hyper-V met een SMB3 fileserver, de integratie met Hyper-V was echt top en de snelheid en het beheren er van waren erg prettig Ik zou bij Hyper-V zeker SMB3 boven iSCSI kiezen..

[Rolfie]

Hyper-V replication al eens bekeken?

Gewoon 2 machines met local storage, en de VM's laten repliceren naar de andere host.

[Jazzy]

Rolfie schreef op donderdag 6 juli 2017 @ 15:09:
Hyper-V replication al eens bekeken?

Gewoon 2 machines met local storage, en de VM's laten repliceren naar de andere host.

Live Migration en automatische failover, wat de TS vraagt, geven je de mogelijkheid om onderhoud te doen aan een host of bijvoorbeeld uitval te kunnen verdragen. Hyper-V Replica is een DR oplossing en niet geschikt om een VM snel te verhuizen naar een andere host. Bij uitval van een host zit je bovendien met mogelijk dataverlies of corruptie omdat de DR VM gestart moet worden op basis van de laatst gekopieerde snapshot.

Voor de TS niet relevant misschien, maar lang niet elke workload ondersteunt features als Hyper-V Replica, Exchange is daar een voorbeeld van.

[ Voor 9% gewijzigd door Jazzy op 06-07-2017 15:15 ]

[Ximon]

Jazzy schreef op donderdag 6 juli 2017 @ 15:13:
[...]
Live Migration en automatische failover, wat de TS vraagt, geven je de mogelijkheid om onderhoud te doen aan een host of bijvoorbeeld uitval te kunnen verdragen. Hyper-V Replica is een DR oplossing en niet geschikt om een VM snel te verhuizen naar een andere host. Bij uitval van een host zit je bovendien met mogelijk dataverlies of corruptie omdat de DR VM gestart moet worden op basis van de laatst gekopieerde snapshot.

Voor de TS niet relevant misschien, maar lang niet elke workload ondersteunt features als Hyper-V Replica, Exchange is daar een voorbeeld van.

Ik denk dat @Rolfie shared nothing live migration bedoelt. Dus ja, wat OP wil kan wel (alleen niet via Hyper-V Replica).

[Jazzy]

Wat de OP wil kan zeker, dat is ook wat ik zeg. Maar 'Hyper-V replication' kwam op mij over als het verkeerd spellen van Hyper-V Replica. Ook omdat hij het in de tweede zin nog een keer over repliceren heeft.

[bigfoot1942]

Jazzy schreef op dinsdag 11 juli 2017 @ 10:27:
Wat de OP wil kan zeker, dat is ook wat ik zeg. [...]
\Ook omdat hij het in de tweede zin nog een keer over repliceren heeft.

Volgens mij heeft de OP niks over replication gezegd?

[Jazzy]

Ik reageerde op Rolfie die het over replicatie heeft. Ximon stelt dat Rolfie het niet over replicatie had maar over een compleet andere feature. Ik wijs er vervolgens op dat Rolfie het wel degelijk had over replicatie.

De OP had het inderdaad niet over replicatie.

[bigfoot1942]

Helder ;-)

Is dit niet de 'holy grail' in deze situatie?

https://www.tech-coffee.n...with-windows-server-2016/

Shared Nothing migration suggereert dat je er geen hyperconverged (storage) cluster van bouwt?
Als je het inricht zoals in de link kan je gewoon de reguliere LiveMigration gebruiken.