Recientemente, en una conversación de pasillo con un cliente debatiamos sobre la utilidad real de colocar equipos redundados en el Data Center. Su argumento era, que  la redundancia solo entra en juego cuando un equipo se rompe, y esta circunstancia ocurre en muy raras ocasiones. ¿Está en lo cierto? Pues en mi opinión, no del todo.

La redundancia de equipos hardware es la principal razón a esgrimir en un diseño porque es un concepto facilmente entendible por todos. Pero detrás de la redundancia, hay muchas otras ventajas (y alguna que otra desventaja). En este artículo exponemos que pros y contras tenemos al introducir redundancia en nuestro Data Center

Redundancia en el Data Center, por qué SÍ (o por qué no)

La redundancia generalmente consiste en incluir en paralelo un segundo equipo (o secundario) del mismo modelo formando un cluster con el equipo principal (o primario). El segundo equipo tiene 2 modos de funcionamiento: activo/pasivo donde el secundario está a la espera por si el primario falla; o activo/activo donde ambos equipos se reparten la carga de trabajo. La elección de uno u otro modo es un criterio de diseño, aunque generalmente el switching y routing se coloca en activo/activo (con soluciones de nivel 2 como MLAG, VLT, vPC y soluciones de nivel 3 como HSRP o VRRP) y el firewall se suele colocar en activo/pasivo para evitar un problema de incorrecto dimensionamiento y para reducir costes.

Dicho esto, ¿que equipos podemos redundar en el Data Center? En mi opinión, debemos plantearnos redundar los siguientes elementos:

• Firewall perimetral.
• Firewall interno (si hubiese).
• Equipos de switching de core.
• Equipos de routing dl operador.

Pros

• Redundancia de equipos. Es la razón más obvia para redundar. Si un equipo se rompe o se apaga, el equipo redundante seguirá asumiendo las funciones del cluster. Esto es especialmente importante en los Firewalls que solo suelen llevar UNA única fuente de alimenación.
• Redundancia de enlaces. Al disponer de dos equipos, podemos conectar enlaces independientes a cada uno de ellos. Por ejemplo, un switch de acceso remoto puede llegaar una fibra al Core-1 y otra fibra al Core-2. De esta manera, si se rompe una fibra o se cae un core, todo seguirá funcionando.
• Doble capacidad. Adicionalmente, si estamos funcionando en activo/activo, podemos disfrutar de doble ancho de banda con alguna tecnología de agregación de enlaces formando un port-channel.
• Operaciones de mantenimiento. Cada equipo del cluster tiene un plano de control independiente, esto implica que se puede actualizar cada equipo de manera independiente….sin corte! Esta es una gran funcionalidad que los equipos de IT aprecian enormemente.
• Redundancia de conexiones externas. Cuando instalamos un cluster podemos darnos cuenta por ejemplo que nuestro ISP solo nos ofrece un cable para la conexión a internet. ¿Donde conecto el cable al primario o al secundario? El hecho de instalar un cluster en nuestra infraestructura va a aflorar otros puntos singulares de fallo.

 

Contras

• Coste. De manera general, tener un segundo equipo puede implicar un coste hasta x2 en la adquisición del material. Además, en algunos casos lleva aparejado un pequeño incremento en forma de licencia para el cluster.
• Configuración más compleja. Montar un cluster implica aumenta la complejidad de la configuración. Tu integrador de confianza debe tener experiencia en este tipo de diseños. Por ejemplo un error en las condiciones de failover (traspaso del control de un equipo a equipo a otro) puede desembocar en conmutaciones aleatorias del cluster.
• Incorrecto dimensionamiento. En el caso de optar por un activo/activo, en ocasiones no tenemos en cuenta que un solo equipo standalone debe hacerse cargo de todo el trabajo si uno de los dos cae.

 

Conclusión

Desde un punto de vista de diseño, la redundancia es un «must» por todas las razones expuestas. Toda red importante debería disponer de equipos redundados en sus puntos más críticos.

Con respecto al tema económico, la pregunta que deberías hacerte es ¿como de importante es mi Data Center? Aumentar la inversión inicial puede ahorrarte una interrupción de negocio en el futuro de consecuencias catastróficas.

Desde la perspectiva técnica, mantener un cluster es un aumento de responsabilidades que conlleva una mayor exigencia de habilidades de las que debe disponer tu equipo IT.

En resumen, redundar equipos en el Data Center debería ser tu única opción valida. Solo deberías plantearte la opción de un solo equipo en entornos de baja importancia (por ejemplo un Disaster Recovery o una sede remota) o en caso que sea imposible por razón presupuestaria.