Conciencia Colectiva en Tecnología y Algo Más: El dilema de eso que significa contar con "alta disponibilidad" ennuestras arquitecturas de tecnología (parte 2 de 3)

Una vez que ya sabemos como realizar el cálculo de disponibilidad de cada equipo individual, tenemos que contestar a la pregunta siguiente: ¿Cuál entonces será el SLA que tiene la red en su conjunto?. Para ello, nos ayudaremos de la figura siguiente.

Para realizar el cálculo de SLAs de la red, se deben definir diferentes escenarios de los cuales se requiere conocer el SLA probable, no es posible simplemente calcular un SLA para toda la red. Los escenarios mostrados en la figura anterior, son los que utilizaremos para el cálculo de SLAs.

Ejemplo 4: Empezaremos con el cálculo del SLA para el escenario de comunicación entre un par de sitios de la red WAN. Para calcular la disponibilidad de la comunicación entre la PC A y el servidor B, requerimos en primer lugar, calcular la disponibilidad de cada elemento que se encuentre en la trayectoria de esta comunicación (switch, ruteador del sitio remoto, ruteador del sitio central, switch de core del sitio central, switch de server farm) como se explicó en la primera parte de este artículo. Es común, no poner atención a que hay un elemento muy importante en este escenario, el SLA del enlace WAN pactado con el carrier. Una vez que tenemos todos los elementos que forman parte de este escenario, para calcular el SLA, la trayectoria de comunicación debe ser tratada como elementos en serie, y utilizar el cálculo descrito en la primera parte de este artículo como sigue.

Disponibilidad del escenario (%) = disponibilidad switch * disponibilidad ruteador remoto * disponibilidad enlace WAN * disponibilidad ruteador central * disponibilidad switch core * disponibilidad switch server farm

Nota.- Nótese que para este ejemplo no contemplamos la disponibilidad propia de los elementos terminales (PC y servidor), en caso que el lector lo considere, deber adicionarlos dentro de cálculo respectivo.

Ejemplo 5: Para el escenario siguiente, tratará de la disponibilidad o SLA en la comunicación de una extensión telefónica (teléfono IP) a la red pública (PSTN), el cálculo de disponibilidad deberá realizarse como sigue:

Disponibilidad del escenario (%) = disponibilidad del teléfono IP * disponibilidad del switch de acceso * disponibilidad del switch de core * disponibilidad del gateway de voz * disponibilidad del enlace de telefonía (troncal analógica o digital)

Vamos ahora a llevar a cabo el cálculo de disponibilidad de un escenario de un servicio de Cloud Computing que tengamos contratado, para fines de este ejemplo, se tratará de un servicio de comunicaciones unificadas (servicio de voz y aplicaciones), mostrado en la siguiente figura.

Ejemplo 6: Si el proveedor de servicios (service provider) de comunicaciones unificadas (UCaaS, Unified Communications as a Service) que tenemos contratado, nos ofreciera un SLA de su nube hasta el equipo de demarcación que éste colocará en el sitio al que se conecta de nuestra red, mediante un ruteador (equipo CPE) propiedad de él, de 99.998%; y nosotros como responsables de la TI interna realizáramos las adecuaciones necesarias en la red LAN que es nuestra responsabilidad, para contar con SLA en ella de 99.99%, ¿cuál sería el SLA del servicio a comprometer con el usuario del videoteléfono ejemplificado en el diagrama?. El cálculo de este escenario, contempla calcular la disponibilidad o SLA de cada elemento individual (switch de acceso al que esta conectado el videoteléfono, el switch de core y el videoteléfono mismo cuya disponibilidad pensemos que sea 99.97%) y posteriormente, realizar el cálculo como elementos en serie en toda la trayectoria previa al ruteador del proveedor, para finalmente considerar el SLA del proveedor de servicios de comunicaciones unificadas en la nube como un solo elemento en serie como sigue:

Disponibilidad de la red LAN (%) = disponibilidad del switch de acceso * disponibilidad switch core

Disponibilidad del servicio de comunicaciones unificadas (%) = disponibilidad de la red LAN * disponibilidad del videoteléfono * disponibilidad proveedor de UCaaS

Disponibilidad del servicio de comunicaciones unificadas (%) = 0.9999 * 0.9997 * 0.99998 = 99.95%

Tercera Conclusión: "Al ser elementos en serie, la disponibilidad del servicio extremo a extremo en un servicio de Cloud Computing, depende directamente de la disponibilidad interna de los elementos de no formen parte del control del carrier y son responsabilidad de la TI".

En este punto, ya tenemos las bases para realizar un cálculo de disponibilidad de acuerdo a los componentes o equipos que se tengan y de las redundancias respectivas en cada elemento que compone a cada equipo individual.

¿Restaría considerar algún componente más?, la respuesta es SI. Primero, nos falta considerar la disponibilidad asociada a todos los componentes habilitadores de la red tales como cableado, respaldo de energía (UPS), circuitos eléctricos, etc. Cada componente cuenta como un elemento más en serie para el cálculo total de disponibilidad o SLA del escenario que nos encontremos evaluando. A pesar de ello, es literalmente casi imposible calcular la disponibilidad de cada uno de estos componentes de "capa física", así que para fines prácticos, estos no son considerados para el cálculo respectivo.

Segundo, hemos platicado extensamente de la disponibilidad de cada componente de la red en términos de hardware, enlaces o proveedores de servicios y componentes habilitadores o de capa física. Aunque ya cuentan con bastante robustez para el cálculo de disponibilidad o SLA los componentes contemplados, todo equipo de comunicaciones esta formado también por elementos de software (el sistema operativo de cada equipo y firmware en algunos casos más) y al presentarse bugs o corrupciones, provocarán la caída del hardware y por tanto cuentan como elementos en serie aunque no se pueda tener un MTBF tangible. Por ello, la disponibilidad del sistema operativo y firmware, debe contar como elementos en serie para el cálculo de disponibilidad de cada equipo individual. Al igual que el cálculo de disponibilidad de los componentes habilitadores de red, es muy difícil calcularlo al ser solo el fabricante el que cuente con valores de MTBF de su software derivados de estadísticas llevadas a cabo y documentadas por medio de sus centros de asistencia técnica (conocidos como TAC, Technical Assistant Center).

Ahora, ¿para que requerimos la red?, principalmente, para que sobre ella, "corran" las aplicaciones de negocio. Por tanto, las aplicaciones también tienen su SLA que debe ser considerado en el cálculo de disponibilidad para conocer como impacta el SLA hacia los usuarios de dichas aplicaciones, cuando se este calculando el SLA de ellas. Como en el caso del sistema operativo, es muy difícil (casi imposible), calcular el SLA por este concepto, así que lo omitiremos.

Brevemente, describiré algunas prácticas a considerar para contribuir en incrementar la disponibilidad o SLA de una arquitectura de tecnología:

Preferir imágenes de sistema operativo estables vs imágenes nuevas o en espera de retroalimentación de hallazgos en operación por parte de los clientes (cada fabricante califica a sus imágenes de sistema operativo regularmente en 3 niveles: nueva imagen, imagen con parches e imagen completamente probada y parchada sin nuevos hallazgos).
Recomendaciones básicas de redundancia de componentes en cada equipo:

Enlaces redundantes entre capas
Considerar redundancia de fuentes de alimentación
Considerar redundancia en supervisoras o routing engines
Considerar redundancia en linecards que conectan equipos entre capas de la red LAN (acceso, distribución y core) y la red del DataCenter.
Considerar habilitar virtualización de chasis en la capa de distribución o core de la red LAN y en la capa de core del DataCenter.
Considerar redundancia en el backplane de los switches de core de la red LAN y el core del DataCenter.
Considerar redundancia en aplicaciones virtualizadas en cómputo diferente (blades o servers).

Considerar respaldo de energía independiente para las fuentes principal y de respaldo de los equipos.
Considerar redundancia en los circuitos eléctricos para las fuentes principal y de respaldo de los equipos.
Considerar trayectorias de fibra óptica independientes para las conexión entre capas de la red LAN y la red del DataCenter.

Quisiera terminar los diferentes cálculos de alta disponibilidad que hemos venido haciendo con una reflexión, hay diferentes nivel de redundancia en los diferentes elementos que componen un equipo de comunicaciones, que pueden ser denominados con la nomenclatura 1+1, N+1, N+M, etc. ¿qué significan? el número posterior al signo de "+" indica cuando elementos redundantes se pueden colocar como redundancia a cada elemento principal, es decir, 1+1 indica que por cada elemento principal, habrá uno más redundante. Una redundancia 2+1, indica que por cada 2 elementos principales, existe un solo elemento como redundancia a ambos, etc. ¿Qué arreglo da una mayor disponibilidad (1+1 o 2+1)?, hagamos el cálculo.

Suponiendo que tenemos fuentes de alimentación con disponibilidad de 99.97% cada una de ellas, si tuviésemos un equipo que maneje redundancia 1+1, ¿cuál sería la disponibilidad de las fuentes de alimentación?. Para ello, hacemos uso del cálculo de elementos en paralelo que se detalla en la primera parte de este artículo, de la siguiente manera:

Disponibilidad fuentes en arreglo 1+1 (%) = 1 - [(1-0.9997)*(1-0.9997)] = 99.999%

Si ahora contáramos con un equipo que requiere para operar 2 fuentes de alimentación y cuenta con 1 más como redundancia (2+1) con las mismas disponibilidad individuales, la disponibilidad del arreglo de fuentes sería:

Disponibilidad de 1 fuente activa y su redundancia (elementos en paralelo) = 1 - [(1-0.9997)*(1-0.9997)]
Disponibilidad de 1 fuente activa y su redundancia (elementos en paralelo) = 99.999%

Disponibilidad fuentes en arreglo 2+1 (%) = disponibilidad de fuentes 1+1 * disponibilidad fuente
Disponibilidad fuentes en arreglo 2+1 (%) = 0.99999 * 0.9997 = 99.96%

Cuarta Conclusión: "Cuentan con mayor disponibilidad, los esquemas de redundancia 1+N (donde N es igual o mayor a 1) que los esquemas de redundancia N+1".

La alta disponibilidad como puede verse, esta en función de la cantidad de elementos en paralelo para con ello, lograr que la disponibilidad en serie nos lleve a un alto SLA o tendiente a los famosos cinco 9s. Sin embargo, el precio es un excelente indicador que puede decirnos cuanta redundancia es suficiente para un equipo o un escenario, basado en los objetivos de negocio que deberemos cumplir en último fin. La gráfica siguiente que llamo de "costo-beneficio de disponibilidad" ilustra lo anterior.

Ya sabiendo todo lo que hemos comentado, ¿Cuánta disponibilidad es la correcta de acuerdo a nuestro negocio?, el que podamos pagarla es un indicador como he indicado, pero lo que realmente nos da un segundo y el mas importante indicador al respecto desde mi punto de vista, es las afectaciones visibles hacia el exterior por una indisponibilidad, y como es inevitable en esos casos, cuando ocurre todo mundo se da cuenta. ¿A qué me refiero?, lo contestaré con preguntas, ¿cuánto representa en una mala imagen al cliente que el servicio de cobro mediante tarjetas de crédito no funcione el fin de semana de una venta especial para una tienda departamental?, ¿Cuantas cancelaciones de líneas móviles puede representar una intermitencia en el servicio de un operador de telefonía móvil?, ¿Qué sucedería si el sistema de declaraciones anuales, se encuentra indisponible en la última semana de recepción de este trámite?, ¿me explico?, la afectación a la imagen, los clientes y la ciudadanía en la general nos darán una idea para evitar caer en la tentación de ahorrarnos unos miles al inicio, que nos pueden costar millones en la operación cotidiana.

¿Pero qué creen?, de acuerdo a un estudio llevado a cabo por Gartner en 2007 y aún vigente, menciona que la principal razón por la cual una red de comunicaciones falla o "se cae" es por errores del personal de operación y soporte al momento de realizar alguna actividad de mantenimiento. ¿Cuál es la razón?, lo de "siempre", por no contar con un plan definido y previamente revisado y aprobado de cambios, por la inexistencia de un plan de contingencia por si algo no sale como se planeo, por no contar con bitácoras que nos indiquen quién hizo qué y cuando en cada equipo, por no llevar documentada toda la operación de la red, etc, etc, etc.. La lista es interminable. La siguiente figura lo muestra.