Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.
Cuando un procesador accede a la memoria lo hace a través del bus de memoria pero, cuando la placa base del ordenador tiene varios procesadores, TODOS acceden a la memoria a través del mismo bus de memoria. Esto produce un cuello de botella en la arquitectura de los procesadores debido a las esperas para utilizar el bus de memoria.
Para evitar congestión en el acceso a memoria, se creo la arquitectura Non Uniform Memory Architecture (NUMA). En NUMA, cada procesador tiene acceso directo mediante un bus privado a unos bancos de memoria. Además, comparten el bus de memoria general para acceder a la memoria asignada a otro procesador.
Es decir, puedes acceder a un banco de memoria desde el bus general de memoria por cualquier procesador y desde el bus privado por el procesador preferente.
Esto mitiga las esperas en el bus general ya que se utiliza mucho menos.
Según los benchmarking encontrados en vmware.com, NUMA proporciona acceso a memoria entre 2 y 3 veces mas rápido.
¿Cómo asegurarme que NUMA está activado en mi sistema?
Normalmente se le encuentra como “interleaving” en la BIOS: cuando interleaving está desactivado, entonces NUMA esta activado.
¿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.
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.
).
