Hola amigos, hoy en nuestra sección semanal de XenServer, veremos cómo utilizar Bonding y las ventajas que nos aporta para nuestros servidores.
El Bonding en XenServer consisten en crear un interface de red virtual que utiliza dos NICs físicas. Esto, nos permite entre otras opciones, tener tolerancia a fallos de red de forma automática y totalmente transparente.
Podéis consultar la tabla de modos que puede trabajar los bondings de XenServer en el post de Adolfo, http://www.josemariagonzalez.es/2009/11/11/opciones-bonding-xenserver.html Veréis que se permite, además de tolerancia a fallos, otras opciones enfocadas a optimizar el performance de red, pudiendo utilizar las dos NICs de forma activa/activa, round robin, etc.
Hay que estudiar con cariño que opción podemos utilizar, ya que en los casos actio/activo, tu electrónica de red tiene que estar correctamente configurada (LACP). Como mínimo, puedes utilizar la opción por defecto (SBL) sin tener mayor complicación que utilizando XenCenter.
Este modo “Bonding Mode: source load balancing” aporta activo/activo pero solo soporta balanceo del tráfico de las máquinas virtuales a través de las NIC físicas. Añade también fail-over para cualquier otro tráfico, iscsi, management, etc.
Una vez creado el bond, podemos ver sus propiedades ejecutando:
[root@xenserver ~]# cat /proc/net/bonding/bond0
Bonding Mode: source load balancing
Primary Slave: None
Currently Active Slave: eth4
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 31000
Down Delay (ms): 200
Source load balancing info:
[031] = eth4
Slave Interface: eth4
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:00:c9:b5:f6:95
Promiscuity ref count: 1
Flags: 0×1903
Slave Interface: eth5
MII Status: down
Link Failure Count: 0
Permanent HW addr: 00:00:c9:b5:f6:99
Promiscuity ref count: 1
Flags: 0×1903
Y si por ejemplo queremos modificar el modo del bond y queremos que sea siempre activo/pasivo:
Esto es todo por hoy, espero que como siempre te haya parecido interesante. Un saludo
¿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.
For those of you who are involved or may get involved with backup and recovery for VMware or Citrix environments, I suggest you check out the new release of PHD Virtual Backup and Replication 5.4 which has added high performance, cloud enabled data protection.
Extensible API Integration – The new PHD Virtual API and SDK makes it easy to integrate backup, recovery and replication with your existing infrastructure, tools and applications. It also provides additional flexibility to extend and customize data protection for your virtualized applications.
Management Console Performance Improvements – New optimizations improve the interaction and responsiveness of the management console for larger deployments.
As with its previous version, PHD offers VM replication for fast and easy disaster recovery. More information about PHD Virtual backup and monitoring products can be found at www.phdvirtual.com.
¿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.
Hola amigos, esta semana vamos a ver como configurar de forma básica Dynamic Memory Control (DMC) para nuestros Pools de XenServer, una funcionalidad que resulta muy interesante para flexibilizar nuestro entorno y optimizar recursos.
Esta tecnología permite a las máquinas virtuales aumentar o reducir su memoria RAM en caliente de forma dinámica dependiendo de la carga del servidor a partir de in intervalo definido entre memoria mínima y máxima que puede llegar a consumir una máquina virtual.
Para los que utilicéis la versión Free y queráis utilizar esta funcionalidad, es necesario tener como mínimo un licenciamiento Essentials.
En pocas palabras, podemos ajustar la cantidad de RAM sin sobredimensionar las máquinas virtuales con su consecuente pérdida de memoria para el resto del entorno, ni quedarnos cortos teniendo luego que apagar la máquina virtual y añadirle más memoria.
Usando XenCenter, es muy sencillo de configurar, solamente tenemos que establecer el intervalo mínimo y máximo de memoria por cada máquina.
Una vez establecido estos valores, la cantidad de memoria oscilará entre el límite mínimo y máximo de la cantidad máxima asignada.
Con esto me despido por hoy, espero que como siempre, te haya parecido interesante y animarte a utilizar XenServer en tus sistemas.
¿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 que tal, como estáis? Soy José Mª Gris y como cada miércoles estoy aquí con vosotros para hablar y comentar que ocurre en el Ecosistema.
En Octubre de año pasado os hablaba de Cloudarray de TwinStrata y como me había impresionado su facilidad de instalación y la performance que desarrollaba. Me quedó una duda, ¿cómo juega todo esto en el ecosistema?
Una charla con Said de Datacore me dio todo la visión de cómo jugaban los dos productos y cual era era el sentido de una SAN en Cloud.
Todo ello ha cogido mucho más sentido en la entrevista con George Teixeira 1 , 2 y 3 parte, donde queda claro el concepto del “Big Data” por un lado y por otro el sentido común de usar disco “barato” para los datos de menos uso y disco “caro y de “mas perfomance” para los datos mas “calientes” de la organización. Todo ello nos conduce al Tiering del Storage, el Auto-tiering y el concepto de tener una masa de disco “on demand”.
He hecho pruebas con CloudArray pero reconozco que la mayor limitación del producto ha sido el número de proveedores de SAN en Cloud que enlazaba.
Pues bien, parece que los amigos de TwinStrata están por la labor. Acaban de anunciar la versión 3.2.2 de su producto estrella que tiene estas nuevas funcionalidades:
Soporte para nuevos proveedores de cloud Storage
Google cloud storage support – US o EU regions
Cloudian cloud storage support
New Amazon S3 region support
Sao Paulo región support added
Acceso seguro SSL de CloudArray basado en la interfaz de web de usuario
Parece que están en el buen camino para hacer un producto que revolucione la forma de plantear el storage. Podéis conseguir una demo full funcional en su web con una subscripción sin cargo temporal de algunos proveedores de SAN en Cloud.
Espero que el tema os interese. Hasta la semana que viene, take care!
¿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.
