Dovrei avere ancora un controller di dominio fisico, anche post-Server 2012?

Nei giorni precedenti a Windows Server 2012, la raccomandazione sembrava essere quella di avere almeno un controller di dominio fisico posizionato accanto ai controller di dominio virtualizzati.

Una giustificazione per questo era perché se i tuoi host Hyper-V erano raggruppati, allora richiedevano che un controller di dominio fosse contattabile durante l'avvio. Questo ha perfettamente senso per me.

Tuttavia, vorrei spesso sentire le persone dire che è ancora importante disporre di un controller di dominio fisico anche se non si dispone di una configurazione in cluster (ad esempio in una configurazione semplice con un singolo server Hyper-V che esegue un paio di VM, uno di cui è una DC). La giustificazione per questo sembrava (e non potrei mai essere del tutto sicuro) che avresti ancora un problema nel senso che quando l'host Hyper-V si avvia per la prima volta, non c'è DC presente sulla rete. Le credenziali memorizzate nella cache indicano che è ancora possibile accedere, ma per quanto riguarda tutti quei bit che si verificano durante l'avvio che indicano che avere un controller di dominio è vantaggioso? Questo è davvero un problema? Esistono effettivamente operazioni che potrebbero essere eseguite soloall'avvio che causerà un problema? Qualche politica di gruppo per esempio? Quello che sto sostanzialmente chiedendo è: l'argomento DC fisico trattiene veramente l'acqua solo quando è coinvolto il clustering o (prima del 2012) c'era un caso tecnico significativo per esso senza clustering? Questo articolo di Altaro (vedi la sezione "Il mito di pollo e uova") suggerisce che non ce n'è bisogno, ma non sono ancora sicuro.

Ora alla seconda (e principale) parte della mia domanda:

Windows Server 2012 ha introdotto diverse funzionalità mirate a risolvere i problemi relativi alla virtualizzazione dei controller di dominio, tra cui:

1. ID di generazione VM : risolto il problema del rollback USN che significava che lo snapshot (o più specificamente il rollback a uno snapshot) non era supportato / una pessima idea
2. Bootstrap del cluster : è stato risolto il problema "pollo e uovo" relativo al clustering di failover che ho menzionato sopra. Il clustering di failover non richiede più la presenza di un controller di dominio durante l'avvio.

Quindi la mia seconda domanda è simile alla prima, ma questa volta per il 2012+. Supponendo che sia il vDC che l'host siano 2012+ e si prende il clustering dall'equazione, ci sono altri problemi come quelli sopra menzionati che significano che dovrei ancora considerare un DC fisico? Dovrei ancora considerare di avere un controller di dominio fisico accanto al mio host Hyper-V 2012 / 2012R2, non cluster, che contiene un controller di dominio virtualizzato singolo? Ho sentito alcune persone suggerire di mettere AD sull'host Hyper-V, ma non mi piace quell'idea per vari motivi (la cache WB è disabilitata per iniziare).

Come nota a margine, la mia domanda presuppone implicitamente che abbia senso unire l'host Hyper-V al dominio per migliorare la gestibilità. Questa affermazione resiste al controllo?

AGGIORNARE:

Dopo aver letto alcune risposte, mi è venuto in mente che avrei potuto pronunciare le cose in modo leggermente diverso per arrivare al cuore di ciò che sto chiedendo:

Anche con i miglioramenti del 2012 e successivi, resta il fatto che senza controller di dominio fisici o controller di dominio virtuali su un altro host, l'host si avvia ancora quando non sono disponibili controller di dominio. Questo è davvero un problema? In un certo senso, suppongo che sia la stessa (o molto simile) domanda se togli completamente la virtualizzazione dall'immagine. Se avvii regolarmente i server membri prima di qualsiasi controller di dominio, è un problema?

Anch'io non renderei l'host Hyper-V un controller di dominio.

Per quanto riguarda se dovresti avere un controller di dominio fisico, la mia opinione è che con le modifiche che Microsoft ha implementato per quanto riguarda i controller di dominio virtualizzati in generale e il bootstrap del cluster senza DC in particolare, non vedo personalmente la necessità, né sostengo avere una DC fisica. Il mantenimento di una DC fisica sembra controintuitivo alla natura del trasferimento dell'infrastruttura su una piattaforma di virtualizzazione. Virtualizzare la mia intera infrastruttura ma tutto dipende da una singola DC fisica disponibile? Qual è il punto in questo?

Ci sono modi per limitare la tua "esposizione" mentre virtualizzi ancora i tuoi controller di dominio. Un modo sarebbe distribuire più controller di dominio su host diversi nel cluster e utilizzare l'anti-affinità per tenerli separati in caso di errore dell'host (in base al numero di host presenti nel cluster).

Sebbene la risposta di Greg includa un collegamento ad alcuni consigli sulla SM, l'articolo ha comunque due anni e si rivolge a Windows Server 2008 e 2008 R2. Non considererei l'articolo come la migliore procedura corrente in relazione a Windows Server 2012 e 2012 R2. Non riesco a trovare un documento MS ufficiale, ma questo ragazzo è considerato un'autorità leader su Hyper-V - http://www.aidanfinn.com/?p=13171

Una logica per conservare un controller di dominio fisico per dominio è se si verifica un incidente rilevante che colpisce l'host o elimina l'archiviazione di frame per i controller di dominio virtualizzati, si avrebbe almeno un controller di dominio fisico con archiviazione locale per eseguire il ripristino e mantenere la continuità. Microsoft continua a eseguire questo controllo e formulare questa raccomandazione durante i RAP di Active Directory (valutazione e pianificazione del rischio).

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv%28v=ws.10%29.aspx

"Mantieni i controller di dominio fisici in ciascuno dei tuoi domini. Ciò mitiga il rischio di un malfunzionamento della piattaforma di virtualizzazione che interessa tutti i sistemi host che usano quella piattaforma."

Sento che stai cercando una risposta a una riga, quindi eccola:

Dovresti avere un controller di dominio fisico se non ti fidi della capacità del tuo ambiente virtuale di resistere ai guasti.

Potremmo approfondire le peculiarità e le eccezioni con ogni scenario, ma penso che questo colpisca la radice della domanda.

Prendiamo i cluster dall'equazione e concentriamoci sull'unica riga della tua domanda che mi fa rabbrividire.

Dovrei ancora considerare di avere un controller di dominio fisico lungo il mio host Hyper-V 2012 / 2012R2 singolo, non cluster, su cui è presente un controller di dominio virtualizzato singolo ?

Perché, perché, perché, vorresti un singolo DC? In un determinato ambiente cerchiamo di evitare di avere singoli punti di errore per una determinata infrastruttura. I controller di dominio sono il tuo pane e burro: forniscono DNS, la spina dorsale di Active Directory. Seriamente, ricostruisci un PC desktop Windows 7 su 2008R2 e promuovilo. C'è sempre un caso valido per un DC fisico.

Hyper-V con Servizi di dominio Active Directory? No semplicemente no. Innanzitutto, Microsoft non supporta questo. In secondo luogo, come hai detto, la gestione dei backup diventerà un problema dipendente dalla configurazione del disco. Per non parlare del fatto che la bellezza della virtualizzazione è la capacità di ritirare gli host fisici il più rapidamente possibile per costruirli (e apprezzo che un dcpromo non sia un grosso problema (a seconda delle dimensioni del tuo ambiente)) e l'hosting di Servizi di dominio Active Directory complica solo che conta. Si introduce anche un'altra complessità del tempo di Windows.

Personalmente lascio i miei host Hyper-V autonomi fuori dal dominio, ma in realtà non ho alcun argomento reale per nessuna delle due configurazioni.

Per rispondere all'ultima domanda se questo in realtà è mai stato un problema: ho notato che i miei host Hyper-V con RDP abilitato, ma che richiedono NLA, non consentono RDP fino a dopo aver riavviato il servizio Network Location Awareness se non è presente DC up all'avvio. Ho avuto occasionali problemi con la connessione remota a VMMS anche in questi punti, ma solo quando anche qualcos'altro era rotto. Quando non è possibile eseguire il RDP o connettersi al gestore Hyper-V in remoto, è davvero difficile capire cosa è rotto e riparare le cose. Mantenere una DC fisica in giro mi ha impedito che ciò accadesse in qualsiasi momento.