En la tabla adjunta, se muestran los cinco tipos de almacenamiento soportados en VMware vSphere™ ESXi 5, así como las diferentes funcionalidades soportadas por cada tipo de almacenamiento.
Con relación a la conectividad iSCSI y su iniciador de software iSCSI, el máximo número de iSCSI targets es de 265. Nota que ahora es posible hacer Boot from SAN (BFS) con iniciadores de software iSCSI.
Asimismo, no es posible crear más de un NIC Teaming con el iniciador de software iSCSI con más de 8 vmnics (uplinks o tarjetas de red físicas disponibles en el servidor ESXi). Solo es posible tener un número máximo de ocho caminos por LUN para los volúmenes VMFS conectados vía software o hardware iSCSI.
En cuanto al tamaño máximo de un volumen VMFS para la versión 3 (VMFS-3) es de 2TB menos 512Bytes de espacio con un block size de 8MB. Sin embargo, en VMFS versión 5 (VMFS-5) el tamaño del block size es de tan solo 1MB, aunque es posible crear ficheros .vmdk con un tamaño máximo de 2TB. Recuerda que en VMFS versión 3 y con un block size de 1MB, el tamaño de disco de la máquina virtual (.vmdk) no podrá superar los 256GB de espacio en disco.
También, el tamaño máximo para un volumen RDM (de las siglas en inglés Raw Device Mapping) en VMFS-5 es de 64TB, siempre y cuando uses la funcionalidad de extenders a nivel VMFS y el modo de compatibilidad de este RDM sea físico. Sin embargo, para un volumen RDM VFMS-5 en modo de compatibilidad virtual, el tamaño máximo es de 2TB menos 512 bytes.
VMware vSphere™ ESXi 5 usa el protocolo NFS versión 3 para comunicarse con cabinas de tipo NAS. Nota que aunque NFS también puede usar la versión 4, esta no está soportada por VMware. En la versión VMware vSphere™ ESXi 5, ahora es posible montar hasta 256 volúmenes NFS por host.
Con relación a los ficheros swaps de las máquinas virtuales, el tamaño máximo que puede alcanzar este tipo de ficheros es de 1TB por máquina virtual, siempre y cuando, configures tu máquina virtual con 1TB de memoria RAM. Puedes ver más información sobre la configuración del block size en VMFS-5 en nuestro canal oficial de YouTube: VMware vSphere 5.0 en entornos SAN iSCSI
En cuanto al número máximo de targets que un servidor host puede ver con un adaptador Broadcom 10GB iSCSI es de 128 targets. El número máximo de tarjetas 1GB Ethernet Broadcom (bnx2) que un servidor host ESXi puede tener es 16.
Por ultimo, recuerda que es posible tener todas las funcionalidades enterprise de VMware (HA, vMoting, Storage vMotion, DRS) con un almacenamiento NAS via NFS. Interesante, ¿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.
Hola amigos, hoy voy a repasar el Webinar de Citrix de la semana pasada, “XenServer 6.0 Technical Master Class” con Lee Bushen y Steve Benton ya que fue muy constructivo y creo que puede ser de vuestro interés.
En el primer cuarto de hora se pudo ver el funcionamiento interno de XenServer, donde se mostró de una forma muy gráfica [PAG 8 del pdf], los dos “pueblos” que componen este sistema. Por un lado “Xenville” donde vemos “xe”, la XAPI y la “XenServer Pool DB (state.db) y por otro lado la parte “Linux Land”, donde al final, todo lo que interpreta la XAPI, se transforma en ficheros de configuración GNU/LINUX.
Posteriormente se explicó algo que ya hemos hablado en este blog, como XenServer organiza el Storage con sus diferencias y modalidades. SR’s, PBD’s, VBD’s. Una parte muy interesante de esta sección fue cuando explicaron cómo se organizan internamente los snapshots, en función del tipo de almacenamiento que podemos utilizar, NFS y Storage Local, LVMD, iSCSI y FC.
Del mismo modo que el storage, en parte de comunicaciones, se explicó desde el hardware hasta llegar a los dispositivos de red virtuales, el funcionamiento de los bridges y como XenServer utiliza el bonding.
En general el Webinar estuvo muy bien. Aplaudo la iniciativa de Citrix y de otras compañías que ofrecen este tipo de seminarios gratuitos para los fans de sus plataformas.
Con esto amigos, nos vemos la semana que viene con la monitorización del storage con Nagios. Aprovecho también para desearos unas felices fiestas a todos.
¿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 amigo, hoy vamos a ver un repaso de las posibilidades disponibles de almacenamiento que tenemos para Citrix XenServer.
Veremos sus pros y sus contras para determinar cual puede ser nuestra mejor opción.
Las opciones que tenemos para un SR son:
Veamos las propiedades de cada una de estas tecnologías.
Local Storage: Por defecto XenServer utiliza los discos locales para poder almacenar máquinas virtuales. Utiliza LVM implementando el formato VHD para los VDIs. VHD permite que los discos sean sparse y que el espacio se vaya reservando en función del crecimiento de los discos de las máquinas virtuales. En las versiones 5.6 y 6.0 se implementa también thin provisioning, para el uso de escritorios vdi con XenDesktop. Fundamentalmente la ventaja principal es que según el Host físico y el tipo de disco, ofrecen un rendimiento superior, sobretodo si se usa discos en estado sólido. El problema es que no pueden ser compartidos como recurso de cluster y las máquinas virtuales instaladas en un disco de un host en local, no serán accesibles por los otros hosts del Pool.
Rápido y optimización de espacio. Pero no puede ser compartido por otros hosts.
NFS: XenServer soporta NFS3 por TCP/IP y permite crear SRs implementando VHD por lo tanto también son óptimos en cuanto a la optimización de espacio. A diferencia del disco local NFS es montado como recurso compartido del Pool y cualquier host puede acceder los VDIs almacenados en este tipo de recurso. Lo bueno también del NFS es lo estándar que es en el mundo UNIX/Linux, que por lo tanto hay multitud de appliances que permiten su gestión simplificada y no hace falta obligatoriamente disponer de una cabina de discos para trabajar en un entorno cluster.
Optimiza el espacio de disco “sparse”, gestión simplificada. Hay que vigilar que no sobrepase el espacio que hemos asignado, pues las VM crecen.
iSCSI: La utilización de iSCSI en XenServer permite una implementación de los discos compartidos muy eficiente a nivel de red a bajo coste. Para ello hemos de configurar nuestra cabina de disco para presentar las LUNs que posteriormente se utilizaran como SRs. Una vez configurado se presenta al sistema como LVM donde los diferentes VIDs tendran un volumen lógico asociado. Los VDIs no pueden ser “sparse” y siempre ocuparan el espacio que hayamos definido en la creación del disco. Parecido a los discos tick de VMware.
Muy óptimo a nivel de red y por lo tanto muy buen rendimiento de disco para las máquinas virtuales. Se desaprovecha espacio al no ser discos dinámicos y a su vez ofrece mejor control del disco usado/libre.
Fibre Channel: Funciona en XenServer de forma parecida que iSCSI y disco local, los discos son VHD corriendo sobre volúmenes lógicos LVM. Hay que disponer de HBAs compatibles con XenServer como Qlogic, Emulex, etc.
Alto rendimiento y optimización de espacio. Hay que tener HBAs compatibles con XenServer.
StorageLink: Sin duda la mejor opción si dispones de un licenciamiento Enterprise o Premium y tu cabina es Citrix Ready o si usas NexentaStor como appliance. StorageLink se define como la capa de interoperabilidad nativa entre XenServer y nuestra cabina de discos. Por lo tanto nos permite realizar clones súper rápidos, snapshots, thin provisioning en la propia cabina desde XenCenter.
Pensado como la solución más avanzada, es la mejor opción si necesitas un entorno de muchas máquinas y funcionalidades extra más allá del alojamiento de VDIs
Conclusiones: Principalmente, en mi modesta opinión, depende del presupuesto destinado y a la dimensión del entorno. Si estas usando una infraestructura de 4-6 nodos con unas 40 VM, un storage iSCSI contra una cabina de discos, funciona perfectamente. Si tienes de 2-3 servidores y no tienes cabina de discos, con una buena maquina sirviendo NFS funcionaría perfectamente. Y si tienes de 50 a 100 Hosts, con XenDesktop, muchos templates y una buena cabina, sin duda StorageLink.
¿Qué tecnología de almacenamiento utilizas en tus entornos?
Eso es todo por hoy amigo, espero como siempre que haya podido aportarte un granito de arena a tus conocimientos sobre la virtualización de servidores con XenServer.
¿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.
Hola amigos. Soy Ferran Serafini y aquí vuelvo hoy como cada miércoles para aprender algo nuevo sobre Citrix XenServer.
La semana pasada Citrix presentó la nueva versión oficial de XenServer 6. Hace unos meses ya vimos las novedades que incluía ya en su versión beta 2. Os dejo un video tutorial en el que podréis ver la instalación de XenServer 6 paso a paso y las novedades más relevantes que escribió nuestro compañero Adolfo Muñoz, aquí
Hoy vamos a ver cómo funcionan los discos en XenServer. Veremos primeramente un poco de teoría para entender como XAPI abstrae y presenta los recursos de discos a nuestras máquinas virtuales.
En XenServer los discos desde la maquina virtual hasta el Host tienen el siguiente conjunto de clases. Esta “jerarquía” viene dada por la XAPI:
VDI: (Imagen de Disco Virtual) Un objeto VDI es la representación de un disco virtual. Los VDIs tienen la propiedad de poderse redimensionar y clonar.
VDB: (Dispositivo de bloque virtual) Este objeto representa la unión entre una máquina virtual y un VDI. Cuando una máquina virtual inicia, primeramente se consulta sus objetos VBD para determinar que discos virtuales VDIs tiene asociados. Los métodos de la clase VBD permiten la conexión y desconexión en caliente de un dispositivo de disco VDI.
SR: (Repositorio de almacenamiento) Es el contenedor donde residen los VDIs encapsulando las propiedades de un almacenamiento físico.
PBD: (dispositivo de bloque físico) Representa la unión entre el host físico y un objeto SR. Este presenta una capa de abstracción física del modo en que se conecta físicamente el disco, NFS, I-scsi, etc a los objetos SR.
Sabiendo esto, para consultar que discos tiene una maquina virtual, ya sabemos que no hemos de ir a buscar un VDI directamente (como nos presenta XenCenter). Es importante ya que los que estéis muy acostumbrados al XenCenter podéis pensar que la maquina virtual va conectada directamente al VDI, y como habéis visto, no es así, la maquina virtual tiene conectados los VDB.
Por lo tanto para consultar que discos tiene una maquina virtual utilizaremos el comando:
Vemos aquí que nuestra maquina virtual vMachine01 tiene dos VDIs conectados, identificados por vdi-uuid: f28ab1b1-e6f4-453f-8d1a-73cbb5c26d14 i 8b0a9e82-064c-ecae-4e46-b8b50d6d6974
Bueno amigo, esto es todo por hoy. Te espero la semana que viene con más trucos y explicaciones para tener bien controlados tus entornos Citrix XenServer.
¿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.
Esta semana te enseñare a instalar y configurar una cabina SAN iSCSi en la nueva versión de VMware vSphere ESXi 5.0.
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 el cloud compuitng en español: ¿Cómo instalar y configurar una cabina SAN iSCSI en la nueva versión VMware vSphere ESXi 5.0? Espero que te guste.
Nos vemos el próximo lunes con un próximo episodio donde te enseñare, otro video tutorial sobre la virtualización y el cloud computing.
Gracias a todos los que dejasteis vuestro comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, deja tu comentario abajo en este video.
¿Crees que este videopost le puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Muchas gracias por tu apoyo.
La política de Round Robin no emite E/S de una forma simple y llanamente como su propio nombre indica.
Por defecto, cuando seleccionas el PSP – de las siglas en inglés Path Selection Plugin – de Round Robin, esta política envía 1.000 comandos E/S de disco por cada ruta antes de pasar al siguiente camino, lo cual es llamado IO Operation Limit.
En algunas configuraciones, yo diría en la gran mayoría, esta configuración por defecto no muestra la agregación de caminos en su máximo exponente porque muchas veces algunos de los miles de comandos de E/S de disco se han completado antes de que el último comando fuese enviado. Esto significa que los caminos de almacenamiento no estarán llenos (a pesar de que la cola en la cabina de almacenamiento puede ser que si este llena).
Cuando se utiliza 1 Gbit en una conexión iSCSI, muy frecuentemente la ruta física es el factor limitante en el rendimiento, y haciendo uso de varias rutas al mismo tiempo con la política de Round Robin, puede que muestre un mejor rendimiento.
Lo interesante de esta política de PSP es que puedes reducir el número de órdenes emitidas por un camino en particular, antes de pasar al siguiente camino hasta llegar a una E/S de disco, lo que garantiza que cada comando posterior se envíe por un camino diferente.
En una configuración con una cabina de almacenamiento de Dell EqualLogic, yo recomiendo un valor de 3 E/S de disco para el campo IO Operation Limit.
Para poder hacer este cambio, es necesario ejecutar el siguiente comando:
esxcli – server nmp roundrobin setconfig – device – IOPS — type iops
No obstante, ten en cuenta que el hecho de disminuir el número de IOPS presenta algunos problemas potenciales.
Mediante la difusión de las solicitudes de E/S a disco a través de varias rutas, estamos influenciando de una manera negativa la optimización de la cache de cualquier cabina almacenamiento lo que puede acabar por afectar el rendimiento de esta.
Afortunadamente, muchos de los sistemas de almacenamiento más modernos no “cachean” por puerto. No obstante, y aunque menos importante, el cambiar constantemente la E/S de disco entre las rutas disponibles representa un uso adicional de ciclos de reloj de la CPU de nuestro servidor VMware ESX/ESXi con lo que hay que tenerlo en cuenta.
¿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.
Hola, soy Miguel Ángel Alonso y aquí estoy como cada martes para hablaros sobre el maravilloso mundo de la virtualización. Siguiendo la estela de la semana pasada en la que comenzamos a introducirnos en el mundo de la virtualización de Microsoft con Hyper-V R2, continuaremos con el capítulo 2, en el cual veremos de forma generalizada como instalar y configurar nuestros servidores para comenzar a virtualizar nuestros entornos con Microsoft HyperV. Antes de empezar a mostraros ambos procesos y vista la suscitación que el post de la semana pasada tuvo en nuestros lectores (¡¡¡Gracias Akuma,Sombra y Diego!!!!), vamos a dar unas pequeñas notas sobre las capacidades de Hyper-V y alguna nota descriptiva de interés:
Aquí podréis encontrar los S.O. soportados por Hyper-V
Requerimientos del sistema:
Procesador x64 con Intel VT o AMD-V activado
Mínimo de 1.4 GHz de CPU y, 2 GHz (recomendado). Soporte de hasta 8 procesadores físicos y 64 lógicos. Hasta 4 procesadores virtuales por VM
Mínimo de 1 GB de RAM ,2 o más (recomendado). Máximo de 1 TB. Posibilidad de usar NUMA para una mayor eficiencia de la gestión de la memoria.
Un mínimo de 8Gb de espacio en disco, 20 GB (recomendado). El sistema de archivos es NTFS. Uso de volúmenes compartidos(Clúster Shared Volumes) para el uso de Live Migration, Dynamic Optimization o Alta Disponibilidad.
DVD Rom
Display (super VGA) 800X600 o mayor
Soporta hasta 384 VMs por Host
Con la versión R2 conseguimos soporte para JUMBO FRAMES, el cual debe ser soportado por la electrónica de Red, cabina y activado el los Switches virtuales mediante el gestor de propiedades de nuestra tarjeta de Red.
Si utilizamos el teaming de tarjetas de Red, este se activará desde el correspondiente software de gestión especializado (Intel,Broadcom,etc…)
Respecto al almacenamiento compartido debo decirte que el Cluster de Microsoft trabaja con iSCSI-3 (reservas persistentes) por lo que nuestro almacenamiento deberá soportar dicha tecnología. Esta pequeña nota también va dirigida para aquellos que utilizan Openfiler en sus entornos de Laboratorio, ya que este “no soporta” dicha tecnología (iSCSI-3). Necesitaremos de 2 LUNs como mínimo en un entorno de Alta Disponibilidad (1 para el Quorum) imprescindible en los Cluster de Microsoft y otra para el almacenamiento de nuestras VMs.
Recomiendo la descarga de las herramientas de administración remota de servidor para la gestión de Sevidor ( VMs y el Cluster desde nuestro portátil o PC). Aquí como ejemplo podéis encontrar las de Windows 7 SP1.
Así que, una vez tenemos preparada todas las necesidades, procederemos a ver la instalación:
Una vez instalado el paquete recomendado para la gestión remota del servidor de Windows 7 SP1, iremos a Panel de Control-Programas-Activar o desactivar características de Windows y marcaremos las que se ven en rojo, para la gestión de los Host y el Cluster.
Iremos a nuestro/s Host/s y desde la consola de mantenimiento del servidor, en el apartado roles, ejecutaremos añadir role (como se indica em la imagen anterior).
Y marcaremos la opción de Hyper-V para añadir el role de Virtualización de nuestro Servidor, este seguirá con unos sencillos pasos donde deberemos elegir que tarjeta utilizaremos como tarjeta de gestión.
Aquí, ya podemos ver el role de Hyper-V activo y trabajando con una máquina virtual en marcha.
Seguido a todo esto, y desde la consola de mantenimiento de nuestro/s (Host/s), deberemos activar 2 características fundamentales:
Failover Clustering
Multipath I/O
Con la primera opción, estaremos preparando nuestros HOSTS para alta disponibilidad y con ello las máquinas virtuales. Con la segunda, tendremos activado el Multipathing para preparar los caminos de conexión a nuestro almacenamiento y dotarlo de balanceo y/o Failover.
Con el administrador de Hyper-v, una vez abierto, podemos ver como dentro de la imagen de arriba, en su recuadro en rojo, aparecen las acciones más comunes que se utilizan para gestionar el Host y las VMs.
No voy a nombrar todas las opciones, ya que la mayoría son obvias como su propio nombre indican. Sólo me centraré en la configuración del Host, administración de las redes virtuales y la configuración de las máquinas virtuales en cuestión.
Desde la configuración del Host podemos indicar como más relevante la opción de la activación de NUMA para el uso eficiente de la memoria de las VMs y las opciones de la ruta de almacenamiento de las VMs y discos virtuales del Host.
Desde la opción de redes Virtuales podremos crearnos las redes que vamos a utilizar en nuestro entorno y podremos asignarles diferentes usos:
Externo: Es como el Bridge de VMware (Conexión directa con la tarjeta física)
Interno: Red en el que todas las VMs de los Hosts se comunican con la partición padre y entre ellas pero no tiene salida hacia el exterior.
Virtual Privada: Las VMs sólo se comunican con la partición padre y las VMs dentro del mismo Host.
Cabe reseñar que las redes que creemos en los Hosts deben de denominarse de la misma manera en todos ellos.
Desde el administrador de Hyper-V y sobre la opción Nueva Máquina Virtual, aparecerá sobre tu pantalla un asistente para crear nuestra máquina virtual llamada Test. Aquí, le damos un nombre y una ruta de almacenamiento para albergar la VM.
En la ubicación de almacenamiento la he modificado para que apunte a ClusterStorage\volume 1 porque es la carpeta (virtual) que representa al espacio de la LUN compartida de almacenamiento de las VMs y que antes he nombrado. Estos son los famosos CSV (Cluster Shared Volumes) que configuramnos desde el asistente del Cluster. Si tuviésemos otra LUN compartida, entonces sería ClusterStorage\volume 2 y así sucesivamente.
En el siguiente paso, seleccionaremos la memoria que quieras que tenga tu VM.
Siguiendo el asistente, elegiremos la red virtual creada en los pasos anteriores que queremos que tenga nuestra VM.
Aquí, le daremos el tamaño necesitado para nuestro disco virtual con sus diferentes opciones.
En el siguiente paso daremos la ruta de la imagen de instalación del Sistema Operativo (ISO ,DVD-ROM, Red)
Y finalmente veremos el resumen de opciones de nuestra VM. Aquí, podemos ver como ya aparece nuestra VM creada y lista para instalar el S.O.
Desde la opción de configuración de la VM, puedes modificar cualquier parámetro que se te ocurra (añadir redes, añadir discos, encendido automático de la VM, etc..). En la imagen de arriba aparecen los famoso servicios de Integración de la VM (similar a las VMware Tools o XenTools) para el control avanzado de las VMs.
Finalmente os mostraré la consola de administración remota del Cluster para que puedas ver a groso modo como se gestionan nuestras VMs desde aquí:
Vemos la interfaz desde donde gestionamos nuestras VMs y a diferencia de la consola de Hyper-V, tenemos la opción de Live Migration y Quick Migration a nuestra derecha.
En el apartado del almacenamiento CSVs (Volúmenes Compartidos del Cluster) podemos ver las LUN donde almacenamos nuestras VMs y que vuelvo a remarcar, aparecen como una carpeta virual en C:\ClusterStorage
Finalmente, en el apartado de las Redes puedes configurar la función para la que serán utilizadas todas ellas. En el caso de arriba sólo está permitido la comunicación de redes del cluster al tratarse de una de mis redes iSCSI.
Sé que podría haber sido todavía mucho más extenso ya que hay mucho que hablar sobre este tema, pero creo que he conseguido de forma generalizada mostrarte lo más importante a la hora de trabajar con HyperV.
La semana que viene nos vemos con un nuevo capítulo sobre la virtualización y en concreto sobre la virtualización con Microsoft con HyperV. Espero tus comentarios y te deseo una feliz semana.
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.
StarWind Software es el líder global de administración de bases de almacenamiento y desarrollo de software de SAN para pequeñas y medianas empresas.
El ejemplo más representativo de productos de StarWind es el software de SAN que convierte cualquier servidor estándar de Windows en una SAN iSCSI segura y tolerante a fallos. El programa está diseñado para su uso como almacenamiento en una red con VMware, Hyper-V, Microsoft SQL Server, Microsoft Exchange, Microsoft SharePoint y otras aplicaciones de servidor que se configuran en los clústeres de servidor.
La compañía StarWind Software está orientada a las pequeñas y medianas empresas ofreciéndoles la tecnología barata de alta disponibilidad que hace poco solamente estaba disponible en los productos prestigiosos y caros de almacenamiento.
Las características avanzadas de sus productos incluyen creación de espejos síncronos con tolerancia a fallos y recuperación automática, replicación remota en una WAN, protección continua de datos y puntos de recuperación, thin provisioning y administración de cintas virtuales.
En el año 2003 StarWind lanza su primer programa de SAN iSCSI convirtiéndose en el producto favorito para más de 30.000 usuarios de todo el mundo en más de 100 países, desde pequeñas y medianas empresas, hasta gobiernos y compañías de Fortune 1000.
Aprenda más sobre las soluciones de productos StarWind registrándose en nuestros seminarios web gratuitos:
Después de que un usuario me lanzara una pregunta via post en los foros de virtualización en español, he intentado documentar los pasos que hay que dar para configurar el iniciador de software iSCSI para un entorno con VMware vSphere ESX/ESXi 4.x.
La idea es, después de seguir todos los pasos siguientes, tener al menos dos caminos por LUN activos para que de esta manara podamos aumentar, no solo la disponibilidad con VMware multipathing sino también, el ancho de banda de E/S de nuestros datastores en VMware vSphere ESX/ESXi.
A continuación, os resumo los pasos a seguir:
Paso 1: Configura un vSwitch y habilita el Jumbo Frames
Este paso (jumbo Frames) tienes que hacerlo desde comando pues en los vswitch estándares no tienes la opción de hacerlo desde la GUI (si está disponible en los vswitch distribuidos)
esxcfg-vswitch –a vSwitch1 (creas un vSwitch llamado vSwitch1)
esxcfg-vswitch –m 9000 vSwitch2 (activas jumbo frame en el vSwitch1)
Paso 2: Añade los VMkernel Ports iSCSI
Aquí, dependerá de las tarjetas de red que tengas cableadas y de las controladoras de disco que tengas en tu cabina.
Al menos, deberías de configurar dos VMkernel Ports con dos tarjetas de red para tener, tanto balanceo de carga con RR ( de las siglas en Inglés Round Robin) como mecanismo de failover.
esxcfg-vswitch –A iSCSI1 vSwitch1 ( creas un VMkernel port llamado iSCSI1 )
esxcfg-vmknic –a –i 10.10.1.1 –n 255.255.255.0 –m 9000 iSCSI1 ( asigna un ip, subnet mask y jumbo frames al VMkernel port iSCSI1 )
esxcfg-vswitch –A iSCSI2 vSwitch1 ( crea un VMkernel port llamado iSCSI2 )
esxcfg-vmknic –a –i 10.10.2.1 –n 255.255.255.0 –m 9000 iSCSI2 ( asigna un ip, subnet mask y jumbo frames al VMkernel port iSCSI2)
Paso 3: Asigna las tarjetas de Red físicas al vSwitch1
Primero, asegúrate que tienes al menos dos tarjetas de red físicas sin asignar a otro vswitch. Lo puedes ver con este comando esxcfg-nics –l.
esxcfg-vswitch –L vmnic3 vSwitch1 (Conecta la tarjeta vmnic3 al vswitch1)
esxcfg-vswitch –L vmnic4 vSwitch1 (Conecta la tarjeta vmnic4 al vswitch1)
Aquí viene lo bueno. Por defecto, cuando creas un team en un vswitch las dos tarjetas son activa/activa. Para que el multipathing de ESX/ESXi funcione con el iniciador de software iSCSI debes cambiar las propiedades del multipathing. Lo explicare en el siguiente paso.
Paso 4: Asocia los VMkernel Ports a las tarjetas de red físicas
Antes de seguir con este paso, teclea el siguiente comando:
esxcfg-vswitch –l
Deberías de ver algo así en tu vswitch1:
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch1 64 7 64 9000
vmnic3,vmnic4
PortGroup Name VLAN ID Used Ports Uplinks
iSCSI2 0 1 vmnic3,vmnic4
iSCSI1 0 1 vmnic3,vmnic4
Aquí, puedes ver que las dos tarjetas están asociadas en los dos VMkernel Ports. Esto es lo que tienes que cambiar con el siguiente comando.
esxcfg-vswitch –p iSCSI1 –N vmnic3 vSwitch1 (borra el vmnic3 del VMkernel port iSCSI1)
esxcfg-vswitch –p iSCSI2 –N vmnic4 vSwitch1 (borra el vmnic2 del VMkernel port iSCSI2)
Para verificar que has tecleado bien los comando, vuelve a teclear este comando para ver la salida:
esxcfg-vswitch –l
Deberías de ver algo así:
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch1 64 7 64 9000
vmnic4,vmnic3
PortGroup Name VLAN ID Used Ports Uplinks
iSCSI2 0 1 vmnic4
iSCSI1 0 1 vmnic3
Paso 5: Habilita el iniciador de software iSCSI
Con el comando esxcfg-swiscsi –e habilitas el iniciador de software iSCSI.
Paso 6 – muy importante: Crear el Binding de los VMkernel Ports con el iniciador de software iSCSI
Primero, confirma el seudo-name de tu iniciador de software iscsi. Lo puedes ver con este comando.
En mi caso como ves, el seudo-name de mi iniciador software iSCSI es vmhba33
Segundo, determina el nombre exacto de los VMkernel ports de tus iniciadores iSCSI. Lo puedes ver con este comando:
esxcfg-vmknic –l
Interface Port Group/DVPort IP Family IP Address
Netmask Broadcast MAC Address MTU TSO MSS
Enabled Type
vmk0 iSCSI1 IPv4 10.10.1.1
255.255.255.0 10.10.5.255 00:50:56:7b:d8:21 9000 65535 true
STATIC
vmk1 iSCSI2 IPv4 10.10.2.1
255.255.255.0 10.10.5.255 00:50:56:7e:ae:81 9000 65535 true
En mi caso, como ves en la salida anterior, es el vmk0 y el vmk1.
Una vez que conozcas cuál es el nombre del iniciador sw software iSCSI (vmhba32) y de los vmkernel ports (vmk0 y vmk1), ya puedes hacer el binding con el siguiente comando:
esxcli swiscsi nic add –n vmk0 –d vmhba33 (crea el binding para el vmk0 VMkernel port con el iniciador de software iSCSI vmhba33)
esxcli swiscsi nic add –n vmk1 –d vmhba33 (crea el binding para el vmk1 VMkernel port con el iniciador de software iSCSI vmhba33)
Para verificar que se han creado bien los binding con los VMkernel ports y el iniciador de software iSCSI, teclea el siguiente comando:
esxcli swiscsi nic list –d vmhba33
Deberías de ver que los dos VMkernel ports estan incluidos en el iniciador de software iSCSI.
Paso 7: Conecta la cabina – en este caso una Dell EqualLogic – a tu entorno VMware ESX/ESXi
Entra en la sección Configuration -> Storage Adapters.
Haz clic en iSCSI Software Adapter and selecciona Properties.
Haz clic en la pestaña Dynamic Discovery.
Clic Add.
En la sección iSCSI Server box, asegúrate de poner el IP del grupo de tu cabina PS y selecciona Ok.
Recibirás un mensaje que te pide hacer un Rescan de todas las HBAs. Dile que estás de acuerdo y en unos minutos deberías de ver tus LUNs si estas han sido configuradas correctamente en tu cabina y los servidores VMware vSphere ESX/ESXi tienen acceso a las LUNs.
¿Y tú qué opinas? ¿Conoces alguna mejor manera de configurar el iniciador de software iSCSI y VMware vSphere multipathing? ¿Cuáles son tus experiencias personales? Deja tu comentario abajo o charlemos sobre ello en twitter.
Hola, que tal? Soy Jose Maria Gris y como cada jueves estoy aquí con vosotros para hablar del ecosistema de VMware.
Curiosamente me he encontrado con dos situaciones iguales en dos entornos distintos, lo que me ha dado a pensar en que sería bueno postearlo. Veeam Backup es muy fácil de configurar en modo network a través de vCenter. Configuraciones en modo SAN o en modo en modo “Virtual Appliance” tienen su configuración especial, pros y contras.
Estamos en un entorno Veeam Backup 4.x donde la maquina veeam tiene iniciadores iSCSI de MS i “ve” las Luns, haciendo las copias en modo “SAN”. Una de las opciones que tenemos habilitada es usar el Traking de bloques cambiados para que las copias incrementales vayan más rápidas al monitorizar los cambios de bloques.
Todo el sistema funciona bien hasta que un día nos damos cuenta que la velocidad de la copia de seguridad baja de forma considerable y a la par baja el ratio de “copia”.
Investigas que ha pasado y no ves ningún cambio importante a la vista. Nuestro Veeam Backup está funcionando perfectamente, pero da unos mensajes “Verifing changed block tracking…”.
Analizando un poco más en profundidad, justo antes de empezar a ir lentos hicimos unos cambios, entre los que había cambios de ubicación de las VMs en otro datastore con StoragevMotion. Y ahí está el problema. Las referencias de los bloques han cambiado y el sistema no puede establecer “el diferencial” porque el entorno que tiene guardado y el que “ve” no cuadran. Hay que reconciliarlos.
Nos vamos a nuestro vCenter y a cada VM que hemos movido y hemos cambiado de Lun le cambiaremos el siguiente parámetro. En Edit Settings, pestaña options, General, veremos el botón Configuration Parameters.
Dentro de las opciones buscaremos el string ctkEnabled y cambiaremos su status a “False”.
Ello permitirá a Veeam volver a reconstruir el entorno de bloques y volver a nuestra velocidad que estábamos obteniendo hasta és momento.
Es importante tener el tema en cuenta porque lo que parece un cambio banal puede significar perder la ventana de backup ya que un job puede alcanzar a otro, dependiendo de cómo lo tengamos organizado. Otro día hablaremos de la configuración “Virtual Appliance” que es muy curiosa.
Saludos, take care.
Hola de nuevo, soy Miguel Angel Alonso y aquí estoy afortunadamente una vez más con vosotros para mostraros un nuevo artículo que espero que os guste y os pueda ayudar en vuestras inquietudes diarias de nuestro mundo de la virtualización.
Hoy le ha tocado el turno a cómo crear Multipathing desde la consola ESXCLI.
En el artículo de Chad Sakac y otros como(Netapp, EMC, Dell, HP, VMware) podremos tener acceso al nuevo método de Multipathing iSCSI para la nueva versión de ESX(vSphere).
Por fin en esta versión el iniciador ISCSI estará habilitado para múltiples conexiones ISCSI. (Multipathing mediante múltiples conexiones TCP)
Estoy encantado realmente con dicha función y lo fácil de configurarala que es. Necesitarás varias pautas a seguir para su correcto funcionamiento. Necesitaremos asignar 2 NICs a un VMkernel (o más) y sólo una NIC áctiva. Las demás NICs las moveremos hacia abajo (DOWN) en la sección “Unused Adapters”.
Después de haber creado tus VMkernels y unirlos (Bound) a una NIC específica, necesitarás añadirlos a tu Software iniciador ISCSI:
esxcli swiscsi nic add -n vmk0 -d vmhba35
esxcli swiscsi nic add -n vmk1 -d vmhba35
esxcli swiscsi nic list -d vmhba35
Si chequeas tu cliente vSphere te darás cuenta que habremos conseguido 2 PATHS en tu ISCSI Target, aquí os dejo un ejemplo:
Y en el ESXTOP, puedes ver los 2 VMKernel Ports con su tráfico:
Esta es una de las muchas cosas que se pueden conseguir mediante la consola de comandos ESXCLI.
Por supuesto en el Screenshot de arriba podemos ver que nuestra opción de Multipathing está en FIXED, pero como ya sabemos podremos elegir también entre MOST RECENT USED (MRU) o ROUND ROBIN (RR).
Bueno por fin un artículo un poquito más corto de lo que es habitual en mí pero creo que no por ello menos interesante. Aprovecho de nuevo para saludaros y daros siempre las gracias por estar ahí y como no, una y cuantas veces hagan falta a Jose María Gonzalez y todos mis compañeros del Blog que son increíbles.
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
