Esta semana, en el blog de virtualización y cloud computing en español, os explicare a eliminar cuellos de botella y mejorar el rendimiento de red en VMware vSphere 5.
Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y VMware vSphere 5: ¿Cómo mejorar el rendimiento de red en VMware vSphere 5? Espero que te guste.
Hasta el próximo lunes, donde os mostraré otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.
El Protocolo Spanning-Tree (STP) mantiene la red física libre de bucles. Para la comunicación entre switches STP utiliza tramas multicast llamadas Bridge Protocol Data Units (BPDUs). No pienso torturar vuestras sobrecargadas mentes con una descripción profunda pero, os diré, que son las culpables de que cuando un camino se pierde entre dos switches, se active otro.
Lo que es menos conocido del STP son algunas funciones que debemos conocer y controlar cuando conectamos un host ESXi, me refiero al BPDU Guard y al BPDU Filter.
Cuando conectamos una NIC de un host ESXi a un switch Cisco, vemos como los leds del puerto se iluminan con una luz naranja durante más segundos de los que quisiéramos (casi un minuto) y luego se ilumina con luz verde.
Durante el periodo de luz naranja, STP analiza la NIC recién conectada para evitar bucles no esperados. Como estamos conectando un host ESXi cuyos vSwitches o dvSwitches no tiene STP por definición, ni pueden generar bucles, podemos evitar esta espera saltándonos el análisis de STP, configurando el puerto en un switch Cisco como portfast (en un Cisco Catalyst con IOS) o como edge port (en un Cisco Nexus con NX-OS), es decir:
sw_ios(config)# interface FastEthernet 0/20
sw_ios(config-if)# spanning-tree portfast trunk
… o bien …
sw_nxos(config)# interface Ethernet 0/20
sw_nxos(config-if)# spanning-tree port type edge trunk
Esta configuración es solo un medio para acelerar la puesta en servicio de un puerto físico que sigue estando bajo el dominio de STP, por tanto, si llegarán BPDUs a este puerto las procesaría como tal. Es decir, podríamos inducir al STP a realizar cambios en la topología de la red haciéndola impredecible.
Para evitar esto tenemos BPDU Guard, una función de los puertos portfast que controla la llegada de BPDUs, por donde no se las espera, bloqueando el puerto como mecanismo de seguridad para evitar males mayores, como un cambio inesperado de la topología de STP.
Un puerto portfast sigue dentro del dominio STP y, por tanto, sigue enviando BPDUs. Para evitarlo tenemos la función BPDU filter que permite no enviar tramas BPDUs por este puerto. Esto es lo que espera el host ESXi.
Se activa a nivel de interface con los comandos:
sw(config-if)# spanning-tree bpdufilter enable
sw(config-if)# spanning-tree bpduguard enable
Siendo los mismos comandos tanto en Cisco IOS como en Cisco NX-OS.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola de nuevo. Soy Miguel ángel Alonso y aquí estoy de nuevo contigo para contarte algo nuevo sobre el apasionante mundo de la virtualización de sistemas.
En el tema de hoy voy a hablarte de una nueva funcionalidad a nivel de Red que no es otra que la tarjeta e1000e, la cual soporta adaptadores Pci-Express y será por defecto la tarjeta de los nuevos Windows 8. Esta tarjeta es una emulación de las Intel 82574L Gigabit Ethernet, y sólo está disponible en vsphere 5 con hardware 8.
El tema de hoy viene dado para explicarte como habilitarla, ya que de por si no viene activada y no puede hacerse a nivel de GUI.
Cuando elegimos de manera normal una tarjeta de red para nuestra VM veremos algo como te muestro en la foto de la cabecera de este post.
Pero si ejecutamos el script que hemos descargado podremos ver algo como esto en nuestra consola del vMA:
Y finalmente podremos tener acceso a la nueva tarjeta de red una vez la hemos activado con el correspondiente script:
Por fin podremos disfrutar de esta nueva tarjeta que nos ofrece vSphere 5 en nuestros entornos y poder sacar todo el beneficio que esta nos pueda dar.Bueno, me despido de vosotros esperando haberos podido contar algo de vuestro interés. Hasta el próximo martes y un saludo.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, soy Ferran Serafini y hoy vengo con un tema sencillo y a la vez muy potente. Seguramente habrás visto en XenCenter que los interfaces de red te permiten configurar QoS. Vamos a ver hoy, como implementarlo en nuestro entorno de virtualización con XenServer.
El QoS (Quality of Service) nos puede ser muy útil en entornos donde tenemos grandes tráficos de red y a su vez estos, sean limitados, hayamos detectado problemas, o bien necesitamos restringir el ancho de banda sin dejar de dar servicio a ciertas máquinas virtuales, etc.
Mediante QoS, XenServer permite establecer a nivel de red qué máquinas virtuales van a estar restringidas y cuáles no.
En algoritmo de XenServer para QoS de red, se asocia a cada dispositivo VIF (Virtual Interface), por lo tanto se aplica a cada interface de red de cada máquina virtual. De este modo es posible tener una máquina con un interfaz limitado a 300 KB/s y otro a 1000KB/s. El valor que podemos establecer es la tasa máxima de transferencia.
Esto es todo por hoy, espero como siempre, haberte aportado algo nuevo e interesante. ¿Utilizas QoS en tu entorno, si es así que política establesces, criticidad de la máquina, segmento de red, etc?
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.
Hola amigos, soy Florián Murillo. Estamos en un entorno muy cambiante, tanto que lo DICHO este mes puede quedar obsoleto el mes próximo… Por ese motivo, durante las próximas semanas, desarrollaré el estado ACTUAL de las tecnologías Cisco relacionadas con el Virtual Networking.
¿Qué es Virtual Networking?
Es la virtualización de la capa de acceso de switches; aquellos switches donde están conectados los servidores que también vamos a virtualizar.
O lo que es lo mismo: Los switches virtuales donde están conectados los servidores (ahora virtuales).
Se esquematiza en la figura siguiente:
Esto es lo que hace que los responsables de configurar los switches físicos a los que se conectarán los hosts ESX/ESXi deban pensar en estos hosts como switches, ya que en realidad están conectados a switches (virtuales).
Características únicas de los switches virtuales:
Los switches virtuales no se pueden apilar entre ellos, solo podemos conectar a un switch virtual interfaces físicos del host, las vNICs de las VMs y los puertos de servicio del kernel (vmk y vswif).
Los switches virtuales no tienen spannning-tree (STP), por tanto recordar deactivar STP en los puertos de los switches físicos donde se conectan los hosts ESX.
Los switches son de nivel 2 (L2), es decir, requieren “ayuda” externa para encaminar tráfico entre VLANs.
Cisco entra en el Virtual Networking con la llegada de vSphere 4 y concretamente utilizando la vNetwork Appliance API.
El switch virtual distribuido (dvSwitch) es un elemento básico para la implantación de grandes infraestructuras virtuales y, por extensión, para el despliegue de soluciones IaaS bajo el modelo de cloud computing. El elemento diferencial es su arquitectura. Las configuraciones se despliegan automáticamente a todos los hosts que participan en el dvSwitch, sin necesidad de repetir el cambio host por host, como ocurre con el vSwitch clásico de VMware.
El dvSwitch aporta funcionalidades nuevas respecto a los vSwitches, que podemos resumir en Seguridad, QoS, Gestión y Arquitectura abierta.
Cisco basa su arquitectura de Virtual Networking en Cisco Nexus 1000V, que incorpora características adicionales respecto dvSwitch.
Desde su aparición en el 2009, han aparecido productos que extienden las funcionalidades de Cisco Nexus 1000V, como son:
Cisco Virtual WAAS
Solución de aceleración WAN y balanceo.
Cisco Virtual Security Gateway
Solución de firewall por zonas, de forma que tengamos varios servicios de clientes diferentes en el mismo segmento de red y poder definir que se puede ver y por quien…
Cisco ASA 1000V (que describimos la semana pasada)
Firewall perimetral y de filtrado entre VMs dentro de una zona.
Estos elementos se complementan con funcionalidades y soluciones clave:
Cisco Nexus vPath
Cisco Virtual Network Management System
En los próximos post, hablaremos de las novedades que nos aporta cada producto, empezando por la base: Cisco Nexus 1000V y Cisco Nexus vPath. ¿Qué opináis de la estrategia de Cisco en el tema Virtual Networking?
¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de abajo. Gracias por el apoyo.
Hola amigos, soy Florián Murillo. En el VMworld 2011 de agosto en Las Vegas, Cisco ha anunciado grandes novedades para la infraestructura virtual de VMware.
Me centraré en una de ellas, en el Cisco ASA 1000V cloud firewall, es un virtual firewall en formato virtual appliance que se integra con Cisco Nexus 1000V, estará disponible en la primera mitad del 2012.
Como es habitual en Cisco (y otros fabricantes) primero llega el marketing y detrás el producto, las características principales del nuevo producto son:
Proporciona cortafuegos perimetral “multi-tenant”, o lo que es lo mismo, se puede utilizar para securizar varios clientes en entornos aislados.
Proporciona VPN site-to-site, las conexiones VPN de clientes remotos, como Cisco AnyConnect no están soportadas en esta primera versión.
Requiere para su funcionamiento, como pre-requisito, de Cisco Nexus 1000V, el switch distribuido de Cisco.
Se gestiona desde el Cisco Virtual Network Managemeng Center (VNMC) compartiendo consola con el Cisco Virtual Security Gateway (otro día hablamos de este producto).
La versión inicial no soportará vCloud Director, pero como Cisco Nexus 1000V está soportado por vCloud Director, no dudo que se soportará en siguientes versiones.
Está soportado desde vSphere 4.1 y se basa en la versión de software Cisco ASA v.8.4
El licenciamiento será por sockets, siguiendo la línea de Cisco Nexus 1000V y Cisco Virtual Security Gateway.
Resumiendo: Es una versión inicial que alegrará a muchos consumidores de tecnología Cisco, aunque con ausencias esperadas, las VPNs de usuarios remotos y la no integración de vCloud Director hacen que denominemos esta versión como “la primera”.
Seguimos esperando el precio final pero, me surge una duda: ¿Puede el mantenimiento y soporte de la versión virtual de un producto ser mas cara que su homónimo del mundo físico?
Lo sabremos en unas semanas
¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.
Hola amigos, soy Florián Murillo. La semana pasada, mi colega de blog, Santi Fernández, expuso en su post “Aterriza la nueva versión de vSphere 5” de forma clara, las líneas generales de las novedades de vSphere 5, que se lanzó el martes 12-julio. En este post, detallaré brevemente las novedades específicas de networking que trae la nueva versión.
La nueva versión de switches distribuidos, la v.5.0.0 (ya van tres versiones) tiene soporte de LLDP, NetFlow, Port Mirroring y funciones avanzadas en Network I/O Control (NIOC).
Link Layer Discovery Protocol (LLDP): Es un protocolo de descubrimiento de “vecinos” estándar, alternativo a Cisco Discovery Protocol (CDP), LLDP me proporciona información acerca del switch al que estamos conectado.
NetFlow: Realmente no es una novedad, en VI3 teníamos NetFlow en calidad de experimental, y desapareció en vSphere 4, quizás por la llegada de Cisco Nexus 1000V, que si soporta NetFlow. En vSphere 5 se pueden capturar y enviar a un “Netflow collector” los flujos de red entre VMs e incluso entre una VM y un servidor físico. Para ello le hemos de poner una IP al switch distribuido, otra novedad que se ha de tener en cuenta en los diseños. En vSphere 5 se soporta NetFlow v.5.
Port Mirroring: Copia el tráfico de que entra y/o sale de un puerto, en un puerto de mirror para tareas de análisis de tráfico o resolución de problemas. Es una gran herramienta.
Las funciones avanzadas que tiene el Network I/O Control son:
User-Defined Network Resources Pools: Network I/O Control llegó en vSphere 4.1 con unos Network Resources Pools (nRP) ya definidos y sin poder añadir mas. Ahora podemos definir nRP a nuestra conveniencia, asociando port-groups a los nRP creados para definir las prioridades de tráfico.
Cada nRP, además de los shares y limits, es marcado con un tagging 802.1p para aplicar Calidad de Servicio.
En definitiva, grandes mejoras que tendremos que ir desglosando una a una para que veáis como aplicarlas.
¿Creéis que estas mejoras ayudarán a optimizar el rendimiento de red en nuestros CPDs?
¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.
Hola, soy Miguel Ángel Alonso, y aquí vuelvo a estar con nuestros queridos lectores del blog, un martes más.
Siguiendo con la estela de los últimos Post relacionados con el mundo de la virtualización de Microsoft en Hyper-V, hoy vamos a ver una interesantísima herramienta de visualización-diagnóstico del entorno de nuestros servidores a nivel de CPU, disco, memoria y red con más de 100 parámetros que nos ayudarán en el deber diario de cada día.
La herramienta en cuestión se llama Vital Signs y es de la empresa SAVISION, experta productos de visualización y diagnóstico para soluciones de hypervisor tipo 1 como Microsoft Hyper-V y otras soluciones, como por ejemplo, SQL y Windows Server.
Este nuevo software de monitorización para Microsoft HyperV dispone de una integración total con System Center Operation Manager (SCOM), con lo que la lectura de datos de nuestra estructura de Hyper-V esta mucho mas elaborada.
Lo que más me gusta de esta herramienta con gran diferencia, por supuesto a parte de la gran cantidad de datos a visualizar, es la claridad de los departamentos en la que está estructurada y la visualización de unos gráficos muy claros y concisos.
Se asegura de forma proactiva de darnos errores producidos en las cargas de trabajo, y de forma automática – sin necesidad de intervención del personal – ,corregirá todos aquellos problemas basándose en anteriores lecturas de trabajo (normal) para volver a conseguir que nuestra infraestructura goce de una más que formidable salud.
Bajo mi punto de vista, es una herramienta que considero imprescindible para los entornos donde reina Hyper-V como plataforma de virtualización.
Aquí os dejo un ScreenShot para que podáis familiarizaros un poco más con este maravilloso producto:
Bueno, hasta aquí por hoy. Espero haberos contado algo interesante, y te emplazo hasta la semana que viene para hablar sobre un nuevo tema, relacionado con este maravilloso mundo de la virtualización de sistemas.
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.
Ya esta disponible online el episodio #17 en virtualizacion.tv, el programa de televisión web que ayuda a profesionales como tú, a entender la virtualización de sistemas y el cloud computing en español.
Virtualizacion.TV es nuevo programa de televisión web que ayuda a profesionales y usuarios de la virtualizacion de sistemas como tú, a virtualizar el centro de datos y no morir en el intento.
En el episodio de esta semana, te mostrare como hacer un curso de VMware ESXi gratuitamente y valorado en 1.500 euros, responderé a la pregunta de un usuario en relación a la configuración del teaming de red en VMware ESX/ESXi y te mostrare otra utilizad impresionante relacionada con el mundo de la virtualización de servidores, Compliance Checker for VMware vSphere.
Gracias a todos los que dejaron su comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, entra en virtualizacion.tv hazlo ahora. Tu apoyo permitirá que este programa de televisión web sobre la virtualización de sistemas y el cloud computing en español, pueda continuar beneficiando a muchas personas.
PD. No te pierdas al final del show, nuestra nueva sección de tomas falsas.
¿Y tú, qué opinas con relación a la pregunta lanzada en el episodio de hoy?¿Qué piensas de las diferentes soluciones de Virtualización que existen en la actualidad en el mercado? ¿Cuál es tu solución favorita y por qué? Deja tu comentario en virtualizacion.tv o charlemos sobre ello en twitter. ¿Crees que este videopost puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por tu apoyo.
¿Que tal? Soy Jose Maria Gris y como cada Miércoles comparto estas páginas virtuales con vosotros.
Hace tiempo publiqué un post (por favor, Jose María) donde teníamos problemas de rendimiento con alguna vmnic. Allí hablábamos como trabajar con herramientas como iperf para ver exactamente que caudal estaba gestionando.
Con la aparición de VMWare vSphere 4.0 y 4.1 han cambiado muchas cosas en este mundillo de las nics y aún me llegan preguntas sobre ellas o bien, cuando estoy en alguna instalación veo que no se han usado los tipos de nic mas adecuados.
Y hoy he creído que sería bueno ver los diferentes modelos de vmnic que hemos movido y para que “sirven” o están planteadas.
Dejo de lado versiones que son “mandatory” para según que clusters y según que combinaciones.
Cito cronológicamente:
Vlance: Vlance es una “Legacy” que tenía su truco. Vlance era una emulación de la AMD 79C970 que su peculiaridad era “to hit de ground running” como los comandos. Esta vmnic empieza a funcionar en cuanto arrancaras la vm tuviera o no las vmwaretools instaladas, eso sí, a 10 Mb, pero conectaba. Al instalar las tools subía a 100 y a 1000 (?).
VMXNET: Este adaptador ya nació virtualizado, pensado para entornos virtuales. Precisaba de las tools. Fue el “abuelo” de las VMXNET actuales.
Flexible: Pues sencillamente eso, Flexible. En cuanto lo arrancabas tenia un comportamiento como una Vlance, al ponerle las tools, se comportaba como una VMXNET
E1000: Emulación de la Intel 82545EM. Personalmente he tenido experiencias no muy satisfactorias con este driver. Mediciones realizadas por mi mismo han dejado la transferencia de este driver muy lejos del Giga.
VMXNET 2 / VMXNET 3: Con vSphere nos llegaron estas vmnics que a mi modo de ver son las que funcionan mejor, incluyendo las ultimas tecnologías de switching. Eso sí, estos tipos tan sólo están soportados por los modernos OS Guest (XP hacia arriba), por lo que no podrán instalarse en entornos Windows 2000. En VMware vSphere 4.1 han sido mejoradas.
Pues con esto me despido hasta la semana que viene.
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.
