Rendimiento de RBS de SQL Server con SharePoint Server 2010 y StorSimple Storage Solution Este documento se proporciona “tal cual”. Es posible que la información y los puntos de vista reflejados en este documento, incluidas la dirección URL y otras referencias a sitios web de Internet, cambien sin previo aviso. El usuario asume el riesgo de su uso. Este documento no proporciona ningún derecho legal sobre la propiedad intelectual e industrial de ningún producto de Microsoft. Este documento puede copiarse y usarse para fines internos y de referencia. Este documento no puede modificarse para fines internos o de referencia.

© 2011 Microsoft Corporation. Todos los derechos reservados.



Microsoft SharePoint Server 2010

abril de 2011

Rendimiento de RBS de SQL Server con SharePoint Server 2010 y StorSimple Storage Solution Burzin Patel StorSimple, Inc. Peter Scharlock Microsoft Corporation

Revisores técnicos: John Flores (StorSimple, Inc.), Srini Acharya, Steve Howard, Shaun Tinline-Jones, Mike Weiner, Kun Cheng, Prem Mehra, Jimmy May, David Koronthaly, Bill Baer Diciembre de 2010. Revisión: abril de 2011 Se aplica a:

SharePoint Server 2010 y SQL Server 2008 R2

Resumen: la tecnología de Microsoft® SharePoint® ha observado un crecimiento de orden de magnitud en su uso durante los últimos años. Este crecimiento es el resultado del almacenamiento por parte de los usuarios de una mayor cantidad de documentos en bibliotecas de SharePoint así como también el almacenamiento por parte de estos de documentos multimedia más grandes, ambos de los cuales dan como resultado un aumento en los costos de almacenamiento así como también algunos desafíos de rendimiento y capacidad de administración para los administradores de SharePoint. Microsoft abordó estos problemas mediante la introducción de compatibilidad nativa para la característica Almacenamiento remoto de blobs (RBS) en SharePoint Server 2010. En estas notas del producto se explica la característica RBS en tanto se aplica a SharePoint Server 2010, y se analiza el impacto de su rendimiento en atributos clave de un conjunto de servidores SharePoint como tamaño de base de datos, tamaño de copia de seguridad de base de datos, tiempos de respuesta de transacciones, y tiempo de copia de seguridad y restauración.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 2 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Contenido Introducción ......................................................................................................................................................4 Almacén remoto de blobs ....................................................................................................................................4 ¿Por qué usar RBS? ......................................................................................................................................5 Objetivos de prueba ...........................................................................................................................................6 Metodología de prueba ........................................................................................................................................7 Carga de trabajo ..........................................................................................................................................7 Configuración del servidor .............................................................................................................................9 Configuración de hardware ................................................................................................................... 10 Configuración de almacenamiento .......................................................................................................... 10 Configuración de software..................................................................................................................... 11 Resultados de las pruebas y observaciones .......................................................................................................... 11 1. Efectos de RBS en el tamaño de las bases de datos de SQL Server ............................................................... 12 2. Efectos de RBS en el tamaño de copias de seguridad de bases de datos ........................................................ 15 3. Efectos de RBS en los tiempos de creación de copias de seguridad y restauración .......................................... 17 4. Efectos de RBS en el rendimiento de la reconstrucción de índices ................................................................. 19 5. Efectos de RBS en los tiempos de respuesta de transacciones de SharePoint ................................................. 21 6. Efectos de RBS en la operación de rastreo ................................................................................................. 23 7. Efectos de RBS en el rendimiento de la carga de archivos ........................................................................... 24 8. Tiempo requerido para migrar datos ......................................................................................................... 26 Conclusión....................................................................................................................................................... 27 Recursos adicionales ......................................................................................................................................... 28 Acerca de StorSimple........................................................................................................................................ 28 Acerca de Microsoft .......................................................................................................................................... 28

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 3 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Introducción Microsoft SharePoint Server tuvo un crecimiento casi exponencial en popularidad durante los últimos años. Este crecimiento se dio gracias a que más clientes adoptan SharePoint Server y que más usuarios almacenan documentos y conjuntos de datos de mayor tamaño dentro de los conjuntos de servidores SharePoint. Con la reciente versión de SharePoint Server 2010, el crecimiento en uso se prevé que aumentará más aún. SharePoint Server 2010 ofrece una interfaz de usuario más simplificada que proporciona una experiencia de usuario más rica, lo que hace que SharePoint Server sea el repositorio elegido para todos los tipos de datos. Esto, junto al crecimiento de contenido multimedia enriquecido, genera que el tamaño del contenido de conjunto de servidores de SharePoint se dispare, lo que a su vez da como resultado un aumento significativo en el almacenamiento físico requerido. Este crecimiento en tamaño a menudo representa un desafío para los administradores de SharePoint que ahora deben lidiar con la carga adicional de administrar más contenido, bases de datos y copias de seguridad de mayor tamaño. Para abordar todos estos problemas, SharePoint Server 2010 introduce una nueva característica (Almacenamiento remoto de blobs [RBS]) que ayuda a abordar los problemas que surgen con el crecimiento del contenido de SharePoint. En estas notas del producto se presentan los beneficios y las características operativas de la característica RBS cuando se usa con Microsoft SharePoint Server 2010. También se presentan aquí las características de rendimiento de un conjunto de servidores de SharePoint configurado para funcionar con la StorSimple storage solution tal como se explica en la próxima sección. Se discutirán, junto con los puntos de datos de rendimiento aplicables, los siguientes temas: beneficios como reducción del tamaño de base de datos, copias de seguridad de base de datos más rápidas, restauraciones de base de datos más rápidas, mejores tiempos de respuesta para documentos de mayor tamaño, ventajas de mantenimiento de base de datos, y menos demanda en almacenamiento de back-end. Todos los puntos de datos que se presentan en estas notas del producto fueron generados como parte de las pruebas de rendimiento llevadas a cabo en los laboratorios de rendimiento de StorSimple, Inc. en Santa Clara en conjunto con los equipos de producto de Microsoft SQL Server y SharePoint.

Nota: Los resultados de laboratorio de estas notas del producto son específicos a los entornos que se describen aquí. Sus resultados pueden variar.

Almacén remoto de blobs Blob es una sigla de objeto binario grande (binary large object), y en el contexto de aplicación de SharePoint hace referencia al objeto de archivo que está almacenado en la base de datos. El Almacenamiento remoto de blobs (RBS) es un conjunto de API de biblioteca de Microsoft ® SQL Server® que se incorpora como Feature Pack de complemento para Microsoft SQL Server 2008 R2. La característica RBS permite a las aplicaciones externalizar el almacenamiento de objetos binarios grandes (blobs) a una ubicación externa a la base de datos, como un recurso compartido de archivos, lo que da como resultado una reducción en la cantidad de almacenamiento requerido de base de datos de SQL Server. Un almacén RBS es generalmente un volumen separado en la misma red que SQL Server. SharePoint Server 2010 aprovecha la característica RBS para externalizar los blobs almacenados en la base de datos de contenido. SQL Server y SharePoint Server administran conjuntamente la integridad de los datos entre los registros de base de datos y el almacén externo RBS según cada base de datos.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 4 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

La característica RBS de SQL Server requiere que haya un proveedor instalado en cada servidor front-end web (WFE) de SharePoint en el que se configura la aplicación de SharePoint. El proveedor consta de un conjunto de DLL que implementan métodos para las API de RBS y realizan la operación en sí de externalizar los blobs. Para todas las pruebas llevadas a cabo en estas notas del producto, el Optimizador de base de datos de SharePoint StorSimple, que incluye un proveedor de RBS, se configuró en el conjunto de servidores de SharePoint Server 2010. La configuración se realizó por medio de un administrador de configuración de RBS Optimizador de base de datos de SharePoint StorSimple, que es una extensión del sitio de Administración central, tal como se muestra en la Figura (i) a continuación.

Figura (i) – Optimizador de base de datos de SharePoint StorSimple - configuración de RBS

¿Por qué usar RBS? SharePoint Server almacena todos sus datos en la base de datos. A medida que se almacena una cantidad cada vez mayor de contenido, el tamaño de la base de datos puede crecer con mucha rapidez. El crecimiento es atribuible a que se está cargando nuevo contenido en SharePoint Server, al igual que las revisiones al contenido existente cuando está habilitado el control de versiones de SharePoint; si se modifica tan solo un byte de un documento de SharePoint, se almacena una copia del blob entero en la base de datos, y se marca la previa como versión anterior. Como ya han visto muchos administradores de SharePoint, esto da como resultado un crecimiento exponencial en el tamaño del contenido. A medida que crece el tamaño de la base de datos, resulta cada vez más difícil administrar el sistema y garantizar un rendimiento óptimo. De lo contrario, las tareas fundamentales como copias de seguridad, © 2011 Microsoft Corporation. Todos los derechos reservados. Página 5 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

restauración y desfragmentación de la base de datos son cada vez más difíciles de ejecutar. Este es uno de los motivos por los que Microsoft recomienda que los clientes limiten el tamaño de sus bases de datos a un tamaño administrable tal como se explica en el artículo: “Administración de capacidad de SharePoint Server 2010: restricciones y límites del software” (http://technet.microsoft.com/enus/library/cc262787.aspx#ContentDB). Respetar este procedimiento recomendado puede implicar que el administrador de SharePoint se vea forzado a crear varias bases de datos, lo que resulta costoso desde la perspectiva de la administración y las tareas de mantenimiento. Una cantidad mayor de bases de datos da como resultado más copias de seguridad para administrar y supervisar, y esto, a su vez, requiere más administradores de SharePoint. Al usar RBS, su aplicación puede almacenar grandes cantidades de datos no estructurados, tales como archivos de audio o vídeos multimedia enriquecidos, lo que permite aprovechar lo mejor tanto de las capacidades relacionales de SQL Server como de la escalabilidad de un almacén de blobs de sistema de archivos de Windows®. Además de esta ventaja principal, la característica RBS ofrece muchas otras ventajas relacionadas con la flexibilidad, el rendimiento, las tareas de mantenimiento y los costos de almacenamiento: 

Tamaños de base de datos más pequeños. Esto da como resultado un uso óptimo de costosos recursos de servidor de bases de datos como procesadores, memoria y discos



Archivos de copia de seguridad de base de datos más pequeños



Tiempos de recuperación y copia de seguridad menos prolongados



Operaciones de mantenimiento de base de datos más rápidas, como desfragmentación y reconstrucción de índices



Mejor rendimiento general, especialmente para almacenar objetos grandes y obtener acceso a ellos.

Cuando SharePoint Server está configurado para usar RBS, la semántica de transacción de operaciones del usuario se preserva en su totalidad, y no se observa absolutamente ningún cambio desde la perspectiva de un usuario final. SharePoint Server en conjunto con el proveedor de RBS realizan automáticamente en el back-end la tarea de externalizar los blobs desde la base de datos. RBS funciona sin problemas cuando se usa con clústeres de conmutación por error de SQL Server. Sin embargo, no funciona con reflejo de SQL Server cuando la base de datos de contenido de SharePoint se refleja en un servidor de bases de datos en otro conjunto de servidores.

Objetivos de prueba El objetivo de nuestra prueba era caracterizar el rendimiento de un conjunto de servidores de SharePoint configurado con RBS mediante el uso del proveedor de RBS StorSimple, que forma parte del Optimizador de base de datos de SharePoint StorSimple, y luego comparar ese rendimiento con el rendimiento de un conjunto de servidores de SharePoint sin la característica RBS habilitada. También queríamos medir los efectos de RBS en lo siguiente: 

Tamaños de archivo de registro de transacciones y datos de base de datos de SQL Server



Tamaño de archivo de copia de seguridad



Tiempo empleado en crear copia de seguridad y restaurar base de datos de contenido



Tiempo empleado en reconstruir los índices de base de datos de contenido



Efectos de operación de reconstrucción de índices en el rendimiento de las transacciones del usuario final



Tiempos de respuesta de transacciones de SharePoint



Operación de rastreo de búsqueda de SharePoint Server

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 6 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010



Rendimiento de carga de archivos



Rendimiento coherente a medida que aumenta la escala del contenido



Tiempo empleado en migrar datos adentro y afuera del almacén de RBS

abril de 2011

El comportamiento de SharePoint Server 2010 para características de carga de trabajo de aplicaciones variantes o umbrales variantes para el tamaño de los blobs que se externalizan escapa el alcance de estas notas del producto.

Metodología de prueba Nuestra meta era realizar las pruebas descriptas en la sección anterior contra una carga de trabajo que representaba situaciones del mundo real lo más parecido posible. Otra meta era mantener esa configuración de prueba (configuración de servidor, configuración de base de datos, esquema de tabla, etc.) relativamente coherente en todas las pruebas para poder comparar y contrastar el rendimiento de las diferentes operaciones. Las pruebas estaban divididas en 3 categorías generales: (1) pruebas de carga, (2) pruebas de combinación de transacción completa y (3) pruebas varias. Pruebas de carga de documento: este conjunto de pruebas medía el rendimiento y los efectos de RBS en la carga de documentos del usuario para tamaños de archivos promedio variantes. Pruebas de combinación de transacción completa de SharePoint: este conjunto de pruebas medía los efectos de RBS en el rendimiento del conjunto de servidores de SharePoint. Las pruebas incluían todas las transacciones de usuario de SharePointcomúnmente ejecutadas comoExaminar, Buscar, Cargar documento, y Creación de sitio. La métrica de rendimiento principal utilizada era el tiempo de respuesta promedio de las páginas web. Pruebas varias: estas pruebas incluían operaciones como restauración y copia de seguridad de base de datos, migración de objetos adentro y afuera de la base de datos y al almacén de RBS, y rastreo de búsqueda de SharePoint Server.

Carga de trabajo Las diversas preguntas para las que queríamos hallar una respuesta mediante nuestras pruebas nos forzaron a usar diferentes conjuntos de datos de carga de trabajo. Se usaron dos cargas de trabajo para las pruebas: (1) la combinación de carga de trabajo de archivos de carga y (2) la combinación de transacción completa de SharePoint.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 7 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

La combinación de carga de trabajo de archivos de carga incluía dos conjuntos de archivos con un tamaño ponderado promedio de aproximadamente 100 KB utilizado para generar la base de datos de 100 GB, y 500 KB utilizado para generar la base de datos de contenido de 1 TB. La distribución de tamaño de archivo para el conjunto de datos de 100 KB se muestra en la Figura (ii).

Figura (ii): distribución de tamaño de archivo de carga de trabajo

La combinación de carga de trabajo de archivos de carga se usaba principalmente para medir las características de carga de documento con y sin RBS. La combinación de transacción completa de SharePoint se usaba para representar una combinación de transacciones de SharePoint típicas que un usuario final ejecutaría todos los días. Microsoft Visual Studio ® Team System 2008 Team Suite se usaba para generar la carga de trabajo mediante el uso de una versión modificada del kit de herramientas de rendimiento Microsoft Office SharePoint Server 2007 original compartido en Codeplex. Las siguientes transacciones se usaban para cada una de las pruebas.

Nombre de prueba

Descripción

Porcentaje

Flujo de trabajo de página

Pasar por un flujo de trabajo de página: desproteger, aprobar y proteger

1%

Crear página

Crear una nueva página

6%

Administrador de sitio

Abrir la vista Administrador de sitio

1%

Crear sitio de publicación

Crear un nuevo sitio con la plantilla de publicación

1%

Crear sitio de equipo

Crear una nueva colección de sitios con la plantilla de sitio de equipo dentro del directorio de sitios

1%

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 8 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Página de inicio

Navegar hasta la página de inicio del portal

25%

Página grande

Navegar hasta una variedad de páginas en todo el portal

10%

Página pública de Mi sitio

Navegar hasta la página pública de Mi sitio

16%

Editar perfil de Mi sitio

Editar el perfil personal

7%

Consulta de búsqueda

Realizar una Consulta de búsqueda y ver los resultados en la página Centro de búsqueda

15%

Cargar documento

Cargar un documento (promedio 90 KB)

5%

Descargar documento

Descargarun documento (promedio 90 KB)

12% Total:

100%

Tabla (i): combinación de transacción completa de SharePoint.

Configuración del servidor El conjunto de servidores de SharePoint se configuró con seis servidores front-end web (WFE), un servidor de aplicaciones que se configuró para ejecutar el rastreo de búsqueda y un servidor de bases de datos como se muestra en la Figura (iii).

Figura (iii): topología de conjunto de servidores de SharePoint

Los servidores de aplicaciones y WFE se configuraron para ejecutarse en una máquina virtual (VM) mientras que el servidor de bases de datos se ejecutó en un servidor físico dedicado (no virtualizado).

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 9 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Además, se usaron seis servidores de controlador de carga basados en VM (no se muestran más arriba) para generar la carga de trabajo para la combinación de transacción de carga de archivos y la combinación de transacción completa de SharePoint.

Configuración de hardware Rol de equipo

Hardware

WFE

Procesadores con 2 procesadores Intel Xeon E5504 de 2 GHz (virtualizados) 8 GB de RAM

Servidor de aplicaciones

Procesadores con 2 procesadores Intel Xeon de 2 GHz (virtualizados) 8 GB de RAM

Servidor de bases de datos

2 procesadores de cuatro núcleos Intel Xeon de 2 GHz (no virtualizados) 16 GB de RAM (12 GB asignados a SQL Server) Tabla (ii): configuración de hardware

Configuración de almacenamiento Todo el almacenamiento que se usó en la prueba comparativa se configuró en la StorSimple 1010 Storage Appliance1. Las bases de datos del sistema de SQL Server, las bases de datos de SharePoint, y el almacén de blobs se ubicaron en volúmenes separados tal como se muestra en la Tabla (iii) a continuación.

Volumen

1

Unidad

Bases de datos del sistema de SQL

C:\

archivos de registro y datos tempdb

H:\

Archivos de datos de base de datos de contenido

P:\

Archivo de registro de base de datos de contenido

Q:\

Archivo de datos de base de

S:\

StorSimple 1010 es un aparato de almacenamiento optimizado de aplicaciones que está dirigido a aplicaciones como

Microsoft SharePoint y Microsoft Exchange. Para obtener información adicional, vaya a http://www.storsimple.com. © 2011 Microsoft Corporation. Todos los derechos reservados. Página 10 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

datos de búsqueda Archivo de registro de base de datos de búsqueda

Q:\

Almacén de blobs

X:\

Copias de seguridad

O:\

Tabla (iii): configuración de almacenamiento

Configuración de software La configuración y las versiones de software utilizadas para los diferentes servidores eran las que se muestran en la Tabla (iv) a continuación.

Software

Cambios adicionales

Rol de equipo Servidores de aplicaciones y WFE

Windows Server® 2008 R2 Enterprise x64

Se aplicaron todas las últimas revisiones de Windows Server.

Microsoft SharePoint Server 2010 RBS.msi se instaló desde el SQL Server 2008 R2 Feature Pack.

Servidor de bases de datos

Windows Server 2008 R2 Enterprise x64

Se aplicaron las últimas revisiones de Windows Server.

SQL Server 2008 R2 Enterprise x64

Se realizaron los siguientes cambios a la configuración del servidor de bases de datos: -

“Memoria máxima del servidor” = 12 GB

-

Se crearon 4 archivos de datos tempdb, que se movieron a su propio volumen.

Tabla (iv): configuración de software

Resultados de las pruebas y observaciones En esta sección se resumen los resultados de las pruebas llevadas a cabo para medir los efectos del uso de RBS para externalizar el contenido de blobs en diversos atributos de una implementación de SharePoint Server 2010 y ayudar a responder las preguntas que se enumeran en la Tabla (v) a continuación.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 11 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Descripción de la prueba 1

Efectos de RBS en el tamaño de bases de datos

2

Efectos de RBS en el tamaño de copias de seguridad de bases de datos

3

Efectos de RBS en el tiempo de creación de copias de seguridad y restauración

4

Efectos de RBS en el rendimiento de la reconstrucción de índices

5

Efectos de RBS en los tiempos de respuesta de transacciones de SharePoint

6

Efectos de RBS en la operación de rastreo

7

Efectos de RBS en la carga de archivos para tamaños de archivos variantes

8

Tiempo requerido para migrar datos adentro y afuera del almacén de RBS Tabla (v): situaciones de prueba

1. Efectos de RBS en el tamaño de las bases de datos de SQL Server Como se explicó en la sección de RBS, la mayoría de los datos en la base de datos de SQL Server corresponde a datos BLOB de SharePoint. En la mayoría de las implementaciones de clientes de SharePoint, especialmente los que usan SharePoint para administración de registros y colaboración, los datos BLOB representan más del 95 % del tamaño de la base de datos. Según el tamaño de la base de datos, este contenido podría traducirse con facilidad a cientos de gigabytes de datos de base de datos. Mientras que esto es intencional, plantea muchos desafíos y es a menudo un factor limitante sobre el usode SharePoint Server, la escalabilidad de la solución y el uso de ciertas características beneficiosas como las Papeleras de reciclaje. En estas pruebas cuyos resultados se resumen en esta sección, se midieron el tamaño de la base de datos, los archivos de datos, y el archivo de registro para bases de datos de contenido de 100 GB de SharePoint compuestas por 100.000 objetos, y una base de datos de contenido de 1 TB de SharePoint compuesta por 2 millones de objetos con y sin la característica RBS. Los tamaños de los archivos para cada una de estas bases de datos se muestran en la Tabla (vi). Tamaño (GB)

Reducción

Sin RBS

Con RBS

Tamaño de base de datos (100 GB)

217.2

7.0

96.8%

Tamaño de archivo de datos de base de datos (100 GB)

106.9

3.2

97.0%

Tamaño de archivo de registro de transacciones de base de datos (100 GB)

111.6

3.8

96.6%

--

96.2

--

2,292

26

98.9%

Tamaño de datos externalizados de RBS Tamaño de base de datos (1 TB)

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 12 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Tamaño de archivo de datos de base de datos (1 TB)

1,120

6.5

99.4%

Tamaño de archivo de registro de transacciones de base de datos (1 TB)

1,173

20

98.3%

--

1,115

--

Tamaño de datos externalizados de RBS

Tabla (vi): tamaños de archivos y bases de datos

Figura (iv): tamaños de archivos y bases de datos

Como se describe en la Figura (iv) más arriba, sin RBS los tamaños generales de las bases de datos después de cargarles contenido de SharePoint de 100 GB y 1 TB fueron de 217,2 GB y 2,29 TB respectivamente. Para la base de datos con 100 GB de contenido de SharePoint, 106,9 GB correspondieron a datos de bases de datos reales mientras que los otros 111,6 GB correspondieron al registro de transacciones de bases de datos. De manera similar para la base de datos con 1 TB de contenido de SharePoint, 1,12 TB correspondieron a la base de datos y 1,2 TB correspondieron al registro de transacciones de la base de datos. Para una base de datos con RBS habilitado, el tamaño de la base de datos de contenido de 100 GB fue 96,8 % más pequeño, mientras que el tamaño de la base de datos de contenido de 1 TB fue 98,9 % más pequeño. Los tamaños de los archivos de registro de transacciones y datos fueron menores en la misma medida. Mientras que el espacio adicional requerido para almacenar blobs dentro de la base de datos a menudo es aparente y se comprende bien, un aspecto negativo menos conocido y menos comprendido aún es el desafío relacionado con el crecimiento de archivos de registro de transacciones de SQL Server. El motivo de este crecimiento es que SQL Server es una base de datos transaccionalmente coherente, que ofrece las propiedades Atomicidad, Coherencia, Aislamiento, Durabilidad (ACID) completas. Esto sugiere que cada transacción está garantizada para funcionar correctamente o arrojar un error (sin estado intermedio). SQL Server implementa las propiedades ACID al registrar completamente cada operación en el registro de © 2011 Microsoft Corporation. Todos los derechos reservados. Página 13 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

transacciones de base de datos mediante acceso a disco de escritura simultánea antes de confirmar la operación. Las propiedades ACID se aplican a todos los datos y tipos de datos de SQL Server, incluidos los blobs. No existe ningún mecanismo a través del cual se puede deshabilitar o evitar de alguna manera. Como cabe esperar, cuando los blobs de SharePoint se almacenan dentro de la base de datos de SQL Server, los blobs se escriben dos veces, primero en el registro de transacciones y luego en el archivo de base de datos como se puede observar mediante el tamaño de la base de datos (2,29 TB) utiliza para almacenar 1 TB de contenido de usuario. Este archivo de registro se trunca cuando se toma la copia de seguridad de la base de datos y está seleccionada la opción “Truncar registro”. Cuando RBS se usa para externalizar el contenido de blobs, los datos BLOB se escriben en el almacén de blobs antes de que se confirme la operación de SharePoint. Por consiguiente las propiedades ACID de la operación se realizan indirectamente sin incurrir en el doble trabajo transacción-registro-escritura. La cantidad de reducción de los archivos de registro de transacciones y datos de bases de datos depende del tamaño de los datos y la frecuencia con la que usted trunca el registro de transacciones durante una copia de seguridad. El contenido de blob externalizado se almacena en recurso compartido de archivos centralizado al que pueden obtener acceso todos los servidores de aplicaciones y los WFE de SharePoint. Este volumen de recurso compartido de archivos puede estar ubicado en el servidor de bases de datos o algún otro servidor. En la Figura (v) se describen las propiedades del recurso compartido de archivos utilizado en las pruebas comparativas.

Figura (v): tamaño de volumen de recurso compartido de archivos de RBS Nota: RBS reduce el tamaño de la base de datos al mover los datos BLOB a un almacenamiento externo, por lo tanto es importante tener en cuenta que no se reduce el espacio de disco general consumido por los datos BLOB. Por supuesto, los proveedores de almacenamiento pueden ayudar con esto mediante el uso de tecnologías propietarias como la eliminación de duplicados que podría ayudar a reducir el espacio de disco. Los blobs no se eliminan automáticamente del almacén de RBS cuando el contenido correspondiente se elimina de SharePoint; se requiere un ciclo de colección de elementos no utilizados por separado que usa este trabajo del Mantenedor de RBS integrado a fin de purgar los blobs huérfanos.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 14 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

2. Efectos de RBS en el tamaño de copias de seguridad de bases de datos En las pruebas cuyos resultados se resumen en esta sección, se midieron los efectos de RBS en el tamaño de copias de seguridad de bases de datos para una base de datos de contenido de 100 GB de SharePoint compuesta por 100.000 objetos, y una base de datos de contenido de 1 TB de SharePoint compuesta por 2 millones de objetos. Las pruebas y el análisis no incluían el almacén de RBS. Es decir, las técnicas y las duraciones relacionadas con las copias de seguridad y la restauración de datos BLOB que residían en el almacenamiento de RBS escapan el alcance de estas notas del producto. El siguiente comando Transact-SQL se usó para realizar la copia de seguridad. BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH NOFORMAT, INIT, N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;

NAME =

Las pruebas también se llevaron a cabo para medir los efectos de la característica de compresión de copia de seguridad de SQL Server2para determinar su efecto en el tamaño de la copia de seguridad con y sin RBS. Los resultados de dichas pruebas se resumen en la Tabla (vii) a continuación.

Tamaño (GB)

Reducción

Sin RBS

Con RBS

Tamaño de archivo de datos de base de datos (100 GB)

106.9

3.2

97.0%

Tamaño de copia de seguridad de SQL Server (100 GB)

107.0

3.3

96.9%

71.5

0.7

99.1%

0

96.2

--

Tamaño de archivo de datos de base de datos (1 TB)

1120

6.5

99.4%

Tamaño de copia de seguridad de SQL Server (1 TB)

1,119.0

6.6

99.4%

Tamaño de copia de seguridad de SQL Server con compresión (1 TB)

1,046.0

1.2

99.9%

0

1115

--

Tamaño de copia de seguridad de SQL Server con compresión (100 GB) Tamaño de almacén de blobs (100 GB)

Tamaño de almacén de blobs (1 TB)

Tabla (vii): tamaños de copias de seguridad y bases de datos

2

La capacidad de comprimir las copias de seguridad de base de datos requiere el uso de SQL Server Enterprise. Esta característica no está disponible en SQL Server Standard o SQL Server Express. © 2011 Microsoft Corporation. Todos los derechos reservados. Página 15 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Figura (vi): tamaños de copias de seguridad y bases de datos

Como se puede ver en el gráfico y la tabla de arriba, el tamaño de la copia de seguridad de base de datos correspondiente al contenido de 100 GB fue 96,9 % más pequeño (107 GB vs. 3,3 GB) mientas que el tamaño de copia de seguridad de base de datos del contenido de 1 TB fue 99,4 % más pequeño (1.119 GB vs. 6,6 GB) cuando RBS estaba habilitado. Para el contenido de 100 GB, el tamaño de los blobs que se habían externalizado desde la base de datos fue 96,2 GB y el de la base de datos de 1 TB fue 1115 GB. Cuando la característica de compresión de copia de seguridad de SQL Server se habilitó en la base de datos, el tamaño de las copias de seguridad se redujo aún más a 71,5 GB y 1.046 GB respectivamente sin RBS, y 0,7 GB y 1,2 GB con RBS. Tenga en cuenta que la compresión de copia de seguridad fue efectiva en la reducción de espacio en el caso donde no se usó RBS porque SharePoint Server almacena los datos BLOB en fila con los otros datos (metadatos). Si los blobs se hubieran seleccionado para almacenarse fuera de fila, la compresión de copia de seguridad no hubiera tenido ningún efecto ya que los blobs almacenados fuera de fila no se comprimen. Mientras que esto es una ventaja en este caso, se obtiene a costa de un conjunto de trabajo mayor y una disminución en la eficacia de memoria caché que en definitiva dan como resultado un rendimiento reducido. Como los blobs de SharePoint son inmutables, lo que significa que nunca cambian una vez creados, puede crearse una copia de seguridad del contenido de blob en cualquier momento tras la finalización de la copia de seguridad de base de datos de SQL Server. Esto brinda la flexibilidad de hacer una rápida copia de seguridad coherente transaccionalmente de estados anteriores de la base de datos de SQL Server y luego crear una copia de seguridad del volumen de almacén de blobs en un momento posterior. La copia de seguridad de SQL Server y la copia de seguridad del almacén de contenido de RBS comprenden un conjunto completo de copia de seguridad del contenido de SharePoint. Una vez completo, el conjunto de copia de seguridad puede usarse para restaurar la base de datos de SharePoint desde el momento del © 2011 Microsoft Corporation. Todos los derechos reservados. Página 16 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

comienzo de la copia de seguridad de SQL Server.Nota: cuando planee una estrategia de copia de seguridad y restauración que implique almacenamiento de datos de RBS, planee el tiempo de recuperación de RBS. Hasta que se restaure RBS, los documentos de SharePoint no estarán disponibles.

3. Efectos de RBS en los tiempos de creación de copias de seguridad y restauración En las pruebas cuyos resultados se resumen en esta sección, se midieron los efectos de RBS en el tiempo empleado para crear una copia de seguridad de una base de datos y restaurarla. Al igual que en la sección anterior, se usó una base de datos de contenido de 100 GB de SharePoint compuesta por 100.000 objetos. Se llevó a cabo una serie de pruebas a fin de medir el tiempo requerido para crear copias de seguridad de las bases de datos y restaurarlas con y sin RBS habilitado. En la Tabla (viii) a continuación se presenta un resumen de los resultados de las pruebas contra la base de datos de 100 GB.

Operación

Sin RBS

Con RBS

Reducción

106.9

3.2

97.0%

Tiempo para realizar copia de seguridad de base de datos

2.490 segundos

38 segundos

98.5%

Tiempo para restaurar base de datos

1.290 segundos

28 segundos

97.8%

Tiempo para realizar copia de seguridad de base de datos con compresión de base de datos habilitada

3.160 segundos

37 segundos

98.8%

Tiempo para restaurar base de datos desde copia de seguridad comprimida

1.330 segundos

28 segundos

97.9%

Tiempo para realizar copia de seguridad de almacén de blobs (instantánea)

--

14 segundos

--

Tiempo para restaurar almacén de blobs (instantánea)

--

28 segundos

--

Tiempo para realizar copia de seguridad de almacén de blobs (comando copiar)

--

2.578 segundos

--

Tiempo para restaurar almacén de blobs (comando copiar)

--

2.880 segundos

--

Tamaño de archivo de datos de base de datos

Tabla (viii): tiempos de copia de seguridad y restauración para base de datos de 100 GB

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 17 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Figura (vii): tiempos de copia de seguridad y restauración para conjunto de datos de 100 GB

Para copias de seguridad y restauraciones de bases de datos, la cantidad de tiempo empleado es linealmente proporcional al tamaño de la base de datos. Puesto que el tamaño de la base de datos era considerablemente más pequeño con RBS habilitado, la cantidad de tiempo se redujo de forma acorde, tal como se muestra en la Figura (vii). Con RBS habilitado la cantidad de tiempo empleado en crear la copia de seguridad de la base de datos fue un 98,5 % menos (2.490 segundos vs. 38 segundos), mientras que la cantidad de tiempo empleado en restaurar la base de datos fue 97,7 % menos (1.284 segundos vs. 28 segundos). De forma similar, la cantidad de tiempo empleado en crear la copia de seguridad de la base de datos con compresión de copia de seguridad de SQL Server fue 98,8 % menos, mientras que la cantidad de tiempo empleado en restaurar una base de datos comprimida con copia de seguridad fue 97,9 % menos. La copia de seguridad de la base de datos con compresión de copia de seguridad tardó 27 % más tiempo y usó considerablemente más recursos de servidor de SQL Server debido al procesamiento adicional requerido para comprimir los datos. Los comandos usados para crear la copia de seguridad de las bases de datos y restaurarlas fueron los siguientes:

BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH NOFORMAT, INIT, N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;

NAME =

BACKUP DATABASE [WSS_Content] TO DISK = N'O:\WSS_Content' WITH COMPRESSION, NOFORMAT, INIT, NAME = N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD; RESTORE DATABASE [WSS_Content] FROM DISK = N'O:\WSS_Content' WITH FILE = 1, MOVE N'WSS_Content' TO N'J:\ContentDB_Data\WSS_Content.mdf', MOVE N'WSS_Content_log' TO N'S:\ContentDB_Log\WSS_Content_log.LDF', NOUNLOAD, REPLACE;

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 18 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Cuando se usa RBS, debe crearse una copia de seguridad del almacén RBS por separado. Esta copia de seguridad puede realizarse de forma asincrónica y en paralelo con la copia de seguridad de base de datos, con el único requisito de que la copia de seguridad del almacén RBS debe iniciarse después de que se haya iniciado la copia de seguridad de base de datos. Se pueden usar diversos mecanismos para crear una copia de seguridad del almacén RBS. En las pruebas se midió el tiempo empleado en crear una copia de seguridad del almacén con un mecanismo de instantánea de disco así como también una copia de directorio secuencial simple. Para los 100 GB de contenido, el tiempo empleado para crear una copia de seguridad del almacén RBS con una instantánea fue 14 segundos, mientras que el tiempo empleado con el comando copiar fue 2.578 segundos.

Nota: cuando se use el proveedor FILESTREAM, SharePoint 2010 automáticamente creará copias de seguridad de los datos BLOB y de los metadatos, o restaurará estos elementos.

A la hora de restaurar una base de datos que tiene habilitado RBS, también se debe restaurar el almacén de blobs. El conjunto de servidores de SharePoint se considera como completamente restaurado y accesible solamente después de que se haya restaurado el almacén de blobs. Para los 100 GB de contenido, el tiempo empleado para restaurar el almacén RBS fue 28 segundos cuando se usó un mecanismo de instantánea de disco y 2.880 segundos cuando se usó el comando copiar. Es importante mencionar que el almacén RBS solamente debe restaurarse en caso de que se haya dañado o entrado a un estado incoherente.

4. Efectos de RBS en el rendimiento de la reconstrucción de índices Una de las características de SharePoint Server es la frecuente y gran fragmentación de las tablas de bases de datos de SQL Server del back-end que almacenan el contenido blob. Esta fragmentación es de muchas maneras intencional y atribuible a cómo está diseñada la aplicación de SharePoint y el patrón de acceso de la base de datos de SQL Server del back-end. Cuando la base de datos se fragmenta, las páginas de bases de datos que son contiguas lógicamente no aparecen como contiguas físicamente en el archivo de datos. Además, las páginas de datos a menudo no se usan a su capacidad total, lo que provoca que se requiera una cantidad mayor de estas páginas de baja densidad para almacenar los datos. Ambos factores hacen que el conjunto de trabajo sea más grande de lo necesario, y podría dar como resultado una disminución en el rendimiento. La buena noticia es que SharePoint 2010 reduce automáticamente la fragmentación mediante la ejecución de tres reglas del Analizador de mantenimiento de SharePoint. Estas reglas comprueban regularmente la fragmentación de los índices y ejecutan el procedimiento almacenado proc_DefragmentIndices para desfragmentar los índices automáticamente. Sin embargo, se debe tener en cuenta que este proceso con uso intensivo de recursos y el conjunto completo de servidores de SharePoint no está disponible durante el proceso de reconstrucción de índices. Las tres reglas son: 

Las bases de datos utilizadas por SharePoint tienen índices fragmentados



Una o más base de datos de rastreo de búsqueda tiene índices fragmentados



Una o más base de datos de propiedad de búsqueda tiene índices fragmentados

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 19 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

La externalización de los blobs a través de RBS ayuda significativamente a paliar este problema porque la base de datos de menor tamaño requiere menos tiempo para reconstruir los índices. Para medir los efectos de la reconstrucción de índices, se ejecutó un conjunto de pruebas en que se forzó una operación de reconstrucción de índices para todas las tablas de la base de datos de contenido de SharePoint. Si bien esto puede no ser representativo de la implementación en el mundo real donde los índices se reconstruyen según sea necesario hacerlo, se eligió este enfoque para hacer que la prueba sea determinista y repetible. Como parte de estas pruebas se midió el tiempo empleado en reconstruir los índices para bases de datos de contenido de 100 GB y 1 TB con y sin RBS habilitado. También se midió el impacto de una operación de reconstrucción de índices en la disponibilidad y el rendimiento del conjunto de servidores de SharePoint.

Sin RBS

Con RBS

Reducción

Tiempo de reconstrucción de índices para todas las tablas (100 GB)

120 sg

4 sg

96.7%

Tiempo de reconstrucción de índices para todas las tablas (1 TB)

600 sg

146 sg

75.7%

Tabla (x): fragmentación de base de datos

Como se puede ver en la Tabla (x) más arriba, la cantidad de tiempo empleado en reconstruir los índices es 96,7 % menos (120 segundos vs. 4 segundos) para la base de datos de 100 GB y 75,7 % (600 segundos vs. 146 segundos) para la base de datos de 1 TB cuando RBS está habilitado. Como la aplicación web de SharePoint no está disponible la mayor parte del tiempo en que se reconstruyen los índices, el tiempo reducido afecta directamente a la disponibilidad de la aplicación de SharePoint y permite una ejecución más frecuente de la operación de reconstrucción de índices, manteniendo de esta manera un rendimiento coherente. Se realizaron varias pruebas para medir los efectos de prueba de reconstrucción de índices en una base de datos de 100 GB sin RBS. En la Figura (viii) a continuación se grafican los resultados para una de estas pruebas donde se simuló una carga de trabajo de carga de documentos y se ejecutó la operación de reconstrucción de índices durante un estado de equilibrio.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 20 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Figura (viii): Efectos de operación de reconstrucción de índices en el rendimiento

Como se puede ver durante la operación normal (6:28 a. m. a 6:56 a. m.) la tasa de carga de archivos esperada tuvo un promedio de unos 85 archivos por segundo. A las 6:56 a. m. se ejecutó una operación de reconstrucción de índices, que duró 120 segundos. Durante este tiempo la tasa de carga de archivos cayó casi a cero, como se puede ver en el gráfico. Esto sugiere que el conjunto de operaciones del usuario ejecutadas durante este período se pierde durante 120 segundos como máximo o, peor aún, agota el tiempo de espera y da como resultado un mensaje de error que se muestra al usuario final. Ya que la operación de reconstrucción de índices cuando RBS está habilitado en la base de datos es de solo 4 segundos, la ventana era tan pequeña que el impacto general no se notó. De hecho, la caída en el rendimiento tuvo tan poca importancia que resultó difícil representarla en el gráfico y por lo tanto no aparece en el gráfico de manera intencional. Mientras que esta prueba se realizó con una carga de archivos como carga de trabajo, el efecto en la disponibilidad del conjunto de servidores de SharePoint es el mismo en todos los tipos de transacciones.

5. Efectos de RBS en los tiempos de respuesta de transacciones de SharePoint Como se explicó en las secciones anteriores, habilitar la característica RBS da como resultado bases de contenido de SharePoint más pequeñas que, a su vez, requieren menos recursos en el servidor de bases de datos de SQL Server para ejecutar las consultas. Los recursos guardados se liberan para procesar las consultas existentes con más rapidez y para atender más consultas. En la prueba cuyos resultados se resumen en esta sección, se midieron los efectos de habilitar RBS en los tiempos de respuesta de transacciones. Para esta prueba, se usó la carga de trabajo de combinación de transacción completa de SharePoint, que se explica en la sección Metodología de prueba. Esta carga de trabajo se ejecutó en 6 controladores de carga que simularon una carga de usuario de 100 usuarios que ejecutan la transacción de SharePoint en promedio cada 15 segundos. Cada prueba se simuló durante 5 minutos y luego se ejecutó continuamente durante 2 horas. Los tiempos de respuesta promedio se © 2011 Microsoft Corporation. Todos los derechos reservados. Página 21 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

midieron durante todo el rendimiento de 2 horas con estado de equilibrio de la prueba. Estos resultados de alto nivel se muestran en la Tabla (xi) a continuación. Métrica

Sin RBS

Con RBS

Reducción

Carga de usuario máx.

100

100

0.0%

Solicitudes/sg

84

84.3

-0.4%

Solicitudes con error

0

0

Tiempo de respuesta prom.

28 msg

21 msg

25.0%

Pruebas/sg

6.4

6.42

-0.3%

Tiempo de página prom.

210 msg

160 msg

23.8%

0.0%

Tabla (xi): métricas de prueba de tiempo de respuesta de transacciones

El tiempo de respuesta promedio en todas las transacciones fue 25 % menos (28 milisegundos vs. 21 milisegundos) cuando RBS estuvo habilitado en la base de datos de contenido. Esto sugiere que cuando RBS estuvo habilitado en promedio los tiempos de respuesta de usuario final de las transacciones de SharePoint fueron 25 % más rápidos en toda la variedad de transacciones. Dado que la productividad y la satisfacción de los usuarios de SharePoint a menudo dependen de los tiempos de respuesta de transacciones de SharePoint, una reducción del 25 % daría como resultado niveles más altos de productividad y satisfacción. En la Tabla (xii) a continuación se desglosan en más detalle los tiempos de respuesta para cada una de las catorce transacciones de usuario final.

Transacción

% de transacción

Tiempo de transacción prom. (sg) Sin RBS

Reducción

Con RBS

Mi sitio público

16.0%

0.14

0.08

42.9%

Página de inicio

25.0%

0.43

0.22

48.8%

Flujo de trabajo de página

1.1%

109.00

109.00

0.0%

Crear página

6.0%

15.72

15.67

0.3%

Crear sitio de publicación

1.0%

13.00

12.70

2.3%

Crear sitio de equipo

1.0%

17.90

18.30

-2.2%

12.2%

4.03

4.03

0.0%

6.9%

29.84

29.90

-0.2%

Página grande

10.1%

0.12

0.09

25.0%

Consulta de búsqueda

14.8%

60.00

60.10

-0.2%

Administrador de sitio

1.0%

0.45

0.31

31.1%

Cargar documentos

4.9%

30.20

30.50

-1.0%

Descargar documento Perfil de edición de Mi sitio

Tabla (xii): tiempos de respuesta de transacciones

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 22 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Figura (ix): tiempos de respuesta de transacciones

Como se muestra más arriba, los tiempos de respuesta promedio para 10 de las 14 transacciones fueron iguales o mejores cuando RBS estuvo habilitado, con cuatro de las transacciones que presentaron una mejora cercana al 50 %. Para las cuatro transacciones que retrocedieron en cuanto al rendimiento, este retroceso fue de menos del 2,2 %, que muy posiblemente un usuario real no lo percibiría. En general cuando RBS está habilitado, se puede esperar ver una mejora en el rendimiento para archivos de gran tamaño, especialmente para sistemas enlazados de E/S ya que E/S se redirige desde la base de datos de SQL Server. Para archivos de menor tamaño, puede presentarse una degradación relativa del rendimiento ya que WFE debe emitir dos solicitudes en el cable en contraposición con una sola. Sin embargo, la expectativa es que el incremento relativo no sería observable por más que la diferencia porcentual fuera grande ya que los tiempos de acceso de archivo son insignificantes en primer lugar.

6. Efectos de RBS en la operación de rastreo La búsqueda constituye una parte integral de la mayoría de implementaciones de SharePoint y uno de los servicios de SharePoint con más uso intensivo de recursos. Muchas implementaciones empresariales tienen un gran porcentaje de usuarios que obtienen acceso a datos mediante la navegación desde el portal de búsqueda en contraposición con obtener acceso al sitio o documento directamente. Este comportamiento da como resultado un uso intenso de la búsqueda y no es ninguna sorpresa que muchos clientes afirmen que la búsqueda se convirtió en su cliente de recursos número uno, o que es a menudo un cuello de botella. Existen dos componentes en la búsqueda de SharePoint Server: rastreo de búsqueda y consulta de búsqueda. El proceso de rastreo de búsqueda implica rastreadores que rastrean el corpus de búsqueda y © 2011 Microsoft Corporation. Todos los derechos reservados. Página 23 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

construyen (o actualizan) el índice de búsqueda. El índice de búsqueda de SharePoint consta de dos partes, una base de datos de búsqueda y un archivo de índice de búsqueda plano. Las consultas de búsqueda a su vez utilizan el índice y la base de datos de búsqueda para devolver las consultas de búsqueda del usuario. En los resultados de las pruebas que se resumen en esta sección, se midió el tiempo empleado en rastrear el corpus de búsqueda mediante un solo servidor de aplicaciones que usa configuración de búsqueda integrada. Los resultados para el tiempo empleado con y sin RBS se resumen en la Tabla (xiii) a continuación. Los resultados de consulta de búsqueda se resumieron en la sección anterior y, por lo tanto, no se repiten aquí.

Operación Rastreo completo de búsqueda

Cant. de objetos

Sin RBS

Con RBS

Reducción

503,206

150 minutos

146 minutos

2.7%

Tabla (xiii): tiempos de rastreo de búsqueda

Figura (x): resumen de rastreo completo de búsqueda

Como se puede ver en los resultados de arriba, habilitar RBS en las bases de datos del corpus de búsqueda tiene un efecto muy insignificante en el rendimiento, aumentando el rendimiento en tan solo un 2,7 %. Esto se alinea con nuestras expectativas porque el procesamiento realizado en ambos casos es aproximadamente el mismo.

7. Efectos de RBS en el rendimiento de la carga de archivos La cantidad de tiempo empleado en cargar archivos de gran tamaño en SharePoint Server a menudo es un factor inhibitorio para aquellos usuarios que cargan grandes cantidades de contenido. La queja más común es que copiar un archivo a un recurso compartido de archivos de Windows a menudo es más rápido en orden de magnitud que cargar el mismo archivo en SharePoint Server. Uno de los motivos de esto es que, de manera predeterminada, todo el contenido del archivo se almacena en la base de datos de SQL Server, y que tiene una sobrecarga asociada con esto. Además, dado que la base de datos de SQL Server funciona en un modelo transaccionalmente coherente, se ve forzada a registrar el blob completo en el registro de transacciones de SQL Server, además de almacenar la copia real de él en la base de datos, lo que da como © 2011 Microsoft Corporation. Todos los derechos reservados. Página 24 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

resultado el doble de carga de E/S en el sistema. RBS aumenta significativamente el rendimiento de las cargas de archivos para archivos de gran tamaño, ya que externaliza el blob directamente desde el WFE y por lo tanto se minimiza la carga de E/S en el sistema de SQL Server. En los resultados de las pruebas que se resumen en esta sección, se modeló una implementación de administración activos digitales de SharePoint y se midió el rendimiento de cargar archivos grandes de 1 MB a 1,99 GB con y sin RBS habilitado. Los resultados para el tiempo empleado en cargar los archivos con y sin RBS se muestran en la Tabla (xiv) a continuación.

Tamaño de archivo

Tiempo empleado en cargar archivo (segundos)

Reducción

Sin RBS

Con RBS

1 MB

1.2

1.0

16.7%

100 MB

12.2

9.7

20.5%

500 MB

55

28.8

47.6%

1 GB

69.4

48

30.8%

1,5 GB

138

71

48.6%

1,99 GB

178

87

51.1%

Tabla (xiv): tiempos de carga de archivo

Figura (xi): tiempos de carga de archivo.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 25 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Como la tabla y el gráfico muestran, el tiempo empleado en cargar un archivo con RBS es entre 15 % y 50 % más rápido que cuando RBS no estaba habilitado. En términos absolutos, esto se traduce a un archivo de 1,99 GB que tarda 87 segundos en comparación con los 178 segundos para cargar. Esto es importante para los usuarios de centros de registro que cargan archivos considerando que a menudo simplemente esperan delante de sus exploradores web hasta que la operación se complete antes de continuar con sus actividades. Con cientos de usuarios en una organización, cada uno realizando en decenas de estas operaciones, los ahorros en tiempo y los beneficios se suman en seguida, y son particularmente notables cuando hay un cuello de botella de recursos en el servidor. Ventajas similares se aplican también a las operaciones de descarga de archivos, aunque con las descargas de archivos el sistema de SQL Server y el WFE de SharePoint almacenan en búfer los datos de archivos, lo que hace que se gasten menos recursos en el almacenamiento del back-end.

8. Tiempo requerido para migrar datos Una vez que RBS está habilitado en una base de datos, todos los archivos cargados o modificados se externalizan automáticamente en el almacén de blobs RBS asociado con el proveedor activo. Los objetos que se almacenaron anteriormente en la base de datos siguen estando allí, y se puede obtener acceso a ellos desde el interior de la base de datos; no se migran automáticamente hacia el almacén RBS. En esta configuración, SharePoint facilita un acceso sin problemas tanto a los archivos que se externalizaron mediante RBS, como a los que aún están almacenados en la base de datos. Mientras que el mecanismo anterior funciona bien, con el paso del tiempo, es posible que los usuarios deseen migrar todo el contenido existente que puede estar almacenado en la base de datos al almacén RBS externo; o bien, es posible que deseen migrar todo el contenido de RBS externalizado de nuevo a la base de datos. Ambas operaciones pueden realizarse con el cmdlet Migrate() de Windows PowerShell™ 2.0 que se proporciona con SharePoint Server 2010. La secuencia exacta de comandos de Windows PowerShell que se deben ejecutar se muestra en el script a continuación.

$cdb=Get-SPContentDatabase $rbss=$cdb.RemoteBlobStorageSettings $rbss.GetProviderNames() $rbss.SetActiveProviderName($rbss.GetProviderNames()[0])3 $rbss.Migrate() Estos pasos deben ejecutarse para cada base de datos en la que desee migrar los blobs. La ejecución del script de Windows PowerShell cuando el proveedor de RBS está habilitado ocasiona que los blobs se migren afuera de la base de datos y adentro del almacén RBS, mientras que la ejecución del script de Windows PowerShell cuando el proveedor está deshabilitado ocasiona que los blobs se migren nuevamente adentro de la base de datos.

3

Nota: $rbss.GetProviderNames()[0]corresponde al proveedor de RBS de StorSimple.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 26 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

Considerando que una base de datos de contenido pueden tener miles o incluso millones de objetos almacenados, se debe evaluar cuidadosamente el paso por seguir antes de migrar los datos ya que podría tardarse mucho tiempo en completar las operaciones. Se recomienda ejecutar el cmdlet Migrate() durante las horas de poca actividad y desde un servidor de aplicaciones o WFE de SharePoint que no se esté utilizando en gran medida. En nuestras pruebas, se ejecutó el script anterior desde el servidor de aplicaciones para migrar 500.000 objetos de SharePoint, cada uno con un tamaño promedio de 100 KB, adentro y afuera de la base de datos. Los resultados de dichas pruebas se resumen en la Tabla (xv) a continuación.

Operación

Tiempo empleado (minutos)

Blobs migrados por segundo

Migrar datos desde base de datos de contenido hasta almacén de blobs (externalizar datos)

243

34.3

Migrar datos desde almacén de blobs hasta base de datos de contenido (internalizar data)

504

16.5

Tabla (xv): tiempos de migración de blobs de RBS

Se atribuyó el tiempo adicional empleado en migrar datos hasta la base de datos de contenido al procesamiento de SQL Server y SharePoint Server adicional que se necesitaba realizar en el back-end. Para asegurar que los resultados fueran comparables y para no dejar de cumplir con los requisitos de soporte de Microsoft, no se realizó ningún ajuste adicional en la base de datos de SQL Server más allá del mencionado en la sección de configuración de software. El método Migrate de RBS puede reiniciarse y comenzará a migrar los blobs adentro o afuera de la base de datos desde la ubicación donde dejó la última vez que se lo invocó.

Conclusión En estas notas del producto, se vio de qué manera el uso de RBS puede ayudar a reducir el tamaño efectivo del tamaño de copia de seguridad y base de datos de contenido de SharePoint en más del 95 %, lo que reduce el tiempo de copia de seguridad en una cantidad equivalente a la vez que proporciona la opción de usar un almacenamiento más económico para almacenar los datos BLOB. También se vio de qué manera la característica RBS ayuda a los usuarios para almacenar archivos multimedia grandes en SharePoint Server y obtener todos los beneficios de SharePoint Server sin provocar un cuello de botella en la base de datos de SQL Server y sin hacer que la solución sea tan costosa que no se pueda usar. También se analizaron los efectos de RBS en los tiempos de rastreo de búsqueda, rendimiento de la tarea de mantenimiento de reconstrucción de índices (reducido un 96 %), y los tiempos de respuesta de transacciones del usuario final (que se redujeron un 30 % o más para algunas transacciones). Por último,

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 27 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).

Microsoft SharePoint Server 2010

abril de 2011

se midieron el rendimiento de carga de archivo multimedia individual de gran tamaño y el tiempo empleado en migrar los datos BLOB adentro y afuera de la base de datos con RBS. En general, se encontró que el uso de RBS ayuda con las tareas de mantenimiento de un conjunto de servidores de SharePoint a la vez que mejora la escalabilidad de la solución. Esto a su vez da como resultado ahorros de costos y una mejor experiencia del usuario final. Sin embargo, cuando se usa RBS en operaciones de mantenimiento como copias de seguridad del almacén de blobs, se debe planear con atención y calcular en la lista de tareas de mantenimiento.

Recursos adicionales Información general de almacenamiento remoto de blobs: http://technet.microsoft.com/enus/library/ee748649.aspx Migrar contenido adentro o afuera de RBS: http://technet.microsoft.com/en-us/library/ff628254.aspx Optimizador de base de datos de SharePoint StorSimple: http://www.storsimple.com/ Pruebas de carga de rendimiento de Microsoft Office SharePoint Server 2007:http://sptdatapop.codeplex.com/releases/view/1214#DownloadId=6918 Microsoft® SQL Server® 2008 R2 Feature Pack: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5aae0c5c83d52

Acerca de StorSimple La solución de StorSimple resuelve problemas clave relacionados con el almacenamiento en cuanto a rendimiento, escalabilidad, capacidad de administración, protección de datos, y costo para Microsoft SharePoint Server 2010. StorSimple le brinda exclusivamente la capacidad de implementar un almacenamiento local de próxima generación para hacer frente a los desafíos actuales relacionados con las aplicaciones a la vez que le brinda la capacidad de aprovechar el almacenamiento en la nube, ya sea público o privado, cuando usted esté listo. Puede encontrar más información acerca de StorSimple en www.storsimple.com.

Acerca de Microsoft Microsoft Corporation es una corporación pública multinacional con sede en Redmond, Washington, EUA, que desarrolla, fabrica, licencia y brinda soporte para una amplia variedad de productos y servicios relacionados primordialmente con la informática a través de sus divisiones de productos diferentes.

© 2011 Microsoft Corporation. Todos los derechos reservados. Página 28 Para hacer comentarios sobre estas notas del producto o para solicitar más documentación sobre estas características, póngase en contacto con SharePoint IT Docs ([email protected]).