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]).

Pic: High Availability
Diag. 1: Configuración redundante en failover de una aplicación web estándar.

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 el ya difunto Sun Microsystems; una idea interesante que formaba parte de dicho plan eran los centros de datos portátiles que ofrecía, llamados Blackbox porque se encontraban en un contenedor de carga.

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.
Anuncios