Recomendaciones de almacenamiento físico (Office SharePoint Server)
Los discos y matrices que se eligen (y la colocación de los datos en dichos discos y matrices) pueden afectar de forma significativa al rendimiento del sistema. Si no está familiarizado con la matriz redundante de discos independientes (RAID), vea los siguientes recursos:
Para ver una introducción sobre los tipos de RAID que se usan con Microsoft SQL Server 2008, vea Niveles de RAID y SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0xC0A).
Para obtener una comparación de los niveles de RAID que se usan con SQL Server 2008, vea el tema sobre cómo comparar diferentes implementaciones de los niveles de RAID (https://go.microsoft.com/fwlink/?linkid=105582&clcid=0xC0A).
Este tema describe principalmente SQL Server 2008, aunque también se admiten Microsoft SQL Server 2005 y Microsoft SQL Server 2000.
Uso de las matrices RAID y los discos adecuados
La siguiente lista proporciona algunos procedimientos recomendados y sugerencias para elegir el nivel de RAID y los discos duros más adecuados.
El rendimiento se mejora con un número mayor de discos y matrices más rápidos. La clave es mantener las colas y la latencia bajas en todos los discos.
Para lograr una disponibilidad y rendimiento altos (lectura/escritura aleatoria), configure la matriz para RAID 10.
Consulte al proveedor de hardware de almacenamiento o la documentación antes de configurar matrices RAID. Tenga en cuenta si sería ventajoso para la base de datos contar con un tiempo de respuesta de lectura aleatorio más rápido (por ejemplo, para el contenido web estático, donde RAID 5 y RAID 10 ofrecen un rendimiento similar). Por otra parte, un tiempo de respuesta de escritura aleatorio más rápido puede ser más importante (por ejemplo, en un sitio de colaboración con un uso mixto de lectura y escritura, donde RAID 10 tiene ventaja.
Al configurar una matriz RAID, es crucial alinear el sistema de archivos con el desplazamiento proporcionado por el proveedor. Si no puede obtener información del proveedor, vea la documentación sobre procedimientos recomendados para E/S previos a la implementación de SQL Server (en inglés) (https://go.microsoft.com/fwlink/?linkid=105583&clcid=0xC0A) (en inglés).
Para obtener más información acerca del aprovisionamiento de RAID y el subsistema E/S de SQL Server, vea el artículo sobre procedimientos recomendados de SQL Server (en inglés) (https://go.microsoft.com/fwlink/?linkid=168612&clcid=0xC0A) (en inglés).
Antes de implementar una nueva granja, recomendamos que establezca como referencia el subsistema de E/S mediante la herramienta de pruebas comparativas del subsistema de disco SQLIO. Para obtener más detalles, vea el tema sobre la herramienta de pruebas comparativas del subsistema de disco SQLIO (en inglés) (https://go.microsoft.com/fwlink/?linkid=105586&clcid=0xC0A) (en inglés).
Administre de forma proactiva el crecimiento de los archivos de datos y de registro
Ajuste previamente el tamaño de los archivos de datos y registro.
No se base en el crecimiento automático únicamente. En lugar de eso, administre de forma manual el crecimiento de los archivos de datos y de registro. Puede habilitar el crecimiento automático por motivos de seguridad, pero deberá administrar de manera proactiva el crecimiento de los archivos de datos y registro.
Configure los valores de crecimiento automático para adaptarlos a las necesidades de la implementación.
Cuando se planean bases de datos de contenido que superan el tamaño recomendado (100 GB), se debe establecer el valor de crecimiento automático de la base de datos en un número fijo de megabytes, en lugar de un porcentaje. Esto permite reducir la frecuencia con la que SQL Server aumenta el tamaño de un archivo. El aumento del tamaño del archivo es una operación de bloqueo que implica rellenar el nuevo espacio con páginas vacías.
Nota
SQL Server 2008 que se ejecuta en Windows Server 2003 es compatible con la inicialización de archivos instantánea. La inicialización de archivos instantánea puede reducir en gran medida el impacto de rendimiento de una operación de crecimiento de archivo. Para obtener más información, vea el tema sobre la inicialización de los archivos de la base de datos (https://go.microsoft.com/fwlink/?linkid=132063&clcid=0xC0A).
Cuando se planean bases de datos de contenido que no alcanzan el tamaño recomendado (100 GB), establezca el tamaño de las bases de datos en 100 GB cuando las cree mediante la propiedad ALTER DATABASE MAXSIZE.
Si el espacio en el disco es limitado o no se puede cambiar el tamaño de las bases de datos, deberá configurar el valor de crecimiento automático en un porcentaje fijo. Por ejemplo, configure el valor de crecimiento automático al 10% para las bases de datos con menos de 500 GB y a un número fijo de megabytes si las bases de datos superan los 500 GB.
Mantenga un nivel de al menos el 25 por ciento del espacio disponible entre discos para permitir el crecimiento y los patrones de uso máximo. Si administra el crecimiento agregando discos a una matriz RAID o asignando más almacenamiento, supervise el tamaño del disco para evitar quedarse sin espacio.
Limitación del tamaño de la base de datos de contenido para mejorar la facilidad de administración
Considere un tamaño de base de datos que permita mejorar la administración y el rendimiento del entorno.
Nota
Los límites recomendados solo se aplican a un servidor que está ejecutando SQL Server 2008 y que hospeda Microsoft Office SharePoint Server 2007, y no son una guía general para SQL Server 2008.
En la mayoría de los casos, para mejorar el rendimiento de Office SharePoint Server 2007 se recomienda no usar bases de datos de contenido de más de 100 GB. Si el diseño requiere una base de datos de más de 100 GB, siga estas instrucciones:
No use una base de datos superior a 100 GB para más de una colección de sitios.
Use una solución de copia de seguridad diferencial, como SQL Server 2008 o Microsoft System Center Data Protection Manager 2007, en lugar de las herramientas integradas de copia de seguridad y recuperación.
Pruebe el servidor que está ejecutando SQL Server 2008 y el subsistema de E/S antes de cambiar a una solución que dependa de una base de datos de contenido de 100 GB.
Limite las bases de datos de contenido que contengan varias colecciones de sitios a aproximadamente 100 GB.
Separación y asignación de prioridades a los datos en los discos
Se recomienda colocar la base de datos tempdb, las bases de datos de contenido y los registros de transacciones de SQL Server 2008 en discos duros físicos independientes.
En la siguiente lista se ofrecen algunos procedimientos recomendados y sugerencias para asignar prioridades a los datos.
Al asignar prioridades a los datos en discos más rápidos, use la siguiente clasificación:
Archivos de datos de tempdb y registros de transacciones
Registros de transacciones de base de datos
Base de datos de búsqueda
Archivos de datos de la base de datos
En un sitio del portal orientado principalmente a la lectura, asigne prioridad a los datos frente a los registros.
Las pruebas y los datos de los clientes han mostrado que el rendimiento de la granja de servidores de Office SharePoint Server 2007 se puede dificultar de forma significativa por una E/S de disco insuficiente para tempdb. Para evitar este problema, asigne discos dedicados para tempdb. Si se proyecta o supervisa una carga de trabajo alta [es decir, la operación de lectura media o la operación de escritura media requieren más de 20 milisegundos (ms)] es posible que deba quitar el cuello de botella separando los archivos en los discos o reemplazando los discos por discos más rápidos.
Para obtener un rendimiento óptimo, coloque tempdb en una matriz RAID 10. La cantidad de archivos de datos de tempdb debe ser igual a la cantidad de CPU de núcleo y los archivos de datos de tempdb se deben establecer en el mismo tamaño. Para ello, cuente los procesadores de doble núcleo como dos CPU. Cuente cada procesador compatible con la tecnología hyper-threading como una única CPU. Para obtener más información, vea el tema en el que se explica cómo optimizar el rendimiento de tempdb (https://go.microsoft.com/fwlink/?linkid=148537&clcid=0xC0A).
Separe los datos de la base de datos y los archivos de registros de transacciones en diferentes discos. Si los archivos deben compartir discos porque son demasiado pequeños para aprovechar un disco completo o una banda, o bien no dispone de espacio en el disco, coloque los archivos que tengan patrones de uso diferentes en el mismo disco para minimizar las solicitudes de acceso simultáneas.
Consulte al proveedor de hardware de almacenamiento acerca de cómo configurar todos los registros y las bases de datos de búsqueda para optimizar la escritura para su solución de almacenamiento particular.
Asigne ejes dedicados para la base de datos de búsqueda.
Uso de varios archivos de datos para bases de datos de contenido grandes y la base de datos de búsqueda del SSP
Para mejorar el rendimiento de las bases de datos de contenido grandes, considere la posibilidad de usar varios archivos de datos.
Nota
-
No se admite el uso de varios archivos de datos para bases de datos que no sean de contenido ni la base de datos de búsqueda del SSP.
-
Las bases de datos de Productos y Tecnologías de SharePoint no admiten el uso de particiones de SQL Server. Use sólo archivos de datos simples.
Uso de varios archivos de datos para bases de datos de contenido
Siga estas recomendaciones para obtener el mejor rendimiento:
Sólo cree archivos en el grupo de archivos principal de la base de datos.
Distribuya los archivos en discos independientes.
El número de archivos de datos debe ser menor o igual que el número de CPU de núcleo. Con este fin, cuente los procesadores de doble núcleo como dos CPU. Cuente cada procesador compatible con la tecnología Hyper-Threading como una única CPU.
Cree archivos de datos que tengan el mismo tamaño.
Importante
Aunque las herramientas de copia de seguridad y recuperación integradas en Productos y Tecnologías de SharePoint se pueden usar para realizar copias de seguridad de varios archivos de datos y recuperarlos, si sobrescribe en la misma ubicación, las herramientas no pueden restaurar varios archivos de datos en una ubicación diferente. Por este motivo, se recomienda que al usar varios archivos de datos para una base de datos de contenido, use las herramientas de copia de seguridad y recuperación de SQL Server. Para obtener más información acerca de cómo realizar copias de seguridad y recuperación de Office SharePoint Server 2007, vea Elección de herramientas de copia de seguridad y recuperación (Office SharePoint Server).
Para obtener más información acerca de la creación y administración de grupos de archivos, vea el tema sobre grupos de archivos y archivos de bases de datos físicas
Uso de varios archivos de datos para la base de datos de búsqueda del SSP
Para la base de datos de búsqueda, se recomienda usar grupos de archivos para segregar las tablas que se usan principalmente para el procesamiento de consultas y rastreo. El grupo de archivos que hospeda las tablas más afectadas por el rastreo se debe mover a un conjunto de ejes distinto del grupo de archivos principal, para reducir al máximo el impacto en el subsistema de E/S.
Las tablas de base de datos que se enumeran en la siguiente tabla están relacionadas principalmente con el rastreo.
MSSAnchorChangeLog |
MSSCrawlDeletedErrorList |
MSSAnchorPendingChangeLog |
MSSCrawlDeletedURL |
MSSAnchorText |
MSSCrawlErrorList |
MSSAnchorTransactions |
MSSCrawlHostList |
MSSCrawlChangedSourceDocs |
MSSCrawlQueue |
MSSCrawlChangedTargetDocs |
MSSCrawlURL |
MSSCrawlContent |
MSSCrawlURLLog |
MSSTranTempTable0 |
Importante
Se encuentran disponibles secuencias de comando o scripts de Transact-SQL para mover estas tablas a un grupo de archivos. Estos scripts son el único mecanismo compatible para mover las tablas relacionadas con el rastreo. Los scripts se incluyen en la entrada de blog sobre (https://blogs.msdn.com/error.htm?aspxerrorpath=/blogs/post.aspx), que se publicó en el blog sobre Microsoft Enterprise Search.
Siga estas recomendaciones para obtener el mejor rendimiento para las bases de datos de búsqueda:
Mueva las tablas fuera del grupo de archivos principal para la base de datos.
Distribuya los archivos en discos independientes.
Importante
El proceso de mover las tablas a un nuevo grupo de archivos es demasiado costoso y puede tardar horas en completarse, dado que implica soltar y volver a crear muchos índices agrupados. Tenga en cuenta que la base de datos estará sin conexión durante el traslado.
Problemas conocidos
En las siguientes secciones se describen problemas conocidos al usar grupos de archivos para la base de datos de búsqueda.
Copia de seguridad y restauración
La copia de seguridad y la restauración en Productos y Tecnologías de SharePoint no tienen en cuenta los grupos de archivos. No hay forma de indicar dónde se debe restaurar el nuevo grupo de archivos. El proceso de restauración intenta colocar el grupo de archivos de rastreo en la misma unidad en la que se encontraba cuando se realizó la copia de seguridad. Para la restauración, debe disponer de unidades para los grupos de archivos principales y de rastreo con la misma letra de unidad que la de la unidad de copia de seguridad inicial.
Futuras actualizaciones, Service Pack y revisiones
Cada actualización, Service Pack y revisión que se aplica al servidor tiene el potencial de modificar el índice que se movió al grupo de archivos de rastreo o de agregar un nuevo índice a una de las tablas que se movió al grupo de archivos. Si esto ocurre, el índice se volverá a mover o a crear en el grupo de archivos principal.
Debido al riesgo de modificación de índices, después de aplicar una actualización deberá repetir el proceso de mover las tablas al grupo de archivos mediante la ejecución de los scripts que se proporcionan en el blog de Enterprise Search.
Requiere al menos SQL Server 2005, se prefiere SQL Server 2008
El script que se utiliza para mover los índices usa características que se publicaron en SQL Server 2005 y que se continuaron en SQL Server 2008. Esta optimización se puede realizar sólo si está ejecutando SQL Server 2005 o una versión posterior.
Siga las recomendaciones de configuración del proveedor
Para obtener un rendimiento óptimo al configurar una matriz de almacenamiento física, siga las recomendaciones de configuración del hardware proporcionadas por el proveedor de almacenamiento en lugar de basarse en los valores predeterminados del sistema operativo.
Si no obtiene instrucciones del proveedor, se recomienda que emplee la utilidad de configuración de disco DiskPart.exe para configurar el almacenamiento de SQL Server 2008. Para obtener más información, vea el documento sobre los procedimientos recomendados para E/S previos a la implementación (en inglés) (https://go.microsoft.com/fwlink/?linkid=105583&clcid=0xC0A) (en inglés).
Descarga de este libro
Este tema se incluye en el siguiente libro, el cual se puede descargar para facilitar la lectura y la impresión:
- Planeación y arquitectura para Office SharePoint Server 2007, parte 2 (https://go.microsoft.com/fwlink/?linkid=85548&clcid=0xC0A)
Vea la lista completa de libros disponibles en el contenido para descargar para Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=89172&clcid=0xC0A).