Planeación de disponibilidad (SharePoint Server 2010)

Se aplica a: SharePoint Foundation 2010, SharePoint Server 2010

Última modificación del tema: 2016-11-30

En este artículo se describen las decisiones clave que se deben tomar con el fin de elegir las estrategias de disponibilidad para un entorno de Microsoft SharePoint Server 2010.

A medida que revise los requisitos de disponibilidad, tenga en cuenta que cuanto más alto sea el nivel de disponibilidad y cuanto más sistemas proteja, más compleja y costosa será la solución de disponibilidad.

Es posible que no todas las soluciones de una organización requieran el mismo nivel de disponibilidad. Puede ofrecer distintos niveles de disponibilidad para distintos sitios, servicios o conjuntos o granjas de servidores.

En este artículo:

• Introducción a la disponibilidad

• Elección de una estrategia y un nivel de disponibilidad

• Redundancia y conmutación por error entre centros de datos próximos configurados como una granja de servidores única (granja de servidores "expandida")

Introducción a la disponibilidad

La disponibilidad es el grado en el que los usuarios perciben que un entorno de SharePoint Server está disponible. Un sistema disponible es un sistema que es resistente (es decir, los incidentes que afectan al servicio no son frecuentes y, cuando suceden, se buscan soluciones a tiempo y efectivas).

La disponibilidad es parte de la administración de continuidad empresarial (BCM) y está relacionada con las copias de seguridad, la recuperación y la recuperación ante desastres. Para obtener más información sobre los procesos relacionados, vea Planeación de copia de seguridad y recuperación en SharePoint (Server 2010) y Planeación de la recuperación ante desastres (SharePoint Server 2010).

Una de las medidas más comunes de la disponibilidad es el porcentaje de tiempo activo expresado en cantidad de nueves (es decir, el porcentaje de tiempo en el que un sistema determinado está activo y trabajando). Por ejemplo, se considera que un sistema con un porcentaje de tiempo activo de 99,999 tiene una disponibilidad de cinco nueves.

La siguiente tabla presenta de forma correlativa porcentajes de tiempo activo y equivalentes de tiempo del calendario.

Si puede hacer una suposición fundada sobre la cantidad total de horas de tiempo de inactividad que posiblemente tenga por año, puede usar las siguientes fórmulas para calcular el porcentaje de tiempo de actividad por año, mes o semana:

% tiempo de actividad/año = 100 − (8760 − cantidad total de horas de tiempo de inactividad por año)/8760

% tiempo de actividad/mes = 100 − (24 × cantidad de días de un mes) − cantidad total de horas de tiempo de inactividad en ese mes del calendario)/(24 × cantidad de días del mes)

% tiempo de actividad/semana = 100 − (168 − cantidad total de horas de tiempo de inactividad en esa semana)/168

Costos de la disponibilidad

La disponibilidad es uno de los requisitos más costosos para un sistema. Cuanto más alto sea el nivel de disponibilidad y cuanto más sistemas se protejan, más compleja y costosa será la solución de disponibilidad. Cuando se invierte en disponibilidad, los costos incluyen lo siguiente:

• Hardware y software adicional, lo que puede aumentar la complejidad de las interacciones entre las aplicaciones y los entornos de software.

• Complejidad operativa adicional.

Los costos de mejorar la disponibilidad deben evaluarse junto con las necesidades de negocio, ya que no todas las soluciones de una organización requerirán el mismo nivel de disponibilidad. Puede ofrecer distintos niveles de disponibilidad para distintos sitios, servicios o granjas de servidores.

La disponibilidad es un área clave en la que los grupos de tecnología de la información (TI) ofrecen contratos de nivel de servicio (SLA) para establecer las expectativas con los grupos de clientes. Muchas organizaciones de TI ofrecen varios SLA asociados con distintos niveles de facturación.

Determinación de los requisitos de disponibilidad

Para evaluar la tolerancia que tiene la organización al tiempo de inactividad de un sitio, servicio o granja de servidores, responda las siguientes preguntas:

• Si el sitio, el servicio o la granja de servidores no está disponible, ¿será un impedimento para que los empleados lleven a cabo sus responsabilidades laborales?

• Si el sitio, el servicio o la granja de servidores no está disponible, ¿se detendrán las transacciones comerciales y de los clientes, lo que produciría una pérdida de negocios y de clientes?

Si respondió afirmativamente alguna de estas preguntas, debe invertir en una solución de disponibilidad.

Elección de una estrategia y un nivel de disponibilidad

Se puede elegir entre muchos enfoques para mejorar la disponibilidad en un entorno de SharePoint Server, entre los que se encuentran los siguientes:

• Mejorar la tolerancia a errores de los componentes del hardware de servidor.

• Aumentar la redundancia de roles de servidor dentro de una granja de servidores.

Tolerancia a errores de componentes de hardware

La tolerancia a errores de componentes de hardware es la redundancia de componentes de hardware y sistemas de infraestructura, como sistemas de alimentación en el nivel del servidor. Al planear la tolerancia a errores de componentes de hardware, considere lo siguiente:

• La redundancia completa de todos los componentes de un servidor puede no ser posible o práctica. Use servidores adicionales para conseguir redundancia adicional.

• Para obtener una redundancia mayor, asegúrese de que los servidores tengan varios sistemas de alimentación conectados a diferentes fuentes de energía.

En cualquier sistema, se recomienda que trabaje con proveedores de hardware para conseguir hardware con tolerancia a errores que sea apropiado para el sistema, incluida una matriz redundante de matrices de discos independientes (RAID). Para obtener recomendaciones, vea Administración del rendimiento y de la capacidad (SharePoint Server 2010) y Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

Redundancia en una granja de servidores

SharePoint Server 2010 admite la ejecución de roles de seguridad en equipos redundantes (también denominado "escalar") en una granja de servidores para aumentar la capacidad y mejorar la disponibilidad básica.

La capacidad que necesita determina tanto la cantidad de servidores como el tamaño de los servidores de la granja de servidores. Una vez cumplidos los requisitos de la capacidad base, es posible que desee agregar más servidores para aumentar la disponibilidad general. En la siguiente ilustración, se muestra cómo puede ofrecer redundancia para cada rol de servidor.

Disponibilidad en una granja de servidores

En la siguiente tabla se describen los roles de servidor de un entorno de SharePoint Server 2010 y las estrategias de redundancia que puede usar para cada uno en una granja de servidores.

Estrategias de disponibilidad de bases de datos

Puede usar la agrupación de clústeres de conmutación por error de Microsoft SQL Server o la creación de reflejos de la base de datos con alta disponibilidad de SQL Server para permitir la compatibilidad de disponibilidad de bases de datos en un entorno de SharePoint Server.

Agrupación de clústeres de conmutación por error de SQL Server

La agrupación de clústeres de conmutación por error puede ofrecer compatibilidad de disponibilidad para una instancia de SQL Server. Un clúster de conmutación por error es una combinación de uno o más nodos o servidores y dos o más discos compartidos. Una instancia de un clúster de conmutación por error figura como un equipo único pero tiene funcionalidad que proporciona conmutación por error de un nodo a otro si el nodo actual no está disponible. SharePoint Server puede ejecutarse en cualquier combinación de nodos activos y pasivos en un clúster compatible con SQL Server.

SharePoint Server hace referencia al clúster en su totalidad. Por lo tanto, la conmutación por error es automática y no presenta problemas desde la perspectiva de SharePoint Server.

Para obtener información sobre clústeres de conmutación por error, vea el tema de introducción a los clústeres de conmutación por error de SQL Server 2008 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0xC0A) y Configuración de la disponibilidad mediante la agrupación en clústeres de SQL Server (SharePoint Server 2010).

Creación de reflejo con alta disponibilidad de SQL Server

La creación de reflejo de la base de datos es una tecnología de SQL Server que puede proporcionar redundancia por cada base de datos. En la creación de reflejo de la base de datos, las transacciones se envían directamente desde una base de datos y un servidor principales a una base de datos y un servidor reflejados cuando el búfer de registro de transacciones de la base de datos principal se escribe en el disco. Gracias a esta técnica es posible mantener la base de datos reflejada prácticamente al día en relación con la base de datos principal. SQL Server Enterprise Edition proporciona funcionalidad adicional que mejora el rendimiento de la creación de reflejo de la base de datos. Para obtener más información, vea SQL Server 2008 R2 y productos de SharePoint 2010: mejor juntos (notas del producto) (SharePoint Server 2010).

Para crear reflejos en una granja de servidores de SharePoint Server, debe usar la creación de reflejos con alta disponibilidad, también conocida como seguridad alta con conmutación automática por error. La creación de reflejos de bases de datos con alta disponibilidad consta de tres instancias de servidor: un servidor principal, un servidor reflejado y un servidor testigo. El servidor testigo permite que SQL Server conmute por error del servidor principal al reflejado. Generalmente, la conmutación por error de la base de datos principal a la reflejada tarda varios segundos.

Un cambio de la versión anterior es que SharePoint Server reconoce la creación de reflejos. Después de configurar una instancia de una base de datos reflejada de SQL Server, puede usar Administración central de SharePoint o cmdlets de Windows PowerShell para identificar la ubicación del servidor de bases de datos (reflejadas) de conmutación por error, de la base de datos de contenido o de la base de datos de aplicaciones de servicio. La configuración de la ubicación de una base de datos de conmutación por error agrega un parámetro a la cadena de conexión que SharePoint Server usa para conectarse a SQL Server. Si se produce un evento porque se supera el tiempo de espera en SQL Server, sucede lo siguiente:

1. El servidor testigo configurado para la creación de reflejos de SQL Server intercambia automáticamente los roles de las bases de datos principal y reflejada.

2. SharePoint Server intenta comunicarse automáticamente con el servidor especificado como la base de datos de conmutación por error.

Para obtener información sobre cómo configurar la creación de reflejos de bases de datos, vea Configurar la disponibilidad mediante la creación de un reflejo de la base de datos de SQL Server (SharePoint Server 2010).

Para obtener información sobre cómo configurar la creación de reflejos de bases de datos, vea el tema sobre creación de reflejos de bases de datos (https://go.microsoft.com/fwlink/?linkid=180597&clcid=0xC0A).

Comparativa de estrategias de disponibilidad de bases de datos para una única granja de servidores: la agrupación de clústeres de conmutación por error de SQL Server frente a la creación de reflejos con alta disponibilidad de SQL Server

En la siguiente tabla, se compara la agrupación de clústeres de conmutación por error con la creación de reflejos con alta disponibilidad de SQL Server sincrónica.

Estrategias de redundancia para aplicaciones de servicio

La estrategia de redundancia que se implemente para proteger las aplicaciones de servicio que se ejecutan en varias granjas de servidores dependerá de dónde almacene los datos la aplicación de servicio.

Aplicaciones de servicio que almacenen datos fuera de una base de datos

Para proteger las aplicaciones de servicio que almacenen datos fuera de una base de datos, instale la aplicación de servicio en varios servidores de aplicaciones para proporcionar redundancia dentro del entorno.

En esta versión de SharePoint Server, al instalar una aplicación de servicio en varios servidores de aplicaciones, los trabajos del temporizador se ejecutarán en todos los servidores de aplicaciones que ejecutan la instancia de servicio asociada a esa aplicación de servicio, o bien en el primer servidor disponible. Si se produce un error en un servidor de aplicaciones, los trabajos del temporizador que se ejecuten en ese servidor se reiniciarán en otro servidor cuando el siguiente trabajo del temporizador esté programado para ejecutarse.

La instalación de una aplicación de servicio en varios servidores de aplicaciones mantiene la aplicación de servicio en ejecución, pero no garantiza que no se pierdan datos. Si se produce un error en un servidor de aplicaciones, se perderán las conexiones activas de ese servidor de aplicaciones y los usuarios perderán algunos datos.

Las siguientes aplicaciones de servicio almacenan datos fuera de una base de datos:

• Servicios de Access

• Aplicación de Servicios de Excel

Aplicaciones de servicio que almacenan datos en bases de datos

Para ayudar a proteger las aplicaciones de servicio que almacenan datos en bases de datos, debe seguir estos pasos:

1. Instale el servicio en varios servidores de aplicaciones para proporcionar redundancia dentro del entorno.

2. Configure la creación de clústeres o reflejos de SQL Server para proteger los datos.

Las siguientes aplicaciones de servicio almacenan datos en bases de datos:

• Aplicación del servicio de búsqueda, incluidas las siguientes bases de datos:

  • Administración de búsqueda

  • Rastreo

  • Propiedad

    Nota

    Se admite la creación de reflejo de las bases de datos de búsqueda, pero son necesarias algunas acciones adicionales para proporcionar redundancia para la búsqueda. Para obtener información detallada, vea la sección Estrategias de redundancia de búsqueda en una granja de servidores.

• Servicio de perfiles de usuario, incluidas las siguientes bases de datos:

  • Perfiles

  • Social

  • Sincronización

    Nota

    No se admite la creación de reflejo de la base de datos de sincronización.

• Aplicación de Servicio de conectividad a datos empresariales

• Aplicación de servicio del Registro de aplicaciones

  No se recomienda crear un reflejo de la base de datos del Registro de aplicaciones, porque solo se usa al actualizar la información del Catálogo de datos profesionales de Microsoft Office SharePoint Server 2007 a SharePoint Server 2010.

• Aplicación de servicio de recolección de datos de mantenimiento y uso

  Nota

  No se recomienda crear un reflejo de la base de datos de registros de la aplicación de servicio de recolección de datos de mantenimiento y uso.

• Aplicación de servicio de metadatos administrados

• Aplicación de servicio de almacenamiento seguro

• Aplicación de servicio de estado

• Aplicación de servicio de Web Analytics, incluidas las siguientes bases de datos:

  • Informes

  • Almacenamiento provisional

    Nota

    No se admite la creación de reflejo de la base de datos provisional.

• Aplicación del servicio Word Automation Services

• Servicio de configuración de suscripción de Microsoft SharePoint Foundation

• PerformancePoint Services

Estrategias de redundancia de búsqueda en una granja de servidores

Servidor únicamente

La aplicación del servicio de búsqueda es un caso especial de redundancia en una granja de servidores. En la siguiente ilustración se muestra cómo se pueden configurar la redundancia y la conmutación por error para una aplicación del servicio de búsqueda dedicada mediana que rastrea aproximadamente 40 millones de elementos. Para obtener más información acerca de la arquitectura de la aplicación del servicio de búsqueda, vea el tema sobre las arquitecturas de búsqueda de Microsoft SharePoint Server 2010 en el artículo Diagramas técnicos (SharePoint Server 2010).

Aplicación del servicio de búsqueda redundante

• Servidor de consultas. Un servidor de consultas hospeda componentes de consulta y particiones de índice.

  • Los componentes de consulta devuelven resultados de búsqueda. Cada componente de consulta forma parte de una partición de índice asociada a una base de datos de propiedades específica que contiene metadatos asociados a un conjunto específico de contenidos rastreados. Para que una partición de índice sea redundante, se deben agregar componentes de consulta "reflejados" a una partición de índice y colocarlos en distintos servidores de la granja.

    Nota

    El uso del término componentes de consulta reflejados hace referencia a copias de archivos idénticas, no a la creación de reflejo de la base de datos de SQL Server.

  • Las particiones de índice son grupos de componentes de consulta, cada uno de los cuales contiene un subconjunto del índice de texto completo y devuelve resultados de búsqueda. Cada partición de índice está asociada a una base de datos de propiedades específica que contiene metadatos asociados a un conjunto específico de contenidos rastreados. Puede determinar qué servidores de una granja de servidores atenderán las consultas mediante la creación de un componente de consulta en ese servidor. Para equilibrar la carga de atención de las consultas entre varios servidores de la granja, debe agregar componentes de consulta a una partición de índice y asociarlos a los servidores que desea usar para atender las consultas. Para obtener más información, vea Agregar o quitar un componente de consulta. Para que una partición de índice sea redundante, se deben agregar componentes de consulta reflejados a una partición de índice y colocarlos en distintos servidores de consultas.

• Servidor de rastreo. Un servidor de rastreo hospeda componentes de rastreo y un componente de administración de búsqueda.

  • Los componentes de rastreo procesan rastreos de orígenes de contenido, propagan los archivos de índice resultantes a los componentes de consulta y agregan información acerca de la ubicación y la programación de rastreo de los orígenes de contenido a las bases de datos de rastreo asociadas. Los componentes de rastreo están asociados a una aplicación del servicio de búsqueda única. La carga de rastreo se puede distribuir mediante la adición de componentes de rastreo a distintos servidores de rastreo. Puede haber tantos componentes de rastreo en un servidor de rastreo determinado como lo permitan los recursos. Si tiene varias ubicaciones de contenido, puede agregar componentes de rastreo y bases de datos de rastreo, y dedicarlos a contenido específico. Cada componente de rastreo de un servidor de rastreo determinado debe estar asociado a una base de datos de rastreo independiente. Para conseguir redundancia, se recomienda que haya al menos dos componentes de rastreo. Debe configurarse cada componente de rastreo de modo que rastree ambas bases de datos de rastreo. Si los elementos de una base de datos superan los 25 millones, se recomienda agregar una base de datos de rastreo y un componente de rastreo nuevos.

  • El componente de administración de búsqueda supervisa las acciones entrantes del usuario y actualiza la base de datos de administración de búsqueda. Solo se permite un componente de administración de búsqueda por aplicación del servicio de búsqueda. El componente de administración de búsqueda puede ejecutarse en cualquier servidor, preferentemente en un servidor de rastreo o un servidor de consultas.

• Servidores de bases de datos. Los servidores de bases de datos hospedan bases de datos de rastreo, bases de datos de propiedades, la base de datos de administración de búsqueda y otras bases de datos de SharePoint Server 2010.

  • Base de datos de rastreo

    Las bases de datos de rastreo contienen datos relacionados con la ubicación de los orígenes de contenido, las programaciones de rastreo y otra información específica de las operaciones de rastreo para una aplicación del servicio de búsqueda específica. La adición de bases de datos de rastreo a diferentes equipos que ejecuten SQL Server permite distribuir la carga de la base de datos. Las bases de datos de rastreo están asociadas a componentes de rastreo y pueden dedicarse a hosts específicos mediante la creación de reglas de distribución de host. Para obtener más información acerca de los componentes de rastreo, vea Adición o eliminación de un componente de rastreo. Para obtener más información acerca de las reglas de distribución de host, vea Adición o eliminación de una regla de distribución de host. Las bases de datos de rastreo son redundantes si se reflejan o implementan en un clúster de conmutación por error de SQL Server.

  • Base de datos de propiedades

    Las bases de datos de propiedades contienen metadatos asociados al contenido rastreado. Para distribuir la carga de la base de datos de las consultas, debe agregar bases de datos de propiedades a diferentes equipos que ejecuten SQL Server. Las bases de datos de propiedades están asociadas a las particiones de índice y devuelven los metadatos asociados al contenido de los resultados de la consulta.

    Las bases de datos de propiedades son redundantes si se reflejan o implementan en un clúster de conmutación por error de SQL Server.

  • Base de datos de administración de búsqueda

    Hay una sola base de datos de administración de búsqueda por cada instancia de aplicación del servicio de búsqueda en una granja de servidores.

    La base de datos de administración de búsqueda solo es redundante si se refleja o implementa en un clúster de conmutación por error de SQL Server.

Para obtener más información acerca de la redundancia de búsqueda, vea Administración de la topología de búsqueda.

Redundancia y conmutación por error entre centros de datos próximos configurados como una granja de servidores única (granja de servidores "expandida")

Algunas empresas tienen centros de datos próximos con conexiones de ancho de banda alto que se pueden configurar como una única granja de servidores. Esto se denomina granja de servidores "expandida". Para que este tipo de granja funcione, debe haber una latencia menor de 1 milisegundo entre SQL Server y los servidores web front-end en una dirección, y al menos un ancho de banda de 1 gigabit por segundo.

En este escenario se puede proporcionar tolerancia a errores siguiendo las instrucciones estándar para convertir las bases de datos y las aplicaciones de servicio en redundantes.

En la siguiente ilustración, se muestra una granja de servidores expandida.

Granja de servidores expandida