Seleccionar una estrategia de recuperación ante desastres para SharePoint Server
SE APLICA A:
2013 2016 2019 Subscription Edition 
SharePoint en Microsoft 365
Definimos la recuperación ante desastres como la capacidad para recuperarse de una situación en la que el centro de datos principal que hospeda una granja de servidores de SharePoint Server no es capaz de seguir funcionando. Independientemente de la naturaleza del evento y de su causa, la interrupción del centro de datos es lo suficientemente significativa para poner en marcha las acciones definidas en el plan de recuperación ante desastres de su organización. Esto significa poner una granja de servidores totalmente operativa en producción usando los recursos de equipo ubicados en un centro de datos que no está afectado por el evento.
SharePoint Servers 2019, 2016, 2013 y los servidores SQL Server que los admiten proporcionan opciones de configuración y recuperación de contenido que pueden cumplir el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) necesarios para su empresa si se produce un desastre. Para obtener más información sobre estos y otros conceptos de recuperación ante desastres, vea Conceptos de alta disponibilidad y recuperación ante desastres en SharePoint Server.
Introducción
Una estrategia eficaz de recuperación ante desastres para una granja de servidores de SharePoint Server debe ser suficiente para cumplir los requisitos empresariales de su organización, que normalmente se expresan con dos medidas: Objetivo de tiempo de recuperación (RTO) y Objetivo de punto de recuperación (RPO). Los requisitos de RTO y RPO se calculan determinando el costo del tiempo de inactividad para la organización en caso de desastre.
Importante
El procedimiento que recomendamos es identificar y cuantificar de forma clara los valores de RTO y RPO para su organización antes de desarrollar una estrategia de recuperación y de implementar una solución técnica. Céntrese en lo que necesita, no en cómo hacerlo.
Los costos por tiempo de inactividad varían significativamente de una industria a otra, y dentro de cada industria, especialmente por los diferentes efectos del tiempo de inactividad. El tamaño de la empresa es el factor más obvio. Sin embargo, no es el único. Definir una medida significa establecer la naturaleza y las implicaciones del error. Reducido al nivel más simple, un error de una aplicación crítica podría producir los siguientes tipos de pérdidas:
Pérdida del servicio de la aplicación. El efecto del tiempo de inactividad varía según la aplicación y el negocio.
Pérdida de datos. La posible pérdida de datos debida a una interrupción del sistema puede tener importantes repercusiones legales y financieras.
En la mayoría de las organizaciones, ambos tipos de pérdidas provocarán costos por tiempo de inactividad, pero la naturaleza del negocio determinará qué tipo de pérdida tendrá un efecto mayor. En el artículo siguiente, escrito por Chris Preimesberger de eWEEK, destaca el efecto sobre las finanzas del tiempo de inactividad de los centros de datos. El tiempo de inactividad de TI no planeado puede llegar a costar 5000 dólares por minuto: informe.
En la mayoría de los casos, Productos de SharePoint es una de las diversas aplicaciones que deben recuperarse en caso de una interrupción del centro de datos clasificada como desastre. Por este motivo, no hemos incluido información sobre el planeamiento de la recuperación ante desastres, sino que nos centramos en las opciones para asegurarse de que puede recuperar la granja de servidores de SharePoint Server en otra ubicación.
Independientemente del tipo y la magnitud de un desastre, la recuperación implica el uso de un centro de datos en espera en el que se pueda recuperar la granja de servidores.
Opciones de recuperación del centro de datos en espera
Se necesitan centros de datos en espera para aquellos casos en los que los sistemas redundantes locales y las copias de seguridad no se puedan recuperar después de la interrupción del centro de datos principal. El tiempo y el esfuerzo inmediato para poner en marcha una granja de servidores de sustitución en una ubicación diferente suele denominarse espera activa, semiactiva o pasiva. Nuestras definiciones para estos centros de datos de recuperación de granjas de servidores son los siguientes:
Espera pasiva. Un centro de datos secundario que puede proporcionar disponibilidad en horas o días.
Espera semiactiva. Un centro de datos secundario que puede proporcionar disponibilidad en minutos u horas.
Espera activa. Un centro de datos secundario que puede proporcionar disponibilidad en segundos o minutos.
Cada uno de estos centros de datos en espera tiene características y requisitos específicos, y también un costo asociado de funcionamiento y mantenimiento.
Estrategia de recuperación ante desastres con espera pasiva: una empresa envía regularmente copias de seguridad para una reconstrucción completa a almacenamientos externos locales y regionales, y tiene contratos para el alquiler de servidores de emergencia en otra región.
Pros: Suele ser la opción más económica de mantener en términos operativos. La recuperación con esta opción suele ser costosa porque es necesario configurar correctamente los servidores físicos después de que se produzca un desastre.
Contras: es la opción más lenta de recuperar.
Estrategia de recuperación ante desastres con estado de espera semiactiva con Azure Site Recovery.
Pros: La recuperación suele ser muy económica porque una granja de servidores virtual necesita poca configuración en el momento de la recuperación.
Cons: Su mantenimiento puede ser muy costoso, tanto en términos monetarios como de tiempo.
Estrategia de recuperación ante desastres con estado de espera activa: una empresa tiene varios centros de datos, pero solo sirve contenido y servicios a través de un centro de datos.
Pros: La recuperación suele ser muy rápida.
Cons: Puede ser muy costosa de configurar y mantener.
Importante
Independientemente de cuál de las soluciones de recuperación ante desastres anteriores decida aplicar, es probable que produzca alguna pérdida de datos.
Recuperación con espera pasiva
En un escenario de recuperación ante desastres en espera en frío, se recupera configurando una nueva granja de servidores en una nueva ubicación (preferiblemente mediante una implementación con scripts) y restaurando copias de seguridad. O bien, puede recuperar mediante la restauración de la granja de servidores mediante una solución de copia de seguridad como System Center - Data Protection Manager (DPM). DPM protege los datos en el nivel del sistema operativo del equipo y le permite restaurar cada servidor individualmente. Este artículo no contiene instrucciones detalladas sobre cómo crear y recuperar en escenarios con espera pasiva. Para obtener más información, vea:
Información general sobre la copia de seguridad y recuperación en SharePoint Server
Planear copias de seguridad y recuperación en SharePoint Server
Recuperación con espera semiactiva
En un escenario de recuperación ante desastres con espera semiactiva, el entorno de espera semiactiva se crea con una granja de servidores duplicada en el centro de datos alternativo, y se asegura la actualización regular mediante copias de seguridad completas e incrementales de la granja de servidores principal.
Entornos virtuales de espera semiactiva
La virtualización es una opción viable y económica para una solución de recuperación en espera semiactiva. Puede usar Hyper-V como solución local o Azure como solución hospedada para proporcionar la infraestructura necesaria para recuperación. Para obtener más información, vea Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure (Implementación de SharePoint Server con grupos de disponibilidad AlwaysOn de SQL Server en Azure).
Recuperación con espera activa
En un escenario de recuperación ante desastres con espera activa, se configura una granja de servidores de conmutación por error en el centro de datos de espera para que pueda asumir las operaciones de producción casi inmediatamente después de que la granja de servidores principal se quede sin conexión. Un entorno que cuenta con una granja de servidores de conmutación por error independiente tiene las siguientes características:
En la granja de servidores de conmutación por error deben mantenerse una base de datos de configuración y una base de contenido de el sitio web de Administración central de SharePointindependientes.
Todas las personalizaciones deben implementarse en ambas granjas de servidores.
Sugerencia
Ambas granjas de servidores son coherentes y, para reducir la posibilidad de errores, le recomendamos usar una implementación con scripts para crear las granjas de servidores principal y de conmutación por error, con las mismas personalizaciones y opciones de configuración.
Es necesario aplicar las actualizaciones del sistema operativo y del software de SQL Server y SharePoint Server en las dos granjas de servidores para que la configuración sea coherente en ambas.
Puede copiar las bases de datos de contenido de SharePoint Server a la granja de servidores de conmutación por error con la creación de reflejo asincrónica, con la confirmación asincrónica en una réplica de grupo de disponibilidad o con un trasvase de registros.
Nota:
La creación de reflejos de SQL Server solo se puede usar para copiar bases de datos en un único servidor reflejo, pero puede realizar el trasvase de registros a varios servidores secundarios.
La característica de creación de reflejo de la base de datos de SQL Server se quitará en versiones futuras. Se recomienda evitar el uso de esta característica en nuevas implementaciones. Planee cambiar las aplicaciones que actualmente usan esta característica. En su lugar, use grupos de disponibilidad AlwaysOn.
Las aplicaciones de servicio varían en cuanto a si pueden realizar el trasvase de registros a una granja de servidores. Para más información, vea Redundancia de las aplicaciones de servicio más adelante en este artículo.
La topología de granja de servidores de espera activa se puede repetir en más de un centro de datos, siempre que configure el trasvase de registros de SQL Server a uno o varios centros de datos adicionales.
Importante
La latencia y el ancho de banda de red disponible son consideraciones importantes al usar un método de conmutación por error para la recuperación ante desastres. Se recomienda consultar con el proveedor de SAN para determinar si puede usar la replicación SAN para bases de datos SQL u otro mecanismo compatible para proporcionar el nivel de disponibilidad en espera activa entre centros de datos. Tenga en cuenta que no se admite el uso de la replicación san para servidores de SharePoint.
Redundancia de las aplicaciones de servicio
Para proporcionar disponibilidad para las aplicaciones de servicio entre los centros de datos, le recomendamos que para los servicios que se puedan ejecutar entre granjas, ejecute una granja de servidores de servicio diferente a la que se pueda acceder tanto desde el centro de datos principal como desde el secundario.
Para los servicios que no se puedan ejecutar entre granjas, y para proporcionar disponibilidad para la propia granja de servidores de servicios, la estrategia para proporcionar redundancia entre los centros de datos para un aplicación de servicio varía. La estrategia a emplear depende de si:
Ejecutar la aplicación de servicio en la granja de servidores de recuperación ante desastres cuando no se está usando aporta algún valor desde el punto de vista empresarial.
Se puede realizar el trasvase de registros de las bases de datos asociadas con la aplicación de servicio, o si las bases de datos se pueden reflejar asincrónicamente o se pueden replicar mediante confirmación asincrónica.
La aplicación de servicio solo se puede ejecutar con bases de datos de solo lectura.
Vea el artículo Compatibilidad de alta disponibilidad y opciones de recuperación ante desastres para bases de datos de SharePoint antes de diseñar una solución de recuperación ante desastres que usa un centro de datos con espera semiactiva o activa.
Requisitos del sistema para la recuperación
En un escenario ideal, los componentes y sistemas de conmutación por error coincidirían con los componentes y sistemas principales en todos sus aspectos: plataforma, hardware y número de servidores. Como mínimo, el entorno de conmutación por error debe poder administrar el tráfico que espera durante una conmutación por error. Recuerde que puede que el sitio de conmutación por error solo tenga que atender a un subconjunto de los usuarios. Los sistemas deben coincidir al menos en lo siguiente:
Versión del sistema operativo y todas las actualizaciones
Versiones de SQL Server y todas las actualizaciones
Versiones de SharePoint Server y todas las actualizaciones
Además de los requisitos anteriores, el tiempo de recuperación de la granja de servidores también se verán afectado por la disponibilidad de instalaciones y componentes de la infraestructura. Asegúrese de que se cumplen los siguientes requisitos:
La alimentación, refrigeración, red, directorio y SMTP son completamente redundantes
Elija un mecanismo de conmutación, ya sea DNS o equilibrio de carga de hardware, que satisfaga sus necesidades.
Consulte también
Conceptos
Conceptos de alta disponibilidad y recuperación ante desastres en SharePoint Server
Otros recursos
¿Qué cargas de trabajo puede proteger con Azure Site Recovery?