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.
¿Alguna vez te has preguntado como puedes poner un servidor VMware vSphere ESXi en modo mantenimiento desde una tarea programada? El problema inicial es que no es posible poner un host ESX/ESXi en modo mantenimiento desde el vCenter Server con una tarea programada. No obstante, SI es posible ponerlo en modo mantenimiento desde la nueva versión de VMware vSphere Management Assistant (vMA)
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 poner un ESXi en modo mantenimiento con vSphere Management Assistant?
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.
Buenos días a todos, soy José Mª Gris y como cada Miércoles estoy aquí para comentar temas del ecosistema de la Virtualización.
La foto del post no es un gazapo, es un sistema 4381 de IBM, porque ese sistema también usaba VMs aunque parezca extraño. Varias son las veces que me comentan “la nueva tecnología de la virtualización”, y lo cierto es que tiene sus años… Vamos a hacer algo de historia.
Fue sobre los años 60 cuando IBM empezó a tener unos Hosts que ya tenían importante capacidad de computación, por lo que empezaron a pensar en que el host tuviera unas particiones lógicas, las cuales, en el año 80 personalmente empecé a escuchar con la denominación “VMs” en un CPD con un 4381 de una gran empresa española. De tener un concepto de unidad física con mucha potencia, se aplicaba el tener varias unidades lógicas utilizando mejor los recursos (¿os suena verdad? ).
Pues bien, el SO que hasta entonces IBM llamaba “Supervisor” como otros sistemas llamaban “monitor”, evolucionó a Hypervisor, pues era capaz de gestionar varios SO (ahora ya sabemos de donde viene el nombre de marras).
En los años 80 unos cuantos nos dedicamos a montar sistemas “cliente servidor” y hacer la competencia a los Hosts, aprovechando la plataforma x86 que ya empezaba a tener solidez. Y ahí tomo fuerza esta arquitectura.
Pero en los años 90 nos empezamos a encontrar que de nuevo ya se estaba llegando al momento en que la unidad de proceso empezaba a desaprovechar recursos. Con ello se llegó en los años 90 al mismo punto de los años 60. Vamos a virtualizar.
Y aquí nos encontramos con los requerimientos de virtualización de Popek y Goldberg. Se trata del conjunto de condiciones que debe cumplir una arquitectura para poder dar soporte a un sistema de virtualización de forma eficiente. Y ahí nos encontramos que mientras los system/370 de IBM es compliant y que los célebres Motorola 68000 tan sólo tienen una instrucción “no compliant”, la arquitectura x86 tiene 17 instrucciones que generan problemas a la hora de virtualizar.
Para que esta arquitectura fuera “compliant” y dar el fruto de eficiencia y eficacia requerido, VMware desarrolló una técnica que interfiere, adapta y convierte en instrucciones seguras, dejando el resto de instrucciones trabajar de forma original.
Y fue en 1999 cuando VMware presentó el primer Hypervisor en x86. Recuerdo que precisamente en el año 2000, estando en la formación MCSE con nuestro Windows 2000 que me comentaron “¿Has visto el VMware? Pues no, que es eso? Pues chico no lo sé, pero me han dicho que instalas VMware con Windows 2000 y funciona como una maravilla”. Y me picó la curiosidad, la primera vez en mi vida que oí VMware. Y hasta nuestros días.
Gracias Dani por darme la idea Hasta la semana que viene, take care.
¿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.
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.
En la primera parte de esta mini serie de video tutorial sobre la optimización de red en VMware vSphere 5, vimos como al cambiar el driver virtual de red de una máquina virtual se mejoraba su rendimiento. En esta parte veremos como al cambiar la configuración de los switches virtuales tambien mejoramos considerablemente la optimización de nuestra red en VMware vSphere.
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? – Parte II. 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.
Unified Fabric es una iniciativa liderada por Cisco desde el año 2005 con la intención de innovar radicalmente las arquitecturas de I/O. Se ha llegado a comparar el impacto del Unified Fabric en el Datacenter con el que produjo la virtualización, aunque, desde mi punto de vista, el Unified Fabric es una consecuencia del éxito de la virtualización.
¿En qué consiste Unified Fabric? Pretende unificar los distintos protocolos de transporte que existen en los Datacenters utilizando Ethernet como el medio universal de transporte.
¿Qué protocolos circulan por nuestros Datacenters sin utilizar Ethernet de forma nativa?
Me vienen a la cabeza: Fibre Channel, FICON, RDMA e Infiniband.
En definitiva, tenemos demasiados protocolos para los retos a los que se enfrentan los Datacenters desde hoy. Es decir, la escalabilidad masiva, la orquestación y la necesidad de aprovisionar de forma inmediata y dinámica computación y recursos de I/O allá donde sean necesarios.
La iniciativa Unified Fabric propone encapsular los protocolos Fibre Channel, RDMA y Infiniband en Ethernet, unificando varias redes en una sola.
Hagamos un repaso de cada protocolo:
Fibre Channel over Ethernet (FCoE). Se ha hablado mucho de este protocolo, ya que permite encapsular FC sobre tramas Ethernet de 10Gb en este momento y con el tiempo sobre 40Gb y 100Gb.
Remote Direct Memory Access (RDMA). Se utiliza en clusters de computación paralela permitiendo que un sistema acceda a memoria de otro sistema. Se puede transportar sobre Ethernet, IP o Infiniband.
Infiniband. Es utilizado en algunos de los TOP500 Superordenadores del mundo como un bus de latencia casi cero y alta velocidad, para la comunicación entre nodos en HPC. La encapsulación sobre Ethernet se le denomina IBoE.
Con el Cisco Nexus 5548P tenemos cubiertos todos los objetivos de la estrategia Unified Fabric ya que soporta RDMAoE (también llamado RoE), FCoE y IBoE.
Una iniciativa de Cisco y un equipo a seguir de cerca.
¿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.
Los port groups de tipo Management Network, Virtual Machine y VMkernel pueden ser todos configurados en un único VSS. Asimismo, sólo un VLAN ID puede ser especificado por port group pero múltiples port groups pueden especificar el mismo VLAN ID.
En vSphere™ ESXi 5, el número máximo de puertos soportados para un VSS es de 4088. A este vSwitch, puedes conectar ninguno, uno o más de un uplink.
Recuerda que es posible cambiar el número de puertos en los VSS siempre que sea necesario. Sin embargo, dicho cambio requiere un “reboot”del servidor ESXi para que los cambios tengan efecto.
Es posible también garantizar un mínimo de servidor o ancho de banda a todas y cada una de tus máquinas virtuales. Para ello, puedes usar una técnica de gestión de recursos llamada Traffic Shapping, a nivel de port group, donde está incluida la máquina virtual, para aliviar problemas de congestión de red o garantizar un ancho de banda determinado. Esta funcionalidad para los VSS te permite limitar el ancho de banda desde la máquina virtual hacia afuera (outbound) pero no desde fuera hacia la máquina virtual (inbound).
Si precisas tener que limitar el ancho de banda desde fuera hacia dentro y desde dentro hacia afuera (inbound y outbound), tendrás que usar los switches distribuidos (VDS). Recuerda que este switch distribuido se crea en el vCenter Server, con lo que para usar VDS, aparte, debes de contar con una licencia de vCenter.
Cuando creas un virtual switch estándar, por defecto, el número de puertos que se definen son 120. Sin embargo, si utilizas la línea de comando y ejecutas el comando “esxcfg-vswitch –l” verás que en realidad son 128 puertos.
Estos ocho puertos son puertos extra que utiliza el VMkernel internamente y que no podemos usar desde la GUI. Estos ocho puertos extras solo pueden verse desde la línea de comando en ESXi 5.
Asimismo, es posible que tengas la necesidad de limitar el ancho de banda en los diferentes tipos de conexiones descritas anteriormente, y sobre todo, que tengas que aliviar problemas de cuellos de botella en la capa de red. En post posteriores cubriremos algunas técnicas para aliviar cuellos de botella en los diferentes componentes de vSphere 5.
¿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.
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.
La funcionalidad de red en una infraestructura virtual es de suma importancia. Permite que las máquinas virtuales en un servidor VMware vSphere™ ESXi 5 puedan comunicarse con otras máquinas físicas o máquinas virtuales en otros servidores VMware vSphere™, mediante la configuración de los virtual switches.
También te permite comunicarte con el Management Network de los servidores VMware vSphere™ 5 para poder gestionarlos y con el VMkernel para poder configurar vMotion y cabinas de almacenamiento basadas en protocolos NFS o iSCSI.
En este post y en post posteriores, te enseñaré a entender el propósito general de un virtual switch y un distributed virtual switch, cómo configurarlos y conectar uplink ports, así como a entender las diferentes configuraciones y políticas de seguridad que se pueden definir a nivel de virtual switch, port group o ambas.
Un virtual switch estándar (VSS) tiene tres funciones principales:
1. Comunicar con máquinas virtuales dentro de un mismo servidor VMware ESXi o con otras máquinas físicas o virtuales en otro servidor VMware ESXi, para lo que utilizamos un Virtual Machine Port Group.
2. Comunicar con nuestro servidor ESXi vía SSH (puerto 22) o vSphere Client, para lo que utilizamos un Management Network Port.
3. Comunicar con el VMkernel y puertos IP de tipo VMotion, NFS e iSCSI, para lo que utilizamos un VMkernel Port.
A diferencia de los switches físicos, no es posible conectar dos virtual switch juntos mediante un ISL (InterSwitch Link Protocol), ni puedes mapear la misma tarjeta de red a más de un virtual switch a la vez. Recuerda que sí es posible configurar un virtual switch sin ninguna tarjeta de red, lo que es denominado como internal switch only.
Cuando creas un NIC teaming (una o más tarjetas de red mapeadas a un virtual switch para incrementar el ancho de banda o dotar de alta disponibilidad a la capa de red), todas las tarjetas de red dentro del teaming pasan a ser activas por defecto. Para crear virtual switches puedes usar el vSphere Client o, desde la consola del servidor ESXi, puedes usar el comando: esxcfg-vswitch -a “nombre vSwitch”.
Si hay dos máquinas virtuales conectadas a dos virtual switches diferentes, el tráfico entre dichas máquinas fluirá a través de las tarjetas físicas mapeadas a los switches virtuales y entre los servidores ESXi. Por el contrario, si varias máquinas virtuales están conectadas al mismo VSS del mismo servidor ESXi, los paquetes no salen por la red, sino que son transmitidos internamente en el servidor ESXi por el VMkernel.
Para mejorar el rendimiento de red de las máquinas virtuales es posible mapear más de una tarjeta física (uplink) al VSS.
También es posible configurar switches distribuidos virtuales (Virtual Distributed Switch). La configuración de los switches distribuidos (VDS) es almacenada en el servidor vCenter a diferencia de los switches estándar, los cuales almacenan la configuración en los servidores ESXi. Un Virtual Distributed Switch no es más que un VSS que es compartido entre múltiples servidores VMware vSphere™ ESXi.
La mala noticia es que los VDS solo están incluidos en la versión Enterprise Plus.
¿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.
Esta semana, en el blog de virtualización y cloud computing en español, os explicare cómo activar virtual machine storage profiles en VMware vSphere vCenter Server 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 activar Virtual Machine Storage Profiles? 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.
Los Resource Pools (RP) son una excelente herramienta que nos ayudará a poner en marcha nuestro modelo de maduración de la infraestructura virtual, al inicio no lo utilizamos mucho, pero con el tiempo nos ayuda a garantizar y contener el consumo de recursos por los diferentes grupos de máquinas virtuales que tenemos.
Si no los utilizáis no os preocupéis, a lo mejor no los necesitáis, pero como los recursos suelen ser finitos y su consumo suele ir mas rápido que el aprovisionamiento de nuevos recursos de computación, os llegará el momento de utilizar esta poderosa herramienta.
Con la llegada de vSphere 5, los RP sufren un cambio importante, según la documentación, la gestión de los RP “se traslada” a vCenter Server en vez del host. Pero como todo en la vida tiene matices os pondré un ejemplo:
Para el ejemplo tengo un vCenter Server que gestiona un host. Creo una VM con una reserva de memoria de 1GB, también creo un RP con una reserva de 256MB, sin expandable reservation como se observa en la imagen siguiente.
Si intento ejecutar la VM ya os imagináis el resultado, al tener el RP una reserva inferior a la reserva de la VM falla la ejecución.
Si me conecto directamente al host y realizo la misma ejecución, también falla el arranque, por tanto el host también controla los recursos asignados al RP, ya que está creado en el host y gestionado por vCenter Server.
Ahora hacemos la siguiente prueba, creamos un cluster DRS en el Datacenter e ingresamos nuestro host al cluster, creamos un RP dentro del cluster DRS con las mismas características del anterior (256MB de reserva y expandable reservation OFF).
Ingresamos nuestra VM de prueba al RP nuevo e intentamos arrancar la VM y nos volvemos a encontrar con nuestro ya familiar error por falta de recursos en el RP.
¿Que ocurre si arrancamos la VM conectándonos directamente al host? Nuestra VM de prueba arranca sin problemas.
Volvemos a vCenter Server para ver que le ha parecido nuestra travesura y vemos que no le ha hecho ninguna gracia nuestra prueba.
Detecta que la VM ha arrancado violando la configuración del RP y no ha podido evitarlo eso si nos avisa con un mensaje de error.
Conclusión:
Si tenemos RP configurados en el host, se gestionan por vCenter Server pero se controlan en el host.
Si tenemos RP configurados en el cluster, se gestionan y controlan por vCenter Server.
PD: No os recomiendo utilizar el atajo del host en un entorno productivo para arrancar una VM en contra de la política aplicada en el RP y gestionada por vCenter Server. No seáis malos
¿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.
).
