GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

MOSS 2007: Diseño de MOSS y Planificación de la Instalación MOSS

Volver a: [Instalar y Configurar Microsoft Office SharePoint Server 2007 (Instalar MOSS 2007)]


Este capítulo detalla varias consideraciones de Diseño e Infraestructura de MOSS (Topología de MOSS), a considerar previamente a la instalación de una Granja MOSS. Intentaremos dar respuesta a preguntas frecuentes de MOSS como: ¿Qué es una Granja MOSS? ¿Qué papel puede desempeñar cada Servidor MOSS de la Granja? ¿Cuando es necesario o Por qué es necesario crear varias Granjas MOSS? ¿Cómo diseñar el Modelo de Ciclo de Vida en Portales de Contenido y Colaboración de MOSS? ¿Qué mecanismos de autenticación pueden utilizarse con MOSS?

Desde un punto de vista de Topología de MOSS, una Granja MOSS puede estar formada por una única máquina (que ejecutará SQL Server, IIS, MOSS tanto para Sitios Web como para Aplicaciones, etc), o por un conjunto amplio de máquinas (dos máquinas dedicadas como Cluster de SQL Server, y un conjunto amplio de servidores MOSS que comparten la misma base de datos de configuración, como por ejemplo 4 servidores MOSS frontales para hospedar los Sitios Web de MOSS configurados en Balanceo de Carga NLB, y dos servidores MOSS para hospedar las Aplicaciones - Búsqueda, Indexación, Servicios de Excel, etc.).

Sin embargo, son varios los aspectos a tener en cuenta en el diseño de una implementación de MOSS 2007, no sólo el número de servidores. Quizás, los aspectos más importantes sean cuántas Granjas MOSS 2007 serán necesarias, tamaño de la Granja MOSS (pequeña, mediana o grande, es decir, que cúantos servidores MOSS), tipos de accesos necesarios (es decir, si se utilizará para Internet, Extranet y/o Intranet), requisitos especiales del cliente, seguridad, etc.

Revisando la documentación de MOSS, es posible encontrar algunas Recomendaciones de diseño (topología de MOSS), como por ejemplo:

  • Si se desean utilizar varios Servidores de Búsqueda (Search Server) en la Granja MOSS, estos no deben configurarse como Index Server y Query Server, por lo que deberá existir un Servidor de Indexación (Index Server) adicional que no actúe como Servidor de Búsqueda (Search Server). Es decir, una configuración válida sería un Servidor de Aplicaciones MOSS actuando como Servidor de Indexación (Index Server), y dos Servidores MOSS actuando como Frontales (WFE) y también como Servidores de Búsqueda (Search Server). El motivo de esta recomendación, está en que si el Servidor de Indices (Index Server) es también Servidor de Búsqueda (Search Server), no se podrá realizar correctamente la propagación de índices desde el Servidor de Indices al resto de Servidores de Búsqueda (sólo se hará correctamente al Servidor de Búsqueda local, es decir, al propio Servidor de Indices).
  • Es recomendable parar el servicio Windows SharePoint Services Web Application en todos los Servidors MOSS que actúen sólo como Servidores de Aplicaciones (es decir, que no sean Servidores Frontales). Existen excepciones a esta regla: por ejemplo, si tenemos un servidor MOSS dedicado como Index Server, y dos servidores MOSS actuando como frontales (WFE) y servidores búsqueda (Search Server) simultáneamente, es recomendable mantener iniciado el servicio Windows SharePoint Services Web Application en el Index Server, de tal modo, que durante la indexación de contenidos de MOSS pueda obtener dichos contenidos desde sí mismo y no tener que pedírselos a los frontales (evitando así impactar en el rendimiento de los Frontales) aunque los usuarios no se conecten al Index Server (es decir, el Index Server está fuera del NLB de los Frontales). A esta configuración, se la conoce como dedicated front-end Web server for crawling. Por el contrario, podríamos tener otro servidor MOSS adicional actuando como Excel Services, y en este servidor si podríamos detener el servicio Windows SharePoint Services Web Application.
  • Es recomendable iniciar el servicio Windows SharePoint Services Help Search sólo en los casos en los que se utilice. Si no se desea (o no es requisito) que los usuarios puedan realizar este tipo de búsquedas, no es necesario iniciar este servicio.
  • En aquellas Granjas MOSS con más de un Servidor de Indexación (Index Server), es recomendable parar el servicio Central Administration en todos los Servidores de Indexación (Index Server).

Habitualmente, suele hablarse de Granjas pequeñas, medianas y grandes. Sin embargo, ¿a que se refieren estos términos?

  • Granja Pequeña. Máximo, un servidor SQL Server y un servidor MOSS 2007 actuando tanto de Frontal como de servidor de Aplicaciones (Búsqueda, Indexación, Servicios de Excel, etc). También considera el caso de una máquina con todo, tanto MOSS 2007 como SQL Server. Muy útil como entorno de desarrollo (instalando también SharePoint Designer 2007 y Visual Studio 2008 en el servidor MOSS, claro). En cualquier caso, en la medida de lo posible, resulta muy recomendable mantener separado el servidor SQL Server del servidor MOSS (es decir, utilizar dos máquinas, al margen de que la máquina SQL Server actúe de servidor de base de datos compartido para otras muchas aplicaciones).
  • Granja Mediana. Máximo, un servidor SQL Server, uno o dos servidores MOSS 2007 actuando tanto como Frontal (Web Content y Search Querys), y un servidor MOSS 2007 actuando como servidor de Aplicaciones (Indexación, Servicios de Excel, etc).
  • Granja Grande. Dos o más servidores SQL Server configurados en Alta Disponibilidad (Microsoft Cluster, Database Mirroring, etc.), múltiples servidores MOSS 2007 en Balanceo de Carga (NLB) actuando tanto como Frontales, y múltiples servidores MOSS 2007 actuando como servidores de Aplicaciones (cada servidor de Aplicaciones ofrecerá un servicio específico).

Pero ¿Qué es una Granja MOSS? Una Granja MOSS es un conjunto de servidores MOSS (es decir, un servidor MOSS o varios servidores MOSS en una misma ubicación) que comparten una misma base de datos de Confinguración, donde cada servidor MOSS puede actuar como Servidor Web (conocido también como Frontal, hospeda los Sitios Web de MOSS, y soporta las conexiones y peticiones de los usuarios), puede actuar como Servidor de Aplicaciones (hospeda servicios de Indexación, Servicios de Excel, etc.), o puede actuar como ambos (es decir, un servidor MOSS puede actuar como Frontal y como Servidor de Aplicaciones - ej: instalación Stand Alone). Una Granja MOSS actúa como un contenedor lógico de diferentes componentes como Shared Services Providers, Database Services, Web Application, y Site Collections (se dice, que la Granja MOSS es el contenedor principal desde el punto de vista de la Arquitectura de SharePoint).

¿Cuándo es necesario disponer de varias Granjas MOSS? Los principales motivos por los que disponer de múltiples Granjas MOSS son los siguientes:

  • Licenciamiento. Existen dos modos diferentes de licenciamiento de MOSS 2007: Licenciamiento por Servidor (para redes internas, implica la adquisición de un número necesario de Licencias de Cliente o CAL) y Licenciamiento para Internet (para el acceso a través de Internet por personal externo a la organización - es decir, que no es para los empleados, sino para Partners, clientes, etc. – sin necesidad de adquirir Licencias de Cliente o CAL, se licencia por cada Servidor). En caso de necesitar que accedan a SharePoint tanto el personal interno de la organización (es decir, los empleados), como personal externo, podría ser necesario utilizar dos Granjas de MOSS, cada una en un modo de Licenciamiento diferente, aunque existen casos en los que se podría utilizar una única Granja MOSS (ej: crear un sitio para utilizar como Extranet dentro de una Granja MOSS con Licenciamiento por Servidor, sin que sea necesario adquirir CALs para el sitio de la Extranet; Utilizar una Granja MOSS con Licenciamiento para Internet, teniendo en cuenta que no será posible crear Sitios para utilizar sólo y exclusivamente por personal interno - empleados). En la práctica, es interesante investigar las diferentes opciones de licenciamiento (ej: Licencias por Volumen), con el objetivo de identificar la fórmula más económica para cada caso. También es importante tener en cuenta, casos como la utilización de Servidores en Frío o Servidores en Reserva, es decir, aquellos servidores que permanecen apagados y que sólo serán levantados para reemplazar a un servidor existente, como método de Alta Disponibilidad. Los Servidores en Frío no consumen Licencia conforme a la Microsoft Software Assurance.
  • Alta Disponibilidad. Algunos escenarios de Alta Disponibilidad para MOSS 2007, implican la implementación de múltiples Granjas de MOSS en múltiples ubicaciones físicas, asumiendo los correspondientes costes de hardware, software y comunicaciones, evidentemente.
  • Emplear múltiples Granjas MOSS para los diferentes entornos o fases del Modelo de Ciclo de Vida utilizado. Un poco más adelante se trata en más detalle.
  • Crear diferentes entornos por motivos evidentes de seguridad, como puede se el caso de utilizar múltiples Granjas MOSS en el Entorno de Producción, como por ejemplo, una Granja MOSS para los contenidos publicados a Internet para Clientes y Partners (es decir, una Extranet), y otra Granja MOSS para los contenidos internos de la Intranet (accedidos sólo y exclusivamente desde la red interna o desde VPN). Diferentes Granjas MOSS pueden construirse bajo diferentes dominios de Directorio Activo, de hecho, la existencia de una Granja MOSS para Intranet y otra Granja MOSS para Extranet, suele implicar la existencia de dos Directorios Activos separados e independiente (es decir, dos Bosques): un Directorio Activo con los usuarios propios de la organización, y otro dedicado a usuarios externos de la Extranet (ej: Clientes y Partners).

Evidentemente, además de SQL Server y MOSS, deberemos disponer de una infraestructura de Directorio Activo y DNS, y por supuesto, si deseamos exponer alguno de los Sitios Web de MOSS a Internet será de gran interés publicar los Sitios Web de MOSS a través de ISA Server 2004 ó ISA Server 2006, manteniendo los servidores MOSS en un segmento de red seguro (es decir, en una DMZ o en la red interna, en función de la topología de nuestra red, y de las ganas que tengamos de correr riesgos ;-).

Desde el punto de vista del Ciclo de Vida de MOSS, es posible construir diferentes Granjas de MOSS para cada fase del Modelo de Ciclo de Vida elegido. Así, podríamos diferenciar diferentes entornos o fases, donde cada entorno sería una Granja (o quizás diferentes entornos pudieran ser diferentes Sitios Web de la misma Granja):

  • Entorno de Desarrollo. Utilizado por los Desarrolladores para el desarrollo de aplicaciones MOSS, diseño y construcción de Sitios (con sus Listas y Galerías de Documentos), WebParts, Workflows, etc.
  • Entorno de Pruebas Integradas. Utilizado para realizar las baterías de pruebas definidas para los desarrollos de MOSS.
  • Entorno de Desarrollo de Contenidos. Utilizado para la elaboración de contenidos, desde un entorno separado del entorno de Producción. Esto permite configuraciones como un Entorno de Desarrollo de Contenidos en nuestra red interna, y un Entorno de Producción en Internet, en cuyo caso conseguiríamos como ventaja principal una mejora de la seguridad en nuestra infraestructura MOSS. Además, en este entorno, se podría implementar procesos de edición y aprobación de contenidos, habilitar el versionado, habilitar la Papelera de Reciclaje de MOSS, etc., funcionalidades todas ellas que quizás en el Entorno de Producción no serían necesarias.
  • Entorno de Pre-Producción. Utilizado para la realización de baterías de pruebas finales, pruebas de rendimiento, validación final de contenido, etc.
  • Entorno de Producción. Utilizado por los usuarios finales de las Aplicaciones MOSS. Cabe la posibilidad de desarrollar procesos que actualicen el contenido del Entorno de Producción con el contenido del Entorno de Pre-Preproducción, de forma automatizada y periódica.

En el caso de utilizar múltiples entornos, es importante definir un Procedimiento de Paso entre Entornos (qué elementos son susceptibles de promover entre entornos, y que pasos son necesarios seguir para su promoción), que sea capaz de promover entre los diferentes entornos MOSS (ej: de Desarrollo a Pruebas Integradas), los diferentes Sitios Web y sus dependencias (WebParts, Assemblies, etc.)

Para cada Granja MOSS que debamos instalar, será necesario identificar:

  • Cuantos Servidores MOSS formarán la Granja MOSS.
  • Qué papel (rol) desempeñará cada Servidor MOSS: Servidor Web, Servidor de Aplicaciones, o Mixto. En cualquier caso, recomiendo siempre realizar la instalación completa, y luego, ya veremos como repartimos los roles (sobre todo, por si deseamos cambiar nuestra topología de servidores MOSS en un futuro).

Habitualmente para entornos de Producción utilizaremos una Granja MOSS formada por varios servidores MOSS. En este caso, antes de la instalación es importante tener en cuenta qué Usuarios de Directorio Activo será necesario crear para utilizar como cuentas de servicio, así como garantizar que dichos usuarios de Directorio Activo tienen los permisos necesarios para su funcionamiento. Ejemplo de usuarios a considerar para su creación en Directorio Activo:

  • Cuenta de Servicio para MOSS 2007.
  • Cuenta para MOSS Search.
  • Cuenta para el Crawler (Indexación).
  • Una o varias cuentas para los Application Pool del IIS sobre los que se ejecutarán los Sitios Web de MOSS (es posible tener múltiples sitios sobre múltiples Application Pool, aunque minimizar el número de Application Pool minimizará los recursos consumidos por nuestra Granja MOSS).
  • Una o varias cuentas para los Application Pool del IIS sobre los que se ejecutarán los Proveedores de Servicios Compartidos (Shared Services Provider).
  • Una cuenta para la ejecución de los Proveedores de Servicios Compartidos (Shared Services Provider).

Es muy importante tener en cuenta que MOSS no soporta SQL Server en Cluster Geográfico, por lo tanto será necesario recurrir a otras alternativas de Alta Disponibilidad, como es el caso de Database Mirroring en SQL Server 2005 o superior.

Otro detalle a tener en cuenta es elegir el mecanismo de autenticación de MOSS (puede especificarse el mecanismo de autenticación deseado editando el fichero Web.config de la Aplicación Web de MOSS), pudiendo elegir en MOSS 2007 entre los siguientes mecanismos de autenticación:

  • Autenticación NTLM (Windows Integrada). Mecanismo de autenticación de desafío-respuesta (challenge-response), donde el usuario y contraseña es transmitido en forma segura (encriptado)
  • Autenticación Kerberos (Windows Integrada). Mecanismo de autenticación basado en el protocolo Kerberos. Se trata de un mecanismo seguro de autenticación basado en tickets de sesión. El equipo cliente o usuario obtiene un ticket de sesión desde un servidor de autenticación (en el caso de Directorio Activo, un Controlador de Dominio o DC). Este ticket de sesión es presentado para acceder a los recursos (ej: presentar el ticket a los servidores IIS de nuestro SharePoint), de tal modo que el servidor que ofrece los recursos (es decir, el IIS) pueda comprobar la validez del ticket utilizando un servidor de autenticación (es decir, un Controlador de Dominio). Las principales ventajas, es que facilita la Delegación en IIS y MOSS, y además evita que se tenga que enviar las credenciales (usuario y contraseña) continuamente por la red.
  • Acceso Anónimo. En caso necesita acceso anónimo, será necesario decidir si configurar acceso anónimo a todo el Sitio Web, o sólo a algunas partes del Sitio Web (ej: ciertas librerías de documentos y páginas). Es importante recordar, que el acceso anónimo en IIS se basa por defecto en la cuenta IUSR_ComputerName.
  • Autenticación Básica. Aunque funciona con la gran mayoría de Navegadores, al ser parte de la propia especificación del protocolo HTTP 1.0, resulta un mecanismo NO seguro al enviar las credenciales (usuario y contraseña) en texto claro (excepto que se utilice SSL para cifrar la comunicación entre el equipo cliente y el IIS).
  • Autenticación basada en Formularios ASP.NET. En MOSS 2007 es posible realizar métodos de autenticación personalizados basados en Formularios ASP.NET.

Es interesante tener en cuenta que es posible utilizar múltiples mecanismos de autenticación para un Sitio Web de SharePoint, aprovechando las ventajas de cada uno.

Otro tema del que hablar, es el Proveedor de Servicios Compartidos (Shared Services Provider - SSP), concepto que simboliza una organización lógica de Aplicaciones Web de MOSS (Web Applications) utilizada para acceder a un conjunto común de servicios.

Cada Aplicación Web de MOSS debe estar asociada con un y sólo un Proveedor de Servicios Compartidos (Shared Services Provider - SSP), aunque es posible compartir un SSP con múltiples Aplicaciones Web de MOSS 2007 (de hecho, es bastante común crear un único SSP y varias Aplicaciones Web asociadas con dicho SSP en una Granja MOSS 2007). En consecuencia, en una Granja MOSS 2007 es necesario que exista al menos un SSP (siendo la creación del primer SSP uno de los pasos básicos a realizar durante la instalación de MOSS 2007) o bien, la Granja MOSS puede acceder algún SSP existente en otras Granjas MOSS 2007 (en este caso, no se podrá utilizar Excel Services).

El Proveedor de Servicios Compartidos (Shared Services Provider - SSP) ofrece los siguientes servicios genéricos:

  • Business Data Catalog.
  • Excel Services.
  • Personalization Services.
  • Portal Usage Reporting.
  • SharePoint Server Search.

¿Cuándo utilizar múltiples SSP? Habitualmente es apropiado y suficiente con un único Proveedor de Servicios Compartidos (Shared Services Provider - SSP) en la Granja MOSS 2007. Sin embargo, en ocasiones puede ser necesario utilizar múltiples SSP. Por ejemplo, si deseamos utilizar una única Granja MOSS 2007 para el acceso por usuarios internos, y para el acceso por usuarios externos (es decir, desde Internet), podría resultar de interés utilizar dos SSP: uno para las Aplicaciones Web de los usuarios internos y otro para las Aplicaciones Web de los usuarios externos. Como vemos, el objetivo de utilizar varios SSP es el aislamiento y la seguridad, como ocurre en otros entornos (ej: cuando utilizar múltiples Bosques de Directorio Activo). En cualquier caso, es recomendable utilizar el menor número de SSP, con el objetivo de minimizar los recursos necesarios, optimizando así el rendimiento de la Granja MOSS.

En el caso de utilizar múltiples Servicios Compartidos (Shared Services Provider - SSP), habitualmente cada SSP suele comportarse como una entidad separada e independiente del resto de SSP, aunque es posible compartir información entre diferentes SSP.

Por último, y antes de continuar con el resto de capítulos del presente artículo, puede resultar de bastante interés repasar otros Conceptos de MOSS 2007 (Aplicación Web, Accesos Alternativos, Colección de Sitios, Base de Datos de Contenido de MOSS), con el fin de estar familiarizados con los mismos, y además, porque pueden resultar de utilidad para definir el Diseño y Topología de nuestra infraestructura de MOSS 2007.

Volver a: [Instalar y Configurar Microsoft Office SharePoint Server 2007 (Instalar MOSS 2007)]


[Fecha del Artículo (UTC): 08/03/2009]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas