Bonjour à tous,
Mon infra est sous vsphere 5.5 et contient des vm pour exchange 2010 et des serveur tse sous win2008
Notre dc actuel est physique sous win2003 (le support va s'arrêter).
Je souhaiterai mettre en place un nouveau dc mais j'hésite entre renouveler le serveur physique et le conserver en tant que dc ou passer le dc dans une vm sous vsphere

Quels sont vos avis sur la question ?

Merci bien

1 physique et 1 virtuel

pour ma part sur un cluster esx ou tout est redondant je n'ai plus aucun dc physique d'ailleurs tout mes actifs a part les switch sont virtualisés.

idem, aucun physique sur le site principal.
Je@nb, pour comprendre (doit bien y avoir une raison valable^^) quel est l'intéret de garder un DC physique dans une infra virtuelle ?

Dans les cas où ton infra de virtu dépend d'AD (pour de l'authentification par exemple) et que ton DC ne veut pas démarrer, tu peux pas te connecter à ton infra de virtu pour démarrer le DC. Aussi en full virtu t'es plus à même de te taper des usn rollback avec les snapshot/backup ou des pb de synchro temps.
 
Après chez des clients qui sont matures, expérimentés, qui connaissent les risques, qui ont plusieurs datacenter oui, partir sur du full virtu est pas déconseillé mais ils savent ce qu'il faut et faut pas faire sur leur infra et ont testé

je comprends mieux, en effet, que ça peut avoir du sens. Merci pour l'éclairage Nous avons en effet testé quelques scénarios de perte ou de plantage d'un DC (maj foireuse, etc, et)...mais ces scénarios étaient basés sur le fait qu'on voyait la coquille avec un délais suffisant pour démarrer l'environnement de backup distant (SRM) Pour l'environnement virtuel, il n'est pas impacté sur ce plan de notre côté.
ça mériterait d'autres tests, tiens.....

A minima l'auth et une partie NS si t'as pas envie de te faire chier sur l'ip, doit pouvoir se faire manuellement et simplement ou ne pas être virtualisé pour relancer les DC/hosts, ou bien les hosts doivent être hors infra avec auth séparée. 'fin c't'un peut une règle en full virtu d'avoir au moins un hote d'un DC hors infra.

+1 pour le couple physique/virtuel
 
et +1 aussi sur le pb de synchro de temps en full virtualisé ^^

Si tu prend ESXI tu peux demarrer les vcenter sans un compte admin, mais celui local a l'esxi.
Tu peux bien avoir qu'un AD virtuel (moi je prendrai pas le risque)

Nous sur deux AD virtuel, avec une règle de séparation sur les ESX, ça évite d'avoir les 2 au même endroit.
 
Après pour Vcenter, authentification local aucun problème.

 
Dans tous les cas même si l'authentification se fait via LDAP il y aura toujours un compte local du VCenter ainsi qu'un compte local sur les serveurs physiques, je ne vois que des avantages à être en full virtu.

L'accès local peut être désactivé. Et tu auras toujours les problèmes de sécurité, les risques d'USN rollback, la synchro NTP etc.

Désactivé l'accès local est étrange, ne pas laisser du TSE ou autre pourquoi pas, mais si tu es virtualisé, tu auras toujours accès à ton ESX, donc comme si tu étais physiquement devant.
 
Nous avons déjà eu une belle désynchro d'AD...bas si pas de compte local tu t'amuses très rapidement . J'ai un peu de mal à comprendre la volonté de garder du physique dans ce cas là perso.

Je parle de l'accès local à l'ESX

C'est chercher les ennuies quand même à un moment

je capte pas pourquoi il y aurait tout de virtualisé moi ?
 
Si jamais tu virtualise tout et que ton Vcenter a un soucis, plus personne ne peux s'authentifier sur son pc auniveau reseau (sera sur une session locale).  
 
Fin apres tu me diras, l'interet qu'il puisse s'authentifier en soit... si le serveur de fichier est pas accessible ca sert a rien...
Il pourra aller sur le net et basta. pas d'access a la messagerie puisque les serveur seront virtualisé etc donc en effet, ce serait cool d'avoir un peu plus de précision sur ce point la puisqu'il y a bien un compte local a vcenter qui permettra de débuger.

 
En cas de crash du VCenter c'est l'interface de gestion des VM qui est impliqués, les services qu'elles fournissent continuent de fonctionner (serveur de fichier, AD etc.) et les serveurs physique sont toujours allumés. Tu peux toujours te loger directement sur l'hôte qui héberge le VCenter et résoudre la panne. Je dirais qu'il faut mettre le VCenter en cluster avec l'AD et les VM critiques pour une sécurité optimal. Au pire des cas tu peux toujours remonter un VCenter et le resynchronisé avec tes hôtes avec un backup de la BDD.
 
Ici une doc de ce qu'implique le crash du VCenter
http://www.yellow-bricks.com/wp-content/uploads/vc.pdf

Mon Vcenter peut crasher, ça m'empechera pas de travailler. Mes ESX restent toujours disponible et les VMs tournent toujours.
 
Il faut que je perdre sur mon infra 2 ESX différent pour ne plus avoir de DC, ça peut arriver hein, mais dans ce cas la ... j'aurai bien d'autre soucis que l'authentification, qui souvent ne pose pas de soucis car la session est enregistré en local sur les users.

t'as beau avoir la session en local, le serveur de fichier est en reseau donc cool ils peuvent se logger mais peuvent rien faire...

Fin bref, en meme temps si t'as l'infra info qui tombe normal qu'ils peuvent plus travailler. ( et ca me parait etre un minimum quand t'as plusieurs ESX et uniquement 2 DC de pas les mettre sur le meme ESX ^^ )

Mais ok le vcenter qui crache ca n'entraine pas les ESX donc ca va...
Et quand tu valides une option qui permets aux gens de s'authentifier avec leur compte du domaine pour administrer le vcenter j'imagine que le compte local a également la possibilité de s'y connecté justement dans le cas ou les DC tombent ? car sinon la c'est la caca....

par contre vcenter en cluster avec l'AD je vois pas vraiment ce que tu veux dire.... l'AD ne se met pas en cluster puisqu'il y a des processus de réplications internes a l'AD qui font que c'est inutile (dfs-r entre autre)

Après, je manque un peu (beaucoup) de maturité sur le produit, car je me forme actuellement dessus mais juste que je me disais que si tu virtualise tout et que ton systeme de virtualisation se casse la gueule, t'as plus de systeme info qui fonctionne.
Je vois tous les intérêts que peuvent apporter la virtualisation, mais je vois aussi les risques que cela peut engendrer si c'est pas bien métriser.
Parce qu'avoir 15 vm qui est l'objectif de vmware par hote, et mal maitriser leur gestion en cas de plantage de l'hote ca peut rapidement faire des dégats.

Je le répète car tu ne semble pas avoir compris.
 
Le VCenter n'est que l'interface de contrôle de tes VM. Si il crash tu ne pourras simplement plus utiliser les outils qu'il te mets à disposition pour la gestion des VM mais ton infra ne sera aucunement touché, même virtuelle. Tu auras le temps de résoudre ta panne.
 
Je sais pas ce que tu veux dire pas infra qui tombe car ça ne veux pas dire grand chose. Si tu entends la grosse panne d'un serveur physique ou d'un DNS ou d'un AD c'est autant valable dans une infra physique, il faut prévoir des scénarios de restore.
 
Ce n'est pas parce qu'il y a des processus de réplication que ça m'empêche de le mettre en cluster avec les autres VM critiques.
 
Je me répète également concernant l'authentification via le domaine :
Dans tous les cas même si l'authentification se fait via LDAP (domaine) il y aura toujours un compte local du VCenter ainsi qu'un compte local sur les serveurs ESXi.
 
Notre infra comporte 2 cluster de 2 et 3 serveurs hôtes physiques sur deux sites différents, ces clusters contenant chacun à peut près 20 à 30 VM critiques + 4 hôtes physique ESXi indépendant le tout backupé avec Veam et géré depuis le même VCenter qui est lui même en cluster. Tu restore n'importe quelle VM en 5 minutes. Les datas du FS sont elles backupé sur bande et tu peux revenir aux versions antérieurs des fichiers (supprimé ou modifié) depuis n'importe quel poste.

"t'as beau avoir la session en local, le serveur de fichier est en reseau donc cool ils peuvent se logger mais peuvent rien faire..."
 
Tu sais que les gens ne font pas que du fichier hein ? notre ERP s'en fout de mon CIFS sur mon SAN.  
 
 
"Et quand tu valides une option qui permets aux gens de s'authentifier avec leur compte du domaine pour administrer le vcenter j'imagine que le compte local a également la possibilité de s'y connecté justement dans le cas ou les DC tombent ? car sinon la c'est la caca..."
 
Je pourrai gérer mon infra sans mon vcenter pendant 1 semaine voir plus sans aucun soucis, ça sera moins souple, mais c'est tout. Et aujourd'hui avec VeeamBackup et autre, je remonte un DC en quelques minutes, donc ça sera un détails vraiment.
 
Concernant la virtu, tout comme système sensible tu le double.  
 
Aujourd'hui chez nous tu vas retrouver donc :
 
- 2 contrôleurs de domaines sur deux serveurs différents
- 2 San qui héberge chacun un DC différent avec une réplication entre les baies
- Un système de backup/resto qui te remonte un DC en moins de 10min etc...
 
Virtualiser ne veut pas dire ne pas faire de redondance

J'ai tout a fait compris ce qu'est Vcenter ca aucun probleme la dessus c'est surement que je m'exprime mal.
Si vcenter tombe en panne on s'en fou en gros c'est juste on peut plus gerer les machines graces a ca (et si on a choisi que les utilisateurs ne peuvent pas se connecter directement si un ESXi lorsqu'on l'a integre a vcenter, bé faut le réparer avant de pouvoir faire quoi que ce soit comme opération de gestion).

Une infra qui tombe laisse tomber je voulais juste dire en gros que ca sert a rien de vouloir a tous prix avoir un DC et dire cool j'ai sauvé mon DC dans l'optique ou t'as par exemple 3 physique un DC sur un et 2 esx sur les autre et les 2 esx tombent. Car c'est bien les utilisateurs peuvent se loguer, mais il ne peuvent rien faire de plus.... internet et point puisque le serveur de fichier est dans une vm, le serveur d'impression aussi, les appli metier etc etc.
Donc tout ca pour dire, ca sert a rien non plus de vouloir a tous pris que le DC soit disponible peut importe ce qui se passe si le reste ne l'est pas. Parce qu'un utilisateur qui peut se logger mais ne peut pas aller sur le serveur de fichier, c'est la meme chose que si il n'était pas logger pour moi...

et dans le cas que tu cites, ce n'est pas l'AD que tu mets en cluster (car c'est impossible) mais la VM qui contient l'AD voila pourquoi je ne comprenais pas ce que tu voulais dire.

oui et parfait pour ce qui est de l'authentification LDAP je te remercie pour ces informations.

@Micko

Tout a fait il n'y a pas que le serveur de fichier j'ai mal lu ta phrase en réalité en pensant qu'il n'y avait que 2 ESX la ou tu etais donc si ils tombent tu fesais plus rien pour moi ^^

Bref, la on parle d'infra qu'a ce jour je reve de voir...
1 SAN ce serait enorme alors 2....

Et le backup a ce jour j'en suis juste a wbadmin -_- donc je prends note et veam a l'air d'etre tres apprécié de ce que j'ai pu voir

Bref, chaque chose en son temps, ca va venir

Et je suis d'accord avec toi justement quand on virtualise il faut mettre en cluster et utiliser DRS ainsi que vMotion mais ca a aussi un prix ^^ et c'est toujours le meme probleme

" Donc tout ca pour dire, ca sert a rien non plus de vouloir a tous pris que le DC soit disponible peut importe ce qui se passe si le reste ne l'est pas."  
 
Oui mais c'est jamais comme ça, il y a jamais que le DC que tu sauves. On prévois chez nous de pouvoir dans tous les cas démarré ce qui fait vivre la boite, même si ça doit être un peu en mode dégradé le temps de réparer ou remonter des backups.
 
Chez nous tu auras de répliquer donc :
 
- DC
- ERP (BDD, APPLIs)
- 1 Serveur d'impression
- Mails
- Fichiers sensibles
 
Ca dans tous les cas, il y a toujours une redondance. Pour les DC ce n'est pas un cluster au sens classique, mais il se réplique l'un sur l'autre dans tous les cas (objets, droits etc...).
 
 
EDIT :  
 
Les SANs de nos jours sont plus accessible qu'avant, nous avons chez nous 2 Dell Powervault MD3620F avec 26To chacun et 1 Netapp FAS2020 et 1 Netapp FAS2040, et nous sommes une PME de 150 personnes
avec un CA de 30M€, donc pas une super multinational. Mais si ta direction veut un minimum d'informatique ...il faut mettre un minimum la main à la poche, mais je comprend pas évident des fois

Ça me parraissait évident que ce soit des VM en cluster et non des rôles  
 
C'est toi qui fait une fixation sur l'AD, tu parle ici d'un scénario de crash d'un hôte physique, d'où l'intérêt des clusters et de la disponibilité des VM critique. L'infra sera toujours debout même si un hôte ou des VM tombent.

Je vais te donner un vrai exemple : maintenance électrique lourde. Coupure totale sur un grand site pendant plusieurs heures, donc arrêt de l'infra ESX au complet.
 
Au redémarrage, catastrophe, impossible de se logguer à l'infra ESX : les comptes admins sont uniquement des comptes de domaine, hors tous les DC sont arrêtés. Panique chez le client qui n'arrive pas à résoudre ce problème d'oeuf et de poule. Si l'accès local à l'ESX avait été désactivé (ce qui normalement aurait du être le cas), il était vraiment mal.

Après c'est ce tirer une balle dans le pied aussi, si tu sais que tu as un soucis en cas de problème des ADs, soit tu fais la redondance qui va bien, soit un accès local au ESX pour les restarts.
 
Mais je comprend pas l'intérêt d’empêcher un accès local au ESX, Tu peux même faire un PC dans ta salle des serveurs, avec uniquement lui qui a un accès si tu as peur d'un piratage.

Aucun intérêt d'empêcher le login local sur les hôtes tout autant que sur le VCenter, explique nous pourquoi tu ferais ça?
 
Login LDAP et login locale cohabite parfaitement ensemble je ne vois pas le problème.
 
Tu défini un superadmin local du VCenter, des superadmin locaux sur tes hôtes et une authentification LDAP pour les droits d'accès par utilisateur, point final.

Règles de sécurité, recommandations de cabinet de consulting alakon, historique jamais corrigé, voire oubli des login/mots de passe, il y a plein de raisons    

Règles de sécurité, recommandations de cabinet de consulting alakon, historique jamais corrigé, voire oubli des login/mots de passe, il y a plein de raisons    
 
Plein de mauvaises raison, car historique jamais corrigé et oubli ... je pense que même avec 10 serveurs ils auront toujours des emmerdes la
 
Après règles de sécurité je peux le comprendre, mais la encore, un PC dans une salle des serveurs verrouillé avec un accès unique depuis cette machine et hors réseau ça va être dur de faire mieux à un moment.
 
Après je pense qu'il y a encore une grande frilosité à la virtualisation pour certains décideurs, et donc ils cherchent toutes raisons pour ne pas virtualiser.

Mesure de sécurité et de savoir où tu mets ton authentification. On n'est pas tout schyzo, tu es censé n'avoir qu'une identité, gérée centralement, pour pouvoir auditer.
 
Après si tu peux séparer infra physique et virtuelle tant mieux.
 
 
Un autre problème qu'on avait jusqu'à 2012 et hyper-v. Un cluster hyper-v (enfin un cluster windows) a besoin d'AD pour monter. Si tes DC sont virtualisés sur ton cluster, si le cluster a pas d'AD, il peut pas démarrer, s'il démarre pas, tu peux pas démarrer les VM, donc démarrer les VM des DC. Oeuf et poule. Donc si t'as pas d'autre DC dispo pour démarrer ton cluster t'es baisé. Tu vas galérer à faire démarrer ton cluster (au final tu vas peut être y arriver via des mécanismes cachés ). Une solution de contournement c'est de pas mettre en cluster tes VM des DC. Tu t'en fou qu'elles soient en cluster (ou au moins une on va dire). AD résiste bien si tu éteins des DC.

Après effectivement sur du Hyper-V ça je serai pas te dire, je dois m'auto former sur le sujet, car ça m’intéresse.
 
C'est vrai que sur Vmware, je n'ai pas ce soucis d'obligation d'AD pour reboot l'infra.

Le gros point noir de virtualiser les DC, c'est que cela donne concrètement aux admins virtus l'accès complet à l'annuaire. Ce n'est pas un problème pour de petites boîtes, mais ça peut l'être pour de très grosses.

 
Il aura accès à la VM et à la gestion de celle-ci mais il ne pourra pas se logger dessus si il n'a pas le compte admin du domaine ou l'admin local donc pas forcément d'accès à l'annuaire.

C'est un problème de droits, pas de virtualisation ça par contre.

Tout a fait

Pas du tout, déjà parce que les problèmes de sécurité sont liés aussi à l'aspect backup/restore/synchro NTP expliqués plus haut. Ensuite parce qu'avec les vmdk on peut ensuite avoir accès à l'AD sans avoir besoin de se logger.

Non toujours un problème de droit, si tu montes un VMDK (ça peut se crypter hein déjà...), mais si tu as pas de login et mdp local ça te fera une belle jambe.
 
On a pas dit de donner full droit (comptes locaux etc..) à l'ensemble de tes admins, mais le donner à qui te juge bon de l'avoir.
 
Et la encore comme je l'ai dit, tu as ta salle des serveurs qui est accessible à quelques personnes, dans lequel tu fous un PC hors réseau qui lui a accès au ESX en local.  
 
Les backups/resto même combat, tu interdits l'accès et les mecs ne pourront pas y aller pas plus dur que ça.

 
Alala quel manque d'objectivité à chercher absolument la faute dans la virtualisation. La faute se situe souvent entre le tabouret et le Datacenter  

Oui la je comprend pas la problématique, mais je pense qu'il y en n'a tout simplement pas au final.

 
C'est bien naïf tout ça ...
 
Aujourd'hui, tu as un DC virtuel. Une personne ayant accès au stockage des vm prend le vmdk et l'emporte chez lui. C'est ni vu ni connu. Les DC tournent normalement, la vie continue.
Pendant ce temps là, j'ai accès à la base de l'AD en offline (bah oui tu montes ton vmdk sur un autre pc, ton ntds est lisible). A partir de là tu peux faire plein de trucs : J'ai accès à tous les hash des mdp. J'ai mon PC avec des softs pas très légaux, j'utilise les rainbow table pour récupérer les mdp de qq utilisateurs, si possible des admins;
J'ai aussi accès au cache windows des logins qui se sont logués, pareil, je peux récup les infos et faire du pass the hash.
 
 
Pire, je peux faire planter un AD en lui faisant répliquer des données sur les autres dc si je réinjecte le vmdk (bon moins simple mais possible quand même, si j'isole le dc avant de voler et remettre le vmdk modifié)
 
 
Pars du principe que si tu as accès au DC, que ce soit physiquement ou virtuellement, tu as au final possibilité d'avoir tous les droits...