vSphere 4.0: Mis razones para... (I)
Con este post que tenía a medio hacer hace bastante tiempo comienzo una serie (que prometo terminar) sobre mi particular percepción respecto a vSphere 4.0. Como remarco en el título, lo aquí recogido es mi opinión personal (y por tanto profesional) sobre vSphere 4.0. Los lectores de este blog (si aún me queda alguno después de mi dejadez) son libres de estar o no de acuerdo, y espero que ejerzan esta libertad opinando al respecto. Empecemos:
... No implementar VMware FT en producción:
Sí, leeis bien. Todo un vExpert desaconsejando VMware FT en producción. Como muchos sabéis, Vmware FT permite la ejecución en simultáneo de dos máquinas virtuales haciendo exactamente lo mismo, es decir, una actúa como sombra de la otra en otro host distinto. A priori esto suena bien: si cae un host, la VM sobreviviente recoge la carga de la primera sin impacto para los usuarios. La pregunta es si merece asumir las limitaciones que impone FT para evitar 30 segundos de pérdida de servicio. Mi respuesta es que depende. FT no te va a proteger de una corrupción de datos, ni de la pérdida de los mismos. Si el servicio que nos interesa se cae en la VM primaria, también se caerá en la máquina "shadow". FT no garantiza más que la operación de una VM (ojo que digo VM, no servicio) en caso de caída del host que la aloja. No con esto quiero quitar méritos a FT: Como obra de ingeniería es impresionante. Como medida de continuidad del servicio no deja de ser un paso más. FT puede transmitir la falsa sensación de que se ha elevado el nivel de servicio, y quizá en algunos casos lo haga, haciendo que el responsable de sistemas baje la guardia. No creo que por el momento implemente FT en bases de datos críticas o servidores de correo: La penalización de una única CPU y el desaprovechamiento del nodo donde se ejecuta la VM "espejo" no compensan, al menos, por el momento. Nada como una buena replicación de log de transacciones en una base de datos, a ser posible diferido, como para garantizar la disponibilidad.
... Implementar los vNetwork Distributed switchs: Bonding, load balancing, MACs, etc... Demasiados términos que suenan propios de los chicos de networking. Los distributed switches (en especial el Nexus 1000v de Cisco) acercan a los responsables de networking a un área de la virtualización que, hasta ahora, consideraban extraña: los switches virtuales. Con los Distributed Switches el networking virtual es, por fin, networking, y puede caer en las manos de quien mejor lo controla: La gente de red. Para bien o para mal la virtualización ha caido en la parte de sistemas, olvidando que una parte fundamental del entorno virtual es la red. Ahora este aspecto del entorno virtual se vuelve amigable para los chicos de la red.
... Implementar DPM (si deja de ser experimental): En grandes proyectos de virtualización, el consumo eléctrico tiene su peso. Si a las ventajas inherentes a eliminar toneladas de hierro le añadimos que el hierro con el que virtualizamos también consume lo justo... miel sobre hojuelas.
Paro por el momento.
Un saludo.