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.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *