J'ai besoin de la raison pour laquelle nous ne devons pas installer SQL Server sur le contrôleur de domaine
Je suis administrateur système pour une petite entreprise. Nous envisageons maintenant de déployer Windows Server 2008 R2 pour l'entreprise. Nous prévoyons de mettre en œuvre Active Directory. Nous souhaitons également mettre à niveau RDMS, de SQL Server 2000 vers SQL Server 2014.
Nous pouvons nous permettre d'acheter un seul serveur en raison de la taille de notre organisation, nous prévoyons donc d'implémenter à la fois AD et SQL Server 2014 sur la même machine. Cependant, Microsoft recommande de ne pas installer SQL Server 2014 sur un contrôleur de domaine.
J'ai vérifié les raisons, mais je ne comprends pas quel est le problème, donc si quelqu'un répond à mes questions ci-dessous, c'est vraiment utile.
- Vous ne pouvez pas exécuter les services SQL Server sur un contrôleur de domaine sous un compte de service local. → Si nous exécutons SQL Server sur un contrôleur de domaine sous un compte d'utilisateur de domaine, que se passerait-il?
- Une fois que SQL Server est installé sur un ordinateur, vous ne pouvez pas remplacer l'ordinateur d'un membre de domaine par un contrôleur de domaine. Vous devez désinstaller SQL Server avant de remplacer l'ordinateur hôte par un contrôleur de domaine. → Nous prévoyons de promouvoir notre serveur en contrôleur de domaine avant d'installer SQL Server 2014 et nous ne prévoyons pas de retirer la promotion du serveur membre car c'est notre seul serveur. Notre plan est-il mauvais?
- Une fois que SQL Server est installé sur un ordinateur, vous ne pouvez pas remplacer l'ordinateur d'un contrôleur de domaine par un membre de domaine. Vous devez désinstaller SQL Server avant de remplacer l'ordinateur hôte par un membre de domaine. → Nous ne prévoyons pas de dé-promouvoir sur le serveur membre car c'est notre seul serveur. Notre plan est-il mauvais?
- Les instances de cluster de basculement SQL Server ne sont pas prises en charge lorsque les nœuds de cluster sont des contrôleurs de domaine. → Nous ne prévoyons pas d'installer de cluster de basculement, nous pensons donc que ce n'est pas un problème. Avons-nous tort?
- Le programme d'installation de SQL Server ne peut pas créer de groupes de sécurité ou provisionner des comptes de service SQL Server sur un contrôleur de domaine en lecture seule. Dans ce scénario, le programme d'installation échouera. → Parce que nous n'avons qu'un seul serveur, donc ce ne sera jamais un contrôleur de domaine en lecture seule, donc nous pensons que ce n'est pas un problème. Avons-nous tort?
En fait, je suppose que si nous effaçons (1), nous pouvons installer SQL Server 2014 sur notre contrôleur de domaine.
Merci d'avoir lu toutes les phrases. J'espère que quelqu'un nous donnera des réponses.
Les points que vous avez énumérés sont indiqués dans BOL ici , et même s'il cite:
Le programme d'installation de SQL Server ne bloquera pas l'installation sur un ordinateur qui est un contrôleur de domaine
Il indique sur cet article de la base de connaissances que la configuration échouera, bien que le s'applique uniquement à la liste jusqu'à la version 2012.
Une des principales raisons pour lesquelles vous allez vous opposer à cela est le support Microsoft. Comme il est indiqué dans la documentation, vous ne devez pas l'installer, ils ne fourniront probablement pas de support. Surtout si vous rencontrez des problèmes de sécurité ou de performances. À moins que vous ne déboursiez plus d'argent, ils ne feront probablement pas grand-chose pour vous.
Je n'ai jamais vu une entreprise combiner ces deux rôles par choix. Je déteste le dire, mais s'ils ont besoin d'exécuter une application dans SQL Server et que ce sera une application critique, il n'y a aucune raison pour eux de ne pas investir dans l'exécution de cette application. Le matériel est bon marché de nos jours et il ne faut pas beaucoup de temps pour que AD fonctionne si votre organisation est si petite. Vous pouvez même aller chercher du matériel vieux de 2 ou 3 ans.
Cela dit, le serveur Windows Small Business était le guichet unique pour une situation comme celle que vous décrivez. Il s'agit d'un serveur AD, Exchange et Web tout en un; et si je me souviens également eu une installation de SQL Server mais je ne me souviens pas. J'ai installé un de ces serveurs pour un département une fois.
Cependant, avec Windows Server 2012, ils ont changé cela en Window Server Essential Edition , et je ne sais pas quels rôles vous obtenez avec cette édition. Je dirais que vous dépensez simplement l'argent pour obtenir l'édition standard. Une fonctionnalité que vous obtenez avec Standard est la licence pour exécuter deux machines virtuelles de système d'exploitation invité via Hyper-V. Si vous dimensionnez le matériel de manière appropriée, cela vous permettra d'exécuter votre instance SQL Server dans une seule VM puis votre application dans la deuxième machine virtuelle. Bien que vos performances soient toutes sur un serveur, elles offrent une séparation des limites et serait une configuration entièrement prise en charge par Microsoft. Juste mes deux cents.
Les raisons que vous avez données sont les principales raisons pour éviter la combinaison de SQL Server et d'un contrôleur de domaine. J'en ajouterai deux autres:
- cela peut représenter un risque pour la sécurité si votre serveur SQL est accessible par une machine exposée à Internet (comme un serveur Web)
- SQL Server a le potentiel de priver Windows de ressources - ce qui arrêterait efficacement votre contrôleur de domaine et, à son tour, votre réseau
Cela dit, il n'est pas nécessairement rare de voir SQL Server installé sur un contrôleur de domaine dans une petite entreprise - vous n'avez que tant de ressources à contourner et vous devez parfois vous contenter de ce que vous avez.
L'essentiel: évitez de combiner les rôles de serveur si vous le pouvez. Si vous devez combiner AD et SQL Server, soyez conscient des risques et faites ce que vous pouvez pour les atténuer.
[Avertissement: je n'envisagerais jamais de combiner AD et SQL Server dans autre chose qu'une très petite entreprise. Il y a trop de risques, et les charges de serveur sont généralement beaucoup plus lourdes.]
Le vrai problème ici est que AD DC utilise déjà SQL Server comme son propre moteur de base de données interne avec des personnalisations spéciales pour assurer de bonnes performances (la soi-disant base de données interne Windows). Si vous installez SQL Server sur un DC, cela entrera en conflit avec cette implémentation, vous rencontrerez donc non seulement des problèmes de promotion ou de dé-promotion des DC, mais aussi avec la base de données elle-même.
Il existe également le problème des performances du disque pour les services et applications autres que AD-DS sur le contrôleur de domaine, mais cela peut être résolu en installant SQL Server et en plaçant les bases de données et les fichiers journaux sur un disque différent de celui contenant l'AD NTDS.DIT base de données.