Objective 2.1: Configure Advanced Policies/Features and Verify Network Virtualization Implementation
Compare and contrast vSphere Distributed Switch (VDS) capabilities
Funcionalidades que tienen los switch Distribuidos:
- Central Management: administración centralizada para todos los hosts que están asociados al switch.
- Network I/O Control: permite asignar el ancho de a aplicaciones para resolver situaciones en las que varios tipos de tráfico compiten por recursos comunes
- PVLAN Support: permite el uso de VLAN privadas, ampliando la funcionalidad de las VLAN.
- LACP Support: soporte para utilizar Link Aggregation Control Protocol (LACP)
- LLDP Support: permite el uso de Link Layer Discovery Protocol (LLDP) para comunicarse con otros switch de la infraestructura
- NetFlow Support: soporte para utilizar Netflow que permite supervisar los paquetes IP que atraviesan los puertos del switch
- Port Mirroring: permite reflejar el tráfico de un puerto distribuido a otros puertos del switch o a interfaces físicos.
- Ingress and egress traffic shaping: control del ancho de banda de entrada y salida.
- Load Based Teaming: balanceo de carga entre los interfaces físicos teniendo en cuenta la carga de uso de cada uno de ellos
- VM Port Blocking: bloquear de forma individual el puerto asignado a una máquina virtual
- Per Port Policy Settings: aplicar directivas de forma individual a cada puerto del switch
- Port State Monitoring: monitorizar es estado de cada puerto de forma individuarl
- Backup/Restore Network config: permite realizar un backup de la configuración del switch y poder restaurar la configuración desde ese backup.
Create/Delete a vSphere Distributed Switch
Crear un vSphere Distributed Switch
- Accedemos al vSphere Web Client
- Accedemos a la sección de Networking
- Pinchamos con el botón derecho sobre el Datacenter (o sobre una carpeta existente) -> Distributed switch -> New Distributed Switch
- Indicamos el nombre
- Seleccionamos la versión:
- Distributed switch: 6.0.0: Compatible con ESXi 6.0 y versiones posteriores
- Distributed switch: 5.5.0: Compatible con ESXi 5.5 y versiones posteriores
- Distributed switch: 5.1.0: Compatible con ESXi 5.1 y versiones posteriores
- Distributed switch: 5.0.0: Compatible con ESXi 5.0 y versiones posteriores
- En Edit Settings configuramos
- Number of uplinks: la cantidad de interfaces de red físicos (NIC) que se van a utilizar en cada host
- Network I/O Control: permite habilitar esta funcionalidad que permite priorizar el acceso a los recursos de red para ciertos tipos de tráfico de la infraestructura.
- Default Port Group (Create a default port group): permite crear un nuevo grupo de puertos con la configuración predeterminada
- Port Group Name (opcional): nombre del grupo de puertos creado por defecto (si está marcada la opción anterior)
- Finalizamos el asistente con la creación del Switch Distribuido
- Comprobamos que tenemos acceso al nuevo objeto
Borrar un vSphere Distributed Switch
- Accedemos al Switch
- Seleccionamos la opción Delete
- Confirmamos la acción
Add/Remove ESXi hosts from a vSphere Distributed Switch
Agragar Hosts a un vSphere Distributed Switch
Para administrar las redes del entorno vSphere con vSphere Distributed Switch, tras crearlo, tenemos que añadir los servidores host al switch Prerequisitos
- Comprobamos que tenemos disponibles los interfaces de red físicos en el host Procedimiento
- Accedemos a vSphere Web Client
- Accedemos al objeto vSphere Distributed Switch
- Seleccionamos la opción Add and Manage Hosts
- Seleccionamos Add Hosts
- Añadimos los hosts que queremos agregar al switch
- Seleccionamos las tareas que queremos realizar al agregar los hosts
- Manage physical adapters
- Manage VMkernel adapters
- Migrate virtual machine networking
- Manage advanced host settings
- Tenemos que marcar al menos una de las tareas
- Seleccionamos los interfaces físicos de red que se van a utilizar por cada host
- Seleccionamos el interfaz (vmnicX) y pinchamos en Assign uplink
- Seleccionamos el uplink del switch al que asociamos el interfaz
- Repetimos los pasos hasta configurar todos los interfaces deseados para cada host
- El asistente analiza el impacto del cambio de configuración
- Sin Impacto: iSCSI continuará con su funcionamiento normal después de aplicar la nueva configuración de redes
- Impacto importante: El funcionamiento normal de iSCSI podría interrumpirse si se aplica la nueva configuración
- Impacto crítico: el funcionamiento normal de iSCSI se verá interrumpido si se aplica la nueva configuración de redes
- Finalizamos el asistente
- Comprobamos que los hosts se han agregado al switch
Eliminar hosts de un vSphere Distributed Switch
- Accedemos al switch
- Seleccionamos Add and Manage Hosts
- Seleccionamos la opción Remove Hosts
- Añadimos el host que vamos a quitar del switch
- Finalizamos el asistente
Add/Configure/Remove DVPort Groups
Agregar un grupo de puertos distribuidos (DVPort Groups)
- Accedemos al switch
- Seleccionamos Distributed Port Group -> New Distributed Port Group…
- Indicamos el nombre del Grupo de puertos
- Configuramos las siguientes opciones:
- Port binding: Ejeimos como se asignan los puertos a las máquinas virtuales Static binding: se asigna un puerto a una máquina virtual cuando la máquina virtual se conecta al grupo de puertos distribuido. Dynamic binding: se asigna un puerto a una máquina virtual la primera vez que se enciende la máquina virtual después de conectarla al grupo de puertos distribuido. (Opción obsoleta) *Ephemeral: no hay una asignación de puertos.
- Port allocation Elastic: la cantidad predeterminada de puertos es ocho. Cuando se asignan todos los puertos, se crea un nuevo conjunto de 8 puertos. Fixed: la cantidad predeterminada de puertos es ocho y no se crean puertos adicionales cuando todos los puertos están asignados.
- Number of ports: es la cantidad de puertos del grupo distribuido
- Network resource pool: permite asignar el nuevo grupo de puertos a un grupo de recursos de red ya definido.
- VLAN: indica el tipo de VLAN None: no se utiliza ninguna VLAN VLAN: es necesario indicar el VLAN ID (un número entre 1 y 4094) VLAN Trunking: es necesario indicar un rango de VLAN IDs Private VLAN: podemos elegir una VLAN privada creada previamente
- Advanced: marcamos la casilla para personalizar la configuración de las directivas del grupo de puertos
- Si hemos marcado la casilla Customize default policies configuration, iremos configurando las distintas opciones de configuración que veremos más adelante: Security, Traffic shapping, Teaming…
- Finalizamos el asistente
Configure DVPort Groups
- Accedemos al grupo de puertos distribuidos
- Accedemos a la pestaña Manage -> Settings -> Properties
- Si pinchamos en el botón Edit… accedemos a las opciones que hemos configurado al crear el grupo de puertos
- Podemos configurar las siguientes opciones
- Advanced
- Seciruty
- Traffic shaping
- VLAN
- Teaming and failover
- Monitoring
- Traffic filtering and marking
- Miscellaneous
Remove DVPort Groups
- Accedemos al grupo de puertos
- Seleccionamos la opción Delete
- Confirmamos la acción
Add/Remove uplink adapters to DVUplinks groups
Agregar interfaces de red físicos (NIC) en un host a un vSphere Distributed Switch
- Accedemos al host ESXi
- Accedemos a Manage -> Networking -> Virtual switches
- Seleccionamos el switch Distribuido
- Pinchamos en el botón Manage the physical network adapters
- Añadimos el interfaz de red pinchando en el botón
- Comprobamos que se ha añadido correctamente
Quitar un intefaz de red físico (NIC) de un vSphere Distributed Switch
- Accedemos al host ESXi
- Accedemos a Manage -> Networking -> Virtual switches
- Seleccionamos el switch Distribuido
- Pinchamos en el botón Manage the physical network adapters
- Seleccionamos el interfaz vmnicX y pinchamos en el botón
Configure vSphere Distributed Switch general and DVPort group settings
Configure vSphere Distributed Switch general
- Accedemos al Switch Distribuido
- Accedemos a Actions -> Settings -> Edit Settings
- En la sección General, podemos modificar los siguientes valores
- Name
- Number of uplinks
- Network I/O Control
- Description
- En la sección Advanced, podemos modificar los siguientes valores:
- MTU /Bytes): tamaño máximo de MTU
- Multicast filtering mode Basic: el switch distribuido reenvía el tráfico relacionado con un grupo multicast en función de una dirección MAC generada a partir de los últimos 23 bits de la dirección IPv4 del grupo IGMP/MLD snooping: el switch distribuido reenvía el tráfico multidifusión a las máquinas virtuales en función de las direcciones IPv4 e IPv6 de los grupos multicas suscritos mediante mensajes de pertenencia definidos por el protocolo IGMP y MLD
- Discovery Protocol *Type
- Cisco Discovery Protocol
- Link Layer Discovery Protocol
- Disabled *Operation
- Listen
- Advertise
- Both
- Administrator contact: nombre y detalles del administrador del Switch Distribuido
- Name
- Other details
- Administrator contact: nombre y detalles del administrador del Switch Distribuido
Create/Configure/Remove virtual adapters
En este caso la configuración la realizamos en cada host
- Accedemos al host ESXi
- Manage -> Networking -> VMkernel adapters
Create Virtual Adapters
- Pinchamos en el icono Add Host Networking
- Seleccionamos el tipo VMkernel Network Adapter
- Seleccionamos el switch al que se va a conectar el nuevo VMkernel
- Select an existing network: permite elegir un grupo de puertos de un switch distribuido
- Select an existing standard switch: permite elegir un switch estándar existente
- New standard swich: permite crear un nuevo switch estándar al que conectar el VMkernel
- Configuramos el tipo de servicio y el stack TCP/IP
- TCP/IP stack: Después de elegir una pila TCP/IP para el VMkernel no es posible cambiarla más adelante Default: soporta todos los tipos de tráfico: administración, vMotion, IP Storage, Fault Tolerance… vMotion: soporta el tráfico utilizado para vMotion. Si configuramos un VMkernel con vMotion TCP/IP stack, sólo se podrá utilizar esta configuración para realizar vMotion. Provisioning: soporta el tráfico utilizado para la migración, clonación y creación de snapshots. Si se configura este stack para un VMkernel, se deshabilitar el tráfico Provissioning en el resto de VMkernel Custom: stack creado de forma manual.
- Available services
- Management traffic: se utiliza para la comunicación entre el host ESXi y el servidor vCenter, para el tráfico entre host de HA. Se recomienda dos o más interfaces físicos (NIC) para proporcionar redundancia.
- vMotion traffic: se utiliza para el tráfico vMotion entre servidores host ESXi. Para un mayor rendimiento se pueden utilizar múltiples interfaces de red con diferentes vMotion VMkernel.
- Provisioning traffic: utilizado para el tráfico utilizado al clonar, migrar o crear snapshots.
- Fault Tolerance traffic: utilizado por el tráfico que la máquina virtual primaria envía a la máquina virtual secundaria configurada con Fault Tolerance.
- vSphere Replication traffic: el tráfico saliente que se transfiere entre servidores ESXi con vSphere Replication
- vSphere Replication NFC traffic: la entrada para el tráfico de replicación de vSphere Remplication
- Virtual SAN traffic: se utiliza para el tráfico VSAN si el host pertenece a un cluster Virtual SAN
- Configuramos un puerto para tráfico vMotion
- Asignamos la dirección IP al VMkernel
- DHCP
- Static: las opciones de Default Gateway y DNS server addresses están definidas por el stack seleccionado en el punto anterior
- Resumen del VMkernel que vamos a crear
- VMkernel creado
Configure Virtual Adapters
- Seleccionamos el adaptador VMkernel
- Pinchamos en el icono Edit Settings
- En Port Properties, podemos cambiar el tipo de tráfico
- En NIC settings podemos cambiar el tamaño MTU
- En IPv4 settings podemos cambiar la dirección IP asignada
- En Analyze impact se muestra si hay algún impacto en la configuración al utilizar adaptadores con iSCSI software
Remove Virtual Adapters
- Seleccionamos el adaptador VMkernel y pinchamos en el botón Remove Selected Network Adapter
- Podemos borrar directamente el adaptador o analizar el impacto en el almacenamiento iSCSI
- Si pinchamos en Analyze impact
Migrate virtual machines to/from a vSphere Distributed switch
- Seleccionamos Migrate VM to Another Network desde un objeto Datacentero un Switch Distribuido
- Seleccionamos la red origen
- Specific network y utilizamos el botón Browse para seleccionar una red específica
- No network, para migrar todos los adaptadores de red de máquinas virtuales que no están conectados a ninguna red
- Seleccionamos la red de destino
- Seleccionamos las máquinas virtuales y los interfaces que queremos migrar
- Finalizamos el asistente
Configure LACP on VDS given design parameters
Esquema general de conectividad LACP en servidores ESXi
Es necesario configurar el Switch físico con las siguientes características:
- Crear un canal de puerto LACP
- La cantidad de puertos en el canal de puerto LACP debe ser igual a la cantidad de interfaces físicos de red que se desean agrupar en el host
- El algoritmo de hash debe ser el mismo que se configurará en el Switch Distribuido
- Todas las NIC físicas que se conecten al canal de puerto LACP se deberán configurar con la misma velocidad y dúplex.
Limitaciones de LACP
- No admite el software para habilitar iSCSI multipath
- No está disponible en Host Profile
- No está disponible en Nested ESXi
- No funciona con ESXi Dump Collector
- No funciona con Port Mirroring
- El Health Check de Teaming And Failover no funciona en los puertos LAG
- La compatibilidad con LACP mejorada funciona correctamente cuando solo un LAG gestiona el tráfico por puerto distribuido o por grupo de puertos
- LACP 5.1 soporta solo IP Hash Load Balancing y Link Status Network failover
- LACP 5.1 soporta solo un LAG por switch y por host
Para configurar LACP en un Switch Distribuido seguimos estos pasos:
- Accedemos a Manage -> Settings -> LACP en el Switch Distribuido
- Para crear un enlace LAG pinchamos en el icono New Link Aggregation Group
- Configuramos el LAG
- Asignamos un nuevo nombre
- Iniciamos el número de puertos (tiene que ser el mismo número que el canal del puerto LACP configurado en el switch físico)
- Mode Active: Todos los puertos LAG están en modo de negociación activa. Los puertos de LAG inician negociaciones con el canal de puerto LACP Pasive: Los puertos de LAG están en modo de negociación pasiva. Responden a los paquetes LACP que reciben pero no inician una negociación LACP
- Load balancing mode: tiene que ser el mismo configurado en el switch físico.
- VLAN y NetFlow: se configuran estas políticas cuando está configurado que los puertos puedan sobreescibir la configuración.
- Vemos el LAG creado
- También lo podemos ver a nivel de host
Migrar el tráfico al LAG creado
Seguimos los pasos indicados en la siguiente ventana
- Configuramos el LAG como standby en el grupo de puertos
- Accedemos a las propiedades del grupo de puertos
- Editamos la opción Teaming and failover
- Colocamos el LAG como Standby uplinks
- Aceptamos el mensaje de advertencia de que esta configuración solo está soportada como paso intermedio para migrar un grupo de puertos a LAG.
- Asignamos los interfaces físicos del host al LAG
- En el Swtich Distribuido seleccionamos Add and Manage Hosts…
- Seleccionamos Manage host networking
- Añadimos los hosts a configurar
- Seleccionamos Manage Physical Adapters
- Asignamos los interfaces físicos de cada host al LAG
- Se analiza el impacto del cambio de configuración
- Finalizamos el asistente
- Establecemos el LAG como uplink activo en el grupo de puertos
- Accedemos a las propiedades del grupo de puertos
- Editamos la opción Teaming and failover
- Colocamos el LAG como Standby uplinks
- Podemos ver cómo queda la configuración
Describe VDS security Policies/Settings
La directiva de seguridad ayuda a proteger el tráfico contra la suplantación de direcciones MAC y la exploración de puertos no deseada.
- Promiscuous Mode: el modo promiscuo quita el filtrado de recepción que realiza el adaptador de la máquina virtual con el objetivo de que la máquina virtual reciba todo el tráfico que se observa en la conexión.
- Accept: la máquina virtual recibe todos los paquetes, incluso los que no están destinados a ella. Puede ser útil habilitarlo en ocasiones en las que se utiliza software de detección de intrusiones de red o analizador de tráfico
- Reject: el filtrado es efectivo, y la máquina virtual recibe sólo el tráfico destinado a ella.
- MAC Address Changes: afecta al tráfico que recibe una máquina virtual
- Accept: el servidor ESXi acepta las solicitudes de cambiar la dirección MAC efectiva por una dirección diferente a la inicial
- Reject: el servidor ESXi no acepta las solicitudes de cambiar la dirección MAC efectiva por una dirección diferente a la inicial. El puerto que utilizó el adaptador de la máquina virtual para enviar la solicitud se deshabilita y el adaptador de la máquina virtual no recibe más tramas hasta que la dirección MAC efectiva coincida con la MAC inicial. En ciertas ocasiones (como por ejemplo en ciertas configuraciones del balanceador de carga de Microsoft, NLB) es necesario que esta opción esté en Accept
- Forged Transmits: afecta al tráfico que se envía desde una máquina virtual
- Accept: el servidor ESXi no compara las direcciones MAC origen y efectiva.
- Reject: El host compara la dirección MAC de origen y la dirección MAC efectiva. Si las direcciones no coinciden, el host ESXi descarta el paquete
Configure DVPort group blocking policies
Las directivas de bloqueo de puertos permiten bloquear selectivamente el envío o la recepción de datos en los puertos.
En el grupo de puertos distribuido podemos bloquear todos los puertos del grupo accediendo al apartado Miscellaneous de las directivas del grupo de puertos. También podemos bloquear de forma individual los puertos del switch, editando las propiedades de cada puerto.
Configure Load Balancing and Failover policies
La directiva de equilibrio de carga determina de qué forma se distribuye el tráfico entre los adaptadores de red de un host. En los switch de vSphere, el equilibrio de carga se aplica solamente al tráfico saliente. La directiva de detección de errores de red permite establecer los métodos y el comportamiento ante errores en los interfaces físicos.
- Load Balancing:
- Route based on the originating virtual port: enruta según el Puerto virtual de origen por donde el tráfico entró al conumtador distribuido *Ventajas:
- Una distribución equilibrada del tráfico si tenemos más NIC virtuales que físicos
- Bajo consumo de recursos
- No se requieren cambios en el switch físico *Desventajas
- El switch virtual no equilibra la carga del tráfico utilizando los interfaces de red menos utilizados
- El ancho de banda disponible para una máquina se limita a la velocidad de un interfaz de red
- Route based on IP hash: enuta el tráfico basado en un hash de las direcciones IP de origen y de destino de cada paquete. *Ventajas:
- Se logra una distribución más uniforme de la carga
- Una mejor capacidad de proceso potencial para las máquinas que se comunican con varias direcciones IP *Desventajas
- Más consumo de recursos
- El switch no reconoce la carga real de al red
- Se requieren cambios en la red física
- El proceso de solución de problemas es complejo
- Route based on source MAC hash: enruta según el hash de MAC de origen *Ventajas:
- Se logra una distribución más equilibrada del tráfico que con la opción Route Base don Originating Virtual Port
- Las máquinas virtuales utilizan siempre el mismo interfaz de red (mientras no cambie la MAC virtual)
- No se requieren cambios en el switch físico *Desventajas
- El ancho de banda disponible para una máquina se limita a la velocidad de un interfaz de red
- Más consumo de recursos que Route Base don Originating Virtual Port ya que calcula el hash por cada paquete
- El switch no reconoce la carga de tráfico por lo que puede sobrecargar los interfaces y no equilibrarlo de forma correcta utilizando los que más ancho de banda tienen disponible
- Route based on physical NIC load: enruta según la carga del interfaz físico *Ventajas:
- El consumo de recursos es bajo
- El switch reconoce la carga de tráfico y equilibra de una mejor forma el tráfico por los interfaces
- No se requieren cambios en el switch físico *Desventajas
El ancho de banda disponible en las máquinas virtuales es el límite de velocidad de cada interfaz físico
- Use explicit failover order: no hay ningún equilibrio de carga. Utiliza siempre el orden indicado en los adaptadores activos.
Network failure detection: indica que método de detección se utilizará para detectar un error en el interfaz
- Link Status only: detecta el estádo del adaptador de red. Detecta errores como cables extraídos y errores de alimentación, pero no errores de configuración.
- Beacon Probing: permite detectar más tipos de errores que solo los detectados por el estado, utilizando paquetes de prueba. Se utiliza con 3 o más interfaces de red.
- Notify switches
- Yes: notifica a los switch externos en caso de una conmutación por error para actualizar las tablas del switch remoto.
- No: no se notifica a los switch
- Failback: esta opción determina de qué forma un adaptador de red físico vuelve a activarse después de recuperarse de un error.
- Yes: el adaptador vuelve a servicio active inmediatamente después de recuperarse
- No: un adaptador con errores de deja inactivo incluso después de recuperarse, hasta que otro adaptador activo presente errores y sea necesario sustituirlo
- Failover order: indica el estado y orden de los adaptadores de red
- Active Uplinks: son los adaptadores que se utilizan si están activos y funcionando
- Standby Uplinks: se utiliza si uno de los adaptadores activos no está funcionando
- Unused Uplinks: no se utilizan estos adaptadores
Configure VLAN/PVLAN settings for vms given communications requirements
vSphere admite tres modos de etiquetado de VLAN en ESXi
- External Switch Tagging (EST): el switch físico ejecuta el etiquetado de VLAN
- Virtual Switch Tagging (VST): el switch virtual realiza el etiquetado VLAN antes de que los paquetes salgan del host ESXi. Los interfaces se configuran en un trunk de VLAN.
- Virtual Guest Tagging (VGT): la máquina virtual ejecuta el etiquetado VLAN y el switch virtual mantiene las equitas VLAN en los paquetes. Los interfaces se configuran en un trunk de VLAN. VLAN privadas Las VLAN privadas permiten agregar una segmentación adicional del dominio de difusión en varios subdominios de difusión más reducidos. Una VLAN privada se identifica con el identificador VLAN principal y un identificador VLAN secundario. Las VLAN principales son Promiscuous para que los puertos de una VLAN privada puedan comunicarse con puertos configurados como VLAN principal Los puertos en una VLAN secundaria pueden ser:
- Isolated: se comunican sólo con puertos Promiscuous
- Community: se comunican tanto con puertos Promiscuous como con puertos que están en la misma VLAN secundaria En vSphere sólo podemos utilizar las VLAN privadas en Switch Distribuidos
Crear una VLAN privada
- Accedemos al Switch Distribuido
- Manage -> Settings -> Private VLAN
- Pinchamos en el botón Edit
- Añadimos una VLAN principal
- Agregamos una VLAN secundaria indicando el ID y el tipo de VLAN
- Cerramos la ventana y comprobamos la configuración creada
- Asignamos a un grupo de puertos distribuido la VLAN correspondiente
- Seleccionamos el tipo Private VLAN y a continuación la VLAN secundaria deseada
Configure traffic shaping policies
La política de Traffic Shapping permite establecer límites para la cantidad de ancho de banda tanto en tráfico entrante (Ingress) como tráfico saliente (Egress) del grupo de puertos
Para cada tipo de tráfico (Ingress o Egress) se configuran las siguientes opciones:
- Status: permite habilitar o deshabilitar los límites
- Average bandwith (kbit/s): establece la cantidad de bits por segundo permitida para atravesar un puerto, promediada en el tiempo. Esta es la carga promedio permitida
- Peak bandwidth (kbit/s): la cantidad máxima de bits por Segundo que se permitirá en un puerto para el envío o recepción de una ráfaga de tráfico. Esta cantidad máxima supera el ancho de banda utilizado por un puerto cada vez que este utilice las ráfagas adicionales
- Burst Size (KB): es la cantidad máxima de bytes que se permiten en una ráfaga. Cada vez que el puerto necesite más ancho de banda que el especificado en Average bandwidth podrá transmitir temporalmente datos a una velocidad mayor si está disponible una ráfaga de tráfico.
Enable TCP Segmentation Offload support for a virtual machine
TCP Segmentation Offload (TSO) permite configurar que componente realza la segmentación de los paquetes de red, el adaptador físico, el servidor ESXi, la máquina virtual… El adaptador de red de la máquina virtual tiene que ser de tipo VMXNET2 o VMXNET3 Configuración en un equipo Linux
- Para hablitar TSO ejecutar
- ethtool –K ethY tso on
- Para deshabilitar TSO ejecutar
- ethtool –K ethY tso off Donde ethY identifica el adaptador de red en la máquina virtual
Configuración en un equipo Windows
- Accedemos a las propiedades del adaptador de red
- Pinchamos en Configurar
- En la pestaña Opciones avanzadas marcamos la opción de Enabled/Disabled en las opciones
- Large Send Offload V2 (IPv4)
- Large Send Offload V2 (IPv6)
Enable Jumbo Frames support on appropiate components
Jumbo Frames permite que los host ESXi envíen tramas de tamaño más grande hacia la red física. Todos los componentes de la red deben de ser compatibles con Jumbo Frames
Habilitar Jumbo frames en vSphere Distributed Switch
- Accedemos al switch Distribuido
- Manage -> Settings -> Properties
- Pinchamos en Edit
- En Advanced, establecemos el valor MTU mayor de 1500. El tamaño máximo es 9000 bytes
Habilitar Jumbo Frames en vSphere Standard Switch
- Accedemos al host ESXi
- Manage -> Networking -> Virtual switches
- Editamos el vSwitch
- Establecemos el valor MTU
Habilitar Jumbo Frames en un adaptador VMkernel
- Accedemos al host
- Manage -> Networking -> VMkernel adapters
- Editamos el adaptador VMkernel
- Indicamos el valor MTU
Habilitar Jumbo Frames en una máquina virtual
- Nos aseguramos que el interfaz de red virtual es de tipo VMXNET2 o VMXNET3
- Configuramos el sistema operativo
- En Linux
- En Windows
Recognize behavior of VDS Auto-Rollback
A partir de la version vSphere 5.1, la función rollback permite recuperar la configuración de red ante errores de configuración que provoquen problemas de conectividad. La opción de Rollback está habilitada por defecto. Los siguientes ejemplos muestran un ejemplo de configuración que pueden desencadenar un rollback en la configuración de red de un servidor ESXi:
- Actualización de la velocidad o la función dúplex de una NIC física
- Actualización de la configuración de DNS y de enrutamiento
- Cambio de las siguientes opciones del grupo de puertos que contiene el adaptador de red VMkernel de administración
- Teaming and failover
- VLAN
- Traffic shaping
- Incrementar el valor MTU del adptador VMkernel a un valor no admitido por la infraestructura física
- Cambio de la configuración de IP de los adaptadores de red VMkernel de administración
- Quitar el adaptador de red VMkerel de administración del switch
- Quitar una NIC física de un switch que contenta el adaptador VMkernel de administración
- Migrar el adaptador VMkernel de un switch estándar a un switch distribuido Los siguientes cambios muestran los cambios de configuración que activan el rollback en un switch distribuido
- Cambio del valor MTU de un switch distribuido
- Cambio de las siguientes opciones del grupo de puertos que contiene el adaptador de red VMkernel de administración
- Teaming and failover
- VLAN
- Traffic shaping
- Bloqueo de todos los puertos del grupo de puertos que contiene el adaptador VMkernel de administración
- Anulación de las directivas en el nivel de puerto distribuido del adaptador VMkernel de administración
Explain the behavior of a vSphere Distributed Switch (VDS) Auto-Rollback
Vamos a ver algunos ejemplos de cómo funciona Auto-Rollback
- Configuramos una dirección IP del VMkernel de administración de forma incorrecta
- El VMkernel del servidor está asociado a un grupo de puertos del switch distribuido
- Vamos a introducir una configuración IP en el VMkernel que provocará una desconexión con el servidor vCenter
- El cambio de IP se realiza en el servidor y llegamos a perder algunos paquetes
- Como vemos, al cabo de unos segundos se inicia el Rollback volviendo a la configuración anterior
- Configuramos una VLAN incorrecta en el grupo de puertos del VMkernel de administración
- Establecemos una VLAN ID incorrecta
- Tras unos segundos se restablece la configuración inicial
Configure VDS across multiple vCenter Servers to support Long Distance vMotion
Para habilitar la migración entre instancias de vCenter Server, el sistema debe cumplir con ciertos requisitos.
- Las instancias de origen y destino de vCenter Server y los hosts ESXi deben contar con la versión 6.0 o una posterior.
- Ambas instancias de vCenter Server deben estar en Enhanced Linked Mode y tienen que estar en el mismo dominio de vCenter Single Sign-On de manera que vCenter Server de origen pueda autenticarse en vCenter Server de destino.
- Ambas instancias de vCenter Server tienen que estar sincronizadas en la fecha y hora
- Ambas instancias de vCenter Server deben estar conectadas al almacenamiento en el que se encuentra la máquina virtual
La migración de máquinas virtuales entre instancias de vCenter Server transfiere la máquina virtual a redes nuevas. El proceso de migración realiza comprobaciones para constatar que las redes de origen y de destino sean similares. vCenter Server realiza una serie de comprobaciones de compatibilidad de red para prevenir los siguientes problemas de configuración:
- Compatibilidad de la dirección MAC en el host de destino
- Transferencia de vMotion de un conmutador distribuido a un conmutador estándar
- Transferencia de vMotion entre conmutadores distribuidos de versiones diferentes
- Transferencia de vMotion a una red interna (por ejemplo, una red sin una NIC física)
- Transferencia de vMotion a un conmutador distribuido que no funciona correctamente vCenter Server no realiza comprobaciones y no envía notificaciones en relación con los siguientes problemas:
- Si los conmutadores distribuidos de origen y de destino no se encuentran en el mismo dominio de difusión, las máquinas virtuales pierden la conectividad de red después de la migración.
- Si los conmutadores distribuidos de origen y de destino no tienen los mismos servicios configurados, es posible que las máquinas virtuales pierdan la conectividad de red después de la migración.