Necesito la razón por la que no debemos instalar el servidor SQL en el controlador de dominio

Soy administrador de sistemas para una pequeña empresa. Ahora consideramos implementar Windows Server 2008 R2 para la empresa. Planeamos implementar Active Directory. También nos gustaría actualizar RDMS, de SQL Server 2000 a SQL Server 2014.

Podemos permitirnos comprar un solo servidor debido al tamaño de nuestra organización, por lo que planeamos implementar AD y SQL Server 2014 en la misma máquina. Sin embargo, Microsoft recomienda no instalar SQL Server 2014 en un controlador de dominio.

He verificado los motivos, pero no entiendo cuál es el problema, por lo que si alguien responde mis preguntas a continuación, es realmente útil.

1. No puede ejecutar servicios de SQL Server en un controlador de dominio con una cuenta de servicio local. → Si ejecutamos SQL Server en un controlador de dominio con una cuenta de usuario de dominio, ¿qué pasaría?
2. Después de instalar SQL Server en una computadora, no puede cambiar la computadora de un miembro de dominio a un controlador de dominio. Debe desinstalar SQL Server antes de cambiar la computadora host a un controlador de dominio. → Planeamos promocionar nuestro servidor a un controlador de dominio antes de instalar SQL Server 2014 y no planeamos cancelar la promoción al servidor miembro porque es nuestro único servidor. ¿Está mal nuestro plan?
3. Después de instalar SQL Server en una computadora, no puede cambiar la computadora de un controlador de dominio a un miembro de dominio. Debe desinstalar SQL Server antes de cambiar la computadora host a un miembro de dominio. → No planeamos dejar de promocionar al servidor miembro porque es nuestro único servidor. ¿Está mal nuestro plan?
4. Las instancias de clúster de conmutación por error de SQL Server no son compatibles cuando los nodos del clúster son controladores de dominio. → No planeamos instalar el clúster de conmutación por error, por lo que creemos que no es un problema. Estamos equivocados
5. El programa de instalación de SQL Server no puede crear grupos de seguridad ni aprovisionar cuentas de servicio de SQL Server en un controlador de dominio de solo lectura. En este escenario, la instalación fallará. → Porque tenemos un solo servidor, por lo que nunca será un controlador de dominio de solo lectura, por lo que creemos que no es un problema. Estamos equivocados

En realidad, supongo que si borramos (1), podemos instalar SQL Server 2014 en nuestro controlador de dominio.

Gracias por leer todas las oraciones. Espero que alguien nos dé respuestas.

Los puntos que ha enumerado se muestran en BOL aquí , y aunque cita:

El programa de instalación de SQL Server no bloqueará la instalación en una computadora que sea un controlador de dominio

Establece en este artículo de KB que la configuración fallará, aunque solo se aplica a la lista hasta la versión 2012.

Una de las principales razones por las que no tendrá que hacer esto es el soporte técnico de Microsoft. Como se indica en la documentación, no debe instalarlo, es probable que no proporcionen soporte. Especialmente si experimenta problemas de seguridad o rendimiento. A menos que desembolses una buena cantidad de dinero, probablemente no harán mucho por ti.

Nunca he visto a una compañía poner estos dos roles juntos por elección. Odio decirlo, pero si necesitan ejecutar una aplicación en SQL Server y va a ser una aplicación de misión crítica, no hay razón para que no inviertan en ejecutar esa aplicación. El hardware es barato en estos días y AD no tarda mucho en ejecutarse si su organización es tan pequeña. Incluso podría ir y obtener hardware de 2 o 3 años para el caso.

Ahora con eso dicho, el servidor Window Small Business solía ser la ventanilla única para una situación como la que usted describe. Es un servidor AD, Exchange y web todo en uno; y si recuerdo también tenía una instalación de SQL Server pero no recuerdo. Configuré uno de estos servidores para un departamento una vez.

Sin embargo, con Windows Server 2012 cambiaron esto a Windows Server Essential Edition , y no estoy seguro de qué roles tiene con esta edición. Sin embargo, sugeriría que simplemente gaste el dinero para obtener la Edición estándar. Una característica que obtiene con Standard es la licencia para ejecutar dos máquinas virtuales de SO huésped a través de Hyper-V. Si dimensiona el hardware adecuadamente, le permitirá ejecutar su instancia de SQL Server en una VM y luego su aplicación en la segunda VM. Aunque su rendimiento es todo en un servidor, proporciona una separación de límites y sería una configuración totalmente compatible con Microsoft. Solo mis dos centavos.

Las razones que dio son las razones principales para evitar la combinación de SQL Server y un controlador de dominio. Agregaré dos más:

• puede ser un riesgo para la seguridad si se accede a su SQL Server por una máquina que está expuesta a Internet (como un servidor web)
• SQL Server tiene el potencial de privar a Windows de recursos, lo que efectivamente cerraría su controlador de dominio y, a su vez, su red

Dicho esto, no es necesariamente raro ver que SQL Server está instalado en un controlador de dominio en una pequeña empresa: solo tiene tantos recursos para distribuir y, a veces, tiene que conformarse con lo que tiene.

La conclusión: evite combinar roles de servidor si puede. Si debe combinar AD y SQL Server, tenga en cuenta los riesgos y haga todo lo posible para mitigarlos.

[Descargo de responsabilidad: nunca consideraría combinar AD y SQL Server en otra cosa que no sea una empresa muy pequeña. Existen demasiados riesgos, y las cargas del servidor suelen ser mucho más pesadas.]

El verdadero problema aquí es que AD DC ya usa SQL Server como su propio motor de base de datos interno con algunas personalizaciones especiales para garantizar un buen rendimiento (la llamada Base de datos interna de Windows). Si instala SQL Server en un DC, entrará en conflicto con esta implementación, por lo que enfrentará no solo problemas para promocionar o des-promocionar DC, sino también con la base de datos misma.

También existe el problema del rendimiento del disco para servicios y aplicaciones que no sean AD-DS en el DC, sin embargo, eso se puede solucionar instalando SQL Server y colocando los DB y los archivos de registro en un disco diferente al que contiene el NTDS.DIT ​​AD base de datos.