¿Por qué no es aconsejable tener la base de datos y el servidor web en la misma máquina?

Al escuchar la entrevista de Scott Hanselman con el equipo de Stack Overflow ( parte 1 y 2 ), insistió en que el servidor SQL y el servidor de aplicaciones deberían estar en máquinas separadas. ¿Es esto solo para asegurarse de que si un servidor se ve comprometido, ambos sistemas no son accesibles? ¿Las preocupaciones de seguridad superan la complejidad de dos servidores (costo adicional, conexión de red dedicada entre los dos, más mantenimiento, etc.), especialmente para una aplicación pequeña, donde ninguna de las partes está usando demasiada CPU o memoria? Incluso con dos servidores, con un servidor comprometido, un atacante podría causar graves daños, ya sea eliminando la base de datos o alterando el código de la aplicación.

¿Por qué sería esto tan importante si el rendimiento no es un problema?

1. Seguridad. Su servidor web vive en una zona desmilitarizada, accesible a Internet público y que recibe información no confiable de usuarios anónimos. Si su servidor web se ve comprometido, y ha seguido las reglas de menos privilegios para conectarse a su base de datos, la exposición máxima es lo que su aplicación puede hacer a través de la API de la base de datos. Si tiene un nivel comercial intermedio, tiene un paso más entre su atacante y sus datos. Si, por otro lado, su base de datos está en el mismo servidor, el atacante ahora tiene acceso de root a sus datos y servidor.
2. Escalabilidad. Mantener su servidor web sin estado le permite escalar sus servidores web horizontalmente casi sin esfuerzo. Es muy difícil escalar horizontalmente un servidor de bases de datos.
3. Actuación. 2 cajas = 2 veces la CPU, 2 veces la RAM y 2 veces los husillos para acceder al disco.

Dicho todo esto, ciertamente puedo ver casos razonables que ninguno de esos puntos realmente importa.

Realmente no importa (puede ejecutar su sitio web / base de datos en la misma máquina), es el paso más fácil para escalar ...

Es exactamente lo que hizo StackOverflow: comenzando con una sola máquina que ejecuta IIS / SQL Server, luego, cuando comenzó a cargarse mucho, se compró un segundo servidor y el servidor SQL se trasladó a eso.

Si el rendimiento no es un problema, no desperdicie dinero comprando / manteniendo dos servidores.

Por otro lado, refiriéndose a un blogueo diferente de Scott (Watermasyck, de Telligent), descubrieron que la mayoría de los usuarios podían acelerar los sitios web (usando el servidor comunitario de Telligent), colocando la base de datos en la misma máquina que el sitio web. Sin embargo, en el caso de sus clientes, por lo general, el servidor web y db son las únicas aplicaciones en esa máquina, y el sitio web no está presionando demasiado a la máquina. Luego, la eficiencia de no tener que enviar datos a través de la red compensó más la mayor tensión.

Creo que el gran factor sería el rendimiento. Tanto el código del servidor web / aplicación como el SQL Server almacenarían en la memoria caché los datos solicitados comúnmente en la memoria y está eliminando el rendimiento de su caché ejecutándolos en el mismo espacio de memoria.

Tom tiene razón en esto. Algunas otras razones son que no es rentable y que existen riesgos de seguridad adicionales.

Los servidores web tienen diferentes requisitos de hardware que los servidores de bases de datos. Los servidores de bases de datos funcionan mejor con mucha memoria y una matriz de discos realmente rápida, mientras que los servidores web solo requieren suficiente memoria para almacenar en caché los archivos y las solicitudes frecuentes de DB (dependiendo de su configuración). Con respecto a la rentabilidad, los dos servidores no serán necesariamente menos costosos, sin embargo, la relación rendimiento / costo debería ser mayor, ya que no es necesario que diferentes aplicaciones compitan por los recursos. Por esta razón, probablemente tendrá que gastar mucho más en un servidor que atiende a ambos y ofrece un rendimiento equivalente a 2 servidores especializados.

La preocupación de seguridad es que si la única máquina se ve comprometida, tanto el servidor web como la base de datos son vulnerables. Con dos servidores, tiene algo de espacio para respirar, ya que el segundo servidor seguirá siendo seguro (al menos durante un tiempo).

Además, hay algunos beneficios de escalabilidad ya que es posible que solo tenga que mantener unos pocos servidores de bases de datos que son utilizados por un montón de aplicaciones web diferentes. De esta manera, tiene menos trabajo que hacer aplicando actualizaciones o parches y haciendo ajustes de rendimiento. Sin embargo, creo que existen herramientas de administración del servidor para facilitar estas tareas (en el caso de una sola máquina).

La seguridad es una gran preocupación. Idealmente, su servidor de base de datos debería estar sentado detrás de un firewall con solo los puertos necesarios para realizar el acceso a datos abierto. Su aplicación web debe conectarse al servidor de la base de datos con una cuenta SQL que tenga los derechos suficientes para que la aplicación funcione y no más. Por ejemplo, debe eliminar los derechos que permiten la caída de objetos y, ciertamente, no debe conectarse utilizando cuentas como 'sa'.

En el caso de que pierda el servidor web por un secuestro (es decir, una escalada de privilegios completa a los derechos de administrador), el peor de los casos es que la base de datos de su aplicación puede verse comprometida pero no todo el servidor de la base de datos (como sería el caso si el servidor de base de datos y servidor web eran la misma máquina). Si ha encriptado las cadenas de conexión de su base de datos y el hacker no es lo suficientemente inteligente como para desencriptarlas, entonces todo lo que ha perdido es el servidor web.

Un factor que aún no se ha mencionado es el equilibrio de carga. Si comienza a pensar en el servidor web y la base de datos como máquinas separadas, optimiza para menos viajes de ida y vuelta a la red y también es más fácil agregar un segundo servidor web o un segundo motor de base de datos a medida que aumentan las necesidades.

Puedo decir por experiencia de primera mano que a menudo es una buena idea colocar el servidor web y la base de datos en diferentes máquinas. Si tiene una aplicación que requiere muchos recursos, puede hacer que los ciclos de CPU en la máquina alcancen su punto máximo, esencialmente deteniendo la máquina. Sin embargo, si su aplicación tiene un uso limitado de la base de datos, probablemente no sería un gran problema que compartan un servidor.

Wow, nadie menciona el hecho de que si realmente compra un servidor SQL a 5k dólares, es posible que desee usarlo para más que su aplicación web. Si estás usando express, tal vez no te importe. Veo que los servidores SQL ejecutan bases de datos para 20 a 30 aplicaciones, por lo que ponerlo en el servidor web no sería inteligente.

En segundo lugar, depende de para quién es el servidor. Trabajo para compañías financieras y el gobierno. Por lo tanto, utilizamos un dolor loco en el enfoque de usar solo sprocs y limitar los puertos del servidor web a SQL. Entonces, si la aplicación web es pirateada. Lo único que puede hacer el hacker es llamar a sprocs ya que la cuenta de usuario en el servidor web está bloqueada para ver / llamar solo sprocs en la base de datos. Así que ahora el hacker tiene que descubrir cómo ingresar al DB. Si está en el servidor web, es fácil llegar a él.

Estoy de acuerdo con Daniel Earwicker: la pregunta de seguridad es bastante defectuosa.

Si tiene una configuración de cuadro único con un servidor web y solo la base de datos para ese servidor web, si ese servidor web está comprometido, perderá tanto el servidor web como solo la base de datos para esa aplicación específica.

Esto es exactamente lo mismo que sucede si pierde el servidor web en una configuración de 2 servidores. Pierde el servidor web y solo la base de datos para esa aplicación específica.

El argumento de que "se mantiene el resto de la integridad del servidor de base de datos" donde tiene una configuración de 2 servidores es irrelevante, porque en el primer escenario, todos los demás servidores de bases de datos relacionados con cualquier otra aplicación (si hay alguna) tampoco se verán afectados - siendo, como son, alojados en otro lugar.

Del mismo modo, a la pregunta planteada por Kev '¿qué pasa con todas las demás bases de datos que residen en el servidor DB? Todo lo que has perdido es una base de datos.

• si alojara una aplicación y una base de datos en un servidor, solo alojaría bases de datos en ese servidor relacionadas con esa aplicación. Por lo tanto, no perderá ninguna base de datos adicional en la configuración de un solo servidor en comparación con una configuración de varios servidores.

Por el contrario, en una configuración de 2 servidores, donde el atacante tenía acceso al servidor web y, por proxy, derechos limitados (en el mejor de los casos) al servidor de la base de datos, podrían poner en riesgo las bases de datos de cualquier otra aplicación al llevar Realice consultas lentas e intensivas en memoria o maximice el espacio de almacenamiento disponible en el servidor de bases de datos Al separar las aplicaciones en sus propias preocupaciones, al igual que la virtualización, también las aísla por motivos de seguridad de una manera positiva.

Depende de la aplicación y el propósito. Cuando la alta disponibilidad y el rendimiento no son críticos, no está mal no separar la base de datos y el servidor web. Especialmente teniendo en cuenta las ganancias de rendimiento: si la aplicación realiza una gran cantidad de consultas a la base de datos, se puede eliminar una cantidad considerable de carga de red al mantener todo en el mismo sistema, manteniendo bajos los tiempos de respuesta.

Creo que es porque las dos máquinas generalmente tendrían que optimizarse de diferentes maneras. Aparte de eso, no tengo idea, ejecutamos todas nuestras aplicaciones con la base de datos del servidor en la misma máquina, siempre que no estemos frente al público, pero no hemos tenido problemas.

No puedo imaginar que a muchas personas les importe que una máquina se vea comprometida por ambas, ya que la aplicación web generalmente tendrá acceso casi ilimitado a, al menos, los datos, si no el esquema dentro de la base de datos.

Interesado en lo que otros puedan decir.

Escuché ese podcast y fue divertido, pero el argumento de seguridad no tenía sentido para mí. Si ha comprometido el servidor A y ese servidor puede acceder a los datos del servidor B, entonces tendrá acceso instantáneo a los datos del servidor B.

Las licencias de bases de datos no son baratas y, a menudo, se cobran por CPU, por lo tanto, al separar sus servidores web, puede reducir el costo de sus licencias de bases de datos.

Por ejemplo, si tiene 1 servidor que hace tanto web como base de datos que contiene 8 CPU, tendrá que pagar una licencia de 8 cpu. Sin embargo, si tiene dos servidores cada uno con 4 CPU y ejecuta la base de datos en un servidor, solo tendrá que pagar por una licencia de 4 CPU

Una preocupación adicional es que a las bases de datos les gusta tomar toda la memoria disponible y mantenerla en reserva para cuando quiera usarla. Puede forzarlo a limitar la memoria, pero esto puede reducir considerablemente el acceso a los datos.

Argumentar que hay una ganancia de rendimiento real al ejecutar un servidor de base de datos en un servidor web es un argumento defectuoso.

Dado que los servidores de bases de datos toman cadenas de consulta y devuelven conjuntos de resultados, los datos que fluyen realmente del servidor de datos al servidor web son relativamente pequeños, pero la potencia requerida para procesar la consulta y generar el conjunto de resultados es relativamente grande. Por lo tanto, optimizar el rendimiento en torno al tiempo de transferencia de datos es optimizar en torno a lo incorrecto.

Con respecto a la seguridad, hay ventajas de tener el servidor de datos en una caja diferente que el servidor web. Tener una configuración de este tipo no es todo y terminar con toda la seguridad, pero es un paso en la dirección correcta.

En cuanto a la escalabilidad, es fácil y relativamente barato agregar servidores web y ponerlos en clúster para manejar el aumento del tráfico. No es tan fácil y barato agregar servidores de datos y agruparlos. Además, los servidores web y los servidores de datos tienen diferentes necesidades de hardware, por lo que múltiples cuadros ayudan con la escalabilidad.

Si está comenzando con algo pequeño y solo tiene una caja, entonces una buena manera sería usar máquinas virtuales. Ejecutar el servidor web y el servidor de datos en diferentes máquinas virtuales en un host le brinda todas las ganancias de cajas separadas al costo de un precio de caja grande.

El sistema operativo es otra consideración. Si bien su base de datos puede requerir espacios de memoria más grandes y, por lo tanto, UNIX, su servidor web, o más específicamente su servidor de aplicaciones, ya que menciona solo dos niveles, puede estar basado en .Net y, por lo tanto, requiere Windows.

¡Okay! Aquí está la cosa, es más seguro tener su servidor DB instalado en otra máquina y su aplicación en el servidor web. Luego conecta su aplicación a la base de datos con un enlace web. Gracias