Diseño para la copia de seguridad y la recuperación
Las organizaciones como Tailwind Traders requieren un alto grado de confiabilidad de sus aplicaciones críticas. Para lograr la confiabilidad deseada para las aplicaciones locales, es habitual comprar más recursos informáticos, como servidores y almacenamiento. La compra de más recursos informáticos crea redundancia en una infraestructura local.
También es fundamental que cualquier aplicación crítica y sus datos asociados se puedan recuperar después de un error. Esta capacidad de recuperación la suelen proporcionar las copias de seguridad, los componentes de restauración y los procedimientos. En el caso de las organizaciones con aplicaciones hospedadas en Azure u organizaciones con implementaciones de aplicaciones híbridas, hay otras consideraciones y opciones.
Las aplicaciones confiables son:
Resistentes a los errores de los componentes.
De alta disponibilidad y con la capacidad de ejecutarse en un estado correcto sin un tiempo de inactividad significativo.
Para lograr la resistencia y la alta disponibilidad deseadas, primero debe definir sus requisitos.
Nota:
En este módulo se usará el término resistencia como la capacidad de un sistema de controlar y recuperarse correctamente de los errores, tanto involuntarios como malintencionados.
Definición de los requisitos
La definición de los requisitos implica lo siguiente:
Identificar sus necesidades empresariales.
Crear un plan de resistencia para satisfacer esas necesidades.
Use la siguiente tabla de consideraciones como guía sobre este proceso.
| Consideración | Descripción |
|---|---|
| ¿Cuáles son sus cargas de trabajo y su utilización? | Una carga de trabajo es una funcionalidad o tarea independiente que está separada de forma lógica de otras tareas, en términos de requisitos de lógica de negocios y de almacenamiento de datos. Es probable que cada carga de trabajo tenga requisitos diferentes de disponibilidad, escalabilidad, coherencia de los datos y recuperación ante desastres. |
| ¿Cuáles son los patrones de uso de sus cargas de trabajo? | Los patrones de uso pueden determinar sus requisitos. Identifique las diferencias en los requisitos durante períodos críticos y no críticos. Para garantizar el tiempo de actividad, planifique la redundancia entre varias regiones en caso de que se produzca un error en una región. Por el contrario, para minimizar los costes durante períodos no críticos, puede ejecutar su aplicación en una sola región. |
| ¿Cuáles son las métricas de disponibilidad? | El tiempo medio de recuperación (MTTR) y el tiempo medio entre errores (MTBF) son las métricas usadas normalmente. MTBF es lo que razonablemente es previsible esperar que dure un componente entre dos interrupciones. MTTR es el tiempo medio necesario para restaurar un componente después de un error. Use estas métricas para determinar dónde debe agregar la redundancia y definir los acuerdos de nivel de servicio (SLA) para los clientes. |
| ¿Cuáles son las métricas de recuperación? | El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable que una de sus aplicaciones puede no estar disponible después de un incidente. El objetivo de punto de recuperación (RPO) es la duración máxima de la pérdida de datos que es aceptable durante un desastre. Tenga en cuenta también el objetivo de nivel de recuperación (RLO). Esta métrica determina la granularidad de la recuperación. En otras palabras, si debe poder recuperar una granja de servidores, una aplicación web, un sitio o simplemente un elemento específico. Para determinar estos valores, realice una evaluación de riesgos. Asegúrese de comprender el coste y el riesgo del tiempo de inactividad o la pérdida de datos en su organización. |
| ¿Cuáles son los objetivos de disponibilidad de la carga de trabajo? | Para ayudar a garantizar que la arquitectura de la aplicación cumple los requisitos empresariales, defina los SLA objetivo para cada carga de trabajo. Analice el costo y la complejidad que supone satisfacer los requisitos de disponibilidad además de las dependencias de la aplicación. |
| ¿Cuáles son sus SLA? | En Azure, el Acuerdo de Nivel de Servicio describe los compromisos de Microsoft en cuanto a tiempo de actividad y conectividad. Si el Acuerdo de Nivel de Servicio de un servicio determinado es del 99,9 %, significa que lo esperable es que el servicio esté disponible un 99,9 % del tiempo. |
Sugerencia
Si el MTTR de cualquier componente crítico en un escenario de alta disponibilidad supera el RTO del sistema, un error en el sistema podría provocar una interrupción del negocio inaceptable. En otras palabras, no se puede restaurar el sistema dentro del RTO definido.
Defina sus propios SLA objetivo para cada carga de trabajo de su solución respondiendo a las preguntas anteriores. Esto ayuda a garantizar que la arquitectura cumple sus requisitos empresariales. Por ejemplo, si una carga de trabajo requiere un tiempo de actividad del 99,99 %, pero depende de un servicio con un SLA del 99,9 %, ese servicio no puede ser un único punto de error en el sistema.
Después de definir los requisitos de recuperación, puede seleccionar una tecnología de recuperación adecuada.