Cargas de trabajo de Microsoft SQL Server en VMware vSAN
Cuando pensamos en diseñar, implementar o migrar cargas de trabajo de SQL Server en un cluster de vSAN; es importante comprender no solo las cargas de trabajo de SQL, sino también qué configuraciones son adecuadas dentro de un cluster de vSAN para soportar dichas cargas de trabajo. No todas las cargas de trabajo de SQL Server son iguales, algunas requieren un alto rendimiento, otras una gran capacidad de almacenamiento y otras requieren ambas.
Las siguientes recomendaciones apuntan a ayudar a seleccionar la configuración vSAN correcta para las diferentes cargas de trabajo de SQL Server.
Recomendaciones Generales
Este conjunto de recomendaciones son relevantes para cualquier carga de trabajo de SQL Server alojada en vSAN.
- Considere incluir un host adicional (N + 1) a los resultados de dimensionamiento de un cluster, donde N = número mínimo de hosts necesarios. Por ejemplo, el requisito mínimo para un cluster de vSAN es tener al menos tres hosts, la recomendación, en este caso, sería tener cuatro o más hosts en este cluster vSAN. Esta capacidad adicional permite la remediación automática en el caso de una fall de grupo de discos, disco o falla del host.
- Asegúrese de que la infraestructura de red utilizada para el tráfico de red vSAN sea lo suficientemente robusta como para sostener la carga de trabajo planificada: se recomienda un mínimo de 10 Gb de ancho de banda de red dedicado para el tráfico de red vSAN. Este es un requisito para los clusters vSAN All-Flash. Las conexiones de red redundantes también son recomendadas.
- Mientras que un solo grupo de discos por host es soportado, se recomienda tener al menos dos grupos de discos o más por host. Varios grupos de discos pueden mejorar el rendimiento en muchos casos y proporcionan una mayor capacidad de recuperación ante ciertos escenarios de fallas de discos.
- Servicios de vSAN a nivel del cluster:
- El servicio vSAN Performance proporciona métricas de rendimiento para los sistemas de monitoreo que permiten que vROps y otras herramientas de monitoreo recopilen datos de rendimiento basados en vSAN y resuelvan de manera eficiente la implementación de vSAN. El servicio de rendimiento está habilitado de forma predeterminada a partir de la versión 6.7 de vSAN. Para versiones anteriores a vSAN 6.7, considere habilitar este servicio manualmente.
- Encryption – Para demandas de alta seguridad, el cifrado de datos en reposo (complace requerimientos de FIPS 140-2) podría habilitarse como una configuración de todo el cluster. Nuestra validación de estrés de almacenamiento demostró que el rendimiento de las IOPS generales es muy similar entre ejecuciones cifradas y no cifradas, pero agregará sobrecarga de CPU para cifrar y descifrar datos. Recomendamos altamente utilizar CPU físicos que admitan la utilización de AES-NI y verificar que la función AES-NI esté habilitada en el BIOS del servidor. Para una solución de cifrado de extremo a extremo, considere utilizar IPSEC para el cifrado de canales. Si solo las bases de datos de SQL Server seleccionadas deberían estar cifradas, en su lugar se pueden usar las opciones de cifrado nativo de SQL Server.
- vSAN 6.7 amplía la funcionalidad del servicio vSAN iSCSI Target para proporcionar el soporte de reservas persistentes SCSI-3 para discos compartidos para el cluster de Windows Failover Cluster si se usa FCI de SQL Server, el modo de alta disponibilidad es un requisito. El servicio vSAN iSCSI Target en el nivel de cluster vSAN debe habilitarse para este propósito.
- Configure y aplique la política de SPBM apropiada para los datos de SQL Server:
- Fallas de tolerancia: asegúrese de que se haya seleccionado una opción con al menos “1 (una) falta de tolerancia”. No utilice la opción: “Sin redundancia de datos”.
- Número de tiras de disco por objeto (Stripe Width): use el número predeterminado (1) y considere la posibilidad de distribuir los datos entre varios VMDK conectados a varios controladores vSCSI.
- Límite de IOPS por objeto: vSAN 6.2 y las versiones posteriores tienen una función de QoS que establece una política para limitar la cantidad de IOPS que un objeto puede consumir. No utilice esta configuración para ningún objeto que requiera rendimiento. Esta función se puede usar para limitar la asignación de IOPS para las operaciones de copia de backup/restauración para evitar la saturación de la carga de trabajo de producción. Use con precaución ya que esto influirá en el tiempo de copia de backup/restauración y también en el RTO/RPO.
Los ajustes de configuración adicionales pueden ayudar a obtener más beneficios para su carga de trabajo. Use la sección que describe la carga de trabajo “Nivel 1” para las cargas de trabajo de SQL Server donde el rendimiento es la prioridad, mientras que la sección “Nivel 2” podría adaptarse mejor a las cargas de trabajo donde la capacidad y el ahorro de costos son más importantes.
Nivel 1 – Carga de trabajo de procesamiento de transacciones en línea (OLTP) de alto rendimiento:
Las actividades típicas de I/O de SQL Server para cargas de trabajo OLTP, incluyen consultas con muchas operaciones de búsqueda, actividades de control que limpia las páginas sucias en el disco periódicamente y escrituras de registro de transacciones. El I/O de los datos en vuelo es bastante pequeño, y típicamente entre 8K y 64K. Los puntos de referencia TPC-E se usan comúnmente para reproducir las cargas de trabajo similares a OLTP.
Para tales cargas de trabajo donde el rendimiento y la disponibilidad son muy importantes, considere lo siguiente:
- Configuraciones de All-Flash vSAN clusters
- Considere usar al menos dispositivos SAS SSD. Un dispositivo SAS SSD tendrá un mejor desempeño que un dispositivo SATA SSD en la mayoría de los casos, y tiene una mayor profundidad de queue. Los dispositivos más nuevos, como NVMe, producirán un mejor rendimiento.
- Deshabilite la deduplicación y la compresión (esto está deshabilitado por defecto en vSAN). Puede implementar la compresión por tabla en el nivel de la base de datos (se requiere la edición Enterprise de SQL Server) si es necesario.
- Establezca la reserva de espacio de objetos: “Thick Provisioning” para todos los VMDK que alojan archivos de logs y datos de SQL Server. La asignación previa del espacio para los registros de SQL Server logs puede reservar el espacio para evitar el problema de falta de espacio. La capacidad se reservará en el datastore de vSAN. Desde el lado de SQL Server, recomendamos que se otorgue el privilegio de realizar tareas de mantenimiento en la configuración para inicializar los archivos de datos de forma instantánea (disponible en la interfaz de usuario a partir de SQL Server 2016). Asigne previamente el espacio para el registro de la base de datos, para evitar que ocurra el crecimiento automático, o para configurar el método de crecimiento en GB en lugar de por porcentaje.
- No utilice el límite de IOPS para la opción de objeto
- Utilize RAID-1 y al menos 1 fallo de tolerancia (FTT) para ambos datos, y VMDKs de logs. Este es el método de tolerancia de fallos recomendado para este tipo de carga de trabajo.
- Los requisitos de disponibilidad adicionales pueden dictar la necesidad de aumentar el FTT y/o implementar soluciones de alta disponibilidad de SQL Server como los Grupos de disponibilidad (Always On Availability Groups). Si se aumentará el FTT, realice ajustes en la cantidad de discos necesarios para satisfacer no solo la capacidad, sino también los requisitos de rendimiento. Si los Grupos de disponibilidad están habilitados, puede tener una alta disponibilidad a nivel de la aplicación, así como la alta disponibilidad de almacenamiento; sin embargo, se necesita más espacio de almacenamiento y se requiere una red de máquinas virtuales bien diseñada.
- Si se requiere una disponibilidad en varios sitios, la configuración de “vSAN Stretched Cluster” puede usarse para aumentar la disponibilidad de datos en los centros de datos.
- También es importante pensar en los switches de red que se utilizarán durante una implementación de vSAN. Cuando se utilizan configuraciones como all-NVMe vSAN clusters, los controladores físicos del disco ya no forman parte de la configuración y permiten que dichos dispositivos NVMe procesen una gran cantidad de IO en poco tiempo. Network switches de nivel empresarial (10 Gbit o más) ) capaz de tener tamaños de búfer grandes (no compartidos) es ideal para permitir un mayor flujo de IO al cluster vSAN.
Nivel 2 – Carga de trabajo de procesamiento de transacciones en línea (OLTP):
Las cargas de trabajo de nivel 2 se asocian con implementaciones de SQL Server de propósito general que no tienen requisitos dominantes de rendimiento pero deben tener un costo bajo. Todas las consideraciones publicadas a continuación no deben aplicarse a ninguna infraestructura en la cual el rendimiento sea el objetivo principal.
- El vSAN híbrido puede satisfacer los requisitos para tales cargas de trabajo si se tiene en cuenta lo siguiente:
- Se recomienda el uso de múltiples grupos de discos para aumentar el rendimiento del sistema.
- Es importante tener suficiente espacio en el nivel de almacenamiento en caché. La recomendación general de SSD como el nivel de almacenamiento en caché para cada host debe ser al menos el 10 por ciento de la capacidad de almacenamiento total. Sin embargo, el tamaño de SSD recomendado debe ser al menos dos veces el del conjunto de datos de trabajo.
- Seleccione la clase SSD adecuada para admitir los IOPS planificados. Un dispositivo SAS SSD tendrá un mejor desempeño que un dispositivo SATA SSD en la mayoría de los casos, y tiene una mayor capacidad en el queue.
- vSAN All-Flash puede proporcionar un rendimiento satisfactorio con mejores ahorros de espacio que vSAN híbrido, a un costo menor con la siguiente configuración.
- Habilite la deduplicación y la compresión si la carga de trabajo es baja en escritura y el ahorro de costos/espacio supera los requisitos de rendimiento.
- Para los discos de datos de SQL Server, usar la codificación de borrado RAID 5/6 para reducir el uso del espacio podría ser una opción, si se desean ahorros de espacio/costo. Los discos virtuales para los registros de transacciones (logs) aún deben colocarse en el VMDK configurado con la política RAID 1. Es importante tener en cuenta que esta recomendación se aplica a las cargas de trabajo que no requieren un alto rendimiento, y se desean ahorros de espacio.
- Establecer reserva de espacio de objetos: “Thick provisioning” para todos los VMDK que alojan logs de SQL Server. La asignación previa del espacio para los registros de SQL Server (logs) puede reservar el espacio para evitar el problema de falta de espacio. La capacidad se reservará en el datastore de vSAN. Desde el lado de SQL Server, recomendamos que se otorgue el privilegio de realizar tareas de mantenimiento en la configuración para inicializar los archivos de datos de forma instantánea (disponible en la interfaz de usuario a partir de SQL Server 2016). Asigne previamente el espacio para el registro de la base de datos, para evitar que ocurra el crecimiento automático, o para configurar el método de crecimiento en GB en lugar de por porcentaje.
Cargas de trabajo de almacenamiento de datos (Data Warehouse) y/o de reportes
Las aplicaciones de almacenamiento de datos (Data Warehouse) emiten operaciones de escaneo intensivo que acceden a grandes porciones de datos a la vez, así como a operaciones de carga masiva que se realizan comúnmente. Estas operaciones dan como resultado tamaños de I/O más grandes que las cargas de trabajo de OLTP y requieren un subsistema de almacenamiento que pueda proporcionar el rendimiento requerido. Esto hace que el rendimiento, o megabytes por segundo (MB/s), la métrica crítica. Las aplicaciones comunes de tipo de almacenamiento de datos incluyen aplicaciones de soporte de decisiones. Los puntos de referencia TPC-H se utilizan comúnmente para reproducir dicha carga de trabajo.
Para tales cargas de trabajo considere lo siguiente:
- En configuraciones de all-flash, el uso de NVMe SSD en el nivel de capacidad puede beneficiar el rendimiento de la carga de trabajo debido a las operaciones de consulta de lectura dominante.
- En configuraciones totalmente flash donde ahorrar espacio es la prioridad, el uso de RAID5/6 para datos VMDK puede ser una opción. Realice pruebas inteligentes ya que la configuración RAID1 generalmente proporcionará un mejor rendimiento.
- Establecer reserva de espacio de objetos: la asignación previa del espacio para los registros de SQL Server puede reservar el espacio para evitar el problema de FUERA DE ESPACIO. La capacidad se reservará en el datastore de vSAN.
- No utilice el límite de IOPS para la opción de objeto. Como en todo momento, las métricas críticas deben disponer de suficiente ancho de banda para dichas cargas de trabajo.
- Considere el uso de dispositivos de red de alto rendimiento para la red backend vSAN. Utilice al menos switches de 10 Gbit con suficientes buffers para mantener un alto rendimiento.
Un agradecimiento especial a Oleg Ulyanov (CPBU) y Tony Wu (SABU) por colaborar en estas recomendaciones.
Dave Morera – @GreatWhiteTec
