VMware Brasil: 2013

quinta-feira, 24 de outubro de 2013

Disponibilizado o vCenter Converter Standalone 5.5

Foi disponibilizado pela VMware a nova versão do VMware vCenter Converter Standalone 5.5.

Para quem ainda não está familiarizado com a ferramenta, trata-se de uma solução que permite conversão de máquinas físicas (Windows e Linux) ou máquinas virtuais (Microsoft Hyper-V) e imagens de diversas fontes diferentes (Parallels Desktop, Symantec Backup Exec System Recovery, Norton Ghost, Acronis, StorageCraft, Microsoft Virtual Server ou Virtual PC) em máquinas virtuais VMware.

A ferramenta é extremamente fácil de utilizar, pois possui uma interface bastante intuitiva.

As principais novidades do vCenter Converter Standalone 5.5 são:

- Suporte ao novo hardware virtual versão 10;

- Suporte a conversão de máquinas virtuais do RedHat KVM;

- Uma nova opção para escolher a interface de rede na máquina de destino;

- Suporte a novos sistemas operacionais convidados (confira abaixo uma lista com todos os sistemas operacionais suportados);

- Conversão paralela de discos (quem já usou o converter já deve ter reparado que nas versões anteriores os discos eram convertidos um de cada vez);

- Suporte a Virtual SAN.

Sistemas Operacionais suportados:

- Windows XP Professional SP3 (32-bit and 64-bit)

- Windows Server 2003 R2 SP2 (32-bit and 64-bit)

- Windows Vista SP2 (32-bit and 64-bit)

- Windows Server 2008 SP2 (32-bit and 64-bit)

- Windows Server 2008 R2 (64-bit)

- Windows 7 (32-bit and 64-bit)

- Windows 8 (32-bit and 64-bit)

- Windows Server 2012 (64-bit)

- Red Hat Enterprise Linux 3.x (32-bit and 64-bit)

- Red Hat Enterprise Linux 4.x (32-bit and 64-bit)

- Red Hat Enterprise Linux 5.x (32-bit and 64-bit)

- Red Hat Enterprise Linux 6.x (32-bit and 64-bit)

- SUSE Linux Enterprise Server 9.x (32-bit and 64-bit)

- SUSE Linux Enterprise Server 10.x (32-bit and 64-bit)

- SUSE Linux Enterprise Server 11.x (32-bit and 64-bit)

- Ubuntu 10.04 LTS (32-bit and 64-bit)

- Ubuntu 12.x (32-bit and 64-bit)

- Ubuntu 13.04 (32-bit and 64-bit)

Uma observação importante é que ao migrar uma máquinas Linux de forma online (com a máquina de origem ligada), o vCenter Converter Standalon 5.5 preserva os seguintes sistemas de arquivo na máquina de destino: ext2, ext3, ext4, reiserfs e vfat. Todos os sistemas de arquivos diferentes dos citados anteriormente são automaticamente convertidos para ext3 na máquina de destino.

Faça o download do vCenter Converter Standalone 5.5 aqui!

sexta-feira, 4 de outubro de 2013

VSphere Flash Read Cache, o que é isso??

Com o lançamento da nova versão VMware VSphere 5.5, foi introduzida uma nova tecnologia chamada VSphere Flash Read Cache (vFRC). Esta tecnologia já havia sido apresentada anteriormente, na VMworld 2012, mas ainda na versão beta, e sob a nomenclatura de vFlash.

Antes de falar propriamente do vFRC, é importante falar sobre uma nova camada adicionada à pilha de armazenamento do ESXi, chamada de VSphere Flash Infrastructure, que é a camada responsável pelo gerenciamento dos dispositivos que possuem a tecnologia Flash, sejam placas PCIe Flash ou discos SSD, instaladas localmente nos hosts ESXi. Esta nova camada, VSphere Flash Infrastructure, é usada para agregar estes dispositivos flash em um único recurso, conhecido como Virtual Flash Resource, assim como já era feito para CPU e Memória.

Depois de configurado o Virtual FLash Resource, é possível utilizá-lo de duas maneiras diferentes:

Virtual Flash Host Swap Cache: essa funcionalidade já existia na versão 5.0, mas era conhecida como Host Cache, e consiste na possibilidade de utilizar um disco SSD para fazer swap caso o host venha a sofrer com falta de memória. Com o VSphere 5.5 você define a quantidade de espaço do Virtual Flash Resource que será utilizado para o Virtual Flash Host Swap Cache. É possível utilizar até 4TB do Virtual Flash Resource, e uma vez que essa quantidade é definida, ela fica reservada e não volta para o Virtual Flash Resource para ser utilizada pelas máquinas virtuais.

Virtual Flash Read Cache: o vFRC é um software que já vem nativamente instalado no ESXi. Este software permite a criação de um cache para leitura, também conhecido como write-through, que melhora o desempenho das máquinas virtuais sem a necessidade de fazer modificações nas aplicações ou no sistema operacional da VM. A melhora no desempenho acontece porque o Virtual Flash Read Cache está localizado entre a máquina virtual e o dispositivo de armazenamento, independente se este é acessado via SAN ou via NAS.

Um detalhe interessante da implementação do vFRC é que ele é habilitado por disco virtual (VMDK), permitindo que o administrador escolha de forma mais controlada quais os discos, e de quais VM’s, que farão uso do cache. Na hora de configurar o cache para o disco virtual o administrador tem a opção de definir a quantidade de cache que estará disponível para aquele disco virtual e qual o tamanho do bloco que será utilizado nas operações de I/O.

Uma vez que o vFRC for configurado para um disco virtual, o cache só será criado quando a máquina virtual foi iniciada.

Como funciona o VFRC?

No caso de uma operação de leitura, quando uma requisição é feita pela VM para um disco virtual que possui o recurso de vFRC habilitado, os metadados do vFRC são lidos para verificar se os dados requisitados encontram-se inteiramente no cache. Se todo o dado estiver disponível no cache, os dados são lidos do dispositivo flash e a requisição de leitura é atendida. Essa operação é chamada de vFRC hit (cache hit). Caso aconteça de parte dos dados ou todo ele, não estar presente no cache, o que significa que o dado pode estar sendo acessado pela primeira vez ou que já esteve no cache mas foi removido, então toda a operação de leitura é realizada diretamente do VMDK e enviada para a VM. Simultaneamente os dados lidos do VMDK são escritos no cache para as consultas futuras. Esse tipo de situação é conhecida como vFRC miss (cache miss).

No caso de uma operação de escrita, os dados são escritos primeiramente no VMDK e posteriormente são copiados de forma assíncrona para o cache.

O vFRC é um cache volátil, portanto existem algumas situações que farão com que o cache seja totalmente descartado, entre elas: suspender/resumir uma VM, consolidação/reversão de um snapshot, e até mesmo uma operação de vMotion, caso a opção para migrar o cache não seja escolhida.

Alguns requisitos para a utilização do vFRC:

Virtual Center:

O vFRC é suportado somente no VMware VSphere vCenter Server 5.5 ou superior. Pode ser gerenciado tanto na versão Windows como no VCSA (VMware vCenter Server Appliance).

O Virtual Flash Read Cache só pode ser configurado e gerenciado pela VSphere Web Client versão 5.5.

Hosts:

O vFRC só é suportado nas versões do VSphere ESXi 5.5 ou superior.

Máquinas Virtuais:

Somente máquinas virtuais que já possuam o hardware virtual na versão 10 (VMX-10).

Configurações máximas do Virtual Flash Resource:

- Um Virtual Flash Resource (VFFS) por host VSphere;

- 8 dispositivos flash por Virtual Flash Resource (VFFS);

- Dispositivos flash de no máximo 4TB;

- vFRC de no máximo 400GB por disco virtual (VMDK);

- Máximo de 4TB de Virtual Flash Host Swap Cache por host VSphere ;

- Virtual Flash Resource de no máximo 32TB;

Quem quiser ler mais sobre essa tecnologia pode acessar os documentos abaixo disponibilizados pela VMware:

What’s New in VMware vSphere Flash Read Cache

Performance of vSphere Flash Read Cache in VMwarevSphere 5.5

Existe também uma página no blog Yellow Bricks que mantém um FAQ sobre o VSphere Flash Read Cache, clique aqui para acessar.

segunda-feira, 23 de setembro de 2013

VSphere 5.5 disponibilizado para download!

Aqueles que estavam ansiosos para testar as novas funcionalidades do VSphere 5.5, já podem relaxar. A VMware disponibilizou ontem para o download uma lista de novas versões e novos produtos que já podem ser baixados por qualquer pessoa. O blog Yellow Bricks,de Duncan Epping, traz essa lista completa com o link para o download de cada um dos produtos.

Junto com o download, também foi disponibilizada toda a documentação da plataforma VMware VSphere 5.5. Você pode conferir tudo nesse link.

segunda-feira, 9 de setembro de 2013

WhitePaper - iSCSI Design Considerations and Deployment Guide

Um novo white paper contendo as melhores práticas na utilização do protocolo iSCSI em ambientes VMware foi disponibilizado. O documento analisa todos os aspectos do uso do iSCSI em um ambiente vSphere. Ele discute as opções de configuração de rede, a interoperabilidade com outros componentes do vSphere e algumas configurações avançadas que podem ser feitas para melhorar a utilização do protocolo em determinados ambientes. Você pode fazer o download do documento no site da VMware, clicando na imagem abaixo:

quarta-feira, 4 de setembro de 2013

VSphere 5.5 - O que há de novo?!

Na última semana, entre os dias 26 e 29 de agosto, aconteceu em San Francisco a décima edição da VMworld, conferência anual realizada pela VMware. Como de costume, várias novidades foram apresentadas ao público, e dentre elas, a nova versão da plataforma de virtualização da VMware, VSphere 5.5.

De fato esta nova versão trouxe algumas novas funcionalidades e também mudanças interessantes, principalmente com relação às configurações máximas, como por exemplo, o novo limite de 62TB para discos virtuais (vmdk).

A seguir apresento as principais novidades dessa versão.

VSphere ESXi:

- Hot-Pluggable PCIe SSD Devices

Foi adicionada ao ESXi a capacidade de adicionar e remover dispositivos SSD (Solid State Disks) “a quente”, ou seja, assim como já acontecia com discos SATA e SAS, agora é possível adicionar um disco SSD ao servidor ESXi sem a necessidade de desliga-lo.

- Suporte a tecnologia RMT (Reliable Memory Technology)

A tecnologia RMT é uma funcionalidade que alguns fabricantes de hardware (no momento só encontrei informações sobre RMT através da DELL), que permite que setores físicos da memória que apresentem problemas sejam isolados e em seguida “escondidos” do sistema operacional, e também reporta quais as áreas da memória são mais confiáveis. Esta nova versão do ESXi é capaz de utilizar essas informações para otimizar o posicionamento do VMkernel e outros componentes críticos dentro da memória, prevenindo que erros de memória aconteçam.

- Melhorias no gerenciamento de energia

Até a versão 5.1, a política “Balanced” de gerenciamento de energia de um host ESXi utilizava apenas os estados de desempenho do processador (P-state), o qual mantêm o processador rodando em frequências e voltagens menores. Com o VSphere 5.5, os estados operacionais do processador (C-state) também são utilizados, permitindo maiores economias no consumo de energia.

Virtual Machine:

- Compatibilidade das VM’s com o VSphere 5.5

Junto com o vSphere 5.5, foi introduzido um novo hardware virtual (version 10) para as máquinas virtuais com vários recursos novos, como suporte a controladora LSI SAS para o sistema operacional Oracle Solaris 11, habilitação de novas arquiteturas de CPU, e uma nova controladora de disco (AHCI). Esta nova controladora, virtual-SATA, suporta tanto os discos virtuais como dispositivos de CD-ROM, podendo conectar até 30 dispositivos por controladora, num total de quatro controladoras por VM, permitindo que uma máquina virtual possa ter até 120 dispositivos, o limite anterior era de 60 dispositivos.

- Expansão do suporte a vGPU

O VSphere 5.1 foi a primeira versão do VSphere a fornecer suporte para aceleração de hardware 3D, através da vGPU, dentro de uma VM. Até então o suporte era limitado somente a placas gráficas com chipset NVIDIA. Com o lançamento do VSphere 5.5, este suporte foi expandido também para placas de vídeo baseadas em Intel e AMD. Para saber quais os modelos compatíveis, consulte o guia de compatibilidade da Vmware.

O suporte a vGPU pode ser habilitado pelo VSphere Web Client e pelo VMware Horizon View para os sistemas operacionais Windows 7 e Windows 8. As seguintes distribuições Linux são suportadas: Fedora 17 ou superior, Ubuntu 12 ou superior e Red Hat Enterprise Linux (RHEL) 7. A configuração de vGPU para máquinas virtuais Linux deve ser pelo VSphere Web Client.

Virtual Center Server:

- Melhorias no vCenter Server Appliance

O vCenter Server Appliance (vCSA), appliance virtual baseado em Linux com o Virtual Center embutido, ganhou uma melhoria significante nesta nova versão. Até então, o database que já vem incluso no appliance, um Postgres, era recomendado apenas para ambientes menores (5 hosts ou 50 VM’s). Essa era uma das razões que ainda levavam muitos a optar pela versão Windows do Virtual Center. Com o lançamento do VSphere 5.5, este banco de dados, ainda um Postgres, pode suportar até 500 hosts e 5.000 VM’s.

- VSphere App HA

Umas das novidades do Vsphere 5.5 é a introdução do VSphere App HA. Nas versões anteriores o VSphere HA, era capaz de monitorar o status de uma máquina virtual através do VMware Tools e reiniciá-la em caso de falha no recebimento dos pacotes de heartbeat. Assim como também era capaz de reiniciar as máquinas virtuais em outros hosts ESXi no caso de o host em que a VM estava viesse a falhar. Com o VSphere App HA, um novo nível de monitoramento foi adicionado. O VSphere App HA é capaz de monitorar se uma determinada aplicação parou de responder e então tentar reiniciar somente a aplicação, e caso não consiga, aí sim ele reinicia a VM. Neste momento, somente as aplicações a seguir são suportadas:

Microsoft SQL 2005, 2008, 2008R2, 2012;
Tomcat 6.0, 7.0;
TC Server Runtime 6.0, 7.0;
Microsoft IIS 6.0, 7.0, 8.0;
Apache HTTP Server 1.3, 2.0, 2.2;

- Compatibilidade do VMware HA com as regras de afinidade VM-VM

Em versões anteriores do vSphere 5.5, o vSphere HA não detectava as regras de anti-afinidade entre máquinas virtuais, fazendo com que elas fossem violadas durante um evento de failover do VSphere HA. Se o vSphere DRS estivesse habilitado, detectaria tais violações e faria uma migração de uma das máquinas virtuais para um outro host, através do vMotion, para satisfazer a regra de anti-afinidade entre as VM’s. Na maioria dos ambientes, essa operação é aceitável e não causa problemas. No entanto, alguns ambientes podem ter restrições de conformidade que necessitam que determinadas máquinas virtuais jamais fiquem num mesmo host.

Para atender essa necessidade de manter a colocação de máquinas virtuais em diferentes hosts, sem a necessidade de um vMotion, após uma falha do host, o vSphere 5.5 foi melhorado para se adaptar com as regras de anti-afinidade entre VM’s. Esse recurso é configurado como uma opção avançada no vSphere 5.5.

Veja mais em:
http://www.yellow-bricks.com/2013/09/04/vsphere-5-5-nuggets-high-availability-enhancement/

Storage:

- Aumento no tamanho do limite de um VMDK

O limite de 2TB para discos virtuais não existe mais. Com o lançamento do VSphere 5.5, agora é possível a criação de discos virtuais (vmdk) e discos RDM (tipo virtual mode) com até 62TB, tanto em datastores VMFS como em datastores NFS.

Algumas considerações importantes sobre essa novidade:

A expansão de discos virtuais maiores de 2TB só pode ser feita de forma off-line;

Não é possível expandir ou manipular um disco maior que 2TB utilizando o VSphere Client, é necessário utilizar o VSphere Web Client.

- Suporte fim a fim de HBA’s de 16GB

No vSphere 5.5, a VMware fornece o suporte fim a fim de conexões FC de 16Gb. Tanto as HBA’s como as controladoras do Storage podem ser executadas a velocidades de 16Gb, desde que o switch FC entre eles suporte.

- Introdução do Vsphere Flash Read Cache

Talvez umas das funcionalidades mais interessantes desta nova versão do VSphere 5.5, seja o VSphere Flash Read Cache, também conhecido como vFlash. Como o nome sugere, o vFlash é um sistema de cache que utiliza os discos SSD locais dos hosts ESXi. Esse cache é então utilizado pelas VM’s para leitura, evitando que as VM’s precisem utilizar a infraestrutura da rede SAN para ler determinados blocos, liberando assim, recursos para as operações de escrita.

Cada host pode ter até 8 discos SSD, sendo de 4TB cada, possibilitando um máximo de 32TB de cache por host. Esse cache também pode ser usado para fazer cache de memória do host ESXi, assim como já era possível no VSphere 5.1.

A implementação deste recurso é feito por máquina virtual, ou seja, é necessário definir quanto de espaço cada VM irá utilizar do cache. Outro detalhe é a necessidade de upgrade do hardware virtual da VM para a versão 10.

A seguir tem um vídeo demonstrando como habilitar esta funcionalidade:

Network:

O vSphere 5.5 introduziu algumas melhorias e capacidades de rede fundamentais para simplificar ainda mais as operações, melhorar o desempenho e garantir a segurança em redes virtuais. A seguir estão algumas das principais melhorias nos recursos desta versão:

As melhorias nas funcionalidades de agregação de link (LACP) permitem a escolha de vários algoritmos de hash e também aumenta o limite no número de grupos de agregação de link (LAG’s);

Aumento na segurança de portas é ativado através do suporte a filtragem de tráfego;

Priorização de tráfego na camada 3 aumenta o suporte a qualidade do serviço (QoS);

Uma nova ferramenta de captura de pacotes semelhante ao tcpdump;

Suporte a placas de rede de até 40 Gb;

Quem quiser saber mais sobre todas essas novidades pode conferir os seguintes documentos lançados recentemente pela VMware:

What’s New in VMware vSphere 5.5 Platform

Performance of vSphere Flash Read Cache inVMware vSphere 5.5

Host Power Management in VMware vSphere 5.5

segunda-feira, 2 de setembro de 2013

Divulgação de vaga - Training Tecnologia

A Training Tecnologia está em busca de profissionais certificados em VMware, abaixo mais alguns detalhes da vaga em questão:
______________________________________________________________________________

Profissional com Certificação: VMware Certified Professional 5 - VCP5
Detalhes da contratação serão acertados mediante entrevista prévia.
Disponibilidade de início imediato
Atuação em Brasília/DF
Interessados enviar e-mail para: hisis@trainingtecnologia.com.br
______________________________________________________________________________

segunda-feira, 26 de agosto de 2013

Novas certificações VMware – VCA (VMware Certified Associate)

A VMware acaba de adicionar mais uma certificação na sua trilha de certificações. Trata-se das certificações VCA (VMware Certified Associate). Como o próprio nome sugere, esta é uma certificação inicial, vem antes da certificação VCP na ordem das certificações VMware, e diferentemente da VCP, para se tornar um profissional VCA não há nenhum treinamento obrigatório para ser feito. Ainda assim a VMware disponibilizou um treinamento gratuito para cada uma das certificações VCA disponíveis.

VMware Certified Associate – Cloud (VCA-Cloud)

VMware Certified Associate – Data Center Virtualization (VCA-DCV)

VMware Certified Associate – Workforce Mobility (VCA-WM)

VMware Certified Associate – Network Virtualization (VCA-NV) – Ainda indisponível

Cada um dos exames custará $120 dólares.

Uma observação importante é que o fato de se tornar um profissional certificado VCA, não altera em nada os requisitos para se tornar um profissional VCP, ou seja, você ainda será obrigado a fazer um treinamento oficial e a passar no exame de certificação para ser considerado um VMware Certified Professional.

quinta-feira, 22 de agosto de 2013

Onde estão os profissionais VCP???

Essa é uma curiosidade que muitos profissionais, principalmente os que trabalham com virtualização, devem ter. Perguntas do tipo “Quantos VCP’s existem atualmente?” ou “Quantos VCP’s existem no Brasil?”, essas e outras perguntas foram respondidas com a publicação do infográfico abaixo.

Algumas curiosidades:

- 86% dos países já possuem algum profissional certificado VCP;

- No Brasil existem 1.015 profissionais VCP;

- O Japão é o terceiro país com o maior número de profissionais (jurava que no Japão eles utilizavam tecnologias completamente diferentes das nossas! hehehe)

O post original você pode ver em:
http://blogs.vmware.com/education/2013/08/where-in-the-world-are-vcps.html

quinta-feira, 11 de abril de 2013

Qual a diferença entre discos 'THICK', 'THIN' e RDM (Raw Device Mapping)?

Quando vamos criar uma máquina virtual, ou quando adicionamos um novo disco a uma VM já existente, somos obrigados a escolher qual o tipo de disco virtual que iremos disponibilizar para essa máquina.

Atualmente, existem três tipos de disco virtual que podem ser criados e disponibilizados para as máquinas virtuais:

Thick Provision Lazy Zeroed – é um disco “thick” padrão, ou seja, todo o espaço é alocado no momento da sua criação. Neste formato de disco virtual, qualquer dado que exista no dispositivo físico é mantido no momento da criação, e só são “zerados” no momento em que a máquina virtual vai escrevendo seus dados.

Thick Provision Eager Zeroed – é um disco “thick” que possui suporte a alguns recursos de cluster, como FT. Também aloca todo o espaço necessário no momento da sua criação. A diferença para o formato “lazy” (ou flat) é que os dados existentes no dispositivo físico são todos zerados no momento da criação. O tempo de criação deste tipo de disco pode demorar mais que os demais.

Thin Provision – neste tipo de disco apenas um espaço mínimo é utilizado no momento da sua criação. A medida que mais espaço físico for sendo necessário, o disco “thin” vai aumentando o seu tamanho, podendo chegar até o tamanho alocado inicialmente.

Raw Device Mapping

Também existe a possibilidade de disponibilizar para a máquina virtual um disco no formato RDM (Raw Device Mapping). Um disco RDM permite que uma VM acesse uma LUN do storage (Fibre Channel ou iSCSI) diretamente. O disco RDM na verdade é um arquivo .vmdk criado no datastore que faz o mapeamento para a LUN no storage. Possui apenas algumas informações de metadados e os apontamentos para o disco físico.

Os discos RDM podem ser configurados de duas formas diferentes: modo de compatibilidade virtual (virtual compatibility mode) e modo de compatibilidade física (physical compatibility mode).

No modo virtual, a LUN mapeada é apresentada para uma máquina virtual exatamente como um disco virtual criado num datastore VMFS. As verdadeiras características de hardware da LUN ficam invisíveis para a VM. No modo virtual é possível se beneficiar de algumas características do VMFS, como por exemplo, “file locking” e “snapshots”.

No modo físico, o VMkernel transfere a maioria dos comandos SCSI para a LUN mapeada, permitindo uma maior integração da VM com a LUN. O modo físico é útil na virtualização de máquinas que possuem agente de gerenciamento de redes SAN e também na criação de clusters entre máquinas físicas e máquinas virtuais, ou entre máquinas virtuais em diferentes hosts.

sexta-feira, 1 de fevereiro de 2013

vCloud Suite Poster

Esse pôster foi desenhado para ajudar os administradores vSphere a compreenderem quais os produtos que fazem parte da suíte vCloud, mostra o que está disponível como parte da vCloud Suite e também como cada um dos produtos (tanto os produtos para o gerenciamento da nuvem como os produtos que compõem a infraestrutura da nuvem) se encaixam.

O pôster (abaixo) pode ser baixado como um arquivo PDF aqui.

segunda-feira, 28 de janeiro de 2013

O que é VAAI?? VMware Vsphere Storage APIs for Array Integration

Apesar de ter sido anunciada há algum tempo (desde o lançamento da versão 4.1), esta funcionalidade ainda não é muito bem compreendida e aproveitada por aqueles que utilizam o VMware VSphere como a sua plataforma de virtualização. O objetivo deste post é apresentar um pouco mais desta tecnologia, apresentando os principais conceitos por trás de cada uma das funcionalidades oferecidas.

Primeiramente, o que é VAAI?

Como o próprio nome sugere VMware Vsphere Storage APIs – Array Integration, é um conjunto de APIs (Application Programming Interface) que permitem uma comunicação entre os hosts ESXi e os dispositivos de armazenamento (Storage Array). Estas APIs definem um conjunto de funcionalidades que permitem que o host ESXi transfira para o storage a carga de execução de determinadas operações de disco, reduzindo com isso a utilização dos recursos no host ESXi e ao mesmo tempo obtendo um melhor desempenho na execução destas operações. Por isso essa tecnologia também é conhecida como “hardware acceleration” ou “hardware offload” APIs, pois transfere para o hardware a execução de algumas tarefas.

Vamos imaginar a execução de uma operação de clonagem de uma máquina virtual ou então a realização de um Storage vMotion de determinado .vmdk, se o local de origem e o local de destino, do clone e do .vmdk que está sendo movido, é o mesmo, ou seja, são datastores/LUNs que estão num mesmo storage, porque deixar que essa atividade seja controlada pelo software, no caso o ESXi, ao invés de transferir para o hardware (storage) essa responsabilidade, uma vez que o mesmo está muito mais preparado para executar tais tarefas do que o ESXi?

Como um administrador VMware, você não quer que seu host ESXi fique ocupado copiando blocos de um lado para o outro ou executando operações de clonagem. Você não quer que sua rede SAN ou Ethernet seja entupida com tráfego de Storage vMotion. Você quer ver o seu host processando as requisições das suas VM’s e gerenciando a sua memória!

Como citei anteriormente, a primeira versão da VAAI foi lançada juntamente com o VSphere 4.1, porém neste momento oferecia suporte apenas para armazenamento via bloco (FC, iSCSI e FCoE). Com o lançamento do VSphere 5.0, houve uma atualização também da VAAI, dessa vez oferecendo suporte para armazenamento via NAS e também novas funcionalidades relacionadas com a tecnologia de Thin Provisioning.

VAAI – Armazenamento em bloco (FC, iSCSI e FCoE)

São três as “funcionalidades” oferecidas para armazenamento em bloco:

- Atomic Test & Set (ATS)

Como sabemos, o VMFS é um sistema de arquivos em cluster, ou seja, permite que vários hosts o acessem ao mesmo tempo. Mas para que isso ocorra, são necessários alguns mecanismos que controlem determinadas operações, e um destes mecanismos é o “locking” (bloqueio). Quando um host ESXi faz alguma atualização nos metadados de um volume VMFS, este mecanismo de “locking” é necessário para garantir a integridade do sistema de arquivos e prevenir que um outro host ESXi tente atualizar esses mesmos metadados simultaneamente. São várias as operações que exigem este “locking”.

Até o Vsphere 4.0, esse mecanismo de bloqueio era realizado através de “SCSI Reservations”. Este “SCSI reservation” bloqueava toda a LUN no qual o VMFS se encontrava, evitando que outros hosts fizessem atualizações de metadados enquanto um determinado host possuía o “lock”. Esse era um fator que limitava a utilização de volumes VMFS muito grandes, devido a problemas de contenção que poderiam ocorrer no caso de muitas VM’s compartilharem o mesmo datastore.

Com o VAAI, um novo mecanismo de bloqueio foi introduzido, trata-se do ATS (Atomic Test & Set). O ATS permite que apenas um setor do disco seja modificado em um volume VMFS, evitando os problemas de contenção que ocorriam com a utilização do “SCSI Reservation” e permitindo a criação de volumes VMFS muito maiores.

Esta imagem foi copiada do documento: http://content.dell.com/br/pt/empresa/d/business~smb~sb360~pt/Documents~DFDF_2012_VMWare_Storage.pdf.aspx

- XCOPY (Extended Copy)

Quando não se tem o VAAI, uma operação de clone ou migração de dados entre datastores é realizada através de um driver chamado “Data Mover” presente no VMkernel. Além de demorar demais, essas operações ainda consomem ciclos de CPU, memória e comando nas filas da HBA do host.

Com a funcionalidade do XCOPY (Extended Copy), o ESXi dispara um comando para o Storage, para que ele execute a cópia dos blocos no lugar do “Data Mover”, resultando em operações muito mais rápidas e que desoneram o consumo de recursos nos hosts.

Esta imagem foi copiada do documento: http://content.dell.com/br/pt/empresa/d/business~smb~sb360~pt/Documents~DFDF_2012_VMWare_Storage.pdf.aspx

- Write Same (Zero)

Quando criamos um disco do tipo THICK, temos duas opções: Lazy Zeroed ou Eager Zeroed. O “lazy” zera os blocos à medida que forem sendo utilizados, e o “eager” zera todos os blocos no momento da sua criação. De qualquer forma, essa operação de zerar os blocos é realizada através de comandos SCSI que são enviados pelo host, consumindo recursos do host.

Com o VAAI, os hosts ESXi podem ser habilitados para enviar um comando SCSI chamado de WRITE_SAME. Este comando zera uma grande quantidade de blocos de um disco, sem a necessidade de transferência de dados pelo link de transporte. Algumas das operações que são beneficiadas por este comando são:

- Operações de clone que possuem como alvo um disco Eager Zeroed;

- Alocação de novos blocos para discos THIN;

- Inicialização de blocos ainda não escritos para discos Lazy Zeroed.

Esta imagem foi copiada do documento: http://content.dell.com/br/pt/empresa/d/business~smb~sb360~pt/Documents~DFDF_2012_VMWare_Storage.pdf.aspx

VAAI – Armazenamento em NAS (NFS)

Como já citado anteriormente, as funcionalidades VAAI para NAS foram incluídas a partir da versão VSphere 5.0. A diferença para o VAAI oferecido para armazenamento em bloco é que para tirar proveito dessas funcionalidades, será necessária a utilização de plug-in específico, o qual deverá ser fornecido pelo fabricante do storage.

- Full File Clone

Esta funcionalidade é semelhante à funcionalidade XCOPY (Extended Copy) disponibilizada para o armazenamento em bloco. Ou seja, permite que discos virtuais sejam clonados por dispositivos NAS ao invés de utilizar o driver “Data Mover”, que consome CPU, memória e no caso de cópias via NAS, ainda consome banda de rede.

A única diferença entre o “Full File Clone” e o “XCOPY” é que o Full File Clone não é utilizado em operações de Storage vMotion, que continuam utilizando o “Data Mover”. Somente máquinas virtuais que são migradas enquanto estiverem desligadas é que serão beneficiadas pela funcionalidade do “Full File Clone”.

- Fast File Clone/Native Snapshot Support

Essa funcionalidade permite que a criação de um sanpshot para uma máquina virtual seja realizada pelo dispositivo de armazenamento NAS (Storage). Foi lançado previamente com o VMware View 5.1, através do Vmware View Composer, permitindo que a criação de novos desktops virtuais usando Linked Clone fosse realizada pelo storage e não mais pelo hosts ESXi. Para o VSphere 5.1 essa funcionalidade foi extendida para vApps do vCloud Director.

- Extended Statistics

Com essa funcionalidade, os administradores VMware agora podem ter acesso às estatísticas de uso de datastores NFS, o que é extremamente útil para os casos em que são utilizados datastores “thin-provisioned”, pois permite que o VSphere exiba as estatísticas de utilização de espaço reais. Anteriormente, os administradores VMware precisavam de ferramentas de fornecedores de storage para saber quanto de espaço um disco VMDK “thin” estava realmente consumindo de um datastore, agora essas informações podem ser vistas diretamente no VSphere Client.

- Reserve Space

Em versões anteriores do VSphere, somente discos virtuais “thin” podiam ser criados em datastores NFS. Com essa nova funcionalidade “Reserve Space” oferecida pela VAAI, é possível que discos “thick” sejam criados também em datastores NFS.

VAAI - Thin Provisioning

Quem já fez uso de LUN’s “thin” com certeza já se deparou com uma situação em que mesmo após deletar uma máquina virtual de determinado datastore, o espaço que deveria ter sido liberado com a exclusão dessa VM não apareceu! Ou então, casos em que uma situação de datastore cheio veio a suspender todas as máquinas virtuais nele presente.

Algumas dessas “reclamações”, constantes por parte daqueles que fazem uso da tecnologia “thin provisioning”, fizeram com que a VMware pensasse em algumas funcionalidades que pudessem amenizar essa situação e oferecer ao administrador VMware, mais tranquilidade para trabalhar com essa tecnologia.

- Thin Provisioning Stun

Visa resolver o problema que envolvia a suspensão de todas as VM’s presentes em um datastore “thin” caso esse viesse a ficar com 100% de espaço utilizado. Agora, caso um datastore “thin” fique com 100% de espaço utilizado, apenas as máquinas virtuais que necessitarem de mais espaço em disco serão pausadas, as VM’s que não precisarem de espaço continuarão rodando normalmente. Depois que for alocado mais espaço para o datastore, as máquinas virtuais que foram pausadas poderão ser resumidas.

- Thin Provisioning Space Threshold Warning

Com esta nova funcionalidade, um alerta é exibido no Virtual Center quando um datastore “thin” atinge determinado threshold. Esse threshold é configurado no storage.

- Dead Space Reclamation

Essa é a funcionalidade que permite a recuperação de um espaço anteriormente utilizado num datastore “thin” por uma máquina virtual que tenha sido excluída ou migrada para outro datastore. Através de um comando chamado SCSI UNMAP, o host ESXi avisa ao storage que determinado espaço, anteriormente utilizado, pode ser recuperado pelo storage. Com isso, os storages poderão relatar com maior precisão a utilização de espaço em um datastore “thin provisioned”.

Esta imagem foi copiada do documento: http://content.dell.com/br/pt/empresa/d/business~smb~sb360~pt/Documents~DFDF_2012_VMWare_Storage.pdf.aspx

Na primeira implementação desta funcionalidade no VSphere 5.0, essas operações de recuperação de espaço eram realizadas automaticamente, ou seja, assim que a VM era excluída ou migrada, o host ESXi automaticamente enviava o comando SCSI UNMAP para o storage recuperar aquele espaço. Devido a alguns problemas de desempenho e de tempo de recuperação destes espaços em determinados storages, esse esquema foi alterado, e essa operação agora deve ser disparada manualmente.

Quem quiser saber mais detalhadamente como esse processo de recuperação de espaço pode ser realizado, o artigo abaixo explica bem detalhadamente como funciona todo o processo. Vale a pena fazer a leitura.

http://blogs.vmware.com/vsphere/2012/04/vaai-thin-provisioning-block-reclaimunmap-in-action.html

Mais detalhes, como por exemplo, implementação, tuning, verificação de status e etc., sobre a tecnologia VAAI podem ser encontrados no whitepaper “VMware vSphere Storage APIs – Array Integration (VAAI)”, através do link abaixo:

http://www.vmware.com/resources/techresources/10337