Planeación para la recuperación ante desastres (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 principales al elegir estrategias de recuperación ante desastres para un entorno de Microsoft SharePoint Foundation 2010.

En este artículo:

• Introducción a la recuperación ante desastres

• Elección de una estrategia de recuperación ante desastres

• Planeación de centros de datos de estado de espera pasiva

• Planeación de centros de datos de estado de espera semiactiva

• Planeación de centros de datos de estado de espera activa

• Requisitos del sistema para la recuperación ante desastres

Información general sobre recuperación ante desastres

Para los propósitos de este artículo, se define la recuperación ante desastres como la capacidad de recuperarse de una situación en la que un centro de datos que hospeda a SharePoint Foundation deja de estar disponible.

La estrategia de recuperación ante desastres usada para SharePoint Foundation debe coordinarse con la estrategia de recuperación ante desastres usada para la infraestructura relacionada, incluidos los dominios de Active Directory, Exchange Server y Microsoft SQL Server. Trabaje junto con los administradores de la infraestructura en la que se basa para diseñar un plan y una estrategia de recuperación ante desastres coordinados.

Al tiempo y al esfuerzo inmediato necesarios para poner en funcionamiento una granja o conjunto de servidores en una ubicación distinta se hace referencia como estado de espera activa, estado de espera semiactiva o estado de espera pasiva. Las definiciones de estos términos son las siguientes:

Estado de espera activa Un centro de datos secundario que puede proporcionar disponibilidad en segundos o minutos.

Estado de espera semiactiva Un centro de datos secundario que puede proporcionar disponibilidad en minutos u horas.

Estado de espera pasiva Un centro de datos secundario que puede proporcionar disponibilidad en horas o días.

La recuperación ante desastres puede ser uno de los requisitos más caros para un sistema. Cuanto más corto sea el intervalo entre el error y la disponibilidad y cuantos más sistemas se protejan, más costosa y compleja será una solución de recuperación ante desastres. Al invertir en centros de datos de estado de espera activa o semiactiva, entre los costos se incluye:

• Hardware y software adicionales, que a menudo incrementan la complejidad de las operaciones entre las aplicaciones de software, como scripts personalizados para la recuperación y la conmutación por error.

• Complejidad operativa adicional.

Los costos del mantenimiento de centros de datos de estado de espera activa o semiactiva deben evaluarse en función de las necesidades de negocio. Probablemente no todas las soluciones de una organización requieran el mismo nivel de disponibilidad después de un desastre. Pueden ofrecerse diferentes niveles de recuperación ante desastres para conjuntos de servidores, servicios o contenido distintos (por ejemplo, contenido de gran impacto en el negocio, servicios de búsqueda o un conjunto de servidores de publicación en Internet).

La recuperación ante desastres es un área clave en la que los grupos de tecnología de la información (TI) ofrecen contratos de nivel de servicio para establecer las expectativas con los grupos de clientes. Una gran cantidad de organizaciones de TI ofrecen diversos contratos de nivel de servicio asociados con distintos niveles de facturación.

Al implementar la conmutación por error entre conjuntos de servidores, se recomienda en primer lugar implementar la solución principal y ajustarla dentro de un conjunto de servidores y, posteriormente, implementar la recuperación ante desastres y probarla.

Elección de una estrategia de recuperación ante desastres

Se puede elegir entre varios enfoques para proporcionar recuperación ante desastres para un entorno de SharePoint Foundation, en función de las necesidades de negocio. En los siguientes ejemplos se muestra por qué las compañías podrían optar por estrategias de recuperación ante desastres de estado de espera activa, de estado de espera semiactiva o de estado de espera pasiva.

• Estrategia de recuperación ante desastres de estado de espera pasiva: una empresa envía copias de seguridad que permitan la recuperación completa a un almacenamiento externo local o regional de forma periódica, y cuenta con contratos para el alquiler de servidores de emergencia en otra región.

  Ventajas:

  • Desde un punto de vista operativo, es a menudo la opción más barata en cuanto al mantenimiento.

  • Es a menudo una opción costosa en cuanto a la recuperación, ya que es necesario que los servidores físicos se configuren correctamente después de un desastre.

  Inconvenientes: es la opción más lenta en cuanto a la recuperación.

• Estrategia de recuperación ante desastres de estado de espera semiactiva: una empresa envía imágenes virtuales de los servidores a conjuntos de servidores de recuperación ante desastres regionales y locales.

  Ventajas: su recuperación es a menudo relativamente barata, ya que un conjunto de servidores virtuales no necesita demasiada configuración después de la recuperación.

  Inconvenientes: su mantenimiento puede ser muy costoso y consumir demasiado tiempo.

• Estrategia de recuperación ante desastres de estado de espera activa: una empresa dispone de varios centros de datos, pero sirve contenido y servicios a través de uno solo de ellos.

  Ventajas: su recuperación es a menudo relativamente rápida.

  Inconvenientes: su mantenimiento y configuración pueden ser bastante costosos.

Planeación de centros de datos de estado de espera pasiva

En un escenario de recuperación ante desastres de estado de espera pasiva, la recuperación puede realizarse mediante la instalación de un nuevo conjunto de servidores en una nueva ubicación (preferentemente mediante una implementación generada por script) y la restauración de las copias de seguridad. O bien, se puede realizar mediante la restauración de un conjunto de servidores desde una solución de copia de seguridad como Microsoft System Center Data Protection Manager 2007 que protege los datos en el nivel de equipo y permite restaurar cada servidor de forma individual. En este artículo no se incluyen instrucciones detalladas para la creación y recuperación en escenarios de estado de espera pasiva. Para obtener más información, vea:

• Restaurar una granja de servidores (SharePoint Foundation 2010)

• Restauración de las personalizaciones (SharePoint Foundation 2010)

Planeación de centros de datos de estado de espera semiactiva

En un escenario de recuperación ante desastres de estado de espera semiactiva, para crear una solución de estado de espera semiactiva, debe asegurarse de crear frecuente y coherentemente imágenes virtuales de los servidores del conjunto de servidores que se envían a una ubicación secundaria. En esta ubicación secundaria, se debe contar con un entorno disponible en el que se puedan configurar y conectar fácilmente las imágenes para volver a crear el entorno del conjunto de servidores.

En este artículo no se incluyen instrucciones detalladas para crear soluciones de estado de espera semiactiva. Para obtener más información acerca de cómo planear la implementación de conjuntos de servidores mediante soluciones virtuales, vea Planeación de virtualización (SharePoint Foundation 2010).

Planeación de centros de datos de estado de espera activa

En un escenario de recuperación ante desastres de estado de espera activa, puede configurar un conjunto de servidores de conmutación por error para proporcionar recuperación ante desastres en un centro de datos independiente del conjunto de servidores principal. Un entorno que cuenta con un conjunto de servidores de conmutación por error independiente tiene las siguientes características:

• En en conjunto de servidores de conmutación por error debe mantenerse una base de datos de configuración independiente y una base de datos de contenido de Administración central.

• Todas las personalizaciones se deben implementar en ambos conjuntos de servidores.

  Nota

  Se recomienda usar una implementación generada por script para crear la granja de servidores principal y la de conmutación por error mediante el uso de la misma configuración y personalizaciones.

• Las actualizaciones se deben aplicar en ambos conjuntos de servidores de forma individual.

• Las bases de datos de contenido de SharePoint Foundation pueden reflejarse de forma asincrónica o trasvasar los registros correctamente en el conjunto de servidores de conmutación por error.

  Nota

  La creación de reflejo de SQL Server solo puede usarse para copiar bases de datos en un solo servidor reflejado, pero los registros se pueden trasvasar a varios servidores secundarios.

• Las aplicaciones de servicio varían en función de si sus registros pueden trasvasarse a una granja de servidores. Para obtener más información, vea Redundancia de aplicación de servicio en centros de datos más adelante en este artículo.

Esta topología se puede repetir en muchos centros de datos si se configura el trasvase de registros de SQL Server en uno o varios centros de datos adicionales.

Póngase en contacto con su proveedor de SAN para determinar si puede usar la réplica de SAN u otro mecanismo compatible para proporcionar disponibilidad en los centros de datos.

En la siguiente ilustración se muestran conjuntos de servidores principales y de conmutación por error antes de la conmutación por error.

Conjuntos de servidores principales y de conmutación por error antes de la conmutación por error

Redundancia de aplicación de servicio en centros de datos

Para proporcionar disponibilidad en centros de datos para aplicaciones de servicio, se recomienda que para los servicios que pueden ejecutarse entre conjuntos de servidores se ejecute un conjunto de servidores de servicios independiente al que se pueda obtener acceso desde los centros de datos principales y secundarios.

Para los servicios que no pueden ejecutarse entre conjuntos de servidores y para proporcionar disponibilidad para el conjunto de servidores de servicios mismo, la estrategia para proporcionar redundancia en centros de datos para una aplicación de servicio varía. La estrategia empleada dependerá de si:

• Existe un valor comercial en la ejecución de la aplicación de servicio en el conjunto de servidores de recuperación ante desastres cuando no está en uso.

• Las bases de datos asociadas con la aplicación de servicio pueden trasvasar los registros o reflejarse de forma asincrónica.

• La aplicación de servicio puede ejecutarse en bases de datos de solo lectura.

En las siguientes secciones se describen las estrategias de recuperación ante desastres recomendadas para cada aplicación de servicio. Las aplicaciones de servicio se agrupan por estrategia.

Bases de datos que pueden trasvasar los registros o reflejarse de forma asincrónica.

Una vez implementada inicialmente una aplicación de servicio en un conjunto de servidores secundario, las bases de datos que admiten las siguientes aplicaciones de servicio pueden reflejarse de forma asincrónica o trasvasar los registros entre conjuntos de servidores:

• Aplicación de Servicio de registro de aplicaciones

  Bases de datos: Servicio de registro de aplicaciones

• Aplicación de Servicio de conectividad a datos empresariales

  Bases de datos: conectividad a datos empresariales

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

  Bases de datos: registro

  Nota

  Es posible trasvasar los registros de la base de datos de registro o reflejarla. Sin embargo, se recomienda no ejecutar el servicio de recolección de datos de uso y estado en el conjunto de servidores de recuperación ante desastres y no reflejar la base de datos de registro ni trasvasar sus registros.

Bases de datos y aplicaciones de servicio que no pueden reflejarse de forma asincrónica ni trasvasar los registros

Las siguientes aplicaciones de servicio deben implementarse en los conjuntos de servidores principales y de conmutación por error, y no pueden reflejarse de forma asincrónica ni trasvasar los registros. Para la mayoría de estas aplicaciones de servicio, se recomienda implementarlas y, a continuación, comprobar que el conjunto de servidores de conmutación por error tenga los mismos valores de configuración que el conjunto de servidores principal. Si se realizan cambios de configuración que afectan al servicio en el conjunto de servidores principal, se deberá actualizar el conjunto de servidores de conmutación por error.

• Aplicación de servicio de configuración de suscripción de Microsoft SharePoint Foundation

  Base de datos: configuración de la suscripción

  Nota

  No se admite el trasvase de registros de la base de datos de configuración de suscripción.

Requisitos del sistema para la recuperación ante desastres

En un escenario ideal, los sistemas y los componentes de conmutación por error coinciden con los sistemas y los componentes principales en todos los aspectos: plataforma, hardware y cantidad de servidores. Como mínimo, el entorno de conmutación por error debe poder controlar el tráfico previsto durante una conmutación por error. Tenga en cuenta que es posible que el sitio de conmutación por error sólo pueda atender un subconjunto de usuarios. Los sistemas deben coincidir como mínimo en lo siguiente:

• Versión del sistema operativo y todas las actualizaciones

• Versiones de SQL Server y todas las actualizaciones

• Versiones de Productos de SharePoint 2010 y todas las actualizaciones

Aunque en este artículo se describe principalmente la disponibilidad de Productos de SharePoint 2010, el tiempo de actividad del sistema también se verá afectado por el resto de los componentes del sistema. En particular, asegúrese de realizar lo siguiente:

• Asegúrese de que las dependencias de infraestructura como la electricidad, la refrigeración, la red, el directorio y SMTP sean totalmente redundantes.

• Elija un mecanismo de conmutación, ya sea DNS o equilibrio de carga del hardware, que se ajuste a sus necesidades.