sábado, 20 de febrero de 2010

MSS 2010: Remote BLOB storage (RBS)

¿Que es un BLOB? El acrónimo viene de Binary Large OBject (Objetos Grandes Binarios) y se define como la corriente de datos asociada a un fichero (es el fichero en sí mismo).

En SharePoint, como todos sabemos, los BLOBs se guardan out-of-the-box directamente en una base de datos SQL Server. Dicho de otro modo, cuando subimos un fichero a SharePoint, este queda almacenado en el SQL. Esto permite que copiando una base de datos de contenido podamos recrear portales enteros con todos sus contenidos (ficheros, imágenes, vídeos, etc.), pues absolutamente TODA la información de contenido está embebida en la propia Base de Datos. El esquema de funcionamiento vendría representado por el siguiente diagrama:

El almacenamiento de BLOBs en el SQL Server es una de las mayores polémicas que suscita el uso de SharePoint. A muchas empresas (sobre todo las más grandes) no les gusta que todos sus datos estén incluidos en una o varias bases de datos. ¿Qué sentido tiene embeber en un SQL un vídeo de 300MB? ¿Qué sentido tiene verse obligado a manejar bases de datos de crecimiento exponencial de varios TB? (con la carga adicional de mantemiento que conlleva administrar esas BD )

Hay que tener en cuenta que los BLOBs suelen ocupar entre el 60 y el 70% del total del contenido de una intranet, y puede ser superior en proyectos donde el protagonismo lo lleven las librerias de documentos y Record Centers.

Entre los principales problemas que suponen almacenar los BLOBs en las bases de datos de contenidos es el impacto en el rendimiento del propio SQL Server (hace un uso intensivo del disco al estar continuamente cargando los ficheros que contiene), impactando por consiguiente en todo el rendimiento de nuestra granja de servidores. Otro factor es el coste de manejabilidad de nuestras copias de seguridad y restauración, debido al inmenso tamaño que adquieren las Bases de Datos que contienen todos los BLOBs.

En SharePoint 2007 SP1 ya existía la posibilidad de que los BLOBs no se almacenaran directamente en el SQL y lo hicieran de forma totalmente externa. A ese servicio le llamábamos External Blob Storage (EBS).

Sin embargo SharePoint 2010 mejora el EBS en múltiples aspectos, consiguiento un tratamiento muy mejorado de los BLOBs externalizados llamado Remote BLOB Storage (RBS). A continuación se muestra una tabla que narra la evolución de los BLOBs remotos en las diversas versiones de SharePoint:


SharePoint 2010 también soporta EBS, aunque está catalogado como "deprecated", y no estará soportado en futuras versiones (RBS sí que tiene soporte garantizado en futuras versiones de SharePoint).

En la siguiente tabla se mustran las diferencias más destacadas entre el antiguo EBS y el nuevo RBS:


¿Cómo funciona realmente RBS en SharePoint 2010? Es indispensable que un proveedor externo de blobs nos proporcione una API en forma de add-in descargable (en nov. 2009 ya estaban disponibles EMC²; OpenText; AvePoint; Commvault y NetApp). El almacenamiento para todos los BLOBs en las Bases de Datos de contenido estará disponible cuando activamos la API del proveedor y a partir de entonces, los clientes pueden elegir el proveedor de BLOBs que van a utilizar.

De hecho, lo único que se almacena en el SQL Server cuando se ha activado el RBS son los metadatos propios del item y su BLOB ID. Con este BLOB ID podremos posteriormente recuperar el BLOB en questión en sistema de almacenamiento de BLOBs proporcionado por cada proveedor. A continuación se muestra un esquema de un flujo típico de escritura mediante RBS:

Para instalar RBS en SharePoint 2010 necesitaremos disponer de un SQL Server 2008 R2, donde instalaremos el Add-in de RBS en el propio SQL Server. Después instalaremos las librerías (.dll) de las APIs del BLOB del proveedor en cada servidor frontal (WFE). Finalmente activaremos el RBS utilizando PowerShell (todo el RBS se administra con PowerShell).

Para mantener el RBS se instalará un recolector de basura (garbage collector) en el propio SQL o un WFE de SharePoint que se encargará de realizar las tareas de mantenimiento. Este recolector se podrá activar periodicamente mediante un procedimiento programado (schedule) y que podrá parametrizarse con políticas de retención

A modo de conclusión, podemos decir que el uso de RBS proporciona las siguientes ventajas destacadas:
  1. Capacidad de almacenar los BLOBs de forma separada a los metadatos
  2. La gestión del almacenamiento de datos se realiza independientemente del SQL Server, con la liberación de carga de trabajo y aumento de "performance" que conlleva este hecho en nuestra granja de MSS 2010.
  3. Aprovecha las ventajas de las características de almacenamiento avanzado de datos que proporcionan los proveedores de BLOBs externos (expurgar, múltiples localizaciones de almacenamiento, escrituras inmutables, garantía de retención, garantía de supresión, etc.)
  4. Administración jerárquica del almacenamiento: El uso de SQL y diversas capas de BLOBs se supone que ahorran costes en CapEx y OpEx .Este tipo de administración también proporciona patrones de acceso eficientes para el tratamiento de datos.

Realmente parece que el RBS va a ser mucho más fácil de implantar que el EBS, más fácil de administrar (PowerShell), más eficiente y con mayor soporte de los diversos proveedores de BLOBs. Personalmente estoy deseando poderlo probar en alguna implantación real y comprobar así la eficiencia de tener los archivos en repositorios externos, utilizando el SQL Server solo para almacenar los metadatos y otros tipos de elementos menos pesados del SharePoint.
¡Saludos!

8 comentarios:

jmcvasco@hotmail.com dijo...

Hola Ignasi, queria consultarte sobre la vulnerabilidad que salio hace unas semanas MS10-039 Vulnerabilities in Microsoft SharePoint Could Allow Elevation of Privilege
(2028554).

Si tenemos que tener en cuenta algun procedimiento ya que no tiene rollback este parche, si toca el Esquema de Base de Datos?.

Yo tengo Microsoft Office Sahrepoint 2007 SP2
Saludos coordiales.

Ignasi Tebé Tena dijo...

Saludos compañero, lamento decirte que no tengo ninguna información al respecto. Lamento no poder ayudarte en este tema concreto.

un saludo!

Ana dijo...
Este comentario ha sido eliminado por el autor.
Ana dijo...

Hola Ignasi!
Me ha parecido muy interesante tu artículo sobre RBS en MSS 2010. Podrías decirme si has tenido oportunidad de probarlo finalmente? estoy documentándome sobre FILESTREAM y la verdad es que me ayudaría mucho contar con tus experiencias para planificarlo lo mejor posible!
Muchas gracias, tienes un blog estupendo.

Ana dijo...

También me gustaría saber si este sistema de RBS es recomendable cuando la mayoría de los ficheros que manejamos en la intranet no son multimedia, que son los que más pesan en principio. Qué hay de usar RBS para el resto de documentos? Office, pdf, etc...
Gracias!

Ignasi Tebé Tena dijo...

Hola Ana, gracias por tus elogios. Comentarios como los tuyos son los que nos animan a continuar compartiendo el conocimiento.

Lamento decirte que no he podido profundizar en el tema más allá de lo que lo hice en su momento para publicar el post. Sigo trabajando en proyectos de SharePoint 2010, pero cada vez más desde la capa de jefatura, y en ninguno de ellos hemos planteado todavía un RBS...

Si tengo ocasión de testearlo no dudes que sacaré un nuevo post.

Saludos!

Ana dijo...

Muchas gracias Ignasi, seguiré consultando tu blog porque hacéis un trabajo estupendo.

Alberto Muñoz dijo...

Hola Ignasi, sobre el tema de RBS, sabes si hay alguna forma de conectar el RBS con alguna ubicacion NAS tipo "\\nas\recursocompartido"??????
O solo es posible utilizando las api que comentas????
Gracias y felicidades por el blo