Hola amigos, soy Florián Murillo. El objetivo de los mecanismos de Network Failover Detection existentes en los switches virtuales, es, como dice su nombre, para poder detectar que un enlace ha perdido conectividad de red y reconducir los tráficos de red de las VM por otro interfaz de red.
Disponemos de dos posibilidades: link down y link down & beacon probing. El valor por defecto es link down, pero ¿Estamos protegidos con link down? si cae el interfaz de red, el cable o el switch donde está directamente conectado, estamos protegidos, pero ¿es suficiente?, observemos el escenario de la cabecera.
Imaginemos que cae la conexión entre el Switch 1 y el Core Switch, como en la imagen siguiente:
Si configuramos link down en el port group, no se detecta ninguna caída, por tanto las VM que estaban saliendo por vmnic1, pierden conectividad de red, para resolver este problema existe link down & beacon probing.
El funcionamiento es sencillo, por cada interfaz de red se envía un frame ethernet tipo 0x05FF por broadcast, a todo el dominio de colisión, siendo recibido por los otros interfaces de red del balanceo, como vemos en la imagen siguiente:
Este proceso ocurre en todos los vmnic activos, con lo que todos los interfaces de red se anuncian a todos.
En el momento que un interfaz deja de recibir tres beacon frame consecutivos, el algoritmo lo da por perdido y cambia el tráfico de las VM que están saliendo por el, por otro interfaz de red, recuperándose de la caída.
El precio que hemos de pagar es disponer de, al menos, tres interfaces balanceados, para poder determinar, en caso de caída de un interfaz de red, cual es el que ha caído. Eso no impide que lo podamos utilizar con solo dos interfaces de red, pero en ese caso el tráfico de red es enviado por los dos interfaces ¿está mi red preparada para sobrevivir a este caso?
Por tanto, en el caso de disponer de una topología como la descrita, link down & beacon probing es mi elección ¿Cual es la tuya?
Queridos amigos, aprovecho para desearos a todos un feliz día de Navidad.
Mi buen amigo, Jeff Miller, jefe de prensa en Veeam Software, ha anunciado que Veeam está ofreciendo licencias gratuitas de Veeam Backup y Veeam Replication versión 5 para todos aquellos con la acreditación oficial VCP (VMware Certified Professionals), VCI (VMware Certified Instructors) y VMware vExperts.
Estoy seguro que aquellos que ya tienen la certificación oficial, son instructores oficiales, o, han sido galardonados con la acreditación oficial de VMware vExpert, se alegraran de esta noticia extraordinaria por parte de Veeam.
Pero Franco ya ha muerto, verdad? Nunca me hubiese imaginado que llegaría a esta situación y menos aún que llegaría a tener que usar mi blog personal para poder despedirme de mis queridos colegas y amigos de las comunidades de VMware Iberia.
La razón fundamental de tener que reproducirlo en este medio, es debido a que mi post de despedida posteado el 13 de Diciembre del 2010 a las 22:30pm en las comunidades de VMware Ibera, ha sido deliberadamente censurado por su reciente moderador Diego Quintana – al cual, contrario a lo que puedas pensar – no le guardo ningún rencor ni desprecio.
Es por lo que me veo obligado a reproducir íntegramente el post de despedida de las comunidades de VMware de Iberia en la entrada de hoy de nuestro blog para poder despedirme de los foros de VMware Iberia.
Estimados amigos/amigas,
El que me conoce, sabe perfectamente que soy un hombre de principios que se viste por los pies y que nunca he aceptado ni aceptare censuras en un foro público y menos aun cuando los hechos son fundados y tomados fuera de contexto.
Es por lo que he decido hacer publica mi postura de NO contribuir de forma activa en los foros de virtualización de VMware de iberia.
He visto crecer esta gran comunidad con halago y placer y me enorgullece enormemente poder haber contribuido con mi granito de arena.
Mucha suerte a todos. Ha sido un placer poder serviros.
Jose Maria Gonzalez
No obstante, este anuncio forzado por la situación, no significa que estaré retirado de la consultoría diaria vía foros.
Por supuesto, podréis encontrarme en nuestros foros de virtualización – SIN CENSURA – en la dirección http://www.josemariagonzalez.es/foros y en los foros de VMware EMEA.
Solo me queda una duda, ¿ quien es la mano negra ?¿ Me ayudas a descubrirla ?Deja tu comentario.
¿ Alguna vez has tenido el problema de máquinas virtuales inaccesibles ?
Es uno de los errores/problemas mas frecuente que se dan en entornos de virtualización con VMware vSphere ESX/ESXi, y que están relacionados, principalmente, por motivos de perdida de acceso al datastore NFS.
En este episodio nos “bajaremos” de nivel – via ssh – para usar el comando vmkmod_load y poder ver así, los módulos del kernel VMware ESX/ESXi que tenemos ejecutando en nuestro servidor VMware vSphere ESX/ESXi.
En este episodio número #50, en concreto, veremos como podemos confirmar que el modulo nfsclient esta arrancado, así como el comando exacto para arrancarlo si este no estuviera cargado en memoria del VMkernel:
Hola amigos, soy Florián Murillo, y voy a narrar lo que es un día normal en nuestras vidas, imagino que os veréis identificados con esta u otra alegría.
Que tendrá el primer cafe de la mañana que siempre tiene que ser interrumpido, esta vez es un ESX que ha dejado de “ver” una tarjeta de 4 puertos ethernet, con los problemas que ya nos podemos imaginar.
Gracias a que este equipo está en un cluster HA (y que es la hora del café) no afecta al negocio, así que procedemos a recuperar el ESX sin el pánico colectivo de épocas anteriores, cuando no existían infraestructuras virtuales.
Tras varias pruebas se decide volver a reinstalar el ESX, por tanto, así procedemos, y tras la reinstalación (manteniendo el datastore local) celebramos que la tarjeta de 4 puertos ethernet vuelve a ser reconocida.
Pero como este trabajo siempre tiene un “pero”, el “pero” de hoy es que los puertos vmnic han cambiado de nombre, no todo podía ser tan fácil.
[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic2 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic3 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic4 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic5 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic6 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic7 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500
Cuando antes de la instalación, según la documentación existente (aquí os he impresionado), la situación anterior era la siguiente:
[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic0 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic1 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic2 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic3 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic4 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic5 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500
Hemos de dejar los interfaces igual que antes, si queremos evitar problemas de diseño e implantación, por tanto pasamos a editar el archivo /etc/vmware/esx.conf
Reiniciamos el host y tras el reboot nos encontramos lo siguiente:
[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic0 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic1 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic2 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic3 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic4 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic5 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500
… lo incluimos de nuevo en el cluster HA y nos tomamos otro café, a ver si este acaba bien …
Hola, soy Jose Maria Gris. He sufrido una intervención quirúrgica de urgencia que me ha dejado durante 3 semanas bastante “off line”. Pero no hay mal que cien años dure…..
De nuevo estoy aquí para hablaros esta vez de dos mundos. El ecosistema de VMware y……. el iPAD!. El Ecosistema se amplía hacia Cupertino .
Que sí! Antes de ir al VMworld de Europa ya me lo había comprado. En Kopenhagen fue increíble ver la concentración de iPAD que había. Y fue allí donde oí que estaban sacando el cliente de vCenter para el iPAD.
Pero no me he podido esperar. Os presento iDatacenter. Disponible en el Appstore a los precios módicos que hay en él. Evidentemente no es un vCenter pero podemos ver lo que está pasando en él y hacer interacciones.
En esta primera pantalla podremos ver la visión general de nuestro Datacenter. El uso de recursos, los disponibles y nuestras VM.
También podemos ver el desglose de nuestro Datacenter en cuanto a hosts se refiere y la vista de VM and templates con sus carpetas administrativas si las hemos creado.
Podemos ver la información que se refiere a un host en concreto. Sus recursos, VMs que corren en el, versión de ESXi que tenemos instalada, sus datastores, incluso, podriamos cambiar el estado del servidor. Podríamos activar el Maintenance mode o bien pararlo.
Por último, evidentemente, nos quedará la vista referente a nuestras VM. Podremos ver como esta el host que la aloja, características de nuestras vms y podremos cambiar el estado de las mismas asi como un storage vMotion de las mismas, aunque no un vMotion.
El autor anuncia nuevas features en breve, de momento a mí lo que hay me funciona muy bien (mejor me va el iPAD), pero bueno. Esperemos el vCenter para iPAD, aunque creo que será un cliente parecido. ¿ O no ?
Bueno, esta pequeña maravilla es lo que tenemos ahora en nuestras manos y es con lo que disfrutamos.
Sois muchos los que diariamente contactáis conmigo para preguntarme las nuevas funcionalidades y precios de VMware vSphere ESX/ESXi 4.1.
Es por lo que hoy, día festivo en España, os propongo que leáis con detenimiento este documento excepcional del web de VMWare donde especifica claramente las nuevas funcionalidades de VMware y las diferentes opciones que hay a la hora de adquirir las licencias.
Es un documento muy interesante que describe, entre otras cosas, las diferentes funcionalidades incluidas en las distintas alternativas de licencias en VMware, que dicho sea de paso, son muchas.
También incluye un apartado donde se describe el proceso de actualización de licencias de VMware versión .3x a las nuevas licencias y las diferentes opciones de actualización que nos proporciona VMware.
Este documento es de obligada lectura para aquellos que tienen pensado actualizar las licencias de versiones anteriores o entender las opciones existentes en cuanto a las funcionalides incluidas en las distintas versiones de licencias de VMware vSphere.
Happy reading y feliz fiesta de la Inmaculada. Felicidades a todas las “Inmaculadas”.
En un post publicado el 22 de noviembre de este mismo año, publique una entrada sobre las políticas de anti-afinidad de un clúster VMware DRS
Permiteme recordate la importancia de VMware Distributed Resource Scheduler (DRS).
Básicamente VMware DRS balancea dinámicamente las máquinas virtuales de un servidor VMware ESX/ESXi a otro servidor o servidores VMware ESX/ESXi para mejorar el tiempo de respuesta de las aplicaciones que las máquinas virtuales contienen.
Cuando un virtual máquina experimenta un aumento de la carga, VMware DRS automáticamente asigna recursos adicionales mediante la redistribución de otras máquinas virtuales entre los servidores físicos.
Sin embargo, VMware DRS no sabe qué servicios dichas máquinas virtuales se están ejecutando con lo que se hace necesario configurar policías de afinidad y anti-afinidad en un clúster VMware DRS.
¿ Te imaginas un clúster VMware DRS donde aplicaciones multi-tier se están ejecutando en diferentes servidores VMware ESX/ESXi y que este se caiga ?
En este episodio número #49 te enseñare a crear políticas de afinidad para tus aplicaciones multi-tier.
De esto modo, VMware DRS se asegurara automáticamente de ejecutar las máquinas virtuales del backend y frontend en un mismo servidor VMware ESX/ESXi y mejor así las latencias de red de estas máquinas virtuales, de modo que la comunicación de red entre dichas máquinas virtuales se “quedan” en un mismo servidor VMware ESX/ESXi.
Hola amigos, soy Florián Murillo y en los cursos de VMware que imparto como VCI detecto que los módulos de networking requieren mas esfuerzos que otros, por eso he pensado que podía ser de utilidad explicar con claridad y brevedad (a ver si lo consigo) como se ha de configurar un switch Cisco Catalyst para conectar sistemas ESX/ESXi.
¿Que nos recomienda VMware?
- Los puertos de los switches donde se conectan los ESX/ESXi se han de configurar con trunk VLAN 802.1q
switchport mode trunk
- Los puertos de los ESX/ESXi no participan de negociación en protocolos como DTP, PAgP o LACP, por tanto desactivar protocolos dinámicos de configuración en los puertos de los switches.
switchport nonegotiate
- Los puertos de los ESX/ESXi no participan en negociaciones de STP (spanning tree protocol) por tanto se ha de desactivar en lor puertos de los switches el envío de BPDUs de STP.
spanning-tree portfast trunk
- En Cisco, la native VLAN es la VLAN por la que circula el tráfico de protocolos de nivel 2, y los que no tiene un tagging de VLAN, por tanto, todos los port-groups han de tener VLAN ID para prevenir que algún tráfico se “cuele” en la native VLAN en vez de “circular” por la VLAN que le toca.
switchport trunk native vlan 99
- Otra cosa a cuidar es que ninguna VLAN tenga el mismo número de VLAN que la native VLAN.
- Todos los puertos de los switches donde se conecta un ESX/ESXi han de permitir, solamente, el paso de las VLANs que se han configurado en la infraestructura virtual.
switchport trunk allowed vlan 10-12, 20
Si vemos la configuración completa del puerto, queda de la siguiente manera:
Estoy de acuerdo que esta configuración no engloba todas las posibilidades y diseños, pero en los temas cubiertos se ajusta a las Best Practices de VMware.
Hola amigos, soy Florián Murillo, a veces me pregunto si todos los host del cluster tienen la misma versión y si todas las VM tienen la misma versión de la placa base.
Recordar que la versión de la placa base virtual define que dispositivos podemos entregar a la VM y que propiedades tiene la blaca base, por ejemplo la ampliación de discos VMDK en caliente o el añadir RAM y vCPUs en caliente.
En un entorno pequeño lo sabemos de memoria, tardamos un segundo en contestar, pero en un entorno mediano o grande no podemos responder tan rápidamente con total garantía.
Actualmente es motivo de problema, intentar añadir un host v.4.0 en un switch distribuido creado en la versión v.4.1, además las auditorías de seguridad dependen de la versión del host (VI3 o vSphere 4), por tanto ya no es una información “curiosa” tener esta información, sino una necesidad para evitar problema y cumplir normativas de seguridad, o sea, disminuir el riesgo del negocio ante problemas de seguridad.
Por tanto, he creado un script que os ayudará a conocer el estado de vuestros sistemas, espero que os ayude:
