Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes. Antes de nada quiero desearos un feliz inicio de año 2012 y que lo acabéis mejor que lo empezáis.
Alguna vez te has preguntado: ¿Cuanto dura un vMotion en una VM de 255GB de memoria asignada? es decir el límite de memoria de una VM en un host ESX/ESXi v.4 con hardware v.7 en la placa base de la máquina virtual. Pues con vSphere 5 aparecen VMs de hasta 1GB de RAM, anunciando migraciones de larga duración para máquinas virtuales de gran formato.
vSphere 5 trae una funcionalidad que no aparece entre las mas importantes pero que es muy bien recibida en entornos con grandes máquinas virtuales. Me refiero a la posibilidad de hacer vMotion utilizando varios interfaces de red SIMULTANEAMENTE.
En EMC han realizado un análisis de carga interesante, han comparado un vMotion con diferentes escenarios, con 1 NIC, con 2NICs y con 4 NICs.
La máquina virtual de test no está nada mal, un SQL Server con 60 GB de memoria, mas de 2TB de datos y 10.000 IOPS. Es decir una máquina virtual con alta actividad y tamaño medio/alto.
Los resultados (redondeados a minutos) han sido los siguientes:
vMotion con 1 puerto de vmKernel: 23 minutos.
vMotion con 2 puertos de vmKernel: 8 minutos.
vMotion con 4 puerto de vmKernel: 3 minutos
Para evitar dudas os diré que las pruebas se han hecho con todos los interfaces a 1Gbps y con una MTU de 9000 bytes, o como la conocemos coloquialmente con Jumbo Frame activado en todos los puertos de vmKernel.
¿Cuál es la conclusión?
En todo diseño con máquinas virtuales de tamaño medio o grande, hemos de tener en cuenta el tamaño de las maquinas mas grandes para atender sus necesidades de conectividad y sus necesidades de movilidad, o sea vMotion. La eficiencia obtenida es tan alta con vMotion multi-NIC que merece la pena invertir un poco en interfaces de red.
Con máquinas de gran tamaño ¿Os podéis permitir tardar mas de una hora en poner un host en mantenimiento? o bien que DRS tarde este tiempo en mejorar el balanceo de un cluster ¿impensable verdad?
¿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.
VMware vSphere™ ESXi 5 incluye dos nuevas funcionalidades para aumentar la seguridad del VMkernel:
Memory Hardening: El kernel del ESXi, aplicaciones user-mode y ejecutables como drivers y librerías están localizadas en zonas de memoria aleatorias para evitar que software del tipo troyanos averigüen de una forma sencilla la localización de estas zonas de memoria.
Kernel Module Integrity: Los módulos, drivers y aplicaciones de ESXi son “firmados” digitalmente para asegurar la integridad de estos una vez que el VMkernel los carga en memoria.
Asimismo, a diferencia de las versiones VMware ESX 4.x, en VMware vSphere™ ESXi 5 es posible hacer boot de tu servidor ESXi desde un disco USB externo. También es posible instalar tus servidores ESXi con la opción de VMware Auto Deploy, sobre todo cuando tienes un número de host importante que instalar. De esta forma, acelerarás la fase de instalación del binario de ESXi y el despliegue de tus máquinas virtuales.
Si haces una actualización de la versión ESX 4.x a la versión ESXi 5 el portgroup tipo Service Console (solo disponible en versiones ESX) será borrado, ya que en los servidores ESXi no existe un Service Console. Asimismo, el portgroup de gestión en ESXi es llamado Management Port. Recuerda antes de actualizar un servidor ESXi hacer una copia de seguridad de su configuración con el comando vicfg-cfgbackup desde el vCli.
Desde el punto de vista de almacenamiento compartido SAN iSCSC, el número máximo de LUNs iSCSI que puedes conectar a un servidor ESXi es de 256. Otro de los límites que han cambiado en esta nueva versión de VMware vSphere™ ESXi 5 con respecto a las versiones anteriores, es que ahora es posible tener arrancadas hasta 2.048 máquinas virtuales por volumen VMFS.
También, ahora es posible activar – y está soportado – el modo soporte (TSM – de las siglas en inglés Tech Support Mode) de modo que podrás entrar vía SSH a tu servidor ESXi. Puedes activar el modo TSM desde la DCUI (de las siglas en inglés Direct Console User Interface) o con el vSphere Client a través del panel Security Profile localizado dentro de la pestaña de Configuration.
Una vez entres en la consola de tu servidor ESXi vía comando, podrás ver los logs de tu sistema, configurar las propiedades de los servicios de DNS, NTP, arrancar máquinas virtuales, apagar servidores ESXi y un largo etcétera. Sin embargo, una de las pocas tareas que no podrás hacer desde consola es la de poner tu host ESXi en modo mantenimiento.
Para poder ver una guía de referencia de todos los comandos disponibles por consola en la versión ESXi 5.0, te recomiendo que veas el episodio número 31 de nuestro canal de televisión web sobre la virtualización y el cloud computing en español en la siguiente dirección: http://www.virtualizacion.tv
Asimismo, con el fin de mejorar la seguridad del servidor ESXi, VMware ha añadido un firewall embebido en el VMkernel. A diferencia de las versiones anteriores, este firewall no está basado en IPtables de Linux.
Por último, y si aún tienes servidores VMware ESX en tu entorno virtual y necesitas aplicar parches en el Service Console del ESX, debes de asegúrate de aplicar dichos parches solo y únicamente cuando VMware haya hecho público las actualizaciones y siempre que sea sugerido por personal autorizado de VMware o por el equipo experto de VMware llamado VMware Security Advisories. Para poder recibir alertas de seguridad sobre vulnerabilidades del software de VMware, puedes suscribirte en esta dirección: http://www.vmware.com/security
¿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 Florián Murillo y hoy hablaremos de como podemos automatizar, desde PowerCLI, la creación de un vSwitch, un port-group y un puerto de kernel en un host.
Antes de describir las líneas anteriores, solo explicar la regla utilizada para asignar nombres a las variables y objetos, los objetos empiezan por “o_” a diferencia de las variables que almacenan valores básicos como una cadena de caracteres.
01 al 05. Asignamos valores a variables, $server es el nombre del host sobre el que vamos a trabajar, $vsw es el nombre del vSwitch que vamos a crear, $pg es el nombre del port-group que crearemos en el vSwitch, $vmkIP es la IP del puerto de kernel que vamos a crear en el vSwitch y $vmkMask es la máscara IP del puerto de kernel.
06 y 07. Creamos objectos, $o_server es el objeto VMHost que representa al host almacenado en $server, y $o_vnw es el objeto VMHostNetwork que almacena la información de red del host $server.
con la instrucción :
> $o_server | Get-Member | Format-List
podemos ver los métodos y propiedades de la clase VMHostNetwork, de la cual hereda $o_server.
08. Una de las propiedades de un objeto del tipo VMHostNetwork es una tabla de objetos llamada PhysicalNic, la cual tiene tantas entradas como interfaces vmnic el host. El objeto PhysicalNic[1] describe el interfaz vmnic1, y su propiedad PhysicalNic[1].DeviceName nos informa del nombre del interfaz. En esta línea asignamos ese valor a la variable $pnic, este será el interfaz a añadir al vSwitch. Hemos visto en esta línea como recuperar la información de una propiedad de un objeto, con la sintaxis “objeto.propiedad”.
09. Creamos el vSwitch llamado $vsw en el host $o_server entregándole la interfaz $pnic. Creamos un objeto $o_vsw que contiene toda la información del switch recién creado. En el vCenter Server veremos lo siguiente:
10. Creamos un port-group llamado $pg en el vSwitch $o_vsw. En el vCenter Server veremos lo siguiente:
Creamos un puerto vmkernel en el host $o_server, el puerto estará en el port-group “vMotion network”, en el vSwitch $vsw y le entregaremos la IP $vmkIP y la máscara $vmkMask. La función a realizar por este puerto de kernel se la especificamos con el flag -VMotionEnabled:$true
Observar que en este comando hemos entrado directamente el valor del port-group sin utilizar una variable, es otra posibilidad.
Habréis observado que a veces entramos objetos como parámetros y en ocasiones variables, eso depende de la definición del comando.
Hasta ahora PowerCLI ha sido una herramienta eficaz para automatizar procesos de explotación, pero ahora además, es necesario su conocimiento para el examen VCAP. Hasta la semana próxima.
¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.
¿ Alguna vez has tenido el problema de máquinas virtuales inaccesibles ?
Es uno de los errores/problemas mas frecuente que se dan en entornos de virtualización con VMware vSphere ESX/ESXi, y que están relacionados, principalmente, por motivos de perdida de acceso al datastore NFS.
En este episodio nos “bajaremos” de nivel – via ssh – para usar el comando vmkmod_load y poder ver así, los módulos del kernel VMware ESX/ESXi que tenemos ejecutando en nuestro servidor VMware vSphere ESX/ESXi.
En este episodio número #50, en concreto, veremos como podemos confirmar que el modulo nfsclient esta arrancado, así como el comando exacto para arrancarlo si este no estuviera cargado en memoria del VMkernel:
Pues nada, aquí escribiendo el post mientras Pedrito amartillea la portería de Alemania y tengo el “Editor in Chief”, Jose Maria González perdiendo los nervios a mi lado esperando el gol que llegará.
Jose Mª y su esposa Ann están en casa viendo la semifinal. Post histórico escrito durante la semifinal de los mundiales del 2010
Que tal, soy Jose Mª Gris, en crónica de urgencia para nuestros amigos del Blog.
Jose Maria nos explicaba hace poco, como monitorizar los i/o de los discos de nuestra infraestrutura. Importante el mantener el buen funcionamiento de nuestro sistema.
Os voy a presentar una pequeña joya, AppVIEW de vkernel:
Esta herramienta gratuita nos permite monitorizar 5 VMs de forma gratuita. Nos monitorizará memoria, CPU, capacidades de disco, i/os.
Por cierto, Gol de Pujol!!!!!
Si hay un problema, os dirá una orientación del error y podréis bajar una trial de Vkernel Analyzer durante 15 días. Excelente herramienta para tunear.
VMware vSphere puede reclamar hasta un 65% de la memoria de la máquina virtual durante el proceso de ballooning por defecto.
Sin embargo si has reservado memoria en la máquina virtual, el mecanismo de ballooning no podrá acceder a la memoria reservada de esta máquina virtual, a no ser que dicha máquina virtual no este usando su memoria reservada.
Es posible cambiar el porcentaje máximo de memoria que por defecto el mecanismo de ballooning puede reclar. La opcion avanzada del VMkernel es Mem.CtlMaxPercent.
Una de la mejores configuraciones de este setting es no configurar las reservas de memoria demasiado bajas, ya que de ser asi, el VMkernel, y durante periodos de alta activada, podría forzar hacer swapping a disco lo cual relantizaria enormemente el rendimiento de tu servidor VMware ESX/ESXi.
En este episodio #28 te mostrare una mejor practica sobre como configurar las reservas de memoria de las máquinas virtuales para evitar swapping del VMkernel:
El balloon-driver permite ceder memoria desde las máquinas virtuales al VMkernel para que este, pueda asignar dicha memoria a otras máquinas virtuales más necesitadas de memoria RAM.
Este mecanismo de compartición de memoria – balloon driver – también es conocido como vmmenctl. Cuando una maquina virtual necesita “ceder” parte de su memoria a otras maquinas virtuales, es el sistema operativo guest el que decide que páginas de memoria serán decidas ya que este conoce mejor las páginas de memoria que fueron accedidas en última instancia.
El sistema operativo guest dentro de la maquina virtual no es “consciente” de la comunicación que existe entre el mecanismo del balloon-driver y el VMkernel. No obstante, el sistema operativo guest es consciente de que el balloon-driver (vmmenctl) ha sido instalado, aunque no conoce cuál es el propósito final de dicho driver.
Así, cuando la memoria física del servidor ESX/ESXi escasea, el VMkernel elige una maquina virtual a la cual reclamara memoria RAM.
Por defecto, el VMkernel puede reclamar hasta un 65% de la memoria virtual de las maquinas virtuales durante el proceso de ballooning, siempre que estas maquinas virtuales no tengan memoria virtual reservada, en cuyo caso esta no podrá ser reclamada por el VMkernel si esta en uso.
El parámetro avanzado del VMkernel que controla cuanta memoria puede ser reclamada por esta técnica de ballooning es Mem.CtlMaxPercent y puede ser configurado hasta un total del 75% de la memoria virtual de las maquinas virtuales.
Para poder usar este mecanismo de compartición de memoria, es necesario tener instaladas las VMware tools en la máquina virtual, ya que de no tenerlas instaladas, la maquina virtual no podría usar esta técnica.
Un uso excesivo de actividad de balloon driver entre las máquinas virtuales y el VMkernel, seguido de una actividad “alta” del VMkernel swap, podría indicar que el servidor físico necesita más memoria física. Por consiguiente, el componente de memoria RAM física del servidor ESX/ESXi, podría contener un cuello de botella.
Hasta la proxima semana con un nuevo truco de VMware – mejor dicho -, hasta el próximo año.
El blog de Virtualización te desea un propero año nuevo
Cada máquina virtual que este encendida, necesita su propio fichero VMkernel swap. Este fichero permite al VMkernel, hacer un swap de la memoria RAM de la máquina virtual a disco, si la memoria física escasea. Nota que esta técnica es el último mecanismo para ahorrar memoria y que el rendimiento, tanto de la maquina virtual como del ESX, seria gravemente afectado.
Dicho fichero swap es creado cuando la máquina virtual es encendida y, es borrado cuando la máquina virtual es apagada. El tamaño del fichero swap es igual al tamaño de la memoria RAM asignada a esa máquina virtual. Por ejemplo, si asignamos un 1GB de memoria RAM a nuestra máquina virtual, el tamaño del fichero swap será de un 1GB, siempre y cuando, no asignes ninguna reserva.
En caso de reservar 256MB de memoria RAM, el tamaño del fichero swap será la diferencia entre el total de memoria asignada (1GB) y la reserva (256MB) , es decir, el tamaño de nuestro fichero swap seria 1GB – 256MB.
Por defecto, la localización del fichero swap estaría en el mismo volumen VMFS donde reside el disco virtual de la máquina virtual. La localización del fichero swap puede ser cambiada, aunque no es recomendable por VMware ya que podría afectar el rendimiento de una máquina virtual cuando se esté migrando en caliente con VMotion.
Descubre y domina la nueva versión de VMware vSphere™ 5 y aprovéchate de hasta un
20% de descuento al comprarlo online.
Regístrate y
recibe un capitulo de nuestro nuevo libro totalmente gratuito
Nuevo Site Recovery Manager 4 en español Consigue una copia gratuita del eBook
