Conceptos de alta disponibilidad y recuperación ante desastres en SharePoint Server

SE APLICA A:2013 2016 2019 Subscription Edition SharePoint en Microsoft 365

La alta disponibilidad y la recuperación ante desastres son las principales prioridades cuando se crea un plan y especificaciones del sistema para una granja de servidores de SharePoint Server. No se cumplen otros aspectos del plan, como alto rendimiento y capacidad, si los servidores de una granja no tienen una alta disponibilidad o si no se puede recuperar una granja.

Para diseñar e implementar una estrategia eficaz que permita mantener un funcionamiento eficiente y sin interrupciones, debe comprender los conceptos básicos de alta disponibilidad y recuperación ante desastres. Estos conceptos también son importantes para evaluar y elegir las soluciones técnicas más adecuadas para su entorno de SharePoint.

Introducción a la administración de la continuidad empresarial

La administración de la continuidad empresarial es un programa o proceso de administración que define, evalúa y ayuda a administrar los riesgos para el funcionamiento continuo de una organización. La administración de la continuidad empresarial se centra en la creación y el mantenimiento de un plan de continuidad empresarial, que consiste en una guía para lograr un funcionamiento continuo cuando las actividades habituales del negocio se ven interrumpidas por condiciones adversas. Estas condiciones pueden ser naturales, artificiales o una combinación de ambas. Los planes de continuidad se derivan de los siguientes análisis y entradas:

• Un análisis del impacto en el negocio

• Un análisis de las amenazas y los riesgos

• Una definición de los escenarios de impacto

• Un conjunto de requisitos de recuperación documentados

Se obtiene como resultado un diseño de solución u opciones identificadas, un plan de implementación, un plan de pruebas y de aceptación de la organización, y un plan o programa de mantenimiento.

Un ejemplo de administración de continuidad empresarial sería la recuperación ante desastres y la protección de datos y aplicaciones, que proporciona una instantánea del programa de continuidad empresarial de Microsoft.

La tecnología de la información (TI) es, desde luego, un aspecto central de la planeación de la continuidad empresarial para muchas organizaciones. Pero la continuidad empresarial es más global, ya que incluye todas las acciones necesarias para garantizar que una organización pueda continuar haciendo negocios durante un evento de interrupción importante o inmediatamente después de él. El plan de continuidad empresarial incluye, entre otros elementos:

• Directivas, procesos y procedimientos

• Opciones posibles y responsabilidad en la toma de decisiones

• Recursos humanos e instalaciones

• Tecnología de la información

Aunque la alta disponibilidad y la recuperación ante desastres a menudo se identifican con la administración de la continuidad empresarial, son en realidad subconjuntos de ella.

Descripción de la alta disponibilidad

Para un servicio o aplicación de software específico, la alta disponibilidad se mide en última instancia en función de las expectativas y la experiencia del usuario final. El impacto en el negocio tangible y percibido del tiempo de inactividad se puede expresar en términos de pérdida de información, daños a la propiedad, disminución de la productividad, costos de oportunidad, daños contractuales o pérdida de la buena fe.

El principal objetivo de una solución de alta disponibilidad es minimizar o mitigar el impacto del tiempo de inactividad. Una estrategia eficaz con este fin equilibra de manera óptima los procesos empresariales y los contratos de nivel de servicio (SLA) con las capacidades técnicas y los costos de infraestructura.

Se considera que una plataforma tiene una alta disponibilidad según el contrato, y las expectativas de los clientes y las partes interesadas. La disponibilidad de un sistema se puede expresar mediante este cálculo:

Tiempo activo real / tiempo activo esperado x 100%

El valor resultante se suele expresar en el sector en función de la cantidad de nueves que ofrece la solución. Se pretende expresar un número anual de minutos de tiempo activo posible o, por el contrario, de minutos de tiempo de inactividad.

Tiempo de inactividad previsto e imprevisto

Las interrupciones del sistema pueden ser previstas o planeadas, o el resultado de un error no planeado. No se tiene que considerar el tiempo de inactividad de manera negativa si este se administra correctamente. Existen dos tipos clave de tiempo de inactividad previsto:

• Mantenimiento planeado. Se anuncia previamente y se coordina una ventana de tiempo para las tareas de mantenimiento planeado, como revisiones de software, actualizaciones de hardware, actualizaciones de contraseñas, nuevas indizaciones sin conexión, cargas de datos o el ensayo de los procedimientos de recuperación ante desastres. Los procedimientos operativos intencionales y bien administrados deben minimizar el tiempo de inactividad y evitar la pérdida de datos. Las actividades de mantenimiento planeado pueden considerarse inversiones necesarias para evitar o mitigar otros escenarios de interrupciones no planeadas potencialmente más graves.

• Interrupción no planeada. Pueden surgir errores de nivel del sistema, de infraestructura o de procesos que no sean planeados o controlables, o que sean imprevistos, pero que su aparición sea muy poco probable o su impacto se considere aceptable. Una solución de alta disponibilidad eficaz detecta estos tipos de errores, se recupera automáticamente de la interrupción y luego reestablece la tolerancia a errores.

Al establecer SLA para alta disponibilidad, debe calcular indicadores clave de rendimiento (KPI) independientes para las actividades de mantenimiento planeado y el tiempo de inactividad imprevisto. Este enfoque permite comparar la inversión realizada en las actividades de mantenimiento planeado con la ventaja que implica evitar un tiempo de inactividad imprevisto.

Disponibilidad degradada

La alta disponibilidad no se debe tratar como una propuesta de tipo "todo o nada". Como alternativa a una interrupción total, suele ser aceptable para el usuario final que un sistema tenga una disponibilidad parcial, una funcionalidad limitada o un rendimiento degradado. Entre estos diferentes grados de disponibilidad, se incluyen:

• Operaciones diferidas y de solo lectura. Durante una ventana de mantenimiento o una recuperación ante desastres por fases, se puede llevar a cabo la recuperación de datos, pero es posible que se pongan en cola o se detengan temporalmente los nuevos flujos de trabajo y el procesamiento en segundo plano.

• Latencia de datos y capacidad de respuesta de las aplicaciones. Debido a una carga de trabajo intensa, un trabajo de procesamiento pendiente o un error parcial en una plataforma, los recursos de hardware limitados pueden verse comprometidos de manera excesiva o tener un tamaño deficiente. Es posible que la experiencia del usuario se vea afectada, pero el trabajo posiblemente se complete de todos modos, con una productividad reducida.

• Errores parciales, transitorios o inminentes. Solidez en la lógica de aplicaciones o pila de hardware que reintenta la acción o se corrige automáticamente tras detectar un error. El usuario final puede experimentar estos tipos de problemas como una latencia de datos o una capacidad de respuesta deficiente de las aplicaciones.

• Error parcial de un extremo a otro. Las interrupciones planeadas o no planeadas se pueden producir de manera estable en las capas verticales de la pila de solución (infraestructura, plataforma y aplicación), o bien de manera horizontal entre diferentes componentes funcionales. Los usuarios pueden experimentar un resultado correcto o una degradación parciales, según las características o los componentes afectados.

Se debe considerar la aceptabilidad de estos escenarios no ideales como parte de un espectro de disponibilidad degradada que puede generar hasta una interrupción total, y como pasos intermedios en una recuperación ante desastres por fases.

Cuantificación del tiempo de inactividad

Cuando se genera tiempo de inactividad, ya sea previsto o imprevisto, el principal objetivo de la empresa es reanudar el funcionamiento del sistema y minimizar la pérdida de datos. Cada minuto de tiempo de inactividad conlleva costos directos e indirectos. Con el tiempo de inactividad imprevisto, debe equilibrar el tiempo y el esfuerzo necesarios para determinar por qué se produjo la interrupción, cuál es el estado actual del sistema y qué pasos se deben realizar para recuperarse de la interrupción.

En un momento predeterminado en cualquier interrupción, debe fomentar o tomar la decisión empresarial de dejar de investigar la interrupción o de realizar tareas de mantenimiento, recuperarse de la interrupción mediante la reanudación del funcionamiento del sistema y, si es necesario, restablecer la tolerancia a errores.

Objetivos de recuperación

La redundancia de datos es un componente clave de una solución de base de datos de alta disponibilidad. La actividad de transacciones de la instancia principal de SQL Server se aplica de manera sincrónica o asincrónica a una o varias instancias secundarias. Cuando se produce una interrupción, las transacciones en desplazamiento se pueden revertir o se pueden perder en las instancias secundarias debido a retrasos en la propagación de datos.

Puede medir el impacto y definir los objetivos de recuperación en función de cuánto se tardará en reanudar el negocio y cuánta latencia de tiempo existe en la última transacción recuperada:

• Objetivo de tiempo de recuperación (RTO). Es la duración de la interrupción. El objetivo inicial es reanudar el funcionamiento del sistema con capacidad de solo lectura como mínimo para poder investigar el error. Sin embargo, el principal objetivo es restaurar el servicio completo hasta el punto en que se puedan realizar nuevas transacciones.

• Objetivo de punto de recuperación (RPO). Por lo general, se conoce como una medida de pérdida de datos aceptable. Es el intervalo o la latencia de tiempo entre la última transacción de datos confirmada antes del error y los datos más recientes recuperados después del error. La pérdida real de datos puede variar en función de la carga de trabajo del sistema en el momento del error, el tipo de error y el tipo de solución de alta disponibilidad en uso.

  Nota:

  Un objetivo relacionado es el objetivo de nivel de recuperación (RLO). Este objetivo define la granularidad con la que debe poder recuperar los datos, es decir, si podrá recuperar toda la granja de servidores, aplicación web, colección de sitios, sitio, lista o biblioteca, o elemento. Para más información, vea Planear copias de seguridad y recuperación en SharePoint Server.

Debe usar los valores de RTO y RPO como objetivos que indican la tolerancia de la empresa respecto del tiempo de inactividad y la pérdida de datos aceptable, y como métricas para supervisar el estado de disponibilidad.

Justificación de la rentabilidad de la inversión o el costo de oportunidad

Los costos empresariales del tiempo de inactividad pueden ser financieros o se pueden expresar como buena fe del cliente. Estos costos pueden acumularse con el tiempo o incurrirse en un momento específico de la ventana de interrupción. Además de proyectar el costo de una interrupción con un punto de recuperación de datos y tiempo de recuperación determinado, también puede calcular las inversiones en infraestructura y procesos empresariales que se necesitan para alcanzar los valores de RTO y RPO, o para evitar la interrupción por completo. Estos temas relacionados con la inversión deben tratar:

• Cómo evitar el tiempo de inactividad. Los costos de la recuperación de una interrupción se pueden evitar en su totalidad si no se produce ninguna interrupción. Las inversiones incluyen el costo de infraestructura o hardware redundante y con tolerancia a errores, la distribución de cargas de trabajo en puntos de error aislados y el tiempo de inactividad previsto para el mantenimiento preventivo.

• Cómo automatizar la recuperación. Si se produce un error del sistema, puede mitigar considerablemente el impacto del tiempo de inactividad en la experiencia del cliente por medio de una recuperación automática y transparente.

• Uso de recursos. Una infraestructura secundaria o en espera puede permanecer inactiva, a la espera de una interrupción. También se puede usar para las cargas de trabajo de solo lectura o para mejorar el rendimiento general del sistema mediante la distribución de las cargas de trabajo en todo el hardware disponible.

Para determinados RTO y RPO, las inversiones en recuperación y disponibilidad necesarias, junto con los costos proyectados de tiempo de inactividad, se pueden expresar y justificar como una función del tiempo. Durante una interrupción real, esto permite tomar decisiones relacionadas con costos en función del tiempo de inactividad que ha transcurrido.

Supervisión del estado de disponibilidad

Desde un punto de vista operativo, durante una interrupción real, no debe tratar de considerar todas las variables pertinentes ni calcular la rentabilidad de la inversión o los costos de oportunidad en tiempo real. En su lugar, debe supervisar la latencia de datos en las instancias en espera como un proxy para el RPO previsto.

En caso de que se produzca una interrupción, también debe limitar el tiempo inicial dedicado a investigar la causa raíz durante la interrupción y debe, en cambio, enfocarse en validar el estado del entorno de recuperación, y luego usar los registros detallados del sistema y las copias secundarias de datos para un análisis forense posterior.

Planeación de la recuperación ante desastres

Mientras los esfuerzos de alta disponibilidad implican las tareas que realiza para evitar una interrupción, los esfuerzos de recuperación ante desastres tratan las acciones realizadas para restablecer una alta disponibilidad tras la interrupción.

En el mayor grado posible, los procedimientos y las responsabilidades de recuperación ante desastres se deben formular antes de que se produzca una interrupción real. Según la supervisión y alertas activas, la decisión de iniciar un plan de conmutación por error y recuperación automático o manual se debe basar en los umbrales preestablecidos de RTO y RPO. El alcance de un plan eficaz de recuperación ante desastres debe incluir lo siguiente:

• Granularidad de error y recuperación. De acuerdo con la ubicación y el tipo de error, puede tomar medidas correctivas en niveles diferentes, es decir, centro de datos, infraestructura, plataforma, aplicación o carga de trabajo.

• Materiales de origen de investigación. El historial de supervisión reciente y de línea base, las alertas del sistema, los registros de eventos y las consultas de diagnóstico deben estar disponibles para las partes pertinentes.

• Coordinación de dependencias. Dentro de la pila de aplicación y entre los participantes, ¿cuáles son las dependencias del sistema y de la empresa?

• Árbol de decisión. Un árbol de decisión predeterminado, repetible y validado que incluye responsabilidades de roles, evaluación de errores, criterios de conmutación por error en función de los valores de RPO y RTO, y pasos de recuperación recomendados.

• Validación. Tras llevar a cabo los pasos para recuperarse de una interrupción, ¿qué se debe hacer para comprobar que el sistema reanudó su funcionamiento normal?

• Documentación. Recopile todos los elementos anteriores en un conjunto de documentación, con detalles y aclaraciones para que un equipo externo pueda llevar a cabo el plan de recuperación con una asistencia mínima. Por lo general, este tipo de documentación funciona como un manual de operaciones o procesos de TI.

• Ensayos de recuperación. Ensaye el plan de recuperación ante desastres periódicamente para establecer las expectativas de línea base para los valores de RTO, y considere rotar el sitio de producción primario con frecuencia entre el sitio primario y cada uno de los sitios de recuperación ante desastres.

Vea también

Conceptos

Seleccionar una estrategia de recuperación ante desastres para SharePoint Server

Otros recursos

¿Qué cargas de trabajo puede proteger con Azure Site Recovery?

Replicar una aplicación de SharePoint de niveles múltiples para una recuperación ante desastres mediante Azure Site Recovery