Tema 2: VMWARE VSPHERE. ENTENDER EL NETWORKING

Transcripción

1 Orense, Madrid D`Aribau, Barcelona Tema 2: VMWARE VSPHERE. ENTENDER EL NETWORKING Parte 1 - Cómo funcionan los adaptadores virtuales de Ethernet Parte 2 - Switches virtuales en VMware estándar y distribuidos Parte 3 - Componentes ESX Server para Networking Parte 4 - VLAN en la infraestructura de VMware Parte 5 - Agrupación de enlaces de red para capacidad y disponibilidad Formadores IT, Todos los derechos reservados. Prohibida su reproducción total o parcial.

2 2.1.1 Tipos de adaptadores virtuales dentro de MV Como hemos visto en el módulo anterior de Buenas Practicas, disponemos de varios tipos de adaptadores de red para asignar a nuestras máquinas virtuales. A diferencia de otro tipo de recursos, en los adaptadores de red no estamos compartiendo un recurso físico existente entre varias máquinas virtuales. En este caso es imposible tener sobreasignación de adaptadores, todo dependerá del ancho de banda disponible desde el nodo hasta la red física y de la cantidad de tráfico que se queda dentro del nodo. Ya que este es el motivo por el cual los adaptadores virtuales no tienen una representación física por cada uno. La forma más clara de imaginárnoslos es visualizando el switch virtual que crea el hipervisor ESXi y luego tenemos varias conexiones completamente lógicas a los puertos que provee nuestro switch virtual. Todo el tráfico que se quede dentro el switch virtual no consume nada de red física y además tenemos un ancho de banda casi ilimitado ya que nos quedamos dentro de la memoria física del nodo. Por tanto puede ser interesante definir políticas de afinidad entre máquinas virtuales que se comunican mucho para que estén siempre en el mismo nodo, con lo que ganaremos en rendimiento y reduciremos los recursos físicos de red necesarios. Esta característica la aprovechan las VSA (Virtual Storage Appliances) que en casos muy específicos, por ejemplo en virtualización de escritorios (VDI) se convierten en proveedoras de almacenamiento de los escritorios (Windows 7, XP, Linux, etc ) alojados en el mismo nodo. vsphere presenta a las máquinas virtuales varios tipos de adaptadores, escoger uno u otro dependerá del uso que le vayamos a dar a esa máquina virtual y el sistema operativo que instalaremos. Debemos tener en cuenta que no todos los sistemas operativos soportan todos adaptadores ni existen controladores para todas las combinaciones posibles. Los adaptadores paravirtualizados y que por tanto no pueden emular un adaptador específico del mundo físico requerirán de las Vmware Tools, así que si por cualquier motivo no las podemos instalar en esa máquina, no deberíamos seleccionar ninguno de los adaptadores de la familia VMXnet. En la interfaz de vsphere Client solo se nos muestran los adaptadores compatibles con el tipo de sistema operativo que hemos seleccionado para nuestra máquina virtual. Las opciones que tendríamos para un sistema que los soporte todos serían: Vlance Una versión emulada de la tarjeta de red AMD 79C970 PCnet32- LANCE, una antigua tarjeta de 10Mbps con controladores disponibles para la mayoría de sistemas operativos de 32 bits excepto Windows Vista y posteriores. Al estar disponibles los controladores en el propio sistema operativo alojado, esa máquina dispondrá de conectividad de red desde el inicio. VMXNET El adaptador virtual VMXnet no tiene una versión física del mismo. VMXnet está optimizado para el rendimento de la máquina virtual. Ya que los proveedores de sistemas operativos no incluyen un controlador para este tipo de tarjeta, no obtendremos conectividad de red hasta instalar las Vmware Tools que incluyen el controlador adecuado. Flexible El adaptador virtual Flexible se identifica como Vlance cuando la máquina virtual arranca y luego funciona como VMXnet o VLance dependiendo de qué controlador lo inicializa. Con las Vmware Tools instaladas, el controlador VMXnet cambia el adaptador Vlance hacia el VMXnet de mayor rendimiento. E1000 Es una versión emulada de las tarjetas Gigabit Ethernet basadas en Intel 82545EM. Un controlador para este tipo de tarjeta no está incluido siempre con el sistema operativo pero los Linux basados en versión y posteriorers, los Windows XP Professional x64 y los Windows Server 2003 (32 bits) y posteriores ya incluyen el controlador adecuado para E1000. De esta forma

3 obtendremos conectividad antes de instalar las VMtools. Nota: E1000 solo soporta paquetes jumbo en ESX/ESXi 4.1 y posteriores. E1000e Emula una versión más moderna de una tarjeta Gigabit Ethernet de Intel, la Tiene el nombre interno de e1000e vnic. Este tipo de tarjeta solo estará disponible en hardware de la versión 8 y más nuevos, es decir vsphere 5. Además también será la tarjeta virtual por defecto para Windows 8 y posteriores. Para Linux, a e1000e no estará disponibles desde vsphere Client, y en caso de necesitarla deberemos modificar el fichero XML que describe el hardware de la máquina. VMXNET 2 (Enhanced) El adaptador virtual VMXNET 2 está basado en el VMXnet pero ofrece algunas funcionalidades de alto rendimiento que normalmente se encuentran en las redes modernas, como paquetes jumbo y descarga de procesamiento al HW. Este tipo de adaptador solo está disponible para algunos sistemas operativos alojados en ESX/ESXi 3.5 y superiores. VMXNET 2 está soportado en los siguientes sistemas operativos: Versiones de 32 y 64 bits de Microsoft Windows 2003 (Enterprise, Datacenter, y Standard). Nota: Se puede usar VMXnet 2 con otras versiones de Windows 2003, pero se requieren cambios en el vsphere Client si VMXnet 2 no está disponible. Microsoft Windows XP Professional de 32 bits. Versiones de 32 y 64 bits de Red Hat Enterprise Linux 5.0. Versiones de 32 y 64 bits de SUSE Linux Enterprise Server 10. Versiones de 64 bits de Red Hat Enterprise Linux 4.0. Versiones de 64 bits de Ubuntu Linux. En ESX 3.5 Update 4 o superior, se añadió soporte para: Microsoft Windows Server 2003, Standard Edition (32-bit). Microsoft Windows Server 2003, Standard Edition (64-bit). Microsoft Windows Server 2003, Web Edition. Microsoft Windows Small Business Server VMXNET 3 VMXnet 3 es la siguiente generación de adaptadores de red paravirtualizados diseñados para el rendimiento, y no está relacionado con los VMXnet o VMXnet 2. Ofrece todas las funcionalidades disponibles en VMXnet 2 y añade funcionalidades como soporte para multiples colas (Windows lo llama Recieve Side Scaling o RSS), descarga hacia el hardware para IPv6 y entrega de interrupciones MSI/MSI-X de forma que se repartan entre las vcpus. VMXNET 3 está soportado solo para máquinas virtuales con hardware de la versión 7 o superiores y en los siguientes sistemas operativos: Versiones de 32 y 64 bits de Microsoft Windows XP,7, 2003, 2003 R2, 2008, y 2008 R2. Versiones de 32 y 64 bits de Red Hat Enterprise Linux 5.0 y posteriores. Versiones de 32 y 64 bits de SUSE Linux Enterprise Server 10 y posteriores. Versiones de 32 y 64 bits de Asianux 3 y posteriores. Versiones de 32 y 64 bits de Debian 4. Versiones de 32 y 64 bits de Ubuntu 7.04 y posteriores. Versiones de 32 y 64 bits de Sun Solaris 10 U4 y posteriores. Notas: Los paquetes Jumbo no están soportados en sistemas alojados basados en Solaris con adaptadores VMXnet 2 o VMXnet 3. La tolerancia a fallos (FT) no está soportada en máquinas virtuales con adaptadores VMXnet 3 en vsphere 4.0, pero si que está soporta en vsphere 4.1 y posteriores. Dependiendo del tipo de sistema operativo alojado, tendremos varias opciones de tipo de adaptador, aquí se muestran algunas.

4 3 de 3 06/07/ :36

5 2.1.2 Configuración de un adaptador virtual en ESXi El adaptador virtual visto por ESXi es por donde pasaremos el tráfico de VMkernel, este adaptador como el resto de adaptadores virtuales que asignados a las máquinas virtuales debe estar vinculado a un switch virtual, ya sea estándar o distribuido. En el caso del adaptador virtual dedicado a VMkernel, no estamos emulando ningún dispositivo, sino que trabaja en modo nativo y no se nos da posibilidad de influir en su comportamiento. Lo que si podemos hacer, a parte de asignarle una dirección IP, mascara y posiblemente puerta de enlace es indicar para que lo pueda utilizar ESXi y habilitar funciones que nos permitan mejorar el rendimiento. Usos que podemos asignar al adaptador: vmotion: Usaremos este adaptador para el tráfico vmotion, habilitamos que ese adaptador se utilice para migrar máquinas virtuales de un nodo a otro. Fault Tolerance: Utiliza este adaptador VMkernel para sincronizar máquinas virtuales protegidas por FT. Almacenamiento IP: Se usará para conectar con cualquier almacenamiento basado en IP que sea soportado por ESXi. Management: Podremos utilizar ese puerto para acceder por SSH o gestionar nuestro nodo ESXi.

6 La pila TCP/IP en VMkernel proporciona soporte de red de varias maneras por cada uno de los servicios que permite. La pila TCP/IP de VMkernel trata iscsi, NFS y vmotion de la siguiente manera: iscsi como datastore de máquinas virtuales. iscsi para montar directamente ficheros.iso que son presentados como CD-ROMs a las máquinas virtuales. NFS como datastore de máquinas virtuales. NFS para montar directamente ficheros.iso que son presentados como CD-ROMs a las máquinas virtuales. Migración con vmotion. Registro de modificaciones para Fault Tolerance. Vinculación de vmotion a puertos para obtener todo el ancho de banda posible. Proporcionar información de red a adaptadores hardware iscsi dependientes. Si disponemos de dos o más tarjetas de red para iscsi, podemos crear múltiples caminos con el iniciador iscsi por software configurando iscsi Multipathing (hablaremos de él en el módulo 5).

7 ESXi solo soporta NFS3 sobre TCP/IP, así que el proveedor de almacenamiento también lo deberá soportar. Para comprobar si el almacenamiento es compatible con vsphere, aquí tenéis el enlace a la base de datos oficial

8 2.1.3 Los adaptadores virtuales para máquina virtual En cada máquina virtual podemos asignar varios adaptadores virtuales que emulen o se comporten como cualquiera de los tipos descritos anteriormente, es decir E1000, E1000e, VMXnet, VMXnet2, VMXnet3, Vlance o Flexible. Como se ha descrito, en sistemas operativos modernos la decisión se basa en escoger E1000 o VMXnet3, uno maximiza la compatibilidad mientras que el otro mejora el rendimiento, no solo por estar paravirtualizado, sino porque tenemos disponibles funcionalidades como Jumbo frames o descarga de la segmentación TCP. Una máquina virtual puede disponer de hasta 10 adaptadores virtuales de red de cualquiera de los tipos mencionados asignados a cualquiera de las redes disponibles, ya sea mediante un switch virtual estándar o un switch virtual distribuido. Estos adaptadores virtuales normalmente también se les llama vnic, siguiendo la nomenclatura de vcpu, vram, etc Ya que emulan a un enlace Ethernet deben tener asignada una dirección MAC o Media Access Control. Es decir la forma que tiene una red Ethernet para identificar a cada uno de los equipos que tenemos en la misma. Ya que la red Ethernet entra hasta el nodo ESXi a nivel 2, ESXi debe asignar una dirección MAC a cada uno de los adaptadores asegurándose que es una dirección MAC única, además se da opción al administrador para que asigne sus propias MAC a cada vnic y éste también debería tener en cuenta que las direcciones MAC deben ser únicas en por lo menos todo el dominio de nivel 2 o dominio de difusión. Una dirección MAC está formada por 48 bits y normalmente se representa en hexadecimal, los primeros 3 bytes de la misma identifican al proveedor de la tarjeta con un código llamado OUI, o Organizationally Unique Identifier, Vmware tiene asignado el código 00:50:56, así que todas las direcciones generadas por ESXi tendrán ese prefijo. El listado de OUI lo tenéis disponible en el siguiente enlace Las direcciones MAC cuando se asignan en modo automático, que es el por defecto, ESXi utiliza el siguiente algoritmo: Los primeros tres bytes de la dirección MAC generada para un vnic consisten del OUI. El algoritmo de generación produce tres otros bytes (6 bytes = 48 bits). El algoritmo asegura direcciones MAC únicas dentro de un nodo e intenta proporcionar MACs únicas entre máquinas. El algoritmo limita el numero de máquinas que están corriendo o suspendidas en un momento dado en un nodo. Además no trata todos los casos cuando máquinas virtuales se está ejecutando en nodos diferentes, así que puede ser necesario forzar alguna dirección en concreto. El Vmware Universally Unique Identifier (UUID) genera direcciones MAC que son validadas buscando conflictos. Las direcciones MAC generadas son creadas usando tres partes: el OUI de Vmware, el SMBIOS UUID para el nodo ESXi y una función hash basadas en el nombre del objeto para el que estamos generando la MAC. Una vez la dirección MAC ha sido generada, no cambia hasta que la máquina virtual es movida a una ubicación diferente, por ejemplo, a un datastore diferente. Todas las direcciones MAC que han sido asignadas a vnics de máquinas que están corriendo o suspendidas en un determinado nodo son vigiladas. La dirección MAC de una máquina virtual parada no es comprobada contra las de las máquinas que están corriendo o suspendidas. Es posible que cuando la máquina virtual vuelve a ser arrancada, puede adquirir una dirección MAC diferente. Esta adquisición viene dada por un conflicto con una máquina virtual que ya estaba corriendo en ese nodo.

9 2.1.4 Funciones avanzadas Podemos habilitar paquetes jumbo en un switch estándar o distribuido de vsphere cambiando el tamaño máximo de transmisión (MTU). Y para mejorar el uso de la CPU, habilitar la Descarga de la Segmentación TCP (TSO), que por defecto está habilitada en el interfaz VMkernel, pero debe ser activada a nivel de máquina virtual. Para activar TSO al nivel de máquina virtual debemos cambiar el interfaz existente por uno de tipo VMXnet 2 o 3. Este cambio puede resultar en cambios en la dirección MAC del adaptador virtual. Los pasos para conseguirlo son: 1. Abrir vsphere Client y seleccionar la máquina virtual 2. Editar los parámetros 3. Seleccionar el adaptador de red de la lista de hardware 4. Apuntar los parámetros de red y la dirección MAC del adaptador 5. Eliminar el adaptador de red 6. Añadir un nuevo adaptador de red 7. Como tipo seleccionamos VMXnet 2 (enhanced) o VMXnet3 8. Configurar los parámetros de red y la dirección MAC que tenia el adaptador de red antiguo 9. Finalizar 10. Si la máquina virtual no está configurada con actualizar las Vmware Tools en el arranque, actualizarlas de forma manual La ventaja principal en habilitar TSO es que todo el trabajo de validar que el paquete es correcto realizando la suma de comprobación de Ethernet, IP y TCP, y que toda la gestión de remontar el paquete que ha quedado fragmentado se realiza en el procesador específico del adaptador de red. Un paquete se puede fragmentar por varios motivos pero el más normal es que la aplicación quiere enviar por ejemplo 32 KB de datos, pero la red solo soporta 1500 bytes, con lo que para enviar una sola comunicación, tendremos varios paquetes en la red, que además pueden seguir varios caminos y llegar con un orden diferente al del envío. La tarea de reordenarlos, comprobar si están todos y luego entregarlos a la aplicación es lo que acaba consumiendo una gran parte de recursos de CPU. Para leer en más detalle sobre TCP/IP, puedes hacerlo en la Wikipedia En VMkernel, TSO está habilitado por defecto, si por algún motivo se deshabilita la única forma de volverlo a habilitar es eliminando el adaptador VMkernel y volviéndolo a crear. Los paquetes Jumbo permiten a ESXi enviar paquetes más grandes a la red física, por tanto la red debe soportar paquetes jumbos de inicio a final. Paquetes Jumbo de hasta 9kB (9000 bytes) están soportados. Antes de activar Jumbos, se debe validar que todo el equipamiento de red soporta Jumbo frames Los paquetes Jumbo reducen la carga en la CPU a causa de la transferencia de datos. Los paquetes normales solo permiten 1500 bytes, con lo que aparte de tener que tratar con menos paquetes,

10 mejoramos la eficiencia de transmisión ya que el resto de cabeceras se mantienen constantes. Habilitaremos Jumbo frames en VMkernel cambiando la MTU de la siguiente forma: Ir a Hosts and Cluster con el vsphere Client Seleccionar un host e ir a la pestaña Configuration->Networking Seleccionar Properties del switch estándar asociado al VMkernel que queremos modificar En la pestaña Ports, seleccionamos el VMkernel y lo editamos Cambiamos la MTU a 9000 y salimos con OK Si en lugar de tener un switch virtual estándar tenemos uno de distribuido, el proceso es el siguiente: 1. Entrar en vsphere Client y seleccionar la vista de Networking del inventario 2. Botón derecho sobre el switch distribuido vsphere y editar parámetros 3. En la pestaña de propiedades, seleccionar Advanced 4. Configurar Maximum MTU al valor máximo de MTU de todos los adaptadores virtuales conectados en el switch distribuido y salir con OK Por ultimo nos queda activar Jumbo frames a nivel de máquina virtual, como hemos visto antes, para tener funcionalidades avanzadas, necesitamos de los adaptadores VMXnet 2 o 3. El proceso sería: 1. Seleccionar desde el inventario de vsphere Client la máquina virtual que nos interesa 2. Editar los parámetros de la misma 3. Seleccionar el adaptador de red de la lista de hardware 4. Apuntar los parámetros de red y la dirección MAC del adaptador 5. Eliminar el adaptador de red 6. Añadir un nuevo adaptador de red 7. Como tipo seleccionamos VMXnet 2 (enhanced) o VMXnet3 8. Configurar los parámetros de red y la dirección MAC que tenia el adaptador de red antiguo 9. Comprobamos que hemos vinculado el adaptador de red a una red de un switch virtual con los jumbo

11 frames activados 10. Desde dentro del sistema operativo alojado activamos los jumbo, mediante las herramientas nativas 11. Asegurar que todos los equipos con los que se comunica esta máquina virtual soportan Jumbo frames Para más detalle sobre las MTU, os recomendamos una lectura del siguiente artículo de la Wikipedia

12 2.2.1 Límites vsphere dispone de una abstracción que simula un switch de red Ethernet, a este switch le podemos conectar varias máquinas virtuales por un lado y asignar varios adaptadores de red físicos a modo de uplink. La ventaja principal de disponer de ese tipo de abstracción, es que facilita que las personas que componen los equipos de redes, sistemas y almacenamiento entiendan las ventajas e inconvenientes de este tipo arquitecturas al comportarse de forma muy similar a las infraestructuras del mundo físico. Aunque sean abstracciones, existen límites en el número y capacidades en el entorno de red. Por ejemplo, respecto a las máquinas virtuales, cada una de ellas puede disponer de 10 vnics o lo que es lo mismo, 10 adaptadores virtuales de red. Si por algún (extraño) motivo fuesen necesarias más redes se deberían buscar otras soluciones, como por ejemplo subir las VLANs al sistema operativo alojado. Los límites físicos de conexiones dependen del tipo de tarjeta y de su velocidad, por ejemplo los límites de puertos probados son: Tipo de adaptador físico número de puertos por nodo e1000 1Gb Ethernet (Intel PCI-x) 32 e1000e 1Gb Ethernet (Intel PCI-e) 24 igb 1Gb Ethernet (Intel) 16 tg3 1Gb Ethernet (Broadcom) 32 Bnx2 1Gb Ethernet (Broadcom) 16 Forcedeth 1Gb Ethernet (NVIDIA) 2 Nx_nic 10Gb Ethernet (NetXen) 8 Ixgbe 10Gb Ethernet (Intel) 8 Bnx2x 10Gb Ethernet (Broadcom) 8 Be2net 10Gb Ethernet (Emulex) 8 Combinación de 10gb y 1Gb Seis 10Gb y cuatro 1Gb Vmware recomienda disponer de por lo menos dos tipos de redes para reducir el riesgo de problemas por fallo de un controlador. Además estos son máximos suponiendo ningún otro límite, en caso de estar afectados por algún otro, el más restrictivo es el que afecta. Por los que respecta a límites en los switches virtuales, tanto estándar (VSS) como distribuido (VDS), tenemos:

13 Característica Valor máximo Puertos totales de switch por nodo (VSS y VDS) 4096 Puertos activos máximos por nodo 1016 Puertos máximos por VSS 4088 Grupos de puertos por VSS 256 Puertos de VDS por vcenter Grupos de puertos estáticos por vcenter 5000 Grupos de puertos efímeros por vcenter 256 Nodos por VDS 350 VDS por vcenter 32 Como podemos ver, no podemos llegar al máximo de todos los valores ya que están planteados para tener diferentes tipos de switches, con diferente número de puertos cada uno, algunos pequeños y otros más grandes de forma que no superemos el límite restrictivo, por ejemplo los puertos activos máximos por nodo.

14 2.2.2 Switches estándar Los switches estándar son locales a cada nodo ESXi, por tanto tendremos una configuración específica en cada uno de ellos. Debemos intentar que todos los nodos tengan una configuración equivalente y que cada uno de los switches creados disponga de suficientes puertos para soportar la carga máxima de máquinas virtuales. Por defecto este número es de 120 puertos, pero debemos tener en cuenta que cada máquina virtual puede tener más de una vnic (o adaptador virtual de red), hasta un límite de 10 vnics por máquina virtual. Un switch estándar puede enrutar el tráfico interno entre máquinas virtuales y enlazar a redes externas. Se puede utilizar un switch estándar para combinar el ancho de banda de múltiples tarjetas de red y balancear las comunicaciones entre ellas. También lo podemos configurar para que trate los fallos de las tarjetas físicas y active otras. Un switch estándar vsphere modela un switch Ethernet tradicional. El número por defecto de puertos es de 120. Podemos conectar un adaptador virtual de red de máquina virtual a cada uno de esos puertos. Cada enlace con el exterior mediante una tarjeta física también gasta un puerto. Cada uno de esos puertos lógicos en el switch virtual es un miembro de un solo grupo de puertos. Cada switch estándar puede tener un grupo de puertos o más asignados a él. Para ver los máximos, lo tenéis en el apartado anterior. Cuando dos o más máquinas virtuales son conectadas al mismo switch estándar, el tráfico de red entre ellas se queda dentro del nodo. Si añadimos un enlace físico al switch estándar, cada una de las máquinas virtuales podrá acceder a la red externa donde está conectado ese a tarjeta de red.

15 2.2.3 Grupos de puertos estándar Los grupos de puertos agregan múltiples puertos bajo una configuración común y proporcionan un sitio estable para que las máquinas virtuales se conecten a redes etiquetadas (el nombre que damos al grupo de puertos). Cada grupo de puertos está identificado por una etiqueta de red, que es única dentro del nodo. Esas etiquetas se usan para que la configuración de la máquina virtual sea portable entre varios nodos. A todos los grupos de puertos del datacenter que están físicamente conectados a la misma red se les debe dar la misma etiqueta. De la misma manera que dos grupos de puertos que no se deban ver a nivel 2 Ethernet, tendrá etiquetas diferentes. A cada grupo de puertos se le puede indicar un ID de VLAN de forma que aunque físicamente estén conectados a la misma red, los switches involucrados la particionan de forma que a nivel 2 de Ethernet no se pueda ver. Entraremos más a fondo en las VLANes en la lección 2.4 VLAN en la infraestructura de vsphere.

16 2.2.4 Configuración de los grupos de puertos para máquinas virtuales La forma más ágil para añadir o modificar un grupo de puertos para máquinas virtuales es desde el vsphere Client. El asistente de Add Network nos guía a través de las tareas para crear una red virtual a la que las máquinas virtuales se puedan conectar, e incluye crear un switch estándar y asignar una etiqueta de red. Cuando se configura una red para máquinas virtuales, debemos tener en cuenta si vamos a querer migrar la máquina virtual entre nodos, en ese caso, debemos estar seguros que ambos nodos deben estar en el mismo dominio de difusión (broadcast domain), eso es, en la misma subred de nivel 2. ESXi no soporta la migración de máquinas virtuales entre nodos en diferentes dominios de difusión porque la máquina virtual migrada puede requerir sistemas y recursos a los que no tendrá acceso en la nueva red. Aunque tengamos la red configurada como de alta disponibilidad o dispongamos de switches inteligentes que puedan solucionar las necesidades de nuestra máquina virtual entre las redes, podremos experimentar retardos mientras el Protocolo de Resolución de Direcciones (ARP) actualiza las tablas y reanuda el tráfico de red para la máquina virtual. Las máquinas virtuales alcanzan las redes físicas mediante las tarjetas de red físicas de enlace. Un switch estándar puede transferir datos a las redes externas solo cuando una o más tarjetas de red están asignadas a él. Cuando dos o más adaptadores están vinculados a un switch, de forma transparente funcionan como equipo. Añadir un grupo de puertos de Máquinas virtuales Vamos a describir como hacerlo desde vsphere Client 1. Seleccionamos el nodo sobre le que queremos trabajar 2. Vamos a Configuration->Networking 3. Seleccionamos la vista vsphere Standard Switch 4. En el lado derecho vemos Add Networking 5. Aceptamos el tipo de conexión Virtual Machines

17 6. Seleccionamos Create a vsphere standard switch o uno de los ya existentes y las tarjetas físicas que usaremos para ese grupo de puertos Podemos crear un switch estándar virtual con o sin adaptadores Ethernet Si lo creamos sin adaptadores físicos, todo el tráfico en ese switch se quedará en ese switch. Ninguno de los otros nodos en la red física o máquinas virtuales en otros switches virtuales pueden enviar o recibir tráfico hacia ese switch virtual estándar. 7. En Port Group Properties, definimos la etiqueta de red que identificará el grupo de puertos 8. Opcionalmente, si usamos VLAN (Virtual LAN), tenemos la opción de indicar qué VLAN ID estará vinculado a nuestro grupo de puertos. Si no usamos VLAN lo dejamos en blanco

18 9. Salimos con Finish y ya podremos vincular adaptadores de red de máquina virtual a ese nuevo grupo de puertos o red

19 2.2.5 Propiedades de un vsphere Standard Switch Como hemos visto, un switch estándar se configura por defecto con 120 puertos, pero lo podemos modificar hasta un mínimo de 8 y un máximo de Debemos tener en cuenta que los adaptadores físicos asignados también consumen puertos. Este cambio no será efectivo hasta que reiniciemos el nodo. Otra opción que tenemos, es cambiar la velocidad del enlace de nuestras tarjetas físicas, o añadir o quitar adaptadores según convenga.

20 2.2.6 Switches distribuidos Un switch distribuido vsphere funciona como un solo switch distribuido entre todos los nodos asociados. Por tanto nos permitirá crear configuraciones de red que abarquen a todos los nodos miembros, y permitirá a las máquinas virtuales mantener una configuración de red consistente conforme van migrando de host a host. Al igual que los switches estándar, cada switch distribuido es un concentrador de red que las máquinas virtuales utilizan. Un switch distribuido puede enviar el tráfico interno entre máquinas virtuales o enlazar con redes externas al conectarse con ellas mediante adaptadores Ethernet físicos, conocidos como uplinks. Cada switch distribuido puede tener uno o varios grupos de puertos distribuidos asignados. Un grupo de puertos distribuido agrupa varios puertos bajo una configuración común y proporciona un anclaje estable para que las máquinas virtuales se puedan conectar a redes etiquetadas. Cada grupo de puertos distribuido es identificado por una etiqueta de red que es única en todo el datacenter. Estos grupos de puertos distribuidos pueden estar vinculados a un ID de VLAN que permite vincular nuestro grupo de puertos distribuido a un segmento lógico Ethernet en la red física. Los grupos de recursos de red, nos permiten gestionar el tráfico de red por tipo de tráfico. Adicionalmente al propio switch distribuido de vsphere, vsphere 5 también proporciona soporte para switches de terceras partes como por ejemplo el Cisco Nexus 1000v.

21 2.2.7 Configurar un switch distribuido vsphere Para crear un switch distribuido necesitamos un datacenter basado en vcenter Server. Una vez creemos un switch distribuido, podremos añadir nodos, crear grupos de puertos distribuidos y editar las propiedades y políticas del switch distribuido. Para añadir un switch distribuido lo pasos son los siguientes 1. En el vsphere Client seleccionamos la vista de Networking y seleccionamos el datacenter 2. Seleccionamos Inventory -> Datacenter -> New vsphere Distributed Switch 3. Escogemos una versión. Tenemos disponibles versiones basadas en ESX 4.0, 4.1 y 5.0. Deberemos escoger la que nos marque el nodo más antiguo al que vayamos a asignar ese switch distribuido 4. Le damos nombre 5. Definimos el número de puertos de enlace por nodo Number of uplink ports Los puertos de enlace conectan el switch distribuido a la red física en los nodos asociados. El número de enlaces define el máximo número de tarjetas que puede tener asignadas este switch distribuido por nodo Seleccionamos si queremos añadir ahora los nodos o lo dejamos para más tarde Opcionalmente limitamos el número de puertos que puede tener por nodo Opcionalmente seleccionamos si queremos que cree un grupo de puertos por defecto o lo dejamos para configurarlo nosotros. Finalizamos Una vez creado, debemos añadirle nodos, para hacerlo vamos a seguir esos pasos:

22 1. Desde vsphere Client, seleccionamos la vista Networking 2. Con botón derecho sobre el switch que nos interesa seleccionamos Add Host 3. Seleccionamos los nodos a añadir 4. Por cada nodo, seleccionamos que adaptadores físicos vamos a asignar. Podemos asignar adaptadores no usados o usados, pero teniendo en cuenta que un adaptador solo puede pertenecer a un switch, con lo que podemos dejar a alguno sin conectividad. 5. Para cada uno de los adaptadores virtuales, seleccionamos Destination port Group y seleccionamos el grupo de puertos desde el menú, o seleccionamos Do not migrate 6. Opcionalmente definimos el número máximo de puertos por nodo 7. Opcionalmente migramos la configuración de red de las máquinas virtuales al switch distribuido 8. Validamos que todo es correcto y finalizamos A parte de cambiar los valores que acabamos de definir, como número máximo de puertos o parecidos, una vez creado podemos cambiar: la MTU para habilitar Jumbo frames El protocolo de descubrimiento. Podemos habilitarlo o deshabilitarlo, se soporta solamente Cisco Discovery Protocol y trabajando como escuchador (Listen) o notificador (Advertise) o los dos modos a la vez (Both) Y para ser un buen ciudadano de la red, le podemos informar de la información de contacto del administrador que será visible por SNMP Podemos actualizar la versión de vsphere Distributed Switch en caso que los últimos nodos de la versión más antigua de ESX/ESXi se hayan actualizado