Los switches distribuidos han sido uno de los más importantes cambios introducidos en vSphere desde la versión 4. Facilitan no solo el despliegue de nuevos hypervisores , tambiéns aportan un único punto de administración que facilita su gestión. Gracias a esta nueva funcionalidad podemos hacer uso del fabuloso NIOC (Network IO Control) que además nos garantiza una buena gestión del ancho de banda en un entorno donde usamos adaptadores convergentes de 10GbE o más, concrétamente en momentos de alta demanda como son las tareas de vMotion.
Os podéis imaginar cómo sería poder ver los paquetes de nuestras máquinas virtuales circulando por la red, entrando y saliendo de nuestros Uplinks como si fueran piezas de LEGO cantando aquello de “Todo es fabuloso”. Porque en realidad, lo es. Hasta que tu vCenter decide dejar de cantar en armonía y dar el salto a nuestra realidad con un tremendo casque.
Puede ser algo habitual, como una parada de servicio, una falta de espacio en disco, o simplemente lo ha reiniciado el HA por un error inesperado en el ESXi dónde estaba corriendo y la cosa tarde un poco más en arrancar de lo que esperábamos. O desafortunadamente nuestra BBDD se ha ido al garete. El caso es que sabemos que vamos a tardar más tiempo del esperado en traer nuestro vCenter de vuelta.
Normalmente no tenemos demasiada presión porque nuestras máquinas van a estar funcionando y dando servicio, manteniéndose totalmente ajenas al apagado de nuestro vCenter. El asunto se nos puede complicar cuando, por cumplir ciertos SLA, nos demandan realizar una migración de una VM a otro ESX dentro del clúster en ese preciso momento. Suena raro, pero lamentablemente, en ocasiones existen pequeñas diferencias a nivel de networking que hacen que una VM de serios problemas en uno de los DC’s cuando se trata de un Cluster extendido. En un reciente caso, la máquina en cuestión perdía toda conectividad resultando ser totalmente inaccesible. Os imagináis que esa VM sea la BBDD del vCenter ?. Al conocer las virtudes y defectos de nuestro entorno, sabemos que si la VM la pasamos a otro Host ubicado en el DC contrario recuperaríamos nuestro mundo fabuloso de nuevo, y eso es lo que me ha tocado hacer.
Recordáis el “No Martini, no party !”?. Pues en nuestro caso aplica a “No hay vCenter, no hay vMotion”. Y como quiern no quiere la cosa van pasando los minutos, los indicadores ya marcan un DEFCON 2 y algunos alrededor nuestro comienzan a sufrir ciertas contracciones por lo que viene siendo la bajante principal. Todo un indicio claro de que ésto empieza a ser serio, y nos va a tocar improvisar para traer de vuelta ese vCenter.
Tiempo atrás, el vCenter era una herramienta exclusiva que solamente utilizábamos los responsables de la plataforma de virtualización, en realidad, en España, hace 4 a
ños nadie ajeno a virtualización conocía el vCenter Server mas allá de una máquina Windows que era crítica para nosotros y que usaba una Base de Datos. Si se nos caía el servicio, nadie se enteraba. Eso de instalar un programa que, tras escribir un nombre de máquina, usuario y password, te abría un entorno gráfico con Hosts y Virtual Machines, te permitía acceder a las consolas de cada una de ellas, montar ficheros ISO, añadir y quitar discos, adaptadores de red…. todo eso, era algo desconocido y misteriorp que solamente conocíamos nosotros. No exagero si os digo que hablar de vCenter (“viCenter“) en algunos proyectos de hace años, para otros equipos de trabajo era como quien tenía un primo llamado Vicente. Hoy en día vCenter Server es una herramienta ampliamente conocida y utilizada por el resto de equipos de trabajo. Backup, Monitorización, Storage, etc. Por tanto, la criticidad de “Éste, nuestro servicio” se ha incrementado con el paso de los años.
No vamos a realizar un vMotion, eso está claro, pero si podemos aprovechar la falta de servicio para apagar la máquina en cuestión – en éste caso la BBDD del vCenter- y que eso nos de opción a registrar la VM en otro ESX desde su Datastore. Es aquí donde quiero llegar con este post, hay que tener siempre en cuenta que trabajar con los vDS nos facilita la vida, pero toda la información relativa a su configuración y todos sus PortGroups residen en la BBDD del vCenter y están accesibles mientras lo esté el propio vCenter server. Por tanto antes de hacer esta operación hay que recordar que cuando vayamos a registrar la misma VM en otro ESX, mediante nuestro vSphere Client, todas las VLANS que actualmente residen en el vDS no estarán disponibles y nos quedaremos con el culete al aire.
Ésta situación es algo confusa, pero real. Y es el comportamiento normal cuando se crean los Port Groups por defecto en un vDS, es como funciona la asignación por defecto y que todos usamos, es el Static Binding. Con ésta opción por defecto, cuando conectamos una VM a un PortGroup, se asigna y se reserva un nuevo puerto inmediatamente. Por supuesto garantiza la conectividad en todo momento, incluso si el vCenter está “apagado o fuera de cobertura”. El puerto se desconecta solo al quitar la VM de ese PortGroup.
También existe un segundo modo, que prácticamente está en desuso, llamado Dynamic Binding. En este caso el puerto se asigna y reserva cuando la máquina se enciende – y además tiene conectada la NIC. Del mismo modo, el puerto se elimina cuando la VM se apaga o se desconecta su adaptador de red desde el vSphere client. Obviamente éstas VM solo pueden encenderse y apagarse desde el vCenter.
El modo más avanzado corresponde al Ephemeral Binding. En este modo el puerto también se asigna y crea al encender la VM teniendo el adaptador de red en estado “conectado” pero a diferencia del Dynamic, es el Host el que realiza esta asignación, pudiendo actuar de forma independiente del vCenter Server. Ésta sería nuestra opción adecuada para un caso como el que vengo planteando. Por supuesto, una vez apagada la VM, el puerto se borra.
Vmware recomienda usar este último modo de creación de puertos solo para propósitos de recuperación. Sinceramente no he apreciado en prácticamente ningún entorno por los que he estado la selección de éste tipo de binding. En el escenario que estoy planteando, con el Static Binding, tenemos que seguir improvisando.
De modo que nos encontramos ahora mismo con la VM que contiene nuestra BBDD registrada en el ESX que está en el DC correcto para garantizar su funcionamiento, está apagada, y no podemos seleccionar la VLAN correcta porque pertenece a un PortGroup creado por defecto en un Switch Distribuido y el vCenter está KO.
En esta situación necesitamos sacarnos un PortGroup para poder Taggear la VLAN correspondiente, y lamentablemente solo podemos hacerlo en un vSS (virtual Standard Switch) en nuestro ESX. Podemos crear el vSS, pero nuestros vmnics están todos ya asignados en nuestra , ya madura, infraestructura.
Una de las maravillosas funcionalidades de una infrastructura vSphere que, por supuesto siga las buenas prácticas, es la facilidad de crear tolerancia a fallos, en nuestro caso la que nos vendría de maravilla sería aprovecharnos de la redundancia de los adaptadores de red y disponer de, al menos, dos Uplinks totalmente funcionales en nuestro vDS.
Con esta simple y mínimamente exigida configuración, podríamos ‘romper’ esa redundacia sacándo un vmnic del vDS y añadírselo a nuestro recien creado vSS. Ahora, solamente necesitaríamos crear un PortGroup con la VLAN de nuestra BBDD y posteriormente seleccionar esta nueva VLAN para que la use nuestra ansiada VM editando sus propiedades.
Recapitulando. En este punto tendríamos nuestra máquina de BBDD del vCenter registrada en el ESX adecuado dónde tenemos garantizada su conectividad, además está conectada a un vSS que solo existe en ese host, usando uno de los vmnics que formaban NLB en el vDS, y finalmente conectada a un PortGroup que tiene la VLAN correctamente taggeada. Tenemos todos los ingredientes para el éxito. Así pues, tras encendérla, nuestros servicios de vCenter serán capaces, y de hecho lo fueron, de poder conectar con la BBDD y arrancar de forma satisfactoria. Nuestro vCenter volvío a la vida.
VirtualPad 