Planeación de la disponibilidad (SharePoint Foundation 2010)

 

Se aplica a: SharePoint Foundation 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 Foundation 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 de servidores.

En este artículo:

• Introducción a la disponibilidad

• Elegir una estrategia y un nivel de disponibilidad

• Redundancia y conmutación por error entre centros de datos próximos configurados como un conjunto de servidores único (conjunto de servidores "expandido")

Introducción a la disponibilidad

La disponibilidad es el grado en el que los usuarios perciben que un entorno de SharePoint Foundation 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 Plan de copia de seguridad y recuperación (SharePoint Foundation 2010) y Planeación para la recuperación ante desastres (SharePoint Foundation 2010).

Nota

Al calcular la disponibilidad, la mayoría de las organizaciones excluyen o agregan horas expresamente para las actividades de mantenimiento planeado.

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.

Porcentaje de tiempo activo aceptable	Tiempo de inactividad por día	Tiempo de inactividad por mes	Tiempo de inactividad por año
95	72,00 minutos	36 horas	18,26 días
99 (dos nueves)	14,40 minutos	7 horas	3,65 días
99,9 (tres nueves)	86,40 segundos	43 minutos	8,77 horas
99,99 (cuatro nueves)	8,64 segundos	4 minutos	52,60 minutos
99,999 (cinco nueves)	0,86 segundos	26 segundos	5,26 minutos

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 conjuntos 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 su organización tiene al tiempo de inactividad de un sitio, servicio o conjunto de servidores, responda las siguientes preguntas:

• Si el sitio, servicio o conjunto de servidores no está disponible, ¿impedirá eso que los empleados lleven a cabo sus responsabilidades laborales?

• Si el sitio, servicio o conjunto 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 clientes?

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

Elegir una estrategia y un nivel de disponibilidad

Puede elegir entre muchos enfoques para mejorar la disponibilidad en un entorno de SharePoint Foundation, como los siguientes:

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

• Aumentar la redundancia de roles de servidor dentro de un conjunto 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).

Redundancia en un conjunto de servidores

SharePoint Foundation 2010 admite ejecutar roles de seguridad en equipos redundantes (es decir, escalar) en un conjunto 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 del conjunto 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 un conjunto de servidores

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

Rol del servidor	Estrategia de redundancia preferida en un conjunto de servidores
Servidor web front-end	Implemente varios servidores web front-end y use equilibrio de carga de red (NLB).
Servidor de aplicaciones	Implemente varios servidores de aplicaciones en un conjunto de servidores.
Servidor de base de datos	Implemente servidores de bases de datos con agrupación en clústeres o creación de reflejos de la base de datos con alta disponibilidad.

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 Foundation.

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 Foundation puede ejecutarse en cualquier combinación de nodos activos y pasivos en un clúster compatible con SQL Server.

SharePoint Foundation 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 Foundation.

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 Foundation 2010).

Creación de reflejos con alta disponibilidad de SQL Server

La creación de reflejos de base de datos es una tecnología de SQL Server que puede ofrecer redundancia de base de datos por cada base de datos. En la creación de estos reflejos, las transacciones se envían directamente desde una base de datos y un servidor principales a una base de datos y un servidor reflejados cada vez que el búfer de registro de transacciones de la base de datos principal se escribe en el disco. Esta técnica puede mantener la base de datos reflejada actualizada con la base de datos principal. SQL ServerEnterprise Edition proporciona una funcionalidad adicional que mejora el rendimiento de la base de datos.

Para crear reflejos en un conjunto de servidores de SharePoint Foundation, 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 Foundation 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 Foundation usa para conectarse a SQL Server. Si se produce un evento por que se haya superado 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 Foundation intenta automáticamente comunicarse 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 Configuración de la disponibilidad mediante la creación de reflejos de bases de datos de SQL Server (SharePoint Foundation 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).

Nota

No se puede crear un reflejo de las bases de datos que están configuradas para usar el proveedor de almacenes remotos de blobs de FILESTREAM de SQL Server.

Comparativa de estrategias de disponibilidad de bases de datos para un único conjunto 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.

	Agrupación de clústeres de conmutación por error de SQL Server	Creación de reflejos con alta disponibilidad de SQL Server
Tiempo para la conmutación por error	Un miembro del clúster asume el control inmediatamente al producirse un error.	El reflejo asume el control inmediatamente al producirse un error.
¿Coherencia transaccional?	Sí	Sí
¿Simultaneidad transaccional?	Sí	Sí
Tiempo para la recuperación	Menos tiempo para recuperarse (milisegundos).	Un poco más de tiempo para recuperarse (milisegundos).
¿Pasos necesarios para la conmutación por error?	Los nodos de la base de datos detectan el error automáticamente; SharePoint Foundation 2010 hace referencia al clúster para que la conmutación por error se realice sin problemas y de forma automática.	La base de datos detecta el error automáticamente; SharePoint Foundation 2010 reconoce la ubicación del reflejo, si se configuró correctamente, para que la conmutación por error sea automática.
¿Protección contra el almacenamiento erróneo?	No protege contra el almacenamiento erróneo porque el almacenamiento se comparte entre los nodos del clúster.	Protege contra el almacenamiento erróneo porque los servidores de las bases de datos principal y reflejada escriben en los discos locales.
Tipos de almacenamiento admitidos	Almacenamiento compartido (más costoso).	Puede usar almacenamiento directo (DAS).
Requisitos de ubicación	Los miembros del clúster tienen que estar en la misma subred.	Los servidores principal, reflejado y testigo tienen que estar en la misma LAN (con una latencia de recorrido de ida y vuelta de hasta 1 milisegundo).
Modelo de recuperación	Se recomienda el modelo de recuperación completa de SQL Server. Puede usar el modelo de recuperación simple de SQL Server, pero el único punto de recuperación disponible si el clúster se pierde será la última copia de seguridad completa.	Requiere el modelo de recuperación completa de SQL Server.
Sobrecarga del rendimiento	Puede haber una reducción del rendimiento cuando se produce una conmutación por error.	La creación de reflejos con alta disponibilidad introduce latencia transaccional porque es sincrónica. También requiere memoria adicional y sobrecarga del procesador.
Carga operativa	Se configura y mantiene en el nivel del servidor.	La carga operativa es mayor que la de creación de clústeres. Se debe configurar y mantener para todas las bases de datos. La reconfiguración es manual después de una conmutación por error.

Estrategias de redundancia para aplicaciones de servicio

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

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 de Servicio de conectividad a datos empresariales

• Aplicación de Servicio de 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 Windows SharePoint Services 3,0 a SharePoint Foundation 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.

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

Redundancia y conmutación por error entre centros de datos próximos configurados como un conjunto de servidores único (conjunto de servidores "expandido")

Algunas empresas tienen centros de datos próximos con conexiones de ancho de banda alto que se pueden configurar como un solo conjunto de servidores. Esto se denomina un conjunto de servidores "expandido". Para que este tipo de conjunto 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, puede proporcionar tolerancia a errores siguiendo las instrucciones estándar para hacer que las bases de datos y las aplicaciones de servicio sean redundantes.

En la siguiente ilustración, se muestra un conjunto de servidores expandido.

Conjunto de servidores expandido