h1

Alta Disponibilidad: Qué es y Cómo se logra

19 agosto, 2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

En el ambiente IT actual, dominado por el paradigma cliente-servidor y las arquitecturas de N-capas, todos los estudios de TCO (Total Cost of Ownership – Costo Total de Propiedad) han mostrado que el TCO de servidores interconectados y estaciones de trabajo es muy alto en comparación con una mainframe centralizada y los thin clients de antaño, siendo la razón principal la baja atención de requerimientos post-liberación, especialmente la disponibilidad.

Durante estas últimas semanas el equipo de trabajo al que pertenezco ha tenido la tarea de diseñar soluciones de alta disponibilidad para nuestros clientes. Esto porque a últimas fechas se han dado cuenta que el tuning & performance de sus servidores y aplicaciones no hace mucho sentido si 1) el diseño de su arquitectura está hecho con los pies y 2) no tienen un plan coherente de administración de sus sistemas una vez que han sido liberados a producción. Sin hacer muy largo el cuento, el detonante de esta nueva asignación es que durante la actualización de firmware de un servidor de base de datos, se volaron la configuración de mirror[1] del mismo, chocolateando la información y perdiendo un 10% de los datos productivos, que vale la pena mencionar, no estaban respaldados. Oooops…

Pues bien, eso aunado al hecho de que terminé de leer el librito High Availability: Design, Techniques, and Processes (Alta Disponibilidad: Diseño, Técnicas y Procesos) de Michael Hawkings y Floyd Piedad, me ha permitido tener una mejor comprensión de este concepto. Dicho libro está algo viejón para los estándares de la industria pues fue publicado en el 2000, pero al menos los conceptos básicos si los tiene y son explicados de forma consistente a lo largo del libro. En resumen, nos cuenta que para alcanzar la alta disponibilidad en nuestros deployments debemos tener lo que el cliente antes mencionado no ha logrado implementar: un buen diseño de arquitectura y un plan de gestión de la solución productiva.

A continuación incluyo un pequeño resumen del libro, que llegué a mostrar a nuestros clientes para crearles conciencia de la necesidad de este tipo de tareas, lo que afortunadamente dio en el clavo.

¿Qué es la disponibilidad?

La disponibilidad es una de las características de las arquitecturas empresariales que mide el grado con el que los recursos del sistema están disponibles para su uso por el usuario final a lo largo de un tiempo dado. Ésta no sólo se relaciona con la prevención de caídas del sistema (también llamadas tiempos fuera de línea, downtime u offline), sino incluso con la percepción de "caída" desde el punto de vista del usuario: cualquier circunstancia que nos impida trabajar productivamente con el sistema – desde tiempos de respuesta prolongados, escasa asistencia técnica o falta de estaciones de trabajo disponibles – es considerada como un factor de baja disponibilidad.

¿Cómo medimos la disponibilidad?

De primera instancia, todo sistema debe tener establecido un Acuerdo de Nivel de Servicio (Service Level Agreement – SLA) que defina cuánto tiempo y en qué horarios debe estar en línea. En el caso de aplicaciones de baja criticidad, dicho SLA puede ser de 8×5 horas a la semana excluyendo días festivos; para sistemas con mayor criticidad como una red de cajeros automáticos se tienen niveles de servicio que alcanzan las 24 horas al día, los 365 días del año. Así entonces, suponiendo un sistema con un SLA de 24×365 podríamos calcular su disponibilidad de la siguiente manera:

Disponibilidad = ((A – B)/A) x 100 por ciento)

Donde:

A = Horas comprometidas de disponibilidad: 24 x 365 = 8,760 Horas/año.

B = Número de horas fuera de línea (Horas de "caída del sistema" durante el tiempo de disponibilidad comprometido). Por ejemplo: 15 horas por falla en un disco; 9 horas por mantenimiento preventivo no planeado.

así entonces:

Disponibilidad = ((8,760 – 24)/8,760) x 100 por ciento) = 99.726%

Cuando se realicen negociaciones para definir objetivos de disponibilidad con los usuarios, es necesario hacerlos concientes de las implicaciones técnicas y económicas, como se muestra en la siguiente tabla:

Disponibilidad (%)

Tiempo offline/año

Tiempo offline/mes

Tiempo offline/día

90%

36.5 días

73 hrs

2.4 hrs

95%

18.3 días

36.5 hrs

1.2 hrs

98%

7.3 días

14.6 hrs

28.8 min

99%

3.7 días

7.3 hrs

14.4 min

99.5%

1.8 días

3.66 hrs

7.22 min

99.9%

8.8 hrs

43.8 min

1.46 min

99.95%

4.4 hrs

21.9 min

43.8 s

99.99%

52.6 min

4.4 min

8.6 s

99.999%

5.26 min

26.3 s

0.86 s

99.9999%

31.5 s

2.62 s

0.08 s

Disponibilidad para un sistema 24×7 y tiempos de caída permitidos.

Estos números (especialmente aquellos que pasan de la marca del 99.5% de disponibilidad) son difíciles de alcanzar, ya que es necesario poder recuperarse ante caídas del sistema de manera transparente. La capacidad e intervalo de tiempo necesarios para recuperarse ante tal eventualidad son directamente dependientes de:

• La complejidad del sistema.
• La severidad del problema.
• La disponibilidad del personal de soporte.
• La madurez en materia de administración del sistema y sus operaciones.
• Otros factores técnicos o de gestión: falta de refacciones, fallas en la cadena de escalamiento, etc.

Alcanzando alta disponibilidad

• Al elaborar un plan eficaz para hacer frente a los retos que disminuyen la disponibilidad de un sistema, primero es necesario comprender el sistema en su conjunto y cómo cada componente afecta la disponibilidad general del mismo.

• Para entonces, es posible identificar los componentes más críticos. Es importante recalcar: no importa cuán insignificante un componente del sistema pueda parecer, es posible que tenga un profundo impacto sobre la disponibilidad general del sistema.

• Una vez que hayan sido identificados los componentes más críticos, se puede buscar la manera de mejorar su confiabilidad, recuperabilidad, capacidad de servicio y administrabilidad.

En la siguiente tabla pueden distinguirse las disciplinas de gestión con el mayor impacto sobre la disponibilidad del sistema: la a menudo descuidada disciplina de la administración de sistemas.

Fase

Disciplina

Descripción

1.Generación de Objetivos

Administración de Niveles de Servicio

Identificar, negociar y acordar los servicios a ser implementados, métricas de calidad y objetivos de desempeño a proporcionar a los usuarios.

2.Planeación

Diseño de Aplicaciones y sistemas

Planear y diseñar infraestructura IT para alcanzar los niveles de servicio comprometidos con el usuario.

 

Planeación de Capacidad

Planeación de requerimientos de crecimiento del sistema.

 

Administración de la Configuración

Crear y mantener información de la configuración del sistema.

 

Administración de activos

Crear y mantener un inventario de activos; rastrear y monitorear dichos activos.

3.Ejecución

Administración de incidencias

Detectar, registrar, resolver incidencias.

 

Respaldo y recuperación

Diseñar sistemas y recursos alternativos para restaurar inmediatamente los servicios IT cuando ocurran problemas.

4.Medición

Administración del Desempeño

Monitorear información de desempeño del sistema; realizar tuning del sistema para alcanzar los niveles de servicio óptimos comprometidos con los usuarios.

5.Control

Administración del Cambio

Controlar todos los cambios en el sistema para asegurar que dichos cambios no degradan el desempeño del sistema.

 

Administración de la seguridad

Controlar y administrar acceso al sistema para minimizar las amenazas a la integridad del mismo.

 

Administración de la disponibilidad

Monitorear y controlar los recursos del sistema y la operación IT para mantener la disponibilidad del sistema.

Las disciplinas pertenecientes a la administración de sistemas.

La administración de sistemas es parte integral de cualquier sistema con alta disponibilidad, y un ingrediente necesario para alcanzar una mayor disponibilidad, pues de acuerdo a ésta:

No hay soluciones técnicas para problemas de gestión, pero puede haber soluciones administradas para problemas técnicos.

Es importante tomar en cuenta que conforme se alcanzan mayores niveles de disponibilidad (arriba del 99.5%) cada vez adquieren mayor importancia los procesos de administración de sistemas e inversamente, influyen en menor grado las técnicas ingenieriles (como tuning & performance, el diseño de la arquitectura o la última generación de hardware de alta disponibilidad).

El aspecto ingenieril de la alta disponibilidad

Aunque la metodología de administración de sistemas se encuentra fuera del alcance de este post, aquí se presentan sencillas técnicas de la ingeniería de sistemas que aseguran que el sistema se desenvolverá de acuerdo a los objetivos marcados. Algunas de ellas son:

Redundancia

La redundancia es una técnica mediante la cual un componente del sistema es duplicado y cualquiera de sus instancias puede ser utilizada en caso de falla. Ya que dos componentes idénticos están en línea, el sistema puede continuar su funcionamiento: no debe existir impacto alguno en la operación si es que esto llegara a ocurrir.

Como ejemplo práctico, en el siguiente diagrama se muestra una aplicación web en configuración de failover: un componente activo o primario siempre atiende las peticiones de los clientes, y en caso de falla, el componente pasivo o secundario entra en acción para procesarlas. Esto aplica tanto para los elementos de software (application server, motor de base de datos) como para los de hardware y almacenamiento (servidores, fuentes de poder, tarjetas de red, arreglo de discos[1]).

Diag. 1: Configuración redundante en failover de una aplicación web estándar.
[Click en imagen para ver en tamaño original]

Adicionalmente se debe considerar que en una configuración redundante debe existir un re-balanceo de la carga de manera automática; asimismo, los componentes deben ser idénticos con el objetivo de lograr que sea transparente para el resto del sistema cuál de los dos elementos está en línea.

Respaldo de recursos críticos

El respaldo (backup) es una técnica donde un componente del sistema – generalmente de software o la información de la base de datos – es duplicado y el respaldo es puesto en reserva o standby, para ser usado en caso de que el componente primario falle. A diferencia de la redundancia, el usuario final puede percibir una caída del sistema; sin embargo, el respaldo se emplea para minimizar el tiempo que toma hacer el cambio hacia el componente de respaldo, reduciendo a su vez el downtime.

Aunque el respaldo de elementos de software – como la información de base de datos, bitácoras o configuración del sistema operativo – es el más común, también existen otros dos tipos de respaldo:

• De componentes de hardware: dependiendo del diseño del sistema, los elementos respaldados son generalmente aquellos con partes mecánicas, manufactura de menor calidad (por ejemplo, equipos ensamblados) o que están sujetos a condiciones ambientales extremas (por ejemplo, en algunos países y regiones el suministro de energía eléctrica no es confiable con apagones y altibajos de voltaje frecuentes; en dichas localidades las fuentes de poder o reguladores de energía tienen un tiempo de vida mucho menor).

• Del personal operativo de IT: Es indispensable contar siempre con más de una persona con los conocimientos críticos necesarios para asegurar que la operación del sistema se lleve a cabo a pesar de la ausencia – o incluso pérdida – de personal clave. Esto se logra mediante manuales de procedimientos claramente definidos y contratos de mantenimiento sobre los componentes del sistema.

En muchas compañías (especialmente aquellas que poseen infraestructura de alto costo o con operaciones que involucren información crítica) es indispensable que los respaldos de hardware, software y personal clave así como los procedimientos de restauración de los mismos estén integrados en un Plan de Recuperación ante Desastres (Disaster Recovery Plan – DRP). Un ejemplo de este tipo de instrumentos – aunque enfocado hacia el hardware – es el Servicio de continuidad de negocio y recuperación ante desastres ofrecido por Sun Microsystems; una idea interesante que forma parte de dicho plan son los centros de datos portátiles que ofrece, llamados Blackbox porque se encuentran en un contenedor de carga (ver aquí o aquí):

Demostración del Blackbox en Monterrey, México.
[Click en la imagen para ver la fuente en sun.com]

Clusterización

En la clusterización, la carga de trabajo es compartida entre múltiples componentes o recursos del sistema redundantes y todos operan al mismo tiempo, actuando conjuntamente como si fueran un único recurso. A diferencia de la redundancia, cada componente procesa una parte de la carga de trabajo; un ejemplo de este tipo de configuraciones a nivel middleware es el Oracle RAC, que permite balancear carga entre los diferentes motores de base de datos, compartiendo un único medio de almacenamiento y redirigiendo las peticiones en caso de caída de alguno de éstos.

Estandarización

La estandarización es el establecimiento de especificaciones para el hardware, software, procedimientos y técnicas que se utilizarán en toda la infraestructura de sistemas. Esta disciplina es a menudo ignorada en favor de dar a los usuarios la libertad de elegir sus propios conjuntos de aplicaciones e interfaces con los demás sistemas de la empresa. Sin embargo, la libertad sin restricciones a menudo conduce al caos y problemas con la administrabilidad del sistema. Por otro lado, cualquier modelo de gestión de calidad (como CMM, Six Sigma o ISO-9000) requiere del establecimiento de un sistema de normas y estándares corporativos.

Conclusiones

En muchos casos, estas técnicas y procesos ya son implementados en la mayoría de los productos y servicios disponibles en el mercado, especialmente aquellos ofrecidos por proveedores de buena reputación[2]. Sólo es cuestión de saber cómo han sido incorporados, y cómo deben ser adaptados al ambiente de sistemas propio, sin embargo es importante recalcar que no importa cuántos recursos se inviertan en soluciones técnicas, éstas serán poco efectivas para prevenir las caídas a menos que también se implementen correctamente las disciplinas de administración de sistemas.

Finalmente, existe una estrategia genérica recomendada para mejorar la disponibilidad de sistemas empresariales:

• Estabilizar el sistema eliminando todos los problemas existentes. Posteriormente, resolver los problemas que ocurren con frecuencia realizando una técnica de análisis de caídas[3]. Estabilizando el sistema permite liberar recursos que pueden ser utilizados para iniciar proyectos de mejora de disponibilidad más avanzados, e incrementar la credibilidad ante los stakeholders para lograr el apoyo necesario para este tipo de soluciones.

• Implementar la administración de sistemas a través de toda la organización IT. Las buenas prácticas de administración de sistemas hacen posible conservar sistemas estables, y previenen nuevos tipos de caídas que pueden ser provocadas al introducir nuevas tecnologías o aplicaciones. Debe comenzarse con la administración de incidencias y luego se debe continuar con la administración del cambio. Después deben enfocarse los esfuerzos en la administración de la seguridad para proteger la integridad de la información ante daños intencionales o accidentales. Las disciplinas de administración de sistemas no necesitan haber sido perfeccionadas para proceder con tareas más avanzadas.

• Deben seleccionarse para mejora de disponibilidad aquellas aplicaciones y subsistemas críticos que impactan la disponibilidad general del sistema en mayor grado.

• Finalmente, deben seleccionase qué técnicas deben implementarse primero, iniciando con la confiabilidad, recuperabilidad, capacidad de servicio y terminando con la administrabilidad. Cuando sea posible, deben implementarse técnicas de disponibilidad enfocadas a mejorar varias características a la vez (por ejemplo el clústering que mejora desempeño y confiabilidad). Las elecciones específicas dependerán de las capacidades de implementación: recursos disponibles, presupuesto y capacidad técnica.

Notas y pies de página

1. La redundancia en los sistemas de almacenamiento se logra a través de configuraciones como la RAID (Redundant Array of Inexpensive Disks – Arreglo Redundante de Discos de Bajo Costo), que combina varios dispositivos de almacenamiento para ser vistos como un solo subsistema. El tipo de implementación RAID del arreglo define cómo la información es almacenada en cada disco, siendo las dos opciones más utilizadas RAID-1 y RAID-5:

• RAID-1 (también denominado mirroring) es la configuración donde efectivamente el almacenamiento se duplica entre los discos del arreglo para mayor disponibilidad, con la desventaja de la disminución en desempeño debido a la duplicidad de la escritura en disco.

• RAID-5 es aquella configuración donde la información y los datos de paridad necesarios para verificar, corregir y recuperar la información en caso de falla son distribuidos entre todas las unidades del arreglo. La principal ventaja de esta última opción es el alto desempeño, aunque se tiene una pequeña disminución de disponibilidad de la información almacenada debido al proceso de recuperación.

2. Sin embargo esta característica aplica principalmente a proveedores de hardware (por ejemplo, Hitachi Data Systems ha ofrecido desde hace casi 10 años soluciones de almacenamiento con 100% de disponibilidad) y proveedores de software que ofrecen productos desarrollados para Unix/Linux, como Oracle o MySQL.

3. El análisis de caídas es esencial para prevenir problemas de disponibilidad. Muchas organizaciones no encuentran las causas de las fallas porque se concentran en atacar los síntomas en vez la verdadera raíz de la caída. El hardware puede fallar, los usuarios pueden equivocarse y el software puede caerse, pero el sistema no necesariamente debe caerse si ha sido diseñado para tolerancia a fallos. Por ejemplo:

Un sistema diseñado para operar 24×7 de pronto se apaga. Ocurrió un apagón hace 30 minutos, y un generador diseñado para operar por dos horas dejó de funcionar por falta de combustible. ¿Cuál es la verdadera causa de la caída del sistema? Muchos pueden opinar que el apagón es el causante. Sin embargo, la raíz del problema es en realidad la falta de combustible para el generador – la persona encargada de verificar los niveles de combustible no lo hizo el día anterior. Una solución podría ser seleccionar un nuevo generador que automáticamente envíe alertas de "nivel bajo de combustible" a los administradores correspondientes.

About these ads

25 comentarios

  1. Si tengo 2 equipos redundantes (como cluster), y cada equipo tiene una disponibilidad de 99.5% ((8760-43)/8760)x100)=99.5%. En teoria al tener redundancia en los dos equipos mi disponibilidad deberia de aumentar, ¿Cuál es la formula para calcular la disponibilidad con equipos redundantes?


  2. Muy buena esa: Para calcular la Alta disponibilidad con equipos redundantes es necesario utilizar la siguiente fórmula:

    Disponibilidad = Disponibilidad Componente 1 + ((1-Disponibilidad Componente 1) x Disponibilidad Componente 2)

    En el ejemplo que me muestras, la disponibilidad sería la siguiente:

    Disponibilidad = 0.995 + ((1-0.995) x 0.995) = 0.999975

    Esto en términos humanos significa que si tu primer equipo se cae el 0.5% del tiempo (o lo que es lo mismo, 1-99.5%), el segundo servidor sólo estará disponible el 99.5% de ese 0.5%. Con redundancia, alcanzas el 99.9975%.Por ello alcanzar la cifra de los 5 9′s es carísima: en tu ejemplo, requerirías 3 equipos de confiabilidad del 99.5% para alcanzar una disponibilidad de 99.999988%


    • Hola Eduardo

      Esto es muy interesante, puedes decirme en donde encontraste esta formula para equipos redundantes

      Saludos

      Benjamin


      • Te soy honesto: ya tiene más de 4 años que obtuve esa fórmula. Creo que la tomé de ese mismo libro, aunque he encontrado otros ejemplos en la web como el que se proporciona en este ejemplo.


  3. Excelente, muchas gracias


  4. como puedes calificar un equipo con disponibilidad alta? si el equipo opera bajo una disponibilidad de 70% se dice que es una disponibilidad baja?


    • La alta o baja disponibilidad es muy relativa, por lo que depende mucho de la criticidad del sistema. La mejor manera de decidir si tiene o no una baja disponibilidad es considerar cuánto tiempo al día puedes permitirte que esté fuera de línea:

      Para un sistema de baja criticidad como una página con políticas de recursos humanos no debe ser mucho problema una disponibilidad del 70% (7 horas offline al día); en términos generales esto es considerado bajo, pero depende de qué tanto “le pega a la operación” que la página no pueda ser consultada.

      Para un sistema de cajeros electrónicos es importante tener una disponibilidad que ronda el 98-99% (de 15 a 30 minutos fuera de línea al día) por lo que dependiendo de a quíen le preguntes, ese porcentaje puede considerarse mediano o alto.

      Finalmente, para un sistema de defensa (NORAD) donde segundos “volando a ciegas” pueden significar la destrucción del mundo, o un sistema de alta transaccionalidad (NASDAQ) donde un milisegundo abajo significa cientos de millones de dólares perdidos, no puedes permitir nada menos del 99.9999% de disponibilidad (0.08 segundos al día).


      • mi pregunta es basada en base a compresores y turbinas que se encargan de transportar gas natural a una planta de extracción de líquidos, estos trabajan 24 horas al día por un periodo de 2928 horas que es igual a 122 días. por eso pregunto que si mi disponibilidad del equipo debe manejarse por encima del 90% calificándola como buena? y si esta por debajo calificándola como critica?


      • Una disponibilidad de 90% no está mal, siempre y cuando el tiempo fuera no impacte demasiado en tu operación. Para saber mejor la calificación de tu disponibilidad deberías poder contestar las siguientes preguntas:

        ¿Cuánto se pierde en $ por cada minuto que esos compresores estén fuera de línea? ¿Cuánto $ al día/mes está dispuesto a perder la gerencia debido a tiempos offline?
        ¿Existe algún riesgo si estos compresores están fuera de línea? Por ejemplo, que se dé un aumento en la presión que pueda resultar en una explosión
        ¿La alta gerencia estaría dispuesta a comprar el doble de generadores/turbinas para asegurar una disponibilidad de 99.9999%?

        Dependiendo de esas respuestas, puedes quedarte con ese 90% y calificarlo como “bueno”, pero no “excelente”.


      • MUCHAS GRACIAS!!! lo tendré en cuenta!!! agradecida por la ayuda


  5. Estimado; me podrias aclarar los siguientes conceptos y la vez cómo calcularlos ???

    1.Disponibilidad Ajustada.

    2.Factor de Uso.

    Es un exelente blog…Gracias !!!

    Víctor


    • 1. Existen dos tipos de disponibilidad: la ideal o predecida y la ajustada u operacional. La ideal es la que calculamos considerando caidas en el servicio planeadas (por ejemplo, mantenimiento de ruteadores que impactarán en 2 horas el sistema). La ajustada es aquella en la que debemos considerar caidas no planeadas (por ejemplo, una fuente de poder que se “murió” y tomó 1 hora para que el sistema se recuperara) y se calcula al final del periodo. Así, la disponibilidad para una semana quedaría así:

      - Disponibilidad ideal o predecida: (24×7) – 2 = 166 horas o un ideal de 100%
      - Disponibilidad ajustada: 166 – 1 = 165 horas o una disponibilidad ajustada de 165/166 = 99.39%

      2. Tienes cinco usuarios que navegan por tu pagina web y cada uno se queda en tu pagina por un tiempo determinado (en minutos): L1 = 15, L2 = 12, L3 = 10, L4 = 10, L5 = 12. Estos tiempos los obtuviste al revisar los logs de tu pagina por 25 minutos. Así, tu Factor de Uso es la sumatoria de los tiempos individuales de uso entre el periodo de muestreo: UF = (15+12+10+10+12)/25 = 2.36. En realidad, el factor de uso es una métrica muy básica para determinar cuántos usuarios concurrentes tienes en tu sistema en un momento dado; en este caso (redondeando) son 3. Esto lo explico a mayor detalle en otro post de este mismo blog: Estimando usuarios concurrentes.


      • Te pasaste…gracias por tu tiempo y la generosidad en compartir tus conocimentos !!!

        Atte.
        Víctor


  6. Buenas tardes, me podrias colaborar con la siguiente inquietud:
    Como se calcula la disponibilidad en un sistema con redundancia (N+X), en el Gold Book hay una formula de una sumatoria pero al aplicarla da resultados no coherentes, es decir, a medida que aumento el numero de equipos en redundancia disminuye la disponibilidad del sistema.

    Mil gracias, buen blog


    • Tendría que ver la fórmula en cuestión, pero creo que la fórmula a la que te refieres es relacionada a la disponibilidad paralela:

      Disp Paralela = 1 – [Multiplica: 1 a n (1 - disponibilidad(i)]

      Que en caso de tres componentes con disponibilidad individual de 0.95, 0.90 y 0.85 quedaría como algo así:

      Disp = 1 – (1 – 0.95) * (1 – 0.90) * (1 – 0.85) = 0.99925 o una disponibilidad de 99.925%


      • Buenos días,
        Gracias por la respuesta,

        La formula en cuestión es:
        R(t)= Σ (k=m,n,(n!/k!*(n-k)!)*(exp(-(λk))^k)*((1-exp(-(λk))^(n-k))
        en donde:
        n: es el número total de componentes.
        m: es el número de componentes requeridos.
        λ: es el numero de fallas por periodo de tiempo (año), es decir;
        λ=1/MTBF

        Para el caso que estoy trabajando se requieren 3 generadores eléctricos en paralelo para lograr la potencia requerida, adicional a estos tenemos un generador, también en paralelo, como backup para un total de 4 equipos, esto es un sistema N+1 con N=3, cada uno de los generadores por si mismo tiene una disponibilidad propia (ejemplo 0.99).

        Al aplicar esta fórmula se supondría que al aumentar el número de generadores de backup, para el mismo número de generadores funcionando, aumentaría la disponibilidad pero el resultado que arroja es al contrario.

        Cordial saludo,


  7. Hola, recien me encontré con tu blog y se me hace muy interesante. Ojalá me puedas ayudar.
    Estoy trabajando en calcular la disponibilidad de los sistemas en una empresa con varias fábricas de producción. Después, se comparan los resultados entre las fábricas.
    Apliqué tu formula de Disponibilidad = ((A – B)/A) x 100 por ciento)

    Ésta formula me da resultados que considero son muy buenos, sin embargo, cuando los comparo, no es muy real por lo siguiente:

    *Tengo 3 Fábricas.
    *Cada fábrica tiene diferentes sistemas, pero solo 5 de ellos son afines.

    Mi idea es lograr saber los siguientes indicadores:
    1. Porcentaje de disponibilidad de todos los sistemas.

    Ya recibo un reporte mensual de todos los tiempos de solucion de fallas de todos los sistemas y es con ese que apliqué la formula que muestras. Me di cuenta que daba más información si la aplicaba dia a dia que por todo el mes.

    Sin embargo me he topado con los siguientes problemas:
    1. Las fábricas no tienen los mismos sistemas, algunas tienen más sistemas, lo cual implica mayor cantidad de incidentes y otras tienen menos, por lo cual no es facil compararlas.

    2. El tiempo que estoy tomando es acumulado, por lo que tampoco creo que sea lo mejor. Por ejemplo:
    Incidente 1:
    Formateo de PC. Tiempo 5 hrs.

    Incidente 1:
    Reparación de impresora. Tiempo 1.30 hrs.

    Indicente 2:
    Reparación de un sistema. Tiempo 2.30 hrs.

    Indicente 3:
    Problemas con un Servidor. Tiempo 20 min.

    En este ejemplo, yo estoy tomando el acumulado que serían 8.20 horas por lo que con tu formula me da lo siguiente:

    Disponibilidad = ((A – B)/A) x 100 por ciento)
    Calculandolo por día:
    ((24-8.20)/24)x100=65.833333

    Segun esto, la disponibilidad es de 65%

    Sin embargo, el problema es que es acumulativo. Hay alguna forma de que se pueda obtener un mejor resultado tomando en cuenta los diferentes sistemas?

    He pensado en aplicar criticidades y porcentaje en base a esto. Es decir, no es lo mismo que una PC de una persona se haya dañado, pues no es grande el impacto para mi producción, como el que un servidor se haya dañado. El servidor me puede hacer perder producción mientras la PC no.

    ¿Que me recomiendas?
    ¿es posible comparar entre fábricas los resultados?

    Muchas gracias por tu tiempo y apoyo.


    • Hola. Perdón por la tardanza pero he estado fuera durante el fin de semana. Resolviendo tu duda:

      A las fórmulas de este post se les utiliza en el cálculo de disponibilidad para sistemas con diversos componentes cuya confiabilidad individual afecta la disponibilidad del sistema principal. Es decir, la fórmula que estás aplicando sólo tendría sentido si por el fallo de la PC o la impresora, corres riesgo de que se detenga TODA la producción, en cuyo caso deberías tener impresoras, sistemas y PCs de respaldo. Si un empleador o cliente te está imponiendo un SLA con disponibilidad para todos los aparatos y dispositivos de la “fábrica” en su conjunto, con todo respeto, te está chamaqueando.

      Lo más recomendable es que calcules la disponibilidad de cada componente por separado: usando el ejemplo de la PC que se tuvo que formatear, supongo que se le usa por 8 horas al día en horario y semana laboral (= 8 x 21 = 168 horas/mes). Al haberse dañado, su disponibilidad será de ((168-5)/168)x100 = 97.02%. Siguiendo el mismo ejemplo, el servidor debería tener otros requerimientos diferentes de disponibilidad, por lo que ese en teoría debería ser 7×24 (= 720 horas al mes = 43200 minutos). Su disponibilidad después de esos 20 minutos abajo debería ser de ((43200-20)/43200)x100 = 99.95%, lo que no está mal, a menos que sea un servidor crítico para la operación.

      Y ya llegando al tema de las 3 fábricas: sólo puedes comparar peras con peras y manzanas con manzanas. Es decir, tendrás que comparar la disponibilidad de sistemas equivalentes (no afines, pues no es lo mismo): impresoras láser con impresoras láser; PCs con PCs; servidores web o de bases de datos con sus respectivos equivalentes de las demás fábricas siempre y cuando, tengan exactamente las mismas características de hardware y software.


  8. saludos, primero este es un gran bloq, mi preguat es la siguiente, estoy realizando de tesis la implementacion de un cluster de alta disponibilidad en una universidad y necesito obtener indicadores para poder medirlos, si me pudieran ayudar seria genial,basicamente quisiera saber que puedo y como puedo medir para mejor un servidor web


    • Tu mejor opción es Apache HTTP server montado en Linux. Los detalles de la implementación dependerán de la versión del web server así como del sistema operativo, pero un buen ejemplo se encuentra en esta liga. La medición de disponibilidad dependerá entre otras cosas, de la carga máxima de usuarios concurrentes que puede aguantar cada web server de forma individual. Esto tendrás que obtenerlo experimentalmente, ya que dicha carga depende completamente de las características del hardware. Así puedes calcular cuál sería la disponibilidad de cada servidor y de todo el conjunto de servidores en forma de clúster.


      • En mi proyecto de tesis estoy proponiendo:
        - Reducir la cantidad de horas fuera de línea del sistema
        - Aumentar la cantidad de horas disponibles del sistema
        - Aumentar el tiempo de respuesta del servidor
        y según lo que encontré en tesis similares ellos calculan con las siguientes formulas:
        TiempoFueradeLinea=(SumatorioHoraporDiaFueradeLinea)/NumerototaldeHorasFueradeLinea
        TiempoDisponible=(SumatoriadeHorasporDiaDisponible)/numerototaldeHorasDisponible

        podrian ayudarme con las formulas para estimar los objetivos planteados?


  9. Que solucion recomiendas para mantener la alta disponibilidad en un negocio de servicios electronicos o banco, en donde se busca que el cliente tenga su estado de cuenta al instante y siempre disponible, asi como sus reporteos de movimientos detallados, el flujo de informacion tiene un promedio de 10 transacciones por Segundo, obviamente se busca tener el 99.99 % de disponibilidad con el mejor desempeno posible …


    • En términos de hardware, todo debe ser redundante: discos, tarjetas de red, memoria. El enlace de red debe estar duplicado también – tal vez incluso con diferente proveedor – y el site debe tener UPSs redundantes. En un par de trabajos que he tenido, la compañía tiene su propia subestación de energía eléctrica alimentada por diesel. Todo debe correr en un sistema robusto (Linux o Unix) con software que pueda hacer un fail-over de forma rápida. La configuración “activo-activo” de los balanceadores de carga y web servers es la mejor, ya que no es necesario “prender” ningún dispositivo o iniciar ningún “ejecutable” en caso de fallo.

      Sin embargo, todo esto son recomendaciones muy generales. Puede que también te interese ver el artículo en este mismo blog relacionado a encontrar los usuarios concurrentes de un sistema, para dimensionar el tipo y número de servidores que necesitarás.

      El software, middleware, bases de datos y aplicaciones dependen puntualmente de tu aplicación, aunque en la mayoría de los casos, el software opensource te puede ayudar con los costos, a menos que quieras “matar los problemas a billetazos”.


  10. Buenos Días! Leyendo el post anterior, si se quisiera calcular la disponibidad total de servicio de un cajero automático de un banco…por ejemplo, se deberían de multiplicar todas las disponibilidades de los subsistemas (energía, plataformas de redes, plaaformas de TI y la del cajero en si mismo) para obterner el resultado global cierto?


    • Así es. Mientras más factores se introducen en la ecuación, más fiable es el cálculo de disponibilidad.



Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 27 seguidores

%d personas les gusta esto: