Conceptos de alta disponibilidad y recuperación ante desastres en SharePoint ServerHigh availability and disaster recovery concepts in SharePoint Server

Resumen: obtenga información sobre los conceptos de alta disponibilidad y recuperación ante desastres de SharePoint Server 2016 y SharePoint 2013 para elegir la mejor estrategia para la granja de servidores.Summary: Understand high availability and disaster recovery concepts in SharePoint Server 2016 and SharePoint 2013 so you can choose the best strategy for your farm.

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.High availability and disaster recovery is the highest priority when you create a plan and system specifications for a SharePoint Server farm. Other aspects of the plan, such as high performance and capacity, are negated if farm servers are not highly available or a farm cannot be recovered.

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.To design and implement an effective strategy that maintains efficient and uninterrupted operations, you should understand the basic concepts of high availability and disaster recovery. These concepts are also important to evaluate and pick the best technical solutions for your SharePoint environment.

Introducción a la administración de la continuidad empresarialIntroduction to business continuity management

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:Business continuity management is a management process or program that defines, assesses, and helps manage the risks to the continued running of an organization. Business continuity management focuses on creating and maintaining a business continuity plan, which is a roadmap for continuing operations when normal business operations are interrupted by adverse conditions. These conditions can be natural, man-made, or a combination of both. A continuity plan is derived from the following analyses and inputs:

  • Un análisis del impacto en el negocioA business impact analysis

  • Un análisis de las amenazas y los riesgosA threat and risk analysis

  • Una definición de los escenarios de impactoA definition of the impact scenarios

  • Un conjunto de requisitos de recuperación documentadosA set of documented recovery requirements

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.The result is a solution design or identified options, an implementation plan, a testing and organization acceptance plan, and a maintenance plan or schedule.

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.An example of business continuity management is Disaster recovery and protection for data and applications, which provides a snapshot of the business continuity program at 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:Obviously Information Technology (IT) is a significant aspect of business continuity planning for many organizations. However, business continuity is more encompassing - it includes all the operations that are needed to make sure that an organization can continue to do business during and immediately after a major disruptive event. A business continuity plan includes, but is not limited to, the following elements:

  • Directivas, procesos y procedimientospolicies, processes and procedures

  • Opciones posibles y responsabilidad en la toma de decisionespossible options and decision-making responsibility

  • Recursos humanos e instalacioneshuman resources and facilities

  • Tecnología de la informacióninformation technology

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.Although high availability and disaster recovery are often equated to business continuity management; they are in fact, subsets of business continuity management.

Descripción de la alta disponibilidadDescribing high availability

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.For a given software application or service, high availability is ultimately measured in terms of the end user's experience and expectations. The tangible and perceived business impact of downtime may be expressed in terms of information loss, property damage, decreased productivity, opportunity costs, contractual damages, or the loss of goodwill.

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.The principal goal of a high availability solution is to minimize or mitigate the impact of downtime. A sound strategy for this optimally balances business processes and Service Level Agreements (SLAs) with technical capabilities and infrastructure costs.

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:A platform is considered highly available per the agreement and expectations of customers and stakeholders. The availability of a system can be expressed as this calculation:

Tiempo activo real / tiempo activo esperado x 100%Actual uptime/Expected uptime 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.The resulting value is often expressed by industry in terms of the number of 9's that the solution provides; meant to convey an annual number of minutes of possible uptime, or conversely, minutes of downtime.

Cantidad de nuevesNumber of 9's Porcentaje de disponibilidadAvailability Percentage Tiempo de inactividad anual totalTotal Annual Downtime
22
99%99%
3 días, 15 horas3 days, 15 hours
33
99,9%99.9%
8 horas, 45 minutos8 hours, 45 minutes
44
99,99%99.99%
52 minutos, 34 segundos52 minutes, 34 seconds
55
99,999%99.999%
5 minutos, 15 segundos5 minutes, 15 seconds

Tiempo de inactividad previsto e imprevistoPlanned versus unplanned downtime

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:System outages are either anticipated or planned for, or they are the result of an unplanned failure. Downtime need not be considered negatively if it is appropriately managed. There are two key types of foreseeable downtime:

  • 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.Planned maintenance. A time window is preannounced and coordinated for planned maintenance tasks such as software patching, hardware upgrades, password updates, offline re-indexing, data loading, or the rehearsal of disaster recovery procedures. Deliberate, well-managed operational procedures should minimize downtime and prevent any data loss. Planned maintenance activities can be seen as investments needed to prevent or mitigate other potentially more severe unplanned outage scenarios.

  • 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.Unplanned outage. System-level, infrastructure, or process failures may occur that are unplanned or uncontrollable, or that are foreseeable, but considered either too unlikely to occur, or are considered to have an acceptable impact. A robust high availability solution detects these types of failures, automatically recovers from the outage, and then reestablishes fault tolerance.

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.When establishing SLAs for high availability, you should calculate separate key performance indicators (KPIs) for planned maintenance activities and unplanned downtime. This approach allows you to contrast your investment in planned maintenance activities against the benefit of avoiding unplanned downtime.

Disponibilidad degradadaDegraded availability

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:High availability should not be considered as an all-or-nothing proposition. As an alternative to a complete outage, it is often acceptable to the end user for a system to be partially available, or to have limited functionality or degraded performance. These varying degrees of availability include:

  • 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.Read-only and deferred operations. During a maintenance window, or during a phased disaster recovery, data retrieval is still possible, but new workflows and background processing may be temporarily halted or queued.

  • 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.Data latency and application responsiveness. Due to a heavy workload, a processing backlog, or a partial platform failure, limited hardware resources may be over-committed or under-sized. User experience may suffer, but work may still get done in a less productive manner.

  • 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.Partial, transient, or impending failures. Robustness in the application logic or hardware stack that retries or self-corrects upon encountering an error. These types of issues may appear to the end user as data latency or poor application responsiveness.

  • 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.Partial end-to-end failure. Planned or unplanned outages may occur gracefully within vertical layers of the solution stack (infrastructure, platform, and application), or horizontally between different functional components. Users may experience partial success or degradation, depending upon the features or components that are affected.

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.The acceptability of these suboptimal scenarios should be considered as part of a spectrum of degraded availability leading up to a complete outage, and as intermediate steps in a phased disaster recovery.

Cuantificación del tiempo de inactividadQuantifying downtime

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.When downtime does occur, either planned, or unplanned, the primary business goal is to bring the system back online and minimize data loss. Every minute of downtime has direct and indirect costs. With unplanned downtime, you must balance the time and effort needed to determine why the outage occurred, what the current system state is, and what steps are needed to recover from the outage.

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.At a predetermined point in any outage, you should make or seek the business decision to stop investigating the outage or performing maintenance tasks, recover from the outage by bringing the system back online, and if needed, reestablish fault tolerance.

Objetivos de recuperaciónRecovery objectives

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.Data redundancy is a key component of a high availability database solution. Transactional activity on your primary SQL Server instance is synchronously or asynchronously applied to one or more secondary instances. When an outage occurs, transactions that were in flight may be rolled back, or they may be lost on the secondary instances due to delays in data propagation.

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:You can both measure the impact, and set recovery goals in terms of how long it takes to get back in business, and how much time latency there is in the last transaction recovered:

  • 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.Recovery Time Objective (RTO). This is the duration of the outage. The initial goal is to get the system back online in at least a read-only capacity to facilitate investigation of the failure. However, the primary goal is to restore full service to the point that new transactions can take place.

  • 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.Recovery Point Objective (RPO). This is often referred to as a measure of acceptable data loss. It is the time gap or latency between the last committed data transaction before the failure and the most recent data recovered after the failure. The actual data loss can vary depending upon the workload on the system at the time of the failure, the type of failure, and the type of high availability solution used.

    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.A related objective is Recovery level objective (RLO). This objective defines the granularity with which you must be able to recover data — whether you must be able to recover the whole farm, Web application, site collection, site, list or library, or item. For more information, see Plan for backup and recovery in 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.You should use RTO and RPO values as goals that indicate business tolerance for downtime and acceptable data loss, and as metrics for monitoring availability health.

Justificación de la rentabilidad de la inversión o el costo de oportunidadJustifying ROI or opportunity cost

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:The business costs of downtime may be either financial or in the form of customer goodwill. These costs may accrue with time, or they may be incurred at a certain point in the outage window. In addition to projecting the cost of incurring an outage with a given recovery time and data recovery point, you can also calculate the business process and infrastructure investments needed to attain your RTO and RPO goals or to avoid the outage all together. These investment themes should include:

  • 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.Avoiding downtime. Outage recovery costs are avoided all together if an outage doesn't occur in the first place. Investments include the cost of fault-tolerant and redundant hardware or infrastructure, distributing workloads across isolated points of failure, and planned downtime for preventive maintenance.

  • 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.Automating recovery. If a system failure occurs, you can greatly mitigate the impact of downtime on the customer experience through automatic and transparent recovery.

  • 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.Resource utilization. Secondary or standby infrastructure can sit idle, awaiting an outage. It also can be leveraged for read-only workloads, or to improve overall system performance by distributing workloads across all available hardware.

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.For given RTO and RPO goals, the needed availability and recovery investments, combined with the projected costs of downtime, can be expressed and justified as a function of time. During an actual outage, this allows you to make cost-based decisions based on the elapsed downtime.

Supervisión del estado de disponibilidadMonitoring availability health

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.From an operational point of view, during an actual outage, you should not attempt to consider all relevant variables and calculate ROI or opportunity costs in real time. Instead, you should monitor data latency on your standby instances as a proxy for expected RPO.

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.In the event of an outage, you should also limit the initial time spent investigating the root cause during the outage, and instead focus on validating the health of your recovery environment, and then rely upon detailed system logs and secondary copies of data for subsequent forensic analysis.

Planeación de la recuperación ante desastresPlanning for disaster recovery

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.While high availability efforts entail what you do to prevent an outage, disaster recovery efforts address what is done to re-establish high availability after the outage.

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:As much as possible, disaster recovery procedures and responsibilities should be formulated before an actual outage occurs. Based upon active monitoring and alerts, the decision to initiate an automated or manual failover and recovery plan should be tied to pre-established RTO and RPO thresholds. The scope of a sound disaster recovery plan should include:

  • 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.Granularity of failure and recovery. Depending upon the location and type of failure, you can take corrective action at different levels; that is, data center, infrastructure, platform, application, or workload.

  • 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.Investigative source material. Baseline and recent monitoring history, system alerts, event logs, and diagnostic queries should all be readily accessible by appropriate parties.

  • 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?Coordination of dependencies. Within the application stack, and across stakeholders, what are the system and business dependencies?

  • Á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.Decision tree. A predetermined, repeatable, validated decision tree that includes role responsibilities, fault triage, failover criteria in terms of RPO and RTO goals, and prescribed recovery steps.

  • 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?Validation. After taking steps to recover from the outage, what must be done to verify that the system has returned to normal operations?

  • 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.Documentation. Capture all of the above items in a set of documentation, with sufficient detail and clarity so that a third party team can execute the recovery plan with minimal assistance. This type of documentation is commonly called a 'run book' or a 'cook book'.

  • 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.Recovery rehearsals. Regularly exercise the disaster recovery plan to establish baseline expectations for RTO goals, and consider regular rotation of hosting the primary production site on the primary and each of the disaster recovery sites.

Consulte tambiénSee also

ConceptsConcepts

Seleccionar una estrategia de recuperación ante desastres para SharePoint ServerChoose a disaster recovery strategy for SharePoint Server