¿Cómo están estimados?, espero que bien! Hoy toca hablar sobre las opciones que tenemos a la hora de configurar una controladora SCSI en una máquina virtual en VMware vSphere 6.7. Esta publicación viene a raíz de una consulta que nos surgió la semana pasada en un cliente, y que me vino bien para refrescar un poco los conceptos.
Como siempre ante un problema o consulta que se me plantea, si tengo alguna duda de cuál sería la mejor opción, lo primero que hago es revisar la documentación oficial de VMware:
En ese enlace encontraran la explicación de como configurar el Bus Sharing deseado, y cuáles son los 3 modos existentes:
Por si no queda claro, lo paso en limpio:
Opción «None»: Es como viene por default la controladora y no te permite compartir discos virtuales entre diferentes máquinas virtuales.
Opción «Virtual»: Si se configura este modo se pueden compartir discos virtuales entre máquinas virtuales, pero con la condición de que estén ejecutando en el mismo ESXI.
Opción «Physical»: Si se configura este modo se pueden compartir discos virtuales entre máquinas virtuales, y con la ventaja de que las VMs pueden residir en diferentes ESXI dentro del mismo Cluster.
¿Y en qué caso se podría aplicar una configuración «Virtual» o «Physical»? Si por ejemplo se requiere configurar un WSFC (Windows Server Failover Cluster).
Para realizar el análisis de cómo funcionan los tres tipos de modos existentes, vamos a plantear un esquema en donde estén 2 servidores Windows Server 2019 con la feature «Failover Clustering» instalada y que cumplirán la función de File Servers.
Comencemos por la configuración que viene por default: «None». A continuación, podrán ver como respondería un WSFC virtual en caso de tener dicha opción aplicada.
Tenemos 2 Servidores desplegados y ambos se encuentran apagados:
Si observan las siguientes imágenes, las VMs tiene dos controladoras cada una y están con la configuración de «Bus Sharing: None». Además, tienen tres discos virtuales cada una: el «Hard disk 1» vendría a ser el disco «C» para el sistema operativo, el «Hard disk 2» es el el volumen utilizado para que el Rol de File Server pueda almacenar los archivos a compartir y el «Hard disk 3″ de 5GB que cumple la función de Witness dentro del Cluster.
.
Si prestan atención, los discos 2 y 3 del «Nodo 2» son los discos correspondientes al «Nodo 1». O sea que el «Nodo 2» no tiene discos secundarios propios (el único propio es el «Disk 1»), sino que está conectado «virtualmente» a los discos ya generados en el «Nodo 1»:
.
Noten que los discos tienen la siguiente nomenclatura «NODO1-CLUSTER_1.vmdk» y «NODO2-CLUSTER_1.vmdk». Lo cual indica que pertenecen al «Nodo 1».
Aclaración: Lo que está tachado es el nombre del Datastore y la carpeta que contiene a los archivos «vmdk».
¿Y por qué se configura así? Es un requisito indispensable para poder desplegar un WSFC. No quiero ahondar mucho en la teoría de Clustering en Windows (no es la finalidad de esta publicación), pero si les interesa les dejo dos enlaces en donde podrán encontrar más información:
https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster
Volviendo al lado de VMware, una vez configurado las VMs de esa manera, vamos a proceder con el encendido de los nodos y veremos qué es lo que sucede:
El primer nodo enciende sin problemas
Pero a la hora de encender el segundo nodo, nos va a devolver el siguiente error:
¿Y eso a que se debe? El primer nodo que encienda se va a hacer propietario de los discos compartidos, por lo tanto, a la hora de querer encender el segundo nodo nos dará un mensaje de error. La propia definición del modo «None», aclara que los discos no podrán ser compartidos entre VMs. ¿Y si enciendo el «Nodo-2» primero, va a pasar lo mismo? Ya que recordemos que los discos estaban en la carpeta correspondiente al primer nodo. Veamos qué es lo que sucede:
.
Con esta prueba podemos llegar a la conclusión de que no importa la ubicación del archivo «vmdk», la cuestión es quien de los nodos enciende primero.
Algo a destacar de la configuración «None», es que nos permitirá ejecutar Snapshots sobre las máquinas virtuales, por lo tanto pondríamos realizar un respaldo convencional con una herramienta como Veeam. Cuando menciono backup convencional, me refiero a no tener la necesidad de utilizar un agente.
Ahora le toca el turno al modo «Virtual». Veamos que sucede cuando configuro ambas máquinas virtuales con dicha opción y quiero encenderlas:
.
Efectivamente pude lograr que ambas levanten:
Por lo tanto, funcionan de manera correcta. Pero prestemos atención al siguiente detalle:
.
Ambos equipos están corriendo en host ESXI diferentes, pero si recordamos la definición del modo «Virtual», nos decía que las VMs deben encontrarse sobre el mismo ESXI. Bueno, acá podemos refutar la teoría, porque funciona sin ningún problema. Pero el inconveniente lo vamos a tener si queremos ejecutar un vMotion, ya que al hacerlo en cualquiera de los dos nodos nos va a devolver el siguiente mensaje de error:
.
O sea, para que se cumpla la regla de que estén en el mismo ESXI, a la hora de encenderlas deben estar en el mismo host. Caso contrario no podré migrarlas.
Otra limitante que tiene este modo de configuración es que a la hora de realizar un snapshot, la opción no estará disponible y no me dejará ejecutarlo. Por consiguiente, si necesito efectuar un backup, necesito hacerlo mediante un agente instalado a nivel del SO Guest.
Por último tenemos la opción de «Physical», que en resumidas cuentas funciona igual que la opción «Virtual», salvo con la diferencia de que si me va a permitir ejecuta un vMotion (sobre cualquiera de los nodos) en caso de ser necesario:
.
.
Conclusiones de cada caso:
None:
Pros: Me deja ejecutar vMotion, Snapshot y backup convencional
Contras: En caso de tener que configurar un WSFC u otro esquema de discos compartidos, esta opción no es la indicada.
Virtual:
Pros: Puede ser utilizado en un esquema de WSFC.
Contras: No puedo ejecutar snapshots, vMotion y debo realizar backups mediante agente instalado en el Sistema Operativo.
Physical:
Pros: Puede ser utilizado en un esquema de WSFC y me permite ejecutar vMotion.
Contras: No puedo ejecutar snapshots y debo realizar backups mediante agente instalado en el Sistema Operativo.
¡Bueno gente, hasta acá llegamos con la publicación del día de hoy! Espero que te haya servido para sacarte alguna duda, para conocer del tema o simplemente como me paso a mí, para refrescar un poco la memoria. Cualquier consulta que tengas no dudes en contactarme a través de los comentarios o vía mail. Compartilo con colegas, compañeros o amigos. Si te gusta este tipo de contenido, podes suscribirte a este blog.
¡Hasta la próxima publicación!
Se autoriza la reproducción de los materiales de este blog citando la fuente e incluyendo un enlace al mismo.
Blog de Cloud Computing y Virtualización 
Para la opcion Physical, el vMotion debe ser siempre con la maquina apagada. Cierto?
Me gustaMe gusta
Buenas tardes Telmo! Disculpa la demora en responder. No, la opción Physical te permite hacer vMotion con la VM encendida, siempre que sea dentro del mismo Cluster. Lo podes observar en la captura que le realicé a la VM «NODO1-CLUSTER», como podrás notar la misma se encuentra en estado de ejecución (encendida). Espero haber respondido tu consulta. No te olvides e suscribirte para recibir una notificación cada vez que haga una publicación nueva. Saludos colega!
Me gustaMe gusta