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


127

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?

Respuestas:


158
  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.


27
Pero con 2 máquinas tiene el doble de probabilidad de falla de hardware;)
TWith2Sugars

44
@ TWith2Sugars - en lugar de qué?
Kev

3
Árbitro. punto 1. Si el nivel web es propiedad, ¿qué más quiere o necesita que la interfaz API de la aplicación / base de datos? ¿Seguramente se acabó el juego en ese momento? ¿Entonces las cosas se ponen muy interesantes en términos de servicios requeridos para soportar la infraestructura DMZ, por ejemplo, cualquier servicio de AD o Microsoft en juego?
Noelie Dunne

44
@Noelie: su nivel web no tendría acceso para decir, haga una copia de seguridad de la base de datos en un archivo y envíe ese archivo a ftp.hackers.com utilizando xp_cmdshell. O descartar la base de datos. O modificar los valores de configuración. etc.
Mark Brackett el

66
@kirgy: dado que las dos máquinas están en paralelo y son cada una un punto único de falla, la confiabilidad general es menor; técnicamente no es el doble (en realidad es 1 - (r1 * r2)) pero lo suficientemente cerca para una gran confiabilidad y pequeños nodos ... En el caso de 0.01%, sería 0.0199%. Pero para 100 nodos, sería 36.6% en lugar del 100% implícito en la declaración de duplicación.
Mark Brackett

45

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.


3
Estoy de acuerdo, se puede hacer mientras la carga es baja ... a medida que aumenta la carga, es fácil separarlos en 2 o más máquinas.
EJ Brennan

44
Entré e iba a comentar sobre lo mismo. Cambiar su servidor DB es tan fácil como cambiar su cadena de conexión (en la mayoría de los casos).
CitizenBane el

Uuh, eso me gusta. ¡Alguien está pensando en el contexto antes de sugerir una solución!
retiro

22

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.


44
... hasta que aumente el uso concurrente, y el servidor db necesite más memoria para hacer un uso efectivo de las memorias intermedias y los cachés. Una vez que los servidores web / app y db necesitan más memoria de la que pueden compartir en una sola caja, aumenta la paginación y la E / S de disco, y los tanques de rendimiento.
kermatt

@MattK, pero ¿qué pasa si tienes grandes cantidades de memoria? Tenemos una aplicación donde cada cliente tiene su propia base de datos, por lo que tanto la base de datos como los servidores web pueden escalar horizontalmente con mucha facilidad. Dado que tenemos más memoria que el disco en uso (64 GB frente a ~ 40 GB), ¿no sería mejor para el rendimiento mantenerlo todo en la misma máquina?
Beep beep

1
Si su conjunto de trabajo cabe en la memoria, es posible que no vea ninguno de los problemas de rendimiento que menciono. Más a menudo, los servidores tienen más disco que RAM, pero parece que en su caso tiene bases de datos que se adaptarán completamente a la RAM, siempre y cuando las aplicaciones en el servidor compartido no consuman demasiado.
Kermatt

15

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.


12
¿Qué pasa si tiene una base de datos pequeña (ish), pero con toneladas de memoria? ¿El costo de ir a través de la red para cada llamada a la base de datos, particularmente si hay muchos, superaría los beneficios?
Beep beep

1
@ Tom Ritter Aunque el rendimiento es una preocupación (por esta respuesta, y el punto # 3 en la respuesta de Mark Brackett) Sé que algunas personas (incluido yo) probablemente pondrían el dinero ahorrado al NO tener un servidor DB separado en MÁS CPU / RAM / etc. en el único servidor que lo reemplazó. Por lo tanto, esto debe tenerse en cuenta. En cuanto a la memoria separada, IIS y SQL podrían configurarse para dar cuenta de su competencia por los recursos. Personalmente, el "pateador" para mí fue el punto # 1 de Mark ... seguridad. Me gusta la idea del acceso limitado que tendría un servidor web comprometido a un servidor de base de datos separado .
Dylan - INNO Software

@ Tom, siempre puedes dividir el espacio de memoria en dos unidades separadas. La mitad para el servidor y la otra mitad para la base de datos.
Pacerier

15

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).


2
Si está ejecutando cualquier cosa menos SP entonces su servidor web probablemente tiene acceso completo a los datos en su base de datos de todos modos
George Mauer

¿Por qué no es rentable? Por favor especifica.
Robert Jeppesen

Robert I amplió eso y agregó algunos comentarios sobre escalabilidad y mantenimiento.
Dana the Sane

9

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.


Pero haces una copia de seguridad de la base de datos, ¿verdad? De lo contrario, correría el mismo riesgo de perderlo debido a una falla de hardware o un error rara vez excitado. Un ataque que mata al servidor web causará tiempo de inactividad por sí solo. Los suficientes privilegios para agregar registros a las tablas son suficientes para inutilizar un sitio.
Daniel Earwicker

Por supuesto, hace una copia de seguridad de la base de datos, eso está implícito, en qué parte de mi publicación sugerí lo contrario.
Kev

1
Sí, pero la conclusión es que un ataque destinado a derribar el sitio puede hacerlo destruyendo la configuración del servidor web o la base de datos, y la solución es la misma para ambos: restaurar desde la copia de seguridad. Proteger especialmente la base de datos es (a) innecesario y (b) imposible de todos modos.
Daniel Earwicker

@Earwicker: ¿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.
Kev

8
Además de Daniel, te estás perdiendo un ENORME punto. No se trata de una copia de seguridad de la base de datos, se trata de los datos comprometidos. ¿Sus clientes estarían de acuerdo con que "un hacker robó todos sus datos de clientes y ventas, pero no se preocupe, tengo una copia de seguridad". :)
Dylan - INNO Software

9

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.


6

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.


6

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.


5

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.


4

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.


2

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.


1
George, creo que deberías consultar la respuesta de Mark Brackett. La seguridad que su servidor web tiene para la base de datos NO sería la misma que lo sería si el servidor estuviera separado. Específicamente, el "disco local" no sería accesible. Además, si solo un sitio web (de muchos) fue pirateado, es probable que solo hayan comprometido el acceso a la base de datos de ESE SITIO (a menos que use un usuario demasiado poderoso para esa cadena de conexión). Hay innumerables otros escenarios, simplemente no creo que un comentario aquí sea el lugar para ellos.
Dylan - INNO Software

2

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.


No es verdad. Tiene acceso a los datos o privilegios que tenía la casilla A para la casilla B. En una configuración segura, eso significaría que tiene el nivel más alto de acceso a base de datos que tiene la aplicación en la casilla A. Sin embargo, no tiene sa privs en la base de datos, ni root en el sistema operativo del cuadro B.
Mark Brackett

2
"Usted tiene acceso a los datos o privilegios que tenía la casilla A para la casilla B", eso es lo que quise decir con "tiene acceso instantáneo a los datos en el servidor B". Si el RDBMS estaba en la casilla A y no había una casilla B, ¿qué diferencia haría? NÓTESE BIEN. asumimos que ya ha pirateado la casilla A, de cualquier manera.
Daniel Earwicker

En una configuración de dos cuadros, si está aplicando el principio de privilegio mínimo, si el cuadro A (web) está comprometido, lo peor que debería haber sucedido es que ha perdido el DB en el cuadro B y no más.
Kev

1
Y en una configuración de un cuadro, si ese cuadro está comprometido, ha perdido ese cuadro, que incluye el DB en él. ¿Cual es la diferencia?
Daniel Earwicker

2
La diferencia es que en una configuración de dos cuadros, si el servidor web se ve comprometido, todo lo que ha perdido es el servidor web y, en el peor de los casos, la base de datos. El resto de la integridad del servidor de base de datos se mantiene.
Kev

2

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


Por favor explique cómo esto equivale a un ahorro.
John Saunders

1
John: dice que para obtener un rendimiento equivalente a 2 máquinas, debe duplicar el número de núcleos, lo que duplicaría los costos de licencia de SQL Server. ¿Por qué pagar $ 10-20k adicionales por SQL Server si todo lo que obtiene es el mismo rendimiento que utilizar 2 máquinas?
Beep beep

solo es cierto si el rendimiento / utilización de recursos (por ejemplo, cpu) está dominado por los servidores de aplicaciones y no por el servidor db. si el db necesita 8 cpus, no funcionará.
Andreas Dietrich el

1

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.


-1

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.


1
La pregunta original se refería a los servidores de aplicaciones, no necesariamente a los servidores web públicos de Internet.
João Bragança el

-2

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.


No rechacé votar esto, pero "Si bien su base de datos puede requerir espacios de memoria más grandes y, por lo tanto, UNIX": si está ejecutando ventanas de 64 bits y SQL de 64 bits, hay mucha memoria para jugar.
Kev

Lo sentimos, la memoria fue un motivo de ejemplo para la necesidad de implementar sistemas operativos divididos. Otras razones incluyen: rendimiento, seguridad, estándares corporativos / licencias, soporte de proveedores, etc.
Chris Noe

-6

¡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


3
¿Por qué es más seguro?
Bryan Chen
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.