Es común
escuchar de nuestros clientes solicitarnos que consideremos en la propuesta a
desarrollar un diseño o arquitectura tecnológica con "alta
disponibilidad", con sus "redundancias" o "carrier
class", al estar con ellos tomando algún requerimiento de una nueva
solución o una mejora a una solución ya existente. Sin embargo, la famosa frase
de "alta disponibilidad" dista mucho de ser un feature o licencia más
a agregar en el desglose de números de parte o BOM (Bill of Material) de la
solución a proponerles. De hecho, el término en cuestión, es en mi personal
punto de vista, uno de los aspectos de los cuales se habla mucho en el entorno
de tecnología en general y del que menos se conoce al respecto en toda la
amplitud del tema tanto por fabricantes, como por diseñadores, arquitectos de
tecnología o clientes.
Este pequeño artículo, intenta dar una breve
introducción al tema y ayudar al lector a tener un entendimiento sólido de las
implicaciones que se derivan de hablar de una solución tecnológica con alta disponibilidad.
Si les parece, lo mejor es iniciar
distinguiendo la diferencia entre disponibilidad de la solución y
redundancia. La disponibilidad es un
valor cuantitativo que nos indica la cantidad de tiempo que un elemento de red
(equipo) o la red en sí misma, se encontrará funcionando de manera normal, es
decir, sin falla alguna. La disponibilidad se mide regularmente de manera
porcentual en cifras mayores al 95%. Ejemplos: 99.98%, 99.99%, 99.999%, etc.
Entre mayor sea este valor, menos probable es que el elemento o la red se
encuentren en un estado de indisponibilidad o dicho de otra manera, se cuente
con una "alta disponibilidad" (HA, High Availability). La mayor
disponibilidad ampliamente empleada para un elemento o la red en sí misma, son
los llamados cinco 9s o 99.999%.
Estos porcentajes cercanos al 100% son los que comúnmente se utilizan para firmar acuerdos de niveles de servicio entre los proveedores de servicios y los clientes (conocidos como SLAs, Service Level Agreement).
Estos porcentajes cercanos al 100% son los que comúnmente se utilizan para firmar acuerdos de niveles de servicio entre los proveedores de servicios y los clientes (conocidos como SLAs, Service Level Agreement).
Otro forma de expresar los valores
porcentuales anteriores, es trasladarlos a cifras de tiempo anualizadas, es
decir, ¿cuánto tiempo de indisponibilidad tendrá como máximo un equipo o la red
en sí, que cuente por ejemplo con una disponibilidad de 99.99% o cuatro 9s? La
respuesta la obtenemos calculando la cantidad de minutos año (60x24x365 = 525,960
minutos al año) y aplicando el porcentaje de indisponibilidad (100%-99.99% o 1-disponibilidad)
con lo cual obtenemos que un elemento/equipo o la red en sí tendrá a lo más 52.59
minutos de indisponibilidad (downtime) al año.
Si llevamos a cabo el mismo cálculo para un
elemento o red con cinco 9s o 99.999%, tenemos que no debe encontrarse más de 5
minutos indisponible (caído o downtime) en el lapso de 1 año. Resumiendo la
relación entre dos o más 9s vs el tiempo máximo permisible de downtime al año,
tendremos:
Disponibilidad
|
Downtime Máximo al Año
(minutos)
|
99%
|
5259
|
99.9%
|
525
|
99.99%
|
52
|
99.999%
|
5
|
El método empleado para el cálculo de
disponibilidad, es el conocido como método de porcentajes y es el más empleado
en el ámbito de telecom, sin embargo no es único, existe un método adicional
conocido como método de defectos por millón (DPM, defects per million). En este
artículo nos enfocaremos al primer método únicamente.
Aclaremos ahora el concepto de “redundancia”.
La redundancia de una solución, está asociada a la adición de elementos dentro
de la arquitectura propuesta que nos permitan cumplir la disponibilidad
solicitada u objetivo (a través de considerar elementos adicionales a los
principales o los elementos mínimos para que un equipo o arquitectura opere).
Para lograr una cierta disponibilidad
objetivo (solicitada), se deben tomar en cuenta todos aquellos aspectos que
influyen en el cumplimiento de la misma ya que hay varias consideraciones que
tomar en al menos las siguientes áreas de influencia:
·
La
topología de la arquitectura a proponer.
·
La
redundancia de elementos (hardware) en los dispositivos de red.
·
Los
mecanismos de alta disponibilidad a habilitar en los dispositivos a proponer.
·
Los
mecanismos de seguridad a implementar.
·
La
definición de niveles de administración por usuario y políticas asociadas.
·
La
redundancia considerada en los elementos de soporte a la red (UPS, cableado,
circuitos eléctricos, etc.).
·
Las
estabilidad (o ausencia de bugs) en los sistemas operativos de cada uno de los
elementos de la arquitectura propuesta.
Cada uno de los aspectos anteriores, los
detallaré a continuación.
La topología y su
influencia en la disponibilidad de red
Empecemos primero, por analizar la topología
de red asociada a las diferentes soluciones tecnológicas (LAN, WAN, DC, etc.).
Para ello, nos apoyaremos de la siguiente figura (cuyos círculos llamaremos
indistintamente vértices, nodos o sitios de red):
La figura anterior mejor conocida en el
ámbito de redes como grafo, es una representación de nodos y sus enlaces
físicos de conexión entre ellos, dicho grafo, bien puede ser la topología de
una red WAN, LAN o DC de algún cliente. Desde el punto de vista de teoría de
grafos, hay entre varios aspectos a considerar para una adecuada definición de
una topología de red, 2 de ellos que nos interesan para el tema de "alta
disponibilidad" en cuestión. El primero de ellos, es lo que se conoce como
hop count, es decir, se intenta que cualquier grafo o topología de red, cuente
con la menor cantidad de saltos entre cualesquiera pares de puntos o nodos de
la red con la intención de contar con rutas lo más cortas posibles. Así que el
primer aspecto como consultores que debemos observar en las soluciones
tecnológicas a proponer a nuestros clientes, es sin duda, recomendaciones de
sus diferentes topologías de red con la intención de contar con grafos lo más
limpios posibles. ¿En que nos afecta contar con topologías de red complejas e
ineficientes desde la perspectiva de saltos entre pares de nodos?, en que los
protocolos de red sean estos de capa 2 o capa 3, tardarán un mayor tiempo en converger
ante la reconstrucción de su árbol de decisión de rutas y las rutas alternas,
pueden llegar a ser muy ineficientes con respecto a la ruta principal (u
óptima) e inclusive provocar loops. La resolución de fallas (troubleshooting),
se vuelve también compleja y muy tardada cuando se requiere.
Para el grafo anterior, por ejemplo, el hop
count para el tráfico del sitio 1 al sitio 6 es de 3, mientras que para el
tráfico del sitio 3 al sitio 5 es de solo 2.
El siguiente aspecto a observar en la
topología de red, es el conocido como grado del grafo, es decir, la cantidad de
rutas alternas o enlaces con que cuenta cada sitio o nodo de la red, para
conexiones hacia la siguiente capa o el exterior (posibles rutas alternas). En
nuestro grafo de ejemplo, el nodo 6 tiene grado 1, los nodos 4/5/2 tienen grado
3 y los nodos 1/3 tienen grado 2.
De lo que se trata en toda red si alcanzan a
observar, es que la topología de red cuente en la medida de lo posible con la
menor cantidad de saltos entre pares de nodos y la mayor redundancia (grado)
posible, aunque el aspecto económico siempre debe estar presente. Así pues, una
red con nodos con un mayor grado, tienden a contar con mayores alternativas de
comunicación ante la falla de algunas de las trayectorias principales y con
ello, impactar favorablemente la disponibilidad asociada.
¿Cuánta redundancia
considerar en cada elemento o dispositivo de la red?
¿Qué aspectos de alta disponibilidad debemos
cuidar en los equipos a proponer?, de acuerdo al nivel de disponibilidad
objetivo, se debe considerar aprovisionar redundancia en elementos tales como
fuentes de alimentación, procesadoras/supervisoras/routing engines,
backplane/matriz de conmutación, tarjetas/linecards, etc. donde se conectarán
las interfases hacia distintas capas o sitios de la red, hasta considerar la duplicidad
en los equipos o chasis con la finalidad de que la alta disponibilidad de estos
componentes logre que se cumpla la disponibilidad objetivo. Pero, ¿cuánta
redundancia es necesaria entonces en cada elemento? Para responder esta
pregunta, tendremos que hacer uso de las matemáticas que nos permiten calcular
la disponibilidad por cada elemento individual y posteriormente modelar
escenarios para obtener la disponibilidad de la red en sí misma.
La disponibilidad de un elemento individual,
se calcula de la siguiente manera:
Disponibilidad elemento
individual (%)
= MTBF / (MTBF+MTTR)
Donde:
MTBF (Mean Time Between Failures).- Tiempo
medio entre fallas del elemento analizado (en horas). Es un dato que lo provee
el fabricante del hardware.
MTTR (Mean Time To Repair).- Tiempo
que lleva poner en operación el elemento caído una vez que falló ( en horas).
Es un dato que se determina entre el cliente y quién vaya a llevar a operar
dicho elemento a través de un contrato de servicios (mantenimiento, servicio
administrado, tercerizado o cloud).
Ejemplo 1: consideremos que una
tarjeta procesadora/routine engine/supervisora o como la llame cada fabricante,
tiene un MTBF documentado por el fabricante de 516,000 horas, y el proveedor
actual del contrato de mantenimiento de dicho hardware tiene firmado
contractualmente, un tiempo máximo de reparación de fallas de 4hrs. La
disponibilidad de dicha tarjeta se calculará como sigue:
Disponibilidad tarjeta supervisora (%) =
516,000 / (516,000+4) = 99.9992%
Ahora bien, si hubiésemos considerado 2
tarjetas supervisoras en el equipo a colocar como parte de nuestra solución, el
cálculo de alta disponibilidad al contar con elementos redundantes (también
llamados elementos paralelos), se lleva a cabo de la siguiente manera:
Disponibilidad
elementos paralelos (%) = 1- [(1-disponibilidad elemento 1)*(1-disponibilidad
elemento 2)*(1-disponibilidad elemento 3)*…(1-disponibilidad elemento “n”)]
Ejemplo 2: consideremos la
misma tarjeta del ejemplo 1, con su respectiva supervisora redundante (2
supervisoras en el equipo). La disponibilidad de este arreglo en redundancia (o
alta disponibilidad), sería:
Disponibilidad supervisora principal y
redundante (%) = 1-[(1-0.999992)*(1-0.999992)] = 99.999999%
Como podemos observar, mediante el cálculo de
disponibilidad de elementos en paralelo o redundantes, podemos obtener nuestra Primera Conclusión: "la disponibilidad de un elemento aumenta al colocar 1 ó más
elementos adicionales o en redundancia al principal".
En este punto, ya sabemos cómo llevar a cabo
el cálculo de disponibilidad de elementos individuales y elementos redundantes
o paralelos en un dispositivo o equipo, ¿cómo calcular la disponibilidad de
todo un equipo o dispositivo?, se tienen que llevar a cabo 2 pasos sencillos:
Paso 1.- Calcular la
disponibilidad de todos los elementos redundantes en el equipo (supervisoras,
fuentes, linecards, backplane, etc.) conforme los ejemplos 1 y 2, cuyo
resultado dará un elemento individual que será la combinación de redundancias.
Paso 2.- Calcular la
disponibilidad de todos los elementos del equipo (denominados elementos en
serie ya que la falla de cualquiera de ellos será tomada como falla del equipo
en análisis y contará para la medición de downtime máximo por año), de la
siguiente manera:
Disponibilidad de un
equipo o dispositivo (%) = disponibilidad elemento 1 * disponibilidad elemento 2
*…disponibilidad elemento “n”
Ejemplo 3: ahora pensemos que
vamos a calcular la disponibilidad de un switch de DataCenter, en donde cuenta
con las siguientes disponibilidades ya calculadas previamente en todos sus
componentes:
·
Disponibilidad
procesadoras (elementos en paralelo ya que el equipo cuenta con 1 principal y 1
más redundante) = 99.99%.
·
Disponibilidad
fuentes (elementos en paralelo ya que el equipo cuenta con 1 principal y 1 más
redundante) = 99.999%.
·
Disponibilidad
linecard de puertos GE = 99.98%.
·
Disponibilidad
linecard de puertos 10GE = 99.97%.
·
Disponibilidad
del chasis = 99.99%
Disponibilidad del switch de DC (%) =
0.9999*0.99999*0.9998*0.9997*0.9999 = 99.929%
Segunda Conclusión: "La disponibilidad de un equipo o escenario es afectado por la baja disponibilidad de alguno de los elementos que lo componen".
Nota.- Hay que ser muy cuidadosos al momento de obtener
los datos del MTBF de cada componente ya que regularmente los fabricantes solo
publican en sus sitios Web los valores para los chasis en sus hojas de datos
(datasheets). Recordemos que tenemos que obtener los valores de MTBF de cada
componente individual del equipo.
Ya sabiendo como calcular la disponibilidad
de un dispositivo completo, el siguiente paso, sería calcular la disponibilidad
de todos los componentes que formarán parte de la arquitectura tecnológica a
proponer (switches, ruteadores, servidores, firewalls, IPS/IDP, puntos de
acceso, teléfonos, equipos de video, etc.), llegando a una tabla resumen como
la siguiente:
Dispositivo
|
Disponibilidad
|
Switch
A
|
99.98%
|
Router
C
|
99.97%
|
Server
|
99.9%
|
Firewall
|
99.96%
|
¿Ya sabiendo la disponibilidad de todos los
componentes de la arquitectura propuesta, que más restaría?..Continuará…
No hay comentarios.:
Publicar un comentario