Rendimiento de RBS de SQL Server con SharePoint Server...

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

© 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]).

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.





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





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.





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,





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/en-

us/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

http://technet.microsoft.com/es-es/library/cc262787.aspx#ContentDB

http://technet.microsoft.com/es-es/library/cc262787.aspx#ContentDB





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

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.





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%





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).

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).

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





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 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:\

1 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.

http://www.storsimple.com/





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.

Rol de equipo

Software Cambios adicionales

Servidores de

aplicaciones y

WFE

Windows Server® 2008 R2

Enterprise x64

Microsoft SharePoint Server 2010

RBS.msi se instaló desde el SQL

Server 2008 R2 Feature Pack.

Se aplicaron todas las últimas

revisiones de Windows Server.

Servidor de

bases de

datos

Windows Server 2008 R2 Enterprise

x64

SQL Server 2008 R2 Enterprise x64

Se aplicaron las últimas revisiones de

Windows Server.

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.





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%

Tamaño de datos externalizados de RBS -- 96.2 --

Tamaño de base de datos (1 TB) 2,292 26 98.9%






(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%

Tamaño de datos externalizados de RBS -- 1,115 --

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





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.

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.

Figura (v): tamaño de volumen de recurso

compartido de archivos de RBS





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, NAME =

N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;

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


(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%

Tamaño de copia de seguridad de SQL Server con

compresión (100 GB) 71.5 0.7 99.1%

Tamaño de almacén de blobs (100 GB) 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%

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

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

2La 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.





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





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

Tamaño de archivo de datos de base de datos 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


Tiempo para restaurar base de datos desde copia

de seguridad comprimida


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 --

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





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, NAME =

N'WSS_Content-Full Database Backup', SKIP, NOREWIND, NOUNLOAD;

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;





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





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.





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





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 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%

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) Reducción

Sin RBS 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%

Descargar documento 12.2% 4.03 4.03 0.0%

Perfil de edición de Mi sitio 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%

Tabla (xii): tiempos de respuesta de transacciones





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





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 Cant. de objetos Sin RBS Con RBS Reducción

Rastreo completo

de búsqueda

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





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.





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 <ContentDbName>

$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.





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,





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/en-

us/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-83f5-

aae0c5c83d52

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.

http://technet.microsoft.com/es-es/library/ee748649.aspx

http://technet.microsoft.com/es-es/library/ee748649.aspx

http://technet.microsoft.com/es-es/library/ff628254.aspx


http://sptdatapop.codeplex.com/releases/view/1214#DownloadId=6918

http://www.microsoft.com/downloads/details.aspx?displaylang=es&amilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52

http://www.microsoft.com/downloads/details.aspx?displaylang=es&amilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52


Date post:	03-Sep-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Rendimiento de RBS de SQL Server con SharePoint Server...

Documents