Exportar (0) Imprimir
Expandir todo

Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010)

 

Se aplica a: SharePoint Foundation 2010, SharePoint Server 2010

Última modificación del tema: 2015-02-27

En este artículo se describe cómo planear y configurar el almacenamiento y el nivel de base de datos de Microsoft SQL Server en un entorno de Microsoft SharePoint Server 2010.

La información acerca de la planeación de la capacidad que se incluye en este documento ofrece instrucciones para tener en cuenta durante la tarea de planeación. Esta información se basa en las pruebas realizadas en Microsoft con propiedades activas. No obstante, los resultados que se obtengan pueden variar en función de los equipos que utilice y según las características y la funcionalidad que implemente en sus sitios.

Dado que SharePoint Server a menudo se ejecuta en entornos en los que las bases de datos se administran mediante administradores independientes de SQL Server, este documento está pensado tanto para implementadores de granja de servidores de SharePoint Server, como para administradores de bases de datos de SQL Server. Se le suponen unos amplios conocimientos acerca de SharePoint Server y SQL Server.

En este artículo se asume que está familiarizado con los conceptos presentados en Administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

Varios factores de la arquitectura de SharePoint Server 2010 influyen en el diseño del almacenamiento. La cantidad de contenido, características y aplicaciones de servicio que se usan, el número de granjas de servidores y las necesidades de disponibilidad son factores clave.

Antes de empezar a planear el almacenamiento, debe conocer las bases de datos que SharePoint Server 2010 puede utilizar.

En esta sección:

Las bases de datos que se instalan con SharePoint Server 2010 dependen de las características que se encuentran en uso en el entorno. Todos los entornos de Productos de SharePoint 2010 se basan en las bases de datos del sistema de SQL Server. En esta sección se proporciona un resumen de las bases de datos que se instalan con SharePoint Server 2010. Para obtener información más detallada, vea Tipos y descripciones de bases de datos (SharePoint Server 2010) y el tema sobre el modelo de base de datos (http://go.microsoft.com/fwlink/p/?LinkId=187968).

 

Versión y edición del producto Bases de datos

SharePoint Foundation 2010

Configuración

Contenido de Administración central

Contenido (uno o más)

Recolección de datos de mantenimiento y uso

Conectividad a datos empresariales

Servicio de registro de aplicaciones (si se actualiza desde el Catálogo de datos profesionales de Microsoft Office SharePoint Server 2007)

Servicio de configuración de suscripción (si se habilita mediante Windows PowerShell)

Bases de datos adicionales para SharePoint Server 2010 Standard Edition

Aplicación de servicio de búsqueda:

  • Administración de búsqueda

  • Rastreo (uno o más)

  • Propiedad (una o más)

Aplicación de servicio de perfiles de usuario:

  • Perfil

  • Sincronización

  • Etiquetas temáticas

Aplicación de servicio de Web Analytics

  • Almacenamiento provisional

  • Informes

Almacenamiento seguro

Estado

Metadados administrados

Servicios de automatización de Word

Bases de datos adicionales para SharePoint Server 2010 Enterprise Edition

PerformancePoint

Bases de datos adicionales para Project Server 2010

Borrador

Publicada

Archivar

Informes

Bases de datos adicionales para FAST Search Server

Administración de búsqueda

Si realiza una integración más completa con SQL Server, su entorno podrá incluir bases adicionales, como en los siguientes escenarios:

  • Microsoft SQL Server 2008 R2 PowerPivot para Microsoft SharePoint 2010 se puede usar en un entorno de SharePoint Server 2010 que incluya SQL Server 2008 R2 Enterprise Edition y SQL Server Analysis Services. Si está en uso, también debe planear la compatibilidad con la base de datos de la aplicación PowerPivot y la carga adicional en el sistema. Para obtener más información, vea el tema sobre cómo planear una implementación de PowerPivot en una granja de servidores de SharePoint (http://go.microsoft.com/fwlink/p/?LinkID=186698).

  • El complemento Microsoft SQL Server 2008 Reporting Services (SSRS) puede usarse con todos los entornos de los productos de SharePoint 2010. Si usa el complemento, planee la compatibilidad con las dos bases de datos de SQL Server 2008 Reporting Services y la carga adicional que se necesita para SQL Server 2008 Reporting Services.

En cualquier servidor que hospede SQL Server, es muy importante que el servidor logre la respuesta más rápida posible del subsistema de E/S.

Una mayor cantidad de matrices o discos más rápidos proporcionan suficientes operaciones de entrada y salida por segundo (IOPS) y a la vez se mantiene una baja latencia y puesta en cola en todos los discos.

La respuesta lenta del subsistema de E/S no puede compensarse con la adición de otros tipos de recursos, como CPU o memoria; no obstante, este tipo de respuesta puede influir y causar problemas en toda la granja de servidores. Planee una latencia mínima antes de la implementación y supervise los sistemas existentes.

Antes de implementar una nueva granja de servidores, se recomienda realizar una prueba comparativa del subsistema de E/S mediante la herramienta de pruebas comparativas del subsistema de disco SQLIO. Para obtener más información, vea el tema sobre la herramienta de pruebas comparativas del subsistema de disco SQLIO (http://go.microsoft.com/fwlink/p/?LinkID=105586).

Para obtener más información acerca de la forma de analizar los requisitos de las operaciones IOPS desde una perspectiva de SQL Server, vea el tema sobre el análisis de las características de E/S y determinación del tamaño de los sistemas de almacenamiento para aplicaciones de bases de datos de SQL Server (http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).

La configuración y el almacenamiento de contenido, así como las operaciones IOPS, constituyen la capa base que debe planear en toda implementación de SharePoint Server 2010.

No son muchos los requisitos de almacenamiento para la base de datos de configuración y la base de datos de contenido de Administración central. Se recomienda asignar 2 GB para la base de datos de configuración y 1 GB para la base de datos de contenido de Administración central. Con el tiempo, la base de datos de configuración puede crecer más de 1 GB, pero no lo hace rápidamente, aumenta alrededor de 40 MB por cada 50.000 colecciones de sitios. 

Los registros de transacciones de la base de datos de configuración pueden ser grandes; por lo tanto, se recomienda cambiar el modelo de recuperación de la base de datos, de completa a simple.

NotaNote
Si desea usar la creación de reflejo de la base de datos de SQL Server para proporcionar disponibilidad para la base de datos de configuración, debe usar el modelo de recuperación completa.

Son mínimos los requisitos de las operaciones IOPS para la base de datos de configuración y la base de datos de contenido de Administración central.

Estimar el almacenamiento y las operaciones IOPS necesarias para las bases de datos de contenido no es una actividad de precisión. Las pruebas y las explicaciones de la siguiente información están pensadas para ayudarle a calcular las estimaciones que luego usará para determinar el tamaño inicial de su implementación. No obstante, cuando el entorno esté en ejecución, deberá revisar las necesidades de capacidad en función de los datos obtenidos en el entorno activo.

Para obtener más información acerca de nuestra metodología de planificación de la capacidad total, vea Administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

El siguiente proceso describe cómo estimar aproximadamente el almacenamiento necesario para las bases de datos de contenido, sin tener en cuenta los archivos de registro:

  1. Calcule el número esperado de documentos. Este valor se denomina D en la fórmula.

    La forma de calcular el número de documentos estará determinada por las características que se usen. Por ejemplo, para Mis sitios o sitios de colaboración, se recomienda calcular el número esperado de documentos por usuario y multiplicarlo por el número de usuarios. Para la administración de registros o sitios de publicación de contenido, se puede calcular el número de documentos administrados y generados por un proceso.

    Si va a migrar desde un sistema actual, puede que sea más fácil extrapolar la tasa de crecimiento actual y el uso. Si va a crear un nuevo sistema, revise los recursos compartidos de archivos existentes u otros repositorios y realice la estimación en función de esa tasa de uso.

  2. Estime el tamaño promedio de los documentos que va a almacenar. Este valor se denomina S en la fórmula. Puede ser útil estimar los promedios de distintos tipos o grupos de sitios. El tamaño promedio de archivo de Mis sitios, de los repositorios de medios y los portales de los distintos departamentos puede variar considerablemente.

  3. Estime el número de elementos de lista en el entorno. Este valor se denomina L en la fórmula.

    Es más difícil estimar los elementos de lista que los documentos. Normalmente, se usa una estimación de tres veces el número de documentos (D), pero esto variará en función de cómo piensa usar los sitios.

  4. Determine el número aproximado de versiones. Estime el número promedio de versiones que tendrá cualquier documento de una biblioteca (por lo general, este valor será mucho menor que el número máximo de versiones permitido). Este valor se denomina V en la fórmula.

    El valor de V debe ser superior a cero.

  5. Utilice la siguiente fórmula para calcular el tamaño de las bases de datos de contenido:

    Tamaño de base de datos = ((D × V) × S) + (10 KB × (L + (V × D)))

    El valor de 10 KB en la fórmula es una constante que estima la cantidad aproximada de metadatos requeridos por SharePoint Server 2010. Si el sistema requiere un uso importante de metadatos, quizás desee incrementar esta constante.

Por ejemplo, si desea utilizar la fórmula para calcular la cantidad de espacio de almacenamiento necesario para los archivos de datos de una base de datos de contenido en un entorno de colaboración con las siguientes características, necesitará aproximadamente 105 GB.

 

Entrada Valor

Número de documentos (D)

200.000

Calculado suponiendo 10.000 usuarios multiplicado por 20 documentos

Tamaño promedio de documentos (S)

250 KB

Elementos de lista (L)

600.000

Número de versiones no actuales (V)

2

Suponiendo que el número máximo de versiones es 10

Tamaño de base de datos = (((200.000 x 2)) × 250) + ((10 KB × (600.000 + (200.000 x 2))) = 110.000.000 KB o 105 GB

El uso de las siguientes características de SharePoint Server 2010 puede afectar significativamente el tamaño de las bases de datos de contenido:

  • Papeleras de reciclaje   Hasta que un documento no se elimine completamente de la papelera de reciclaje, tanto de la primera como de la segunda etapa, ocupa espacio en una base de datos de contenido. Calcule cuántos documentos se eliminan por mes para determinar el efecto que tienen las papeleras de reciclaje en el tamaño de las bases de datos de contenido. Para obtener más información, vea Configuración de las opciones de la papelera de reciclaje (SharePoint Server 2010).

  • Auditoría   Los datos de auditoría pueden aumentar rápidamente y usar grandes cantidades de espacio en una base de datos de contenido, especialmente si se activa la vista de auditoría. En lugar de permitir que los datos de auditoría crezcan sin restricciones, se recomienda que solo habilite la auditoría en eventos importantes para satisfacer las necesidades reglamentarias o realizar controles internos. Use las instrucciones siguientes para calcular el espacio que necesitará reservar para la auditoría de datos:

    • Estime el número de nuevas entradas de auditoría para un sitio y multiplique ese número por 2 KB (por lo general, las entradas se limitan a 4 KB, con un tamaño promedio de alrededor de 1 KB).

    • En función del espacio que desee asignar, determine el número de días de los registros de auditoría que desea conservar.

  • Office Web Apps. Si se usa Office Web Apps, la memoria caché de Office Web Apps puede afectar considerablemente el tamaño de una base de datos de contenido. De manera predeterminada, la memoria caché de Office Web Apps se configura en 100 GB. Para obtener más información acerca el tamaño de la memoria caché de Office Web Apps, vea Administración de la memoria caché de Office Web Apps.

Los requisitos de IOPS para bases de datos de contenido varían considerablemente en función de la forma en que se usa el entorno, el espacio disponible en disco y el número de servidores que existen. En general, se recomienda que compare la carga de trabajo prevista en el entorno con una de las soluciones que se han probado. Para obtener más información, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

ImportanteImportant
Las pruebas para el contenido de esta sección aún no se han completado. Vuelva a consultar para obtener más información.

Después de calcular la necesidades de almacenamiento de contenido y operaciones IOPS, a continuación, debe determinar el almacenamiento y las operaciones IOPS que se necesitan para las aplicaciones de servicio que se usan en el entorno.

Para calcular los requisitos de almacenamiento para las aplicaciones de servicio del sistema, deberá, en primer lugar, conocer las aplicaciones de servicio y discernir cómo las usará. Las aplicaciones de servicio disponibles en SharePoint Server 2010 que tienen bases de datos se enumeran en la siguiente tabla.

 

Aplicación de servicio Recomendación de cálculo de tamaño

Búsqueda

La búsqueda requiere tres bases de datos. El entorno podría incluir varias bases de datos de rastreo y propiedades.

La base de datos de administración de búsqueda normalmente es pequeña: asigne 10 GB.

Para estimar el almacenamiento necesario para las bases de datos de rastreo y propiedades, use los siguientes multiplicadores:

  • Rastreo: 0,046 x (suma de las bases de datos de contenido)

  • Propiedad: 0,015 x (suma de las bases de datos de contenido)

Los requisitos de IOPS para la búsqueda son importantes.

  • Para la base de datos de rastreo, la búsqueda requiere de 3.500 a 7.000 IOPS.

  • Para la base de datos de propiedades, la búsqueda requiere 2.000 IOPS.

Para obtener información detallada acerca de cómo calcular la capacidad necesaria para realizar búsquedas, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

FAST Search Server 2010 for SharePoint tiene una arquitectura distinta. La base de datos de rastreo tiene los mismos requisitos previos de IOPS, pero la base de datos de propiedades únicamente se utiliza para buscar personas y existe una base de datos de administración de búsqueda adicional. Para obtener información detallada acerca de FAST Search Server 2010 for SharePoint, consulte Planeación de la topología de la granja de servidores (FAST Search Server 2010 for SharePoint) (traducción automática) y Performance and capacity management (FAST Search Server 2010 for SharePoint).

Perfil de usuario

La aplicación de servicio de perfiles de usuario está asociada con las bases de datos de perfiles, de sincronización y de etiquetas temáticas.

Para calcular el almacenamiento necesario para las bases de datos, use la siguiente información:

  • Perfiles. Con la configuración predeterminada, en un entorno configurado para usar Active Directory, la base de datos de perfil requiere aproximadamente 1 MB por cada perfil de usuario.

  • Sincronización. Con la configuración predeterminada, en un entorno con pocos grupos por usuario, la base de datos de sincronización requiere aproximadamente 630 KB por cada perfil de usuario. El archivo de datos ocupará el 90% del espacio.

  • Etiquetas temáticas. Con la configuración predeterminada, la base de datos de etiquetas temáticas requiere aproximadamente 0,009 MB por cada etiqueta, comentario o clasificación. Para calcular el número de etiquetas y notas que los usuarios crearán, tenga en cuenta la siguiente información acerca del sitio del.icio.us:

    • Aproximadamente el 10% de los usuarios se considera activo.

    • Los usuarios activos crean 4,5 etiquetas y 1,8 comentarios por mes.

En un entorno de colaboración en directo con 160.000 perfiles de usuario, 5 grupos, 79.000 etiquetas, comentarios y clasificaciones (2.500 comentarios, 76.000 etiquetas y 800 clasificaciones), y configuración predeterminada, se han visto los siguientes tamaños para estas bases de datos:

 

Nombre de la base de datos Tamaño de la base de datos

Perfiles

155 Gigabytes (GB)

Sincronización

96 Gigabytes (GB)

Etiquetas temáticas

0,66 Gigabytes (GB)

Metadatos administrados

La aplicación de servicio de metadatos administrados tiene una sola base de datos. El tamaño de la base de datos se ve afectado por el número de tipos de contenido y palabras clave utilizados en el sistema. Muchos entornos incluirán varias instancias de la aplicación de servicio de metadatos administrados.

Web Analytics

Web Analytics tiene dos bases de datos: provisional y de informes. Son muchos los factores que influyen en el tamaño de las bases de datos; entre ellos, el período de retención, el volumen diario de datos con seguimiento y la cantidad de colecciones de sitios, sitios y subsitios de la aplicación web que se va a analizar. Para obtener más información acerca de cómo calcular el tamaño y los requisitos de IOPS, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

Almacenamiento seguro

El tamaño de la base de datos de la aplicación de servicio de almacenamiento seguro está determinado por el número de credenciales en el almacén y el número de entradas en la tabla de auditoría. Se recomienda asignar 5 MB para cada 1.000 credenciales para la base de datos. Los requisitos de IOPS son mínimos.

Estado

La aplicación de servicio de estado tiene una sola base de datos. Se recomienda asignar 1 GB para la base de datos. Los requisitos de IOPS son mínimos.

Servicio de automatización de Word

La aplicación de servicio de automatización de Word tiene una sola base de datos. Se recomienda asignar 1 GB para la base de datos. Los requisitos de IOPS son mínimos.

PerformancePoint

La aplicación de servicio de PerformancePoint tiene una sola base de datos. Se recomienda asignar 1 GB para la base de datos. Los requisitos de IOPS son mínimos.

La disponibilidad es el grado en el que los usuarios perciben que un entorno de SharePoint Server 2010 está disponible. Un sistema disponible es un sistema que es resistente (es decir, los incidentes que afectan al servicio no son frecuentes y, cuando suceden, se buscan soluciones a tiempo y efectivas).

Los requisitos de disponibilidad pueden aumentar significativamente las necesidades de almacenamiento. Para obtener información detallada, vea Planeación de disponibilidad (SharePoint Server 2010).

Aunque Productos de SharePoint 2010 se puede ejecutar en Microsoft SQL Server 2008 R2, SQL Server 2008 o SQL Server 2005, es muy recomendable considerar la posibilidad de que el entorno se ejecute en la edición Enterprise de SQL Server 2008 o SQL Server 2008 R2 para aprovechar las capacidades adicionales de rendimiento, disponibilidad, seguridad y administración que proporciona. Para obtener más información acerca de las ventajas de utilizar SQL Server 2008 R2 Enterprise Edition, vea SQL Server 2008 R2 y productos de SharePoint 2010: mejor juntos (notas del producto) (SharePoint Server 2010).

En concreto, debe tener en cuenta la necesidad de las siguientes características:

  • Compresión de copia de seguridad   La compresión de copia de seguridad puede acelerar cualquier copia de seguridad de SharePoint y está disponible en SQL Server 2008 Enterprise Edition o SQL Server 2008 R2 Standard Edition. Si se configura la opción de compresión en el script de copia de seguridad o si se configura el servidor que ejecuta SQL Server para comprimir de manera predeterminada, se puede reducir significativamente el tamaño de las copias de seguridad de bases de datos y registros de envío. Para obtener más información, vea el tema sobre compresión de copia de seguridad (SQL Server) (http://go.microsoft.com/fwlink/p/?LinkId=129381).

    NotaNote
    La compresión de datos de SQL Server no es compatible con Productos de SharePoint 2010, con la excepción de las bases de datos de aplicación de servicio de búsqueda.
  • Cifrado de datos transparente   Si los requisitos de seguridad incluyen la necesidad de cifrado de datos transparente, se debe usar SQL Server Enterprise Edition.

  • Aplicación de servicio de Web Analytics   Si va a utilizar la aplicación de servicio de Web Analytics para realizar un análisis significativo, considere la posibilidad de usar SQL Server Enterprise Edition, de modo tal que el sistema pueda aprovechar las ventajas de la partición de tabla.

  • Distribución de contenido Si va a utilizar la característica de distribución de contenido, considere la posibilidad de usar SQL Server Enterprise Edition, de modo que el sistema pueda aprovechar las instantáneas de base de datos de SQL Server.

  • Almacenamiento remoto de blobs   Si desea aprovechar las ventajas del almacenamiento remoto de blobs en una base de datos o ubicación fuera de los archivos asociados con cada base de datos de contenido, debe usar SQL Server 2008 o SQL Server 2008 R2 Enterprise Edition.

  • Regulador de recursos   El regulador de recursos es una tecnología que se incluyó por primera vez en SQL Server 2008 y que permite administrar los recursos y las cargas de trabajo de SQL Server, especificando los límites en el consumo de recursos para las solicitudes entrantes. El regulador de recursos permite diferenciar las cargas de trabajo y asignar la CPU y memoria que se solicitan, según los límites especificados. Está disponible solo en SQL Server 2008 o SQL Server 2008 R2 Enterprise Edition. Para obtener más información acerca de cómo usar el regulador de recursos, vea el tema sobre la administración de cargas de trabajo de SQL Server con el regulador de recursos.

    Se recomienda usar el regulador de recursos con SharePoint Server 2010 para llevar a cabo las siguientes tareas:

    • Limitar la cantidad de recursos de SQL Server que consumen los servidores web de destino mediante el componente de rastreo de búsqueda. Como procedimiento recomendado, limite el componente de rastreo al 10 por ciento de CPU cuando el sistema esté bajo carga.

    • Supervisar la cantidad de recursos consumida por cada base de datos en el sistema; por ejemplo, puede utilizar el regulador de recursos para ayudarle a determinar la mejor ubicación de las bases de datos entre equipos que ejecutan SQL Server.

  • PowerPivot para SharePoint 2010 Permite a los usuarios compartir y colaborar en los modelos de datos generados por el usuario y el análisis en Excel y en el explorador mientras se actualiza automáticamente esos análisis. Forma parte de Analysis Services de SQL Server 2008 R2 Enterprise Edition.

Los tipos de disco y la arquitectura de almacenamiento que seleccione para su entorno podrán afectar al rendimiento del sistema.

En esta sección:

Las arquitecturas de almacenamiento directo (DAS), red de área de almacenamiento (SAN) o almacenamiento conectado a la red (NAS) son compatibles con SharePoint Server 2010, aunque NAS se admite únicamente con bases de datos de contenido configuradas para usar almacenamiento remoto de blobs. La elección depende de factores de la solución de negocio y de la infraestructura existente.

Cualquier arquitectura de almacenamiento debe admitir las necesidades de disponibilidad y tener un rendimiento adecuado con respecto a IOPS y latencia. Para que sea compatible, el sistema siempre debe devolver el primer byte de datos dentro de los 20 milisegundos (ms).

DAS es un sistema de almacenamiento digital que está conectado directamente a un servidor o estación de trabajo, sin una red de almacenamiento intermedia. Los tipos de disco físico de DAS incluyen Serial Attached SCSI (SAS) y Serial Attached ATA (SATA).

En general, se recomienda que elija una arquitectura DAS cuando una plataforma de almacenamiento compartido no pueda garantizar un tiempo de respuesta de 20 ms y una capacidad suficiente para el promedio y máximo de IOPS.

SAN es una arquitectura de conexión de dispositivos de almacenamiento de equipos remotos (como matrices de discos o bibliotecas de cintas) con servidores, de modo que los dispositivos aparezcan localmente conectados al sistema operativo (por ejemplo, almacenamiento de bloques).

En general, se recomienda que elija una SAN si las ventajas del almacenamiento compartido son importantes para su organización.

Las ventajas del almacenamiento compartido son:

  • Es más fácil reasignar el almacenamiento en disco entre los servidores.

  • Puede dar servicio a varios servidores.

  • No hay limitación en la cantidad de discos a los que se puede tener acceso.

Una unidad NAS es un equipo independiente que está conectado a una red. Su único propósito es proporcionar servicios de almacenamiento de datos de archivo a otros dispositivos de la red. El sistema operativo y otro software de la unidad NAS proporcionan la funcionalidad de almacenamiento de datos, sistemas de archivos y acceso a archivos, así como la administración de estas funcionalidades (por ejemplo, el almacenamiento de archivos).

NotaNote
NAS solo es compatible con bases de datos de contenido configuradas para usar el almacenamiento remoto de blobs. Cualquier arquitectura de almacenamiento de red debe responder a un ping en menos de 1 ms y debe devolver el primer byte en menos de 20 ms. Esta restricción no se aplica al proveedor local de FILESTREAM de SQL Server porque éste solo almacena datos localmente en el mismo servidor.

Los tipos de disco que se utilizan en el sistema pueden afectar al rendimiento y la confiabilidad. Siendo todo lo demás igual, unidades más grandes aumentan la media del tiempo de búsqueda. SharePoint Server 2010 admite los siguientes tipos de unidades:

  • Interfaz estándar de equipos pequeños (SCSI)

  • Serial Advanced Technology Attachment (SATA)

  • SCSI conectados en serie (SAS)

  • Canal de fibra (FC)

  • Electrónica integrada de dispositivos (IDE)

  • Unidad de estado sólido (SSD) o disco Flash

RAID (matriz redundante de discos independientes) a menudo se utiliza para mejorar las características de rendimiento de los discos individuales (mediante la selección de datos de varios discos) y para proporcionar protección frente a errores de discos individuales.

Todos los tipos de RAID son compatibles con SharePoint Server 2010; no obstante, se recomienda usar RAID 10 o una solución RAID específica del proveedor con rendimiento equivalente.

Cuando configure una matriz RAID, asegúrese de alinear el sistema de archivos con el desplazamiento proporcionado por el proveedor. Si no puede obtener información del proveedor, vea el tema sobre los procedimientos recomendados de entrada y salida antes de la implementación de SQL Server (http://go.microsoft.com/fwlink/p/?LinkID=105583).

Para obtener más información acerca del aprovisionamiento de RAID y el subsistema de entrada y salida de SQL Server, vea el artículo sobre los procedimientos recomendados de SQL Server (http://go.microsoft.com/fwlink/p/?LinkId=168612).

La memoria necesaria para SharePoint Server 2010 está directamente relacionada con el tamaño de las bases de datos de contenido que se hospedan en un servidor que ejecuta SQL Server.

A medida que agrega aplicaciones de servicio y características, es probable que los requisitos aumenten. La siguiente tabla proporciona instrucciones sobre la cantidad de memoria recomendada.

NotaNote
Nuestras definiciones de implementaciones pequeñas y medianas se describen en la sección Arquitecturas de referencia del artículo Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

 

Tamaño combinado de bases de datos de contenido RAM recomendado para el equipo que ejecuta SQL Server

Mínimo para implementaciones pequeñas de producción

8 Gigabytes (GB)

Mínimo para implementaciones medianas de producción

16 Gigabytes (GB)

Recomendación de hasta 2 terabytes

32 Gigabytes (GB)

Recomendación para el intervalo de 2 terabytes a 5 terabytes

64 Gigabytes (GB)

Recomendación para más de 5 terabytes

Una memoria RAM adicional sobre los 64 GB puede mejorar la velocidad de almacenamiento en caché de SQL Server

NotaNote
Estos valores son superiores a los que se recomiendan como valores mínimos para SQL Server debido a la distribución de datos necesaria para un entorno de SharePoint Server 2010. Para obtener más información acerca de los requisitos del sistema de SQL Server, vea el tema acerca de los requisitos de hardware y software para instalar SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=129377).

Entre otros factores que pueden influir en la memoria necesaria se incluyen los siguientes:

  • El uso de la creación de reflejo de SQL Server.

  • El uso frecuente de archivos de más de 15 megabytes (MB).

Planee las conexiones de red dentro y entre granjas de servidores. Se recomienda usar una red que tenga una latencia baja.

En la siguiente lista se proporcionan algunos procedimientos recomendados y sugerencias:

  • Todos los servidores de la granja de servidores deben tener el ancho de banda de LAN y la latencia para el servidor que ejecuta SQL Server. La latencia no debe ser superior a 1 ms.

  • No se recomienda una topología de red de área extensa (WAN) en la que un servidor que ejecuta SQL Server se implementa remotamente desde otros componentes de la granja de servidores a través de una red que tiene una latencia mayor que 1 ms. Esta topología no se ha probado.

  • Planee una red WAN adecuada si tiene pensado usar el trasvase de registros o la creación de reflejo de SQL Server para mantener un sitio remoto actualizado.

  • Se recomienda que los servidores web y los servidores de aplicaciones tengan dos adaptadores de red: un adaptador de red para controlar el tráfico de usuario final y el otro para controlar la comunicación con los servidores que ejecutan SQL Server.

Las secciones siguientes describen cómo planear la configuración de SQL Server para SharePoint Server 2010.

En esta sección:

En general, SharePoint Server 2010 se ha diseñado para aprovechar las ventajas del escalado horizontal de SQL Server,  es decir, SharePoint Server 2010 tendrá un mejor rendimiento con un gran número de servidores medianos que ejecutan SQL Server que con solo unos pocos servidores grandes.

Coloque siempre SQL Server en un servidor dedicado que no esté ejecutando ningún otro rol de granja de servidores ni que hospede bases de datos de cualquier otra aplicación, a menos que vaya a implementar el sistema en un servidor independiente.

A continuación se brinda una guía general sobre cuándo implementar un servidor adicional que ejecutará SQL Server:

  • Agregue un servidor de base de datos adicional si tiene más de cuatro servidores web que se ejecutan con plena capacidad.

  • Agregue un servidor de bases de datos adicional cuando su servidor actual haya llegado a sus límites de eficacia de recursos en relación a RAM, CPU, rendimiento de entrada y salida de disco, capacidad de disco o rendimiento de red.

NotaNote
Microsoft admite configuraciones de servidores que no siguen esta guía.

Para promover el almacenamiento seguro de credenciales cuando se ejecuta la aplicación del servicio de almacenamiento seguro, se recomienda que la base de datos de almacenamiento seguro se hospede en una instancia independiente de la base de datos donde el acceso esté limitado a un solo administrador.

En el servidor que ejecuta SQL Server 2008, se recomienda que la memoria caché de nivel 2 por cada CPU tenga un mínimo de 2 MB para mejorar la memoria.

Para obtener un rendimiento óptimo cuando se configura una matriz de almacenamiento físico, siga las recomendaciones de configuración de hardware suministradas por el proveedor de almacenamiento en lugar de depender de los valores predeterminados del sistema operativo.

En caso de no contar con la supervisión guiada del proveedor, se recomienda configurar el almacenamiento para SQL Server 2008 mediante la utilidad de configuración de disco DiskPart.exe. Para obtener más información, vea el tema sobre los procedimientos recomendados de entrada y salida antes de la implementación (http://go.microsoft.com/fwlink/p/?LinkID=105583).

Asegúrese de que los canales de entrada y salida de SQL Server a los discos no estén compartidos con otras aplicaciones, como el archivo de paginación y los registros de Internet Information Services (IIS).

Proporcione el mayor ancho de banda de bus posible. Un mayor ancho de banda de bus ayuda a mejorar la confiabilidad y el rendimiento. Tenga en cuenta que el disco no es el único usuario de ancho de banda de bus, por ejemplo, también debe tener en cuenta el acceso a la red.

Es necesario configurar los siguientes parámetros y opciones de SQL Server antes de implementar SharePoint Server.

  • No habilite la creación automática de estadísticas en un sistema SQL Server que admite SharePoint Server. SharePoint Server configura las opciones necesarias al aprovisionar y actualizar. La creación automática de estadísticas puede cambiar considerablemente el plan de ejecución de una consulta, de una instancia de SQL Server a otra instancia de SQL Server. Por lo tanto, para suministrar soporte coherente para todos los clientes, SharePoint Server proporciona el código de las sugerencias para las consultas según sea necesario para proporcionar el mejor rendimiento a través de todos los escenarios. 

  • Para asegurar un óptimo rendimiento, se recomienda encarecidamente establecer el grado máximo de paralelismo (MAXDOP) en 1 instancia de SQL Server que hospede bases de datos de SharePoint Server 2010. Para obtener más información acerca de cómo establecer el grado máximo de paralelismo, vea el tema sobre la opción max degree of parallelism (http://go.microsoft.com/fwlink/p/?LinkId=189030).

  • Para facilitar el mantenimiento, configure los alias de conexión de SQL Server para cada servidor de base de datos en su granja de servidores. Un alias de conexión es un nombre alternativo que puede usarse para conectarse a una instancia de SQL Server. Para obtener más información, vea el tema sobre el procedimiento para establecer un alias de SQL Server (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkId=132064).

Las instrucciones siguientes describen los procedimientos recomendados para planear mientras se configura cada base de datos en el entorno.

Lo ideal es colocar la base de datos tempdb, las bases de datos de contenido, la base de datos de uso, las bases de datos de búsqueda 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:

  • Cuando asigne prioridades a los datos en discos más rápidos, use la siguiente clasificación:

    1. Archivos de datos tempdb y registros de transacciones

    2. Archivos de registro de transacciones de bases de datos

    3. Bases de datos de búsqueda, excepto la base de datos de administración de búsqueda

    4. Archivos de datos de las bases 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 SharePoint Server 2010 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 mejor rendimiento, 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 (http://go.microsoft.com/fwlink/p/?LinkID=148537).

  • Separe los datos de la base de datos y los archivos de registro 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 en su solución de almacenamiento particular.

Siga estas recomendaciones para obtener el mejor rendimiento:

  • Cree archivos únicamente 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.

ImportanteImportant
Aunque las herramientas de copia de seguridad y recuperación integradas en SharePoint Server 2010 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 podrán 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 SharePoint Server 2010, vea Planeación de copia de seguridad y recuperación en SharePoint (Server 2010).

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 (http://go.microsoft.com/fwlink/p/?LinkId=117909).

Considere un tamaño de base de datos que permita mejorar la administración, el rendimiento y la actualización del entorno.

Para ayudar a garantizar el rendimiento del sistema, recomendamos limitar el tamaño de las bases de datos de contenido a 200 GB, excepto cuando las condiciones y los escenarios de uso específicos admitan archivos superiores. Para obtener más información acerca de los límites de tamaño de base de datos, consulte la sección acerca de los límites de base de datos de contenido en Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software.

Normalmente recomendamos que una colección de sitios no supere los 100 GB a menos que sea la única colección de sitios en la base de datos, para que se puedan utilizar las herramientas de copia de seguridad pormenorizada de SharePoint Server 2010 para mover una colección de sitios a otra base de datos, si es necesario.

Para obtener más información acerca de los repositorios de documentos a gran escala, vea el tema sobre los requisitos calculados de capacidad y rendimiento para repositorios de documentos a gran escala, disponible en Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

Se recomienda administrar automáticamente el crecimiento de datos y archivos de registro teniendo en cuenta las siguientes sugerencias:

  • En la medida de lo posible, ajuste previamente los datos y archivos de registro a su tamaño final anticipado.

  • Se recomienda que habilite el crecimiento automático por razones de seguridad. No confíe en la configuración predeterminada de crecimiento automático. Tenga en cuenta las siguientes instrucciones al configurar el crecimiento automático:

    • Cuando se planean bases de datos de contenido que superan el tamaño recomendado (200 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.

    • Establezca el valor de crecimiento automático para la base de datos de almacén de propiedades de la aplicación de servicio de búsqueda en 10 por ciento.

    • Si no se espera que el tamaño calculado de la base de datos de contenido alcance el tamaño máximo recomendado de 200 GB durante el próximo año, establezca el tamaño máximo que estima tendrá la base de datos dentro de un año, con un 20 por ciento adicional como margen de error, mediante el uso de la propiedad ALTER DATABASE MAXSIZE. Revise periódicamente esta configuración para asegurarse de que sigue siendo un valor apropiado en función de las tasas anteriores de crecimiento.

  • Mantenga un nivel de al menos el 25  por ciento del espacio disponible en los 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.

Pruebe si la solución de copia de seguridad y rendimiento permite cumplir en su hardware los contratos de nivel de servicio (SLA). En concreto, pruebe el subsistema de E/S del equipo que ejecuta SQL Server para asegurarse de que el rendimiento sea satisfactorio.

Pruebe la solución de copia de seguridad que va a usar para asegurarse de que la copia de seguridad del sistema pueda hacerse durante el período de mantenimiento disponible. Si la solución de copia de seguridad no puede cumplir los SLA que su negocio requiere, considere la posibilidad de usar una solución de copia de seguridad incremental, como System Center Data Protection Manager (DPM) 2010.

Es importante realizar un seguimiento de estos componentes de recursos de un servidor que ejecuta SQL Server: CPU, memoria, proporción de aciertos en caché y subsistema de E/S. Cuando parezca que uno o varios de los componentes están lentos o sobrecargados, analice la estrategia adecuada en función de la carga de trabajo actual y prevista. Para obtener más información, vea el tema sobre la solución de problemas de rendimiento en SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=168448).

En la sección siguiente se indican los contadores de rendimiento recomendados para supervisar el rendimiento de las bases de datos de SQL Server que se ejecutan en el entorno de SharePoint Server 2010. También se indican los valores aproximados de buen estado para cada contador.

Para obtener más información acerca de cómo supervisar el rendimiento y usar contadores de rendimiento, vea el tema sobre la supervisión del rendimiento (http://go.microsoft.com/fwlink/p/?LinkId=189032).

Supervise los siguientes contadores de SQL Server para garantizar el buen estado de los servidores:

  • Estadísticas generales Este objeto proporciona contadores para supervisar la actividad general de todo el servidor, por ejemplo, el número de conexiones actuales y el número de usuarios que se conectan y desconectan por segundo de los equipos que ejecutan una instancia de SQL Server. Considere la posibilidad de supervisar los contadores siguientes:

    • Conexiones de usuario   Este contador muestra el número de conexiones de usuario del equipo que ejecuta SQL Server. Si este número aumenta al 500 por ciento de su línea base, es posible que disminuya el rendimiento.

  • Bases de datos Este objeto proporciona contadores para supervisar las operaciones de copia masiva, copia de seguridad y rendimiento de la restauración, así como las actividades de registro de transacciones. Supervise las transacciones y el registro de transacciones para determinar cuánta actividad de usuario se está produciendo en la base de datos y cuánto está creciendo el registro de transacciones. La cantidad de actividad de usuario puede determinar el rendimiento de la base de datos y afectar al tamaño del registro, a los bloqueos y a la réplica. Supervisar la actividad de registro de bajo nivel para medir el uso de los recursos y la actividad de usuario puede ayudarle a identificar los cuellos de botella de rendimiento. Considere la posibilidad de supervisar los siguientes contadores:

    • Transacciones/s Este contador muestra la cantidad de transacciones en una base de datos o en todo el servidor por segundo. Este número sirve más para su línea base y para solucionar problemas.

  • Bloqueos Este objeto brinda información acerca de los bloqueos de SQL Server en tipos de recursos individuales. Considere la posibilidad de supervisar los siguientes contadores:

    • Tiempo promedio de espera (ms) Este contador muestra el promedio de tiempo de espera para cada solicitud de bloqueo que se esperó.

    • Tiempo de espera de bloqueos (ms) Este contador muestra el tiempo de espera de bloqueos durante el último segundo.

    • Esperas de bloqueo/s Este contador muestra el número de bloqueos por segundo que no se pudieron satisfacer inmediatamente y que tuvieron que esperar recursos.

    • Número de interbloqueos/s Este contador muestra el número de interbloqueos en el equipo que ejecuta SQL Server por segundo. No debe ser mayor que 0.

  • Bloqueos temporales Este objeto proporciona contadores para supervisar los bloqueos de recursos de SQL Server internos llamados bloqueos temporales. La supervisión de los bloqueos temporales para determinar el uso de los recursos y la actividad de usuario puede ayudarle a identificar los cuellos de botella de rendimiento. Considere la posibilidad de supervisar los siguientes contadores:

    • Promedio de tiempo de espera de bloqueos temporales (ms) Este contador muestra el promedio del tiempo de espera de los bloqueos temporales para solicitudes de bloqueos temporales que tuvieron que esperar.

    • Esperas de bloqueos temporales/s Este contador muestra el número de solicitudes de bloqueos temporales que no se concedieron inmediatamente.

  • Estadísticas SQL Este objeto proporciona contadores para supervisar la compilación y el tipo de solicitudes enviadas a una instancia de SQL Server. Supervisar el número de compilaciones y nuevas compilaciones de consulta y el número de lotes recibidos por una instancia de SQL Server indica la rapidez con la que SQL Server procesa las consultas de usuario y la eficacia con la que el optimizador de consultas procesa las consultas. Considere la posibilidad de supervisar los siguientes contadores:

    • Compilaciones SQL/s   Este contador indica el número de veces que se especifica la ruta de acceso del código de compilación por segundo.

    • Recompilaciones SQL/s Este contador indica el número de recompilaciones de instrucciones por segundo.

  • Administrador de búfer Este objeto proporciona contadores para supervisar cómo utiliza SQL Server la memoria para almacenar las páginas de datos, las estructuras de datos internos y la memoria caché de procedimientos, así como los contadores para supervisar la E/S física mientras SQL Server lee y escribe páginas de base de datos. Considere la posibilidad de supervisar los siguientes contadores:

    • Proporción de aciertos en caché del búfer

    • Este contador muestra el porcentaje de páginas encontradas en la memoria caché del búfer sin necesidad de leer en el disco. La relación es el número total de aciertos de caché dividido por el número total de búsquedas de caché a través de los últimos miles de accesos a la página. Como la lectura de la memoria caché es mucho menos costosa que la lectura del disco, es deseable que esta proporción sea alta. Por lo general, es posible aumentar la proporción de aciertos de caché del búfer si aumenta la cantidad de memoria disponible para SQL Server.

  • Caché del plan   Este objeto proporciona contadores para supervisar cómo SQL Server usa la memoria para almacenar objetos, como procedimientos almacenados, instrucciones Transact-SQL ad hoc y preparadas, así como desencadenadores. Considere la posibilidad de supervisar los siguientes contadores:

    • Proporción de aciertos en caché

    • Este contador indica la proporción entre aciertos en caché y búsquedas de planes.

Supervise los siguientes contadores para asegurar el buen estado de los equipos que ejecutan SQL Server:

  • Procesador: % tiempo de procesador: _Total Este contador muestra el porcentaje de tiempo en que el procesador ejecuta procesos de una aplicación o del sistema operativo, que no sean procesos inactivos. En el equipo que ejecuta SQL Server, este contador se debe mantener entre el 50 y el 75 por ciento. Si se producen sobrecargas constantes, investigue si existe una actividad de procesamiento anormal o si el servidor requiere unidades CPU adicionales.

  • Sistema: Longitud de la cola de procesador Este contador muestra la cantidad de subprocesos en la cola del procesador. Supervise este contador para asegurarse de que permanece por debajo de un valor equivalente a dos veces la cantidad de CPU de núcleo.

  • Memoria: Mbytes disponibles Este contador muestra la cantidad de memoria física, en megabytes, disponible para los procesos que se ejecutan en el equipo. Supervise este contador para asegurarse de mantener un nivel de al menos el 20 por ciento del total de la memoria RAM física disponible.

  • Memoria: Páginas/s Este contador muestra la velocidad con que se leen o escriben las páginas en el disco para resolver errores graves de las páginas. Supervise este contador para asegurarse de que permanece por debajo de 100.

Para obtener más información y conocer métodos de resolución de problemas de la memoria, vea el tema sobre el uso de la memoria de supervisión en SQL Server 2005 (http://go.microsoft.com/fwlink/p/?LinkID=105585).

Supervise los siguientes contadores para garantizar el buen estado de los discos. Tenga en cuenta que los siguientes valores representan las medidas tomadas a lo largo del tiempo en lugar de los valores generados durante un pico repentino o valores basados en una única medición.

  • Disco físico: % de tiempo de disco: UnidadDeDatos Este contador contador muestra el porcentaje de tiempo transcurrido durante el cual la unidad de disco seleccionada se encuentra ocupada atendiendo solicitudes de lectura o escritura; es un indicador general de lo ocupado que está el disco. Si el contador Disco físico: % de tiempo de disco es alto (más del 90 por ciento), compruebe el contador Disco físico: longitud actual de la cola de disco para ver cuántas solicitudes del sistema están esperando acceso al disco. El número de solicitudes de E/S en espera debería mantenerse en no más de 1,5 a 2 veces el número de cilindros que componen el disco físico.

  • Disco lógico: Transferencias de disco/s Este contador muestra la velocidad a la que se realizan las operaciones de lectura y escritura en el disco. Use este contador para supervisar adecuadamente los pronósticos y tendencias de crecimiento.

  • Disco lógico: Bytes de lectura de disco/s y Disco lógico: Bytes de escritura en disco/s Estos contadores muestran la velocidad con la que se transfieren los bytes desde el disco durante las operaciones de lectura o escritura.

  • Disco lógico: Promedio de bytes de disco/lectura   Este contador muestra el promedio de bytes de transferencia desde el disco durante las operaciones de lectura. Este valor puede reflejar la latencia del disco; las operaciones de lectura más grandes pueden producir un pequeño aumento en la latencia.

  • Disco lógico: Promedio de bytes de disco/escritura   Este contador muestra el promedio de bytes de transferencia al disco durante las operaciones de escritura. Este valor puede reflejar la latencia del disco; las operaciones de escritura más grandes pueden producir un pequeño aumento en la latencia.

  • Disco lógico: Longitud actual de la cola de disco   Este contador muestra la cantidad de solicitudes pendientes en el disco en el momento en que se recopilan los datos de rendimiento. Para este contador, los valores más bajos son mejores. Los valores mayores de 2 por disco podrían indicar un cuello de botella y deberán ser investigados. Esto quiere decir que un valor de hasta 8 se podría aceptar para una unidad lógica (LUN) formada por 4 discos. Los cuellos de botella pueden crear un trabajo acumulado que se puede extender más allá del servidor actual que está teniendo acceso al disco y generar largos períodos de espera para los usuarios. Las posibles soluciones para el cuello de botella consisten en agregar más discos a la matriz RAID, reemplazar los discos existentes por discos más rápidos o mover algunos datos a otros discos.

  • Disco lógico: Longitud promedio de la cola de disco   Este contador muestra el promedio de solicitudes de escritura y lectura que se pusieron en cola para el disco seleccionado durante el intervalo de muestra. La regla requiere que haya dos o menos solicitudes pendientes de lectura y escritura por cilindro, pero esto puede ser difícil de medir debido a la virtualización del almacenamiento y a las diferencias en los niveles de RAID entre configuraciones. Busque longitudes de cola de disco superiores a la media junto con latencias de disco superiores a la media. Esta combinación puede indicar que la memoria caché de la matriz de almacenamiento se está usando excesivamente o que el rendimiento se ve afectado al compartir el cilindro.

  • Disco lógico: Promedio de segundos de disco/lectura y Disco lógico: Promedio de segundos de disco/escritura   Estos contadores muestran el tiempo medio, en segundos, de una operación de lectura o escritura en el disco. Supervise estos contadores para asegurarse de que permanezcan por debajo del 85 por ciento de la capacidad del disco. El tiempo de acceso al disco aumenta exponencialmente si las operaciones de lectura o escritura superan el 85 por ciento de la capacidad del disco. Para determinar la capacidad específica de su hardware, vea la documentación de su proveedor o use la herramienta de pruebas comparativas del subsistema de disco SQLIO para calcularla. Para obtener más información, vea el tema sobre la herramienta de pruebas comparativas del subsistema de disco SQLIO (http://go.microsoft.com/fwlink/p/?LinkID=105586).

    • Disco lógico: Promedio de segundos de disco/lectura   Este contador muestra el tiempo medio, en segundos, de una operación de lectura del disco. En un sistema bien ajustado, los valores ideales oscilan entre 1 y 5 milisegundos (ms) para los registros (lo idóneo es 1 milisegundo en una matriz de caché) y entre 4 y 20 ms para los datos (lo idóneo es menos de 10 ms). Se pueden producir latencias superiores en horas de máxima actividad, pero si los valores elevados se registran con frecuencia, deberá investigar la causa.

    • Disco lógico: Promedio de segundos de disco/escritura   Este contador muestra el tiempo medio, en segundos, de una operación de escritura del disco. En un sistema bien ajustado, los valores ideales oscilan entre 1 y 5 milisegundos (ms) para los registros (lo idóneo es 1 milisegundo en una matriz de caché) y entre 4 y 20 ms para los datos (lo idóneo es menos de 10 ms). Se pueden producir latencias superiores en horas de máxima actividad, pero si los valores elevados se registran con frecuencia, deberá investigar la causa.

    Cuando use configuraciones RAID con los contadores Disco lógico: promedio de bytes de disco/lectura o Disco lógico: promedio de bytes de disco/escritura, use las fórmulas que se indican en la siguiente tabla para determinar la velocidad de entrada o salida en el disco.

     

    Nivel RAID Fórmula

    RAID 0

    E/S por disco = (lecturas + escrituras) / cantidad de discos

    RAID 1

    E/S por disco = [lecturas + (2 x escrituras)] / 2

    RAID 5

    E/S por disco = [lecturas + (4 x escrituras)] / cantidad de discos

    RAID 10

    E/S por disco = [lecturas + (2 x escrituras)] / cantidad de discos

    Por ejemplo, si tiene un sistema RAID 1 que tiene dos discos físicos y sus contadores están establecidos en los valores que se muestran en la tabla siguiente.

     

    Contador Valor

    Promedio de segundos de disco/lectura

    80

    Disco lógico: Promedio de segundos de disco/escritura

    70

    Longitud promedio de la cola de disco

    5

    El valor de E/S por disco se puede calcular de la siguiente manera: (80 + (2 x 70))/2 = 110

    La longitud de la cola del disco se puede calcular de la siguiente manera: 5/2 = 2,5

    En esta situación, tiene un cuello de botella de E/S límite.

También puede supervisar la latencia de los discos y analizar las tendencias mediante la vista de administración dinámica sys.dm_io_virtual_file_stats en SQL Server 2008. Para obtener más información, vea sys.dm_io_virtual_file_stats (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkID=105587).

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2015 Microsoft