2008-09-29 9 views
32

El departamento de TI donde trabajo está tratando de pasar a servidores 100% virtualizados, con todos los datos almacenados en una SAN. Aún no lo han hecho, pero el plan eventualmente requiere mover las máquinas existentes de SQL Server a servidores virtuales también. HaceServidor SQL virtualizado: ¿por qué no?

unos meses asistí a los héroes suceden aquí evento de lanzamiento, y en una de las sesiones de SQL Server al orador menciona de pasada que esta no es una buena idea para los sistemas de producción.

Así que estoy buscando un par de cosas:

  1. ¿Cuáles son las razones específicas por las cuales esto es o no es una buena idea? Necesito referencias, o no me molesto en responder. Podría hacer una respuesta vaga "E/S obligada" por mi cuenta a través de google.
  2. La recolección de los altavoces HHH probablemente no convencerá a nuestro departamento de TI para que cambie de opinión. ¿Alguien puede dirigirme directamente a algo más autoritario? Y por "directamente", me refiero a algo más específico que un comentario vago de Books OnLine. Por favor, acóbalo un poco.
+0

Vale la pena señalar que esta pregunta es bastante antigua, y muchos de los problemas discutidos aquí se resuelven en gran medida, al menos en teoría. Sin embargo, desde que escribí la respuesta aceptada, realicé varios conciertos en sitios con entornos de BD virtualizados y vi problemas de rendimiento en la mayoría de estos sitios. A pesar de lo que dicen los proveedores, todavía debe prestar atención a la configuración de almacenamiento y sintonización en entornos DB virtualizados. – ConcernedOfTunbridgeWells

Respuesta

36

Puedo decir esto por experiencia personal porque estoy lidiando con este mismo problema mientras hablamos. El lugar donde actualmente trabajo como contratista tiene este tipo de entorno para sus sistemas de desarrollo de SQL Server. Estoy tratando de desarrollar una B.I bastante modesta sistema en este entorno y realmente luchando con los problemas de rendimiento.

TLB falla y las E/S emuladas son muy lentas en una máquina virtual ingenua. Si su O/S tiene soporte de paravirtualización (que aún no es una tecnología madura en Windows) utiliza E/S paravirtualizada (esencialmente un controlador de dispositivo que engancha en una API en la VM). Las versiones recientes de Opteron tienen soporte para tablas de páginas anidadas, lo que elimina la necesidad de emular el MMU en el software (que es realmente lento).

Por lo tanto, las aplicaciones que ejecutan conjuntos de datos de gran tamaño y realizan muchos procesos de E/S como (por ejemplo) ETL tropiezan con el talón de Aquiles de la virtualización. Si tiene algo así como un sistema de depósito de datos que podría ser difícil para la memoria o la E/S de disco, debería considerar otra cosa. Para una aplicación transaccional simple, probablemente sean O.K.

Poniendo en perspectiva los sistemas que estoy usando se ejecutan en blades (un servidor de IBM) en una SAN con 4x enlaces F/C de 2 gbit. Esta es una SAN de rango medio. La VM tiene 4 GB de RAM IIRC y ahora dos CPU virtuales. En el mejor de los casos (cuando la SAN está en silencio), esta sigue siendo solo la mitad de la velocidad de mi XW9300, que tiene 5 discos SCSI (sistema, tempdb, registros, datos, datos) en 1 bus U320 y 4 GB de RAM.

Su kilometraje puede variar, pero recomiendo ir con sistemas de estaciones de trabajo como el que describí para desarrollar cualquier E/S pesada en lugar de servidores virtuales en una SAN. A menos que sus requisitos de uso de recursos vayan más allá de este tipo de kit (en cuyo caso están más allá de un servidor virtual de todos modos) esta es una solución mucho mejor. El hardware no es tan caro, ciertamente mucho más económico que un SAN, un chasis blade y licencias de VMWare. La edición de desarrollador de SQL Server viene con V.S. Pro y arriba.

Esto también tiene la ventaja de que su equipo de desarrollo se ve obligado a lidiar con la implementación desde el primer momento: tiene que crear una arquitectura que sea fácil de implementar con un solo clic. No es tan dificíl como suena. Redgate SQL Compare Pro es tu amigo aquí. Sus desarrolladores también obtienen un conocimiento básico de trabajo de administración de bases de datos.

Un viaje rápido a HP's website me tiene un precio de alrededor de 4.600 $ para un xw8600 (su modelo actual basado en Xeon) con un chip Xeon de cuatro núcleos, 4 GB de RAM y 1x146 y 4x73GB 15k discos duros SAS. El precio de la calle probablemente será algo menor. Compare esto con el precio de un SAN, chasis blade y licencias de VMware y el costo de la copia de seguridad para esa configuración. Para la copia de seguridad puede proporcionar un recurso compartido de red con copia de seguridad donde las personas pueden soltar archivos de copia de seguridad de base de datos comprimidos según sea necesario.

EDITAR: This whitepaper on AMD's web-site analiza algunos puntos de referencia en una máquina virtual. De los puntos de referencia en la parte posterior, la pesada carga de trabajo de E/S y MMU realmente perjudica el rendimiento de la VM. Su punto de referencia (que debe tomarse con un grano de sal ya que es una estadística suministrada por el proveedor) sugiere una penalización de velocidad 3.5x en un punto de referencia OLTP. Si bien esto es proveedor suministra uno debe tener en cuenta:

  • Se puntos de referencia de virtualización ingenuo y lo compara con una solución para-virtualizado, no rendimiento-metal desnudo.

  • Un OLTP de referencia tendrá una mayor de acceso aleatorio/carga de trabajo I O, y se pasar más tiempo esperando a que el disco busca. Un disco patrón de acceso más secuencial (característica de consultas de almacén de datos) tendrá una penalización superior, y una operación de la memoria-pesado (SSAS, por ejemplo, es un cerdo memoria bíblica) que tiene un gran número de TLB fallas también incurrir en sanciones adicionales. Esto significa que las ralentizaciones en este tipo de procesamiento probablemente serían más pronunciadas que la penalización de referencia de OLTP citada en el documento técnico.

Lo que hemos visto aquí es que TLB falla y las E/S son muy caras en una VM. Una buena arquitectura con controladores paravirtualizados y soporte de hardware en la MMU mitigarán parte o todo esto. Sin embargo, creo que Windows Server 2003 no admite la paravirtualización en absoluto, y no estoy seguro de qué nivel de soporte se brinda en el servidor de Windows 2008. Ciertamente, es mi experiencia que una máquina virtual ralentizará radicalmente un servidor cuando se trabaja en un proceso ETL y compilaciones de cubo SSAS en comparación con el hardware bare-metal de especificaciones relativamente modesto.

0

La preocupación más grande para mí cuando la virtualización de software es la concesión de licencias normalmente.

Aquí hay un artículo sobre MS SQL. No estoy seguro de su situación así que no puedo seleccionar ningún punto sobresaliente.

http://www.microsoft.com/sql/howtobuy/virtualization.mspx

0

SQL Server es compatible en un entorno virtual. De hecho, lo recomendaría viendo que una de las opciones de licencia es por socket. Esto significa que puede colocar tantas instancias de SQL Server en un sistema virtualizado (por ejemplo, Windows 2008 Server Datacenter) como desee y pagar solo por cada socket de procesador que tenga la máquina.

Es mejor que eso, porque DataCenter se licencia por enchufe con licencias de máquinas virtuales ilimitadas también.

me gustaría recomendar la agrupación de su Hyper-V en dos máquinas sin embargo de modo que si uno falla el otro puede tomar el relevo.

2

Aquí hay algunas pruebas de VMware en ella .. http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf

por supuesto, no se pueden comparar a las máquinas físicas. Pero, probablemente puedas hacer pruebas similares con las herramientas que utilizaron para tu entorno.

Actualmente ejecutamos SQL Server 2005 en un entorno VMWARE. PERO, es una base de datos muy poco cargada y es genial. Funciona sin problemas

Como la mayoría han señalado, que dependerá de la carga de base de datos.

Tal vez se puede convencer al departamento de TI para hacer algo bueno de pruebas antes de implementar ciegamente.

+2

No conoce nuestro departamento de TI. –

1

No, no puedo apuntar a ninguna prueba específica ni nada por el estilo, pero puedo decir por experiencia que poner su servidor de base de datos de producción en una máquina virtual es una mala idea, especialmente si tiene una gran carga.

Está bien para el desarrollo. Posiblemente incluso las pruebas (en la teoría de que si funciona bien bajo carga en la caja virtual, va a funcionar bien en prodcution) pero no en producción.

Realmente es de sentido común. ¿Desea que su hardware ejecute dos sistemas operativos y su servidor sql o un sistema operativo y servidor sql?

Editar: Mi experiencia sesgó mi respuesta. He trabajado con grandes bases de datos bajo una gran carga constante. Si tiene una base de datos más pequeña con poca carga, la virtualización puede funcionar bien para usted.

+0

Edité mi pregunta para reflejar el problema de 'producción'. Muchos otros sistemas funcionan bajo virtualización. Si al agregar un sistema operativo (uno de los cuales casi siempre está inactivo), puede mejorar la copia de seguridad/restaurar y mejorar la agrupación y el tiempo de actividad, ¿por qué no? –

3

Estamos ejecutando un sistema de nómina para más de 900 personas en VMWare sin problemas. Esto ha estado en producción durante 10 meses. Es una carga de tamaño medio en lo que respecta a DB, y hemos asignado previamente el espacio de disco en la máquina virtual para evitar problemas de E/S. Debe desfragmentar tanto el VM Host como el VM slice de forma regular para mantener un rendimiento aceptable.

0

Creo que la posibilidad de que algo malo le pase a los datos sería demasiado grande.

Como ejemplo, digamos que ejecutó un cuadro de SQL Server en Virtual Server 2005 R2 y los discos deshacer se activaron (por lo tanto, el archivo principal "disco" permanece igual y todos los cambios se realizan en un archivo separado que puede ser purgado o fusionado más tarde). Luego sucede algo (por lo general, se encuentra con el límite de 128 GB o el tamaño que sea) y algún administrador desorientado de la mitad de la noche tiene que reiniciarse y se da cuenta de que no puede hacerlo hasta que retire los discos de deshacer. Estás jodido: incluso si mantiene los archivos del disco de deshacer para un análisis posterior, las posibilidades de fusionar los datos entre sí son bastante escasas.

So echoing the other publicaciones en este hilo - para el desarrollo es genial, pero para la producción no es una buena idea. Su código se puede reconstruir y volver a implementar (otra cosa, las VM para el control de la fuente tampoco son una buena idea) pero sus datos de producción en vivo son mucho más importantes.

+0

¿No ocurriría eso también en un disco físico? ¿Cuál sería la diferencia entre un disco duro completo que reinicia? –

+0

He estado en situaciones en las que la VM no arrancará a menos que suelte el disco de deshacer. Es diferente a un bloqueo de disco duro, es un archivo corrupto en una unidad. Es cierto que los discos duros físicos no son perfectos, pero una VM es una capa adicional de dolor de cabeza en algo tan importante. YMMV. –

+0

Tenía la impresión de que, en general, las VM se consideran MÁS confiables, no menos. –

1

Hay alguna información al respecto en Conor Cunningham's blog artículo Database Virtualization - The Dirty Little Secret Nobody is Talking About....Para citar:

Dentro del servidor, sorprendentemente hay poco conocimiento de muchas cosas en esta área que son importantes para el rendimiento. núcleo del motor de SQL Server supone cosas como:

  1. todas las CPU son igualmente poderosa
  2. todas las instrucciones de proceso CPU o menos a la misma velocidad.
  3. un enjuague en el disco probablemente debería ocurrir en un período de tiempo limitado.

Y la publicación sigue elaborando un poco más estos temas. Creo que es una buena lectura teniendo en cuenta la escasez de información disponible teniendo en cuenta este problema en general.

1

Tenga en cuenta que existen algunos productos de virtualización especiales disponibles para bases de datos que valdría la pena examinar en lugar de un producto general como VMWare.

Nuestra empresa (más de 200 servidores SQL) se encuentra actualmente en el proceso de implementación HP Polyserve en algunos de nuestros servidores:

HP PolyServe Software para Microsoft SQL Server permite varias instancias de Microsoft SQL Server objeto de consolidación en sustancialmente menos servidores y almacenamiento SAN centralizado. La arquitectura única de "datos compartidos" de HP PolyServe brinda disponibilidad de clase empresarial y flexibilidad similar a la virtualización en una plataforma de servicios públicos.

Nuestra razón principal para implementar es hacer más fácil la sustitución de hardware: añadir el nuevo cuadro de la "matriz", barajar, donde cada instancia de SQL reside (sin problemas), luego retire la caja de edad. Transparente para los equipos de aplicaciones, porque los nombres de las instancias de SQL no cambian.

+0

No entiendo por qué se requiere un producto para consolidar servidores RDBMS en menos servidores físicos. Al menos con Oracle, puede instalar varias instancias en el mismo cuadro ... diferente SID, puerto diferente para la diferenciación. Y no puedes usar un cambio de DNS para ocultar el movimiento de los servidores. De nuevo con Oracle. TNSNAMES apunta a un nombre de red que está en el DNS. Cuando el servidor se mueve, cambiamos el nombre de la red DNS a mapeo IP ... voila, transparente. Me estoy perdiendo la ventaja de polyserve. –

+0

@Stephanie: HP Polyserve no era necesario para instalar varias instancias de SQL en el mismo host, pero proporcionaba una capa de supervisión que permitía que esas instancias se movieran a un host diferente durante el mantenimiento o en caso de falla. Desde que se publicó mi respuesta original en 2008, nos alejamos de Polyserve hacia un entorno VMWare para nuestros servidores de bases de datos SQL. – BradC

0

También se deben tener en cuenta los problemas de seguridad cuando se trata de vitalización. Virtualization Security es un buen artículo de PandaLabs que cubre algunas de las preocupaciones.

0

Lo está mirando desde el ángulo equivocado. En primer lugar, no encontrará los White Papers de los proveedores por los que no debería "virtualizarse" o por qué debería virtualizarse.

Cada entorno es diferente y necesita hacer lo que funciona en su entorno. Dicho esto, hay algunos servidores que son perfectos para la virtualización y hay algunos que no deberían ser virtualizados.Por ejemplo, si sus SQL Server/s están haciendo millones y millones de transacciones por segundo, como si su servidor estuviera ubicado en el NYSE o el NASDAQ y millones y millones de dólares dependen de él, probablemente no debería virtualizarlo. Asegúrese de comprender las ramificaciones de la virtualización de un servidor SQL.

He visto donde la gente virtualiza SQL una y otra vez simplemente porque la virtualización es genial. A continuación, quejarse más adelante cuando el servidor de VM no funciona como se esperaba.

Lo que necesita hacer es establecer un punto de referencia, probar completamente la solución que desea implementar y mostrar lo que puede y no puede hacer para que no se encuentre con ninguna sorpresa. La virtualización es excelente, es buena para el entorno y ahorra a través de la consolidación, pero debe mostrar por qué sus supervisores no deben virtualizar sus Servidores SQL y solo usted puede hacerlo.

1

Pregunta antiguo con viejas respuestas

Las respuestas en este tema son años de edad. La mayoría de los puntos negativos en este hilo son técnicamente correctos pero mucho menos relevantes. El costo general de la virtualización y SAN es mucho menos un factor ahora de lo que solía ser. Un servidor, invitado, red y SAN de virtualización correctamente configurados puede proporcionar un buen rendimiento con los beneficios de la virtualización y la flexibilidad operativa, incluidos buenos escenarios de recuperación que solo se brindan por ser virtuales.

Sin embargo, en el mundo real solo se necesita un pequeño detalle de configuración para poner todo de rodillas. En la práctica, su mayor desafío con los servidores SQL virtuales es convincente y trabajar con las personas responsables de la virtualización para que se configure correctamente.

Ironía, en el 100 por ciento de los casos en que eliminamos la producción de la virtualización y la trasladamos de nuevo a un rendimiento de hardware dedicado, subimos al techo en el hardware dedicado. En todos estos casos, no fue la virtualización sino la forma en que se configuró. Volviendo al hardware dedicado, en realidad probamos que la virtualización habría sido un uso mucho mejor de los recursos por factores de 5 o más. El software moderno generalmente está diseñado para escalar a través de los nodos, por lo que la virtualización también le beneficia en ese aspecto.

Cuestiones relacionadas