tiempo solicitud servicio respondio registro pudo porque inicio iniciar inicia eventos error detuvo detiene despues consulte agente actividad sql-server performance virtualization

sql-server - solicitud - porque se detiene el servicio de sql server



Servidor SQL virtualizado: ¿por qué no? (14)

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 exige mover las máquinas existentes de SQL Server a servidores virtuales también.

Hace unos meses asistí al evento de lanzamiento Heroes Happen Here, y en una de las sesiones de SQL Server, el orador mencionó de paso que esta no es una buena idea para los sistemas de producción.

Así que estoy buscando algunas 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. El recuerdo de los altavoces de 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.

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 un sistema de BI bastante modesto en este entorno y realmente estoy luchando con los problemas de rendimiento.

Las fallas de TLB 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 se ejecutan en grandes conjuntos de datos y hacen muchos procesos ETL de tipo E / S 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 estén bien

Ponga en perspectiva que los sistemas que estoy usando se están ejecutando en blades (un servidor de IBM) en una SAN con enlaces 4x 2 gbit F / C. 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 el SAN está en silencio), esta es 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 mucho más allá de un servidor virtual) 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 para desarrolladores de SQL Server viene con VS Pro y versiones posteriores.

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: debe 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 al sitio web de HP me dio un precio de lista 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 discos duros SAS de 1x146 y 4x73GB 15k. 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: Este documento técnico en el sitio web de AMD 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 suministrado por el proveedor, uno debe tener en cuenta:

  • Compara la virtualización ingenua y la compara con una solución para-virtualizada, no con un rendimiento de metal puro.

  • Un punto de referencia OLTP tendrá una carga de trabajo de E / S de acceso más aleatorio, y pasará más tiempo esperando las búsquedas de disco. Un patrón de acceso al disco más secuencial (característica de las consultas del almacén de datos) tendrá una penalización más alta, y una operación de memoria pesada (SSAS, por ejemplo, es un cerdo de memoria bíblica) que tiene un gran número de fallas TLB también incurrirá en sanciones adicionales . Esto significa que las desaceleraciones en este tipo de procesamiento probablemente serían más pronunciadas que la penalización de punto de referencia 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.

También se deben considerar los problemas de seguridad que se pueden presentar cuando se trata de Vitalización. Virtualization Security es un buen artículo de PandaLabs que cubre algunas de las preocupaciones.

Aquí hay algunas pruebas de VMWARE. Http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf

Por supuesto, no lo comparan con 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 ha señalado, dependerá de la carga de su base de datos.

Tal vez pueda convencer al Departamento de TI para que realice algunas buenas pruebas antes de implementar ciegamente.

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.

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.

Es de sentido común en realidad. ¿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.

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

Como un ejemplo simple, digamos que ejecutó un cuadro de SQL Server en Virtual Server 2005 R2 y los discos de deshacer se activaron (por lo tanto, el archivo principal de "disco" permanece igual y todos los cambios se realizan en un archivo separado que puede purgarse o se fusionó 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 muy escasas.

Haciendo eco de las otras 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.

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 también tiene licencia por socket con licencias de máquina virtual ilimitadas.

Sin embargo, recomiendo agrupar su Hyper-V en dos máquinas, de modo que si una falla, la otra puede tomar el relevo.

Hay algo de información sobre esto en el artículo de blog de Conor Cunningham Virtualización de la base de datos - El secreto sucio que nadie está hablando sobre ... Citar:

Dentro del servidor, sorprendentemente hay poco conocimiento de muchas cosas en esta área que son importantes para el rendimiento. El motor central de SQL Server asume cosas como:

  1. todas las CPU son igualmente poderosas
  2. todas las CPU procesan instrucciones aproximadamente a la misma velocidad.
  3. una descarga al disco probablemente debería ocurrir en un tiempo limitado.

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

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

Nuestra compañía (más de 200 servidores SQL) se encuentra actualmente en el proceso de implementar HP Polyserve en algunos de nuestros servidores:

El software HP PolyServe para Microsoft SQL Server permite que varias instancias de Microsoft SQL Server se consoliden 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.

Nuestro principal motivo para implementarlo es facilitar el reemplazo de hardware: agregue el nuevo cuadro a la "matriz", mezcle dónde reside cada instancia de SQL (a la perfección) y luego elimine el cuadro anterior. Transparente para los equipos de aplicaciones, porque los nombres de las instancias de SQL no cambian.

Estás mirando esto 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 necesitas hacer lo que funciona en tu 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 su SQL Server / s está 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 cómo 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 debe 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 no tener sorpresas. 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.

Vieja pregunta con viejas respuestas

Las respuestas en este hilo tienen años. 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 servidores SQL virtuales es convincente y trabajar con las personas responsables de la virtualización para que se configure correctamente.

Irony, en el 100 por ciento de los casos en que eliminamos la producción de la virtualización y la redirigimos a un rendimiento de hardware dedicado, todo el hardware dedicado llegó a su techo. 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 horizontalmente a través de los nodos, por lo que la virtualización también le beneficia en ese aspecto.