Diseño de ejemplo de arquitectura lógica: sitios de colaboración
En este artículo:
Acerca del modelo
Objetivos generales de diseño
Granjas de servidores
Usuarios, zonas y autenticación
Sitios de administración
Grupos de aplicaciones
Aplicaciones web
Colecciones de sitios
Bases de datos de contenido
Zonas y direcciones URL
Directivas de zona
Copia de seguridad y restauración de sitios de colaboración
Diseño para lograr una colaboración externa segura
En este artículo se describe una implementación práctica de componentes de arquitectura lógica para lograr un diseño viable. Este artículo está pensado para usarse junto con el siguiente modelo de diseño de ejemplo de arquitectura lógica aplicado a la colaboración de Windows SharePoint Services (en inglés) (https://go.microsoft.com/fwlink/?linkid=124861&clcid=0xC0A) (en inglés).
Acerca del modelo
El modelo ilustra una implementación corporativa para una empresa ficticia denominada Fabrikam, Inc. Si está planeando una solución con uno o varios de los tipos de sitios de colaboración representados en este modelo, puede utilizar el modelo como base para su propio diseño.
El modelo ilustra una implementación genérica de Windows SharePoint Services 3.0 con tres tipos diferentes de sitios de colaboración representados:
Sitios de grupo
Sitios sin intervención del administrador
Sitios de colaboración de socios
El modelo se aplica a casi todos los componentes de la arquitectura lógica e ilustra cómo se incorporan en el diseño general. En este artículo se describen los objetivos de diseño para el modelo y se explica cómo se logran los objetivos mediante los componentes de la arquitectura lógica que se ilustran en el modelo.
Cada uno de los diferentes tipos de sitios de colaboración:
Hospeda los datos con características de datos diferentes.
Está sujeto a un perfil de uso diferente.
Requiere una estrategia de administración de permisos diferente.
Por lo tanto, las opciones de diseño en el modelo están pensadas para optimizar el rendimiento y la seguridad para cada aplicación.
Sitios de grupo
Los sitios de grupo representan sitios de colaboración muy estructurados y administrados en los que:
Hay un número menor de colecciones de sitios de nivel superior y estas colecciones de sitios están pensadas para incluir una gran cantidad de datos (en contraste con los sitios sin intervención del administrador).
Las direcciones URL de nivel superior tienen un significado para cada grupo.
En las jerarquías, taxonomías y personalizaciones de sitios se dedica más tiempo a la planeación.
El contenido de cada grupo está en una base de datos independiente y se puede administrar por separado.
El siguiente diagrama ilustra la jerarquía del sitio para los sitios de grupo:
.gif "Organización de sitios de grupo")
Sitios sin intervención del administrador
Los sitios sin intervención del administrador proporcionan una alternativa a los sitios de grupo altamente administrados. Puede permitir a los usuarios y equipos crear sus propias colecciones de sitios mediante Administración de sitios sin intervención del administrador, que se activa en Administración central. Este método se recomienda cuando desea permitir que grupos o comunidades creen sitios. Este método también funciona bien si hospeda sitios y desea permitir que los usuarios creen sitios sin tener que esperar un proceso detallado.
Las características de los sitios sin intervención del administrador suelen ser diferentes de los sitios altamente administrados. Éstas son algunas de esas características:
Gran número de colecciones de sitios de nivel superior.
Pequeña cantidad de datos por colección de sitios.
Direcciones URL que se generan automáticamente pero que normalmente no son significativas.
El siguiente diagrama ilustra los sitios sin intervención del administrador tal y como se han implementado en el ejemplo de diseño:
.gif "Sitios para la creación de sitios sin intervención del administrador")
Existen varias contrapartidas que se han de tener en cuenta al planear la implementación de sitios sin intervención del administrador, las cuales afectarán a la forma en que administrará estos tipos de sitios:
En lugar de implementar una taxonomía exhaustiva, los sitios se crean voluntariamente sin ningún principio organizativo entre ellos. Como cada nuevo sitio es una colección de sitios, las plantillas y la navegación no pueden compartirse entre los sitios sin intervención del administrador.
Debido a que cada colección de sitios sólo busca contenido en esa colección de sitios, no hay ninguna agregación de los resultados de la búsqueda a través de colecciones de sitios.
Las colecciones sitios pueden variar mucho en cuanto a tamaño y uso.
Los sitios se pueden abandonar fácilmente.
La administración de sitios sin intervención del administrador puede incluir la administración del almacenamiento de contenido según el tamaño deseado de las bases de datos de contenido y la eliminación periódica de sitios que ya no se utilizan.
Para obtener más información acerca de la implementación de la administración de sitios sin la intervención del administrador, vea Plan process for creating sites (Windows SharePoint Services).
Sitios de colaboración de socios
La aplicación Web de asociados hospeda sitios disponibles de manera externa para ofrecer una colaboración segura con los empleados de las empresas asociadas. El objeto de esta aplicación es que los empleados puedan crear fácilmente sitios seguros para la colaboración. Entre los factores clave en que se basan las opciones de diseño de esta aplicación, se incluyen:
**Aislamiento del contenido **A los asociados no se les permite tener acceso a otros tipos de contenido hospedado en la granja de servidores.
**Autenticación independiente de las cuentas de asociado **Las cuentas de asociado se administran a través de la autenticación mediante formularios. Las cuentas de asociado no se agregan al directorio corporativo.
**Administración de permisos **Los propietarios de sitios individuales administran los permisos de sus sitios y sólo se invita a colaborar a los participantes necesarios.
El siguiente diagrama ilustra los sitios de colaboración de asociados.
.gif "Jerarquía de sitios de proyecto en una Web de asociados")
Objetivos generales de diseño
El modelo muestra una implementación práctica de características de Windows SharePoint Services 3.0 dentro de varios tipos diferentes de aplicaciones de colaboración (sitios de grupo, sitios sin intervención del administrador y sitios de asociados). En este artículo se abordan las implementaciones de diseño de cada una de las aplicaciones de sitios individuales. Entre los objetivos de diseño clave para el modelo, se incluyen:
Crear un marco para diseñar un entorno que puede aumentar de tamaño. Las decisiones sobre el diseño de las aplicaciones de colaboración individuales no impiden la adición de otras aplicaciones. Por ejemplo, una implementación inicial puede incluir sólo los sitios de grupos de colaboración o sitios de asociados. El uso de un diseño de arquitectura lógica similar le permite agregar los otros tipos de sitios de colaboración a la solución sin que ello afecte al diseño de los sitios de colaboración iniciales. En otras palabras, el diseño no incorpora opciones de diseño que limiten el uso del entorno.
Proporcionar acceso a varias clases de usuarios sin poner en peligro la seguridad del contenido dentro de las distintas aplicaciones de colaboración. Los usuarios de zonas de red diferentes (internas y externas) con diferentes proveedores de autenticación pueden participar en la colaboración. Además, los usuarios sólo pueden tener acceso al contenido al que se supone que tienen acceso. El uso de un diseño de arquitectura lógica similar le permite proporcionar acceso a los usuarios en varias ubicaciones y con diferentes objetivos. Por ejemplo, el diseño inicial puede destinarse sólo al acceso de empleados internos. Sin embargo, el uso de un diseño similar le permite habilitar el acceso también para los empleados remotos, empleados de asociados e incluso clientes.
Asegurarse de que el diseño pueda usarse en un entorno de extranet. Puede tomar decisiones de diseño deliberadas para garantizar que las granjas de servidores puedan implementarse de un modo seguro en una red perimetral o dentro de cualquier topología de extranet abordada en Design extranet farm topology (Windows SharePoint Services).
En el resto de este artículo se aborda cada uno de los componentes lógicos que aparecen en el modelo (de arriba a abajo), así como las opciones de diseño que se aplican al modelo. El objetivo de este enfoque es demostrar las distintas formas en que se pueden configurar componentes de arquitectura lógica en función de la aplicación.
Granjas de servidores
El modelo muestra una granja de cinco servidores. Sin embargo, el modelo se puede implementar en una granja de servidores de cualquier tamaño, incluida una que sólo tenga un único servidor. La granja de servidores en el modelo se compone de cinco servidores con la topología siguiente:
Dos servidores cliente web
Un servidor de aplicaciones para cada servidor de búsqueda
Dos servidores de base de datos en clúster o reflejados
El modelo ilustra la arquitectura lógica de Windows SharePoint Services 3.0 al mostrar que:
Todos los sitios se reflejan en servidores cliente web.
El sitio de Administración central se instala en un servidor de aplicaciones para protegerlo contra el acceso directo de los usuarios.
En realidad, el número de equipos servidor y la topología de la granja de servidores no son importantes para la arquitectura lógica, con la excepción de aumentar la capacidad y el rendimiento según sea necesario. La arquitectura lógica puede designarse de manera independiente de la topología de la granja de servidores. El proceso de planeación del rendimiento y de la capacidad le ayudará a ajustar el tamaño de la granja de servidores con el fin de cumplir los objetivos de rendimiento y capacidad. Para obtener más información, vea Plan for performance and capacity (Windows SharePoint Services).
Usuarios, zonas y autenticación
El modelo ilustra cinco clases diferentes de usuarios, cada una de ellas asignada a una zona diferente. En cada aplicación web, puede crear hasta cinco zonas con uno de los nombres de zona disponibles: Predeterminada, Intranet, Internet, Personalizada o Extranet. Una granja que hospede más de una aplicación web puede admitir solicitudes de usuario de más de cinco zonas de red (hasta cinco zonas por aplicación web). Sin embargo, el modelo muestra sólo cinco zonas.
Usuarios y autenticación
El modelo muestra cómo se aplica la autenticación entre los usuarios de zonas de red diferentes. En la tabla siguiente, se muestra también la autenticación que se aplica a cada tipo de usuario y zona.
| Zona | Usuarios | Autenticación |
|---|---|---|
Intranet |
Empleados internos |
NTLM (integrada de Windows) |
Predeterminada |
Empleados remotos |
NTLM (integrada de Windows) o autenticación mediante formularios con el protocolo ligero de acceso a directorios (LDAP). |
Extranet |
Empleados de asociados |
Autenticación mediante formularios |
Empleados internos
La zona de la intranet se usa para el acceso de los empleados internos. Se usa la autenticación integrada de Windows.
Empleados remotos
La zona predeterminada se usa para el acceso de los empleados remotos. Los objetivos de diseño de la zona predeterminada son los siguientes:
Realizar la autenticación en el entorno de servicio de directorio Active Directory interno.
Simplificar la administración de permisos mediante la autenticación de Windows para empleados tanto internos como remotos. Este objetivo es importante porque, si los usuarios se conectan a sitios a través de dos proveedores de autenticación diferentes, Windows SharePoint Services 3.0 crea dos cuentas diferentes para cada usuario, y cada una de estas cuentas debe tener permisos.
El modelo presenta dos opciones diferentes para autenticar a los empleados remotos. Con la primera opción (autenticación integrada de Windows con NTLM), se cumplen ambos objetivos de diseño. La segunda opción (autenticación mediante formularios con LDAP) cumple el primer objetivo pero no el segundo. Por consiguiente, la primera opción es el método preferido para los empleados remotos.
En la siguiente tabla, se resumen las diferencias entre estas dos opciones de autenticación.
| Tipo de comparación | Autenticación integrada de Windows con NTLM | Autenticación mediante formularios con un proveedor LDAP |
|---|---|---|
Funcionalidad |
Este método se basa en el uso de Internet Security and Acceleration (ISA) Server 2006 o Intelligent Application Gateway (IAG 2007) para autenticar a los usuarios y, a continuación, enviar las credenciales de los usuarios a Windows SharePoint Services 3.0. Estos servidores utilizan la autenticación mediante formularios para autenticar a los usuarios en el entorno de Active Directory. A continuación, reenvían las credenciales de Windows a Windows SharePoint Services 3.0. Para obtener más información, vea los recursos siguientes:
Puesto que la zona es la Predeterminada, se usa la autenticación NTLM para cumplir un requisito del componente de índice. Para obtener más información, vea "Requisitos de configuración de la zona predeterminada" más adelante en este artículo. |
Windows SharePoint Services 3.0 usa la autenticación mediante formularios con un proveedor LDAP para autenticar a los empleados remotos en el entorno de Active Directory interno. |
Ventajas |
Windows SharePoint Services 3.0 no crea dos cuentas distintas para los usuarios que trabajan de forma interna y remota. Esto simplifica en gran medida la administración de permisos. |
No requiere un servidor proxy para autenticar a los usuarios y reenviar las credenciales. |
Desventajas |
Requiere configuración y coordinación adicional con ISA Server 2006, IAG 2007 u otro producto de servidor proxy. |
Si los usuarios se conectan a Windows SharePoint Services 3.0 internamente y de manera remota, se crean dos cuentas de usuario diferentes en Windows SharePoint Services 3.0. Por lo tanto, ambas cuentas requieren permisos para sitios y documentos. Los empleados necesitan administrar los permisos para sus propios sitios y documentos para ambas cuentas de usuario si van a trabajar desde la red interna y de forma remota. |
Empleados de asociados
Los empleados de asociados tienen acceso a la red a través de la zona de extranet y se autentican a través de la autenticación mediante formularios. Esto requiere un directorio y proveedor independientes, por ejemplo, una base de datos de Microsoft SQL Server y un proveedor, para almacenar cuentas de asociado en la extranet. Las ventajas de este enfoque son que puede administrar cuentas de asociado por separado y no es necesario agregar cuentas de asociado al directorio de los empleados internos.
También puede usar el inicio de sesión web único para autenticarse directamente en el directorio de un asociado. Sin embargo, este enfoque requiere una zona independiente para cada directorio de asociado.
Dado que el modelo asume que Fabrikam está trabajando con los asociados de varias empresas diferentes dentro de la misma aplicación de asociado, se usa la autenticación mediante formularios. El directorio y el proveedor no se especifican.
Zonas
Al diseñar zonas, debe tomar varias decisiones que son esenciales para que la implementación sea satisfactoria. Se trata de decisiones relativas al diseño y la configuración de las zonas siguientes:
Zona predeterminada
Zonas para acceso externo
En las secciones siguientes, se describen las decisiones que se incorporan en el modelo.
Requisitos de configuración de la zona predeterminada
La zona para la que hay que tener en cuenta más aspectos es la zona predeterminada. Windows SharePoint Services 3.0 impone los siguientes requisitos en el modo en que se configura la zona predeterminada:
Cuando una solicitud de usuario no se puede asociar a una zona, se aplican la autenticación y las directivas de la zona predeterminada. Consecuentemente, la zona predeterminada debe ser la zona más segura.
El componente de índice requiere acceso al contenido a través de, como mínimo, una zona para rastrear el contenido. El componente de índice utiliza la autenticación NTLM. Como consecuencia, para rastrear contenido, como mínimo una de las zonas debe estar configurada para usar autenticación NTLM. Además, el rastreador sondeará las zonas en el orden siguiente hasta que encuentre una zona a través de la cual se pueda autenticar: zona predeterminada, zona de intranet, zona de Internet, zona personalizada y zona de extranet. No obstante, si en primer lugar el rastreador encuentra una zona configurada para usar autenticación Kerberos, básica o implícita, no se autenticará y no intentará obtener acceso a la zona siguiente. Por tanto, asegúrese de que la configuración de las zonas no impida al componente de índice rastrear contenido. Para obtener más información acerca de los requisitos de autenticación relacionados con el rastreo de contenido, vea Plan authentication methods.
El correo electrónico administrativo se envía con vínculos de la zona predeterminada. Esto incluye correo electrónico a propietarios de sitios que se aproximan a los límites de las cuotas. Por tanto, los usuarios que reciben estos tipos de mensajes de correo electrónico deben poder tener acceso a los vínculos a través de la zona predeterminada. Esto es especialmente importante para los propietarios de sitios.
Las colecciones de sitios con nombre de host sólo están disponibles a través de la zona predeterminada. Todos los usuarios que necesiten tener acceso a colecciones de sitios con nombre de host deben tener acceso por medio de la zona predeterminada.
En el modelo, la zona predeterminada se usa para el acceso de empleados remotos por los motivos siguientes:
Los empleados pueden tener acceso a vínculos de correo electrónico administrativo independientemente de si tienen acceso a los sitios internamente o de manera remota.
Los nombres de los servidores internos y las direcciones URL están protegidos de ser expuestos cuando no se puede determinar la zona asociada a una solicitud de usuario. Debido a que la zona predeterminada ya está configurada para los empleados remotos, las direcciones URL no muestran datos confidenciales cuando se aplica esta zona.
Configuración de zonas para un entorno de extranet
En un entorno de extranet, es fundamental diseñar las zonas por estos dos motivos:
Las solicitudes de usuarios pueden iniciarse desde varias redes diferentes. En el modelo, los usuarios inician las solicitudes desde la red interna, Internet y las empresas asociadas.
Los usuarios pueden colaborar en varias aplicaciones web. Por ejemplo, los empleados internos y remotos pueden potencialmente contribuir y administrar contenido en todas las aplicaciones web: sitios de grupo, sitios sin intervención del administrador y Web de asociados.
En un entorno de extranet, asegúrese de que se observan los siguientes principios de diseño:
Configure las zonas de varias aplicaciones web para que se reflejen mutuamente. La configuración de la autenticación y los usuarios a los que está dirigida deben coincidir. No obstante, las directivas asociadas con zonas pueden diferir entre distintas aplicaciones web. Por ejemplo, asegúrese que la zona de intranet se usa para los mismos empleados en todas las aplicaciones web. Es decir, no configure la zona de intranet para empleados internos en una aplicación web y para empleados remotos en otra.
Configure las asignaciones alternativas de acceso precisa y correctamente para cada zona y cada recurso.
En el modelo, la zona predeterminada para cada una de las aplicaciones web está configurada de forma idéntica para el acceso de los empleados remotos. Además, la zona de intranet está configurada de forma idéntica en todas las aplicaciones web para el acceso de los empleados internos. La zona de extranet se configura sólo para una aplicación web.
Cuando se crea la zona, se crean automáticamente asignaciones alternativas de acceso. Sin embargo, si utiliza un servidor proxy o un producto de puerta de enlace para liberar los sitios de Internet, tendrá que agregar una entrada de asignación alternativa de acceso adicional para cada zona. Esto garantiza que las direcciones URL que se devuelven a los usuarios de fuera de la red interna estén disponibles para los usuarios de acuerdo con el contexto de su zona. Para obtener más información, vea Plan alternate access mappings.
Si las zonas entre las aplicaciones web no se reflejan entre sí y los vínculos a recursos externos no son los adecuados, éstos son algunos de los riesgos:
Los nombres de servidor, los nombres DNS (Sistema de nombres de dominio) y las direcciones IP pueden potencialmente quedar expuestas fuera de la red interna.
Quizás los usuarios no puedan tener acceso a sitios web y otros recursos.
Sitios de administración
En el modelo, el sitio de Administración central se hospeda en el servidor de búsqueda. De esta manera, se protege el sitio del contacto directo con los usuarios. Si un cuello de botella de rendimiento u otro problema de seguridad afectan a la disponibilidad de los servidores cliente web, el sitio de Administración central sigue estando disponible. Además, el sitio de Administración central se hospeda dentro de una aplicación web y un grupo de aplicaciones dedicados.
Las direcciones URL de carga equilibrada de los sitios de administración no se explican en el modelo ni en este artículo. Las recomendaciones son las siguientes:
Si se usan números de puerto en direcciones URL administrativas, use los puertos no estándar. Los números de puerto se incluyen en las direcciones URL de forma predeterminada. Si bien normalmente los números de puerto no se usan en direcciones URL expuestas a clientes, el uso de números de puerto para la administración de sitios puede aumentar la seguridad mediante la limitación del acceso a estos sitios a los puertos no estándar.
Cree entradas DNS independientes para los sitios de administración.
Grupos de aplicaciones
Normalmente, se implementan grupos de aplicaciones de Internet Information Services (IIS) independientes para lograr el aislamiento de procesos entre los sitios. Los grupos de aplicaciones permiten que varios sitios se ejecuten en el mismo equipo servidor y que a la vez tengan sus propios procesos de trabajo e identidades. Esto mitiga cualquier posible problema de seguridad en un sitio que ofrece a un atacante la oportunidad de insertar código en el servidor para atacar a otros sitios.
En la práctica, considere la opción de usar un grupo de aplicaciones dedicado para cada una de estas situaciones:
Para separar el contenido autenticado del contenido anónimo.
Para aislar sitios que son principalmente para la colaboración con los socios o clientes externos. Esto aísla las cuentas externas a sitios dentro de un grupo de aplicaciones.
Para aislar sitios en que los usuarios tienen libertad para crear y administrar sitios y colaborar en el contenido.
El modelo usa grupos de aplicaciones de la siguiente manera:
El sitio de administración se hospeda en un grupo de aplicaciones dedicado. Esto es un requisito de Windows SharePoint Services 3.0.
Los sitios de colaboración internos (sitios de grupo y sitios sin intervención del administrador) se hospedan en un grupo de aplicaciones.
La aplicación Web de asociados se hospeda en un grupo de aplicaciones dedicado.
Aplicaciones web
Una aplicación web es un sitio web de IIS creado y usado por Productos y tecnologías de SharePoint. Cada aplicación web está representada por un sitio web distinto en IIS. A cada aplicación web se le asigna un nombre de dominio único, que ayuda a evitar problemas de scripts entre sitios.
Por regla general, debe usar aplicaciones web dedicadas para:
Separar el contenido anónimo del contenido autenticado.
Aislar usuarios. En el modelo, Web de asociados se hospeda en una aplicación web y un grupo de aplicaciones dedicados para asegurarse de que los asociados no tengan acceso al contenido de colaboración interno.
Aplicar permisos. Una aplicación web dedicada ofrece la oportunidad de aplicar los permisos mediante la página Directiva de aplicación web en Administración central. Por ejemplo, puede crear una directiva en el sitio de colaboración interno para denegar de modo explícito el acceso a cuentas de asociados. Las directivas de una aplicación web se aplican independientemente de los permisos configurados en sitios o documentos individuales de la aplicación web.
Optimizar el rendimiento. Los sitios consiguen un mejor rendimiento si se colocan en aplicaciones web con otras aplicaciones de características similares. Por ejemplo, las características de datos de los sitios sin intervención del administrador incluyen una gran cantidad de sitios cuyo tamaño es pequeño. Por el contrario, los sitios de grupo contienen normalmente una cantidad más pequeña de sitios de tamaño muy grande. Si estos dos tipos de sitios se colocan en aplicaciones web independientes, las bases de datos resultantes se componen de datos con características similares, lo cual optimiza su rendimiento. En el modelo, los sitios de grupo y los sitios sin intervención del administrador no poseen requisitos de aislamiento exclusivos sino que comparten el mismo grupo de aplicaciones. No obstante, los sitios de grupo y los sitios sin intervención del administrador se colocan en aplicaciones web independientes para optimizar el rendimiento.
Optimizar la capacidad de administración. La creación de aplicaciones web independientes da como resultado sitios y bases de datos independientes, por lo que puede implementar distintos límites de sitios (para la Papelera de reciclaje, la expiración y el tamaño) y negociar distintos contratos de nivel de servicio. Por ejemplo, puede dedicar más tiempo a restaurar el contenido de sitios sin intervención del administrador si éste no es el tipo de contenido más crítico dentro de la organización. Esto le permite restaurar el contenido más crítico antes de restaurar el de estos sitios. En el modelo, los sitios sin intervención del administrador se colocan en una aplicación web independiente para permitir a los administradores controlar de un modo más agresivo el crecimiento frente a otras aplicaciones.
Colecciones de sitios
Las colecciones de sitios actúan de puente entre la arquitectura lógica y la arquitectura de la información. Los objetivos de diseño de las colecciones de sitios en el modelo son cumplir los requisitos para el diseño de dirección URL y crear divisiones lógicas de contenido.
Para satisfacer los requisitos del diseño de dirección URL, cada aplicación web incluye una colección de sitios única de nivel raíz. Las rutas de acceso administradas se usan para incorporar un segundo nivel de colecciones de sitios de nivel superior. Para obtener más información acerca de los requisitos de las direcciones URL y cómo usar rutas de acceso administradas, vea "Zonas y direcciones URL" más adelante en este artículo. Más allá del segundo nivel de colecciones de sitios, cada sitio es un subsitio.
La siguiente ilustración muestra la jerarquía de sitio de los sitios de grupo.
.jpg "Arquitectura lógica para sitios de colaboración")
Dado el requisito de una colección de sitios de nivel raíz, las decisiones de diseño giran en torno al segundo nivel de colecciones de sitios. El modelo incorpora opciones en función del tipo de la aplicación.
Sitios sin intervención del administrador
En el modelo, los sitios sin intervención del administrador incorporan un sitio de nivel superior con la dirección URL http://sites. Se incorpora una ruta de acceso administrada (mediante la inclusión de caracteres comodín), lo que permite un número indefinido de sitios creados por el usuario. Todos los sitios situados debajo de la ruta de acceso administrada son colecciones de sitios independientes que heredan la plantilla del sitio que se utilizó para crear el sitio de nivel superior. En la siguiente ilustración, se muestran sitios sin intervención del administrador.
Para obtener más información acerca de sitios sin intervención del administrador, vea Plan process for creating sites (Windows SharePoint Services).
Sitios de grupo
Al diseñar colecciones de sitios dentro de una aplicación del sitio de grupo, la recomendación es crear un número finito de colecciones de sitios para la organización en función del modo en que opere la organización. En este enfoque, un administrador de Windows SharePoint Services 3.0 crea colecciones de sitios. Una vez creada la colección de sitios, los grupos pueden crear sitios dentro de ella según sus necesidades.
Este enfoque ofrece la oportunidad de implementar una taxonomía exhaustiva que estructura la forma en que se administran y crecen los sitios de grupos. Además, habrá más oportunidades para el uso compartido de plantillas y para la navegación entre los proyectos y los grupos que comparten una colección de sitios. El desafío para los arquitectos de la información es crear un segundo nivel de colecciones de sitios que tenga sentido para la organización. En la tabla siguiente, se enumeran sugerencias para distintos tipos de organizaciones.
| Tipo de organización | Sugerencias de taxonomía de colección de sitios |
|---|---|
Desarrollo de productos |
|
Investigación |
|
Institución de enseñanza superior |
|
Departamento legislativo provincial |
|
Departamento jurídico corporativo |
|
Fabricación |
|
Web de asociados
El sitio web de asociados está pensado para la colaboración con asociados externos en proyectos que tienen ámbitos finitos o duraciones finitas. Por su diseño, los sitios de la aplicación web de asociados no están diseñados para estar relacionados. Entre los requisitos del sitio web de asociados se incluye garantizar que:
Los propietarios de los proyectos pueden crear fácilmente sitios para la colaboración de asociados.
Los asociados y otros colaboradores tienen acceso sólo a los proyectos en los que están trabajando.
Los propietarios de los sitios administran los permisos.
Los resultados de la búsqueda desde dentro de un proyecto no exponen el contenido de otros proyectos.
Los administradores pueden identificar fácilmente los sitios que ya no se usan y eliminarlos.
Para satisfacer estos requisitos, el modelo incorpora una colección de sitios para cada proyecto, lo que ofrece las siguientes ventajas:
Las colecciones de sitios individuales proporcionan el nivel adecuado de aislamiento entre proyectos.
Se puede implementar la creación de sitios sin intervención del administrador.
Bases de datos de contenido
Puede usar los dos enfoques siguientes para incorporar las bases de datos de contenido en el diseño (el modelo incorpora ambos enfoques):
Establecer objetivos de tamaño para las bases de datos de contenido con los umbrales de advertencia de tamaño apropiados y crear una base de datos nueva cuando se alcancen dichos umbrales. Con este enfoque, las colecciones de sitios se agregan automáticamente a la base de datos o bases de datos disponibles, únicamente en función de los objetivos de tamaño.
Asociar colecciones de sitios con bases de datos de contenido específicas. Este enfoque permite colocar una o más colecciones de sitios en una base de datos dedicada que se puede administrar de forma independiente con respecto al resto.
Si decide asociar colecciones de sitios con bases de datos de contenido específicas, dispone de los métodos siguientes:
Use la herramienta de línea de comandos Stsadm para crear una colección de sitios en una base de datos específica.
Dedique una base de datos a una sola colección de sitios mediante la aplicación de la siguiente configuración de capacidad de base de datos:
Número de sitios antes de que se genere un evento de advertencia = 1
Número máximo de sitios que se puede crear en esta base de datos = 1
Agregue un grupo de colecciones de sitios a una base de datos dedicada llevando a cabo los siguientes pasos:
Dentro de la aplicación web, cree la base de datos y establezca el estado de la base de datos en Listo.
Establezca el estado de todas las demás bases de datos en Sin conexión. Mientras las bases de datos de contenido están sin conexión, no se pueden crear nuevas colecciones de sitios. Sin embargo, las colecciones de sitios existentes de las bases de datos sin conexión siguen estando accesibles para operaciones de lectura y escritura.
Cree las colecciones de sitios. Se agregan a la base de datos automáticamente.
Vuelva a establecer el estado de todas las demás bases de datos en Listo.
Sitios de grupo
El modelo incorpora una base de datos dedicada para cada una de las colecciones de sitios de grupo. Este enfoque permite administrar la base de datos de cada grupo de forma independiente para realizar copias de seguridad, restauraciones y migraciones. Además, cuando un proyecto se haya completado, puede archivar fácilmente la base de datos asociada al proyecto.
Sitios sin intervención del administrador
Para sitios sin intervención del administrador, el modelo consigue la eficacia de escala mediante la administración de bases de datos hasta el objetivo de tamaño máximo. Para lograr este objetivo, se han de establecer las siguientes opciones de configuración:
Limitar el almacenamiento del sitio a un máximo de Esta opción de configuración, que se establece en la página Plantillas de cuota de Administración central, limita el tamaño de un sitio personal.
Papelera de reciclaje de la segunda etapa Esta opción de configuración, que se establece en la página Configuración general de la aplicación web, determina cuánto espacio adicional se asigna a la papelera de reciclaje de la segunda etapa.
Número máximo de sitios que se puede crear en esta base de datos Esta opción de configuración se establece al crear una base de datos. Calcule el número total de sitios permitido mediante el uso de las cifras especificadas para los dos valores anteriores. A continuación, en función del objetivo de tamaño de cada base de datos, determine cuántos sitios cabrán en la base de datos.
El modelo proporciona la siguiente configuración de tamaño basada en un objetivo de tamaño de base de datos de 100 gigabytes (GB) y un objetivo de tamaño para Mi sitio de 500 megabytes (MB):
Límite de tamaño por sitio = 500 MB
Objetivo de tamaño de la base de datos = 100 GB
Número máximo de sitios = 200
Advertencia del nivel del sitio = 175
Cuando se alcance la advertencia del nivel del sitio, cree una nueva base de datos. Después de crear la nueva base de datos, se agregan de manera alterna nuevos sitios sin intervención del administrador a la nueva base de datos y a la base de datos existente hasta que se alcance el número máximo de sitios para una de las bases de datos.
Web de asociados
De forma similar a los sitios sin intervención del administrador, Web de asociados logra la eficacia de escala mediante la administración de bases de datos hasta el objetivo de tamaño máximo.
El sitio web de asociados se hospeda en una aplicación web dedicada, lo que le permite crear límites de tamaño que son más apropiados para los tipos de tamaños que se crean. El modelo ofrece las siguientes opciones de configuración de tamaño de ejemplo:
Objetivo de tamaño de la base de datos = 100 GB
Cuota de almacenamiento por sitio = 5 GB
Número máximo de sitios = 20
Zonas y direcciones URL
El modelo ilustra cómo coordinar las direcciones URL entre las distintas aplicaciones de una implementación corporativa.
Objetivos de diseño
Los siguientes objetivos influyen en las decisiones de diseño de las direcciones URL:
Las convenciones de las direcciones URL no limitan las zonas a través de las cuales es posible tener acceso al contenido.
Los puertos HTTP y HTTPS (80 y 443) estándar pueden usarse en todas las aplicaciones del modelo.
Los números de puerto no se incluyen en las direcciones URL. En la práctica, los números de puerto no suelen usarse en entornos de producción.
Principios de diseño
Para lograr estos objetivos de diseño, se aplican los siguientes principios de diseño:
No se usan colecciones de sitios con nombre de host. Tenga en cuenta que las colecciones de sitios con nombre de host no son iguales que los encabezados de host de IIS. Las colecciones de sitios con nombre de host no funcionan con la característica de asignaciones alternativas de acceso, la cual es necesaria para tener acceso al mismo contenido a través de varias direcciones URL de dominio. Por lo tanto, cuando se usan sitios con nombre de host, estos sitios están disponibles sólo a través de la zona predeterminada. La característica de asignaciones alternativas de acceso también ofrece compatibilidad con la finalización fuera de cuadro de SSL (Capa de sockets seguros), que permite que los escenarios de acceso de empleados remotos y de asociados usen SSL (HTTPS). Para obtener más información acerca del uso de colecciones de sitios con nombre de host, vea White paper: Create shared hosting solutions on Windows SharePoint Services.
Cada aplicación incorpora una sola colección de sitios raíz. Esto es un requisito para usar asignaciones alternativas de acceso. Si se requieren varias colecciones de sitios raíz dentro de una aplicación web y prevé usar sólo la zona predeterminada para el acceso de usuarios, las colecciones de sitios con nombre de host son una buena opción.
Para la aplicación que incluye varias colecciones de sitios de alto nivel, donde cada colección de sitios representa un proyecto o equipo de nivel superior (por ejemplo, sitios de grupo), el modelo incorpora las rutas de acceso administradas. Las rutas de acceso administradas proporcionan un mayor control sobre las direcciones URL para estos tipos de sitios.
Inconvenientes del diseño
El cumplimiento de los objetivos del diseño tiene ventajas e inconvenientes, entre los que se pueden citar los siguientes:
Las direcciones URL son más largas.
No se usan colecciones de sitios con nombre de host.
Diseño de direcciones URL de carga equilibrada
Cuando se crea una aplicación web, se debe elegir una dirección URL de carga equilibrada para asignarla a la aplicación. Además, se debe crear una dirección URL de carga equilibrada para cada zona que se cree dentro de una aplicación web. La dirección URL de carga equilibrada incluye el protocolo, el esquema, el nombre de host y el puerto, si se usa. La dirección URL de carga equilibrada debe ser única en todas las aplicaciones web y zonas. Por tanto, cada aplicación y cada zona de cada aplicación requieren una dirección URL única en todo el modelo.
Sitios de colaboración internos
Cada uno de los dos tipos diferentes de sitios de colaboración internos necesitan una dirección URL única. En el modelo, la audiencia a la que van dirigidos estos sitios es la de los empleados internos y los empleados remotos. En la siguiente tabla, se enumeran las direcciones URL a través de las cuales los empleados internos y remotos tendrán acceso a cada aplicación.
| Aplicación | Dirección URL de empleado interno | Dirección URL de empleado remoto |
|---|---|---|
Sitios de grupo |
http://teams |
https://teams.fabrikam.com |
Sitios sin intervención del administrador |
http://sites |
https://sites.fabrikam.com |
Web de asociados
En el modelo, los empleados internos, los empleados remotos y los empleados de asociados tienen acceso a Web de asociados. Si bien tanto los empleados remotos como los de asociados tienen acceso a Web de asociados de forma externa mediante SSL (HTTPS), cada uno de ellos necesita una dirección URL diferente para aplicar las ventajas de usar zonas independientes, es decir, diferentes métodos de autenticación y diferentes directivas de zona. En la siguiente tabla, se enumeran las direcciones URL que usan los empleados internos, los empleados remotos y los empleados de asociados para tener acceso a Web de asociados.
| Zona | Dirección URL |
|---|---|
Dirección URL de empleado interno |
http://partnerweb |
Dirección URL de empleado remoto |
https://remotepartnerweb.fabrikam.com |
Dirección URL de asociados |
https://partnerweb.fabrikam.com |
Uso de inclusiones explícitas y de caracteres comodín para rutas de acceso de direcciones URL
Al definir rutas de acceso administradas, puede especificar qué rutas del espacio de nombres de direcciones URL de una aplicación web se usan para colecciones de sitios. Puede especificar que existen una o varias colecciones de sitios en una ruta de acceso distinta situada por debajo del sitio raíz. Sin rutas de acceso administradas, todos los sitios creados por debajo de la colección de sitios raíz forman parte de la colección de sitios raíz.
Puede crear los dos tipos siguientes de rutas de acceso administradas:
Inclusión explícita Una colección de sitios con la dirección URL explícita que asigne. Una inclusión explícita se aplica a una sola colección de sitios. Puede crear muchas inclusiones explícitas debajo de una colección de sitios raíz. Una dirección URL de ejemplo para una colección de sitios creada con este método es http://team/Team1.
Inclusión de caracteres comodín Una ruta de acceso que se agrega a la dirección URL. Esta ruta de acceso indica que todos los sitios que se especifican directamente después del nombre de la ruta de acceso son colecciones de sitios únicas. Esta opción suele usarse en el caso de aquellas aplicaciones que admiten la creación de sitios sin intervención del administrador. Un ejemplo de una dirección URL de una colección de sitios creada mediante este método es http://sites/site1.
El modelo incorpora el uso de ambos tipos, como se describe en las secciones siguientes.
Inclusiones explícitas: sitios de grupo
En el modelo, ambas aplicaciones de sitios de grupo incorporan el uso de inclusiones explícitas.
Sitios de grupo
Dentro de la aplicación de sitios de grupo se usa una inclusión explícita para cada colección de sitios de grupo. El límite de escala en colecciones de sitios creadas con una inclusión explícita es de aproximadamente 100 sitios. Recomendamos mantener el número de sitios de grupo de nivel superior en un número que sea fácil de administrar. Asimismo, la taxonomía de los sitios de grupo debe ser lógica para el modo en que funcione el negocio. Muchas organizaciones se ajustan bien a la recomendación de 100 sitios. Si su organización requiere una escala mayor para los sitios de grupo, use una inclusión de caracteres comodín.
En el modelo, el uso de inclusiones explícitas produce las direcciones URL de la siguiente tabla.
| Empleado interno (zona de Intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
En este ejemplo, la colección de sitios raíz, http://team, no hospeda necesariamente contenido para los usuarios.
Inclusiones de caracteres comodín: Web de asociados y sitios sin intervención del administrador
Tanto Web de asociados como los sitios sin intervención del administrador incorporan el uso de una inclusión de caracteres comodín. Las inclusiones de caracteres comodín son ideales para las aplicaciones que permiten a los usuarios crear sus propias colecciones de sitios. Una inclusión de caracteres comodín indica que el siguiente elemento tras el comodín es un sitio raíz de una colección de sitios.
Sitios sin intervención del administrador
En el modelo, los sitios sin intervención del administrador incluyen una inclusión de caracteres comodín denominada /sites (http://selfservice/sites).
Esto da como resultado direcciones URL con el formato que se muestra en la siguiente tabla.
| Empleado interno (zona de intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://selfservice/sites/site1 |
https://selfservice.fabrikam.com/sites/site1 |
http://selfservices/sites/site2 |
https://selfservice.fabrikam.com/sites/site2 |
http://selfservice/sites/user3 |
https://selfservices.fabrikam.com/personal/user3 |
Web de asociados
El sitio web de asociados está diseñado para permitir a los empleados crear fácilmente sitios seguros para la colaboración con asociados externos. Para admitir este objetivo, se permite la creación de sitios sin intervención del administrador.
En el modelo, el sitio web de asociados incluye una inclusión de caracteres comodín denominada (http://partnerweb/sites). Esto da como resultado direcciones URL con el formato que se muestra en la siguiente tabla.
| Empleado interno (zona de Intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
Los colaboradores asociados pueden tener acceso a sitios de Web de asociados a través de las direcciones URL que se enumeran en la tabla siguiente.
| Asociado (zona de extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
Directivas de zona
Puede crear una directiva para una aplicación web con el fin de aplicar los permisos en el nivel de la aplicación web. Una directiva se puede definir para la aplicación web en general o sólo para una zona específica. Una directiva aplica permisos a todo el contenido incluido en la aplicación web o en la zona. Los permisos de directiva reemplazan todos los demás valores de configuración de seguridad que se hayan establecido para los sitios y el contenido. Puede configurar la directiva según usuarios o grupos de usuarios, pero no según grupos de SharePoint.
El modelo proporciona un ejemplo: denegación del acceso de cuentas de asociado a sitios de colaboración internos.
Copia de seguridad y restauración de sitios de colaboración
Existen varias opciones para realizar una copia de seguridad y restaurar el contenido que son adecuadas para los sitios de colaboración:
Herramientas integradas de copia de seguridad y recuperación: utilice las herramientas incluidas con Windows SharePoint Services 3.0 si las bases de datos tienen un tamaño inferior a 100 GB y no hay muchas personalizaciones o las personalizaciones están empaquetadas como una solución.
Herramientas de copias de seguridad y recuperación de Microsoft SQL Server 2005: use estas herramientas si tiene un administrador de base de datos SQL.
Para obtener más información, vea Choose backup and recovery tools (Windows SharePoint Services).
Diseño para lograr una colaboración externa segura
El póster de ejemplo de diseño incluye una introducción a cómo planear una colaboración segura externa. En esta sección, se incluye el texto de la introducción de cada elemento y vínculos a los artículos correspondientes en la biblioteca de TechNet.
| Recomendación de diseño | Referencia |
|---|---|
Selección de una topología de extranet |
Proteja su granja de servidores mediante un firewall perimetral o colocando la granja de servidores en una red perimetral. Para obtener más información, vea los siguientes artículos en TechNet:
|
Protección de la comunicación cliente-servidor |
La colaboración segura en un entorno de extranet depende de la comunicación segura entre los equipos cliente y el entorno de la granja de servidores. Cuando resulte adecuado, use la Capa de sockets seguros (SSL) para proteger la comunicación entre los equipos cliente y los servidores. Para obtener más información, vea los siguientes artículos en TechNet: |
Protección de los servidores back-end y el sitio de Administración central |
La colaboración externa segura requiere servidores orientados a Internet. Puede limitar la exposición al tráfico de Internet colocando un firewall entre los servidores web y otros servidores, y hospedando el sitio de Administración central en un servidor back-end. Para obtener más información, vea los siguientes artículos en TechNet:
|
Configuración de asignaciones alternativas de acceso |
Las asignaciones alternativas de acceso admiten escenarios de implementación de Internet en los cuales la dirección URL de una solicitud web recibida por Internet Information Services (IIS) no es la misma que la dirección URL que ha especificado un usuario final. Es más probable que esto ocurra en escenarios de implementación que incluyan la publicación de proxy inverso y el equilibrio de carga. Por ejemplo, los proxy inversos pueden tener una funcionalidad avanzada, como la recepción de una solicitud web a través de Internet mediante SSL (HTTPS), pero reenviar la solicitud al servidor mediante HTTP. Esto se conoce como "terminación SSL fuera de cuadro". Para obtener más información, vea Plan alternate access mappings. |
Descarga de este libro
Este tema se incluye en el siguiente libro descargable para facilitar la lectura y la impresión:
Vea la lista completa de libros disponibles en la página de libros descargables para Windows SharePoint Services.