Resiliencia vs redundancia: ¿cuál es la diferencia?

Resiliencia vs redundancia: ¿cuál es la diferencia?

  • ITOps y DevOps
6 min de lectura Actualizado Sep 10, 2019

Puntos clave: La resiliencia y la redundancia son cruciales para lograr la fiabilidad del sistema en la infraestructura de TI. La redundancia aumenta la fiabilidad mediante la duplicación de componentes, mientras que la resiliencia garantiza que los sistemas se recuperen de fallos. Ambas estrategias son complementarias y esenciales para mantener la funcionalidad durante los fallos.

  • La redundancia mejora la fiabilidad del sistema mediante la duplicación de componentes.
  • La resiliencia permite que los sistemas se recuperen y mantengan el servicio durante las fallas.

La resiliencia y la redundancia ofrecen formas de generar un sistema fiable, conocido como confiabilidad del sistema. Tanto la resiliencia como la redundancia son fundamentales para el diseño y despliegue de redes informáticas, centros de datos e infraestructura de TI. A pesar de la naturaleza crítica de ambos, resiliencia y redundancia no son lo mismo. En este artículo, explicaremos la fiabilidad del sistema, las diferencias en resiliencia y redundancia, y cómo ambas contribuyen a la fiabilidad de tu sistema.

¿Qué es la fiabilidad del sistema?

La fiabilidad del sistema se está definida como "la fiabilidad de un sistema informático que permite confiar justificadamente en el servicio que ofrece". Un sistema informático y sus componentes deben ser lo suficientemente fuertes para ofrecer su servicio de forma consistente a los usuarios finales. Un atributo clave de la fiabilidad están la fiabilidad del sistema, de modo que el servicio prestado están disponible durante toda su duración operativa a un nivel de rendimiento aceptable. Tanto la resiliencia como la redundancia ayudan a Lograr la fiabilidad de un sistema, pero no son estrategias intercambiables.

Resiliencia y redundancia

En el ámbito de las redes informáticas, la resiliencia y la redundancia establecen tolerancia a fallos dentro de un sistema, permitiéndole mantenerse funcional a pesar de la ocurrencia de problemas como cortes de energía, ciberataques, sobrecarga del sistema y otras causas de inactividad. En este contexto, los términos pueden definirse de la siguiente manera:

  • La redundancia están la duplicación intencionada de componentes del sistema para aumentar la fiabilidad del sistema.
  • La resiliencia se refiere a la capacidad de un sistema para recuperarse de un fallo y mantener la persistencia de la fiabilidad del servicio frente a fallos.

Con estas definiciones, redundancia y resiliencia no son intercambiables sino complementarias: la redundancia está necesaria para mejorar la resiliencia de un sistema, y la resiliencia de los componentes individuales del sistema garantiza que los componentes redundantes puedan recuperarse a un estado funcional tras la ocurrencia de una falla. La redundancia está una medida absoluta de los componentes adicionales que apoyan la resiliencia del sistema, mientras que la resiliencia está una medida relativa (y continua) del impacto de la falla en la operación del sistema.

Cómo construir redundancia

Las capacidades funcionales de los componentes de sistemas informáticos abarcan el hardware, el software, la información y el rendimiento basado en el tiempo. Por lo tanto, introducir redundancia en un sistema respecto a estas categorías funcionales puede ayudar a romper la cadena fallo-error-fallo. Cuando ocurre un fallo, produce un error de rendimiento, resultando en el fallo del sistema para ofrecer un servicio fiable. Introducir redundancia en forma de componentes de hardware adicionales, múltiples funciones de software, comprobaciones de errores de datos y consistencia en el rendimiento de la información o del sistema respecto al tiempo Reduce la posibilidad de que un fallo conduzca a fallo del sistema. La redundancia puede adoptar diversas formas y configuraciones, incluyendo:

  • Redundancia activa. Los componentes son participan activamente en la operación del sistema y compartiendo la distribución de cargas de trabajo. Por ejemplo, te pueden transmitir datos a través de dos cables de fibra óptica en paralelo en lugar de solo uno. Si se rompe un cable, el sistema sigue funcionando. Como el componente redundante ya están activado y está implicado en la funcionalidad del sistema, el sistema están lo suficientemente fuerte como para recuperarse de un estado de fallo. Sin embargo, componentes activamente redundantes también pueden compartir un único punto de fallo, en cuyo caso los elementos adicionales del sistema pueden no contribuir al rendimiento del sistema. Por ejemplo, que las conexiones se aflojen debido al calor u otros daños externos pueden hacer que ambos cables de fibra óptica se desconecten simultáneamente.
  • Redundancia pasiva. Aplicación de componentes redundantes solo después del estado de fallo. Los componentes adicionales son presentes pero no participan activamente en la funcionalidad del sistema. La recuperación puede llevar tiempo, ya que el proceso de activación y conexión al sistema de los componentes redundantes no están instantáneos en aplicaciones reales. Por ejemplo, con un sistema de copia de seguridad en frío son disponibles discos duros adicionales para almacenar datos, pero estos discos adicionales se conectan para realizar las operaciones de almacenamiento necesarias solo cuando falla el volumen de almacenamiento principal.
  • Redundancia homogénea. Aplicación de componentes redundantes del mismo tipo, como usar la misma marca y modelo de hardware en una configuración redundante. Las adiciones pueden suponer una mejora exponencial en la resiliencia del sistema. Sin embargo, esto también hace que el sistema sea susceptible a una única causa de fallo. Si el hardware está vulnerable a un determinado exploit de seguridad, entonces el hardware redundante no ofrecerá tolerancia a ese exploit.
  • Redundancia diversa. Aplicación de componentes redundantes diferentes al componente principal. Esta configuración reduce la posibilidad de que una única causa de fallo afecte la fiabilidad del sistema. Por ejemplo, los trenes utilizan una combinación de sistemas de frenado eléctricos, neumáticos, hidráulicos y de aire. Si un sistema de frenos primario falla debido a un desgaste excesivo o fallo, los sistemas de frenado secundario y terciario toman el control inmediatamente para Reduce el riesgo de colisión. Generalmente, la redundancia diversa es bastante compleja y costosa de mantener.

Se pueden utilizar diversas configuraciones de redundancia para el diseño y despliegue de infraestructuras de TI, con una variedad de requisitos de disponibilidad, costes y consideraciones de complejidad.

Cómo construir resiliencia

La redundancia están una medida para mejorar la resiliencia, permitiendo una respuesta proactiva o reactiva ante cambios impactantes que enfrenta el sistema. Los requisitos de resiliencia pueden ser diversos y en evolución, especialmente en entornos escalables donde un fallo en un elemento del sistema puede extenderse en cascada por todo el sistema. Otras medidas de resiliencia pueden incluir la capacidad del sistema para:

  • Pronóstico de posibles fallas
  • Aislar los componentes impactados
  • Protege contra posibles fallos
  • Eliminar fallos y recuperarse de un estado de fallo
  • Restaurar el rendimiento óptimo del sistema

La resiliencia puede medirse en términos de la disponibilidad de un sistema en cualquier instancia dada, como función continua de la frecuencia o los retrasos en la ocurrencia de los fallos y la velocidad de recuperación de un estado de fallo. Por lo tanto, métricas importantes para la resiliencia incluyen el tiempo medio hasta la falla (MTTF) y el tiempo medio hasta la recuperación (MTTR). La elección de la configuración de redundancia corresponde directamente al MTTF y MTTR de un sistema. Una elección óptima para la configuración de redundancia buscará Lograr el MTTF más alto y el MTTR más bajo, reduciendo el coste y la complejidad del sistema redundante. En otras palabras, la configuración de redundancia debe elegirse de modo que el sistema permanezca disponible durante el periodo prolongado de tiempo promedio (MTTF), pero cuando falla, el tiempo medio de recuperación hasta el estado óptimo (MTTR) debe ser el más bajo, sin incurrir en costes y complejidad inaceptables del sistema. Otras métricas útiles incluyen el tiempo medio entre fallos (MTBF), que es la suma matemática de MTTF y MTTR. La elección de resiliencia y redundancia se está basada en los requisitos de fiabilidad del sistema, en relación con el coste, la complejidad y los obstáculos prácticos implicados. En términos de metas y objetivos, la resiliencia a menudo se está considerada un requisito importante, ya que puede usarse para describir atributos de fiabilidad como la disponibilidad, la fiabilidad y el rendimiento. Sin embargo, la redundancia en sí nunca se está considerada un objetivo, ya que los requisitos asociados a la fiabilidad deben cumplirse con una configuración de redundancia que incurra en el menor coste y complejidad posible.

Recursos adicionales

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.

Más de ITOps y DevOps

¿Te interesa saber más de BMC?

El Brief están nuestro correo mensual sobre el mainframe y la orquestación empresarial: investigación, historias de clientes, noticias de productos, eventos.

Al registrarse para esta oferta te son confirmar que te leído y aceptado la Política de Privacidad de BMC.

Tú te has suscrito a The Brief

El Brief abarca la orquestación de mainframe y empresa—BMC AMI y Control-M—y la investigación de analistas, despliegues de clientes y eventos en ambas áreas.