La gran mayoría de las organizaciones que utilizan la virtualización del servidor hacen uso de tecnologías como el clustering o la realización para la conmutación por error como una manera de protegerse contra fallas a nivel de hipervisor. Aunque tales tecnologías sí recorren un largo camino hacia la protección de las cargas de trabajo virtualizadas, el clustering por sí solo puede ser insuficiente. Es posible que ocurra un corte importante incluso si los hosts de virtualización se agrupan y las máquinas virtuales se han hecho altamente disponibles. Tales fallas pueden ocurrir si alguna pieza de la infraestructura de virtualización se convierte en un punto único de fallo.
Aunque es posible eliminar cada punto concebible de fracaso, hacerlo requiere bolsillos profundos. En la mayoría de los casos, las organizaciones deben identificar los riesgos potenciales y luego evaluar la probabilidad de que el riesgo se convierta en un problema. De esa manera, una organización puede gastar su dinero en amenazas que se consideran los mayores riesgos.
Por supuesto, esto plantea la cuestión de cuáles puntos únicos de falla potenciales existen. Los riesgos reales de fallo pueden variar considerablemente en función de qué proveedores se están utilizando y cómo se ha implementado la infraestructura de virtualización. Algunos riesgos están relacionados con el hardware, mientras que otros están relacionados con el software.
Los riesgos relacionados con el hardware se aplican a cualquier pieza de hardware cuyo fracaso podría potencialmente traer abajo toda la infraestructura de virtualización. Tome la administración de energía, por ejemplo. Muchos hosts de virtualización están equipados con fuentes de alimentación redundantes. La idea es que un fallo de suministro de energía no traerá abajo un servidor host porque una fuente de alimentación secundaria puede tomar el control sobre la marcha. Aun así, los administradores deben considerar qué pasaría si fallara la energía.
Los hosts de virtualización suelen estar conectados a un sistema de alimentación ininterrumpida, y las organizaciones más grandes pueden incluso tener un generador que puede asumir el control en caso de un apagón. Sin embargo, ese generador potencialmente podría convertirse en un punto único de fallo si todos los servidores están ligados al mismo generador después de un fallo de la alimentación principal de energía.
Por supuesto, aquí es donde el concepto de evaluación de riesgos entra en juego. Un montón de cosas tendrían que ir mal antes de que el fallo de un generador de reserva hiciera caer toda la infraestructura de virtualización. La energía tendría que apagarse, y todas las baterías de emergencia tendrían que agotarse. No importa el hecho de que el generador de respaldo tendría que funcionar mal. En consecuencia, las probabilidades de que el generador de emergencia se convierta en un punto único de fallo son relativamente bajas.
Si bien es posible eliminar prácticamente todos los puntos únicos de fallo, como se mencionó antes, sería muy caro. Imagínese qué debería estar involucrado en la creación de un generador de respaldo separado para varios grupos de servidores. Incluso eso no necesariamente eliminaría el potencial de puntos únicos de fallo. Si el combustible para esos generadores de respaldo proviene todo del mismo lugar, y sucede que el combustible está contaminado con agua, entonces el combustible del generador podría convertirse en un punto único de fallo. Una vez más, sin embargo, una gran cantidad de cosas tendría que ir mal antes de que eso suceda.
En entornos en clúster, es mucho más común que el almacenamiento compartido se convierta en un punto único de fallo. El almacenamiento en clúster se diseña generalmente con discos redundantes, pero las fallas pueden ocurrir en el nivel de matriz, el nivel del interruptor, o el nivel de cableado si el grado adecuado de redundancia no se instala.
En el lado del software, los servidores de infraestructura pueden convertirse en un punto único de fallo si no se implementan de manera redundante. Por ejemplo, supongamos que una organización tuviera que implementar System Center Virtual Machine Manager (SCVMM) como una herramienta para la gestión de Hyper-V. SCVMM podría convertirse en un punto único de fallo a menos que resida en una máquina virtual de alta disponibilidad. Del mismo modo, SCVMM depende de una base de datos de SQL Server que también podría convertirse en un punto único de fallo, salvo si son redundantes. Algunos otros puntos únicos de fallo potenciales podrían incluir servidores DNS, controladores de dominio, servidores DHCP, servidores de respaldo o gateways de internet.
Probablemente no es realista para la mayoría de las organizaciones eliminar cada punto potencial de fallo. Una mejor estrategia es identificar los puntos únicos de fallo y luego evaluar a cada uno basado en el riesgo que plantea.
