Alta Disponibilidad y Tolerancia a fallos

Alta Disponibilidad: Mantener un sistema funcionando incluso cuando ocurren problemas, minimizando el tiempo de inactividad y asegurando servicios continuos.

RTO (Tiempo de Recuperación Objetivo): El tiempo máximo deseado para que un sistema vuelva a funcionar después de una falla, reduciendo el impacto del tiempo de inactividad.
RPO (Punto de Recuperación Objetivo): La cantidad máxima de datos que una organización está dispuesta a perder en una interrupción, marcando cuán actualizados deben estar los datos recuperados.

Tolerancia a Fallos: La tolerancia a fallos es la capacidad de un sistema, aplicación o servicio para continuar funcionando de manera aceptable incluso cuando uno o varios componentes experimentan problemas o fallas. Implica diseñar sistemas de manera que sean capaces de manejar errores y problemas sin que todo el sistema se vea comprometido, lo que garantiza la disponibilidad y la continuidad de los servicios incluso en condiciones adversas.

José Pablo Cabrera Romo

Las estrategias de recuperación ante desastres, conocidas como Disaster Recovery (DR), son fundamentales para garantizar la continuidad de los negocios y la protección de los datos en situaciones de emergencia. Aquí tienes algunas estrategias comunes de Disaster Recovery:

Copias de seguridad regulares: Realizar copias de seguridad de los datos críticos y almacenarlas en ubicaciones seguras, ya sea en servidores locales o en la nube. Las copias de seguridad deben ser automáticas y se deben probar de forma periódica para asegurarse de que se pueden restaurar correctamente.
Replicación de datos: Configurar la replicación en tiempo real o cerca de tiempo real de los datos críticos en servidores o centros de datos secundarios. Esto garantiza que siempre haya una copia actualizada de los datos disponibles.
Centros de datos secundarios o fuera del sitio: Mantener un centro de datos secundario o un sitio de recuperación ante desastres en una ubicación geográfica diferente. Esto protege los datos y sistemas en caso de desastres naturales o incidentes locales.
Virtualización y contenedores: Utilizar tecnologías de virtualización y contenedores para permitir la rápida implementación de sistemas y aplicaciones en servidores alternativos en caso de una falla en el servidor principal.
Plan de Continuidad de Negocios (BCP): Desarrollar un plan de continuidad de negocios que detalle cómo se debe actuar en caso de desastres. Esto debe incluir la asignación de funciones y responsabilidades, la comunicación con el personal y proveedores, y los pasos específicos para la recuperación.
Pruebas de recuperación ante desastres: Realizar pruebas periódicas de DR para asegurarse de que todos los procedimientos funcionen correctamente. Esto ayuda a identificar posibles problemas antes de que ocurra un desastre real.
Servicios de nube para DR: Utilizar servicios de nube como parte de su estrategia de DR. Muchos proveedores de nube ofrecen servicios específicos de recuperación ante desastres que pueden facilitar la recuperación y reducir los costos.
Recuperación de datos en tiempo real (RTO) y punto de recuperación (RPO): Definir objetivos claros para el tiempo de recuperación (cuánto tiempo puede pasar antes de que se restaure el servicio) y el punto de recuperación (cuántos datos se pueden perder). Estos objetivos varían según la crítica de la aplicación y los datos.
Almacenamiento resiliente: Utilizar tecnologías de almacenamiento resiliente, como RAID, para proteger los datos contra fallos de hardware.
Educación y capacitación del personal: Asegurarse de que el personal esté capacitado y preparado para responder adecuadamente a situaciones de recuperación ante desastres.

Es importante adaptar las estrategias de DR a las necesidades y presupuesto de su organización. Un enfoque adecuado para la recuperación ante desastres puede minimizar el tiempo de inactividad y proteger los activos críticos en caso de cualquier incidente inesperado.

Julian David Alzate Cuervo

SLA es un documento que especifica todas las condiciones del servicio prestado, responsabilidades de cada una de las partes y las posibles soluciones en el caso de incumplimiento.

Lucas Rojas

Alta Disponibilidad

💡 La disponibilidad se refiere al hecho de cuanto tiempo se encuentra un servicio disponible, para acceder al mismo.

¿Por qué perderíamos disponibilidad?

Problema en la red (Múltiples conexiones entre varios recursos).
Bug de una aplicación (Regularmente el responsable es el creador del software).
Falla del sistema (Ocurre cuando una VM corriendo un S.O. particular se torna como “NO DISPONIBLE”).
Corte de energía.

💡 Alta disponibilidad: Contar con la mayor cantidad de tiempo de disponibilidad de nuestros recursos.
✅ Lo ideal es contar con la mayor cantidad de tiempo de disponibilidad en nuestros recursos.
Los proveedores en la nube, brindan un Acuerdo de Nivel de Servicio (SLA) que garantiza cierto nivel de disponibilidad de los recursos con un porcentaje (%).
Este acuerdo es muy cercano al 100%. 💯
Únicamente aplica para los recursos controlados por el proveedor. 🌐

Tolerancia a Fallos

💡 Tolerancia a Fallos Es la capacidad de permanecer en funcionamiento incluso en el caso de que un componente o servicio deje de funcionar.

Características:

Es la capacidad de un sistema para permanecer en funcionamiento.
Permite la redundancia de los datos permitiendo mayor disponibilidad.

Walter Omar Barrios Vazquez

What is a Service Level Agreement (SLA)?

A service level agreement (SLA) is an outsourcing and technology vendor contract that outlines a level of service that a supplier promises to deliver to the customer. It outlines metrics such as uptime, delivery time, response time, and resolution time. An SLA also details the course of action when requirements are not met, such as additional support or pricing discounts. SLAs are typically agreed upon between a client and a service provider, although business units within the same company can also make SLAs with each other.
Fuente: AWS

Gildder Guerrero Ramirez

El SLA (Service Level Agreement) es un acuerdo que define el nivel de servicio esperado entre un proveedor y un cliente, incluyendo métricas de rendimiento como tiempo de actividad y respuesta. Se relaciona con la tolerancia a fallos ya que un SLA bien definido establece expectativas sobre la disponibilidad continua, incluso en caso de fallas. Una aplicación tolerante a fallos debe cumplir con los SLAs, asegurando que, a pesar de fallos en componentes, el servicio se mantiene disponible y sin degradación significativa.

Enrique Rojas Reyes

hace 9 meses

seria util que #Bancolombia tome esta clase jajajajaja

Mauricio Ruiz Rubio

Diferencias entre DRP y BCP: <https://www.welivesecurity.com/la-es/2014/10/14/plan-de-recuperacion-ante-desastres/>

Mijail Castillo Palomino

hace 10 meses

Alta disponibilidad "Infraestructura que le permite a un sistema continuar en funcionamiento a pesar de que alguno de sus componentes falle. OJO: todas las apps desplegadas en la nube deben ejecutarse en al menos dos zonas de disponibilidad

Kevin Daniel Guzmán Delgadillo

Suponiendo que tengo mi aplicación ejemplo Nequi, tendría sin duda para mejorar el RTO, por lo menos tres zonas Az1, 2, 3, también usaría sin duda, Kubernetes en GCP, así pues usando contenedores para cada uno de mis servicios sean serverless o no, tendré un deamon que estará levantandome nuevas instancias en cuanto se caigan, también por medio de argo podría automatizar el despliegue e integración continua, así asegurando que mi aplicación estará recuperada en caso de que sea una cuestión de error humano y demás. Para el RPO, usaría replicación dependiendo de qué tipo de BD tenga, e implementaría también un tema de bkps automáticos diarios, o sería mejor por medio de la cantidad de datos ingresados?, no sé cómo se podría hacer pero podría implementarse.

Gildder Guerrero Ramirez

La alta disponibilidad y la tolerancia a fallos son conceptos fundamentales en arquitecturas de nube. La alta disponibilidad se refiere a la capacidad de una aplicación de seguir funcionando a pesar de fallos en componentes, lo que implica desplegarla en múltiples zonas de disponibilidad. Por otro lado, la tolerancia a fallos es la capacidad de un sistema de soportar fallas y mantener la disponibilidad sin degradar el servicio. En resumen, una aplicación puede ser altamente disponible sin ser tolerante a fallos, pero si es tolerante a fallos, automáticamente es altamente disponible.

Gildder Guerrero Ramirez

La tolerancia a fallos es la capacidad de un sistema para continuar operando a pesar de la presencia de fallas en algunos de sus componentes. Esto implica que incluso si una parte del sistema falla, el sistema en su conjunto debe seguir funcionando sin interrupciones significativas. En el contexto de la nube, esto se relaciona estrechamente con la alta disponibilidad, ya que un sistema tolerante a fallos puede mantener la disponibilidad del servicio, aunque experimenta contratiempos en alguna de sus partes.

Gildder Guerrero Ramirez

El RPO, o Recovery Point Objective, es el punto de recuperación objetivo en una estrategia de recuperación de desastres. Se refiere a la cantidad máxima de datos que una organización está dispuesta a perder en caso de una interrupción. Por ejemplo, si una base de datos se respalda cada 24 horas, el RPO sería de 24 horas, lo que implica que se podrían perder hasta 24 horas de datos en caso de una falla. Este concepto es clave para diseñar arquitecturas de alta disponibilidad y tolerancia a fallos en sistemas en la nube.

Gildder Guerrero Ramirez

Para calcular el RTO (Recovery Time Objective) de una empresa de manera realista, se deben considerar varios factores: 1. **Análisis de Impacto en el Negocio (BIA)**: Evalúa cuánto tiempo puede estar inactiva la empresa sin afectar gravemente su operación y finanzas. 2. **Identificación de Procesos Críticos**: Determina qué aplicaciones y servicios son esenciales para la continuidad del negocio. 3. **Consultas con Stakeholders**: Recopila información de los líderes de cada área sobre sus necesidades de recuperación. 4. **Simulaciones y Pruebas**: Realiza ejercicios para medir tiempos de recuperación en situaciones de desastre. 5. **Documentación y Revisión Continua**: Actualiza el RTO regularmente, ya que las necesidades pueden cambiar con el tiempo. Este proceso asegura que el RTO sea realista y alineado con las necesidades estratégicas de la empresa.

Gildder Guerrero Ramirez

El costo del RTO (Recovery Time Objective) en proveedores de Cloud se calcula considerando varios factores clave. Primero, debes definir el tiempo máximo que puedes permitir que tu aplicación esté inactiva sin afectar el negocio. Luego, evalúa los costos asociados con la infraestructura necesaria para cumplir ese RTO, incluyendo: 1. **Recursos adicionales**: Si necesitas mantener instancias activas en múltiples zonas, esto incrementa el costo. 2. **Automatización**: Implementar procesos de recuperación rápida puede requerir inversión en herramientas y soluciones de automatización. 3. **Pruebas**: Realizar simulaciones de recuperación también puede implicar costos operativos. Al definir tu RTO, considera el nivel de servicio acordado con los proveedores de Cloud y ajusta tu arquitectura en consecuencia.

Gildder Guerrero Ramirez

El RTO (Recovery Time Objective) es el tiempo máximo tolerable que una aplicación puede estar inactiva después de un fallo antes de que afecte la continuidad del negocio. En el contexto de Cloud Computing, es crucial definir el RTO para garantizar que las aplicaciones se recuperen rápidamente, minimizando el impacto en los usuarios y en la empresa. Por ejemplo, si tu RTO es de 10 minutos, tu estrategia de recuperación debe asegurarse de que la aplicación esté operativa nuevamente dentro de ese tiempo.

ANDRES ALFONSO MIRA MEJIA

✅

Luis Fernando Soto Figueroa

Analisis R. A. M. Confiabilidad: Probabilidad de que un activo cumpla su función en un contexto operacional y tiempo establecido. Disponibilidad: Probabilidad de que un activo cumpla su funcion cada vez que se requiera. Mantenibilidad: Probabilidad de que un activo vuelva a cumplir su función despues de ocurrida una falla. Falla: Incumplimiento de la función. Redundancia: Soporte de la disponibilidad.

Mario Alexander Vargas Celis

| \*\*Característica\*\* | \*\*Alta Disponibilidad (HA)\*\* | \*\*Tolerancia a Fallos (FT)\*\* ||------------------|---------------------|-------------------|| \*\*Objetivo\*\* | Minimizar el tiempo de inactividad | Garantizar continuidad total || \*\*Método\*\* | Redundancia + Recuperación rápida | Redundancia en tiempo real || \*\*Ejemplo\*\* | Balanceo de carga en servidores | Servidor espejo en otra ubicación || \*\*Costo\*\* | Medio | Alto (requiere duplicación total) || \*\*Tiempo de recuperación\*\* | Segundos o minutos | Casi inmediato (milisegundos) |

Mario Alexander Vargas Celis

## **🛡️ Alta Disponibilidad vs. Tolerancia a Fallos** ### **1️⃣ Alta Disponibilidad (High Availability - HA)** 🔹 **Objetivo:** Mantener los sistemas **disponibles** el mayor tiempo posible, minimizando el tiempo de inactividad (*downtime*). 🔹 **Estrategia:** Usa **redundancia** y técnicas de recuperación rápida para evitar interrupciones. 🔹 **Métrica clave:** **"Uptime" (%)**, donde **99.999% (Five Nines)** significa solo **5 minutos de inactividad al año**. ✅ **Ejemplo de Alta Disponibilidad:** * Un sitio web usa **balanceadores de carga** para distribuir tráfico entre varios servidores. * Si un servidor falla, otro asume la carga sin interrumpir el servicio. 📌 **Ejemplo en la nube:** * **AWS Auto Scaling + Load Balancer** * **Google Cloud Load Balancing** ### **2️⃣ Tolerancia a Fallos (Fault Tolerance - FT)** 🔹 **Objetivo:** **Evitar que una falla afecte el sistema**, asegurando que siga funcionando sin interrupciones. 🔹 **Estrategia:** Usa componentes **totalmente redundantes y en tiempo real**, de manera que una falla no cause pérdida de servicio. ✅ **Ejemplo de Tolerancia a Fallos:** * Un avión tiene **dos motores independientes**; si uno falla, el otro sigue operando. * Un centro de datos tiene **fuentes de energía duplicadas**; si una se corta, la otra sigue funcionando. 📌 **Ejemplo en la nube:** * **Bases de datos replicadas en múltiples regiones (AWS RDS Multi-AZ, Google Spanner).** * **Sistemas de almacenamiento distribuido con copias de datos en diferentes servidores.** ## **📊 Diferencias Clave:** **CaracterísticaAlta Disponibilidad (HA)Tolerancia a Fallos (FT)Objetivo**Minimizar el tiempo de inactividadGarantizar continuidad total**Método**Redundancia + Recuperación rápidaRedundancia en tiempo real**Ejemplo**Balanceo de carga en servidoresServidor espejo en otra ubicación**Costo**MedioAlto (requiere duplicación total)**Tiempo de recuperación**Segundos o minutosCasi inmediato (milisegundos) ## **🛠️ ¿Cuál elegir?** ✔ **Alta Disponibilidad (HA)** → Cuando es aceptable un **breve tiempo de recuperación**. ✔ **Tolerancia a Fallos (FT)** → Cuando **cualquier interrupción es inaceptable** (ej. sistemas financieros o médicos). **💡 Ejemplo real:** * **Netflix** usa **Alta Disponibilidad**, distribuyendo contenido en varias regiones. * **Un sistema de control de reactores nucleares** usa **Tolerancia a Fallos**, ya que un fallo no es una opción. ## **📌 Conclusión** 📌 **Alta Disponibilidad** = Evita interrupciones con recuperación rápida. 📌 **Tolerancia a Fallos** = Sigue funcionando incluso si algo falla.

Mateo Montoya Henao

\*\*Alta disponibilidad\*\* se refiere a la capacidad de un sistema o servicio para permanecer accesible y operativo durante el mayor tiempo posible, generalmente expresado como un porcentaje (por ejemplo, 99.9% de disponibilidad). Esto implica diseñar sistemas que minimicen el tiempo de inactividad, incluso frente a mantenimientos programados o fallos imprevistos. Para lograr alta disponibilidad, se utilizan estrategias como la redundancia (tener múltiples servidores o componentes que realicen la misma tarea), balanceo de carga (distribuir el tráfico entre varios servidores) y replicación de datos (asegurarse de que los datos estén disponibles en múltiples ubicaciones). \*\*Tolerancia a fallos\*\*, por otro lado, es la capacidad de un sistema para continuar funcionando, aunque sea de manera limitada, ante errores o fallos en uno o más de sus componentes. Esto se logra mediante mecanismos como la detección automática de fallos, la recuperación automática y la implementación de sistemas de respaldo. Por ejemplo, si un servidor falla, otro puede tomar su lugar sin interrumpir el servicio. La tolerancia a fallos es clave para garantizar la alta disponibilidad, ya que asegura que los problemas técnicos no comprometan la funcionalidad del sistema. En resumen, \*\*alta disponibilidad\*\* busca maximizar el tiempo en que un sistema está operativo, mientras que \*\*tolerancia a fallos\*\* se enfoca en mantener el sistema funcionando incluso cuando ocurren problemas. Ambas son esenciales para construir sistemas robustos y confiables en entornos críticos como la nube o aplicaciones empresariales.

CHRISTIAN JAVIER CISNE TORREZ

hace 3 meses

Terrible. No se si es el video o el sitio de platzi pero es imposible ver la clase, se pega el video. Ojo, no es mi internet. Otros sitios me responden bien

Jonathan Sánchez López

hace 6 meses

Estrategia para Recuperación ante Desastres: ### **Pilot Light** Esta estrategia mantiene una parte mínima de los recursos activos en AWS, mientras que el resto está apagado. En caso de desastre, se encienden los recursos inactivos y se amplía la infraestructura para soportar la carga completa. #### **Pasos principales:** * Mantener servicios críticos (por ejemplo, bases de datos o configuraciones clave) ejecutándose en una región secundaria con un tamaño mínimo. * En caso de fallo, "encender" otros servicios o aumentar la capacidad de los sistemas para soportar la carga completa. * Utilizar servicios como **AWS CloudFormation** para automatizar el despliegue rápido de la infraestructura. #### **Ejemplo:** Un sistema que tiene su base de datos activa en una región secundaria, pero solo crea instancias EC2 adicionales cuando la región principal falla.

Edwin Einsen Vásquez Velásquez

hace 8 meses

Tomando como ejemplo AWS, ellos tienen esta configuración de DRS: 1. Instalación del agente de replicación 2. Monitoreo de la replicación 3. Pruebas de integridad 4. Activación del entorno de DR 5. Replicación inversa y failback La elección de la estrategia correcta debe tener en cuenta variables como el RTO (objetivo de tiempo de recuperación), que se basa en el tiempo que tarda un sistema en recuperarse y reanudar sus actividades después de sufrir una indisponibilidad; así como el RPO (Recovery Point Objective), el cual consiste en la cantidad de datos que la empresa toleraría perder si se interrumpieran los sistemas. Los 4 enfoques de recuperación ante desastres tomando en cuenta el RPO/RTO se pueden ver en la siguiente imagen: ![](https://static.platzi.com/media/user_upload/image-27db9501-8b91-444f-ba81-ef673e9404bc.jpg) Y así funciona RDS en AWS: ![](https://static.platzi.com/media/user_upload/image-51b6a0c6-fbd0-4503-8971-66808c46b7c2.jpg)

Alfredo Olmedo

hace 8 meses

En Tolerancia a Fallos se vio un concepto SLA, que son: SLA (Service Level Agreement): Es un acuerdo formal entre un proveedor de servicios y un cliente que define los niveles de servicio esperados. Incluye métricas específicas como tiempo de actividad, tiempos de respuesta y responsabilidades. Los SLAs suelen tener consecuencias si no se cumplen, como penalizaciones financieras o créditos de servicio. SLO (Service Level Objective): Es un objetivo específico que el proveedor de servicios se compromete a alcanzar para cumplir con el SLA. Por ejemplo, un SLO podría ser un tiempo de actividad del 99.99% o un tiempo de respuesta de soporte de 24 horas. Los SLOs son metas internas que ayudan a asegurar que se cumplan los SLAs. SLI (Service Level Indicator): Es una métrica que mide el rendimiento real del servicio en relación con los SLOs. Por ejemplo, si el SLO es un tiempo de respuesta de 200 ms, el SLI sería la medición real de ese tiempo de respuesta. Los SLIs proporcionan datos cuantitativos para evaluar si se están cumpliendo los SLOs. Estos conceptos son fundamentales para gestionar y monitorear la calidad del servicio en entornos de TI y asegurar que se cumplan las expectativas de los usuarios.

Jonathan Posada Torres

Las soluciones de copias de seguridad y los planes de recuperación después de un desastre son cruciales para lograr el Objetivo de Tiempo de Recuperación (RTO). Estas herramientas permiten a las organizaciones recuperarse rápidamente de interrupciones, minimizando el tiempo de inactividad y la pérdida de datos. Para alcanzar un RTO cercano a cero, se deben considerar las siguientes capacidades y funciones: 1. **Recuperación instantánea**: Permite restaurar y operar máquinas directamente desde el almacenamiento de las copias de seguridad, esencial para mantener operaciones durante interrupciones inesperadas y restaurar datos específicos rápidamente. 2. **Políticas de programación flexibles**: Ajustar los Objetivos de Punto de Recuperación (RPO) según las necesidades actuales de la organización, adaptándose a los cambios en los requisitos del RTO. 3. **Protección de datos continua (CDP)**: Asegura copias de seguridad constantes y protección de datos, permitiendo restauraciones rápidas. Aunque útil para cargas de trabajo críticas, puede impactar en el rendimiento y estabilidad debido a su alto uso de recursos. 4. **Protección casi continua de datos (NCDP)**: Ofrece copias de seguridad casi en tiempo real con un impacto mínimo en el rendimiento, ideal para organizaciones que necesitan mantener objetivos de RTO cercanos a cero. 5. **Recuperación granular**: Permite la recuperación de archivos individuales sin necesidad de restaurar un conjunto completo de datos, agilizando el proceso de recuperación en escenarios de RTO. 6. **Copia fuera del sitio para recuperación después de un desastre**: Tener una copia de los datos en una ubicación secundaria asegura una rápida recuperación de desastres o interrupciones en el sitio principal. 7. **Replicación en vivo con conmutación por error**: Mantiene datos disponibles en tiempo real y permite cambiar rápidamente entre sitios primarios y secundarios en caso de fallos, minimizando las interrupciones y el tiempo de inactividad. Estas funcionalidades, al ser implementadas y gestionadas adecuadamente, permiten a las organizaciones cumplir con sus objetivos de RTO y garantizar la continuidad del negocio ante cualquier eventualidad.

JHON FREDDY TAVERA BLANDON