¿Debería SQL Server estar en la misma máquina que su instalación de IIS?

Question

Estoy escuchando el podcast n. ° 19 y Joel y Jeff discuten acerca de ejecutar SQL Server en la misma máquina que su instalación de IIS. Tengo que decir que parece que Jeff se cruzó con Joel, pero de nuevo solo estoy adivinando cuál es cuál. ;)

¿Cuáles son los pros y los contras de cada uno? ¿Cual es mejor?

Normalmente los ejecuto por separado (la preferencia de Joel) pero puedo ver el punto de Jeff donde los dos están más cerca el uno del otro.

Answer 1

Para fines de seguridad es bueno separar las máquinas de la base de datos y de la web, preferiblemente con un cortafuegos entre las dos. Un servidor web está expuesto al mundo en general. Lamentablemente, hay personas que disfrutan de robar o dañar la información contenida en esos servidores.

Luego está el aspecto de rendimiento . Es de conocimiento común que SQL Server adora la memoria. Lo mismo ocurre con IIS, especialmente si el sitio web hace un uso extenso del almacenamiento en caché y la información de la sesión. Entonces usted tiene un conflicto potencial aquí también. Tener una máquina dedicada para SQL Server es claramente mejor que tener una sola máquina haciendo toda la carga.

Luego, la separación permite identificación más fácil de la necesidad de sintonizar y la capacidad de ajustar componentes de hardware individuales.

En resumen, una máquina lo suficientemente potente como para hacer frente a las demandas de IIS y SQL Server en un entorno en vivo no será necesariamente más barata que dos máquinas especificadas para los requisitos específicos de cada servidor. (Jeff Atwood mencionó en uno de los podcasts que la actualización de una máquina habría costado lo mismo que obtener una segunda máquina).

Answer 2

ponerlos en la misma máquina:

• reduce la latencia entre ellos - por lo que si usted tiene un montón de fácil consulta, esto puede mejorar el rendimiento
• Haga su desarrollo y pruebas de rendimiento más fácil porque usted puede hacerlo con una sola caja (o VM)

Si la aplicación no necesita redundancia y no necesita escalar, ponerlas en la misma caja es una victoria definitiva, es mucho más fácil de mantener.

No creo que el argumento de la seguridad tenga algún peso. No veo ningún beneficio de seguridad al separarlos. El servidor web necesitaría tener suficiente acceso a la base de datos para ver y modificar todos o la mayoría de los datos de todos modos, por lo que si estuviera completamente comprometido, el cuadro SQL también se vería comprometido.

Answer 3

@MarkR

de seguridad es, en efecto intensificarse cambiando de SQL Server a otra caja y que tiene que ver con la superficie de ataque expuestos.

El servidor web está expuesto a acceso malicioso desde Internet. Uno espera que nunca suceda, pero ha habido (y podría haber en el futuro) vulnerabilidades que pueden explotarse a través de solicitudes mal formadas que atraviesan los cortafuegos.

La explotación de una de estas vulnerabilidades podría llevar a la ejecución de código arbitrario.

En caso de que el servidor web se vea comprometido de esta forma, cualquier otra cosa que se ejecute en esa máquina ahora es vulnerable y el software de explotación podría potencialmente ejecutarse en un contexto privilegiado. La superficie de ataque de la máquina comprometida es mucho más amplia.

Si SQL Server está instalado en la misma máquina, cualquier base de datos es vulnerable.

Ahora, si SQL Server está instalado en una máquina separada, solo se puede acceder a él a través de su interfaz pública. La superficie de conexión de la base de datos está limitada a esa interfaz. Por lo tanto, para comprometer la base de datos, primero debe poner en peligro el servicio web primero, luego el servidor SQL. Esto es MUCHO más difícil que tenerlos en la misma máquina.

Extendiendo el principio aún más, también es un argumento para el uso de procs almacenados. Si el servidor web solo puede acceder al servidor de la base de datos utilizando procs almacenados, la interfaz, y por lo tanto la superficie de ataque, está enormemente restringida. Si el servidor web puede ejecutar SQL arbitrario contra el servidor de la base de datos, la superficie de ataque es de nuevo mucho más grande de lo necesario y aumenta en gran medida el riesgo para los datos.

En sistemas donde los datos son valiosos, estos riesgos, aunque relativamente pequeños, son muy reales y la determinación de la exposición comercial de tales riesgos es un aspecto esencial del diseño de la solución.

Answer 4

Para sitios muy sensibles, la ventaja de servidores separados con firewalls entre ellos puede ser útil pero trae una cantidad de problemas.

1. rendimiento de las consultas sobre la distribución de IIS - servidores SQL pueden correr muy lento debido a la necesidad de pasar datos a través de la red, también DNS todavía puede ser un factor incluso con los servidores de 2 pies de distancia, por lo que puede haber algo de trabajo para hacer para que las aplicaciones funcionen y se dividan.
2. Gestión. Puede ser obvio, pero sus 2 servidores, 2 licencias de Windows y la administración que está involucrada y la complejidad de atravesar los firewalls.

recomendaciones del servidor de Split:

1. instalar un gigabit LAN entre servidores.
2. Consultas optimizadas para ejecutar como procedimientos almacenados en su lugar
3. Optimizar consultas para solo devolver la cantidad mínima de datos.
4. Asegúrese de que el direccionamiento entre servidores utiliza la dirección IP o la búsqueda efectiva de DNS.
5. Proporcione las cargas SQL de memoria suficientes para obtener resultados temporales.