vSphere 5.1 – melhorias em storage

Como sempre, storage é a melhor parte. Não somente por ser uma das principais partes de qualquer OS, influenciando no desempenho e na performance, como também pela visibilidade e importancia de sua escalabilidade e bom dimensionamento.

As melhoras listadas parecem ser sutis, mas realmente melhoram a experiencia do usuário, mas também podem vir a gerar novos problemas (porque o reclamation não me liberou o espaço que eu esperava? porque uma LUN não foi de APD para PDL?)

Usando o documento http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Storage-Technical-Whitepaper.pdf como guia, é possível listar alguns pontos especiais:

  • File sharing: não é muito comum que os administradores tenham problemas com isso. Basicamente, nas versões anteriores, um arquivo VMDK só podia ser acessado por 8 ESX diferentes. Bom… voces podem imaginar que somente UM ESX sempre acessa um VMDK (já que a relação é de 1 VMX para vários VMDK, e o VMDK fica locked quando a VM liga) ou, no máximo, duas VMs compartilham um mesmo VMDK (em caso de clustering). Mas uma tecnologia já antiga, os “linked clones”, já fazem esta distribuição: basicamente, existe um VMDK ao qual se apontam vários snapshots, e cada snapshot é apontado a uma VM diferente (o VMDK de origem é acessado por todas em read-only). Todas estas VMs podem estar em N ESX, e o limíte de N era de 8. Isso limitava o número de hosts que poderiam fazer parte de um pool de View,  por exemplo, a 8 no máximo. Agora, com o vSphere 5.1, esse limite subiu a 32.
  • Space-Efficient Sparse disks: um novo tipo de disco virtual, que podem ter o espaço reclamado de volta no VMFS quando o OS não necessita, e também pode ter o tamanho de bloco setado por cada VMDK. Isso quer dizer que se um usuário apagar um arquivo de 1GB de uma VM, este espaço pode ser liberado no VMFS. Ainda não está claro se isso será uma opção no VMware Tools (já que não poder ser acionada todo o tempo pelo usuário final),mas a nível de ESX vão existir opções administrativas para isso. Exemplo de reclamation:
  • All paths down (APD): aqui está a dor de cabeça de muitos administradores de ambientes virtuais. Quem já passou por isso sabe que sair sem um downtime de uma situação assim é impossível. O APD ocorre quando o ESX perde acesso a todos os paths de uma ou mais LUNs, e isso faz com que todos os recursos computacionais sejam gastos para tentar reestabelecer o contato com a(s) LUN(s). Por uma estratégia de arquitetura, o processo responsável pelo monitoramento e rescan de storage também faz a comunicação de gerenciamento do ESX edo vCenter. Consequencia: ESX desconectado do vCenter e sem resposta, embora as VMs possam estar funcionando no mesmo. Do documento citado acima, copio um paragŕafo interessante da 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.” Em teoria, o hostd agora vai poder detectar melhor este estado, e transformar o mesmo de APD a PDL (permanent device loss). O vSphere HA também vai poder detectar este estado de APD/PDL para apagar uma VM de um ESX e ligar a mesma em outro host que não esteja enfrentando a mesma dificuldade.
  • Suporte a HBA’s de 16GBit FC
  • Monitoramento de discos SSD locais
  • SDRS melhorado, com uma forte relação com o SIOC. Isso significa que agora o ESX vai poder detectar latencias de disco de uma VM e, assim, pode migrar a mesma a outro datastore caso esta esteja muito alta, criando estatísticas de utilização e datastores com mais ou menos latencia.
  • Storage vMotion em paralelo, e não mais disco a disco.

Resumindo, muitas ferramentas novas. A do APD é a melhor.

Um abraço!

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