Nuevo libro ya a la venta: Descubre y domina VMware vSphere™ 5
 

Tag Archive | "DataStore"

¿Cómo activar Storage I/O Control en VMware vSphere 5?


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.

Posted in almacenamiento, cloud computing, Estandars, Estrategia, ESX, ESXi, ESXi, Hardware, Integración, josemariagonzalez.es, Manual, Software, software, vCenter, VCP, VCP5, Virtualizacion, virtualización, VMware, vmware, vSphere, vSphere, youtubeComments (0)

“He configurado el Round Robin, pero los caminos no son utilizados de manera uniforme”


 

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.

Posted in almacenamiento, Dell, Estandars, Estrategia, ESX, ESXi, Hardware, Integración, Manual, Manuales, Publicaciones, reviews, Software, software, Virtualizacion, Virtualización, virtualización, VMware, VMware, vmware, vSphereComments (3)

Administrar ESX(i) durante el desastre (III)


Siguiendo con los comandos de la herramienta que nos ocupa, vim-cmd, esta semana me gustaría centrarme en aquellos comandos que nos permiten gestionar aquellos aspectos más relacionados directamente con el host ESX(i) al que estamos conectados.

Por hacer un poco de memoria, la semana pasada os animaba a ejecutar el comando vim-cmd vimsvc/license –show. Como podréis suponer, este comando muestra información acerca de la licencia que está asignada a nuestro ESX(i):

~ # vim-cmd vimsvc/license –show
[200] Sending request for installed licenses…[200] Complete, result is:
serial: H468P-0E050-58E39-018H0-1RQ05
vmodl key: esxBasic
name: vSphere 4 Hypervisor
total: 0
used: 1
unit: cpuPackage:6core
Properties:
[ProductName] = VMware ESX Server
[ProductVersion] = 4.0
[count_disabled] = This license is unlimited
[feature] = maxRAM:256g (“Up to 256 GB of memory”)
[feature] = vsmp:4 (“Up to 4-way virtual SMP”)
[FileVersion] = 4.1.0.8
[LicenseFilePath] = /usr/lib/vmware/licenses/site/license-esx-40-e1-4core-200803

[200] End of report.

Este comando en particular no presenta opciones mucho más espectaculares que esta, salvo la gestión de tareas mediante los subcomandos tasks_list, tasks_info, tasks_description y tasks_cancel y la gestión de roles del subcomando auth. Al igual que ocurría con las máquinas virtuales, para poder hacer cualquier operación con las tareas tendremos que localizar el identificador de tarea mediante el comando tasks_list.

Permitidme que no me pare mucho en el comando vimsvc, ya que el comando del que os quiero hablar a continuación lo encuentro mucho más interesante, hostsvc. Y es que el interés y la importancia de este comando destacan por sí mismas en el momento en el que listamos los subcomandos de los que dispone:

~ # vim-cmd help hostsvc
Commands available under hostsvc/:
advopt/ enable_local_tsm queryconnectioninfo
autostartmanager/ enable_remote_tsm querydisabledmethods
datastore/ firewall_disable_ruleset refresh_firewall
datastorebrowser/ firewall_enable_ruleset refresh_services
firmware/ hostconfig runtimeinfo
net/ hosthardware set_hostid
rsrc/ hostsummary standby_mode_enter
storage/ login standby_mode_exit
summary/ logout start_local_tsm
vmotion/ maintenance_mode_enter start_remote_tsm
connect maintenance_mode_exit stop_local_tsm
cpuinfo memoryinfo stop_remote_tsm
disable_local_tsm pci_add task_list
disable_remote_tsm pci_remove

Debido a motivos de espacio del post, y sobre todo por no aburriros con todos los detalles, no entraré en todas las opciones que presenta este comando, pero al menos sí que me gustaría hacer una descripción somera de las más importantes y, al igual que la semana pasada, repasar un par de ejemplos con vosotros.

  • Advopt, nos da acceso a las opciones avanzadas del host. Sería equivalente al menú de “Advanced Settings” que tenemos disponible en el vClient, en la pestaña “Configuration” del host.
  • Autostartmanager, se encarga de gestionar las opciones de inicio y parada automáticos de las máquinas virtuales. Equivalente al menú “Virtual Machine Startup/Shutdown”
  • Datastore, habla por sí solo. Veremos un ejemplo en detalle.
  • Datastorebrowser, en teoría nos debería permitir explorar los datastores configurados en el host, pero en la práctica no está implementado y por lo tanto no es operativo.
  • Firmware, es el encargado de gestionar las actualizaciones y el backup de nuestro ESXi
  • Net, realmente interesante, ya que nos permite configurar muchos de los aspectos del ESX(i) relacionados con la red. Veremos un ejemplo en detalle.
  • Rsrc, está destinado a gestionar los grupos de recursos.
  • Storage, también bastante interesante, es el subcomando encargado de gestionar los aspectos relacionados con el almacenamiento desde el punto de vista hardware.
  • Summary, nos presenta un resumen de los dispositivos de almacenamiento.
  • Vmotion, encargado de gestionar los aspectos de configuración relacionados con vmotion.

A continuación me gustaría profundizar un poco más alguno de los puntos que comentaba anteriormente con un par de ejemplos.
En el primer ejemplo veremos como añadir un datastore de tipo NFS a nuestro ESXi. Si revisamos la ayuda del comando vemos:

~ # vim-cmd help hostsvc/datastore/nas_create
Usage: nas_create name remoteHost remotePath readonly

Add a NAS datastore.
readonly is a boolean value, 1 for readonly and 0 for rw access.

Con lo que nuestro comando quedaría de la siguiente forma:

~ # vim-cmd hostsvc/datastore/nas_create NFS_Datastore NFS_Host /backups 0
~ #

Al igual que ocurre con los datastores de tipo NAS, podremos crear datastores locales mediante el comando localds_create o datastores “compartidos” mediante el comando vmfs_create. Particularmente importante e interesante es el hecho de que debemos consultar las opciones hardware disponibles a la hora de crear un datastore “compartido” mediante el comando vmfs_query_create_options.

Otras opciones relacionadas con el almacenamiento que no quería dejar escapar son las que se encuentran bajo el comando storage. Si bien, de nuevo, por no hacer muy extenso el post no vamos a entrar en detalle en ellas, creo que es importante mencionar al menos algunas de las más útiles e importantes:

  • storage/multipath_info, muestra información acerca de la política de multipath configurada por cada LUN.
  • storage/hba_rescan, que permite realizar un re-escaneo de la hba que se le pase como parámetro

Continuando con los ejemplos de algunos de los subcomandos de hostsvc, veremos ahora como crear un nuevo virtual switch y asignarle su correspondiente NIC física y portgroups.

En primer lugar crearemos un virtual switch sin asociaciones ninguna, es decir el “esqueleto” de lo que será un vSwitch completamente funcional:

~ # vim-cmd hostsvc/net/vswitch_add vSwitch_TEST
~ #

A continuación crearemos y asociaremos los portgroups que nos interesen. En este caso agregaremos un portgroup de tipo Virtual Machine:

~ # vim-cmd hostsvc/net/portgroup_add vSwitch_TEST VM_PortGroup
~ #

Es importante consultar la ayuda de este comando, ya que en el apartado OPTIONS encontraremos las diferentes variantes y políticas que podremos configurar para el portgroup, bien durante su creación o posteriormente con el comando portgroup_set.

En este punto añadiremos las NIC físicas para dar servicio a nuestro vSwith:

~ # vim-cmd hostsvc/net/vswitch_setbondbridge –vsbridge-bond-pnics=vmnic1 vSwitch_TEST
~ #

Con lo que tendremos nuestro virtual switch configurado y listo para el servicio.

Es importante recordar que muchas de las opciones y políticas que tenemos disponibles en el vClient a través de las propiedades de los port groups o los virtual switches, las tenemos también disponibles en las opciones de los comandos encargados de gestionar estos elementos, por lo que resulta fundamental consultar la ayuda de estos comandos para realizar los ajustes que más nos interesen.

¿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.

Posted in Estandars, Estrategia, ESX, ESXi, Hardware, Integración, reviews, scripts, Software, Virtualizacion, VMware, vSphereComments (0)

Comparativa de espacio entre plataformas, porque el tamaño sí que importa


Una de las preguntas que uno se plantea cuando que se encuentra ante un diseño de una plataforma de virtualización es la del diseño del almacenamiento en general y la del tamaño de las particiones o datastores donde se van a almacenar las máquinas virtuales en particular.

En particular esta última cuestión, el tamaño de los datastores, fue la que me planteó el otro día un cliente. Además me planteaba que plataforma, Microsoft Hyper-V o VMWare Hypervisor, tenía mayores límites, en lo que a almacenamiento se refiere.

En este sentido me gustaría presentaros esta semana una pequeña comparativa entre ambas plataformas en lo que a máximos de almacenamiento se refiere.

Antes de entrar en la comparativa en si misma creo importante hacer una pequeña diferenciación entre:

  • Almacenamiento físico, es decir aquel almacenamiento que es gestionado o “visto” directamente por el hypervisor.
  • Almacenamiento virtual, que para el caso que nos ocupa es el almacenamiento que es usado o “visto” directamente por la máquina virtual.

En el caso del almacenamiento físico antes de poder hacer uso del espacio disponible e independientemente de si se trata de almacenamiento DAS (Direct Attached Storage) o SAN (Storage Area Network) debemos particionar el almacenamiento para después formatearlo.

En este punto es donde llega la primera cuestión que debemos tener en cuenta, ¿de qué tamaño creo la partición? Estrictamente hablando y de forma absolutamente teórica el límite para particiones GUID estaría en 9.4 ZB (ZettaBytes ). El problema real es que una partición no deja de ser como un armario sin cajones, es decir, un espacio vacío donde no hay ni orden ni concierto. En este punto es donde entra en juego el sistema de ficheros. Volviendo al ejemplo anterior, un sistema de fichero sería el equivalente a los cajones, barras, perchas, etc que encontramos dentro del armario, es decir las estructuras que usamos para organizar la ropa, o los datos si hablamos de particiones.

Respecto a los números que nos interesan vemos que el tamaño máximo que puede tener una partición es de:

  • VMFSv3 (VMware) 2 TB por partición única
  • NTFSv6 (Microsoft) 2 TB por partición única

Pero es posible que un datastore (vmware) o un volumen (Microsoft) ocupe más de una partición, con lo que el tamaño máximo para un datastore o volumen crezca por encima de esos 2TB que acabamos de ver, en particular:

  • VMFSv3 hasta 64TB para un único datastore, haciendo uso 32 particiones o “extends” de 2 TB cada una.
  • NTFSv6 hasta 16 EB (ExaBytes) para un único volumen lógico.

Una vez que tenemos el armario organizado, es decir que hemos creado la partición y la hemos formateado con un sistema de ficheros, tenemos que meter la ropa dentro, las máquinas virtuales.

Las máquinas virtuales, como ya sabemos, hacen uso de discos virtuales que son, dicho de forma general, ficheros almacenados en un disco físico, los cuales tienen un formato bien definido que es interpretado por Virtual Machine Monitor (Hypervisor) como un disco duro.

Dicho esto, vemos que un disco virtual no deja de ser un fichero dentro de un disco físco, y como tal está sujeto a las limitaciones del sistema de ficheros. Para el caso que nos ocupa, el límite que nos debe preocupar es el de tamaño máximo de fichero, que para ambas plataformas es de 2 TB por fichero.

Por supuesto, en esta comparativa no entran el mapeo directo del almacenamiento a las máquinas virtuales, bien usando RDM o iSCSI.

Un último apunte que me gustaría hacer es que “simplemente por que podamos hacer algo no significa que debamos hacerlo”, por lo que os animaría a consultar las best practices antes de realizar configuraciones que se acerquen “peligrosamente” a los limites, ya que existen otras implicaciones además del tamaño del almacenamiento.

A continuación os pongo algunos enlaces de referencia para ampliar algo de información:

Posted in almacenamiento, Estandars, Estrategia, Hardware, Virtualizacion, VMware, vSphereComments (3)

VMware vSphere y el comando vmkmod_load


 

¿ 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:

Posted in ESX, ESXi, Manuales, Trucos, Virtualizacion, Virtualización, VMware, VMware, vSphereComments (0)

Desmontando un DataStore NFS en vSphere 4.0


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.

Posted in ESX, ESXi, Videos YouTube, VMware, vSphereComments (0)

Page 1 of 11

Sigue el blog Virtualización en Español

Blog Sponsors

Mi Empresa

JmG Virtual Consulting, expertos en Servicios y Soluciones de Virtualización y Cloud Computing

 

Síguenos en FaceBook

Descubre y domina VMware vSphere™ 5

Descubre y domina VMware vSphere™ 5. Por José María González

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



Nuevo VMware Site Recovery Manager 4 download gratis 

Nombre:
Email:


Anuncios