Planeación de la recuperación ante desastres (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 principales al elegir estrategias de recuperación ante desastres para un entorno de Microsoft SharePoint Server 2010.
En este artículo:
Información general sobre 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 Server deja de estar disponible.
La estrategia de recuperación ante desastres usada para SharePoint Server 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 un 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 Server, 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.
Suele ser 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 de servidores virtuales a granjas de servidores de recuperación ante desastres regionales y locales.
Ventajas: su recuperación es a menudo relativamente barata, ya que una granja 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.
Importante
Independientemente de la solución de recuperación ante desastres que se decida implementar para el entorno, es probable que se pierdan algunos datos.
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:
Restauración de una granja de servidores (SharePoint Server 2010)
Restauración de las personalizaciones (SharePoint Server 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 Server 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 una granja 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 ambas granjas de servidores.
Nota
Se recomienda que use una implementación con scripts para crear la granja de servidores principal y de conmutación por error con las mismas configuraciones y personalizaciones. Para obtener más información, vea Instalación de SharePoint Server 2010 mediante Windows PowerShell.
Las actualizaciones se deben aplicar en ambas granjas de servidores de forma individual.
Las bases de datos de contenido de SharePoint Server pueden reflejarse de forma asincrónica o trasvasar los registros correctamente a la granja de servidores de conmutación por error.
Nota
La creación de reflejo de SQL Server únicamente 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 un conjunto de servidores. Para obtener más información, vea Redundancia de aplicación de servicio en centros de datos posteriormente 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 a 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 granjas de servidores principales y de conmutación por error antes de la conmutación por error.
Granjas de servidores principales y de conmutación por error antes de la conmutación por error
.gif "Granjas 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 la granja 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 metadatos administrados
Bases de datos: servicio de metadatos administrados
Nota
Si el etiquetado está en uso, para usar correctamente la aplicación de servicio de metadatos administrados en la granja de servidores de recuperación ante desastres, debe ejecutar el motor de replicación de perfiles de usuario incluido en el SharePoint Administration Toolkit. Para más información, vea Introducción al motor de replicación de perfiles de usuario (SharePoint Server 2010).
PerformancePoint Services
Bases de datos: aplicación de servicio de PerformancePoint
Aplicación de servicio de Project Server
Bases de datos: borrador, publicada, archivos, informes
Project Server 2010 requiere la sincronización entre sus bases de datos. Project Server puede replicarse entre granjas de servidores mediante un mecanismo de replicación asincrónica (creación de reflejo de la base de datos asincrónica, trasvase de registros o replicación de SAN asincrónica), pero para la recuperación, debe asegurarse de que los registros de la base de datos de Project se sincronicen cuando restaura.
Nota
Aunque se recomienda que trasvase los registros o refleje las bases de datos de Project Server en la granja de servidores de recuperación ante desastres, no se puede ejecutar la aplicación de servicio de Project Server en bases de datos de solo lectura. Por lo tanto, recomendamos no ejecutar la aplicación de servicio de Project Server en la granja de servidores de recuperación ante desastres hasta después de la conmutación por error. Para sincronizar correctamente las bases de datos de Project Server en la granja de servidores de recuperación ante desastres, debe configurar marcas de tiempo o el marcado del registro para las bases de datos.
Aplicación de servicio de almacenamiento seguro
Bases de datos: almacenamiento seguro
Aplicación de servicio de recolección de datos de uso y estado
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.
Aplicación de servicio de Web Analytics
Bases de datos: provisional, informes
Nota
Se recomienda que trasvase los registros o refleje las bases de datos provisionales y de informes de Web Analytics. Sin embargo, se recomienda que no ejecute la aplicación de servicio de Web Analytics en la granja de servidores de recuperación ante desastres hasta después de la conmutación por error.
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 registro de aplicaciones
Bases de datos: servicio de registro de aplicaciones
No se admite el trasvase de registros de la base de datos de servicios 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 perfiles de usuario
Bases de datos: perfil, sincronización, etiquetas temáticas
Las bases de datos de perfil, sincronizacioón y etiquetado social no se pueden trasvasar.
Para proporcionar redundancia para la aplicación de servicios de perfiles de usuario, primero debe implementar la aplicación de servicio en los centros de datos principal y secundario.
Para configurar las bases de datos de perfil y sincronización, se recomienda que recupere una copia de seguridad de las bases de datos para el centro de datos secundario y las adjunte a la aplicación de servicio de perfiles de usuario de ese centro de datos.
Para mantener los perfiles sincronizados, debe ejecutar el motor de replicación de perfiles de usuario que se incluye en SharePoint Administration Toolkit después de actualizar los datos de perfil en la granja de servidores principal. Para obtener más información, vea Introducción al motor de replicación de perfiles de usuario (SharePoint Server 2010).
Aplicación de servicio de configuración de suscripción de Microsoft SharePoint Foundation
Base de datos: suscripción
Nota
No se admite el trasvase de registros de la base de datos de configuración de suscripción.
Servicios de Access
Bases de datos: ninguna
Servicios de Excel
Bases de datos: ninguna
Búsqueda
Bases de datos: rastreo, propiedades, administración de búsquedas
La búsqueda requiere la sincronización completa entre sus bases de datos y el índice. Debido a este requisito, la búsqueda no puede replicarse entre granjas de servidores mediante un mecanismo de replicación asincrónica (creación de reflejo de la base de datos asincrónica, trasvase de registros o replicación de SAN asincrónica).
Para proporcionar búsquedas actualizadas en una granja de servidores de conmutación por error, debe ejecutar la búsqueda en la granja de servidores secundaria.
Importante
La aplicación de servicio de búsqueda de la granja de servidores de conmutación por error se debe establecer para rastrear de forma activa la granja de servidores secundaria. En la conmutación por error, debe configurar la asociación de la aplicación web para que use la aplicación de servicio de búsqueda de conmutación por error.
Servicio de estado
Bases de datos: estado
Nota
No se admite el trasvase de registros de la base de datos de estado.
Servicios de Visio
Bases de datos: ninguna
Servicios de automatización de Word
Bases de datos: servicios de automatización de Word
No se admite el trasvase de registros de la base de datos de servicios de automatización de Word.
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.