Esta semana, en el blog de virtualización y cloud computing en español, os explicare como activar Storage I/O Controler 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 Storage I/O Control en VMware vSphere 5? Espero que te guste.
Nos vemos el próximo lunes con un próximo episodio donde te enseñare, 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.
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 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.
¿ 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:
¿Hola que tal, como estáis? Soy Jose Maria Gris y como cada Jueves estoy aquí con vosotros para compartir información sobre trucos, experiencias, productos del ecosistema VMware.
Hoy hablaremos de NFS. Como ya sabéis, podemos usar recursos NFS siempre que sean exportados con permiso de acceso para root.
Dejando aparte trabajos nativos como hace Nettapp, estamos centrándonos sobre NFS que hemos exportado desde un NAS o appliance de bajo rendimiento. Estos recursos nos van de perlas para mantener plantillas, ISOs, etc. ya que el coste de la Tb es
menor, en general, que el TB de SAN.
Algunas veces, tras perder el enlace entre el ESX y el NFS, nos muestra el acceso como inaccesible, en gris tenue. Intentamos hacer un Browse del datastore y no vemos nada, sudor frío…. Intentamos acceder al mismo, no hay forma. Intentamos hacer delete, no podemos.
Más aún, intentamos “remontar” nuestro NFS, ip del servidor, recurso, nombre del datastore y cual es nuestra sorpresa cuando nos dice vCenter (Vicente para los amigos) que “ya esta en uso”. ¿Cómo?????
Pues ahí estamos, ni arriba ni abajo. Y ahora que hacer….
El sistema es un poco curioso, pero he recuperado volúmenes con este procedimiento.
Nos dirigiremos a los ESX con nuestro Service Console y editaremos el fichero hosts, insertando un nombre FQDN a la ip del servidor NFS. A continuación nos iremos a “Add storage”, seleccionaremos NFS y en lugar de la IP del servidor, pondremos el FQDN, el recurso compartido y daremos un nombre “falso”, distinto al datastore que teníamos. Si teníamos ISOS pondremos ISOS2 por ejemplo.
El sistema nos dará fallo, diciéndonos que ya existe el recurso. Aceptamos y en segundos vemos como aparece el recurso “desaparecido”.
En este video te enseñare a mapear una LUN NFS via vSphere Client y a cómo montar y desmontar un DataStore NFS.
Para desmontar un DataStore NFS, primer selecciona la pestaña Configuration y luego haz clic en el enlace Storage. Una vez selecciona la LUN NFS con el botón derecho del ratón, selecciona Unmount.
Recuerda que le DataStore NFS será desmontado y todos los ficheros residentes en dicha LUN serán inaccesibles. Además, todas las maquinas virtuales que residan en dicho DataStore no podrán ser encendidas. Por favor, asegúrate, antes de desmontar un DataStore NFS, que todas las maquinas virtuales residentes en el volumen NFS, están apagadas.
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
