Jose nos pregunta:
"Como paso previo a desplegar Vmware I3 a final de año, hemos consolidado varios servidores antiguos que se caian a trozos, con paradas indeseadas y demás.Esto se ha hecho con Vmware Server con la intención de que haya trabajo hecho cuando tengamos ESX y porque Converter nos ha facilitado mucho las cosas. Los servidores host (2 blades) son Windows Server 2003 porque aunque Linux pueda ofrecer más rendimiento y estabilidad Vmware no certifica el bonding.Las máquinas virtuales como tales son almacenadas en una partición de la cabina de fibra y acceden a la red por tarjetas que el host tiene activas pero sin tcp/ip. La duda a plantear es: si quiero acceder a la SAN desde una máquina virtual ¿qué tengo que hacer en el anfitrión para que haga de puente pero no acceda a la partición de la máquina virtual?Otra duda ¿si uso physical disk puedo remapear en otro momento a un servidor físico? ¿qué ventaja me aportaría que el disco de datos fuera virtual? Gracias y adelante con el blog."
La respuesta es sencilla: has de usar un raw device mapping. RDM permite a una VM acceder directamente a una partición de disco. EN ESX, esta LUN ha de estar localizada en una SAN, pero con Server, puede ser cualquier tipo de partición.
¿Para qué resulta interesante utilizar RDM? Pues hay unos cuantos escenarios.
El primero: Compatibilidad de la LUN con sistemas físicos. El uso de RDM puede venir bien, por ejemplo, para mover los archivos de datos de una RAW partition de Oracle de un entorno de preproducción en VM's al entorno de producción. Nos basta con desmapear la LUN/partición (dependiendo de si usamos ESX/Server) de la VM y asignársela/ponerle el disco (la misma distinción) al servidor físico.
El segundo: Un cluster V/P, donde uno de los nodos es virtual y otro físico. VMware ESX (y entiendo que Server también) envía directamente los comandos SCSI a la SAN, incluyendo las SCSI reservations.
El tercero: Utilizar determinandas funcionalidades de nuestra SAN. Por ejemplo, Netapp dispone de un agente para SQL server, Exchange y Oracle que permite poner la base de datos en modo backup mientras hace un Snapshot. Evidentemente, si la LUN donde almacenamos los datos está en un VMDK, este software no va a darnos la funcionalidad que esperamos.
Pero no todo es tan bonito: RDM lleva unos riesgos implícitos y requiere de una planificación exhaustiva. En el caso de Server, hay que tener en cuenta que Server "engaña" al Windows subyacente para que no toque esa partición, así que cuidado con los updates de Windows, otros softwares que puedan interferir, etc. En el caso de ESX, RDM te obliga a cumplir a la perfección la HCL de VMware (hardware compatibility list), es decir, tarjetas, hardware, BIOS, firmware, switches FC, etc.
En tu caso, y si tienes clara la adquisición de licencias Enterprise para final de año, yo te aconsejaría hablases con tu contacto en el suministrador de VMware (o por que no, contacta directamente a VMware) para conseguir una licencia de evaluación por el periodo que te queda hasta la adquisición.
Un saludo.
2 comentarios:
Gracias por responder, te cuento:
Somos administración pública y no tenemos partner fijo o acceso directo a Vmware por tema de concurso público.
De todas formas el coste de los nuevos servidores y las licencias de VI3 nos restringirán a 2-3 máquinas nuevas y queremos usarlas para HA con DRS con lo que seguiremos usando VMware Server para los servicios a extinguir.
Respecto a la duda con la RDM en Server (candidata a serlo después en ESX) sería mejor un anfitrión Linux? Realmente cómo puede ser que Vmware no certifique el bonding en Linux? ¿temor a autocompetencia?
Gracias de nuevo.
Bueno... eso de que no tienes acceso a VMware es discutible. Dame un correo y charlamos sobre ello.
Respecto a cual es mejor candidato, prefiero Linux. ¿Qué porqué VMware no certifica el bonding con Server? Pues porque el producto es gratuíto. Certificar plataformas es algo caro, y más con Linux, donde los drivers son desarrollados por la comunidad y cambian constantemente. No justifico a VMware, simplemente les entiendo. Personalmente prefiero que inviertan en mejorar ESX que en certificar configuraciones más o menos específicas bajo cualquier OS.
Publicar un comentario