Servidor SQL virtualizado: ¿Por qué no?

https://stackoverflow.com/questions/149318

02-07-2019
|

Pregunta

El departamento de TI en el que trabajo está intentando pasar a servidores virtualizados al 100%, con todos los datos almacenados en una SAN. Aún no lo han hecho, pero el plan eventualmente requiere mover las máquinas físicas físicas de SQL Server a servidores virtuales.

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

Así que estoy buscando algunas cosas:

¿Cuáles son las razones específicas por las que esto es o no es una buena idea? Necesito referencias, o no me molesto en responder. Podría encontrar un vago " E / S enlazado " respuesta por mi cuenta a través de google.
El solo recuerdo 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, redúzcalo un poco.

Solución

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

Los TLB fallan 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), utilice E / S paravirtualizada (esencialmente un controlador de dispositivo que se enlaza con una API en la VM). Las versiones recientes de Opteron son compatibles con tablas de páginas anidadas, lo que elimina la necesidad de emular la MMU en el software (que es realmente lento).

Por lo tanto, las aplicaciones que se ejecutan en grandes conjuntos de datos y hacen un montón de E / S como (por ejemplo) los procesos ETL se disparan sobre el talón de Aquiles de la virtualización. Si tiene algo como un sistema de almacenamiento de datos que pueda tener problemas de memoria o E / S de disco, debería considerar otra cosa. Para una aplicación transaccional simple, probablemente sean O.K.

Ponga en perspectiva los sistemas que estoy usando se están ejecutando en blades (un servidor de IBM) en una SAN con 4x 2gbit F / C enlaces. Este es un SAN de gama media. La VM tiene 4GB de RAM IIRC y ahora dos CPU virtuales. En su mejor momento (cuando la SAN es silenciosa) 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 4GB de RAM.

Su millaje 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 son mucho más que un servidor virtual) esta es una solución mucho mejor. El hardware no es tan caro, ciertamente mucho más barato que un SAN, chasis blade y licencias de VMWare. La edición para desarrolladores de SQL Server viene con V.S. Pro y superior.

Esto también tiene la ventaja de que su equipo de desarrollo se ve obligado a hacer frente a 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 la administración de bases de datos.

Un viaje rápido a Este documento técnico en el sitio web de AMD discute algunos puntos de referencia en una máquina virtual. Desde los puntos de referencia en la parte posterior, la pesada carga de trabajo de E / S y MMU realmente aumenta el rendimiento de la máquina virtual. 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 de 3.5x en un punto de referencia OLTP. Si bien este proveedor es suministrado, uno debe tener en cuenta:

Hace comparaciones con la virtualización ingenua y lo compara con un solución para-virtualizada, no rendimiento de metal desnudo.
Un índice de referencia OLTP tendrá una carga de trabajo de E / S de acceso aleatorio, y pasar más tiempo esperando por el disco busca Un disco más secuencial. patrón de acceso (característico de consultas del almacén de datos) tendrá un penalización más alta, y una memoria pesada operación (SSAS, por ejemplo, es una memoria bíblica cerdo) que tiene una gran número de TLB también será incurrir en sanciones adicionales. Esta significa que la desaceleración en este tipo de procesamiento probablemente sería más pronunciado que el OLTP penalización de referencia citada en el documento técnico.

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

Otros consejos

SAN, por supuesto, y agrupación en clústeres, pero con respecto a la virtualización, tomará un Impacto de rendimiento (puede o no valer la pena):

http: //blogs.technet .com / andrew / archive / 2008/05/07 / virtualized-sql-server.aspx

http://sswug.org ha tenido algunas notas al respecto en su boletín diario últimamente

Quería agregar esta serie de artículos de Brent Ozar:

No es exactamente autoritativo en el sentido que esperaba (proveniente del equipo que construye el servidor, o un manual oficial de algún tipo), pero Brent Ozar es bastante respetado y creo hace un gran trabajo cubriendo todos los problemas aquí.

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 cuanto a DB, y asignamos previamente espacio de disco en la VM para evitar problemas de E / S. Tiene que desfragmentar el VM Host y el segmento VM de forma regular para mantener un rendimiento aceptable.

Aquí hay algunas pruebas de VMWARE en él ... http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf

Por supuesto, no lo comparan con las máquinas físicas. Sin embargo, es probable que pueda realizar pruebas similares con las herramientas que utilizaron para su entorno.

Actualmente ejecutamos SQL Server 2005 en un entorno VMWARE. PERO, es una base de datos muy ligera y es genial. Se ejecuta sin problemas.

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

Tal vez usted pueda convencer al Departamento de TI para que haga algunas buenas pruebas antes de implementar a ciegas.

No, no puedo señalar ninguna prueba específica ni nada de eso, 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 pruebas (en la teoría de que si se ejecuta correctamente bajo carga en una caja virtual, funcionará bien en producción) pero no en producción.

Es realmente el sentido común. ¿Desea que su hardware ejecute dos sistemas operativos y su servidor de SQL o un sistema operativo y un servidor de SQL?

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

Hay información sobre esto en el artículo del blog de Conor Cunningham Virtualización de base de datos: el pequeño secreto sucio, nadie habla de ... . Para citar:

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


todas las CPU son igualmente poderosas

todas las CPU procesan las instrucciones aproximadamente a la misma velocidad.

es probable que se produzca una descarga al disco en un período de tiempo limitado.

Y la publicación continúa elaborando estos temas también un poco más. 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 hay algunos productos de virtualización especializados que están hechos para bases de datos que vale la pena analizar en lugar de un producto general como VMWare.

Nuestra empresa (más de 200 servidores SQL) está actualmente en 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 menos servidores y almacenamiento de SAN centralizado. Los "datos compartidos" únicos de HP PolyServe " La arquitectura ofrece disponibilidad de clase empresarial y flexibilidad similar a la virtualización en una plataforma de servicios públicos.

Nuestra principal razón para implementarlo es facilitar el reemplazo del hardware: agregue el nuevo cuadro a la "matriz", mezcle en el lugar donde reside cada instancia de SQL (sin problemas) y luego elimine el cuadro anterior. Transparente para los equipos de aplicaciones, porque los nombres de las instancias de SQL no cambian.

Pregunta anterior con respuestas antiguas

Las respuestas en este hilo tienen años de antigüedad. La mayoría de los puntos negativos en este hilo completo son técnicamente aún correctos pero mucho menos relevantes. El costo general de la virtualización y los SAN es mucho menos un factor ahora de lo que solía ser. Un host de virtualización, un invitado, una red y una SAN correctamente configurados pueden proporcionar un buen rendimiento con los beneficios de la virtualización y la flexibilidad operativa, incluidos los buenos escenarios de recuperación que solo se ofrecen al 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 convencer 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 los que retiramos la producción de la virtualización y la devolvimos al hardware dedicado, el rendimiento se disparó en el hardware dedicado. En todos estos casos no fue la virtualización sino la forma en que se configuró. Al volver al hardware dedicado, comprobamos que la virtualización habría sido un mejor uso 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 funciona en su ventaja en ese frente.

La mayor preocupación para mí cuando la virtualización de software es normalmente la licencia.

Aquí hay un artículo sobre él para MS SQL. No estoy seguro de tu situación, así que no puedes elegir ningún punto destacado.

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

SQL Server es compatible con un entorno virtual. De hecho, lo recomendaría ya que una de las opciones de licencia es por socket. Esto significa que puede poner tantas instancias de SQL Server en un sistema virtualizado (por ejemplo, Windows 2008 Server Datacenter) como desee y pagar solo por el zócalo del procesador que tiene la máquina.

Es mejor que eso, ya que DataCenter tiene licencia por socket con licencias ilimitadas de máquinas virtuales también.

Recomendaría agrupar su Hyper-V en dos máquinas, sin embargo, para que si una falla, la otra pueda compensar el problema.

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

Como un simple ejemplo, digamos que ejecutó un cuadro de SQL Server en Virtual Server 2005 R2 y que los discos de deshacer estaban activados (por lo tanto, el archivo principal "disco" se mantiene igual y todos los cambios se realizan en un archivo separado que se puede purgar o fusionar más adelante). Luego sucede algo (por lo general, te topas con el límite de 128 GB o cualquiera que sea el tamaño) y algún administrador despistado durante la mitad de la noche tiene que reiniciar y se da cuenta de que no puede hacerlo hasta que retire los discos de deshacer. Estás jodido, incluso si mantiene los archivos de disco de deshacer para un análisis posterior, las posibilidades de fusionar los datos son muy escasas.

Por lo tanto, hago 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 puede ser reconstruido y redistribuido (eso es otra cosa, las máquinas virtuales para el control de la fuente tampoco son una buena idea) pero sus datos de producción en vivo son mucho más importantes.

También se deben considerar los problemas de seguridad que se pueden introducir al tratar con la Vitalización. Virtualization Security es un buen artículo de PandaLabs que cubre algunos de las preocupaciones.

Estás viendo esto desde el ángulo equivocado. Primero, no va a encontrar los Libros Blancos de Proveedores por los que debería " no " virtualizar o por qué debería virtualizar.

Cada entorno es diferente y debe 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 virtualizarse. Por ejemplo, si sus SQL Server / s están haciendo millones y millones de transacciones por segundo, como si su servidor estuviera ubicado en la NYSE o el NASDAQ y millones y millones de dólares dependen de ello, probablemente no debería virtualizarlo. Asegúrese de comprender las ramificaciones de la virtualización de un servidor SQL.

He visto donde las personas virtualizan SQL una y otra vez solo porque la virtualización es genial. Luego, haga una queja más adelante cuando el servidor de la máquina virtual no funcione 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 que no tenga ninguna sorpresa. La virtualización es excelente, es buena para el entorno y se guarda a través de la consolidación, pero debe demostrar por qué sus supervisores no deben virtualizar sus servidores SQL y solo puede hacerlo.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow