Diseño de la arquitectura lógica para sitios de colaboración

En este artículo:

• Sitios de grupo en un entorno de intranet

• Recomendaciones para el diseño de sitios de grupo

• Hospedaje de sitios de grupo en una aplicación web dedicada

• Planeación de la configuración general de la aplicación web

• Decisión sobre si se debe permitir a los usuarios crear colecciones de sitios

• Diseño de la configuración de la base de datos de contenido para sitios de grupo

• Eliminación automática de sitios no usados

• Uso de rutas de acceso para organizar las direcciones URL de los sitios de grupo

• Planeación de elementos personalizados

• Planeación de los permisos que se aplican a los sitios de grupo

En Microsoft Office SharePoint Portal Server 2003, los sitios de grupo tenían una funcionalidad limitada frente a los sitios de portal. Éste no es el caso en Microsoft Office SharePoint Server 2007. En Office SharePoint Server 2007, los sitios de colaboración en un entorno de intranet pueden aprovechar las mismas características que un sitio del portal de intranet publicado si las características están disponibles en el entorno de la intranet. En este artículo, se hará referencia a esos sitios con el término antiguo, "sitios de grupo". Sin embargo, tenga en cuenta que estos sitios no están tan limitados como en la versión anterior en cuanto a las características que pueden contener. Concretamente, el término "sitios de grupo" implica que estos sitios son usados por grupos más pequeños o para mejorar la colaboración ad-hoc, a diferencia un sitio del portal de intranet publicado y controlado.

Los sitios de grupo son una parte importante de la mayoría de las implementaciones de Office SharePoint Server 2007 y son especialmente importantes para las implementaciones de intranet. La colaboración y el espacio de almacenamiento que proporcionan los sitios de grupo son útiles para proyectos a corto plazo y a largo plazo, así como para la comunicación y la colaboración entre los distintos grupos. Si tiene pensado incluir sitios de grupo como parte de su implementación, debe incluirlos en el diseño inicial de la arquitectura de forma que pueda planear su hospedaje y administración. Por ejemplo, debe considerar las bases de datos que serán necesarias para hospedar el contenido del sitio de grupo, planear el archivado y la eliminación de sitios de grupo de proyectos a corto plazo para dar cabida a más proyectos y supervisar los sitios de comunicación del grupo para asegurarse de que sus tamaños son fáciles de administrar para tareas de copia de seguridad y recuperación.

En este artículo se ofrecen recomendaciones de diseño de la arquitectura lógica para implementar sitios de grupo en una granja de servidores. En este artículo no se describe la arquitectura de la información, es decir, la estructura interna, de los sitios de grupo. Para obtener información acerca del diseño de la arquitectura de la información, vea Planeación de la estructura y la publicación de un sitio web (Office SharePoint Server). Para obtener información acerca de los sitios de grupo, vea Planeación de sitios de colaboración.

Sitios de grupo en un entorno de intranet

En un entorno de intranet de Office SharePoint Server 2007, los sitios de grupo pueden conectarse a un sitio del portal de intranet publicado si se incluyen en el Directorio de sitios. Se pueden crear a través del Directorio de sitios del sitio publicado de manera que compartan el mismo nombre de host o simplemente se pueden agregar sitios ya existentes al Directorio de sitios para agregar todos los sitios de grupo relacionados en un mismo lugar. De esta forma, con independencia de sus direcciones URL, pueden aparecer como parte del portal de intranet publicado.

Dado que los sitios de grupo son sitios de SharePoint que tienen el mismo conjunto de características que todos los sitios publicados en el entorno, también pueden usar la inteligencia empresarial, los formularios y otras características que estén disponibles en el mismo. Estas características pueden influir en la arquitectura de los sitios de grupo. Por ejemplo, si necesita mostrar datos profesionales del catálogo de datos profesionales de un sitio de grupo, debe asegurarse de que los miembros de ese sitio de grupo tienen acceso para ver los datos. Las características y la seguridad de inteligencia empresarial se configuran en el nivel de proveedor de servicios compartidos (SSP), por lo que deben usar el mismo SSP todos los sitios de grupo que se conecten a los mismos datos profesionales y deben estar en aplicaciones web asociadas a ese SSP.

Para obtener más información acerca de cómo planear la inteligencia empresarial y los formularios del entorno, vea los siguientes recursos:

• Planeación de la inteligencia empresarial

• Planeación de InfoPath Forms Services

Recomendaciones para el diseño de sitios de grupo

En la mayoría de las organizaciones, el número de sitios de grupo y el tamaño de cada uno de ellos aumenta, a veces rápidamente. A medida que se reorganizan los equipos o que se completan proyectos y se inician otros nuevos, los equipos crean sitios de grupo nuevos y abandonan los antiguos, o amplían los sitios de grupo actuales para incluir cada vez datos. Para administrar o controlar este crecimiento, necesita planear cuidadosamente la compatibilidad con los sitios de grupo.

Los objetivos de diseño de los sitios de grupo son:

• Optimizar el rendimiento de la granja de servidores general.

• Crear divisiones lógicas de bases de datos para los sitios de grupo para llevar a cabo su mantenimiento (es decir, copia de seguridad, recuperación y actualización).

• Permitirle aplicar la configuración y las directivas adecuadas para los sitios de grupo sin que ello afecte a otros tipos de sitios de la intranet.

En las secciones siguientes se desarrollan estas recomendaciones de diseño para los sitios de grupo:

• Hospedar los sitios de grupo en una aplicación web dedicada.

• Aplicar la configuración general de la aplicación web, como las opciones de administración de cuota y ciclo de vida en el nivel de aplicación web para administrar el crecimiento de los sitios de grupo y mantener el contenido actualizado.

• Diseñar la configuración de la base de datos de contenido con los valores de almacenamiento y escala adecuados para garantizar que puede realizar copias de seguridad y restaurar bases de datos del tamaño diseñado.

• Eliminar automáticamente sitios no usados.

• Usar rutas de acceso para organizar las direcciones URL de los sitios de grupo.

• Planear directivas y permisos adecuados.

Hospedaje de sitios de grupo en una aplicación web dedicada

Hospede los sitios de grupo en una aplicación web dedicada o en una aplicación web compartida con Mis sitios. Recomendamos que no hospede sitios de grupo en la misma aplicación web que un sitio del portal de intranet publicado. Mantener los sitios de grupo independientes del sitio del portal de intranet hace que sea más fácil recuperar los datos y su mantenimiento. (Si administra el tamaño de las bases de datos de contenido, esto deja de ser un problema.) En la siguiente ilustración se muestra la aplicación web que contiene los sitios de grupo de una solución de intranet:

Quizás desee usar varias aplicaciones web dedicadas para hospedar los sitios de grupo. Tenga en cuenta los siguientes ejemplos:

• Una empresa de banca de inversión e investigación de valores de Estados Unidos necesita mantener completamente aislados los sitios de la división de banca de inversión y de la división de investigación de valores para cumplir las leyes de la Comisión de Valores de EE.UU. En este ejemplo, la empresa tiene que usar dos aplicaciones web con conjuntos de colecciones de sitios de grupo aislados para las dos divisiones. La empresa también tiene que usar directivas de aplicación web y SSP independientes para garantizar que los usuarios de una división no ven el contenido generado por la otra.

• Una empresa de investigación y fabricación debe mantener un estricto control sobre su propiedad intelectual y los resultados de sus investigaciones. En este ejemplo, la empresa puede hospedar los sitios de grupo de investigación en una aplicación web independiente y usar directivas de aplicación web para imponer la aplicación de permisos y asegurarse de que el personal de investigación sólo ve el contenido de los sitios de grupo de investigación.

• Una organización hospeda sitios de grupo internos (intranet) y externos (extranet) y desea implementarlos y administrarlos de forma diferente. En este ejemplo, la organización planea e implementa dos aplicaciones web independientes para hospedar los dos conjuntos de sitios de grupo de manera que pueda tener métodos de autenticación diferentes, diferentes bases de datos, y diferentes registros de IIS para cada entorno en caso de que se produzca un problema. Para obtener más información acerca de cómo planear extranets, vea Diseño de la topología de la granja de servidores de extranet (Office SharePoint Server).

Por regla general, debe usar aplicaciones web dedicadas para:

• Separar el contenido anónimo del autenticado.

• Aislar a los usuarios.

• Aplicar los permisos.

• Optimizar el rendimiento.

• Optimizar la administración.

Para obtener más información acerca de cómo decidir si tener aplicaciones web compartidas o dedicadas, vea Modelo de arquitectura lógica: implementación corporativa.

Consideración del rendimiento

Si hospeda los sitios de grupo en una aplicación web dedicada, tendrá varias bases de datos de contenido que incluirán sólo colecciones de sitios de grupo. Si las bases de datos de contenido hospedan sitios con características de datos similares, el software de base de datos Microsoft SQL Server funciona de forma más eficaz, ya que SQL Server selecciona un plan de consulta en función de las características de una base de datos. Por el contrario, si una base de datos hospeda sitios con características de datos muy diferentes, quizás el plan de consulta que usa SQL Server no sea el método más eficaz para todo el contenido de la base de datos. Por ejemplo, si una base de datos hospeda sitios de grupo (es decir, un gran número de sitios de tamaño mediano) y sitios de portal (es decir, un número reducido de sitios muy grandes con muchas solicitudes), el plan de consulta elegido será ineficaz para uno de los dos tipos de sitios. Por lo tanto, al colocar el contenido de los sitios de grupo en bases de datos dedicadas, puede optimizar el rendimiento de SQL Server, lo que mejorará el rendimiento de la granja de servidores en general.

Consideración de la administración

Al hospedar los sitios de grupo en una aplicación web dedicada, la administración se puede mejorar de las maneras siguientes:

• Puede administrar por separado estos elementos:

  • Configuración de la base de datos

  • Plantillas de cuota

  • Opciones de la papelera de reciclaje

  • Acciones automáticas para sitios no usados

  • Autenticación

  • Directivas

• Puede administrar el crecimiento de los sitios de grupo de forma más eficaz al administrar de manera independiente los sitios de grupo y otros tipos de sitios.

• Puede crear la oportunidad de negociar un contrato de nivel de servicio específico. Por ejemplo, junto con su contrato de nivel de servicio para almacenar copias de seguridad completas semanales y copias de seguridad diferenciales diarias de las bases de datos de contenido, podría ofrecer una respuesta más rápida para la recuperación de elementos de contenido individuales mediante la papelera de reciclaje de la segunda etapa.

Selección de un grupo de aplicaciones

En un entorno corporativo, los sitios de grupo pueden compartir un grupo de aplicaciones con aplicaciones web que tengan requisitos de colaboración y aislamiento similares. Por ejemplo, los sitios de grupo pueden compartir un grupo de aplicaciones con Mis sitios, ya que ambos se usan para la colaboración, para almacenar información y documentos, y normalmente se les asigna un ámbito similar con fines de aislamiento (es decir, ambos están disponibles para toda la organización).

En general, un grupo de aplicaciones dedicado es necesario en cualquiera de los casos siguientes:

• Para separar el contenido autenticado del contenido anónimo.

• Para aislar aplicaciones que almacenan contraseñas para aplicaciones empresariales externas e interactúan con ellas (por ejemplo, conexiones de Catálogo de datos profesionales).

• Para aislar aplicaciones en que los usuarios tienen libertad para crear y administrar sitios y colaborar en el contenido.

Para obtener más información acerca de cuándo se recomienda tener grupos de aplicaciones dedicados, vea Modelo de arquitectura lógica: implementación corporativa.

En un entorno de host en que el contenido de varias organizaciones esté hospedado en una sola granja de servidores, recomendamos hospedar todo el contenido de una organización en el mismo grupo de aplicaciones. Esto le proporcionará una mayor escalabilidad (con menos grupos de aplicaciones, tiene menos procesos en ejecución) así como el aislamiento de los procesos entre los grupos de aplicaciones (de modo que si el grupo de aplicaciones del cliente A se detiene, no afecta a los sitios del cliente B). Esto, por supuesto, dependerá del número de organizaciones que tenga, de lo que recomiende su plan de rendimiento y de cuáles sean sus requisitos de aislamiento.

Planeación de la configuración general de la aplicación web

En la página Configuración general de la aplicación web, hay varias opciones que pueden ayudar a administrar el crecimiento de los datos y la manera en que se encuentra el contenido actual en los sitios de grupo del entorno. Estas opciones se aplican a todos los sitios de una aplicación web. Como mínimo, piense en implementar las opciones de configuración siguientes, cada una de las cuales se explica más adelante en esta sección:

• Defina y aplique una plantilla de cuota para limitar el tamaño máximo de sitios de grupo.

• Establezca un tamaño máximo de carga. Elija un tamaño amplio que se base en los requisitos de la empresa para que los usuarios puedan colaborar fácilmente.

• Active las papeleras de reciclaje del sitio y use la papelera de reciclaje de la segunda etapa.

Además de las opciones de configuración enumeradas anteriormente, evalúe todos los valores de características de la página Configuración general de la aplicación web para asegurarse de que son adecuadas para los sitios de grupo de la organización. De forma predeterminada, se habilitan las siguientes características:

• Etiqueta inteligente de nombre de persona y Estado de conexión (se muestra información sobre la presencia en línea)

• Alertas (los usuarios pueden crear un máximo de 500 alertas de forma predeterminada)

• Fuentes Really Simple Syndication (RSS)

• Interfaz de programación de aplicaciones (API) de blog (vínculo para crear un blog)

Determinación de la configuración de la plantilla de cuota

No hay ninguna plantilla de cuota predeterminada para los sitios de grupo de un entorno de Office SharePoint Server 2007. Sin embargo, se recomiendan las siguientes opciones como punto de partida:

• Se envía un mensaje de correo electrónico automatizado al propietario de un sitio cuando el tamaño del sitio alcanza 450 megabytes (MB).

• Se impide a los usuarios cargar documentos adicionales cuando el tamaño de un sitio alcanza 500 MB.

Estas opciones pueden funcionar bien para su organización, pero debe evaluar el tamaño y el número de elementos que se espera que los usuarios almacenen en los sitios de grupo y ajustar estos valores según corresponda para garantizar que los sitios de grupo se usan como está previsto en la organización.

Por ejemplo, si su organización incluye grupos de investigación o diseño que colaboran para producir un gran volumen de contenido que debe almacenarse y archivarse, piense en aumentar los límites de cuota (por ejemplo, aumente el límite del sitio hasta 5 ó 10 gigabytes (GB)). En estos escenarios, hospedar el contenido en sitios de grupo garantiza que se realizan copias de seguridad regulares del contenido y que todos los individuos que necesiten contribuir pueden hacerlo. También puede colocar una colección de sitios de 5-10 GB en su propia base de datos de contenido, sobre todo si espera que esa colección de sitios crezca rápidamente.

Por otro lado, si los sitios de grupo se usan principalmente para proyectos a corto plazo o sitios de comunicación de grupo, considere la posibilidad de usar un límite de cuota inferior. De esta forma, los equipos almacenarán sólo la información necesaria para el avance de proyectos a corto plazo (sin embargo, asegúrese de que el límite no es muy bajo, ya que corre el riesgo de que aumenten los costos asociados a las solicitudes de aumento de cuota al departamento de soporte técnico). En este escenario, pida a los equipos que almacenen el contenido general del equipo o el contenido de un nuevo proyecto en otros sitios de grupo.

Si un equipo o grupo determinados de la organización tienen el requisito empresarial de almacenar un mayor volumen de contenido en su sitio de grupo, puede ajustar los límites de cuota de una colección de sitios individual. Para ajustar los límites de cuota, en la página Bloqueos y cuotas de colección de sitios, seleccione la colección de sitios que corresponda al equipo o grupo. Cambie la plantilla de cuota actual a Cuota individual y, a continuación, especifique los límites adecuados.

Al planear las plantillas de cuota, elija límites que funcionen para la mayoría de los sitios de grupo de la organización. Para mejorar la administración, ajuste sólo las cuotas por usuario cuando sea necesario satisfacer un requisito empresarial.

Determinación del tamaño de carga máximo

El tamaño de carga máximo predeterminado es de 50 MB. Se considera que 50 MB es un límite generoso que concede a los usuarios la flexibilidad de cargar muchos tipos y tamaños de documentos sin afectar negativamente al rendimiento. Si los usuarios de la organización necesitan almacenar archivos de mayor tamaño en sus sitios de grupo, considere la posibilidad de ajustar esta configuración y no olvide supervisar la configuración de tiempo de espera de IIS si tiene usuarios con conexiones más lentas.

Determinación de la configuración de la papelera de reciclaje

Activar la papelera de reciclaje es una forma sencilla de mejorar la capacidad de administración de los sitios de grupo. La papelera de reciclaje permite a los propietarios de sitios recuperar los elementos que se han eliminado sin requerir ninguna intervención administrativa central (para restaurar los datos desde las cintas de copia de seguridad).

En la lista siguiente se describe la configuración predeterminada de la papelera de reciclaje, que funciona correctamente para la mayoría de las organizaciones:

• Estado de la papelera de reciclaje: activada

• Eliminar elementos de la papelera de reciclaje: después de 30 días

• Papelera de reciclaje de la segunda etapa: agregar el 50% de cuota del sitio activo para elementos eliminados de la segunda etapa

La papelera de reciclaje de la segunda etapa almacena los elementos que los usuarios eliminaron de sus papeleras de reciclaje. Sólo los administradores de colecciones de sitios pueden restaurar elementos desde la papelera de reciclaje de la segunda etapa. El tamaño que se especifica para la papelera de reciclaje de la segunda etapa aumenta el tamaño total del sitio de grupo. Por ejemplo, si el límite del sitio de grupo es de 500 MB y la papelera de reciclaje de la segunda etapa se establece al 50%, la cantidad total que se puede usar en el sitio equivale a 750 MB, por lo que se debe planear la capacidad de la base de datos en consecuencia.

Al igual que sucede con la papelera de reciclaje, los elementos de la papelera de reciclaje de la segunda etapa se eliminan automáticamente cuando se alcanza el período de tiempo para los elementos eliminados (30 días, de forma predeterminada). Sin embargo, cuando se alcanza el límite de tamaño de la papelera de reciclaje de la segunda etapa, los elementos se eliminan automáticamente de la misma, empezando por los más antiguos. Los administradores de colecciones de sitios también pueden vaciar la papelera de reciclaje de la segunda etapa manualmente.

Algunas consideraciones clave cuando se usa la característica de papelera de reciclaje son si se va a usar la papelera de reciclaje de la segunda etapa y cuánto espacio se le va a asignar. Considere la posibilidad de asignar al menos una pequeña cantidad de espacio (como un 10 %) a la papelera de reciclaje de la segunda etapa por si se da el caso de que un usuario elimine por equivocación un documento importante, una carpeta de una biblioteca de documentos o una columna de una lista.

Planeación del método de creación de sitios

Puede decidir si desea crear colecciones de sitios para los sitios de grupo de forma centralizada o que los usuarios creen sus propias colecciones de sitios mediante Administración de sitios sin intervención del administrador. Ambos métodos tienen ventajas y desventajas.

Si permite a los equipos crear colecciones de sitios mediante la administración de sitios sin intervención del administrador, los equipos pueden crear un sitio fácilmente, según lo requieran, sin ayuda de un administrador. Sin embargo, esta opción tiene muchos inconvenientes, entre los que se pueden citar los siguientes:

• Pierde la oportunidad de implementar una taxonomía bien meditada.

• La aplicación podría llegar a ser difícil de administrar.

• Resulta fácil abandonar los sitios.

• Las plantillas y la navegación no se pueden compartir entre proyectos o equipos que, de otra forma, podrían compartir una colección de sitios.

Si en su lugar crea colecciones de sitios de forma centralizada, según el funcionamiento de la organización, podrá implementar una taxonomía exhaustiva que proporcione una estructura para la forma en que los sitios de grupo se administran y crecen. Además, habrá más oportunidades para el uso compartido de plantillas y para la navegación entre los proyectos y los equipos que comparten una colección de sitios. Con este enfoque, después de haber creado la colección de sitios inicial, los equipos pueden crear sitios en ella según sus necesidades. Sin embargo, se gastarán recursos de TI cada vez que un usuario desee crear un sitio.

Para obtener ejemplos de cuándo se debe usar cada método, vea Modelo de arquitectura lógica: implementación corporativa. Para obtener más información acerca de cómo planear la creación de sitios, vea Planeación del proceso para la creación de sitios (Office SharePoint Server).

Si su organización ha elegido crear colecciones de sitios para los sitios de grupo en lugar de permitir a los usuarios crear sus propias colecciones de sitios de grupo, use la hoja de trabajo de rutas de acceso a sitios (https://go.microsoft.com/fwlink/?linkid=73149&clcid=0xC0A) (en inglés) para determinar el nivel en el que se crean los sitios de grupo: sitios de nivel superior en sus propias colecciones de sitios o una colección de sitios grande con varios subsitios. Para obtener más información acerca de cómo determinar si se deben crear muchas colecciones de sitios o sólo algunas colecciones de sitios con muchos subsitios, vea la sección en que se explica la decisión sobre el uso de colecciones de sitios individuales o subsitios en una colección de sitios en Determine sites and subsites needed [Windows SharePoint Services], en la Biblioteca técnica de Windows SharePoint Services 3.0. Para obtener más información acerca de los tipos de sitios disponibles en Office SharePoint Server 2007, vea Determinación de los sitios y subsitios.

Diseño de la configuración de la base de datos de contenido para sitios de grupo

En Modelo de arquitectura lógica: implementación corporativa, los sitios de grupo se almacenan en bases de datos dedicadas (una por colección de sitios). Este enfoque permite administrar cada base de datos de la colección de sitios de forma independiente para realizar operaciones de copia de seguridad, recuperación y migración. Además, cuando un proyecto se haya completado, puede archivar fácilmente la base de datos asociada al proyecto. Aunque con este enfoque se crean muchas bases de datos, podrá controlar de forma individual la base de datos de cada colección de sitios.

Sin embargo, tenga en cuenta que el rendimiento de SQL Server puede verse afectado por el número de bases de datos por instancia de SQL Server. Es decir, si planea tener 300 colecciones de sitios de grupo o más, almacenar cada una en una base de datos dedicada puede reducir el rendimiento de SQL Server. Esto se debe a que cada base de datos representa una conexión entre el grupo de aplicaciones y SQL Server. Al agregar servidores web y bases de datos, aumenta el número de conexiones activas. Si se agrega un número excesivo de conexiones, SQL Server puede dejar de responder.

Por lo tanto, si piensa tener más de 300 colecciones de sitios de grupo, no debería usar bases de datos dedicadas. En su lugar, debería almacenar varias colecciones de sitios en cada base de datos. Tenga en cuenta que el departamento de TI de Microsoft usa 300 bases de datos y que este número no es un límite máximo, sino una estimación basada en los datos de SharePoint Portal Server 2003, donde 300 bases de datos representan un nivel de confianza para Microsoft en relación con el número de colecciones de sitios que pueden hospedarse de forma segura en cada servidor. El número variará en función de varios parámetros, como el número de bases de datos. Por ejemplo, usar o no bases de datos dedicadas también puede depender de factores como los siguientes:

• ¿Los equipos tienen diferentes contratos de nivel de servicio (por ejemplo, distintos requisitos de copia de seguridad)?

• ¿Los equipos requieren más de 8 GB de espacio de almacenamiento?

• ¿Los equipos tienen diferentes escalas de tiempo de proyecto? Mezclar equipos con proyectos a corto plazo y equipos con proyectos a largo plazo puede dificultar el archivado de los sitios y su traslado fuera del entorno de producción si comparten la misma base de datos.

• ¿Sus equipos esperan un alto grado de autonomía e independencia para las operaciones que se producen en el nivel de base de datos?

Si responde afirmativamente a cualquiera de estas preguntas, debe considerar el uso de bases de datos dedicadas para las colecciones de sitios.

Si decide almacenar varias colecciones de sitios en cada base de datos, puede calcular cuántas se pueden almacenar en cada base de datos al determinar el tamaño máximo de cualquier base de datos y el tamaño máximo de cada colección de sitios (según el límite de almacenamiento de la plantilla de cuota más la asignación de la papelera de reciclaje). Tenga en cuenta que incluso si asigna en todos los casos cuotas de 500 MB, no todos las usarán al completo, por lo que quizás cree un número excesivo de bases de datos de contenido. Considere las estimaciones de cuota en la planeación de la base de datos, pero asegúrese de que realiza un seguimiento del uso real y se adapta al mismo. Si tuviera un entorno anterior con SharePoint Portal Server 2003 o Windows SharePoint Services 2.0, también podría ver el tamaño que tenían las colecciones de sitios y crear bases de datos basándose en esos tamaños reales en lugar de en las estimaciones de cuota.

En un entorno administrado, los límites de tamaño de la base de datos suelen estar determinados por los siguientes factores:

• El tiempo necesario para realizar una copia de seguridad de una base de datos. A partir de un determinado tamaño de base de datos, las operaciones de copia de seguridad son ineficaces, requieren más tiempo del necesario y pasan a estar sujetas a otros problemas. Además, puede ser el momento de decidir agregar más servidores de base de datos al entorno.

• La ventana de servicio (la cantidad de tiempo) asignado para la restauración de contenido, según lo determinado en el contrato de nivel de servicio. Por ejemplo, si la ventana de servicio para restaurar contenido es de cuatro horas, el tamaño de la base de datos estará limitado al volumen que puede restaurarse en ese período.

Para saber cuál es el tamaño máximo para las bases de datos de las colecciones de sitios de grupo que sería más fácil de administrar, determine los valores enumerados en la tabla siguiente.

A partir de los dos valores para el volumen de contenido (B y D), el tamaño máximo de base de datos posible para la organización es el menor de los dos valores.

Después de determinar el tamaño de destino de las bases de datos de contenido, puede calcular el número de colecciones de sitios que puede admitirse en cada base de datos. En la tabla siguiente se muestra el número de colecciones de sitios por cada base de datos según los límites de tamaño de la base de datos y de la colección de sitios. Los límites de tamaño de la colección de sitios incluyen el espacio asignado a la papelera de reciclaje de la segunda etapa.

Cuando cree la aplicación web para los sitios de grupo, modifique la configuración mediante la página Administrar bases de datos de contenido para la primera base de datos de contenido con el número máximo de colecciones de sitios correspondiente a los límites de tamaño objetivo de la base de datos y de la colección de sitios (Número máximo de sitios). Especifique también el umbral del número de sitios que desencadenará una advertencia (Advertencia del nivel del sitio). Cuando se alcance este valor, cree una base de datos con la misma configuración. Cuando se alcance el número máximo de colecciones de sitios, no se crearán nuevas colecciones de sitios dentro de la base de datos. Si no se ha creado otra base de datos, se producirá un error en la creación de sitios.

Eliminación automática de sitios no usados

Puede aumentar la validez del contenido en los sitios de grupo al eliminar automáticamente los sitios que no se usan. Esto puede ayudarle a controlar el crecimiento general de los sitios de grupo. Si los sitios de grupo se hospedan en una aplicación web independiente, puede administrar los sitios de grupo no usados de forma diferente a los sitios personales; por ejemplo, puede proporcionarles una mayor duración antes de empezar a consultar los sitios web que no se usan.

De manera predeterminada, no se habilita la configuración de eliminación automática de sitios. Para administrar la configuración de eliminación de sitios, en la página Administración de aplicaciones, en la sección Administración de sitios de SharePoint, haga clic en Confirmación y eliminación del uso de sitios.

Si se habilita esta característica, la configuración predeterminada incluye lo siguiente:

• Se envían notificaciones por correo electrónico a los propietarios de los sitios 90 días después de la creación de la colección de sitios para confirmar su uso. Es decir, si no se confirma el uso de un sitio durante 90 días, el propietario del sitio recibe una notificación.

• El sistema busca las colecciones de sitios no confirmadas y envía avisos diariamente a medianoche.

• No se activa la opción para eliminar automáticamente las colecciones de sitios no confirmadas. Si esta opción está activada, los sitios se eliminan automáticamente tras enviar 28 avisos. Como alternativa, puede especificar el número de avisos.

Según la configuración predeterminada, una colección de sitios que no se ha usado durante 90 días se elimina después de 28 avisos o 118 días tras la última confirmación del sitio. Puede especificar una configuración que sea adecuada para su organización. Dado que esta característica funciona por medio de confirmaciones y no se realiza un seguimiento del uso real del sitio, debe planear las ausencias inesperadas de los propietarios de los sitios y no establecer períodos de tiempo cortos para su expiración y eliminación. Además, no olvide designar siempre varios administradores de colecciones de sitios de manera que siempre haya un administrador de reserva para confirmar el uso del sitio si el administrador principal de la colección de sitios está ausente durante un período de tiempo prolongado.

La eliminación automática de sitios puede ayudar a controlar el entorno, pero se corre el riesgo de almacenar datos críticos para la empresa en un sitio que haya sido eliminado automáticamente. Para minimizar este riesgo, se recomienda:

• Solicitar que haya un segundo contacto para todos los sitios. De esta forma, si el propietario del sitio no está disponible o abandona la organización, todavía habrá un contacto disponible para confirmar si un sitio se encuentra en uso. Si no tiene un segundo contacto y reduce el número de días o el número de avisos antes de eliminar un sitio no usado, se arriesga a eliminar accidentalmente un sitio que es necesario. Aplique esta recomendación cuando active Administración de sitios sin intervención del administrador o como proceso de negocio para crear colecciones de sitios desde Administración central.

• Archivar los sitios antes de que se eliminen automáticamente. Muchas organizaciones que implementan la eliminación automática de sitios no usados también invierten en el desarrollo de una herramienta que archive todos los sitios antes que se eliminen automáticamente, por lo que se pueden restaurar fácilmente si hay información empresarial importante en ellos. O bien, piense en almacenar las bases de datos de contenido a largo plazo por si un un sitio eliminado necesita restaurarse en el futuro.

Uso de rutas de acceso o nombres de host para organizar las direcciones URL de los sitios de grupo

En función de la organización y de cómo vaya a usar los sitios de grupo, considere la posibilidad de usar rutas de acceso para organizar las direcciones URL de los sitios de grupo. Por ejemplo, si desea tener direcciones URL diferentes para los sitios de grupo que estén asociados a distintas divisiones, puede usar direcciones URL, como http://nombre_compañía/nombre_división/sites o http:// nombre_compañía/research/sites. De forma similar, puede hacer evidente la asociación a un sitio de intranet publicado mediante http:// nombre_intranet/teamsites. Si va a usar Administración de sitios sin intervención del administrador, la dirección URL predeterminada para los sitios de grupo es http://nombre_servidor/sites, pero también podría incluir caracteres comodín para http://nombre_servidor/team o el prefijo que prefiera para los sitios de grupo.

Para obtener más información acerca de las rutas de acceso, vea los siguientes recursos:

• Planeación de sitios de colaboración

• Determinación de los sitios y subsitios

• "Uso de inclusiones explícitas y de comodines para rutas de acceso de direcciones URL", en Modelo de arquitectura lógica: implementación corporativa

• Notas del producto sobre la creación de soluciones de host compartidas en Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=86128&clcid=0xC0A)

Además, puede crear sitios con nombre de host si tiene sitios de grupo con una función más amplia en la organización. Por ejemplo, si su sitio web de recursos humanos es un sitio de grupo y no forma parte del sitio de intranet publicado, puede crear un sitio de grupo con nombre de host para el sitio denominado http://hrsite o http://humanresources.

Planeación de elementos personalizados

Las personalizaciones pueden aumentar la complejidad del entorno, especialmente cuando se desea probar todos los paquetes de soluciones varias veces: antes de implementarlos, cuando se necesita aplicar una actualización y cuando se va a actualizar el entorno. Debe decidir cuál será la directiva de la organización en cuanto al uso de características personalizadas, plantillas, elementos web, etc. y planear la administración, la compatibilidad y el uso de estos elementos en el entorno.

• Administración Si necesita realizar una operación de copia de seguridad y restauración de todo el entorno (por ejemplo, para la recuperación ante desastres o para mover hardware), debe disponer de copias de seguridad de todos los elementos personalizados (como un elemento web personalizado que se desarrolló para su entorno o una definición de sitio personalizada) y recordar que deben agregarse otra vez cuando se restaure el entorno. Esto se debe a que no se puede restaurar la base de datos de configuración, que contiene todas las referencias a estos elementos personalizados, por lo que debe agregarlos al volver a restaurar el entorno. Por ejemplo, debe volver a agregar las definiciones de sitios personalizadas e instalar los componentes web personalizados. Si olvida un elemento personalizado durante el traslado a un nuevo servidor o al restaurar un servidor, puede provocar errores en los sitios de grupo de los usuarios y deberá realizar un seguimiento del código necesario mientras los usuarios esperan.

• Compatibilidad Tener elementos personalizados en el entorno puede aumentar el tiempo de solución de problemas cuando algo va mal. Cada fragmento de código personalizado es único y puede ser complejo o sencillo y consumir memoria adicional al ejecutarse. Tenga en cuenta el número de lugares donde se usa el código personalizado y cuál es su impacto en el sistema. Además, considere cómo se pueden descartar las personalizaciones como origen de un error a la hora de solucionar problemas. Si va a crear el código personalizado usted mismo, no olvide diseñarlo de forma que cualquier error causado por las personalizaciones se registre en el registro de eventos (para eventos de Microsoft Operations Manager (MOM)) y en cualquier otra ubicación que su organización use para solucionar problemas.

• Uso Debe tener en cuenta si sus soluciones, elementos web y plantillas son prácticos. Si tiene tantas plantillas personalizadas para los sitios de grupo del entorno que la lista de plantillas o elementos web ocupan varias pantallas (por ejemplo, 50 es un número difícil de leer y diferenciar), considere si necesita todos esos elementos personalizados, si se puede dividir la lista de alguna manera o si se deben resumir en selecciones de características comunes para que su navegación y seguimiento sea más fácil.

Algunas organizaciones optan por tener más de una directiva para las personalizaciones. Por ejemplo, pueden decidir tener un sistema de dos o tres niveles: el nivel 1 para sitios normales (con plantillas estándar), el nivel 2 permite algunas personalizaciones (con un contrato de nivel de servicio diferente) y el nivel 3, donde la organización hospeda el hardware, pero el equipo que posee los sitios de grupo es el responsable de ejecutar y administrar su propio entorno personalizado con dicho hardware. Se trata de otro caso donde puede desear que varias aplicaciones web hospeden los sitios de grupo, con diferentes contratos de nivel de servicio para cada aplicación web.

Planeación de los permisos que se aplican a los sitios de grupo

Los permisos y las directivas que se aplican a los sitios de grupo determinan:

• Quién puede crear sitios de grupo

• Quién puede ver y contribuir a los sitios de grupo

• Quién no puede tener acceso al contenido de sitios de grupo

Se recomienda usar grupos de seguridad para administrar los permisos. En la siguiente tabla, se ofrecen referencias para configurar permisos y se indica dónde configurar los permisos.

Descarga de este libro

En este tema se incluye el siguiente libro descargable para facilitar la lectura y la impresión:

• Planeación y arquitectura para Office SharePoint Server 2007 (segunda parte)

Vea la lista completa de libros disponibles en la página que muestra el contenido descargable para Office SharePoint Server 2007.