Servicios Virtualización y Cloud Computing

Sobre el autor

Florian Murillo

Florián Murillo es CTO y socio fundador de Cloud Consulting, consultora especializada en cloud computing y DataCenter, con mas de 25 años asesorando empresas de todos los tamaños y con amplia experiencia en Seguridad, Virtualización VMware (VCP5 y VCI5) y Networking de Cisco (CCNP, CCDP y CCSP). Actualmente se dedica a ayudar a desarrollar negocios y proyectos en la nube a integradores, consultoras y proveedores de servicio.

Artículos Relativos

13 Comentarios

  1. 1

    Jose Maria Gonzalez

    Hola Florían, excelente post como siempre.

    Solo permiteme añadir, para que nuestros lectores sepan, que una mejor practica de VMware – y es lo que recomiendan – es activar beacon probing con al menos tres tarjetas en teaming o mas.

    Os adjunto este articulo del KB que lo explica mas afondo.

    http://kb.vmware.com/kb/1005577

    Muchas gracias y Felices Fiestas.

    Rgds,
    J.

    Responder
  2. 2

    José Luis Gómez Ferrer de Couto

    Hola chicos,

    Añado y espero no estar en lo equivocado, también es la opción a seleccionar en blades aunque tengan dos NICs, ya que si un switch del chasis pierde conectividad por un enlace, los hosts siguen viendo que tienen conectividad con ese switch, pero no saben que mas allá se ha caído el enlace.

    Un saludo.

    Responder
    1. 2.1

      Jose Maria Gonzalez

      Gracias team.

      Perfecto José Luis y Florián. La pregunta podría ser entonces: habéis visto algún entorno con beacon probing, dos tarjetas en el team y los problemas que comenta VMware en su KB?

      Rgds,
      J.

      Responder
      1. 2.1.1

        José Luis Gómez Ferrer de Couto

        Hola JM:

        Según ese KB es totalmente razonable hacerlo con al menos 3 NICs, ya que sólo con 2, estas se quedan aisladas y ambas dejarían de recibir beacons. Pero entonces, cuando se trabaja con chasis y blades que sólo llevan 2 NICs, ¿cómo controlas que los HOSTs ESX(i) vean que se ha caído un enlace? Al fin al cabo, los switches del chasis están integrados y NUNCA perderán enlace con los blades, a no ser que estos switches se extraigan o averíen.

        Entonces recapitulando, si los blades tienen LINK con los switches del chasis, pero a su vez los switches del chasis no tienen link con los switches de producción, ¿cómo avisas a los blades que se ha perdido ese link?.

        Saludos.

        Responder
        1. 2.1.1.1

          Alfonso López García

          No te puedo decir como funcionan los demás tipos de chasis y tecnologías de Blade.

          Pero en el caso de los blades de HP con tecnologías VirtualConnect existe el denominado “Smart Link” el cual transfiere el estado de los enlaces externos a los blades.

          De este modo, si se caen los enlaces del chasis, los blades saben que no tienen conectividad física externa por uno o varios VirtualConnect, y funciona, por desgracia, lo he comprobado.

          Saludos

          Responder
  3. 3

    Florián

    Aunque la recomendación sea 3 NICs, siempre se puede utilizar con dos NICs, lo que hay que conocer es el comportamiento que tiene, para que la red sea previsible. Con dos NICs con beacon probing, cuando las dos NICs pierden los beacons de la otra NIC, el sistema envía el tráfico de todas las VM por las 2 NICs, con lo que hemos de revisar el diseño para asegurarnos que este comportamiento no nos produzca problemas colaterales. Feliz Noche Buena.

    Responder
  4. 4

    Florián

    @Jose Luis, el caso que planteas, es el ideal de trabajo para beacon probing, SIGUE habiendo link pero NO hay conectividad mas alla del bladecenter. En ese caso, el beacon probing enviaría todo el tráfico por los dos interfaces, solo uno llegará a la red.

    Responder
  5. 5

    Florián

    @todos, creo que el término “link down & beacon probing” puede confundir, significa que utiliza los dos algoritmos para detectar caídas de red, espero no haber confundido a nadie con el término.

    Responder
  6. 6

    CABC

    Mi segundo comentario en este blog empieza por lo mismo que el primero. Mi primera sugerencia es que se corrija el título del post por “Por qué recomiendo beacon probing”

    Mi segundo comentario se refiere al uso del término “dominio de colisión”, específicamente en la frase “…se envía un frame ethernet tipo 0x05FF por broadcast, a todo el dominio de colisión”

    Entiendo que es más una errata que nada, porque el frame se envía a todo el dominio de broadcast, no al dominio de colisión.

    En realidad, el concepto de dominio de colisión es ya casi obsoleto desde que no existen los hubs y las conexiones Ethernet son todas full duplex. Afirmar que se envía al dominio de colisión en el caso de una conexión half-duplex indicaría que el frame transmitido no excede el puerto del switch al que está conectada la tarjeta de red que lo transmite, y en el caso de full duplex que ese frame nunca sale de la tarjeta de red. Estando el estado del arte hace ya una década en conexiones “switcheadas” full duplex, considerar que pudiese enviarse algo al dominio de colisión sería más que nada asumir que hay una conexión funcionando mal (en modo half-duplex)

    Responder
  7. 7

    Florián

    @CABC, muy buenas observaciones las tuyas, gracias por tus aportaciones, que comparto completamente.

    Responder
  8. 8

    CABC

    Había olvidado nombrar otra cosa sobre Beacon Probing, y es que es útil para determinar fallos en VLANs específicas. Si alguien mete la pata y quita en el switch una VLAN de uno de los uplinks, se detectará el problema porque se envía un frame sonda por cada VLAN que tenga al menos una VM/VMkernel/SC conectada al vSwitch. No es raro que alguien sin querer desconfigure una VLAN cuando se tiene un entorno con muchas VLANS, al menos a mí me ha pasado alguna que otra vez.

    Responder
  9. 9

    Florián

    @CABC , tienes razón, pero creo que esto es “harina de otro costal”, ¿no te parece?el maravilloso mundo del “porsi” es el caballo de batalla de los procedimiento y de la gestión del cambio ¿no crees?. Creo que el mundo del “porsi” no cabe en todos los discos fabricados hasta hoy. Todo es poco en este maravilloso mundo.

    Responder

Deja un Comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Una Web de JMG Virtual Consulting, especialistas en Soluciones de Virtualización y Formación Oficial VMware y OpenStack | Copyrights © 2017