Componentes de arquitectura lógica (SharePoint Server 2010)
Se aplica a: SharePoint Foundation 2010, SharePoint Server 2010
Última modificación del tema: 2016-11-30
Los componentes de un diseño de arquitectura lógica se pueden organizar de varias maneras. Cada uno de los componentes presenta distintas oportunidades para compartirlo y aislarlo. Antes de empezar el diseño de la arquitectura lógica:
Conozca cuáles son sus objetivos de uso compartido y aislamiento.
Evalúe las compensaciones de cada opción.
En cada una de las secciones de este artículo se describe un componente concreto de la arquitectura lógica y se tratan los siguientes aspectos que hay que tener en cuenta para dicho componente: capacidad, uso compartido y aislamiento, elementos configurables, administración y recomendaciones de planeación.
En este artículo:
Granjas de servidores
Aplicaciones de servicio
Grupos de aplicaciones
Aplicaciones web
Zonas
Directiva de una aplicación web
Bases de datos de contenido
Colecciones de sitios
Sitios
Colecciones de sitios con nombre de host
Mis sitios
Granjas de servidores
Un conjunto o granja de servidores representa el elemento de nivel superior de un diseño. Las granjas de servidores individuales proporcionan aislamiento físico.
Existen varios criterios que vienen determinados por la organización y pueden afectar al número de granjas de servidores que se requieren, entre otros:
Es probable que el uso excesivo de servicios requiera una o más granjas de servidores de servicios dedicados.
Divisiones de responsabilidad operativas independientes.
Recursos de financiación dedicados.
Ubicaciones independientes de centros de datos.
Requisitos de la industria para el aislamiento físico entre sitios.
No obstante, puede satisfacer muchos requisitos de aislamiento en una única granja de servidores. Por ejemplo, puede usar distintos grupos de aplicaciones de Internet Information Services (IIS) con identidades de proceso diferentes para conseguir el aislamiento en el nivel de proceso tanto para las aplicaciones de servicio como para los sitios.
Además de los requisitos de aislamiento que pueden requerir más de una granja de servidores, una organización puede implementar varias granjas de servidores para satisfacer objetivos de rendimiento y escala, requisitos de licencias o un entorno de publicación.
Aplicaciones de servicio
Una aplicación de servicio proporciona un recurso que puede compartirse en sitios dentro de una granja de servidores o, en algunos casos, en varias granjas de servidores.
En SharePoint Server 2010, los servicios ya no se incluyen en un proveedor de servicios compartidos (SSP). En cambio, la infraestructura para hospedar servicios se transfiere a Microsoft SharePoint Foundation 2010, y la configuración de las ofertas de servicios es mucho más flexible. Los servicios individuales pueden configurarse de manera independiente y los terceros pueden agregar servicios a la plataforma.
Se pueden implementar únicamente los servicios que son necesarios para una granja de servidores. Los servicios implementados se denominan aplicaciones de servicio.
Las aplicaciones de servicio están asociadas a aplicaciones web. Cada aplicación de servicio se puede configurar de un modo diferente:
Las aplicaciones web se pueden configurar para que usen únicamente los servicios que son necesarios, en lugar de usar todo el conjunto de servicios implementados.
Se pueden implementar varias instancias del mismo servicio en una granja de servidores y asignar nombres únicos a las aplicaciones de servicio que se obtienen como resultado.
Se pueden compartir aplicaciones de servicio en varias aplicaciones web dentro de la misma granja de servidores.
Algunas aplicaciones de servicio pueden compartirse en las granjas de servidores.
Capacidad
No existe un límite recomendado del número de aplicaciones de servicio en una única granja de servidores.
Uso compartido y aislamiento
Las aplicaciones de servicio puede compartirse de dos formas:
Se pueden compartir las aplicaciones de servicio y los datos de servicio. Este es el comportamiento predeterminado de los servicios que se comparten en aplicaciones web. Por ejemplo, los resultados de búsqueda se comparten en aplicaciones web que consumen la misma aplicación de búsqueda.
Se puede compartir solo la aplicación de servicio, pero se deben aislar los datos mediante la implementación del servicio en modo particionado. En un entorno hospedado, se pueden implementar aplicaciones de servicio en modo particionado mediante Windows PowerShell. Cada dato del inquilino se almacena en una partición independiente en la base de datos para el servicio. Se usa un identificador de la suscripción del inquilino para asignar los datos de servicio de éste a los sitios. Por ejemplo, si implementa el servicio de búsqueda en modo particionado, cada inquilino verá únicamente los resultados de búsqueda de su propio contenido.
Nota
No todas las aplicaciones de servicio admiten la creación de particiones.
Por el contrario, las aplicaciones de servicio se pueden aislar de dos formas:
Implementando varias aplicaciones de servicio en grupos de aplicaciones independientes para lograr el aislamiento de los procesos de servicios y datos de servicio. Por ejemplo, es probable que un equipo de finanzas requiera una aplicación de Conectividad a datos empresariales dedicada e independiente.
Implementando servicios en modo particionado. Este enfoque funciona bien en entornos hospedados en los que los inquilinos nunca comparten los datos de servicio. Sin embargo, es probable que no sea práctico en entornos en los que exista una combinación de necesidades de datos de servicio aislados y compartidos.
En caso de ser necesario, también se pueden aislar aplicaciones de servicio implementándolas en grupos de aplicaciones independientes, a fin de lograr el aislamiento de los procesos. Sin embargo, los grupos de aplicaciones son un recurso limitado, y el rendimiento de la granja de servidores se ve afectado si se usan demasiados grupos de aplicaciones. Para obtener más información, vea Application pools en este artículo.
Elementos configurables
En la siguiente tabla, se muestran los elementos configurables que contribuyen al aislamiento y al uso compartido.
Elemento |
Descripción |
Grupo predeterminado |
De manera predeterminada, todas las aplicaciones de servicio se incluyen en el grupo predeterminado. Se pueden agregar y quitar aplicaciones de servicio del grupo predeterminado en cualquier momento, incluso cuando crea una. Al crear una aplicación web, se puede seleccionar el grupo predeterminado o se puede crear un grupo personalizado de servicios. Para crear un grupo personalizado de servicios, se deben seleccionar únicamente las aplicaciones de servicio que se desea que use la aplicación web. |
Conexión (proxy) |
Cuando se crea una aplicación de servicio, se crea al mismo tiempo una conexión para la aplicación de servicio. Una conexión es una entidad virtual que conecta aplicaciones web a aplicaciones de servicio. Algunas aplicaciones de servicio, como Servicio de metadatos administrados, almacenan opciones de configuración en las conexiones. En Windows PowerShell, las conexiones se denominan proxies. |
Permisos de la aplicación de servicio |
Se puede delegar la administración de aplicaciones de servicio a otros usuarios si se conceden permisos para una o más aplicaciones de servicio. |
Ubicaciones de host de Mi sitio de confianza |
En organizaciones en las que se implementan varias aplicaciones de servicio de perfiles de usuario, esta característica garantiza que los usuarios creen Mi sitio en la ubicación establecida para su perfil. Esta característica impide que los usuarios creen varios Mis sitios en la organización. |
Administración
Se puede delegar la configuración y la administración de aplicaciones de servicio a los administradores especializados en administrar servicios individuales, como la búsqueda, los perfiles de usuario y los metadatos administrados.
En un entorno hospedado, los inquilinos pueden administrar algunas de las opciones de configuración de servicio de la organización.
Recomendaciones de planeación
Configure las aplicaciones de servicio para compartir recursos en varias aplicaciones web o para aislar el contenido.
Por ejemplo, varios sitios que residen en distintas aplicaciones web y grupos de aplicaciones se pueden unificar mediante un uso compartido de servicios en un grupo de proxy predeterminado, a fin de proporcionar taxonomía, tipo de contenido y uso compartido de perfiles en una intranet. Esto facilita la personalización y la estandarización en toda la empresa en varios sitios y aplicaciones. Esta opción ofrece un ejemplo de equilibrio entre el aislamiento de los procesos (mediante la implementación de aplicaciones web y grupos de aplicaciones independientes) y las necesidades empresariales para compartir la información y aprovechar los datos de perfiles en las aplicaciones.
Además, se pueden configurar las aplicaciones de servicio para mejorar los objetivos de aislamiento generales. Por ejemplo, el uso de un conjunto de servicios dedicado para la colaboración de asociados garantiza que los usuarios asociados no puedan buscar o tener acceso a la información confidencial del entorno de la intranet. Se pueden configurar los servicios individuales para aislar aún más el contenido entre las colecciones de sitios de las siguientes formas:
Limite los ámbitos de búsqueda a cada una de las colecciones de sitios.
Configure el servicio de perfiles de usuario para mostrar únicamente a los usuarios que forman parte de la misma unidad organizativa en Servicios de dominio de Active Directory (AD DS).
Use la herramienta de línea de comandos Stsadm para configurar el selector de personas para mostrar sólo los usuarios que son miembros de la colección de sitios.
Al diseñar la estrategia de servicios de una organización, tenga en cuenta los métodos para configurar los servicios individuales, a fin de mejorar el uso compartido del contenido en general o lograr los objetivos de aislamiento.
Al designar una estrategia de servicios para un entorno de hospedaje, determine qué servicios van a estar disponibles y particionados.
Grupos de aplicaciones
En Internet Information Services (IIS) 7.0, un grupo de aplicaciones es una agrupación de una o más direcciones URL a las que presta servicio un proceso de trabajo o un conjunto de procesos de trabajo.
Al crear colecciones de sitios y servicios en los Productos de SharePoint 2010, se selecciona un grupo de aplicaciones para usar o se puede crear un nuevo grupo de aplicaciones. Cada grupo de aplicaciones tiene su propio proceso de trabajo y puede tener una identidad independiente (cuenta de seguridad) que impide que dos procesos puedan interactuar.
Capacidad
La sobrecarga de memoria de un grupo de aplicaciones es de 30 a 50 megabytes (MB) más la memoria de las aplicaciones que se ejecuten en el espacio de proceso del grupo de aplicaciones. Las diferentes demandas de aplicaciones, por lo general, llevan rápidamente el uso de memoria de un grupo de aplicaciones a 800 MB o más. El límite de la cantidad de grupos de aplicaciones está influenciado por la memoria disponible en el sistema. Es decir, la cantidad de grupos de aplicaciones es dictada por los dos factores siguientes:
Memoria direccionable disponible.
Cantidad de memoria consumida por las aplicaciones que se ejecutan en el grupo de aplicaciones.
La instrucción general para obtener un rendimiento aceptable es usar ocho grupos de aplicaciones o menos.
Uso compartido y aislamiento
Los grupos de aplicaciones de IIS 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 puede ayudar a impedir una vulnerabilidad de seguridad en uno de los sitios que permita a un atacante incluir código malintencionado que pueda atacar sitios de distintos grupos de aplicaciones. Lo que es más importante, esta estrategia aísla el código que presenta problemas de memoria u otros problemas, de modo de que el código problemático no afecte a todas las aplicaciones.
Elementos configurables
De ser necesario, se recomienda el uso de una identidad de grupo de aplicaciones independiente para cada grupo de aplicaciones, para fines de seguridad y motivos de aislamiento.
Administración
Si se usan identidades independientes para cada grupo de aplicaciones, se deberá mantener cada identidad.
Recomendaciones de planeación
En la práctica, considere la opción de usar un grupo de aplicaciones dedicado por cada uno de los motivos siguientes:
Para separar el contenido autenticado del contenido principalmente anónimo.
Para aislar las aplicaciones que almacenan contraseñas e interactúan con aplicaciones empresariales externas (por ejemplo, conexiones de la Conectividad a datos empresariales).
Aplicaciones web
Una aplicación web es un sitio web de IIS creado y usado por Productos de SharePoint 2010. Una aplicación web puede extenderse hasta cuatro veces para crear cuatro zonas adicionales en Productos de SharePoint 2010, lo que da como resultado hasta cinco sitios web de ISS que están asociados a una única aplicación web; cada sitio web de IIS está asociado a una zona diferente. Se puede asignar a cada aplicación web un nombre único de dominio. Para obtener más información, vea Zones en este artículo.
Uso compartido y aislamiento
Cada aplicación web tiene un nombre de dominio único, lo cual impide que se realicen ataques XSS (scripting entre sitios).
Elementos configurables
En la siguiente tabla, se muestran los elementos configurables que contribuyen al aislamiento y al uso compartido.
Elemento |
Descripción |
Aplicaciones de servicio |
Las aplicaciones de servicio están asociadas a aplicaciones web. Cuando se crea una aplicación web, se puede seleccionar el grupo de proxy predeterminado (conjunto predeterminado de aplicaciones de servicio) o se puede especificar un conjunto personalizado de aplicaciones de servicio para la aplicación web. Todos los sitios de una aplicación web consumen servicios de las mismas aplicaciones de servicio. Una aplicación de servicio puede proporcionar servicios para más de una aplicación web, lo que permite el uso compartido de contenido y datos de perfiles en las aplicaciones web. |
Zonas |
En una aplicación web, puede crear hasta cinco zonas. Use las zonas para aplicar distintas condiciones de acceso y directivas para grupos de usuarios de gran tamaño. |
Directiva de aplicación web |
Cree una directiva para aplicar los permisos en una o más zonas de una aplicación web. Se puede crear una directiva para un usuario o grupo de usuarios específicos. Para obtener más información, vea Directiva de una aplicación web en este artículo. |
Administración
La administración continua de aplicaciones web no es significativa.
Recomendaciones de planeación
Por regla general, debe usar aplicaciones web dedicadas para:
Separar el contenido disponible para los usuarios anónimos del contenido disponible para los usuarios autenticados.
Aislar a los usuarios. Por ejemplo, puede asegurarse de que los asociados no tendrán acceso al contenido de la intranet si coloca los sitios de los asociados en una aplicación web independiente.
Aplicar permisos mediante el uso de directivas. Por ejemplo, puede crear una directiva para denegar explícitamente el acceso de escritura a uno o más grupos de usuarios. 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 de la base de datos. Las aplicaciones consiguen un mejor rendimiento si se colocan en bases de datos de contenido con otras aplicaciones de características similares. Por ejemplo, las características de datos de Mis sitios incluyen normalmente 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 el rendimiento de la base de datos.
Optimizar la 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 para cada Papelera de reciclaje del sitio, la expiración y el tamaño de cada uno de los sitios y negociar distintos contratos de nivel de servicio. Por ejemplo, puede conceder más tiempo para restaurar los sitios que no sean críticos para su negocio.
Zonas
Las zonas representan distintas rutas de acceso lógicas (direcciones URL) para obtener acceso a la misma aplicación web. En cada aplicación web, puede crear hasta cinco zonas con uno de los nombres de zona disponibles: Predeterminada, Intranet, Internet, Personalizada o Extranet. Cada nombre se puede seleccionar una sola vez por aplicación web. Cada zona está representada por un sitio web distinto en IIS.
La zona predeterminada es la que se crea primero al crear una aplicación web. Las otras zonas se crean al extender una aplicación web.
Capacidad
Puede crear hasta cinco zonas en una aplicación web. Normalmente, las zonas se coordinan entre las diferentes aplicaciones web para que las zonas con el mismo nombre se configuren para los mismos usuarios.
Uso compartido y aislamiento
Las zonas proporcionan un método para dividir a los usuarios por:
Tipo de autenticación : Cada zona se puede configurar para usar un proveedor de autenticación distinto, lo cual permite compartir el mismo contenido entre compañías asociadas.
Zona de red : Cada zona se puede configurar para admitir usuarios que provengan de una zona de red distinta, como una extranet o Internet.
Permisos de directiva: Puede permitir o denegar de forma explícita el acceso de lectura o escritura a contenido por zona según una cuenta de usuario o una cuenta de grupo.
Elementos configurables
En la siguiente tabla, se muestran los elementos configurables que contribuyen al aislamiento y al uso compartido.
Elemento |
Descripción |
Proveedor de autenticación |
Cada zona puede configurarse para usar un proveedor de autenticación distinto. |
Acceso anónimo |
Active o desactive el acceso anónimo por zona. |
Capa de sockets seguros (SSL) |
Active o desactive SSL por zonas. |
Dirección URL pública y asignación alternativa de acceso |
Especifique el nombre de dominio que tendrán que escribir los usuarios para tener acceso al contenido de la aplicación web. Asimismo, puede usar la asignación alternativa de acceso para asignar direcciones URL fáciles de usar o adecuadas para zonas a la dirección URL predeterminada (nombre de servidor y puerto) de cada zona. La asignación alternativa de acceso es compatible con la terminación fuera de cuadro de SSL. La terminación fuera de cuadro de SSL se produce cuando un servidor proxy termina una solicitud SSL y, a continuación, la reenvía a un servidor web con HTTP. En este caso las asignaciones alternativas de acceso se pueden configurar para devolver estas solicitudes con SSL, con lo cual se mantiene la comunicación segura entre el cliente y el servidor proxy. |
Directiva de aplicación web |
Cree un conjunto de directivas único para cada zona de la aplicación web. Si tiene un grupo de usuarios especial que requiere excepciones a la directiva de seguridad global, considere la opción de usar una zona independiente para admitir a estos usuarios. |
Administración
Si usa la asignación alternativa de acceso, tenga en cuenta que todas las direcciones URL públicas requieren entradas del Sistema de nombres de dominio (DNS) para poder asignarse a la dirección IP del equilibrador de carga usado para la granja de servidores.
Recomendaciones de planeación
Al diseñar zonas, debe tomar varias decisiones que son esenciales para que la implementación sea correcta. Se trata de decisiones relativas al diseño y la configuración de las zonas siguientes:
Zona predeterminada
Zonas para acceso externo
En las siguientes secciones, se describen algunas de las recomendaciones y requisitos de planeación para las zonas, incluida la zona predeterminada.
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 cuota. Por tanto, los usuarios que reciben alertas y mensajes de correo electrónico administrativos deben poder tener acceso a 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 por medio de la zona predeterminada. Todos los usuarios que vayan a tener acceso a colecciones de sitios con nombre de host deben tener acceso por medio de la zona predeterminada.
La zona predeterminada debe ser la más segura. El motivo de esto es que cuando una solicitud de usuario no se puede asociar con una zona, se aplican la autenticación y las directivas de la zona predeterminada.
En un entorno de extranet, el diseño de zonas es imprescindible por dos motivos:
Las solicitudes de usuario se pueden iniciar desde varias redes distintas como, por ejemplo, la red interna, una red de una compañía asociada o Internet.
Los usuarios consumen contenido en varias aplicaciones web. Por ejemplo, es posible que un entorno de intranet incluya sitios hospedados en aplicaciones web distintas. Además, es posible que los empleados tengan acceso al contenido de la intranet y al contenido de colaboración 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 de 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 de acceso alternativas precisa y correctamente para cada zona y cada recurso.
Directiva de una aplicación web
Una directiva de una aplicación web aplica los permisos a todo el contenido de dicha aplicación, lo que le permite configurar la directiva de seguridad para los usuarios en el nivel de la aplicación web. Los permisos de una directiva invalidan todas las demás opciones de seguridad configuradas para los sitios y el contenido.
Puede configurar la directiva según usuarios o grupos de usuarios en AD DS, pero no según grupos de SharePoint. Se puede definir una directiva para la aplicación web en general o solo para una zona específica.
Capacidad
No hay ninguna restricción de capacidad que se aplique a directivas de aplicaciones web.
Uso compartido y aislamiento
Una directiva de una aplicación web proporciona un método para configurar permisos según los usuarios y la zona a través de la cual tienen acceso al contenido.
Por ejemplo, mediante una directiva, puede:
Permitir al personal del departamento de soporte técnico tener acceso a todo el contenido.
Denegar el acceso de escritura a asociados o proveedores.
Denegar el acceso a los datos seguros a un grupo de usuarios, independientemente de la forma en que los propietarios de los sitios configuren los permisos.
Asegurarse de que la cuenta de rastreo tiene acceso para rastrear todo el contenido.
Elementos configurables
En la siguiente tabla, se muestran los elementos configurables que contribuyen al aislamiento y al uso compartido.
Elemento |
Descripción |
Directiva de usuario |
Cree una directiva que se aplique a usuarios o grupos de usuarios:
Para modificar los niveles de permiso predeterminados o crear niveles de permiso nuevos, haga clic en la directiva Permiso cuando crea la directiva en Administración central. |
Directiva anónima |
Si se habilita el acceso anónimo para la aplicación web o para una o más zonas, posteriormente puede crear una directiva que se aplique a todos los usuarios anónimos. Las opciones de configuración de directivas predeterminadas son:
Los niveles de directiva de usuario anónimo no se pueden modificar. |
Directiva de permisos |
Edite los permisos específicos asociados a uno de los niveles de permiso predeterminados o cree un nuevo nivel de directiva de permisos. Además, puede especificar los permisos particulares que se permiten o se deniegan para los sitios y las colecciones de sitios. Después de crear un nuevo nivel de directiva de permisos, puede crear una directiva de usuario que use la directiva de permisos. |
Administración
La administración continua de las directivas de aplicaciones web no es significativa.
Recomendaciones de planeación
Como las directivas se administran de forma centralizada, considere la posibilidad de usarlas para administrar grupos de usuarios de gran tamaño, en lugar de usuarios individuales.
Bases de datos de contenido
De forma predeterminada, todo el contenido de una aplicación web se almacena en una base de datos de contenido. Puede dividir el contenido en varias bases de datos de contenido en el nivel de la colección de sitios. Una base de datos de contenido puede incluir una o más colecciones de sitios. Una única colección de sitios no puede abarcar varias bases de datos. La copia de seguridad y restauración de los sitios se realiza en el nivel de la base de datos de contenido.
Capacidad
La instrucción para obtener un rendimiento aceptable es implementar 100 bases de datos de contenido o menos por aplicación web.
Uso compartido y aislamiento
La planeación de las bases de datos permite optimizarlas para que sean eficaces (varias colecciones de sitios que comparten una base de datos) o estén aisladas (una base de datos por colección de sitios).
Para lograr que la escala sea eficaz, administre las bases de datos en el tamaño de destino máximo. En este caso, las bases de datos se configuran para agregar colecciones de sitios nuevas a bases de datos existentes hasta que se alcance la cantidad máxima de colecciones de sitios. Esta cantidad máxima se calcula mediante una estimación del tamaño promedio o máximo de las colecciones de sitios dividido entre el tamaño objetivo máximo de la base de datos. Este enfoque funciona bien si espera tener una gran cantidad de colecciones de sitios pequeñas, como Mis sitios.
Para lograr que el contenido quede aislado entre grupos o proyectos, limite una base de datos a una colección de sitios. Este enfoque le permite administrar de forma independiente el contenido de los equipos individuales. Por ejemplo, puede administrar de forma independiente la base de datos de cada equipo para las operaciones de copia de seguridad, recuperación y migración. Este enfoque ofrece la oportunidad de implementar distintos contratos de nivel de servicio para equipos o proyectos diferentes. También le permite administrar el contenido durante el ciclo de vida de un proyecto. Por ejemplo, puede archivar una base de datos cuando se complete un proyecto.
Elementos configurables
En la siguiente tabla, se muestran los elementos configurables que contribuyen al aislamiento y al uso compartido.
Elemento |
Descripción |
Servidor de base de datos |
Especifique en qué equipo con SQL Server se crea una base de datos de contenido. |
Servidor de conmutación por error |
Puede elegir asociar una base de datos de contenido a un servidor de conmutación por error específico que se usa junto con la creación de reflejo de la base de datos de SQL Server. |
Configuración de capacidad |
Se puede especificar el número de sitios que se pueden crear antes de que se genere un evento de advertencia y el número máximo de sitios que se pueden crear en cada base de datos. |
Administración
Un plan de administración de bases de datos administrable equilibra el número de bases de datos con los recursos necesarios para administrarlas.
La administración de bases de datos incluye lo siguiente:
Creación de bases de datos nuevas para colecciones de sitios o sitios de grupo nuevos que requieren bases de datos dedicadas.
Supervisión de los tamaños de las bases de datos y creación de bases de datos nuevas cuando se aproximen a su tamaño máximo.
Copias de seguridad y restauración de bases de datos.
Recomendaciones de planeación
Elija uno de los dos enfoques siguientes:
Establecer tamaños de destino para las bases de datos de contenido con umbrales de advertencia de tamaño apropiados. Crear bases de datos nuevas cuando se alcancen los umbrales de advertencia de tamaño. 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 a otras bases de datos.
Si desea asociar colecciones de sitios con bases de datos de contenido específicas, puede usar los métodos siguientes para hacerlo:
Use Windows PowerShell para crear una colección de sitios en una base de datos nueva.
Aplique la siguiente configuración de capacidad de la base de datos en la página Administrar configuración de bases de datos de contenido, en el sitio web de Administración central de SharePoint:
Número de sitios antes de que se genere un evento de advertencia = 0
Número máximo de sitios que se puede crear en esta base de datos = 1
Para agregar un grupo de colecciones de sitios a una base de datos dedicada, realice los siguientes pasos:
Agregue una base de datos de contenido para la aplicación web y asegúrese de que el estado de la base de datos esté configurado 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 en línea automáticamente.
Vuelva a establecer el estado de todas las demás bases de datos en Listo.
Colecciones de sitios
Una colección de sitios es un conjunto de sitios web que tienen el mismo propietario y comparten la configuración de administración. Cada colección de sitios contiene un sitio web de nivel superior y puede contener uno o más subsitios.
Capacidad
La instrucción recomendada para obtener un rendimiento aceptable es implementar menos de 50.000 colecciones de sitios por base de datos de contenido; sin embargo, el rendimiento puede verse afectado al implementarse aproximadamente 10.000 sitios. El aumento de la escala mediante la distribución de colecciones de sitios en varios servidores de bases de datos proporciona un rendimiento y una capacidad de almacenamiento mayores.
Uso compartido y aislamiento
Las colecciones de sitios presentan varias oportunidades de uso compartido y aislamiento que afectan a los permisos, la navegación y la implementación de características.
Los siguientes elementos se pueden compartir en una colección de sitios, pero no entre distintas colecciones de sitios (salvo los elementos que se almacenan en un sistema de archivos, como las características en el directorio _layouts):
Páginas maestras
Diseños de página
Imágenes
Plantillas de sitio
Además, los permisos y la navegación se aíslan en el nivel de la colección de sitios de las siguientes maneras:
Los subsitios de una colección de sitios pueden heredar los permisos del sitio de nivel superior.
Las colecciones de sitios no pueden heredar los permisos de otras colecciones de sitios.
No hay navegación integrada de una colección de sitios a otra.
Finalmente, SharePoint Server 2010 agrega los resultados de la búsqueda a las colecciones de sitios en función de los permisos de un usuario, independientemente del número de colecciones de sitios o bases de datos (según los ámbitos de búsqueda).
Es importante tener en cuenta que aunque los permisos se aplican en sitios individuales, los sitios son vulnerables a ataques XSS (scripting entre sitios) provenientes de otros sitios del dominio.
Elementos configurables
En la siguiente tabla, se muestran los elementos configurables que contribuyen al aislamiento y al uso compartido.
Elemento |
Descripción |
Administrador de la colección de sitios |
Puede especificar un usuario como administrador principal de la colección de sitios y un usuario como administrador secundario de la colección de sitios. En Administración central, no puede especificar más de una cuenta para estos roles ni especificar una cuenta de grupo para ellos. |
Plantilla del sitio |
Una plantilla de sitio determina qué listas y características van a estar disponibles en el sitio nuevo. Después de crear un sitio, se pueden personalizar muchos aspectos de éste. Sin embargo, en esta instancia, no se puede modificar la plantilla de sitio. |
Plantilla de cuota |
Puede aplicar una plantilla de cuota para limitar los recursos que se usan para una colección de sitios. Se proporcionan las plantillas siguientes:
|
En la siguiente tabla, se muestran los elementos configurables de una colección de sitios que contribuyen al aislamiento y al uso compartido. Estas opciones de configuración están disponibles una vez que se crea la colección de sitios con las opciones de configuración descritas en la tabla anterior.
Elemento |
Descripción |
Administradores de la colección de sitios |
Puede especificar varias cuentas de usuario como administradores de la colección de sitios. No puede agregar cuentas de grupo. |
Nivel de permisos |
Agregue cuentas de usuario y de grupo a las colecciones de sitios y especifique los niveles de permisos para cada una de ellas. |
Administración
La creación de colecciones de sitios no requiere entradas DNS (a menos que esté creando colecciones de sitios con nombre de host) y se puede automatizar o delegar a los usuarios fácilmente. Puede crear colecciones de sitios para los sitios de grupo de forma centralizada o permitir que los usuarios creen sus propias colecciones de sitios con Administración de sitios sin intervención del administrador.
El uso de una base de datos dedicada para una colección de sitios permite realizar operaciones de copia de seguridad y recuperación en el nivel de la colección de sitios.
Recomendaciones de planeación
Las colecciones de sitios actúan de puente entre la arquitectura lógica y la arquitectura de información. Al diseñar las colecciones de sitios, tenga en cuenta las dos tareas de diseño siguientes:
Diseñar direcciones URL de forma coherente en la organización.
Crear divisiones lógicas del contenido.
A menos que use colecciones de sitios con nombre de host, cada aplicación web debe tener una única colección de sitios de nivel raíz. Esto proporciona una sola ruta de acceso de dirección URL a los sitios que se encuentran ubicados en la aplicación web. Se trata de un requisito si implementa varias zonas en una aplicación web. Para obtener más información, vea Host-named site collections en este artículo.
Muchas organizaciones tienen previsto implementar varias colecciones de sitios en una aplicación web para su uso por parte de grupos o divisiones distintas de la organización. Entre los objetivos de diseño comunes se incluyen los siguientes:
Mantener una colección de sitios distinta e independiente para cada grupo.
Crear una dirección URL única para cada grupo.
Aislar contenido entre grupos.
Para alcanzar estos objetivos, puede usar rutas de acceso administradas para incorporar varias colecciones de sitios de nivel superior en una aplicación web. Al definir rutas de acceso administradas, puede especificar qué rutas del espacio de nombres 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 distintiva 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 el usuario. Una inclusión explícita se aplica a una sola colección de sitios. Puede asociar cada una de estas colecciones de sitios a una base de datos de contenido distinta si desea administrar el crecimiento y ofrecer la oportunidad de realizar operaciones de copia de seguridad y restauración de los sitios por separado. Una dirección URL de ejemplo para una colección de sitios creada con este método es http://fabrikam/hr. El límite de colecciones de sitios creadas con una inclusión explícita es de aproximadamente 100 colecciones de sitios en una aplicación web; sin embargo, 20 colecciones de sitios también es un número máximo recomendado para el buen funcionamiento. Si la organización requiere más colecciones de sitios, use una inclusión de caracteres comodín en su lugar.
Inclusión de caracteres comodín: se agrega una ruta de acceso a la dirección URL. Esta ruta de acceso indica que todos los sitios especificados directamente después del nombre de la ruta de acceso son colecciones de sitios únicas. Esta opción se suele usar para admitir la Administración de sitios sin intervención del administrador, como Mis sitios o los sitios creados para la colaboración de los asociados. Las direcciones URL de ejemplo de las colecciones de sitios creadas mediante este método son http://partnerweb/sites/project1 y http://partnerweb/sites/project2. En estos ejemplos, "http://partnerweb" representa la colección de sitios del nivel raíz y "/sites" representa la inclusión de caracteres comodín.
Sitios
Un sitio está compuesto por una o más páginas web relacionadas y otros elementos (como listas, bibliotecas y documentos) que se hospedan en una colección de sitios.
Capacidad
La instrucción para obtener un rendimiento aceptable es implementar menos de 250.000 sitios por colección de sitios. Puede crear un número total de sitios web muy grande si anida los subsitios. Sin embargo, una gran número de subsitios anidados puede afectar significativamente el tiempo de actualización de los sitios. 5.000 sitios en una colección de sitios es una cantidad objetivo favorable.
Uso compartido y aislamiento
Los sitios incluyen navegación integrada de un subsitio a otro dentro de una colección de sitios. No hay navegación integrada de una colección de sitios a otra.
Al igual que con las colecciones de sitios, los sitios independientes son vulnerables a ataques XSS (scripting entre sitios) provenientes de otros sitios del dominio.
Elementos configurables
Desde dentro de cada sitio, puede agregar cuentas de grupo o de usuario al grupo de propietarios del sitio.
Administración
Existen varias herramientas para realizar operaciones de copia de seguridad y restauración en sitios individuales.
Colecciones de sitios con nombre de host
Las colecciones de sitios con nombre de host son una opción si desea crear varias colecciones de sitios de nivel raíz en una aplicación web. Por ejemplo, los administradores de las organizaciones de hospedaje usan colecciones de sitios con nombre de host para crear varios sitios con nombre de dominio.
No hay ningún modo especial, como un modo de encabezado de host, que resulte necesario para crear colecciones de sitios con nombre de host. Estas colecciones se crean con Windows PowerShell. Además, mediante Windows PowerShell, puede usar rutas de acceso administradas con colecciones de sitios con nombre de host (New-SPManagedPath –HostHeader).
Las colecciones de sitios con nombre de host ofrecen un mayor control sobre las direcciones URL. No obstante, sólo están disponibles a través de la zona predeterminada. Las cuentas de usuario configuradas para autenticarse a través de otras zonas no pueden tener acceso a las colecciones de sitios con nombre de host.
En los Productos de SharePoint 2010, las colecciones de sitios con nombre de host admiten la terminación SSL externa. Sin embargo, solo el esquema de protocolo se puede cambiar de forma externa (http:// or https://). El servidor de proxy inverso no puede cambiar el nombre de host ni el número de puerto (excepto cambiar del puerto SSL predeterminado al puerto HTTP predeterminado).
Capacidad
Puede crear un máximo de 100.000 colecciones de sitios con nombre de host en un único sitio web de IIS.
Uso compartido y aislamiento
Los nombres de dominio independientes que se obtienen de las colecciones de sitios con nombre de host ayudan a impedir los ataques de scripting entre dos sitios.
Administración
Entre las tareas administrativas para las colecciones de sitios con nombre de host se incluyen las siguientes:
Agregue colecciones de sitios con nombre de host con Windows PowerShell.
Cada colección de sitios con nombre de host requiere una entrada DNS independiente.
Mis sitios
Mis sitios son sitios de SharePoint especiales personalizados para cada usuario. La característica Mis sitios se habilita de forma predeterminada como parte del servicio de perfil de usuario, y todos los usuarios de la organización tienen un Mi sitio único. Para obtener información acerca de la capacidad, el uso compartido y el aislamiento, vea Sitios anteriormente en este artículo.