Ariel Kirsman

Office.com sobre SharePoint

Agenda

• Qué es Office.com

• SharePoint como plataforma

• Lecciones aprendidas

• Conclusiones

• Q&A

Qué es Office.com

Soporte para usuarios finales de los productos Office (Word,

Excel, PowerPoint, etc).

Web Site + Web Services

500 autores de contenido...

Que administran 6 millones de páginas...

Que visitan 120 millones de usuarios distintos...

Que generan >3000 RPS (requests por segundo)...

Servidos por 48 farms de 4:1 al 60% de CPU

Distribuidas en 2 data centers (por geo-redundancy)

37 developers, 24 testers, 11 PM’s

Qué es Office.com

En números

Content Management System («Authoring») - donde los autores crean, administran y localizan el contenido,

Office.com («Rendering») – al cual los usuarios y las aplicaciones de Office se conectan,

Bulk Operations Framework – que permite procesar múltiples objetos de manera unificada,

Unified Warehouse - repositorio de sólo-lectura de todo tipo de metadata (de contenido, social, estadísticas de uso, etc) sobre el cual se ejecutan consultas, workflows y análisis.

Qué es Office.com

Vista Conceptual

Qué es Office.com

Vista de Componentes

...

Qué es Office.com

Vista de Datos Mig

ració

n

Mig

ració

n

Propagación de Contenido

Legacy

Authoring

Rendering

Qué es Office.com

Publishing

Llevar a SharePoint a una escala de Internet.

«Dogfooding»: si no es bueno para Microsoft, no es bueno para los clientes.

Implementar a un nivel mayor de abstracción

Deployment

Workflows

Queries

Search

Pero, ¿hacerlo con la versión 14 en desarrollo?

Desventaja: «moving target»

Ventajas

Colaboración del equipo de SharePoint.

Círculo virtuoso.

SharePoint como plataforma

Razones de la elección

En teoría, esta es la proposición de valor de SharePoint: integrar authoring y rendering de manera natural.

Pero no funciona para altos volúmenes de

Contenido

Creadores de contenido

Visitantes al sitio

¿Porqué?

Writes vs. Reads

Secure vs. Anonymous

Transacciones largas (check-in/out) vs. cortas

Solución: webapps y site collections separadas, y en Rendering

Denormalización

No versioning

Caching

Lecciones Aprendidas

Almacenamiento: Separación Authoring vs. Rendering

Todos los lenguajes ocupan aprox. 2TB.

Administrar la DB se vuelve más costoso a mayor tamaño

Backups

Mantenimiento (rebuild indexes, update statistics)

Problema: queries sobre múltiples site collections

Importante para el Localization team: «obtener todos los artículos que fueron asignados al vendor X y no fueron traducidos en una semana».

Solución: exportar metadata a SQL («Unified Data Warehouse»).

Dentro de cada site collection, un root web sin subsites

Sub-sites no ofrecen ventajas de administración de datos.

Look & Feel es consistente por lenguaje.

Lecciones Aprendidas

Almacenamiento: Site collection por lenguaje (Authoring)

Potencia de los Queries

performance.

expresividad.

A futuro, ¿SQL Server’s SPARSE columns?

Máximo de 2 columnas para compound indexes.

Diagnosibilidad de los Queries

e.g., bug cuando los CAML OR’s anidados superaban los 64 niveles

CAML erróneos (e.g., en SPSiteDataQuery) resultan en «default queries» en lugar de lanzarse una excepción.

Lecciones Aprendidas

Queries de SharePoint

Relaciones (aprox. 3M)

Todas las aplicaciones las tienen, y tienen atributos.

SharePoint no soporta nativamente este concepto.

Sin embargo, pudimos haber resuelto los mismos problemas con tagging y folders...

SharePoint no soporta

Logueo de cambios a nivel de configuración/sistema.

Logueo de items borrados en listas y bibliotecas.

Causa: Coupling - «change tracking» está implementado en términos de «version tracking».

Gran volumen de binarios en la base de datos afecta

Performance

Administración

Deberíamos haber implementado EBS.

Lecciones Aprendidas

Modelo de Datos

Cuando el volumen de updates de metadata es grande, pudimos observar problemas de contención

Excesivos SQL locks

Excesivas escalaciones de SQL locks

Lecturas lentas

SharePoint está optimizado para «long-running transactions», (e.g., check-in, check-out), stream de un item.

No está optimizado para cambios frecuentes en la metadata de los items.

Lecciones Aprendidas

Concurrencia y Locking

Muchas operaciones no se pueden hacer «de a muchos (items)», o los límites son artificialmente bajos (e.g., máximo de 100 items a la vez para upload).

uploads/downloads múltiples.

cambios de metadata.

SharePoint no posee «transactional inserts/updates/deletes» (i.e., realizarlos completamente o no realizarlos del todo).

Gran problema para migración de datos.

Lecciones Aprendidas

Bulk Operations

DB roundtrips

Cuándo se va a realizar un DB roundtrip, y cuánto cuestan (e.g., SPList.Items.Count vs. SPList.ItemCount)

fetchDocForHttpGet() trae metadata del ContentType.

RT adicional para fields fuera de él, no 3 RT’s/artículo

No SP* objects caching

Publishing APIs caching es costoso para 1er request.

Costo de list schema.

Event Receivers

La secuencia de eventos debería ser consistente.

No asumir nunca que otro event handler hizo su tarea.

Asincrónicos: no thread-safe, no cancelables.

Reglas complejas de disposing.

SharePoint loguea determinado «usage data» per request.

Metadata no es customizable (e.g., Asset ID)

Lecciones Aprendidas

Programming API

Problema: cómo propagar datos de un master DB a múltiples bases para lograr scale-out.

SQL Replication

Requiere primary keys en todas las tables de la base

SharePoint no las tiene

Export & Import, Content Migration API (PRIME) API: config DB data, check-out status, encuestas no completadas, etc.

Backup & DB Attach: latencia (i.e., tiempo de propagación desde authoring a rendering SQL’s).

Solución elegida: log-shipping.

Requiere poner DB offline.

Mayor latencia que SQL Replication.

Múltiples chequeos adicionales sobre la solución OOB.

Alto costo operacional – «baby-sitting»

Lecciones Aprendidas

Propagación de Contenido

Lecciones Aprendidas

Propagación de Contenido con Log Shipping

Instance

A

Instance

B

Log Shipping

Manager (scheduled tasks)

Master

.TRN’s

Switch B->A, así

B se pone al día

SQL

SQL Alias -> A

Lecciones Aprendidas

Propagación de Contenido con Log Shipping

Instance

A

Instance

B

Master

.TRN’s

Switch A->B, así

A se pone al día

SQL

SQL Alias -> B

Log Shipping

Manager (scheduled tasks)

Se usaron solutions packages y features.

Errores cometidos

Listas y content types se aprovisionaron («crearon») en base a un formato propio (no CAML)

Topología y features a instalar/activar se manejó con código + configuración custom

Complejidad => Errores.

Problemas en la migración de contenido entre versiones.

Alternativas

Usar CAML, site templates y restringir código sólo a feature activation/deactivation, minimizando external scripts.

Ausencia de varias VS tools para SP al inicio del proyecto

Lecciones Aprendidas

Deployment

Authoring: built-in authentication/authorization

Mantener autorización simple es fundamental

Limitar granularidad, minimizar «break inheritance»

Usar domain groups en lugar de domain users.

Problema: acceso de usuarios fuera del dominio.

Solución: Live ID on Claims.

Finalmente, no en producción (Claims no nos llegó a tiempo)

Rendering: acceso anónimo, Live ID para identificar usuarios

Necesita ser «Partner site» para acceder al perfil de usuario.

Lecciones Aprendidas

Security

Curva de aprendizaje de SharePoint

1. Aprender

2. Aprender a hacerlo bien

Perf Testing fue clave para el avance del proyecto

Regresiones (# de DB RT’s)

Plan de capacidad

Topología de farm.

Lecciones Aprendidas

Proceso

SharePoint soporta Internet scenarios con grandes volúmenes de datos

El modelo de datos es fundamental para la performance (e.g., # de fields por content type).

Para grandes volúmenes de datos y transacciones, el modelo de lectura/escritura en una base de datos única no funciona.

Desarrollar un framework para operar sobre múltiples datos a la vez fue una decisión muy acertada.

Planeamiento de capacidad y perf testing desde el inicio fue muy acertado.

Migrar contenido es siempre complicado... no se debe dejar nunca para el final.

Invertir en logging (más allá del OOTB) es beneficioso.

Este proyecto significó un gran aprendizaje para SharePoint mismo... veamos estas experiencias como oportunidades.

Conclusiones

¿Preguntas,

comentarios?

Muchas gracias.