terça-feira, 18 de novembro de 2014
VMware + Openstack
A cada dia que passa tenho escutado mais e mais sobre Openstack, e sobre qual seria a sua relação com a VMware. É comum associar ambos como produtos concorrentes e assumir que se deve escolher entre um ou outro. Mas na verdade não é bem assim. Podemos sim escolher entre o Openstack e um produto VMware (neste caso vCloud Director ou vCAC), assim como também podemos optar em usar o Openstack em conjunto com o vSphere ESXi/vCenter. Para “clarear” o que estou dizendo, vou tentar explicar mais ou menos o que é esse tal de Openstack e como a VMware tem se mostrado interessada em também estar presente numa infraestrutura baseada no Openstack.
O que é o Openstack??
O Openstack é um projeto open source cujo objetivo é possibilitar que qualquer organização seja capaz de construir uma nuvem pública ou privada através de uma plataforma de gerenciamento de nuvem. Também pode ser considerado um sistema operacional para nuvem pois possibilita o gerenciamento em larga escala de todos os componentes de uma infraestrutura (computação, armazenamento, rede, etc...), assim como o SO tradicional gerencia os componentes de uma única máquina. O Openstack é voltado para a oferta de IAAS (Infraestrutura As A Service).
O Openstack surgiu em 2010 de uma parceria entre a NASA e a Rackspace, cada uma trouxe um módulo da solução. A NASA era a responsável pelo módulo de processamento, cujo o nome do projeto é Nova. A Rackspace trouxe consigo o módulo de armazenamento de objetos, conhecido como Swift. Em 2012, surgiu a Openstack Foundation, uma organização sem fins lucrativos que passou a ser a responsável por promover o desenvolvimento, distribuição e adoção do Openstack. A organização já conta com mais de 9.500 membros de 100 países diferentes, e possui em seu conselho administrativo, executivos de grandes empresas do cenário mundial (Cisco, HP, IBM, Red Hat, Intel, Dell e etc...).
Veja aqui toda a linha do tempo do Openstack.
O Openstack é uma plataforma modular, composta por vários projetos independentes (também conhecidos como serviços), que podem ser implementados em conjunto ou separadamente. Atualmente os seguintes serviços estão disponíveis no Openstack:
- Compute (Nova)
- Networking (Neutron)
- Object Storage (Swift)
- Block Storage (Cinder)
- Dashboard (Horizon)
- Identity Service (Keystone)
- Image Service (Glance)
- Telemetry Service (Ceilometer)
- Orchestration Service (Heat)
- Database Service (Trove)
Não vou entrar em detalhes sobre cada um desses projetos, mas aqueles que tiverem interesse em conhecer mais sobre, é só clicar aqui!
O diagrama abaixo mostra como cada um desses serviços se relacionam:
E a VMware, aonde entra nisso aí?
Como disse anteriormente, o Openstack é uma plataforma para gerenciamento da nuvem, mas não substitui a infraestrutura que deve existir para suportar essa nuvem. Ou seja, o módulo de processamento, por exemplo, não consiste de um hypervisor. Na verdade ele se conecta através de drivers a diversos hypervisors existentes atualmente (KVM, XenServer, Hyper-V, VMware e outros), além de servidores físicos (bare-metal). É comum achar que o Openstack é implementado apenas em cima de uma infraestrutura baseada no KVM (sem dúvida nenhuma a grande maioria das instalações de Openstack existentes foram feitas sob o KVM) mas é justamente essa mentalidade que a VMware vem tentando mudar.
Nada impede que uma organização, que já possua uma infraestrutura toda baseada em cima de VMware, inicie uma implantação do Openstack utilizando o ESXi/vCenter para fornecer os recursos de processamento para o módulo Compute (Nova). E posteriormente, se achar melhor, ir adicionando um outro hypervisor por baixo do Nova, uma vez que essa é uma configuração suportada no Openstack.
Atualmente a VMware já fornece para a comunidade Openstack drivers para os módulos Nova e Cinder. E vem trabalhando para ofecer outros drivers futuramente, como por exemplo, um driver para utilizar o VMware NSX em conjunto com o módulo de networking Neutron.
E os esforços da VMware não param por aí!! Na VMworld deste ano, foi anunciado e disponibilizado (ainda em versão beta) uma distribuição Openstack desenvolvida pela própria VMware, chamada de VMware Integrated Openstack. A VIO (como também é conhecida) é uma solução que visa facilitar o deploy e o gerenciamento do Openstack.
Fazer uma instalação do Openstack, integrando diversos componentes, não é uma tarefa fácil e pode consumir bastante tempo. Essa solução da VMware se propõe a fornecer uma instalação, pronta para ser colocada em produção, de maneira rápida e simples, em cima de uma infraestrutura VMware.
Além da solução VIO (voltada para ambientes de produção e ainda em versão beta), a VMware também oferece, para aqueles que desejam ter um primeiro contato com o Openstack, ou para testes e POCs, um appliance virtual chamado VOVA (vSphere Openstack Virtual Appliance). O VOVA nada mais é do que uma instalação do Ubuntu com os principais serviços do Openstack (Nova, Glance, Cinder, Keystone, e Horizon) já configurados e disponibilizado no formato OVF. Os interessados podem fazer o download aqui.
Segue abaixo alguns links para quem tiver interesse em saber mais sobre o assunto:
sexta-feira, 17 de outubro de 2014
Transparent Page Sharing será desabilitado por padrão
A VMware anunciou algumas mudanças em uma das técnicas que gerencia a sobrecarga de memória (Memory Overcommited), conhecida como TPS – Transparent Page Sharing.
Para aqueles que quiserem saber mais sobre o gerenciamento de memória no VMware vSphere, inclusive sobre o TPS, recomendo a leitura de dois posts (parte1, parte2) que fiz há algum tempo atrás que explicam mais detalhadamente todo o processo.
Mas basicamente, o TPS é uma técnica exclusiva da VMware (nenhum outro hypervisor oferece uma funcionalidade semelhante), a qual permite que um host ESX/ESXi, quando sobrecarregado, armazene apenas uma cópia de uma determinada página de memória (4kb) caso existam outras páginas idênticas a ela. Essa única página armazenada pode ser compartilhada com outras VM`s.
Acontece que uma recente pesquisa acadêmica mostrou que o TPS pode permitir o acesso não autorizado a determinados dados em um ambiente sob condições altamente controladas, ou seja, condições dificilmente reproduzidas em ambientes do “mundo real”. Ainda assim a VMware achou por bem tornar essa funcionalidade desabilitada por padrão, afim de manter a política de fazer das configurações padrões as mais seguras possíveis.
Essa alteração passará a valer a partir dos seguintes releases:
- ESXi 5.5 Update release - Q1 2015
- ESXi 5.1 Update release - Q4 2014
- ESXi 5.0 Update release - Q1 2015
- The next major version of ESXi
Antes dos lançamentos mencionados acima, a VMware vai disponibilizar alguns patches que não alteram as configurações existentes, mas adicionam algumas novas capacidades de gerenciamento do TPS:
- ESXi 5.5 Patch 3. For more information, see VMware ESXi 5.5, Patch ESXi550-201410401-BG: Updates esx-base (2087359).
- ESXi 5.1 patch planned for Q4, 2014
- ESXi 5.0 patch planned for Q4, 2014
Para maiores informações veja:
quarta-feira, 3 de setembro de 2014
O que rolou na VMworld 2014??
Na semana passada em São Francisco
(EUA) aconteceu a conferência anual da VMware, a VMworld 2014. Pelos dados revelados
sobre o evento, mais de 22.000 pessoas presentes, de 85 países diferentes,
podemos perceber que a VMware está cada vez mais forte na indústria de TI.
O tema deste ano foi “No
limits”, passando a idéia de que as mudanças são inevitáveis e de que é preciso
coragem para mudar. Umas das frases citadas por Robin Matlock, Chief Marketing
Officer da VMware, foi “change can be either a barrier or an opportunity” (mudanças
podem ser uma barreira ou uma oportunidade), reforçando a ideia de que devemos empurrar as
barreiras e explorar as infinitas possibilidades a fim de expandir nosso conhecimento
e experiência.
Neste ano a VMware reapresentou
a sua estratégia para oferecer aos clientes a possibilidade de construir um
Centro de Dados definido por Software (o famoso SDDC – Software Defined
DataCenter), o que pôde ser percebido através dos principais anúncios feitos no
primeiro dia, durante a sessão geral de abertura. Se você tiver interesse pode
assistir ao vídeo completo no YouTube:
Preparei um post para cada um
dos anúncios que achei mais relevante:
VMworld 2014 - VMware vCloud Air
A até então vCloud Hybrid
Service passou a se chamar VMware vCloud Air.
A VMware vCloud Air é a
plataforma de IAAS da VMware, baseada totalmente no VMware vSphere, e oferece
aos seus clientes a possibilidade de migrar suas cargas de trabalho (VM`s,
aplicações) de uma infraestrutura interna (nuvem privada) para uma infraestrutura
externa (vCloud Air), ou vice-versa, de forma muito mais tranquila, pois
permite usar as mesmas ferramentas que já são utilizadas normalmente.
A vCloud Air está sendo oferecida
em três classes de serviços diferentes:
Dedicated Cloud: classe de serviço que fornece uma nuvem
privada exclusiva com servidores dedicados, tráfego de rede camada 2 isolado,
volumes de armazenamento dedicados, e uma instância para gerenciamento de nuvem
dedicada. A capacidade da infraestrutura pode ser alocada para um único
datacenter virtual ou para múltiplos datacenters, de acordo com a vontade do
cliente.
Virtual Private Cloud: classe de serviço que fornece uma
nuvem privada virtual com recursos isolados logicamente em uma infraestrutura
física compartilhada, configurada como um único datacenter virtual com recursos
de rede.
Disaster Recovery: classe de serviço que fornece uma nuvem
virtual privada, configurada como um datacenter virtual para recuperação de
desastres utilizado para replicação, failover e recuperação de VM’s
remotamente. Assim como na classe de serviço Virtual Private Cloud, nessa
classe os recursos são isolados logicamente em uma infraestrutura física
compartilhada.
VMworld 2014 - EVO:RAIL: appliance para infraestrutura hiperconvergente
Talvez o principal anúncio
feito na VMworld 2014 tenha sido o lançamento da nova plataforma de infrastrutura
hiperconvergente, chamada de EVO.
Para entender melhor o que é
exatamente uma infraestrutura hiperconvergente, vou descrever abaixo como a
forma de construir um data center mudou de alguns anos para cá:
Infraestrutura Customizada (best-of-breed) – Esta é a forma mais
tradicional de se construir um data center. Geralmente as companhias escolhem
os fabricantes que mais lhe agradam em cada uma das áreas (servidores, rede,
armazenamento, segurança e etc...) e faz a interligação entre os seus
componentes. A vantagem deste tipo de arquitetura é que as empresas não ficam
amarradas a um fabricante específico. Mas por outro lado exige uma equipe mais
experiente e com skill em cada uma das soluções.
Infraestrutura Convergente – Esse tipo de solução passou a ser
oferecida por alguns fabricantes com a intenção de minimizar o esforço
necessário para construir uma infraestrutura para um data center. Dessa forma
as empresas passaram a vender uma única solução (que é o caso do Vblock - EMC)
ou um tipo de referência de arquitetura (como o Flexpod - NetApp) que já
integra diversas tecnologias, como servidores, rede, armazenamento e virtualização.
Infraestrutura Hiperconvergente – A última tendência na área de infraestrutura
de TI é a adoção da infraestrutura hiperconvergente. Neste tipo de arquitetura os
fabricantes estão oferecendo todas as soluções necessárias na construção de uma
infraestrutura de TI (servidores, rede, armazenamento, virtualização) em uma
única caixa – geralmente algo em torno de 2U. A diferença é que além das
soluções já citadas, este tipo de infraestrutura também já inclui nessas caixas
soluções de backup, deduplicação, compressão, capacidades de snapshot e etc.
Alguns dos fabricantes com mais destaque nessa área são Nutanix e SimpliVityOmniCube.
É nessa terceira categoria que
a nova família EVO se encaixa. Neste primeiro momento foi anunciado apenas o
primeiro membro da familia, chamado de EVO:RAIL. Posteriormente será lançado um
segundo produto, que será chamado de EVO:RACK.
O que é o EVO:RAIL?
É um appliance de
infraestrutura hiperconvergente (HCIA – Hyper-Converged Infrastructure
Appliance) que combina um software e um hardware com recursos de processamento,
armazenamento e rede e que será oferecido pelos parceiros de hardware da
VMware, que são: EMC, Dell, Fujitsu, Inspu, Net One Systems e SuperMicro.
Componentes de Hardware
Alguns boatos sugeriram que a
VMware também entraria no mercado de hardware, mas isso não se confirmou.
Portanto a aquisição do EVO:RAIL será feita através destes parceiros citados
anteriormente, que farão a venda do appliance juntamente com o software
EVO:RAIL já integrado e também fornecerá todo o suporte de hardware e software
para os clientes.
Cada HCIA (appliance de
infraestrutura hiperconvergente) irá possuir 4 nós de processamento [como se
fossem 4 servidores de rede] com recursos de CPU & RAM, armazenamento e
rede dedicados, além de duas fontes de energia redundantes.
Cada um dos nós que compõem o
appliance terá a seguinte configuração:
- Dois processadores Intel E5-2620 v2 six-core
CPUs;
- 192GB
de RAM;
- Um dispositivo para boot do ESXI (32 GB SLC
SATADOM ou 146GB SAS 10K-RPM HDD);
- 3 discos SAS 10K RPM 1.2TB HDD para ser utilizado
pelo datastore da Virtual SAN;
- Um disco SSD de 400GB MLC enterprise-grade para
leitura/escrita de cache;
- Uma controladora de disco certificada para a
Virtual SAN;
- Duas portas 10GbE (podendo ser tanto 10GBase-T como
SFP+);
- Uma porta 1GbE IPMI para gerenciamento remoto (out-of-band);
Com a versão 1.0 do appliance
será possível combinar até 4 appliances, totalizando 16 hosts ESXi e 1 Virtual
SAN datastore, gerenciados por um único vCenter Server e uma instância do
EVO:RAIL. É o EVO:RAIL que trata da instalação, configuração e gerenciamento, o
que permite que a adição de capacidade computacional e expansão de um datastore
Virtual SAN sejam feitos automaticamente. Novos appliances são descobertos
automaticamente e a adicão destes ao cluster EVO:RAIL é feita facilmente
através de poucos cliques no mouse.
Componentes de Software
O software em si (EVO:RAIL) é
totalmente baseado nas tecnologias já conhecidas da VMware (VMware vSphere,
vCenter Server e Virtual SAN). A grande diferença está na sua Engine, que é
basicamente a interface de front-end construída sobre HTML5.
O EVO:RAIL é composto por:
- O software EVO:RAIL para
Instalação, Configuração e Gerenciamento;
- VMware vSphere Enterprise Plus;
- Virtual SAN;
- vCenter Server;
- vCenter Log Insight;
O EVO:RAIL é otimizado para
novos usuários VMware e também para administradores mais experientes. O fato de
exigir uma experiência mínima para realizar a instalação, a configuração e o
gerenciamento, permite que o EVO:RAIL seja utilizado em locais que possuem
equipes de TI limitadas ou até mesmo nenhuma equipe de TI no local.
Segue abaixo um vídeo com uma breve
demostração do EVO:RAIL:
Aqui você tem um link para
um FAQ sobre o EVO:RAIL.
terça-feira, 2 de setembro de 2014
VMworld 2014 - vRealize Suite: nova plataforma para gerenciamento de nuvens híbridas
Uma outra novidade da VMworld 2014
foi o lançamento de uma nova platoforma para o gerenciamento de nuvens
híbridas, chamada de VMware vRealize Suite.
Segundo a VMware, a grande
adoção dos modelos de nuvem nos datacenters atuais não é completamente atendida
pelas ferramentas e processos de gerência tradicionais, uma vez que estes se
mostram isolados (falta integração entre os componentes), complexos e também não
oferecem o nível de automação que é exigido para atender aos negócios atuais.
Entendendo essa necessidade, a
VMware vRealize Suite se dispõe a oferecer uma plataforma para gerenciamento de
nuvens centralizada que funcione com ambientes heterogêneos e com nuvens híbridas.
Embora seja otimizado para trabalhar com ambientes VMware, a suíte pode prover
e gerenciar recursos de outras plataformas de virtualização como o Microsoft
Hyper-V e o Red Hat KVM. Essa experiência de gerenciamento unificado se extende ainda
para algumas nuvens externas como VMware vCloud Air e Amazon Web Services.
A VMware vRealize Suite possui
as seguintes capacidades:
Entrega de serviço sob demanda: fornecimento automatizado de
infraestrutura, aplicações e serviços de TI através de um portal self-service e
de um catálogo de serviços, entregues por meio de diferentes hypervisors,
nuvens privadas ou públicas.
Capacidade e otimização de recursos: permite que você faça o
correto dimensionamento dos recursos fornecidos, aumentando a utilização e
otimizando a carga sob os recursos locais ou de nuvens públicas;
Gerenciamento de desempenho e monitoramento: gerenciamento
inteligente de utilização desde aplicações até a parte de armazenamento,
passando por ambientes físicos, virtuais e nuvens externas. Possui uma
abordagem integrada de desempenho, capacidade, configuração, conformidade e
gerenciamento de log;
Medição de custos de serviço: análise do custo dos serviços
de infraestrutura, incluindo as taxas cobradas pelos serviços de nuvens
públicas. Permite medir o consumo para futuras cobranças.
Se você achou que já viu isso
anteriormente não está enganado, na verdade essa nova suíte é apenas a oferta
de produtos já existentes mas de uma maneira integrada. A VMware vRealize Suite
está disponível em duas versões diferentes. Abaixo você confere o que está
incluído em cada uma dessas versões:
vRealize Suite Advanced:
- VMware vCloud Automation Center Advanced
- vCenter Operations Management Suite Advanced
- vCenter Log Insight
- VMware IT Business Management Suite Standard
vRealize Suite Enterprise:
- VMware vCloud Automation Center Enterprise
- vCenter Operations Management Suite
Enterprise
- vCenter Log Insight
- IT Business Management Suite Standard
Uma dúvida que pode surgir é
se você deve optar pela VMware vCloud Suite ou pela VMware vRealize Suite.
Provavelmente a VMware já estava esperando por esse tipo de dúvida, por isso na
própria página dessa nova suíte existe a seguinte recomendação:
Resumindo, vCloud Suite é para aqueles que
querem construir e gerenciar uma nuvem privada baseada no VMware vSphere. A
vRealize Suite é para ambientes realmente grandes que já possuem uma nuvem
privada heterogênea (diferentes plataformas de virtualização) assim como fazem
uso também de nuvens públicas.
VMworld 2014 – O que há de novo no vSphere 6.0
Uma das coisas boas da VMworld
é que sempre temos novidades a respeito da plataforma de virtualização VMware
vSphere. Geralmente é quando é feito o lançamento de uma nova versão, porém este ano
isso não aconteceu. Ainda assim algumas sessões
que aconteceram por lá revelaram algumas das novidades que teremos no vSphere
6.0.
Abaixo vou listar algumas dessas novidades com links para artigos que
detalham melhor cada uma das funcionalidades (aqueles que tiverem interesse
recomendo dar uma lida porque tem muita informação interessante):
- VMware FT (Fault Tolerance)
com suporte para VM’s com até 4 vCPU;
- Melhorias na tecnologia de
vMotion: vMotion a longa distância irá suportar latência de até 100ms e também
será possível fazer vMotion entre vCenters diferentes;
- Virtual Volumes
- Virtual Data Center
- Content Library
- Com relação ao vCenter: O
vSphere Client para Windows ainda estará dísponivel na versão 6.0, melhorias de
desempenho no vSphere Web Client, o vCenter Server Appliance (VCSA) irá
suportar até 1000 hosts e 10000 VM’s e ainda suportará apenas o Oracle como banco
de dados externo;
Com certeza existem diversas
outras novidades que devem vir com o vSphere 6.0 mas que se encontram em NDA (acordo
para não divulgação) porque a solução ainda está em fase BETA. Inclusive o acesso
ao vSphere 6.0 BETA está aberto ao público, portanto se você tem interesse em
trabalhar com a solução antes do lançamento oficial, basta se registrar neste
link.
quinta-feira, 21 de agosto de 2014
Windows vCenter Server ou VCSA? Qual deles utilizar??
Uma das principais questões
feitas por aqueles que estão iniciando um projeto de virtualização utilizando
VMware vSphere ou atualizando para uma nova versão está relacionada com qual
versão do vCenter Server deve ser utilizada.
Até o lançamento da versão
vSphere 5.0 essa questão simplesmente não existia pois a única forma de
utilizar o Virtual Center Server era instalando-o em uma máquina Windows. A
partir de então, com o lançamento do VCSA (vCenter Server Appliance), os
arquitetos/administradores passaram a ter uma segunda opção, obrigando-os a
considerar quais as vantagens e desvantagens de cada uma das opções para
escolher aquela que melhor se encaixa em determinado projeto.
Se você reparar bem no
parágrafo anterior, vai perceber que a resposta para a pergunta em questão é a
mesma de muitas outras quando o assunto tem a ver com o planejamento e a
escolha de uma determinada configuração: “Depende!”.
Depende, porque cada caso é um
caso! E é exatamente esse o trabalho de um arquiteto quando está desenvolvendo
determinado projeto. É preciso avaliar a necessidade daquele ambiente e com
base nas características que cada uma das opções oferece, optar por aquela que
melhor atende aos requisitos estabelecidos anteriormente.
Abaixo vou levantar algumas
perguntas que podem ser feitas para ajudar a defeinir qual das opções utilizar:
- O vCenter Server será
físico ou virtual??
Dependendo da resposta aqui
fica fácil de saber se devemos utilizar a versão para Windows ou o VCSA. Caso
tenha optado por utilizar o vCenter Server em uma máquina física, então a única
opção que você tem é a de instalar a versão para Windows. Até o momento não
existe uma versão do Virtual Center que possa ser instalada em um servidor
Linux. Se você optou por utilizar o vCenter em uma máquina virtual, o seu
“dilema” continua...
- Quais as funcionalidades
não estão disponíveis no VCSA??
Desde o seu primeiro
lançamento (na versão vSphere 5.0) o appliance virtual já evoluiu bastante e
oferece suporte a maioria das soluções que se integram com o vCenter Server,
como por exemplo o vCloud Director, vCenter Operations, VMware SRM, Update
Manager e etc. Mas ainda assim existem algumas coisas que ainda não funcionam
com o VCSA, são elas: Linked Mode, vCenter Server Heartbeat, IPv6 e o suporte ao
MS SQL como banco de dados. Portanto se você precisar de alguma dessas opções,
terá de utilizar a versão para Windows.
- Qual o tamanho do
ambiente a ser suportado??
O banco de dados que vem junto
com o VCSA (vPostgres) é capaz de suportar até 100 hosts e 3000 VM’s. Se o seu
ambiente é maior do que isso, você ainda tem a opção de conectar o VCSA a um
banco de dados externo, porém o único suportado até o momento é o Oracle.
Portanto se você possui um ambiente maior que 100 hosts e/ou 3000 VM’s e não
possui a opção de utilizar um banco de dados Oracle, também terá de optar pela
versão Windows.
- Conhecimento e suporte a
um sistema operacional Linux (SUSE)?
Não são todos os ambientes que
possuem um profissional com bons conhecimentos em Linux. Apesar de não ser algo
rotineiro ter de acessar a console do VCSA para executar comandos na linha de
comando do appliance, na hora de fazer um troubleshoot esse conhecimento pode
ser importante. Além disso é importante levar em consideração alguns aspectos
operacionais do ambiente que podem ser impactados com a utilização do
appliance, como por exemplo a política de atualização do sistema operacional, a
instalação de agentes de terceiros ou então os requisitos de backup do banco de
dados.
- Limitação de
licenciamento Windows?
Um dos fatores que podem
contribuir para a utilização do VCSA é o fato de não exigir uma licença para o
Windows como a versão instalável. Então se você não possui uma licença Windows
ou então se as questões levantadas até aqui não impedem você de utilizar o VCSA,
vá em frente com o appliance.
É importante lembrar que
apesar de o Update Manager ser suportado pelo VCSA, o mesmo não pode ser
instalado no appliance virtual e continua dependendo de uma máquina Windows.
Assim como o VMware View Composer, que antigamente era obrigado a ser instalado
na mesma máquina que o vCenter Server, mas que agora pode ser instalado em uma
máquina separada, porém com Windows.
- A complexidade da instalação da versão
Windows é um problema??
Em ambientes e organizações
menores, a facilidade com que o VCSA é configurado pode ser considerado um
diferencial na hora de escolher entre uma das versões, principalmente por conta
da dificuldade técnica que a instalação da versão Windows pode apresentar para
essas organizações.
domingo, 3 de agosto de 2014
Como verificar o status do VMware VAAI
Há algum tempo atrás eu fiz um post explicando sobre o que é o VMware VAAI, recomendo que aqueles que ainda não leram ou que ainda não tem certeza de como esta funcionalidade trabalha que dêem uma passada por lá antes de prosseguirem.
Neste post vou mostrar como podemos verificar no nosso ambiente se essa tecnologia vêm sendo utilizada, uma vez que a funcionalidade já vem habilitada por padrão nos servidores ESXi.
Existem várias formas de verificarmos se os nossos datastores estão fazendo uso do VMware VAAI ou não. Veja a seguir algumas dessas possibilidades:
VMware vSphere Client:
Selecione um host, clique na aba Configuration >> Storage e verifique a aba Hardware Acceleration:
VMware vSphere Web Client:
Para verificar o status do VAAI (Hardware Acceleration) no Web Client é um pouco diferente. Na sua tela inicial (HOME) clique em Storage. Em seguida selecione o datastore desejado, clique na aba Manage >> Settings >> General:
Pela inteface gráfica são três os tipos de status que podem ser exibidos:
Not Supported: Quando o dispositivo não consegue realizar operações VAAI.
Unknown: Quando o dispositivo consegue realizar só algumas das operações VAAI.
Supported: Quando o dispositivo é capaz de realizar todas as operações VAAI.
Pela linha de comando é possível ver com mais detalhes quais as operações que são suportadas em dispositivos do tipo bloco (iSCSI ou FC) através do comando:
esxcli storage core device vaai status get
É possível utilizar a opção –d para exibir apenas o dispositivo desejado.

Nos casos dos dispositivos NAS (NFS) podemos utilizar o comando abaixo, mas o resultado é semelhante ao que é exibido pela interface gráfica:
esxcli storage nfs list
Por padrão as operações do VAAI já vem habilitadas e não há a necessidade de nenhuma intervenção do administrador para o seu funcionamento, com excessão da operação de UNMAP (Dead Space Raclamation), que desde a versão ESXi 5.0 Patch 02 (Build Number 515841) vem desabilitada por padrão, e exige que o administrador execute um comando na CLI para que determinado espaço seja recuperado. Caso seja necessário, todas as demais operações podem ser desabilitadas no ESXi.
Essas alterações podem ser feitas tanto pela CLI como pela GUI, e são dinâmicas, portanto não é necessário colocar o host ESXi em modo de manutenção e nem reiniciá-lo após as alterações.
As operações Full Block (XCOPY) e Block Zero (Write Same) podem ser desabilitadas alterando-se as seguintes opções avançadas no ESXi:
Full Block: DataMover.HardwareAcceleratedInit
Block Zero: DataMover.HardwareAcceleratedMove
A operação Hardware Assisted Locking (ATS) pode ser desabilitada alterando-se a seguinte opção avançada no ESXi:
ATS: VMFS3.HardwareAcceleratedLocking
quinta-feira, 24 de julho de 2014
EMC Virtual Storage Integrator 6.2 para VMware vSphere Web Client
Aqueles que
utilizam VMware juntamente com algum storage EMC não podem deixar de conferir o
plugin EMC VSI (Virtual Storage Integrator). Atualmente na versão 6.2 (lançada
no dia 10/07/2014), o plugin permite que o administrador VMware provisione
novos datastores diretamente na interface do VMware VSphere Web Client. Ou
seja, com o plugin não é mais necessário que o administrador primeiro crie a
LUN/VOLUME no storage, apresente para os hosts ESXi, para só então criar o
datastore. Com a utilização do plugin todas essas etapas são feitas de forma
automática através da integração do Virtual Center com o seu storage EMC. Além
dessa o plugin oferece diversas outras funcionalidades.
Desde a versão 6.0 o VSI passou a suportar o VMware VSphere Web Client, mas apenas em ambientes que possuíam o ViPR, e com os lançamentos seguintes (6.1 e 6.2) passou a suportar algumas outras plataformas: VNX, VMAX e XtremIO.
Aqueles que possuem outras plataformas de armazenamento, como por exemplo VNXe, VPLEX, CLARiiON e Celerra, podem utilizar a versão “clássica” do VSI (a última versão é a 5.6.3).
Existem algumas diferenças entre a versão “clássica” do plugin e a versão para o VMware VSphere Web Client, entre elas é que a versão clássica deve ser instalada em uma máquina Windows que possua o vSphere Client instalado. Cada uma das funcionalidades (Storage Viewer, Unified Storage Management, Path Management) consiste de um instalador diferente que deve ser instalado. Além disso o plugin só estará disponível a partir desta máquina.
Já o VSI for VMware VSphere Web Client consiste de uma VM disponibilizada no formato OVA, que após a configuração é registrada diretamente no Virtual Center como um plugin e fica disponível para acesso a partir do Web Client para qualquer usuário que possua permissão para acessa-lo. Esta opção simplifica a administração e também se alinha com a visão da VMware de centralizar o gerenciamento do ambiente a partir do Web Client (como já foi divulgado, o VSphere Client deve ser descontinuado nos próximos lançamentos).
Abaixo você confere um passo a passo das configurações necessárias para registrar o plugin no Virtual Center.
** Não vou entrar em detalhes sobre o deploy da VM.
Desde a versão 6.0 o VSI passou a suportar o VMware VSphere Web Client, mas apenas em ambientes que possuíam o ViPR, e com os lançamentos seguintes (6.1 e 6.2) passou a suportar algumas outras plataformas: VNX, VMAX e XtremIO.
Aqueles que possuem outras plataformas de armazenamento, como por exemplo VNXe, VPLEX, CLARiiON e Celerra, podem utilizar a versão “clássica” do VSI (a última versão é a 5.6.3).
Existem algumas diferenças entre a versão “clássica” do plugin e a versão para o VMware VSphere Web Client, entre elas é que a versão clássica deve ser instalada em uma máquina Windows que possua o vSphere Client instalado. Cada uma das funcionalidades (Storage Viewer, Unified Storage Management, Path Management) consiste de um instalador diferente que deve ser instalado. Além disso o plugin só estará disponível a partir desta máquina.
Já o VSI for VMware VSphere Web Client consiste de uma VM disponibilizada no formato OVA, que após a configuração é registrada diretamente no Virtual Center como um plugin e fica disponível para acesso a partir do Web Client para qualquer usuário que possua permissão para acessa-lo. Esta opção simplifica a administração e também se alinha com a visão da VMware de centralizar o gerenciamento do ambiente a partir do Web Client (como já foi divulgado, o VSphere Client deve ser descontinuado nos próximos lançamentos).
Abaixo você confere um passo a passo das configurações necessárias para registrar o plugin no Virtual Center.
** Não vou entrar em detalhes sobre o deploy da VM.
1. Após realizado o deploy, o
primeiro passo é acessar a seguinte URL: "https://endereco_ip_vapp:8443/vsi_usm/admin". Será
solicitado que você faça a alteração da senha do usuário admin.
2. Após logar no sistema, será exibida a
tela abaixo com algumas informações sobre a versão do sistema. Clique na opção “VSI Setup”, conforme exibido abaixo:
3. Nesta tela você deverá preencher com
as informações referentes ao Virtual Center no qual você deseja que o plugin
esteja disponível (não necessariamente no mesmo Virtual Center no qual a VM foi
instalada).
**O
usuário utilizado para esta conexão deve possuir permissões de administrador no
Virtual Center.
4. Confirme que registro foi bem
sucedido:
5. O próximo passo é acessar o vSphere
Web Client e verificar se o plugin EMC VSI está disponível, conforme mostrado
abaixo:
6. Em seguida devemos registrar o SIS
(Solutions Integration Service) no novo plugin. Para isso, clique em Solutions Integration Service. No menu Actions, clique na opção Register Solutions Integration Service:
7. Na caixa de diálogo que aparecerá,
você deverá preencher com as informações do seu servidor SIS. É importante
observar que alguns campos estarão desabilitados para preenchimento, entre
eles:
EMC Solutions Integration Service User Name: este campo estará preenchido com o usuário com o qual você está logado no vSphere Web Client. A senha a ser digitada não precisa ser a senha deste usuário, pois será criada uma conta local no SIS com o mesmo nome e a senha que você digitar.
vCenter IP: Endereço IP do seu Virtual Center.
vCenter User Name: Nome de usuário utilizado para logar no Virtual Center.
8. Em seguida você deverá registrar o seu
Storage. Para isso clique em Storage
Systems. No meu Actions, clique
em Register Storage System:
9. Será aberta uma caixa de diálogo na
qual deverão ser preenchidas as informações sobre o seu Storage. Na versão 6.2
do plugin você tem a opção de registrar os seguintes tipos de sistema de armazenamento: ViPR, VNX, VMAX e XtremeIO.
A partir desse momento você já consegue provisionar novos datastores a partir do seu VMware vSphere Web Client, basta selecionar um dos seus hosts ESXi e clicar no menu Actions. Você verá um menu como o mostrado abaixo:
Nessa versão também é possível disponibilizar um novo disco RDM para uma determinada VM, basta clicar com o botão direito sobre a máquina virtual na qual deseja adicionar o novo disco e selecionar a opção New EMC RDM Disk...
VSI 6.2 Release Notes:
Virtual Storage Integrator
- Matriz de Compatilidade
https://support.emc.com/docu49728_Simple-Support-Matrix-Virtual-Storage-Integrator-(VSI)-Storage-Management.pdf
VSI for VMware vSphere Web Client 6.2 Download:
VSI for VMware vSphere Web Client 6.2 Download:
segunda-feira, 30 de junho de 2014
Conheça o VMware Hands-On Lab
Foi pensando nisso que a VMware lançou (no final do ano de 2012) o VMware Hands-On Lab.
Se trata de uma plataforma de educação online e gratuita, parte do projeto VMware Project Nee (Next-Generation Education).
Qualquer um pode se registrar e a partir daí iniciar os laboratórios. Todos os laboratórios incluem um Manual com um passo-a-passo que você pode ir acompanhando. São dezenas de labs que você pode escolher, das mais diversas soluções da VMware.
Veja abaixo alguns dos labs com foco na parte de Storage:
No link a seguir tem um passo-a-passo de como se registrar e iniciar um laboratório no site:
http://blogs.vmware.com/hol/2013/12/how-do-i-register-for-vmware-hands-on-labs-link-to-vmware-hands-on-labs.html
Veja mais no vídeo abaixo:
segunda-feira, 21 de abril de 2014
Problemas com o protocolo NFS no vSphere 5.5 U1
Na última semana a VMware confirmou a existência de um bug no vSphere ESXi 5.5 Update 1 (build number 1623387), que faz com que datastores conectados via NFS percam a comunicação com os hosts, aleatoriamente. O problema começou a ser relatado por alguns bloggers e também por alguns usuários no twitter. Os primeiros a notar o bug foram os usuários de storages NetApp, mas logo foi verificado que o problema estava ocorrendo também com storages de outros fabricantes.
Quando o problema estiver acontecendo, é possível notar que os datastores e as VM`s que estão nestes datastores ficam “cinzas” e inacessíveis. Além disso como o datastore está inacessível, as VM`s não conseguirão fazer nenhum tipo de operação de I/O, o que pode causar tela azul em servidores Windows. Já nas máquinas virtuais Linux, o sistema de arquivos pode entrar em modo somente leitura (read only).
De acordo com a VMware, as mensagens abaixo podem ser encontradas no log vobd quando o problema estiver ocorrendo:
2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
Até o momento, a única solução apresentada para o problema é um rollback para a versão vSphere ESXi 5.5 G.A (build number 1331820).
Para continuar acompanhando este caso, recomendo ficar de olho no KB 2076392
domingo, 23 de março de 2014
Configurando o Virtual SAN mesmo sem um disco SSD
Com o lançamento do VSAN é natural que os interessados na tecnologia busquem uma forma de estudar e conhecer mais a fundo a solução. A idéia deste post é mostrar uma maneira de utilizar a solução em um ambiente de laboratório, onde os recursos nem sempre atendem aos requisitos que as ferramentas exigem.
O primeiro passo para iniciar a instalação do Virtual SAN é fazer o download dos últimos instaladores do VMware Virtual Center 5.5 U1 e do ESXi 5.5 U1.
Não vou entrar em detalhes com relação a instalação do Virtual Center e nem dos hosts ESXi.
A seguir vamos lembrar os principais requisitos para a utilização do VSAN:
- VMware Virtual Center 5.5 U1;
- Mínimo de 3 hosts ESXi 5.5 U1;
- No mínimo 1 disco SSD e 1 disco HDD (lembrando que se o ESXi estiver instalado em um disco local, este não poderá ser utilizado no cluster VSAN);
- 1 interface de rede com no mínimo 1Gb;
Talvez o maior desafio para a maioria seja ter acesso a um disco SSD no ambiente de LAB, mas existe uma forma de “mascarar” e fazer com que o seu ESXi (mesmo virtual) acredite que um determinado disco seja do tipo SSD. Aqueles que já estudaram ou estão estudando para a certificação VCAP-DCA já devem saber do que estou falando.
AVISO: ESSA CONFIGURAÇÃO NÃO DEVE SER UTILIZADA NUM AMBIENTE DE PRODUÇÃO, ALÉM DE NÃO SER SUPORTADA, TAMBÉM NÃO OFERECERÁ O DESEMPENHO ESPERADO.
Se você não tem um disco SSD para utilizar com o VSAN, veja como “mascarar" essa configuração:
Depois de instalado o ESXi e adicionado-o ao Virtual Center, identifique as configurações de disco do seu servidor. No seu WebClient, selecione o seu host ESXi e clique em Manage -> Storage -> Storage Devices:
Veja no exemplo acima que o host esxi01.lab.local possui 1 CDROM, 3 discos locais e 1 disco iSCSI. Para nós o CDROM e o disco iSCSI são indiferentes pois como já sabemos o Virtual SAN trabalha com os discos locais. Neste caso vamos ignorar também o disco mpx.vmhba1:C0:T0:L0 pois ele é o disco no qual a instalação do ESXi foi feita. Portanto nos resta os discos mpx.vmhba1:C0:T1:L0 (10GB) e mpx.vmhba1:C0:T2:L0 (30GB). Repare que ambos estão aparecendo como Non-SSD. Para configurarmos o VSAN vamos precisar que pelo menos um deles seja reconhecido como SSD. Faremos isso com o disco mpx.vmhba1:C0:T1:L0.
O próximo passo será acessar o host via SSH para descobrir qual o SATP (Storage Array Type Plugin) o disco está utilizando: esxcli storage nmp device list -d [device]
Neste caso o disco mpx.vmhba1:C0:T1:L0 está utilizando o SATP VMW_SATP_LOCAL. (Esta informação será útil no próximo passo).
Com estas informações em mãos poderemos criar uma regra no ESXi para que ele reconheça este dispositivo como sendo do tipo SSD.
esxcli storage nmp satp rule add -s [SATP] -d [device] -o enable_ssd
esxcli storage core claimrule load
esxcli storage core claimrule run
esxcli storage core claiming reclaim -d [device]
Veja abaixo que agora o disco mpx.vmhba1:C0:T1:L0 aparece como SSD.
Execute este procedimento em todos seus hosts que irão fazer parte do cluster VSAN.
LEMBRANDO QUE ESTE PROCEDIMENTO DEVE SER EVITADO EM UM AMBIENTE DE PRODUÇÃO.
Em seguida deveremos configurar uma interface VMkernel em cada um dos hosts.
1)
2)
3)
4)
5)
6)
Por último, vamos habilitar o Virtual SAN:.
É possível configurar o Virtual SAN no momento da criação do cluster e também em um cluster já existente. Porém antes de configurar num cluster que tenha o VMware HA habilitado, será necessário desabilita-lo antes, caso contrário receberá uma mensagem de erro como a que segue:
“Turn off vSphere HA to turn on/off Virtual SAN”
Depois que o Virtual SAN for habilitado, você poderá ver a quantidade de hosts existentes no cluster, a quantidade de discos SSD e discos de dados e as informações sobre a capacidade total e a quantidade de espaço livre do VSAN datastore.
Se verificarmos os datastores do cluster, veremos que um novo datastore foi criado. Por padrão o nome deste datastore será “vsanDatastore”, mas nada te impede de alterar este nome.
Repare que o tipo do datastore também aparece como VSAN e não como VMFS5.
Assinar:
Postagens (Atom)