Alta disponibilidad
Sistemas con un alto tiempo de actividad, también conocidos como "siempre activos"

La alta disponibilidad ( HA ) es una característica de un sistema que tiene como objetivo garantizar un nivel acordado de rendimiento operativo, generalmente tiempo de actividad , durante un período más alto que el normal. [1]

Hoy en día, la dependencia de estos sistemas es mayor como resultado de la modernización. Por ejemplo, para llevar a cabo sus tareas diarias habituales, los hospitales y los centros de datos necesitan que sus sistemas tengan una alta disponibilidad. La disponibilidad se refiere a la capacidad de la comunidad de usuarios de obtener un servicio o un bien, acceder al sistema, ya sea para enviar un nuevo trabajo, actualizar o modificar un trabajo existente o recopilar los resultados de un trabajo anterior. Si un usuario no puede acceder al sistema, este no está disponible , desde el punto de vista del usuario . [2] En general, el término tiempo de inactividad se utiliza para referirse a los períodos en los que un sistema no está disponible.

Resiliencia

La alta disponibilidad es una propiedad de la resiliencia de la red , la capacidad de "proporcionar y mantener un nivel aceptable de servicio frente a fallas y desafíos para el funcionamiento normal". [3] Las amenazas y los desafíos para los servicios pueden variar desde una simple configuración incorrecta hasta desastres naturales a gran escala y ataques dirigidos. [4] Como tal, la resiliencia de la red toca una amplia gama de temas. Para aumentar la resiliencia de una red de comunicación determinada, se deben identificar los desafíos y riesgos probables y se deben definir métricas de resiliencia adecuadas para el servicio que se desea proteger. [5]

La importancia de la resiliencia de la red aumenta continuamente, ya que las redes de comunicación se están convirtiendo en un componente fundamental en el funcionamiento de las infraestructuras críticas. [6] En consecuencia, los esfuerzos recientes se centran en interpretar y mejorar la resiliencia de la red y de la computación con aplicaciones a las infraestructuras críticas. [7] A modo de ejemplo, se puede considerar como un objetivo de resiliencia la provisión de servicios a través de la red, en lugar de los servicios de la red en sí. Esto puede requerir una respuesta coordinada tanto de la red como de los servicios que se ejecutan sobre la red. [8]

Estos servicios incluyen:

La resiliencia y la capacidad de supervivencia se utilizan indistintamente según el contexto específico de un estudio determinado. [9]

Principios

Hay tres principios de diseño de sistemas en ingeniería de confiabilidad que pueden ayudar a lograr una alta disponibilidad.

  1. Eliminación de puntos únicos de falla . Esto significa agregar o crear redundancia en el sistema para que la falla de un componente no signifique la falla de todo el sistema.
  2. Cruce confiable. En sistemas redundantes , el punto de cruce en sí mismo tiende a convertirse en un único punto de falla. Los sistemas confiables deben proporcionar un cruce confiable.
  3. Detección de fallos en el momento en que se producen. Si se respetan los dos principios anteriores, es posible que el usuario nunca detecte un fallo, pero la actividad de mantenimiento sí.

Tiempo de inactividad programado y no programado

Se puede hacer una distinción entre tiempo de inactividad programado y no programado. Normalmente, el tiempo de inactividad programado es el resultado de un mantenimiento que interrumpe el funcionamiento del sistema y, por lo general, no se puede evitar con un diseño de sistema actualmente instalado. Los eventos de tiempo de inactividad programado pueden incluir parches para el software del sistema que requieren un reinicio o cambios de configuración del sistema que solo surten efecto al reiniciar. En general, el tiempo de inactividad programado suele ser el resultado de algún evento lógico iniciado por la administración. Los eventos de tiempo de inactividad no programado generalmente surgen de algún evento físico, como una falla de hardware o software o una anomalía ambiental. Algunos ejemplos de eventos de tiempo de inactividad no programado incluyen cortes de energía, fallas en los componentes de CPU o RAM (o posiblemente otros componentes de hardware fallidos), un apagado relacionado con exceso de temperatura, conexiones de red cortadas lógica o físicamente, violaciones de seguridad o varias fallas de aplicaciones , middleware y sistema operativo .

Si se puede advertir a los usuarios que no deben esperar a que se produzcan tiempos de inactividad programados, la distinción es útil. Pero si el requisito es una verdadera alta disponibilidad, entonces el tiempo de inactividad es tiempo de inactividad, independientemente de si está programado o no.

Muchos sitios de computación excluyen el tiempo de inactividad programado de los cálculos de disponibilidad, asumiendo que tiene poco o ningún impacto en la comunidad de usuarios de computación. Al hacer esto, pueden afirmar que tienen una disponibilidad fenomenalmente alta, lo que podría dar la ilusión de disponibilidad continua . Los sistemas que muestran una disponibilidad verdaderamente continua son comparativamente raros y más costosos, y la mayoría han implementado cuidadosamente diseños especiales que eliminan cualquier punto único de falla y permiten actualizaciones, parches y reemplazos de hardware, red, sistema operativo, middleware y aplicaciones en línea. Para ciertos sistemas, el tiempo de inactividad programado no importa, por ejemplo, el tiempo de inactividad del sistema en un edificio de oficinas después de que todos se hayan ido a casa por la noche.

Cálculo de porcentaje

La disponibilidad se expresa generalmente como un porcentaje del tiempo de actividad en un año determinado. La siguiente tabla muestra el tiempo de inactividad que se permitirá para un porcentaje particular de disponibilidad, suponiendo que se requiere que el sistema funcione de manera continua. Los acuerdos de nivel de servicio a menudo hacen referencia al tiempo de inactividad o disponibilidad mensual para calcular los créditos de servicio que coincidan con los ciclos de facturación mensuales. La siguiente tabla muestra la traducción de un porcentaje de disponibilidad determinado a la cantidad correspondiente de tiempo que un sistema no estaría disponible.

Disponibilidad %Tiempo de inactividad por año [nota 1]Tiempo de inactividad por trimestreTiempo de inactividad por mesTiempo de inactividad por semanaTiempo de inactividad por día (24 horas)
90% ("uno nueve")36,53 días9,13 días73,05 horas16,80 horas2,40 horas
95% ("uno nueve cinco")18,26 días4,56 días36,53 horas8,40 horas1,20 horas
97% ("uno nueve siete")10,96 días2,74 días21,92 horas5,04 horas43,20 minutos
98% ("uno nueve ocho")7,31 días43,86 horas14,61 horas3,36 horas28,80 minutos
99% ("dos nueves")3,65 días21,9 horas7,31 horas1,68 horas14,40 minutos
99,5% ("dos nueves cinco")1,83 días10,98 horas3,65 horas50,40 minutos7,20 minutos
99,8% ("dos nueves ocho")17,53 horas4,38 horas87,66 minutos20,16 minutos2,88 minutos
99,9% ("tres nueves")8,77 horas2,19 horas43,83 minutos10,08 minutos1,44 minutos
99,95% ("tres nueves cinco")4,38 horas65,7 minutos21,92 minutos5,04 minutos43,20 segundos
99,99% ("cuatro nueves")52,60 minutos13,15 minutos4,38 minutos1,01 minutos8,64 segundos
99,995% ("cuatro nueves cinco")26,30 minutos6,57 minutos2,19 minutos30,24 segundos4,32 segundos
99,999% ("cinco nueves")5,26 minutos1,31 minutos26,30 segundos6,05 segundos864,00 milisegundos
99,9999% ("seis nueves")31,56 segundos7,89 segundos2,63 segundos604,80 milisegundos86,40 milisegundos
99,99999% ("siete nueves")3,16 segundos0,79 segundos262,98 milisegundos60,48 milisegundos8,64 milisegundos
99,999999% ("ocho nueves")315,58 milisegundos78,89 milisegundos26,30 milisegundos6,05 milisegundos864,00 microsegundos
99,9999999% ("nueve nueves")31,56 milisegundos7,89 milisegundos2,63 milisegundos604,80 microsegundos86,40 microsegundos
99,99999999% ("diez nueves")3,16 milisegundos788,40 microsegundos262,80 microsegundos60,48 microsegundos8,64 microsegundos
99,999999999% ("once nueves")315,58 microsegundos78,84 microsegundos26,28 microsegundos6,05 microsegundos864,00 nanosegundos
99,9999999999% ("doce nueves")31,56 microsegundos7,88 microsegundos2,63 microsegundos604,81 nanosegundos86,40 nanosegundos

Los términos tiempo de actividad y disponibilidad se utilizan a menudo indistintamente, pero no siempre se refieren a lo mismo. Por ejemplo, un sistema puede estar "activo" y sus servicios no "disponibles" en caso de una interrupción de la red . O un sistema que se encuentra en mantenimiento de software puede estar "disponible" para que un administrador del sistema trabaje en él , pero sus servicios no parecen estar "activos" para el usuario final o el cliente. Por lo tanto, el tema de los términos es importante aquí: ya sea que el foco de una discusión sea el hardware del servidor, el sistema operativo del servidor, el servicio funcional, el servicio/proceso de software o algo similar, solo si existe un tema único y consistente de la discusión, las palabras tiempo de actividad y disponibilidad se pueden usar como sinónimos.

Mnemotécnica de cinco por cinco

Una regla mnemotécnica simple establece que 5 nueves permiten aproximadamente 5 minutos de tiempo de inactividad por año. Se pueden obtener variantes multiplicando o dividiendo por 10: 4 nueves son 50 minutos y 3 nueves son 500 minutos. En la dirección opuesta, 6 nueves son 0,5 minutos (30 segundos) y 7 nueves son 3 segundos.

El truco de las "potencias de 10"

Otro truco de memoria para calcular la duración del tiempo de inactividad permitido para un porcentaje de disponibilidad de "-nueves" es utilizar la fórmula segundos por día. norte {\estilo de visualización n} 8.64 × 10 4 − norte {\displaystyle 8,64\times 10^{4-n}}

Por ejemplo, 90% ("uno nueve") da como resultado el exponente y, por lo tanto, el tiempo de inactividad permitido es de segundos por día. 4 − 1 = 3 {\estilo de visualización 4-1=3} 8.64 × 10 3 {\displaystyle 8,64\times 10^{3}}

Además, 99,999% ("cinco nueves") da el exponente y, por lo tanto, el tiempo de inactividad permitido es de segundos por día. 4 − 5 = − 1 {\estilo de visualización 4-5=-1} 8.64 × 10 − 1 {\displaystyle 8,64\times 10^{-1}}

"Nueve"

A veces, los porcentajes de un orden de magnitud particular se indican mediante la cantidad de nueves o "clase de nueves" en los dígitos. Por ejemplo, la electricidad que se suministra sin interrupciones ( apagones , caídas de tensión o sobretensiones ) el 99,999 % del tiempo tendría una confiabilidad de 5 nueves, o clase cinco. [10] En particular, el término se utiliza en relación con mainframes [11] [12] o informática empresarial, a menudo como parte de un acuerdo de nivel de servicio .

De manera similar, los porcentajes que terminan en 5 tienen nombres convencionales, tradicionalmente el número de nueves, luego "cinco", por lo que el 99,95% es "tres nueves cinco", abreviado 3N5. [13] [14] Esto se conoce casualmente como "tres nueves y medio", [15] pero esto es incorrecto: un 5 es solo un factor de 2, mientras que un 9 es un factor de 10, por lo que un 5 es 0,3 nueves (según la fórmula a continuación: ): [nota 2] La disponibilidad del 99,95% es 3,3 nueves, no 3,5 nueves. [16] En términos más simples, pasar de una disponibilidad del 99,9% a una disponibilidad del 99,95% es un factor de 2 (indisponibilidad del 0,1% al 0,05%), pero pasar de una disponibilidad del 99,95% al ​​99,99% es un factor de 5 (indisponibilidad del 0,05% al ​​0,01%), más del doble. [nota 3] registro 10 ⁡ 2 ≈ 0.3 {\displaystyle \log _{10}2\aproximadamente 0,3}

Una formulación de la clase de 9 basada en la indisponibilidad de un sistema sería do {\estilo de visualización c} incógnita {\estilo de visualización x}

do := ⌊ − registro 10 ⁡ incógnita ⌋ {\displaystyle c:=\lpiso -\log _{10}x\rpiso}

(cf. Funciones de suelo y techo ).

A veces se utiliza una medida similar para describir la pureza de las sustancias.

En general, los ingenieros de redes no suelen utilizar el número de nueves al modelar y medir la disponibilidad porque es difícil de aplicar en una fórmula. Más a menudo, se cita la indisponibilidad expresada como una probabilidad (como 0,00001) o un tiempo de inactividad por año. La disponibilidad especificada como un número de nueves se ve a menudo en los documentos de marketing . [ cita requerida ] El uso de los "nueves" ha sido cuestionado, ya que no refleja adecuadamente que el impacto de la indisponibilidad varía con el momento en que ocurre. [17] Para grandes cantidades de nueves, el índice de "inadisponibilidad" (medida del tiempo de inactividad en lugar del tiempo de actividad) es más fácil de manejar. Por ejemplo, esta es la razón por la que se utiliza una métrica de "inadisponibilidad" en lugar de una de disponibilidad en las tasas de error de bits del disco duro o del enlace de datos .

A veces se utiliza el término humorístico "nueve cincos" (55,5555555%) para contrastar con "cinco nueves" (99,999%), [18] [19] [20] aunque este no es un objetivo real, sino más bien una referencia sarcástica a algo que no logra en absoluto cumplir ningún objetivo razonable.

Medición e interpretación

La medición de la disponibilidad está sujeta a cierto grado de interpretación. Un sistema que ha estado en funcionamiento durante 365 días en un año no bisiesto puede haber sido eclipsado por una falla de red que duró 9 horas durante un período de uso pico; la comunidad de usuarios verá el sistema como no disponible, mientras que el administrador del sistema afirmará que el tiempo de funcionamiento es del 100%. Sin embargo, dada la verdadera definición de disponibilidad, el sistema estará disponible aproximadamente en un 99,9%, o tres nueves (8751 horas de tiempo disponible de 8760 horas por año no bisiesto). Además, los usuarios suelen considerar que los sistemas que experimentan problemas de rendimiento están parcial o totalmente no disponibles, incluso cuando siguen funcionando. De manera similar, la falta de disponibilidad de determinadas funciones de la aplicación puede pasar desapercibida para los administradores, pero puede ser devastadora para los usuarios: una verdadera medición de la disponibilidad es holística.

Para determinar la disponibilidad es necesario medirla, idealmente con herramientas de monitoreo integrales ("instrumentación") que sean altamente disponibles. Si no hay instrumentación, los sistemas que admiten el procesamiento de transacciones de gran volumen durante el día y la noche, como los sistemas de procesamiento de tarjetas de crédito o las centrales telefónicas, suelen estar inherentemente mejor monitoreados, al menos por los propios usuarios, que los sistemas que experimentan pausas periódicas en la demanda.

Una métrica alternativa es el tiempo medio entre fallos (MTBF).

El tiempo de recuperación (o tiempo estimado de reparación (ETR), también conocido como objetivo de tiempo de recuperación (RTO) está estrechamente relacionado con la disponibilidad, es decir, el tiempo total requerido para una interrupción planificada o el tiempo requerido para recuperarse completamente de una interrupción no planificada. Otra métrica es el tiempo medio de recuperación (MTTR). El tiempo de recuperación podría ser infinito con ciertos diseños y fallas del sistema, es decir, la recuperación completa es imposible. Un ejemplo de esto es un incendio o una inundación que destruye un centro de datos y sus sistemas cuando no hay un centro de datos de recuperación ante desastres secundario .

Otro concepto relacionado es la disponibilidad de datos , es decir, el grado en el que las bases de datos y otros sistemas de almacenamiento de información registran y notifican fielmente las transacciones del sistema. La gestión de la información suele centrarse por separado en la disponibilidad de datos, o en el objetivo de punto de recuperación , para determinar la pérdida de datos aceptable (o real) ante diversos eventos de fallo. Algunos usuarios pueden tolerar interrupciones del servicio de la aplicación, pero no pueden tolerar la pérdida de datos.

Un acuerdo de nivel de servicio ("SLA") formaliza los objetivos y requisitos de disponibilidad de una organización.

Sistemas de control militar

La alta disponibilidad es uno de los requisitos principales de los sistemas de control en vehículos no tripulados y buques marítimos autónomos . Si el sistema de control deja de estar disponible, se perdería el vehículo de combate terrestre (GCV) o el buque no tripulado de ataque continuo antisubmarino (ACTUV).

Diseño del sistema

Por un lado, agregar más componentes a un diseño de sistema general puede socavar los esfuerzos para lograr una alta disponibilidad porque los sistemas complejos tienen inherentemente más puntos de falla potenciales y son más difíciles de implementar correctamente. Si bien algunos analistas propondrían la teoría de que los sistemas con mayor disponibilidad se adhieren a una arquitectura simple (un sistema físico único, de alta calidad y multipropósito con redundancia de hardware interna integral), esta arquitectura sufre del requisito de que se debe desconectar todo el sistema para aplicar parches y actualizaciones del sistema operativo. Los diseños de sistemas más avanzados permiten aplicar parches y actualizar los sistemas sin comprometer la disponibilidad del servicio (consulte equilibrio de carga y conmutación por error ). La alta disponibilidad requiere menos intervención humana para restablecer el funcionamiento en sistemas complejos; la razón de esto es que la causa más común de interrupciones es el error humano. [21]

Alta disponibilidad mediante redundancia

Por otro lado, la redundancia se utiliza para crear sistemas con altos niveles de disponibilidad (por ejemplo, sitios web de comercio electrónico populares). En este caso, se requiere tener altos niveles de detectabilidad de fallas y evitar fallas por causas comunes.

Si se utilizan partes redundantes en paralelo y tienen fallas independientes (por ejemplo, al no estar dentro del mismo centro de datos), pueden aumentar exponencialmente la disponibilidad y hacer que el sistema general sea altamente disponible. Si tiene N componentes paralelos, cada uno con X disponibilidad, puede usar la siguiente fórmula: [22] [23]

Disponibilidad de componentes paralelos = 1 - (1 - X)^ N

10 hosts, cada uno con una disponibilidad del 50 %. Pero si se utilizan en paralelo y fallan de forma independiente, pueden proporcionar alta disponibilidad.
10 hosts, cada uno con una disponibilidad del 50 %. Pero si se utilizan en paralelo y fallan de forma independiente, pueden proporcionar alta disponibilidad.

Entonces, por ejemplo, si cada uno de sus componentes tiene solo un 50 % de disponibilidad, al utilizar 10 componentes en paralelo, puede lograr una disponibilidad del 99,9023 %.

Hay dos tipos de redundancia: la redundancia pasiva y la redundancia activa.

La redundancia pasiva se utiliza para lograr una alta disponibilidad al incluir suficiente capacidad excedente en el diseño para adaptarse a una disminución del rendimiento. El ejemplo más simple es un barco con dos motores separados que impulsan dos hélices separadas. El barco continúa hacia su destino a pesar de la falla de un solo motor o hélice. Un ejemplo más complejo son múltiples instalaciones de generación de energía redundantes dentro de un gran sistema que involucra transmisión de energía eléctrica . El mal funcionamiento de componentes individuales no se considera una falla a menos que la disminución del rendimiento resultante exceda los límites de especificación para todo el sistema.

La redundancia activa se utiliza en sistemas complejos para lograr una alta disponibilidad sin disminución del rendimiento. Se incorporan varios elementos del mismo tipo en un diseño que incluye un método para detectar fallas y reconfigurar automáticamente el sistema para omitir los elementos fallidos mediante un esquema de votación. Esto se utiliza con sistemas informáticos complejos que están vinculados. El enrutamiento de Internet se deriva del trabajo inicial de Birman y Joseph en esta área. [24] [ fuente no primaria necesaria ] La redundancia activa puede introducir modos de falla más complejos en un sistema, como la reconfiguración continua del sistema debido a una lógica de votación defectuosa.

El diseño de un sistema con tiempo de inactividad cero significa que el modelado y la simulación indican que el tiempo medio entre fallas excede significativamente el período de tiempo entre el mantenimiento planificado , los eventos de actualización o la vida útil del sistema. El tiempo de inactividad cero implica una redundancia masiva, que es necesaria para algunos tipos de aeronaves y para la mayoría de los tipos de satélites de comunicaciones . El sistema de posicionamiento global es un ejemplo de un sistema con tiempo de inactividad cero.

La instrumentación de fallas se puede utilizar en sistemas con redundancia limitada para lograr una alta disponibilidad. Las acciones de mantenimiento se llevan a cabo durante breves períodos de inactividad solo después de que se activa un indicador de falla. La falla solo es significativa si ocurre durante un período crítico para la misión .

La modelización y la simulación se utilizan para evaluar la fiabilidad teórica de sistemas grandes. El resultado de este tipo de modelo se utiliza para evaluar diferentes opciones de diseño. Se crea un modelo de todo el sistema y se somete a tensión mediante la eliminación de componentes. La simulación de redundancia implica el criterio Nx. N representa el número total de componentes del sistema. x es el número de componentes utilizados para someter a tensión el sistema. N-1 significa que el modelo se somete a tensión mediante la evaluación del rendimiento con todas las combinaciones posibles en las que un componente falla. N-2 significa que el modelo se somete a tensión mediante la evaluación del rendimiento con todas las combinaciones posibles en las que dos componentes fallan simultáneamente.

Razones de indisponibilidad

Una encuesta realizada entre expertos académicos en disponibilidad en 2010 clasificó las razones de la falta de disponibilidad de los sistemas de TI empresariales. Todas las razones hacen referencia a la falta de seguimiento de las mejores prácticas en cada una de las siguientes áreas (en orden de importancia): [25]

  1. Monitoreo de los componentes relevantes
  2. Requisitos y adquisiciones
  3. Operaciones
  4. Prevención de fallos en la red
  5. Prevención de fallos internos en las aplicaciones
  6. Evitar servicios externos que fallan
  7. Entorno físico
  8. Redundancia de red
  9. Solución técnica de backup
  10. Solución de proceso de backup
  11. Ubicación física
  12. Redundancia de infraestructura
  13. Redundancia de la arquitectura de almacenamiento

En 2003 se publicó un libro sobre los factores en sí. [26]

Costos de indisponibilidad

En un informe de 1998 de IBM Global Services , se estimó que los sistemas no disponibles habían costado a las empresas estadounidenses 4.540 millones de dólares en 1996, debido a la pérdida de productividad e ingresos. [27]

Véase también

Notas

  1. ^ Usando365,25 días al año; respectivamente, un cuarto es un ¼ de ese valor (es decir,91,3125 días), y un mes es una doceava parte de él (es decir,30,4375 días). Para mantener la coherencia, todos los tiempos se redondean a dos dígitos decimales.
  2. ^ Véase las coincidencias matemáticas relativas a la base 2 para obtener detalles sobre esta aproximación.
  3. ^ "El doble" en una escala logarítmica, es decir, dos factores de 2: × 2 × 2 < × 5 {\displaystyle \times 2\times 2<\times 5}

Referencias

  1. ^ Robert, Sheldon (abril de 2024). "alta disponibilidad (HA)". Techtarget .
  2. ^ Floyd Piedad, Michael Hawkins (2001). Alta disponibilidad: diseño, técnicas y procesos. Prentice Hall. ISBN 9780130962881.
  3. ^ "Definiciones - ResiliNetsWiki". resilinets.org .
  4. ^ "Archivo web ETHZ / Archivo web ETH". webarchiv.ethz.ch .
  5. ^ Herrero, Pablo; Hutchison, David; Sterbenz, James PG; Schöller, Marcus; Fessi, Ali; Karaliopoulos, Merkouris; Lac, Chidung; Plattner, Bernhard (3 de julio de 2011). "Resiliencia de la red: un enfoque sistemático". Revista de comunicaciones IEEE . 49 (7): 88–97. doi :10.1109/MCOM.2011.5936160. S2CID  10246912 – vía IEEE Xplore.
  6. ^ accesstel (9 de junio de 2022). «resiliencia operativa | empresas de telecomunicaciones | accesstel | riesgo | crisis». accesstel . Consultado el 8 de mayo de 2023 .
  7. ^ "El proyecto CERCES - Centro de Infraestructuras Críticas Resilientes en el Real Instituto Tecnológico KTH". Archivado desde el original el 19 de octubre de 2018 . Consultado el 26 de agosto de 2023 .
  8. ^ Zhao, Peiyue; Dán, György (3 de diciembre de 2018). "Un enfoque de descomposición de Benders para la colocación resiliente de funciones de control de procesos virtuales en nubes de borde móviles". IEEE Transactions on Network and Service Management . 15 (4): 1460–1472. doi :10.1109/TNSM.2018.2873178. S2CID  56594760 – vía IEEE Xplore.
  9. ^ Castet J., Saleh J. "Supervivencia y resiliencia de naves espaciales y redes espaciales: un marco para la caracterización y el análisis", Instituto Americano de Aeronáutica y Astronáutica, Informe Técnico AIAA 2008-7707. Conferencia sobre Protocolos de Red (ICNP 2006), Santa Bárbara, California, EE. UU., noviembre de 2006
  10. ^ Notas de la conferencia de M. Nesterenko, Universidad Estatal de Kent
  11. ^ Introducción al nuevo mainframe: Computación comercial a gran escala Capítulo 5 Disponibilidad Archivado el 4 de marzo de 2016 en Wayback Machine IBM (2006)
  12. ^ Vídeo sobre el valor empresarial de IBM zEnterprise EC12 en youtube.com
  13. ^ Metales preciosos, Volumen 4. Pergamon Press. 1981. pág. 262. ISBN 9780080253695.
  14. ^ PVD para microelectrónica: deposición por pulverización catódica a fabricación de semiconductores . 1998. pág. 387.
  15. ^ Murphy, Niall Richard; Beyer, Betsy; Petoff, Jennifer; Jones, Chris (2016). Ingeniería de confiabilidad del sitio: cómo Google ejecuta los sistemas de producción . pág. 38.
  16. ^ Josh Deprez (23 de abril de 2016). «Nines of Nines». Archivado desde el original el 4 de septiembre de 2016. Consultado el 31 de mayo de 2016 .
  17. ^ Evan L. Marcus, El mito de los nueves
  18. ^ Newman, David; Snyder, Joel; Thayer, Rodney (24 de junio de 2012). "Crying Wolf: False alarms hide attack" (Algo así como el lobo: las falsas alarmas ocultan ataques). Network World . Vol. 19, núm. 25. pág. 60 . Consultado el 15 de marzo de 2019 . lo que provoca caídas y cifras de tiempo de actividad más cercanas a nueve cincos que a cinco nueves.
  19. ^ Metcalfe, Bob (2 de abril de 2001). "Después de 35 años de cruzadas tecnológicas, Bob Metcalfe se marcha hacia el ocaso". ITworld . Consultado el 15 de marzo de 2019 . y cinco nueves (no nueve cincos) de fiabilidad[ enlace muerto permanente ]
  20. ^ Pilgrim, Jim (20 de octubre de 2010). "Goodbye Five 9s". Clearfield, Inc. Recuperado el 15 de marzo de 2019. pero me parece que nos estamos acercando a los 9-5 (55,5555555%) en confiabilidad de la red en lugar de los 5-9
  21. ^ "¿Qué es el tiempo de inactividad de la red?". Redes . Consultado el 27 de diciembre de 2023 .
  22. ^ Ingeniería de confiabilidad y disponibilidad: modelado, análisis y aplicaciones . 2017. ISBN 978-1107099500.
  23. ^ Sostenimiento del sistema: procesos de adquisición e ingeniería para el mantenimiento de sistemas críticos y heredados (Serie científica mundial sobre tecnologías emergentes: serie conmemorativa Avram Bar-cohen) . 2022. ISBN 978-9811256844.
  24. ^ RFC  992
  25. ^ Ulrik Franke, Pontus Johnson, Johan König, Liv Marcks von Würtemberg: Availability of enterprise IT systems – an expert-based Bayesian model, Proc. Cuarto Taller Internacional sobre Calidad y Mantenibilidad del Software (WSQM 2010), Madrid, [1] Archivado el 4 de agosto de 2012 en archive.today
  26. ^ Marcus, Evan; Stern, Hal (2003). Modelos para alta disponibilidad (segunda edición). Indianápolis, IN: John Wiley & Sons. ISBN 0-471-43026-9.
  27. ^ IBM Global Services, Mejorar la disponibilidad de los sistemas , IBM Global Services, 1998, [2] Archivado el 1 de abril de 2011 en Wayback Machine .
  • Notas de clase sobre informática empresarial Archivado el 16 de noviembre de 2013 en Wayback Machine Universidad de Tübingen
  • Apuntes de la clase sobre ingeniería de sistemas integrados del profesor Phil Koopman
  • Calculadora de tiempo de actividad (SLA)
Obtenido de "https://es.wikipedia.org/w/index.php?title=Alta_disponibilidad&oldid=1251742851#Resiliencia"