Hyper-V servers in domein opnemen

[rookie no. 1]

Wat zijn de nadelen van de volgende opzet:

Twee Hyper-V hypervisors opgenomen in AD
Twee Windows Server DC's verdeeld over beide hypervisors

Volgens mij is dat een prima opzet voor een kleine omgeving, ware het wel dat ten allen tijde één van beide DC's beschikbaar moet zijn.

[HKLM_]

Je nodes kunnen prima in het domain. Ga je ook de failover cluster manager gebruiken.?

Je kan prima je dc’s in het cluser hangen en zorgen dat op beide nodes een dc staat. Hou er wel rekening mee dat als je csv volumes hebt er altijd een dc beschikbaar moet zijn om je cluster up en running te krijgen als beide nodes samen down gaan.

Er zijn ook wel mannieren om het zonder dc te doen maar in geval van een storing wil je weer zo snel mogelijk up en running zijn.

Wat je kan doen is de vm’s van de dc’s op local storage draaien van je node en niet in het cluster opnemen. Dan staat er altijd een dc op de node geinstalleerd die beschikbaar is ook als je cluster down gaat en weer is opgestart.

Of je zet er een kleine server bij en daar maak je een DC van.

[Squ1zZy]

Ik zou zelf de Hyper-V servers niet in het domein plaatsen. Ik zou core installeren en deze servers hardenen. Core omdat onderhoud en patches dan minder is als bij GUI installaties en het wachtwoord in een kluis leggen. Beheer op de Hyper-V servers is zelden nodig.

Een aanval die mogelijk is op een type 1 Hypervisor en alle VM’s zijn compromised.

[Question Mark]

Hyper-V core kan ook domainjoined worden. Wel de voordelen van een kleinere surface attack, terwijl managementtaken eenvoudiger worden.

[MAX3400]

Op basis van de vraagstelling lees ik niet of/hoe beide hosts verbonden zijn met elkaar of van elkaars bestaan afweten (anders dan dat ze in AD zijn opgenomen); hiermee is ook meteen de noodzaak van 2 nodes nu niet beschreven. Ook mis ik even versie-nummers en andere zaken die je vraagstelling voor ons duidelijk genoeg maken

- mogen ze elkaars VM's overnemen?
- op welke manier kunnen VM's van node A naar B overgaan?
- is er resource-technisch dan voldoende per host aanwezig om alle VM's te kunnen draaien?
- zijn er alternatieve oplossingen bedacht als node A en B niet communiceren en A valt om?

Zoals de rest ook aangeeft; ik zou allicht bedenken om een Core uitvoering te gaan draaien maar misschien is dat beheerstechnisch lastiger voor sommige mensen. En als je ze mag/kan clusteren (dus echt een officieel Microsoft cluster), zou ik me ook inlezen in Cluster-Aware Updates, bijbehorend automatisch/handmatig failover-management en mogelijk ook randzaken als de NUMA nodes en eventueel reservation-tresholds voor bepaalde VM's.

[rookie no. 1]

Dank voor de reacties. Ik heb de vraagstelling doelbewust eenvoudig gehouden, gezien er vele mogelijkheden zijn met shared storage, clusters, etc.

Wat ik tot nu toe in een test omgeving heb draaien is twee Hyper-V (zeg maar Core) servers (local storage, geen cluster, geen live migration) met op elke Hypervisor een VM als DC. Er komen ook nog een paar member server op beide hosts.

Persoonlijk vind ik het enigszins 'tricky' gezien je de hypervisors niet meer kunt beheren als de DC's onbereikbaar zijn, maar aan de andere kant is het een prettig werkende opzet vanwege centrale authenticatie op AD o.a. voor beheer met Server Manager/Honolulu en later aanmaken van cluster en live migration mogelijkheden.

Deze test omgeving ben ik begonnen omdat we nu nog veel klanten hebben met maar één DC en alle hypervisors en vm's met volledige (GUI) Windows Server versie zijn uitgevoerd waar we vanaf willen i.v.m. resources, update beleid en inderdaad 'attack surface'.

Voor minimale kosten willen we een omgeving kunnen aanbieden waar beheer en resources minimaal zijn en redundancy een stuk beter, maar dan moet er natuurlijk geen groot/groter risico zijn dat de omgeving niet meer te beheren is omdat de DC's onbereikbaar zijn. Vandaar mijn 'globale' vraag om eens wat scenarios/configuraties te horen van jullie

[HKLM_]

Ik zou altijd twee dc’s in een omgeving zetten welke dan ook.

[Yodocus]

Volgens MS is het geen probleem: https://blogs.technet.mic...ve-directory-integration/.
Virtuele DC's op een failover cluster worden gewoon ondersteund en zowel je nodes als je Cluster Shared Volumes komen op, nog voordat je virtuele dc gestart is.

[MAX3400]

@rookie no. 1 @HKLM_ alternatief is een Azure AD inzetten in hybrid-mode. Dus 1 DC in-house en als die omvalt, authenticeert iedereen zich tegen Azure.

Het wordt lastiger als de on-prem DC ook alle profiles, scripts, GPO-deployed MSI's en dergelijke huisvest; die wil je liever niet in Azure hebben, zeker als je WAN-verbinding niet heel breed is (ook afhankelijk van de actuele hoeveelheid users & data). Een aandachtspunt wordt dan wel een solide NTP-oplossing om, onder andere, Kerberos tegen Azure netjes te houden

@Yodocus eens maar er is nog geen CSV aangemaakt en ik kan me ook voorstellen dat voor kleinere deployments en TCO, je liever gebruik zou maken van node-replication dan van failover-clustering.

[rookie no. 1]

MAX3400 schreef op vrijdag 16 maart 2018 @ 15:57:
@rookie no. 1 @HKLM_
@Yodocus eens maar er is nog geen CSV aangemaakt en ik kan me ook voorstellen dat voor kleinere deployments en TCO, je liever gebruik zou maken van node-replication dan van failover-clustering.

Klopt helemaal, bij voorkeur geen CSV en eenvoudige node-replication.

[Trommelrem]

rookie no. 1 schreef op vrijdag 16 maart 2018 @ 15:09:
op elke Hypervisor een VM als DC.

Kan prima, maar let zeer goed op je tijdsynchronisatie. Een DC op een Hypervisor waarvan de Hypervisor member is van het domain van de DC leidt altijd tot tijdproblemen als je de default settings gebruikt.

Overweeg een derde DC in Azure. Een simpele DC op een Core installatie kost niet zo veel. Een krat bier is duurder.

[Jazzy]

Trommelrem schreef op zaterdag 17 maart 2018 @ 22:09:
[...]
Overweeg een derde DC in Azure. Een simpele DC op een Core installatie kost niet zo veel. Een krat bier is duurder.

Hangt wel een beetje van het bier af. Over het algemeen is alles in Azure duurder dan het zelf doen, met name als het om simpele dingetjes gaat. Een eenvoudige VM (B2S) met 2 vCPU, 4 GB geheugen, 64 GB opslag en een tweede disk kost ongeveer 45 euro per maand als je voor pay-per-use gaat. Daarvoor moet je dan natuurlijk ook een site2site VPN opzetten waarbij je in het ergste geval (Fritzbox, Experiabox, etc.) nog een betere router moet kopen.

[Tijntje]

Twee interessante artikelen hier over zijn:

Virtualized Domain Controllers: 4 Myths and 12 Best Practices
Yes, Your Hyper-V Host Should be Domain-Joined

[Trommelrem]

Jazzy schreef op zondag 18 maart 2018 @ 13:01:
[...]
Hangt wel een beetje van het bier af. Over het algemeen is alles in Azure duurder dan het zelf doen, met name als het om simpele dingetjes gaat. Een eenvoudige VM (B2S) met 2 vCPU, 4 GB geheugen, 64 GB opslag en een tweede disk kost ongeveer 45 euro per maand als je voor pay-per-use gaat. Daarvoor moet je dan natuurlijk ook een site2site VPN opzetten waarbij je in het ergste geval (Fritzbox, Experiabox, etc.) nog een betere router moet kopen.

Fritzbox kan toch wel met Azure verbinden? Voor zover ik weet kun je met een Fritzbox gewoon een IPSec opbouwen. Alleen is het inderdaad niet verstandig om een Fritzbox of Experiabox met Azure te verbinden: Het is unsupported as hell. Voor backwards compatibility met crappy consumentenrouters kun je overigens ook zo'n klassieke IPSec opbouwen in Azure. Ben de naam even kwijt. Het is die variant waarbij je beperkt bent tot maximaal een enkele site-to-site verbinding per VNet.

Probleem met een DC in een Hyper-V Host die member is van dat domein is clock drift als er langdurig een hoge CPU load is. Dit is met enkele kleine workarounds op te lossen

[ Voor 20% gewijzigd door Trommelrem op 18-03-2018 18:03 ]

[rookie no. 1]

Trommelrem schreef op zondag 18 maart 2018 @ 18:00:
[...]
Probleem met een DC in een Hyper-V Host die member is van dat domein is clock drift als er langdurig een hoge CPU load is. Dit is met enkele kleine workarounds op te lossen

Clock drift? Nog nooit van gehoord voor dit topic. Wel dat je op DC's beter de time synchronization service kunt uitzetten, maar dat is niet voldoende? Overigens geldt dat alleen voor Hyper-V of ook ESXi/vSphere?

[MAX3400]

rookie no. 1 schreef op zondag 18 maart 2018 @ 21:40:
[...]


Clock drift? Nog nooit van gehoord voor dit topic. Wel dat je op DC's beter de time synchronization service kunt uitzetten, maar dat is niet voldoende? Overigens geldt dat alleen voor Hyper-V of ook ESXi/vSphere?

Op je DC's time sync uitzetten? Right... Op een forest & domain, is een goede NTP-source relatief essentieel. Mogelijk dat ik het mis heb maar dan hoor ik het graag welke reden/whitepaper er is dat je je tijd "niet gelijk wil houden".

[rookie no. 1]

MAX3400 schreef op zondag 18 maart 2018 @ 22:01:
[...]

Op je DC's time sync uitzetten?

Niet time sync uitzetten op de DC's zelf, maar via de host (guest time synchronization). Of is dat ook al niet meer nodig?

[VHware]

guest time synchronization moet op beide dc's uit ja