SharePoint, Sistemi

SharePoint 2010 SP1… la rivincita di RBS

Fin dalla prima beta di SharePoint 2010 mi sono accorto che una delle nuove funzionalità che poteva far crescere gli scenari d’adozione della tecnologia era quella dell’RBS (Remote BLOB Storage).

In poche parole si tratta della possibilità di decidere che per specifici Content DB i dati BLOB (es. la parte “pesante” dei documenti) fosse salvata fuori dal Content DB, su un file system disponibile al SQL Server, lasciando su DB solo i metadata e la parte descrittiva dei documenti, con relativo “puntatore” al file salvato su disco.

Uno dei primi progetti che abbiamo realizzato (già sulla Beta 2 di SP 2010) è stato un sistema DAM (Digital Assets Management), sfruttando così le maggiori capacità di archiviazione di SharePoint, aprendo così nuovi scenari difficilmente pensabili su MOSS 2007.

Insieme a Claudio ho anche scritto un capitolo del libro Real World SharePoint 2010: Indispensable Experiences from 22 MVPs, ed un articolo su SharePointCommunity.it.

Se ne è parlato parecchio insomma di RBS… ma più di una volta (in particolar modo da persone di Microsoft) mi è stata suggerita prudenza…

I timori maggiori derivavano da un solo parziale supporto a fronte di “scenari estremi”, sicuramente poco testati, ed a una maggiore complessità di gestione amministrativa per le tematiche di data protection (backup/restore) e disaster recovery.

Ora, con il rilascio dei Service Pack 1, una delle novità introdotte è proprio legata al mondo RBS.

La funzionalità “Shallow Copy”, ad esempio, permette la ritrutturazione di site collections verso Content DBs dove è attivato RBS.

Inoltre, come descritto ampiamente da un recente post pubblicato sul Blog del Team di prodotto, si sono aperti nuovi scenari per il capacity planning ed il dimensionamento dell’infrastruttura SharePoint 2010:

  • Il limite suggerito dalle best practices per la crescita di ogni singolo Content DB resta di 200 GB (come prima dell’SP1), senza richiedere nessuna particolare attenzione o requisito.
  • Le nuove specifiche delle guidance aprono scenari di crescita oltre il “confine” dei 200 GB per Content DB, introducendo una serie di requisiti aggiuntivi:
    • per scenari di crescita fino a 4 TB (!):

      • Requires disk sub-system performance of 0.25 IOPS per GB, 2 IOPS per GB is recommended for optimal performance.

      • Requires the customer to have plans for high availability, disaster recovery, future capacity, and performance testing.

      • And you need to review additional considerations in the TechNet Boundaries and Limits article.

    • per scenari oltre i 4 TB (!!):

      • harePoint sites must be based on Document Center or Records Center site templates and must be an archive scenario where less than 5% of content is actively read from each month and less than 1% of content is actively written to.
      • Do not use alerts, workflows, link fix-ups, or item level security on any SharePoint objects in the content database. Note: document archive content databases can be the recipient of documents as a result of Content Routing workflow.
  • Inoltre è stato elevato il limite del numero di items per singolo Content DB, portanto il valore a 60 milioni.
  • Infine è stato rimosso il limite di 5 TB per per singola istanza SQL Server.