SharePoint 2013: Dimensionado del tamaño de BDs de Contenidos (I)!

Un tema muy recurrente en conversaciones con clientes es en torno al dimensionamiento de las Bases de Datos (BDs) de Contenidos bien porque actualmente están usando SharePoint y tienen grandes volúmenes de información en dichas BDs por diversas cuestiones o bien porque están pensando en dar el salto hacía un sistema de gestión documental como SharePoint y tienen unos requerimientos de almacenamiento muy fuertes (del orden de Terabytes). En estas conversaciones, mis respuestas a las dudas y cuestiones planteadas siempre giran en torno a las capacidades de SharePoint 2013 que siempre tenemos que tener en la cabeza para disipar toda duda en torno a cuanto puede almacenar SharePoint, las recomendaciones en los tamaños de las BDs de contenidos, etc. En este post, voy a comentar mis recomendaciones al respecto a partir de la lecutra de este estupendo post de Sahil Malik:

• Antes de hablar de si SharePoint es capaz o no de guardar grandes volúmenes de información, lo primero que hay que transmitir es que es fundamental un buen diseño de la arquitectura de la información que permitirá dar respuesta a esa inquietud inicial. Se trata de pensar en la jerarquía lógica de SharePoint y en base a la misma diseñar como tiene que ser el acceso a la información en la organización. Estoy pensando por supuesto en la siguiente imagen que tenemos que visionar mentalmente:

• Con esta premisa inicial, en nuestro diseño tenemos que tener muy presentes los límites de SW de SharePoint 2013 y es aquí dónde podremos empezar a responder a las dudas e inquietudes de nuestros clientes. En lo que a tamaño de las BDs de contenidos, dichos límites establecen recomendaciones dependiendo del escenario concreto y también hasta dónde podemos llegar con el producto:
  • La recomendación general es qué para escenarios de colaboración, el tamaño de las BDs de contenidos no supere los 200 GB de tamaño para asegurar un buen rendimiento, que no haya problemas en las copias de seguridad, etc. Por lo tanto, si en nuestro diseño tenemos en cuenta esta recomendación, no tendremos problemas de rendimiento y tampoco en la realización de copias de seguridad. Así, si por ejemplo las necesidades de almacenamiento son superiores a los 200 GB por BD de Contenidos, podemos proponer un diseño en el que haya más de una BD de Contenidos por Aplicación Web teniendo en cuenta el máximo número de BDs de Contenido a nivel de granja es de 500.
  • Si se dispone del HW adecuado, para escenarios de uso general de SharePoint el tamaño de las BDs de contenidos se puede “estirar” bastante y podemos llegar a 4 TB por BD de contenidos teniendo en cuenta que:
    • Necesitamos disponer del HW adecuado en cuanto a rendimiento de operaciones en disco (IOPS). Si tenemos una tasa mínima de 0.25 IOPS por GB, podremos llegar a 4 TB. Digo mínima, porque Microsoft recomienda un valor de 2 IOPS por GB.
    • Lo siguiente que tendremos que tener en cuenta es la realización de copias de seguridad. Lógicamente, si nos vamos al entorno de los 4 TB de información en BDs de Contenido tendremos que recurrir a sistemas alternativos de backup al nativo de SharePoint que aseguren su correcta realización y en un tiempo razonable.
    • Toda personalización que se haga puede penalizar un despliegue SharePoint con esos tamaños de BD.
  • Finalmente, para escenarios de archivado Microsoft establece que no hay límite en los tamaños de las BDs teniendo en cuenta las siguientes restricciones:
    • Se dispone del HW de alto rendimiento en cuanto a IOPS comentado anteriormente,
    • Los sitios de SharePoint creados están basados en las plantillas Document Center o Records Center.
    • Menos del 5 % del contenido de la BD de contenidos se accede en media cada mes y menos del 1 % del contenido se modifica o escribe cada mes en media.
    • No se pueden usar alertas, flujos de trabajo, seguridad a nivel de elemento, etc.
• A partir de esta información tenemos que dimensionar adecuadamente los tamaños de las BDs de Contenidos teniendo en cuenta aspectos adicionales que Sahil menciona en su post y que normalmente los clientes van a requerir:
  • Agilidad en la realización de copias de seguridad.
  • Cuanto más grande es una BD de contenidos, más posibilidades hay de que contenga objetos huérfanos que pueden dar problemas al realizar esas copias de seguridad.
  • Desde el inicio hay que dimensionar cuál va a ser el tamaño de las BDs de Contenido, lo que es especialmente importante para escenarios de colaboración. La fórmula que Sahil utiliza para hacer el dimensionado la podéis encontrar aquí: http://technet.microsoft.com/en-us/library/cc298801.aspx
  • Tener en cuenta en el dimensionado que no solo influyen los documentos que se van a almacenar, sino también el contenido en las papeleras de reciclaje, la información generada por funcionalidades como la auditoría, etc.
  • Ajustarte a las recomendaciones establecidas por Microsoft en cuanto a tamaños de las BDs de Contenido y también basarte en la experiencia previa en otros clientes. Fijaros como Sahil rebaja el tamaño de la BD de Contenidos de 200 GB a 100 GB para asegurar que no hay problemas.
• Revisar la documentación disponible sobre BDs de Contenido de SharePoint 2013 y sobre planning:
  • Database types and descriptions
  • Storage and SQL Server capacity planning and configuration
  • Capacity management and sizing overview

Finalmente, os dejo este estupendo recopilatorio en torno a dimensionado y planning de capacidad para ShrePoint 2013: Sizing and Capacity Planning for SharePoint 2013 – Resources. Y hasta aquí llega este primer post sobre dimensionado de BDs de Contenidos en SharePoint 2013.