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.
4 comentarios:
Pues ya somos dos, no veo muy claro todo esto. El planteamiento es bueno pero como bien dice las limitaciones son demasiadas, creo que el producto aun está verde. Tambien creo que en este caso VMware puede estrellarse, estan dejando demasiadas cosas en modo "experimental"
Simplemente indicarte que no te hemos dejado de leer, y siempre esperamos nuevas actualizaciones en tu blog, que nos permita ver las cosas desde otro punto de vista.
Saludos de un humilde tecnico que se tiene que pelear con la virtualizacion en entornos de "bajo coste", es decir, gastar lo menos pero conseguir lo maximo.
saludos
Hola JL,
Estoy de acuerdo en casi todo. Lo de "No usar en producción" es un tanto alarmista pero después dices que efectivamente "representa un paso más" pero que aún así, no lo vas a implementar en producción, por lo menos en entornos de BBDD críticas, entiendo que tampoco usabas HA entonces.
Para mí, sinceramente, el sistema anterior no debería llamarse alta disponibilidad, más bien algo como disponibilidad-medianita, porque el hecho de que la máquina se apague de golpe, sabemos que en entorno Windows puede ocasionar problemas y no solo a nivel de aplicación. El sistema FT actual me parece un avance bastante importante, es cierto que no garantiza 100% la integridad de datos, pero el hecho de que la máquina ya no se apague es un avance.
Hola,
Con respecto a FT, sólo recordar que existen equipos diseñados específicamente par ofrecer tolerancia a fallos, con procesadores, placas y fuentes redundantes, que valen un pastón y sólo están soportados en determinados entornos y, aún así, se venden. FT nos aporta esta fiabilidad de hardware sin las limitaciones de otros productos y, aunque son muy específicas, estos sistemas tienen un nicho de mercado que FT cubre perfectamente.
Publicar un comentario