Skip to main content
Enterprise applications
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Consideraciones sobre almacenamiento de Microsoft SQL Server

Colaboradores
PDF

La combinación de las soluciones de almacenamiento de ONTAP y Microsoft SQL Server permite crear diseños de almacenamiento de base de datos de nivel empresarial que satisfacen los requisitos de aplicaciones más exigentes en la actualidad.

Para optimizar ambas tecnologías, es vital comprender el patrón y las características de E/S de SQL Server. Gracias a una buena distribución de almacenamiento para una base de datos de SQL Server, el rendimiento de SQL Server y la gestión de la infraestructura de SQL Server. Una buena distribución de almacenamiento también permite que la puesta en marcha inicial tenga éxito y que el entorno crezca sin problemas con el tiempo a medida que crece el negocio.

Diseño de almacenamiento de datos

Para las bases de datos de SQL Server que no utilizan SnapCenter para realizar backups, Microsoft recomienda colocar los archivos de datos y de registro en unidades independientes. Para las aplicaciones que actualizan y solicitan datos simultáneamente, el archivo de registro tiene un gran consumo de escrituras y el archivo de datos (en función de la aplicación) tiene un gran volumen de lecturas y escrituras. Para la recuperación de datos, el archivo de registro no es necesario. Por lo tanto, las solicitudes de datos pueden satisfacerse desde el archivo de datos ubicado en su propia unidad.

Cuando se crea una nueva base de datos, Microsoft recomienda especificar unidades independientes para los datos y los registros. Para mover archivos después de crear la base de datos, ésta debe desconectarse. Para obtener más recomendaciones de Microsoft, consulte "Coloque los archivos de datos y de registro en unidades separadas".

Agregados

Los agregados son los contenedores de almacenamiento de nivel más bajo para las configuraciones de almacenamiento de NetApp. Existe cierta documentación heredada en Internet, que recomienda separar las operaciones de I/O en diferentes conjuntos de unidades subyacentes. No se recomienda con ONTAP. NetApp ha realizado distintas pruebas de caracterización de las cargas de trabajo de I/O utilizando agregados compartidos y dedicados con archivos de datos y archivos de registro de transacciones separados. Las pruebas muestran que un gran agregado con más grupos RAID y unidades optimiza y mejora el rendimiento del almacenamiento y tiene mayor facilidad de gestión para los administradores por dos motivos:

  • Un gran agregado hace que las funcionalidades de I/O de todas las unidades estén disponibles para todos los archivos.

  • Un agregado de gran tamaño permite hacer un uso más eficiente del espacio en disco.

Para alta disponibilidad (HA), colocar la réplica síncrona secundaria de SQL Server Always On Availability Group en una máquina virtual de almacenamiento (SVM) independiente del agregado. Para fines de recuperación ante desastres, coloque la réplica asíncrona en un agregado que forma parte de un clúster de almacenamiento separado en el sitio de recuperación ante desastres, con el contenido replicado mediante la tecnología SnapMirror de NetApp. NetApp recomienda tener al menos un 10% de espacio libre disponible en un agregado para un rendimiento del almacenamiento óptimo.

Volúmenes

Los volúmenes NetApp FlexVol se crean y residen dentro de los agregados. Este término a veces provoca confusión porque un volumen ONTAP no es una LUN. Un volumen ONTAP es un contenedor de gestión para datos. Un volumen puede contener archivos, LUN o incluso objetos S3. Un volumen no ocupa espacio, solo se utiliza para la gestión de los datos contenidos.

Consideraciones sobre el diseño del volumen

Antes de crear un diseño de volumen de base de datos, es importante comprender cómo los patrones de I/O de SQL Server y las características varían en función de la carga de trabajo y de los requisitos de backup y recuperación. Consulte las siguientes recomendaciones de NetApp para volúmenes flexibles:

  • Evite compartir volúmenes entre hosts. Por ejemplo, aunque sería posible crear 2 LUN en un único volumen y compartir cada LUN en un host diferente, esto debe evitarse porque puede complicar la gestión.

  • Utilice puntos de montaje NTFS en lugar de letras de unidad para superar la limitación de 26 unidades en Windows. Cuando se usan puntos de montaje de volumen, se recomienda generalmente asignar a la etiqueta de volumen el mismo nombre que el punto de montaje.

  • Cuando sea necesario, configure una política de tamaño automático de volúmenes para ayudar a evitar condiciones de falta de espacio. 17 Guía de mejores prácticas para Microsoft SQL Server con ONTAP © 2022 NetApp, Inc. Todos los derechos reservados.

  • Si instala SQL Server en un recurso compartido de SMB, asegúrese de que Unicode esté habilitado en los volúmenes SMB/CIFS para crear carpetas.

  • Establezca el valor de reserva de instantáneas en el volumen en cero para facilitar la supervisión desde una perspectiva operativa.

  • Deshabilite las programaciones de Snapshot y las políticas de retención. En su lugar, utilice SnapCenter para coordinar las copias Snapshot de los volúmenes de datos de SQL Server.

  • Coloque las bases de datos del sistema SQL Server en un volumen dedicado.

  • Tempdb es una base de datos del sistema utilizada por SQL Server como espacio de trabajo temporal, especialmente para operaciones DBCC CHECKDB intensivas en E/S. Por lo tanto, coloque esta base de datos en un volumen dedicado con un conjunto de discos separado. En entornos grandes en los que el número de volúmenes es un reto, puede consolidar tempdb en menos volúmenes y almacenarlo en el mismo volumen que otras bases de datos del sistema tras una planificación cuidadosa. La protección de datos para tempdb no es una prioridad alta porque esta base de datos se vuelve a crear cada vez que se reinicia SQL Server.

  • Coloque los archivos de datos de usuario (.mdf) en volúmenes independientes debido a que son cargas de trabajo de lectura/escritura aleatorias. Es común crear backups de registros de transacciones con más frecuencia que los backups de bases de datos. Por este motivo, coloque los archivos de registro de transacciones (.ldf) en un volumen o VMDK separados de los archivos de datos para poder crear programaciones de backup independientes para cada uno. Esta separación también aísla la E/S de escritura secuencial de los archivos de registro de la E/S de lectura/escritura aleatoria de los archivos de datos y mejora significativamente el rendimiento de SQL Server.

LUN

  • Asegúrese de que los archivos de la base de datos del usuario y el directorio de registro para almacenar backup de registros se encuentren en volúmenes independientes para evitar que la política de retención sobrescriba las snapshots cuando estas se usen con la tecnología SnapVault.

  • Asegúrese de que las bases de datos de SQL Server residen en LUN independientes de los LUN que tienen archivos que no son de base de datos, como los archivos relacionados con búsqueda de texto completo.

  • La colocación de archivos secundarios de base de datos (como parte de un grupo de archivos) en volúmenes distintos mejora el rendimiento de la base de datos de SQL Server. Esta separación solo es válida si el archivo .mdf de la base de datos no comparte su LUN con ningún otro archivo .mdf.

  • Si crea LUN con DiskManager u otras herramientas, asegúrese de que el tamaño de unidad de asignación esté establecido en 64K para las particiones al formatear las LUN.

  • Consulte "Microsoft Windows e MPIO nativo bajo las prácticas recomendadas de ONTAP para SAN moderna" Para aplicar la compatibilidad con accesos múltiples en Windows a dispositivos iSCSI en las propiedades MPIO.