vSphere 5.1 – mejorias de storage

Como siempre, storage es la mejor parte. No solo por ser el core de cualquier OS, influenciando el desempeño y performance, como por la visibilidad y la importancia de su escalabilidad y buen dimensionamiento.

Las mejorias de acceso a storage pueden parecer sutiles, pero hasta donde pude ver solo mejoran más la experiencia del usuário, aunque pueden venir a generar nuevos problemas (porque mi disco no reclamó todo el espacio libre en el C:? porque una LUN en APD no fue a PDL?)

Teniendo como guia el documento http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Storage-Technical-Whitepaper.pdf, se pueden listar algunos puntos:

  • File sharing: no es muy comun que los administradores tengan problemas con eso. Basicamente, en las versiones anteriores, un archivo VMDK solo podia ser accedido desde hasta 8 ESX distintos. Bueno, pueden decirme que solo UN ESX siempre accede un VMDK (ya que la relación es de 1 VMX a vários VMDK, pero el VMDK se queda locked así que la VM se prende) o, como mucho, dos VMs comparten un VMDK (en el caso de clustering). Pero una tecnologia ya antigua, los “linked clones”, ya hacen esta distribuición: basicamente, es un VMDK a donde se apuntan vários snapshots, y cada snapshot se presenta a una VM distinta (el VMDK de origen es accedido por todas, read-only). Así que estas VMs pueden estar distribuídas en N ESX, y el límite hasta ahora era 8. Esto limitaba el número de ESX en un cluster de un pool de View a esta máximo de 8. Ahora, en 5.1, este límite es de 32.
  • Space-Efficient Sparse disks: un nuevo tipo de discos virtuales, los cuales pueden tener espacio reclamado de vuelta en el VMFS cuando el OS no lo necesita, y también ahora pueden tener el tamaño de bloque seteado por VMDK, permitiendo una mejor configuración entre cada sistema de archivos de VM y su VMDK correspondiente. Todavia no está claro si eso va estar disponible como una opción del VMware Tools (ya que no debe ser accionada por cualquier usuário), pero es cierto que a nivel de ESX van haberopciones administrativas para hacerlo. Ejemplo de como va ocurrir el proceso:
  • All paths down (APD): acá viene el dolor de cabeza de los administradores de entornos virtuales. Quien yá pasó por eso, sabe que salir sin un downtime importante de una situación comoasí es imposible. El APD ocurre cuando el ESX pierde acceso a todos los paths de una o más LUNs, y esto hace con que se gaste todo los recursos computacionales disponibles para intentar traer a la vida el acceso al disco nuevamente. Por una elección de architectura, el mismo proceso que es responsable por la capa de storage, también hace la comunicación con el management del ESX y el vCenter, por lo cual se pierden todas las funcionalidades de gerenciamiento. En el documento apuntado arriba, hago cópia de un párrafo de la página 6: “Over the previous several vSphere releases, VMware has made significant improvements in handling the APD condition. This is a difficult situation to manage because the ESXi host cannot detect whether it is a permanent device loss or a transient state. The biggest issue regarding APD is the effect on hostd, which is responsible for managing many ESXi host operations. It manages virtual machine operations such as creation, power on/off, VMware vSphere® vMotion®, and so on. It also manages LUN and VMFS volume discovery. If an administrator issues a rescan of the SAN, hostd worker threads will wait indefinitely for I/O to return from the device in APD. However, hostd has a finite number of worker threads, so if all these threads get tied up waiting for disk I/O, other hostd tasks will be affected. This is why a common symptom of APD is ESXi hosts disconnecting from VMware® vCenter™ because their hostd process has become hung.” En teoria, el hostd ahora va a poder detectar mejor este estado, y transformarlo de APD a PDL (permanent device loss). El vSphere HA también va a poder detectar un estado de APD/PDL para apagar una VM de un ESX y prenderla en otro que no tenga el mismo estado.
  • Soporte a HBA’s de 16GBit FC
  • Monitoreo de discos SSD locales
  • SDRS mejorado, con relación estricta con el SIOC. Esto significa que ahora el ESX va a poder monitorear la latencia de disco de una VM, y migrarla a otro datastore en el caso de que esté muy alta, creando estatísticas de utilización y datastores con mas o menos latencia.
  • Storage vMotion en paralelo, no más disco a disco.

En resumen, hay muchas nuevas herramientas. En mi visión, la mejoria del comportamiento del APD es la mejor.

Un abrazo!

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s