Acerca de StorSimple

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 .....................................................................................................................9
Configuración de almacenamiento .......................................................................................................... 10
Configuración de software..................................................................................................................... 10
Resultados de las pruebas y observaciones .......................................................................................................... 11
1. Efectos de RBS en el tamaño de las bases de datos de SQL Server ............................................................... 11
2. Efectos de RBS en el tamaño de copias de seguridad de bases de datos ........................................................ 14
3. Efectos de RBS en los tiempos de creación de copias de seguridad y restauración .......................................... 16
4. Efectos de RBS en el rendimiento de la reconstrucción de índices ................................................................. 18
5. Efectos de RBS en los tiempos de respuesta de transacciones de SharePoint ................................................. 20
6. Efectos de RBS en la operación de rastreo ................................................................................................. 22
7. Efectos de RBS en el rendimiento de la carga de archivos ........................................................................... 23
8. Tiempo requerido para migrar datos ......................................................................................................... 25
Conclusión....................................................................................................................................................... 26
Recursos adicionales ......................................................................................................................................... 27
Acerca de StorSimple........................................................................................................................................ 27
Acerca de Microsoft .......................................................................................................................................... 27
© 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.
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
© 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
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
© 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
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

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
© 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
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.
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
© 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
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.
© 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
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).
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
© 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
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
datos de búsqueda
S:\
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
1
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
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
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
© 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
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
--
Tamaño de base de datos (1 TB)
2,292
26
98.9%
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
Tamaño de datos externalizados de RBS
Tabla (vi): tamaños de archivos y bases de datos
© 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
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.
© 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
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.
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)
Sin RBS
Con RBS
Reducción
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 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
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
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
© 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
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
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%
Tamaño de archivo de datos de base de datos
© 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
Tiempo para restaurar base de datos desde copia
de seguridad comprimida
abril de 2011
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
--
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 %
© 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
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;
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
© 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
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.
© 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
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 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
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 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
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 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
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 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
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 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
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.
© 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
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 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
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 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]).