Siempre que un español habla de algo, pierde valor y no tiene sentido, es una chapuza de salida. Si, por el contrario, repite lo que dice un extranjero, la cosa cambia. Voy a citar y resumir un artículo de otro.  En mis clases, he explicado mil veces estos conceptos antes de encontrar este artículo interesantísimo.

Apliquemos pues Itil a Exchange 2013.

DAG, Database Availability Group, este el concepto de salida. Por este motivo, la unidad de Availability es la base de datos, NO el servidor. Es la base de datos la que puede fallar, que puede o bien fallar o cambiarse, moverse, entre varios servidores dentro de un DAG.

Los servidores que forman un cluster para un failover, al trabajar juntos, en un DAG, lo llamaremos grupos.

Tomando disponibilidad como lo relatado en ITIL, tomamos disponibilidad de un servicio o componente como el asegurar que los servicios TI estén disponibles y funcionen correctamente siempre que los clientes y usuarios deseen hacer uso de ellos en el marco de los SLAs en vigor.

Dentro de una formulación cuantificable, entendemos que disponibilidad, primero, la disponibilidad es el tiempo en el que un servicio o componente se encuentra en funcionamiento. Segundo, el intervalo, ratio, de tiempo que un componente está disponible en relación al intervalo en el que se mide tal disponibilidad.

Así es como aparece, ese ratio, en las SLAS. Normalmente se mide la cantidad de tiempo en el que un sistema está disponible, uptime, tiempo de actividad, durante un período de representación estadística, normalmente un año.

Para contar el tiempo de actividad, uptime, podemos usar el MTBF, tiempo medio entre fallos, y el tiempo medio de reparación o MTTR.

El MTBF mide la disponibilidad entre fallos y el segundo lo que dura la inactividad durante un fallo cualquiera.

Podemos expresar, pues, la disponibilidad (A) como:

Y la probabilidad de fallos, no-disponibilidad:

Combinando todos estos conceptos solemos aceptar la siguiente tabla indicativa:

Para poder encontrar la disponibilidad en cada entorno, tenemos que volver a las SLAs, a la negociación de esa disponibilidad y eso dependerá de los procesos del negocio y los servicios IT que lo sustentan. La disponibilidad de esos procesos de negocios es lo que hace de palanca para definir la disponibilidad del servicio y sus componentes.

Dependencias

Entendemos que “componentes” son el conjunto de elementos que pueden afectar a la disponibilidad de un servicio. Esos componentes, en relación a Exchange 2013, son el subsistema de almacenamiento, el servidor dónde se ejecuta esa base de datos, la red, etc. Si uno de esos componentes falla compromete a todo los demás relacionados con Exchange.

Si hablamos de bases de datos de Exchange, en cuanto a la disponibilidad, hablamos de la disponibilidad de todos los componentes, de las dependencias, por lo que tenemos que asegurar la disponibilidad de todos ellos.

En relación a las bases de datos de Exchange en los mail box tenemos:

1. Subsistema de almacenamiento y discos
2. Servidor de Mailbox
3. El CAS
4. Conexión de red entre clientes y CAS, CAS entre MBX
5. Luz eléctrica en el CPD

Cinco niveles de componentes críticos que, de fallar uno, compromete a los demás.

La lista puede continuar hasta N componentes. No puede fallar el AD, los servidores de certificados, ….

El poner en valor cuantos más nodos de dependencias, menor es la disponibilidad  prevista.

Redundancia y disponibilidad

Llegados a este momento, tenemos que estudiar la redundancia y su relación con la disponibilidad. Está claro que un componente, como un único punto de fallo, redundándolo, supone el reducir la indisponibilidad.

Esos componentes, n, presentes en un servicio, tienen una probabilidad de fallo, que hemos elaborado o buscado, en el anterior apartado.

La probabilidad de fallo de todos ellos sería la multiplicación de las probabilidades de fallo de todos ellos.

Si la probabilidad cae, crece la disponibilidad:

Vamos a coger un disco SATA para almacenar una base de datos de MBX. Un disco SATA tiene un 5% de fallo, según los estándares admitidos, o sea, un 95% de A.

A más redundancia más disponibilidad. Parece obvio.

Traducir esto a Exchange 2013

Nos quedaría esto, por ejemplo:

Primero, más sistemas, cae la disponibilidad, más redundancia, incrementa la disponibilidad. Por lo tanto, más servidores, incrementa la disponibilidad.

Conclusión: Ojala la vida sea tan fácil. Pero eso es el segundo post sobre el tema.