WSS 3.0 & MOSS: Niveles arquitectónicos (III)!

Para concluir la serie de post sobre los niveles arquitectónicos en la plataforma SharePoint (el resto de artículos los podéis leer en la parte I y la parte II de la serie), en este post vamos a ver el tercer nivel de arquitectura: la arquitectura de administración de la plataforma SharePoint.

Arquitectura de Administración de SharePoint

Administrar una granja de servidores SharePoint o una instalación tipo stand-alone implica añadir, editar o eliminar datos que se almacenan en las BD’s de configuración de SharePoint. Realizar estas operaciones implica usar las herramientas de administración que nos proporciona la plataforma en lugar de editar los datos directamente:

  • Realizar un backup de nuestras web applications.
  • Restaurar una web application a partir de un cierto backup
  • Eliminar una web appliction o un site collection.

Y estas operaciones las vamos a poder realizar con las dos herramientas por excelencia de la plataforma SharePoint:

  • La SharePoint 3.0 Central Administration.
  • La utilidad de línea de comandos stsadm.
image image  

image

Todas las settings de administración de la plataforma SharePoint se almacenan en una BD de configuración en Microsoft SQL Server (normalmente la BD se suele llama NombreServidor_Config):

image

Como hemos comentado, todas las settings de administración de SharePoint pueden visualizarse y modificarse mediante dos herramientas de administración: la SharePoint 3.0 Central Administration y la utilidad stsadm. Ambas nos permiten “tocar” la BD de configuración gracias a una arquitectura física de tres niveles:

  • La UI, compuesta por páginas ASP.NET para la SharePoint 3.0 Central Administration y de la interfaz de comandos para stsadm.
  • El modelo de objetos de SharePoint acceder a la BD y devolver, añadir, editar o eliminar datos de configuración.
  • La propia BD.

El modelo de administración de SharePoint a su vez se basa en una arquitectura lógica de tres capas:

  • La capa 1 comprende todas las características y funcionalidades de administración requeridas para la gestión de la granja de servidores. Por lo tanto, las tareas de administración a este nivel son realizadas por los administradores IT tradicionales puesto que incluye actividades como: gestión de los recursos de la granja (memoria, CPU, ancho de banda, …), monitorización de la salud de los servidores de la granja, aspectos y configuraciones de seguridad, etc. Por ejemplo, un administrador a este nivel sería el responsable de crear aplicaciones web, colecciones de sitios, gestionar las e-mail settings (para correo entrante y saliente) o gestionar la topología de l granja:
image image  

image

  • La capa 2 comprende todas las características y funcionalidades de administración requeridas para la gestión de servicios compartidas a lo largo de la granja. Las tareas de administración a este nivel son realizadas por el administrador IT de negocio y pueden incluir actividades de gestión como establecer el nivel de servicio, configurar las búsquedas e indexaciones, o gestionar los informes de uso.
image image  

image

  • La capa 3 que comprende todas las características y funcionalidad para gestionar sitios dentro de una granja. Las tareas de administración a este nivel son realizadas por un administrador de sitio y pueden incluir actividades como gestión de web parts, acceso a los sitios, gestión de contenidos, etc. Por ejemplo, estaríamos hablando de actividades como la creación de listas, configuración del acceso de los usuarios a un sitio y modificar la jerarquía de un sitio.

image

Finalmente comentaros que, aunque nos hemos centrado mucho en los ejemplos en las funcionalidades que nos da la administración central de SharePoint, estas funcionalidades también las tenemos con stsadm. Es más stsadm proporciona comandos adicionales que no tenemos en la SharePoint 3.0 Central Administration. Por ejemplo, con stsadm podemos cambiar la frecuencia de las alertas de SharePoint a otros valores que los que nos da por defecto la interfaz web:

stsadm –o setproperty –propertyname job-inmediate-alerts –url http://Servidor_SharePoint –propertyvalue “every 1 minutes between 0 an 59”

Y hasta aquí llega lo que os quería contar sobre los niveles de arquitectónicos en la plataforma SharePoint. Espero que la serie os haya resultado interesante.