VMware Brasil

Reunião Q3 - Brasilia VMUG - 04/08/2017

2017-08-01T13:32:00.000-03:00

O VMUG Brasília (grupo de usuários VMware independente) se reunirá na próxima sexta-feira, dia 4 de agosto de 2017, no Centro Universitário IESB, às 18h30. O encontro - que faz parte das atividades dos cursos de Análise e Desenvolvimento de Sistemas, Segurança da Informação e Rede de Computadores da instituição - terá duas apresentações técnicas sobre temas de interesse da comunidade VMUG, como por exemplo Composible Infrastruture, Hyperconvergence, Containers and Docker, PaaS and Cloud Ready Applications.

“As tecnologias que serão tratadas nas palestras fornecem a sustentação para ambientes computacionais que exigem alta disponibilidade de aplicações”, explica o coordenador do curso de Segurança da Informação, professor Francisco Marcelo.

O encontro terá as seguintes apresentações:

Como responder às transformações na era digital com a agilidade exigida pelos usuários e os requisitos estabelecidos pelo negócio, com Luciano Freitas, HPE Master Accredited Solutions Expert, que trata de Composible Infrastructure and Containers;

Execute aplicativos em contêineres juntamente com aplicativos tradicionais na infraestrutura já existente, que será oferecida pela VMware, explicando sobre vSphere Integrated Containers, que oferece aos desenvolvedores infraestrutura em nível de produção e ajuda a equipe de operações de TI a executar aplicativos tradicionais e em contêineres simultaneamente, em uma infraestrutura comum proporcionando velocidade, agilidade, segurança, isolamento e gerenciamento de VMs.

Durante o evento, serão sorteados brindes aos participantes e anunciado o ganhador do Badge Contest. Para se inscrever é necessário entrar no https://goo.gl/7HQn7d

Reunião Q3 VMUG Brasília

Data: 04 de agosto

Hora: 18h30

Local: Sala BB1, Campus Sul

Inscrições: https://goo.gl/7HQn7d

VMUG-SP realizará seu primeiro encontro no próximo dia 17/11/2016

2016-11-03T10:49:00.000-02:00

A primeira reunião do VMUG SP – Grupo de Usuários de VMware de São Paulo já tem data e local para acontecer

O Grupo de Usuários VMware de São Paulo (VMUG SP) foi criado para incentivar o networking e o compartilhamento de conhecimento entre os profissionais de VMware no Estado de São Paulo e também fortalecer o relacionamento com a VMware Brasil e seus parceiros de negócios.

O VMUG é uma organização mundial presente nas principais capitais e grandes centros do mundo e conta atualmente com mais de 150 mil membros ativos, sendo a maior organização do mundo para usuários de virtualização. Cada grupo local é totalmente independente e gerido pelos próprios membros que escolhem e apresentam temas de interesse geral relacionados a tecnologia.

O evento acontecerá no escritório da VMware São Paulo, localizado na Rua Surubim 504 – 4o Andar, no bairro do Brooklin em São Paulo no próximo dia 17 de novembro com início às 18 horas.

“Já temos confirmado a palestra de Introdução a Software Defined Network e ao VMware NSX com o System Engineer de NSX da VMware, Caio Oliveira e temos muitos outros assuntos interessantes para apresentar” diz Valdecir Carvalho, líder do VMUG SP.

A agenda completa do evento será divulgada em breve no site do VMUG SP – http://vmugsp.com.br

A participação no evento é totalmente gratuita e haverá sorteio e distribuição de brindes.

O que há de novo no vSphere 6.5? - vSphere DRS

2016-10-25T16:35:00.001-02:00

VM Distribution

A primeira opção faz com que o DRS tente balancear as VMs de maneira mais igual entre os hosts ESXi de um cluster. Por padrão o DRS distribui as VMs em um cluster levando em conta mais a utilização dos recursos nos hosts, e tenta manter uma utilização próxima entre os hosts, independente do número de VMs. Essa opção, VM Distribution, corresponde à opção avançada TryBalanceVmsPerHost, que foi adicionada no vSphere 6.5 para tentar balancear o número de VMs nos hosts.

Por exemplo, muitas vezes acontece de existir uma VM muito grande em um cluster, algumas VMs médias e muitas VMs pequenas. Pode acontecer do DRS alocar a VM grande sozinha em um host e alocar outras dezenas de VMs menores em um outro host. Do ponto de vista da utilização dos recursos, esse cenário até poderá estar bem distribuído, porém do ponto de vista da disponibilidade das VMs, não está. Pois, enquanto a queda de um host pode resultar na indisponibilidade de uma única VM, a queda do outro pode resultar na indisponibilidade de dezenas de VMs.

Com a opção VM Distribution habilitada, cada host terá um limite de VMs “maxVMs”, calculado com base numa média de VMs por host. Esse limite será aplicado somente ao algoritmo de balanceamento de carga do DRS, no caso do algoritmo que define o melhor host na hora de ligar uma VM, esse limite poderá esse violado.

Memory Metric for Load Balancing

Por padrão o DRS utiliza a métrica de Active Memory na hora de balancear as VMs entre os hosts. A métrica Active Memory é resultado de um cálculo feito pelo VMkernel que leva em conta apenas as páginas de memória que foram recentemente acessadas pela VM. Alguns administradores preferem trabalhar com uma outra métrica chamada de Consumed Memory. Essa métrica é um pouco mais conservadora e leva em conta todas as páginas de memória que em algum momento já foram alocadas por uma VM. É por isso que geralmente a métrica Active Memory é inferior à Consumed Memory, que por sua vez é inferior, porém mais próxima, ao Configured VM Size.

Como a própria opção descreve, alterar a métrica a ser utilizada pelo DRS para o balanceamento das VMs, de Active Memory para Consumed Memory só é recomendado para clusters onde não há over-committed de memória.

CPU Over-Commitment

Essa opção pode ser utilizada para controlar a taxa de sobre-alocação (over-commitment) de CPU em um cluster. Existem alguns casos em que os administradores precisem garantir uma determinada relação de vCPU:pCPU (num de CPUs virtuais por num de CPUs físicos), por conta de algum requisito de uma aplicação específica. Em ambientes VDI por exemplo, essa é uma questão bastante relevante.

- DRS – Network Aware

Uma outra novidade no vSphere 6.5 com relação ao DRS é a verificação da utilização de rede em um host na hora de alocar ou mover uma VM. Até então o DRS levava em conta somente os recursos de CPU e Memória de um host na hora de definir o melhor host para pôr uma VM quando ela fosse ligada e também na hora de balancear as VMs. Com isso poderia ocorrer de haver um host com baixa utilização de CPU/Mem e uma alta utilização de rede mas mesmo assim o DRS movimentar VMs para este host ou ligar uma VM nele, podendo causar um congestionamento no uplink, e consequentemente impactando no desempenho de todas as VMs em execução no host.

Com a implementação do Network Aware, o DRS passa a considerar a utilização da placa de rede física dos hosts ESXi, e quando estas apresentarem uma utilização superior a 80%, o DRS irá considerar este host como saturado e evitará ligar novas VMs neste host e também tentará resolver este problema de saturação,movimentando algumas VMs deste host para outros na execução do próximo ciclo do DRS.

- Predictive DRS

O Predictive DRS é uma nova funcionalidade do vSphere 6.5 que como o próprio nome sugere “prevê” a utilização de recursos do cluster e faz o balanceamento da carga (se necessário) antes. Para fazer isso, o DRS irá contar com a ajuda do vROPS (vRealize Operations). A versão do vROPS que terá suporte a essa funcionalidade deve sair até a metade do ano de 2017, portanto apesar dessa funcionalidade já estar embutida no código do vSphere 6.5, será necessário aguardar o lançamento da próxima versão do vROPS para utiliza-la.

O vROPS calcula e prevê a utilização dos recursos de CPU e Memória com base no histórico de dados que ele captura do vCenter. A partir daí o vROPS passa a calcular thresholds dinâmicos (Dynamic Thresholds), e quanto mais dados são capturados ao longo do tempo, essas previsões se tornam mais precisas, e com níveis mais elevados de confiança.

Em seguida essas previsões são enviadas para o DRS, que consome esses dados com antecedência (por padrão o DRS trabalha com 60 minutos de antecedência) e balanceia o cluster com base na utilização prevista. O benefício disso é que picos na utilização dos recursos poderão ser previstos e o balanceamento da carga ocorrerá antes que este pico ocorra, possibilitando um melhor desempenho do ambiente como um todo.

Outros posts sobre o que há de novo no vSphere 6.5:

O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)
O que há de novo no vSphere 6.5? - vSphere HA
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage
O que há de novo no vSphere 6.5? - Virtual SAN 6.5

O que há de novo no vSphere 6.5? - vSphere HA

2016-10-25T16:35:00.000-02:00

Na semana passada, a VMware anunciou oficialmente a nova versão da sua plataforma de virtualização, o vSphere 6.5. O anúncio ocorreu na abertura da edição européia da VMworld 2016, que aconteceu em Barcelona entre os dias 17/10/16 e 20/10/16 , e trouxe muitas novidades.

Nesse post vou falar sobre as novidades do vSphere 6.5 com relação ao HA.

Depois de um bom tempo, finalmente a VMware anunciou algumas mudanças e/ou novidades relativas aos mecanismos do HA (High Availability).

- HA – Admission Control

O Admission Control é uma funcionalidade do HA utilizada para garantir que o cluster terá recursos suficientes para continuar atendendo às VMs no caso de falha em algum(s) hosts. Até então a configuração do Admission Control era de díficil entedimento para muitos, não é atoa que em muitos lugares ela não é nem utilizada, e isso não é nada bom. A maior dificuldade estava na hora de calcular o quanto de recursos seria necessário reservar para continuar atendendo às demandas das VMs sem que as mesmas viessem a sofrer quedas de desempenho.

Com o vSphere 6.5, a interface para configuração foi simplificada, e agora a política padrão passou a ser a “Cluster Resource Percentage”, ao invés da política baseada em slots.

Sobre a política padrão “Cluster Resource Percentage”, agora ela está completamente relacionada à opção “Host failures cluster tolerates”, ou seja, dependendo da quantidade de hosts que você estiver disposto a perder, a porcentagem de recursos reservados será automaticamente calculada. Por exemplo, suponha que o seu cluster possua 4 hosts, ao configurar a opção Host failures cluster tolerates=1, os valores reservados para CPU e Memória serão automaticamente setados em 25%. Se um novo host for adicionado ao cluster, esses valores também serão automaticamente ajustados para 20%.

Se você reparar bem na imagem acima, existe uma nova opção de configuração chamada “Performance degradation VMs tolerate”. Com essa opção é possível setar quantos % de degradação de desempenho será tolerado nas VMs do cluster. Com base no valor configurado, um alerta poderá ser gerado quando, após uma falha, não houver capacidade suficiente para garantir o mesmo nível de desempenho às VMs. Por padrão esse valor é 100%.

- HA Orchestrated Restart

A principal função do HA é garantir que as VMs estejam sempre disponíveis, por isso ao detectar uma falha em um host, o principal objetivo do HA passa a ser religar o quanto antes as VMs, que estavam no host que falhou, nos demais hosts que permaneceram disponíveis. Infelizmente, nem sempre o fato de religar as VMs em outros hosts significava que uma aplicação voltaria funcionar. Esse era o cenário encontrado no caso das aplicações Multi-tier, por exemplo com uma VM para Web-Server, uma para App e uma para BD, se o HA ligasse a VM de App antes da VM do BD, é provável que a aplicação não subiria corretamente e uma intervenção manual seria necessária, aumentando o tempo de recuperação do ambiente.

No vSphere 6.5 foi adicionada uma funcionalidade chamada de HA Orchestrated Restart, que permitirá a criação de grupos de VMs e de regras que irão controlar a ordem com que as VMs nestes grupos serão ligadas.

A imagem acima exemplifica bem como o Orchestrated Restart funciona. Neste caso 3 grupos de VMs seriam criados. O grupo 1 com a VM de BD, o grupo 2 com a VM de App e o grupo 3 com a VM de Web. Em seguida duas regras seriam criadas, a primeira configurando a dependência do grupo 2 ao grupo 1, ou seja, a VM do grupo 2 só vai ligar após a VM do grupo 1. A segunda regra configuraria a dependência do grupo 3 ao grupo 2, o que fará com que a VM do grupo 3 só seja ligada após a VM do grupo 2.

O tempo de espera entre o ligamento das VMs dependerá da configuração da opção “VM Dependency Restart Condition”.

- Proactive HA

Uma nova funcionalidade adicionada ao vSphere 6.5 é o Proactive HA. O Proactive HA, apesar de ter HA no nome e aparecer na seção vSphere Availability na interface gráfica, é na verdade uma funcionalidade do DRS. O principal objetivo do Proactive HA é agir quando ocorrer algum evento no host que possa vir a gerar algum tipo de indisponibilidade no host e consequentemente nas VMs.

Para que isso seja possível, o Proactive HA trabalhará em conjunto com o software de monitoramento de hardware dos fabricantes de servidores (Health Provider), através de um plugin para o WebClient, que fornecerá detalhes sobre a saúde e o status do servidor para o DRS, o qual reagirá de acordo com o status do hardware do host.

Dentre os status possíveis que o Health Provider pode informar ao vCenter Server estão: Healthy, Moderate Degradation, Severe Degradation e Unknown. A definição de quais eventos resultarão em quais status caberá ao fabricante de hardware.

Com base no status indicado o DRS poderá alterar o mode de operação do host para “Maintenance Mode” ou “Quarantine Mode”.

O Maintanence Mode já existia anteriormente e o funcionamento é o mesmo, ou seja, todas as VMs serão migradas para fora do host.

No caso do Quarantine Mode, este modo é novo no vSphere 6.5 e só é ativado através do Proactive HA, não é possível habilita-lo/desabilita-lo manualmente como pode ser feito com o Maintenance Mode. Quando o Quarantine Mode é habilitado não necessáriamente todas as VMs serão migradas para fora do host, existem dois casos nos quais as VMs permanecerão no host:

1. Caso não haja recursos suficientes nos demais hosts para migrar as VMs sem que o desempenho das demais máquinas virtuais do cluster sejam impactadas;
2. Caso exista alguma regra de afinidade do DRS (VM/VM ou VM/Host) que impeça a migração da VM;

Como pode ser visto na imagem acima, é possível configurar diferentes respostas para diferentes tipos de falhas, por exemplo Quarantine Mode para falhas que resultem em um status Moderate Degradation e Maintanence Mode para falhas que resultem em Severe Degradation.

Outros posts sobre o que há de novo no vSphere 6.5:

O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)
O que há de novo no vSphere 6.5? - vSphere DRS
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage
O que há de novo no vSphere 6.5? - Virtual SAN 6.5

O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)

2016-10-25T16:34:00.006-02:00

Nesse post vou falar sobre o que há de novo no vCenter Server Appliance (VCSA) 6.5.

Já faz um tempo que a VMware vêm incentivando os seus usuários a utilizarem o appliance virtual ao invés da versão Windows, porém a sensação que se tinha era a de que sempre estava faltando alguma coisa. Apesar das melhorias feitas nas versões anteriores, ainda assim muitos optavam por permanecer com a versão instalada sob o Windows.

Parece que dessa vez a VMware resolveu “apelar” pra valer, e trouxe muita coisa nova junto com o novo vCenter Server Appliance 6.5.

- vSphere Update Manager (VUM)

Um dos fatores que desmotivavam os usuários a migrarem para o VCSA era a necessidade de manter o VUM rodando em um servidor Windows. Geralmente, a maioria dos administradores que optavam pela versão Windows, utilizavam o mesmo servidor para instalar o VUM. No caso de optarem pelo VCSA, ainda assim teriam de manter um servidor Windows só para o VUM, o que de certa forma gerava um esforço a mais para gerenciamento (o que antes era um único servidor Windows, passou a ser dois servidores , sendo 1 Windows e 1 Linux).

Com a nova versão VCSA 6.5 o VUM já virá embutido no appliance, totalmente integrado e habilitado por padrão. Além disso, o VUM também se beneficiará das novas funcionalidades de alta disponibilidade (HA) e backup do VCSA.

- Processo de Instalação e Configuração do VCSA

Anteriormente o processo de deploy do VCSA era um pouco limitado devido à dependência do Client Integration Plugin (CIP), uma vez que o mesmo só funcionava em máquinas Windows, além de “encrencar” com alguns browsers. O processo de instalação foi extremamente simplificado e consiste de duas etapas: deploy do OVA e processo de configuração. Podendo ser feito tanto de uma máquina Windows, Linux ou Mac.

O menu de configuração possui 4 opções: Install, Upgrade, Migrate e Restore

Das opções listadas anteriormente, acredito que as opções Migrate e Restore mereçam uma atenção especial.

Migrate: Como a própria descrição abaixo da opção explica, essa é uma opção para migrar o vCenter Server instalado no Windows diretamente para o VCSA. Essa opção havia sido lançada a pouco tempo atrás no formato de fling, mas a partir de agora é uma opção completamente suportada e embutida no vCenter. As versões suportadas para migração são 5.5 e 6.0. Tanto as instalações com o banco de dados embutido como as instalações com banco de dados externos poderão ser migradas. Ao término da migração, o novo VCSA assumirá por completo a identidade do vCenter anterior, incluindo UUID, IP, hostname, certificados e etc. Além disso o vSphere Update Manager também será migrado, com todas as configurações (mesmo que seja externo ao vCenter).

Um detalhe importante é que você terá a opção de escolher os dados a serem migrados:
- somente configuração;
- configuração, eventos e tarefas;
- configuração, eventos, tarefas e dados de performance

Restore: Com a nova funcionalidade de backup (veja mais detalhes a seguir), foi incluída também a possibilidade de Restore. Com essa opção, é possível realizar o deploy de um novo OVA e apontar para que seja feita a restauração de um backup. O novo deploy retornará o VCSA com as mesmas configurações anteriores (incluíndo o banco de dados). Essa opção funciona tanto com instalações embutidas (vCenter + PSC) ou externas (vCenter / PSC), e serve para restaurar qualquer um dos appliances (vCenter ou PSC).

- Gerenciamento e Monitoramento do VCSA através da VAMI

VAMI (Virtual Appliance Management Interface) é a principal interface para gerenciamento do appliance. Nas versões anteriores essa interface era bem simples e não tinha muito o que fazer nela a não ser algumas configurações de rede e serviços. Com essa nova versão essa interface foi completamente renovada, e agora além da parte de configuração também permite que o vCenter seja monitorado através dela, com estatísticas de utilização de CPU e Memória, e também informações relativas ao banco de dados do vCenter/VUM.

- Alta Disponibilidade Nativa

Implementar uma solução para alta disponibilidade do vCenter Server nunca foi algo trivial, e sempre houve um ponto de interrogação sobre quando a VMware resolveria essa questão. Alguns devem se lembrar do vCenter Server Heartbeat que foi descontinuado em meados de 2014, e de lá pra cá, nenhum outro produto foi lançado. A última investida da VMware nesse sentido foi a possibilidade de implementar o vCenter Server em cima de um Failover Cluster da Microsoft, mas devido à complexidade da solução, acredito que muitos não chegaram nem a testar essa possibilidade.

Com a nova versão do VCSA 6.5 foi incluído um mecanismo de cluster do tipo ativo/passivo. Para a formação do cluster, deverá ser adicionada uma nova interface de rede no appliance que será utilizada para uma rede privada entre os appliances, e será responsável pela replicação entre eles. A replicação será síncrona no que diz respeito ao banco de dados, utilizando um mecanismo do próprio Postgres. Algumas outras informações que são baseadas em arquivos, serão replicadas de forma assíncrona, pois antes da replicação é necessário que o arquivo seja escrito localmente. Porém de acordo com o que foi passado, esse processo será tão rápido que não deverá causar nenhum problema.

- Backup/Restore

Outra função que há tempos era desejada por aqueles que já utilizavam o VCSA era a possibilidade de fazer backup de uma maneira menos trabalhosa e independente de ferramentas de terceiros.

Agora o backup e o restore dos appliances (VCSA e PSC) serão tratados diretamente no próprio appliance. Com suporte aos protocolos HTTP/S, FTP/S e SCP para a transferência. E também com suporte a criptografia. Além disso haverá um processo para checar a consistência dos backups a fim de garantir que os mesmos estão bons para serem restaurados.

Outros posts sobre o que há de novo no vSphere 6.5:

O que há de novo no vSphere 6.5? - vSphere HA
O que há de novo no vSphere 6.5? - vSphere DRS
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage
O que há de novo no vSphere 6.5? - Virtual SAN 6.5

O que há de novo no vSphere 6.5? - Virtual SAN 6.5

2016-10-25T16:34:00.005-02:00

Na semana passada, a VMware anunciou oficialmente a nova versão da sua plataforma de virtualização, o vSphere 6.5 e junto com ela veio também a nova versão da Virtual SAN 6.5. O anúncio ocorreu na abertura da edição européia da VMworld 2016, que aconteceu em Barcelona entre os dias 17/10/16 e 20/10/16 , e trouxe muitas novidades.

Nesse post vou falar sobre as principais novidades da Virtual SAN 6.5.

Para saber mais sobre Virtual SAN, veja os posts da série sobre VMware Virtual SAN 6.2:

VMware Virtual SAN 6.2 – Parte 1 – Introdução

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

VMware Virtual SAN 6.2 – Parte 4 – VASA e as Políticas de Armazenamento

- Native Support for iSCSI Target

Com o vSAN 6.5 será possível fornecer área de armazenamento para hosts externos ao VMware, por exemplo um outro hypervisor ou cluster microsoft, ou qualquer servidor físico que precise acessar uma área de armazenamento compartilhada. Esse fornecimento de área será feito através do protocolo iSCSI, ou seja, com o vSAN 6.5 será possível configurar o hosts ESXi como um iSCSI target e a partir dele fornecer armazenamento em bloco (LUNs) para outros servidores. As LUNs, criadas em cima do vSAN Datastore, serão objetos do vSAN e portanto poderão estar associadas às políticas de armazenamento disponíveis e usufruir de funcionalidades como Dedup e Compressão, RAID1, RAID5 ou RAID6, e etc...

Os limites máximos para a configuração do iSCSI no Virtual SAN 6.5 serão:

1024 LUNS per cluster
Maximum of 128 sessions per node
Maximum of 128 targets per cluster
Max Lun size is 62 TB

- 2 node Direct Connect

Essa novidade é mais voltada para ambientes menores/remotos onde se têm no máximo dois nodes ESXi para formar um cluster vSAN. A partir do vSAN 6.5, será possível conectar estes 2 nodes diretamente, através de uma conexão cruzada (cross-connected), eliminando assim a necessidade de um switch de rede para o tráfego do vSAN, e consequentemente reduzindo o custo total da solução. Além disso será possível segregar o tráfego de dados do vSAN, que passará no link direto entre os dois nodes, do tráfego para o Witness, que poderá utilizar uma outra interface vmkernel.

- All Flash para todos

Com o VMware Virtual SAN 6.5 vieram algumas mudanças no licenciamento, em especial para os usários que desejam utilizar o vSAN no modelo All Flash. A partir de agora, todas as versões de licenciamento do vSAN, incluíndo a edição Standard, irão suportar modelos de hardware all flash. Um detalhe importante é que os serviços de dados exclusivos dos modelos all flash, como Dedup e Compressão, RAID5/6 continuarão disponíveis apenas a partir da edição Advanced.

- PowerCLI cmdlets for VSAN

Com o novo vSAN 6.5 foi atualizada também a API do vSAN e com a próxima versão do PowerCLI virá uma série de novos cmdlets para o Virtual SAN, possibilitando a automatização de uma série de tarefas de configuração e gerenciamento do cluster vSAN.

No vídeo abaixo é possível ver um exemplo de criação e configuração de um cluster vSAN utilizando o PowerCLI.

Outros posts sobre o que há de novo no vSphere 6.5:

O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)
O que há de novo no vSphere 6.5? - vSphere HA
O que há de novo no vSphere 6.5? - vSphere DRS
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage

O que há de novo no vSphere 6.5? – VMFS-6 / Core Storage

2016-10-25T16:34:00.003-02:00

Na semana passada, a VMware anunciou oficialmente a nova versão da sua plataforma de virtualização, o vSphere 6.5. O anúncio ocorreu na abertura da edição européia da VMworld 2016, que aconteceu em Barcelona entre os dias 17/10/16 e 20/10/16 , e trouxe muitas novidades.

Nesse post vou falar sobre as novidades do vSphere 6.5 com relação ao novo sistema de arquivos VMFS-6 e também sobre algumas mudanças que dizem respeito à parte de armazenamento.

- VMFS-6

O fato da VMware ter incluído uma nova versão do seu sistema de arquivos, o VMFS-6, mostra que mesmo que o direcionamento esteja voltado para novas formas de armazenamento como vSAN e vVOLS, ainda assim novas funcionalidades e melhorias estão sendo implementadas no seu sistema de arquivos mais “tradicional”, visando atender a todos os usuários.

Sobre as melhorias que vieram junto com o VMFS-6, a maioria delas é interna, no entanto apesar de não vê-las o usuário com certeza irá percebê-las, uma vez que o foco destas melhorias esteve voltado para melhorar o desempenho como um todo, como na criação mais rápida de arquivos, na descoberta de novos dispositivos e também no rescan.

Uma outra novidade, e essa mais voltada para o futuro, é o alinhamento em 4K. Essa mudança permitirá que o VMFS-6 suporte os novos discos 4K assim que estes passarem a ser suportados pelo ESXi. Para aqueles que tiverem interesse em saber mais sobre esse formato de discos 4K (chamado de formato avançado), este artigo da Seagate é bastante interessante e completo sobre o assunto.

Outra melhoria que merece atenção é a melhor forma com que o VMFS-6 irá tratar os casos de ATS Miscompare. Se você não enfrentou nenhum problema desses, sorte a sua, mas foram vários os casos de Storage Arrays que tiverem problemas com o hearbeat do ATS (KB2113956). No VMFS-6 foi adicionado um novo mecanismo de “retry” que tentará evitar que os timeouts no heartbeat ATS ocorram e gerem os problemas já conhecidos.

Por último, é importante saber que não haverá um caminho para fazer upgrade de um VMFS-3 ou VMFS-5 para o VMFS-6, devido às diversas mudanças que tiveram. A atualização para o VMFS-6 deverá ser feita através de migrações, como por exemplo utilizando o Storage vMotion. Na minha opinião, sempre que possível esse é mesmo o melhor caminho, mesmo no caso do VMFS-3 para o VMFS-5, em que era possível o upgrade, formatar o disco com VMFS-5 e migrar era a minha primeira opção. Somente em casos em que não havia espaço necessário para a migração é que optava pelo upgrade. Portanto acredito que essa “limitação” no VMFS-6 não será um grande problema.

- UNMAP

O UNMAP é uma técnica utilizada para recuperar um espaço que não está mais sendo utilizado no datastore e devolvê-lo para o storage. O unmap é na verdade uma funcionalidade do VAAI e já estava presente no vSphere desde versões anteriores. A diferença é que agora a recuperação desse espaço pode ser automática e configurada pela própria interface gráfica. Antes o unmap/reclaim deveria ser feita pela linha de comando e manualmente.

- Novos limites

Talvez a novidade que vá alegrar mais alguns dos usuários VMware será essa! Com o vSphere 6.5 o limite de dispositivos por ESXi subiu de 256 para 512 (2x). E também o limite de paths de 1024 para 2000. Conheço vários casos em que esse limite foi atingido e isso gerava uma dor de cabeça imensa para os usuários, com o vSphere 6.5 será mais difícil chegar nesse limite, e se chegar, é porque está na hora de pensar em algo mais escalável e “moderno” como por exemplo vSAN ou vVOLs.

Outros posts sobre o que há de novo no vSphere 6.5:

O que há de novo no vSphere 6.5? - vCenter Server Appliance (VCSA)
O que há de novo no vSphere 6.5? - vSphere HA
O que há de novo no vSphere 6.5? - vSphere DRS
O que há de novo no vSphere 6.5? - Virtual SAN 6.5

Nuvem VMware na AWS

2016-10-16T23:48:00.000-02:00

Na última quinta-feira (13/10/2016), a VMware e a Amazon anunciaram uma parceria estratégica que permitirá a execução de uma nuvem privada da VMware, com todos os componentes do datacenter definido por software da VMware (vSphere ESXi, VSAN e NSX), como um serviço na nuvem da AWS.

Este serviço, chamado de VMware Cloud on AWS, será oferecido em um formato de serviço pela VMware.

Essa infraestrutura será entregue como se fosse uma nuvem privada dedicada para o cliente VMware, e irá conter hosts ESXi, VSAN e NSX, tudo rodando em um datacenter da AWS. Uma observação importante é que o ESXi estará rodando em hosts físicos (bare-metal), e não como uma máquina virtual, na infraestrutura da Amazon. Isso irá permitir que os clientes executem cargas de trabalho com os mesmos níveis de desempenho, confiabilidade e disponibilidade que já possuem nas instalações locais (on-prem), porém utilizando uma arquitetura na nuvem.

Vale ressaltar que este será um serviço totalmente gerenciado pela VMware. Ou seja, a VMware irá instalar, gerenciar e manter toda a infraestrutura. As operações de rotina, como aplicações de patches ou manutenções de falha de hardware ficarão a cuidado da VMware. Os clientes terão permissões em determinadas coisas, como no vCenter, e estarão aptos a utiliza-lo para a execução de tarefas administrativas, mas algumas ações como atualizações serão fornecidas como parte do serviço pela VMware.

A VMware Cloud on AWS estará dísponivel nos modelos Stand-Alone, Hybrid Cloud ou Cloud-to-Cloud. Nos modelos Hybrid Cloud e Cloud-to-Cloud, o vCenter, através do Enhanced Linked-Mode, permitirá o gerenciamento de ambos os ambientes a partir de uma console única. Veja no exemplo abaixo que há um vCenter Local (On-Prem Data Center) e um vCenter na AWS (CloudProvider_1_CDC), ambos gerenciáveis de uma console centralizada e já conhecida pelos administradores VMware.

Algumas das outras características anunciadas são:

- Possibilidade de migração das VMs entre os ambientes utilizando vMotion, sem nenhuma necessidade de conversão ou alteração, simplesmente um vMotion. É claro que será necessário que toda a parte de rede esteja OK, por isso o NSX será um diferencial neste caso. Ou seja, se você ainda não têm o NSX no seu ambiente, isso não será um empecilho para utilizar o VMware Cloud on AWS, porém algumas funcionalidades do NSX para nuvens híbridas ficarão indisponíveis.

- Possibilidade de crescer facilmente o ambiente hospedado na nuvem AWS. Imagine hoje o trabalho e o tempo que se demora para crescer o seu cluster VMware, se formos considerar desde o processo de compra de novos servidores até o ponto em que estejam prontos para serem adicionados ao cluster. Muitas vezes o negócio não pode esperar todo esse tempo. E mesmo que você seja um administrador precavido e tenha alguns servidores “reservas”, nunca se sabe exatamente o quanto e quando o seu ambiente crescerá, o planejamento de capacidade é um dos maiores desafios enfrentados na TI.

A previsão é que no início de 2017 comece o período de testes (Beta) da solução, e a partir da metade do ano, esteja disponível para todos.

Para saber mais detalhes sobre o anúncio, veja os posts abaixo publicados pela VMware:

VMware and Amazon Web Services Announce Strategic Partnership
VMware Cloud on AWS – A Closer Look

Grupo de Usuários VMware chega a São Paulo

2016-10-06T09:10:00.000-03:00

Na última terça-feira (04/10/2016) ocorreu em São Paulo mais uma edição do VMware vForum Brasil, e na ocasião ocorreu o lançamento oficial de um novo grupo de usuários VMware, o VMUG SP!

Para os que ainda não ouviram falar dos VMUGs (VMware User Groups), trata-se de uma associação independente que já possui mais de 150.000 membros espalhados pelo mundo.

O VMUG SP será liderado pelo Valdecir Carvalho do site Homelaber Brasil (@homelaber), e também pelo Fernando Frediani, que já possui uma grande experiência com o VMUG na Inglaterra. Além deles, o grupo contará também com o apoio de Caio Oliveira (@oliveirac_caio), que é Engenheiro Pré-Vendas na VMware.

Segundo o Valdecir Carvalho: O objetivo principal agora é fazer com que os profissionais de VMware saibam da existência da comunidade VMUG e também as inúmeras vantagens de se tornar um membro do VMUG SP, tais como descontos em treinamentos oficiais da VMware, certificações, livros e acesso a todos os produtos VMware por um ano através do programa VMUG Advantage.

A participação nos eventos organizados pelo VMUG é totalmente gratuita e organizada pela comunidade para a comunidade.

Nas reuniões do VMUG são discutidos assuntos técnicos com palestras de membros da comunidade, apresentação de casos de uso e também contam com a presença de parceiros de negócios da VMware que tem a oportunidade de interagir e estreitar o relacionamento com os profissionais de VMware apresentando seus produtos e serviços.

Para saber mais informações sobre o VMUG e o VMUG São Paulo, acesse o site do grupo em http://vmugsp.com.br.

VMware Virtual SAN 6.2 – Parte 4 – VASA e as Políticas de Armazenamento

2016-09-21T16:00:00.000-03:00

Uma das principais características do VSAN é o fato de trabalhar com o gerenciamento baseado em políticas de armazenamento (SPBM - Storage Policy Based Management) para fazer alocação do espaço para as VMs. Cada uma das máquinas virtuais que são criadas em cima de um datastore VSAN devem possuir pelo menos uma política de armazenamento associada a ela (caso não seja, uma política padrão será utilizada).

As políticas de armazenamento definem quais os requisitos de desempenho e proteção que determinada VM ou até mesmo um determinado disco virtual devem possuir. As políticas determinam como os objetos serão alocados no datastore VSAN a fim de garantir os níveis de serviço desejados.

Antes de aprofundar mais nas políticas de armazenamento do VSAN, é necessário fazer uma breve introdução ao VASA (vSphere Storage APIs for Storage Awareness).

O VASA é uma das APIs de armazenamento (vSphere Storage APIs) fornecidas pela VMware que permitem uma maior integração com os fabricantes de equipamentos de armazenamento. Além do VASA, há também o VAAI (que eu já falei a respeito aqui no blog), o VSA-DP (Data Protection) e mais recentemente foi anunciado o VAIO (vSphere APIs for I/O Filtering).

O VASA é o responsável por integrar o equipamento de armazenamento ao VMware vCenter Server, fornecendo ao vCenter Server informações pertinentes aos volumes apresentados. Para essa integração é necessário a existência de um Storage Provider (VASA provider), e cabe ao fabricante do equipamento de armazenamento fornecer este provider. Em alguns casos esse provider vem embutido na controladora do equipamento de armazenamento e em outros é fornecido através de uma máquina virtual ou como uma aplicação standalone.

Fonte: VMware

É através do VASA que o vCenter Server terá informações sobre as “capacidades” de um determinado volume. Essas “capacidades” variam de acordo com o fabricante e também com o equipamento. Alguns exemplos de “capacidades” apresentadas são:

- Tipo de disco (SSD, SATA, SAS, FC);

- Tipo de proteção (local, remota)

- Tipo de volume (thin, thick)

- Dedup;

Com base nessas capacidades é então possível criar perfis de armazenamento (Storage Profiles) no vCenter Server e associar a uma VM ou a um disco virtual afim de garantir que o nível de serviço desejado seja sempre atingido e de maneira automática. Essa automatização é uma das principais razões para essa mudança na forma de alocar os recursos de armazenamento, uma vez que facilita seu gerenciamento ao mesmo tempo que garante que os recursos entregues estarão de acordo com os requisitos.

Voltando ao VMware VSAN, como foi dito que ele faz uso de políticas de armazenamento, também precisará de um VASA Provider para apresentar ao vCenter Server as capacidades disponíveis no datastore VSAN. No caso do VSAN, o VASA Provider já vem embutido no próprio host ESXi, e é habilitado na hora da criação do cluster VSAN. Todos os hosts ESXi em um cluster VSAN poderão servir como um Storage Provider, porém apenas um ficará ativo, os demais ficarão como stand-by.

Dentre as capacidades apresentadas pelo VASA Provider do VSAN para o vCenter Server estão:

- Number of disk stripes per object

- Flash read cache reservation

- Failures to tolerate

- Fault tolerance method

- IOPS limit for object (QoS)

- Disable object checksum

- Force provisioning

- Object space reservation

Number of disk stripes per object

Também é conhecido como Stripe Width, define o número mínimo de discos de capacidade que serão utilizados para armazenar um determinado objeto. Um valor superior a 1 irá prover um melhor desempenho, mas também consumirá uma maior quantidade de recursos. O valor padrão é 1 (também é o mínimo) e o valor máximo é 12.

Flash read cache reservation

Como sabemos todo cluster VSAN possui uma área em flash utilizada para cache de leitura (70%) e para buffer de escrita (30%). Esse cache de leitura é compartilhado entre todos os objetos do datastore VSAN com base na demanda. É possível com esta opção reservar uma área desse cache para um ou todos os discos virtuais (vmdk) de uma máquina virtual. A reserva é feita com base em uma porcentagem da área do disco virtual, por exemplo se você deseja reservar 10% do disco virtual de uma VM, e esse disco tiver um tamanho total de 100GB, então 10GB do cache de leitura ficarão reservados para esse vmdk. Essa opção só é pertinente para clusters com configurações híbridas, uma vez que na configuração all-flash não há cache para leitura. O valor padrão é 0% e o valor máximo é 100%.

Failures to tolerate

Esta capacidade, também chamada de FTT, está relacionada com a disponibilidade dos objetos, e pode ser aplicada em uma VM ou em um VMDK específico. Esta opção define o número de hosts e discos que podem falhar e ainda assim manter acessível um objeto. Dependendo dos requisitos de disponibilidade da máquina virtual, a configuração da política de armazenamento aplicada a esta VM pode gerar um consumo de capacidade até 4x maior do que o espaço total da máquina virtual.

Para cada “n” falhas a serem aceitas, “n+1” cópias dos objetos são criadas e “2n+1” hosts contribuindo com área para armazenamento são necessários. A configuração padrão para esta opção é 1, ou seja, mesmo que uma VM seja criada sem que uma política tenha sido associada, ainda assim haverá uma cópia de cada objeto desta VM. O valor máximo para o FTT é 3.

Fault tolerance method

O Fault tolerance method ou FTM, especifica qual será o método utilizado na proteção dos objetos no cluster VSAN. Até a versão VSAN 6.2 só havia uma forma de proteção, que era através do RAID-1 (mirroring). A partir do VSAN 6.2 foi adicionado um novo método de proteção, conhecido como RAID 5/6 (Erasure Coding), porém disponível apenas nas configurações All-Flash.

IOPS limit for object (QoS)

Com essa configuração é possível limitar a quantidade de IOPS por VM/VMDK. Os IOPS são calculados com base em todas as operações na VM/VMDK (leitura e escrita), incluindo snapshot. Essa opção pode ser usada para impedir que determinada carga de trabalho em uma VM venha a impactar outras VMs.

Disable object checksum

O VSAN faz uma verificação fim-a-fim para garantir a integridade dos dados confirmando que cada cópia de um arquivo é exatamente igual ao arquivo original. O sistema valida os dados durante as operações de leitura/escrita, e se algum erro for detectado o VSAN repara os dados ou reporta um erro. Essa verificação, chamada de Object Checksum, é habilitada por padrão em todos os objetos que residem em um datastore VSAN (v3). Com a opção DisableObjectChecksum é possível desabilitar essa verificação também por objetos através da política de armazenamento.

Force provisioning

Uma política com a opção ForceProvisioning configurada como Yes, permite que os objetos sejam criados mesmo que não seja possível atender as configurações de FailuresToTolerate(FTT), NumberOfDiskStripesPerObject (SW) and FlashReadCacheReservation (FRCR). O VSAN vai tentar alocar os objetos atendendo a todos os requisitos especificados na política de armazenamento, caso não consiga, será utilizada uma alocação simplificada usando os requisitos mínimos (FTT=0, SW=1, FRCR=0). Uma consideração importante é que assim que houver recursos suficientes para atender aos requisitos iniciais, o cluster VSAN automaticamente consumirá estes recursos.

Object space reservation

Por padrão todos os objetos alocados em um datastore VSAN são criados como ThinProvisioned. A opção Object space reservation permite especificar uma porcentagem do tamanho da VM/VMDK a ser reservada (thick provisioned) quando o objeto for criado. Por exemplo, se uma VM for criada com um disco de 100GB, e uma política de armazenamento com uma configuração de 50% na opção Object space reservation for associada a essa VM, então 50GB estarão reservados no datastore VSAN e os outros 50GB irão ser alocados a medida que forem sendo consumidos. O valor padrão é 0% e o valor máximo é 100%.

Para configurar uma nova política de armazenamento ou verificar as políticas já existentes, pelo vSphere Web Client, clique em Home >> Policies and Profiles >> VM Storage Policies.

A imagem abaixo mostra as configurações da política de armazenamento padrão de um cluster VSAN.

Outros posts da série VMware Virtual SAN 6.2:

VMware Virtual SAN 6.2 – Parte 1 – Introdução

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

VMware Virtual SAN 6.2 – Parte 4 – VASA e as Políticas de Armazenamento

Novos Labs disponíveis no VMware Hands-on Labs

2016-09-13T13:35:00.000-03:00

A VMware disponibilizou ontem (12/09/2016) uma série de novos labs na plataforma VMware Hands-on Labs. Se você ainda não conhece a VMware HOL, veja esse post publicado em 2014 aqui no blog.

Os labs lançados ontem foram disponilizados primeiramente no evento VMworld 2016, que acontenceu há duas semanas (de 28/08 a 01/09) em Las Vegas, e agora foram disponibilizados para todos.

Nem todos os LABs foram disponibilizados ainda, alguns serão disponibilizados somente após a VMworld 2016 européia, que acontecerá entre 17/10 e 20/10 em Barcelona.

Abaixo você confere uma lista de todos os novos labs que já estão disponíveis com o respectivo link para iniciar o lab. Aproveitem!!

HOL-1701-USE-1 Introduction to the vSphere Optimization Assessment

HOL-1701-USE-2 vRealize Operations and vRealize Business: Optimize Compute Utilization

HOL-1701-USE-3 vRealize Operations and vRealize Log Insight: Ensure Performance and Availability

HOL-1701-USE-4 vRealize Operations with Management Packs: Monitor Heterogeneous Data Centers & Hybrid Clouds

HOL-1701-CHG-5 vRealize Operations Application Monitoring: Challenge Lab

HOL-1703-SDC-1 VMware NSX: Introduction and Feature Tour

HOL-1703-USE-2 VMware NSX: Distributed Firewall with Micro-Segmentation

HOL-1703-USE-3 VMware NSX: Operations and Visibility

HOL-1706-SDC-1 Cloud Management Platform: Integrate vRealize and NSX

HOL-1706-SDC-3 Secure Your Software Defined Data Center

HOL-1706-USE-4 vRealize Operations: Advanced Use Cases

HOL-1706-SDC-5 VMware Cloud Foundation Fundamentals

HOL-1706-SDC-6 Guide to SDDC: VMware Validated Designs

HOL-1706-USE-7 SAP on VMware SDDC: Design and Management Overview

HOL-1708-SDC-1 Virtual SAN 6.2 from A to Z

HOL-1708-SDC-2 Virtual Volumes and Storage Policy Based Management

HOL-1708-CHG-3 Virtual SAN 6.2: Challenge Lab

HOL-1710-SDC-1 Virtualization 101: vSphere with Operations Management

HOL-1710-USE-2 vSphere with Operations Management: Use Cases

HOL-1710-SDC-3 vSphere with Operations Management: Product Deep Dive

HOL-1710-USE-4 vSphere with Operations Management: Advanced Use Cases

HOL-1710-SDC-5 Automate and Develop vSphere easier with a Technical Preview of vSphere Automation API and SDKs

HOL-1723-SDC-1 Palo Alto Networks Next-Generation Security Platform with VMware

HOL-1725-SDC-1 VMware NSX Advanced Consumption

HOL-1725-USE-2 VMware NSX Multi-Site DR with SRM

HOL-1729-SDC-1 Introduction to vRealize Network Insight

HOL-1751-MBL-1 Introduction to Horizon 7: Virtual Desktop and Apps

HOL-1751-MBL-2 Horizon 7: Application Delivery

HOL-1751-MBL-3 Horizon 7 Suite: Extend Your Value

HOL-1751-MBL-4 Horizon 7: Architecture and Performance

HOL-1751-MBL-5 Horizon 7: End to End Security

HOL-1751-MBL-6 Horizon 7 Advanced Concepts

HOL-1755-MBL-1 Horizon FLEX from A to Z

HOL-1756-MBL-1 Horizon Air from A to Z

HOL-1757-MBL-1 Introduction to VMware AirWatch

HOL-1757-MBL-2 Advanced VMware AirWatch

HOL-1757-MBL-3 VMware AirWatch: Workspace ONE, Single Sign-on and VMware Identity Manager

HOL-1757-MBL-4 VMware AirWatch: Email Integration with Boxer

HOL-1757-MBL-5 VMware AirWatch: Mobile App Management and App Development

HOL-1757-MBL-6 VMware AirWatch Technology Partner Integration

HOL-1782-HBD-1 VMware vCloud Air – Data Center Extension

Fonte:
New 2017 VMware Hands-on Labs Released!
Transitioning to the 2017 Hands-on Labs

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

2016-08-25T11:41:00.000-03:00

Para entender melhor toda a arquitetura do VMware VSAN, precisamos primeiramente entender e conhecer sobre as principais “peças” que fazem parte de um host VSAN e consequentemente contribuem na formação do cluster.

Existem dois tipos de “peças” nessa estrutura, as físicas e as lógicas.

Estrutura Física

- Controladoras de disco
Uma das peças mais importantes em um host VSAN é a controladora de disco (SAS, SATA ou RAID Controller) presente neste host. A primeira recomendação é garantir que a controladora a ser utilizada conste no VCG (VMware Compatibility Guide), isso garante que essa controladora é suportada pela VMware.

É possível, e até recomendado, que haja mais de uma controladora de disco por host, dessa forma é possível diminuir o domínio de falha, dividindo os discos entre controladoras, e ainda conseguir algum ganho de desempenho. Lembrando que algumas controladoras suportam no máximo 16 discos, portanto para utilizar mais discos será necessário mais controladoras.

Dois pontos importantes a serem considerados na escolha de uma controladora de disco são a Queue Depth e a forma que os discos são apresentados (RAID-0 ou Pass-through).

No caso da Queue Depth o recomendado é utilizar controladoras que possuam uma queue maior do que 256, uma vez que valores menores do que este podem impactar no desempenho das VMs, durante algumas operações do cluster (rebuild por exemplo).

Sobre a forma como os discos são apresentados ao ESXi, existem duas formas mais comuns nessas controladoras, RAID-0 e Pass-through. O recomendado é utilizar o Pass-through sempre que possível, uma vez que dessa forma o disco é apresentado diretamente para o ESXi e o gerenciamento é todo feito pelo VSAN. No RAID-0, cada disco é configurado como um volume RAID-0 e então apresentado ao ESXi, o que implica em algumas configurações manuais a serem feitas na hora de substituir um disco por exemplo.

- Dispositivo Flash
Outra peça fundamental no host VSAN é a presença de pelo menos um dispositivo Flash, este pode ser um disco SSD (SATA/SAS), uma placa PCIe ou então um dispositivo NVMe. Esse dispositivo flash será utilizado para buffer de escrita (30%) e cache de leitura (70%) nas configurações híbridas, e 100% como buffer de escrita nas configurações All-flash. A capacidade deste dispositivo flash não é considerada na capacidade total de armazenamento do datastore VSAN.

- Discos magnéticos
Assim como o dispositvo flash, é essencial a presença de pelo menos um disco a ser utilizado para área de armazenamento (nas configurações híbridas são discos magnéticos, e nas configurações all-flash são discos SSD). Este pode ser SATA, SAS ou NL-SAS, e geralmente é referenciado nas documentações sobre VSAN apenas como HDD (numa configuração all-flash, os dispositivos flash dedicado ao armazenamento também são chamados de HDD). Os discos HDD possuem essencialmente duas funções no cluster VSAN, garantir a capacidade necessária para o armazenamento dos objetos e também atender às políticas de armazenamento das VMs no que diz respeito ao stripe width.

Fonte: VMware

- Interface de rede
Para a formação de um cluster VSAN é necessário que cada host deste cluster possua ao menos uma interface de rede. É claro que o ideal seja a presença de mais de uma interface, visando a alta disponibilidade e também o desempenho através do balanceamento de carga. Num cluster VSAN são suportadas interfaces de 1Gb e de 10Gb, sendo que o recomendado pela VMware é que sejam utilizadas interfaces de 10Gb (nas configurações All-Flash somente interfaces de 10Gb são suportadas). Caso seja utilizada uma interface de 1Gb, o recomendado é que essa seja dedicada ao tráfego do VSAN. Com uma interface de 10Gb, o link pode ser compartilhado com outros tipos de tráfego (vMotion, VMs e etc).

Estrutura Lógica

Agora que já conhecemos a estrutura física de um host VSAN, vamos falar sobre como essas partes são abstraídas e transformadas em estruturas lógicas em um cluster VSAN.

- Disk Groups
Os disk groups são uma construção lógica composta de um dispositivo flash e até 7 discos de capacidade. Numa configuração híbrida, um disk group será a combinação de um dispositivo flash para cache e um ou mais discos magnéticos para prover capacidade. No caso de uma configuração All-flash, o disk group será composto de um dispositivo flash para cache e um ou mais dispositivos flashes que serão utilizados para capacidade. Não é possível mistrurar disk groups híbridos com disk groups all-flash em um mesmo cluster.

A tabela abaixo lista os limites mínimo e máximo de disk groups, dispositivos flash e discos magnéticos.

- VSAN Datastore
O VSAN datastore é a área criada da união de todos os disk groups de todos os hosts que compõem o cluster VSAN, lembrando que somente a área dos discos HDD é considerada. Os dispositivos flash utilizados para cache não entram nessa soma. O VSAN datastore é compartilhado entre todos os hosts que compõem o cluster. Somente um VSAN datastore é criado por cluster.

Fonte: VMware

- Objetos

Talvez uma das maiores diferenças entre o armazenamento das VMs num VSAN datastore e num datastore “tradicional” seja o conceito de objetos. Cada máquina virtual armazenada em um VSAN datastore é formada por um conjunto de objetos. Por exemplo, o VMDK (disco virtual da VM) é um objeto, os discos .delta dos snapshots são um objeto, o arquivo de swap da VM é um objeto e etc.

Além dos objetos citados acima, existem alguns outros. Um em especial que merece atenção é o “namespace directory”ou Virtual Machine home. Todos os arquivos da máquina virtual, com exceção dos três objetos listados anteriormente (VMDK, snapshot delta e swap file) residem nesta área denominada “virtual machine namespace” no cluster VSAN. Entre os arquivos que estão nesta área estão o arquivos .vmx, os arquivos de log, os arquivos de descrição dos discos virtuais.

Fonte: VMware

- Componentes

Cada um dos objetos armazenados em um VSAN datastore é composto por um conjunto de componentes. Esses componentes são determinados com base na política de armazenamento associada ao objeto. Por exemplo, se uma VM for criada e a ela associada uma política de armazenamento para tolerar a falha de até 1 host do cluster, então cada um dos objetos terão duas replicas, e cada uma dessas replica é considerada um componente. Outro exemplo, se uma VM for criada utilizando uma política de armazenamento que contenha um stripe width de 2, então um RAID-0 será criado para aquele objeto e cada parte será considerada um componente.

Fonte: VMware

Para cada objeto há ainda um componente chamado Witness. O Witness não contêm nenhum dado efetivo da máquina virtual, apenas metadados. Esse componente é utilizado para decidir qual componente a ser utilizado em situações que envolvam a disponibilidade dos objetos, contribuindo para evitar situações de split-brain.

É importante saber que existe um limite no número de componentes suportados em um cluster VSAN, para o VSAN 5.5 o limite é de 3.000 componentes por host, a partir do VSAN 6.0 esse número subiu para 9.000 componentes por host.

Outros posts da série VMware Virtual SAN 6.2:

VMware Virtual SAN 6.2 – Parte 1 – Introdução

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

2016-08-17T10:58:00.002-03:00

Antes de decidir por habilitar o VMware VSAN no seu ambiente, é importante saber que o VSAN possui um licenciamento separado do vSphere. Ou seja, mesmo que a sua licença de vSphere seja a mais top, no caso a Enterprise Plus, ainda assim será necessário adquirir as licenças do VMware Virtual SAN.

Assim como no licenciamento do vSphere, existem várias edições (tipos) de licença e cada uma possui features diferentes. No caso do VSAN existem as seguintes edições: Standard, Advanced, Enterprise e ROBO (Remote Office/Branch Office). A tabela abaixo mostra cada uma das features que estão disponíveis em cada uma das edições:

A licença Advanced possui todos os features da licença Standard mais as features de Dedup e Compressão, e RAID 5/6 Erasure Coding. É importante ressaltar que essas features só se aplicam para configurações All-Flash, ou seja, mesmo que possua a licença Advanced, se o seu cluster VSAN for híbrido (SSD + HDD), estas features não poderão ser utilizadas.

A licença Enterprise é nova e foi lançada juntamente com o VMware Virtual SAN 6.2. Além de todas as features inclusas nas licenças Standard e Advanced, ainda possui o suporte para Stretched Cluster e QoS para limitar a quantidade de IOPS por objetos.

As licenças Standard, Advanced e Enterprise são licenciadas no modelo per-CPU (socket). Por exemplo, se você possui um VSAN cluster com 4 hosts e cada um deles com 2 CPUs, será necessário aplicar uma licença para o cluster VSAN com uma capacidade mínima para 8 CPUs. A quantidade de Cores/CPU é indiferente.

As licenças do tipo ROBO (Remote Office/Branch Office) são um tipo de licença específica para ambientes remotos. Do ponto de vista da VMware, um escritório remoto ou filial é uma localidade física remota ao datacenter principal. A licença ROBO é fornecida no modelo per-VM e é vendido em pacotes de 25 VMs. É possível utilizar as 25 licenças em um único escritório remoto ou usar por exemplo 5 licenças em 5 escritórios remotos distintos.

Existe ainda um outro tipo de licença que não aparece na tabela acima, que é a licença Virtual SAN for Desktop. Neste caso a licença é exclusiva para ambientes que rodarão apenas desktops virtuais. As licenças Virtual SAN for Desktop também estão disponíveis nas edições Standard, Advanced e Enterprise, porém elas são fornecidas nos modelos per-named user ou per-concurrent user (CCU) e agrupadas em pacotes de 10 ou 100 licenças. Uma licença Virtual SAN Advanced já está inclusa nas licenças do VMware Horizon (Advanced ou Enterprise).

Outros posts da série VMware Virtual SAN 6.2:

VMware Virtual SAN 6.2 – Parte 1 – Introdução

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

VMware Virtual SAN 6.2 – Parte 1 – Introdução

2016-08-10T22:27:00.000-03:00

Há algum tempo fiz alguns posts (post 1, post 2) sobre o VMware Virtual SAN (VSAN), a solução de armazenamento definido por software (SDS – Software Defined Sotrage) da VMware. Já faz um bom tempo que estes posts foram escritos e de lá pra cá muita água já passou por debaixo dessa ponte. Por isso resolvi escrever uma série de posts para tratar do Virtual SAN, uma vez que essa é uma das principais soluções quando falamos de infraestrutura hiperconvergente, que sem dúvida é a nova tendência do mercado e logo mais deve explodir também aqui no Brasil.

Software Defined Data Center

Provavelmente você já ouviu falar do Software Defined Data Center (Datacenter definido por software), e deve se perguntar o que exatamente é isso e como funciona. Resumidamente o SDDC é uma evolução da tecnologia de virtualização para outras áreas da infraestrutura de um datacenter (rede, armazenamento, segurança) permitindo a criação de camadas de abstração dos recursos de infraestrutura, automatizando todo o fornecimento e o gerenciamento desses recursos através de software.

Basicamente são 3 os pilares de um SDDC:

- Virtualização de servidores;
- Armazenamento definido por software (Software Defined Storage - SDS);
- Rede definida por software (Software Defined Network – SDN);

Como você já deve imaginar o VMware Virtual SAN se encaixa no conceito de SDS.

Software Defined Storage

Há algum tempo atrás a camada de armazenamento principal de um servidor era interna, porém devido ao aumento na demanda por capacidade, proteção e até mesmo um gerenciamento mais centralizado, surgiu a necessidade de criar sistemas mais robustos para gerenciar e manter as áreas de armazenamento. Diante disso foram criadas as redes de armazenamento SAN (Storage Area Network) e NAS (Network Attached Storage), compostas de uma rede Fiber Channel ou Ethernet e de equipamentos dedicados para o armazenamento de dados (Storage Arrays).

Com o passar do tempo, algumas organizações perceberam que essas redes de armazenamento estavam se tornando mais complexas com relação ao gerenciamento, à capacidade de expansão e também com relação ao custo. Então por volta de 2013 surgiu um “novo” conceito na arquitetura de soluções de armazenamento, iniciando um novo ciclo nessa área, retornando a camada de armazenamento para dentro do servidor, mas dessa vez sendo gerenciado por um software mais inteligente e capaz de fornecer serviços de dados (dedup, compressão, snaps e etc...).

De acordo com a SNIA (Storage Networking Industry Association), SDS pode ser definido como:

“Virtualized storage with a service management interface. SDS includes pools of storage with data service characteristics that may be applied to meet the requirements specified through the service management interface.”

Uma das principais características do SDS é a possibilidade de se utilizar um hardware independente, desde que este atenda aos requisitos da solução desejada. Atualmente são várias as soluções de SDS disponíveis no mercado, cada uma com as suas características. Além do VMware Virtual SAN, outros exemplos de soluções de armazenamento baseadas em software são o EMC Scale IO, o Microsoft Windows Server Storage Space e o Red Hat Gluster.

Agora que já temos um entendimentos dos conceitos de SDDC e também de SDS, vamos conhecer mais sobre o VMware Virtual SAN?!

VMware Virtual SAN 6.2

O VMware VSAN é uma solução de armazenamento distribuído baseada em software que foi construída diretamente no kernel do ESXi. Diferentemente de outras soluções de armazenamento baseadas em software, o VSAN não necessita de um appliance virtual (VM) rodando em cima do hypervisor, ela está diretamente embutida em seu kernel. Além disso, todo o seu gerenciamento é feito pelo próprio vSphere Web Client, oferecendo assim uma interface única de gerência para seu ambiente.

Basicamente um cluster VMware VSAN utiliza 2 ou mais hosts físicos que possuem uma combinação de discos magnéticos e discos flash (configuração híbrida) ou somente discos flash (configuração all-flash), contribuindo com o cache e a capacidade de armazenamento, para fornecer um datastore distribuído.

Dentre as principais características da VSAN estão:

Eficiência no armazenamento: o VSAN fornece um conjunto avançado de características de armazenamento, incluindo desduplicação, compressão e erasure coding (RAID 5/6), capaz de entregar mais área de armazenamento do que de fato existe fisicamente, a um custo muito mais baixo.

Escalabilidade: o VSAN possui uma arquitetura distribuída que permite que o cluster cresça a medida que for necessário, de forma não disruptiva a partir de 2 até 64 hosts por cluster. É possível crescer a parte de desempenho e capacidade em conjunto, adicionando um novo host ao cluster (conhecido como scale-out) ou crescer a parte de desempenho ou capacidade independentemente, adicionando novos discos aos hosts (conhecido como scale-up).

Gerenciamento e Integração: o VSAN não exige que nenhum software adicional seja instalado. Todo o gerenciamento e monitoramento pode ser feito pelo vSphere Web Client, além disso se integra completamente com as principais funcionalidades do vSphere, incluíndo vMotion, HA/DRS e Fault Tolerance.

Automação: através de um modelo de gerenciamento baseado em políticas, permite que o provisionamento do armazenamento e dos níveis de serviços desejados (proteção, disponibilidade, desempenho) para as VMs sejam automatizados.

A maneira mais rápida, prática e segura para montar um cluster VMware VSAN e através da aquisição de uma solução hiperconvergente que já vem preparada e previamente configurada com o VSAN , como o EMC VxRail, ou então através da aquisição de algum Ready Node já certificado pela VMware. Neste link é possível escolher uma configuração desejada e verificar quais o Ready Nodes disponíveis com aquela configuração. Existem Ready Nodes dos principais fornecedores de hardware, entre eles DELL, HP, Hitachi, Lenovo e etc...

Por enquanto é isso! No próximo post vou falar sobre o licenciamento do VMware VSAN.

Outros posts da série VMware Virtual SAN 6.2:

VMware Virtual SAN 6.2 – Parte 1 – Introdução

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

Limitando o número de conexões simultâneas na console de uma VM

2016-07-07T17:11:00.000-03:00

É comum em alguns ambientes que o acesso ao vCenter seja compartilhado entre vários administradores e até mesmo entre áreas distintas. Uma das recomendações de segurança que a VMware geralmente propõe (pelo menos é o que está no Security Guide) é que o acesso a Console da VM seja minimizado ao máximo, uma vez que o acesso a console se assemelha ao acesso ao monitor de uma máquina física, com teclado e mouse.

Com acesso à console um usuário pode executar ações que fogem ao controle do ambiente virtual, uma vez que as ações estarão sendo executadas de dentro da VM.

Uma outra razão para limitar o número de conexões permitidas à console de uma VM, é o fato de uma outra pessoa poder observar as ações que um administrador estiver executando na máquina virtual, podendo gerar algum incidente de segurança, já que informações sensíveis podem estar sendo exibidas na tela.

Por exemplo, na imagem abaixo é possível identificar que além desta sessão, existem outras 3 sessões abertas nesta console, porém não é possível identificar facilmente quem está visualizando a console junto com você.

Por isso o mais recomendado é que o acesso seja feito, sempre que possível, utilizando as ferramentas nativas do sistema operacional da VM, por exemplo SSH e RDP.

Por padrão não há limites no número de conexões simultâneas na console de uma VM, mas existem formas de alterar esse comportamento através das configurações avançadas de uma máquina virtual.

Pelo vSphere Web Client é possível configurar essa opção clicando em: Edit Settings à VM Options à VMware Remote Console Options à Maximum number of sessions

Para alterar pelo vSphere Web Client é necessário que a VM esteja desligada.

Outra forma de alterar é utilizando o PowerCLI ou o vCLI para alterar o parâmetro “RemoteDisplay.maxConnections”, dessa forma além de permitir que a mudança seja feita com a VM ligada, ainda oferece a possibilidade de automatizar a mudança em várias VMs de uma única vez através de scripts.

Abaixo disponibilizo um exemplo de script de PowerCLI para realizar a mudança em todas as VMs de um determinado cluster.

#Conexão com o Virtual Center
Connect-VIServer -Server [vcenter-address] –User [vcenter-user] -Password [user-password]
$VMCluster = Read-Host "Digite o nome do cluster:"
foreach($vm in Get-Cluster $VMCluster | Get-VM ){
#Checa se a opção já está configurada, caso negativo faz a configuração
if (!(get-advancedsetting -entity $vm -Name "RemoteDisplay.maxConnections")){
$vm|New-AdvancedSetting -Name "RemoteDisplay.maxConnections" -Value "1" -Confirm:$false}
else {
#Se a opção já estiver configurada, a linha abaixo faz a alteração
get-advancedsetting -entity $vm -Name "RemoteDisplay.maxConnections" | SetAdvancedSetting -Value "1" -Confirm:$false} }

Após a alteração, qualquer tentativa de conexão na console da VM, tanto pelo vSphere Web Client como pelo vSphere Client (Windows), falhará com a mensagem de erro abaixo:

EMC/VMware apresentam o novo VCE VxRail

2016-02-17T17:17:00.001-02:00

Ontem foi anunciado pela EMC/VMware o lançamento de um novo appliance de infraestrutura hiper-convergente, chamado VxRail. O VxRail é produto que faltava no portfólio de infraestrutura convergente da VCE, que já possuía os produtos VBlock, VxBlock e VxRack.

Quem acompanha o blog deve se lembrar que há cerca de um ano atrás fiz um post falando sobre o VSPEX Blue, que também é um appliance HCI (Hyper-Converged Infrastructure) ofertado pela EMC. O VSPEX Blue foi a primeira investida da EMC no mercado de HCI, e por isso deixava a desejar em algumas questões, quando comparado com outros produtos ofertados no mercado. Por exemplo:

Tamanho inicial e escalabilidade – uma das principais limitações no VSPEX Blue era a falta de flexibilidade no tamanho inicial da primeira instalação e também a falta de granularidade na hora de expandir uma instalação existente. Ambas essas características se mostraram essenciais para usuários de plataformas HCI. Alguns concorrentes, por exemplo, permitem que os usuários iniciem com uma configuração de 3 nós e cresçam 1 nó por vez. No VSPEX Blue é necessário iniciar com no mínimo 4 nós, e a expansão também deve ser feita com 4 nós.

Limitação na oferta de Data Services – outra limitação do VSPEX Blue era a falta de serviços no armazenamento de dados, como por exemplo: Desduplicação e Compressão. Estes serviços podem oferecer uma economia considerável na quantidade de GB/TB necessários para o armazenamento dos dados.

O VxRail foi desenvolvido em conjunto pela EMC e pela VMware e oferece um produto exclusivo, completamente integrado, pré-configurado e testado, capaz de subir de maneira rápida e fácil um ambiente VMware totalmente virtualizado, tudo definido por software.

A arquitetura do VxRail segue o modelo já conhecido de HCIA, ou seja, uma “caixa”de 2Us composta por até 4 nós (nodes), também conhecida como 2U4N. Sendo que cada um dos nós possui seus próprios processadores, RAM e discos.

Visão Frontal

Visão Traseira

Um detalhe importante é que essas são as disposições iniciais, mas futuramente pode ser que sejam disponibilizadas novas formas de configuração, por exemplo um appliance com 2 nós (2U2N).

Outro ponto positivo para o VxRail é a quantidade de configurações com relação a processamento e armazenamento ofertadas:

Modelos híbridos: combina custos e desempenho através de configurações que comportam discos HDD e SSD.

Modelos All-Flash: Máximo desempenho para aplicações e cargas de trabalho de missão crítica que exigem uma baixa latência.

Alguns destes modelos estarão disponíveis de imediato, enquanto outros só estarão disponíveis a partir do Q2/2016.

Outra característica importante do VxRail é a possibilidade de começar pequeno e ir crescendo na medida em que a demanda for aumentando, com a possibilidade de crescer em um único nó. Isso permite que as organizações invistam apenas o necessário naquele momento, evitando com isso o desperdício de recursos.

Com relação a essa escalabilidade, é possível crescer até o limite de 16 appliances, totalizando 64 nós de processamento, e dependendo da configuração podendo chegar a até 1.2 PB de armazenamento all-flash.

Sobre a parte de software incluída no VxRail, a base de tudo é o VMware vSphere (incluindo vSphere HA, vMotion & DRS por padrão) com Virtual SAN (VSAN). Inicialmente será fornecido o Virtual SAN 6.1, mas a partir do Q2 passará a ser fornecido com o VSAN 6.2, contando com um upgrade não-disruptivo para que estiver na versão 6.1.

Consequentemente, funcionalidades como desduplicação, compressão e erasure coding estarão disponíveis a partir do Q2 (modelos com o VSAN 6.2) nas configurações de appliance com modelos All-Flash.

Além disso, uma série de softwares EMC estão inclusos na solução, por exemplo:

VxRail Manager – Interface única para gerenciamento centralizado da solução (incluindo VMware vCenter e VMware Log Insight).

RecoverPoint for VMs (RP4VM’s) – licenciado para até 15 VMs por appliance, mas nada impede que seja adquiridas licenças adicionais se necessário.

EMC CloudArray – licenciado para até 10TB por appliance. Permite expandir a capacidade de armazenamento do appliance utilizando armazenamento na nuvem.

Lá fora o mercado para appliances de infraestrura hiper-convergente parece estar indo muito bem, não é atoa que vemos uma grande quantidade de soluções sendo ofertadas. Aqui no Brasil ainda nao vejo um mercado muito aquecido nesse sentido, mas é certo que mais cedo ou mais tarde as coisas comecem a mudar...

Saiba mais em ...

Página Oficial do VCE VxRail

ESXi Embedded Host Client – Acessando o ESXi pelo browser

2015-11-16T13:22:00.001-02:00

Há cerca de 3 meses o VMwareLabs, site no qual os engenheiros da VMware costumam compartilhar algumas Flings, disponibilizou uma fling chamada ESXi Embedded Host Client.

Essa fling é uma interface gráfica para o host ESXi e foi toda desenvolvida em HTML5 e JavaScript, e pode representar uma prévia do que pode vir a ser o vSphere Web Client futuramente.

Como se trata de uma fling não há nenhuma garantia de que a mesma se torne algo oficial, mas pelo feedback positivo e o sucesso que tem feito na comunidade VMware, é provável que nos próximos lançamentos o ESXi já venha com essa interface embutidade. Por enquanto também não há nenhum tipo de suporte, em caso de problemas/bugs a única alternativa é deixar uma mensagem na página da própria ferramenta, e aguardar que o engenheiro responsável responda.

No momento as seguintes operações estão disponíveis com a ferramenta:

· VM operations (Power on, off, reset, suspend, etc).
· Creating a new VM, from scratch or from OVF/OVA (limited OVA support)
· Configuring NTP on a host
· Displaying summaries, events, tasks and notifications/alerts
· Providing a console to VMs
· Configuring host networking
· Configuring host advanced settings
· Configuring host services

A ferramenta está disponível no format .vib, para ser instalada diretamente no host ESXi, e também como .zip (offline bundle), para ser utilizada junto com o VUM (vSphere Update Manager).

O download e as instruções de instalação estão na página da solução.

Lab VMware na nuvem (AWS ou Google Cloud)

2015-04-22T23:41:00.000-03:00

Que tal a possibilidade de montar o seu ambiente de lab em uma nuvem pública da Amazon (AWS) ou Google (GCP)?! Parece interessante né?! Pois essa é a nova oferta da startup israelense Ravello Systems.

Basicamente a Ravello Systems desenvolveu o seu próprio hypervisor (baseado no KVM), chamado HVX. O HVX roda em cima de máquinas virtuais nas nuvens da AWS ou Google Cloud. Inicialmente a tecnologia permitia a importação de máquinas virtuais VMware e KVM, sem a necessidade de qualquer modificação nas VMs, oferecendo a oportunidade de reproduzir um ambiente de produção na nuvem, atendendo a uma série de casos de uso:

- Desenvolvimento/testes;

- Demonstrações;

- Treinamentos e etc.

Na última semana, a Ravello Systems anunciou (ainda em versão beta) a implementação de uma nova funcionalidade no HVX que emula as features Intel-VT/AMD-V, permitindo assim que hypervisors como ESXi e KVM possam ser instalados em máquinas virtuais rodando em cima do HVX, que por sua vez está rodando em cima de uma VM na nuvem. J

Por se tratar de uma funcionalidade ainda em versão beta, existem algumas limitações:

- Não há suporte para a interface de rede VMXNET3 no ESXi virtual. Consequentemente também não é possível utilizar o SMP-FT, pois requer uma rede de 10Gb (vmxnet3);

- Não há suporte para o VCSA 6.0 por conta de limitações de controladoras de disco e no suporte ao formato OVF;

Aqueles que tiverem interesse podem se cadastrar para testar a solução por um período de 14 dias e com algumas restrições de capacidade:

- Versions supported: ESXi 5.5 and ESXi 6.0

- Maximum number of CPUs per ESXi host: 4 CPUs

- Maximum memory per ESXi host: 32GB

- Maximum number of guest VMs per ESXi host: 4

- Maximum vCPU per guest VM: 2 vCPUs

- Maximum memory per guest VM: 8GB RAM

- Maximum number of ESXi hosts in an environment: 250

Como eu estava sem hardware disponível para montar meu lab com o novo vSphere ESXi 6.0, resolvi testar a plataforma da Ravello Systems.

O primeiro passo foi me cadastrar no site da Ravello Systems. Após o cadastro recebi um email com todas as informações de como instalar o ESXi na plataforma.

São várias as configurações necessárias, mas com os artigos contendo os passo a passos publicados no blog da empresa, foi bem tranquilo para colocar o lab no ar.

- Howto install ESXi on AWS or Google cloud

- Howto set up a vCenter appliance on AWS or Google cloud

- Howto create an ESXi/ vSphere cluster on AWS or Google cloud

Abaixo você confere o ambiente que eu criei:

AD/DNS – 2vCPU, 2GB RAM, 50GB HD

NFS – 1vCPU, 2GB RAM, 132GB HD

vCenter – 2vCPU, 8GB RAM, 52GB HD

3 ESXi – 4vCPU, 7GB RAM, 20GB HD (cada)

Para se ter uma idéia um ambiente como este que eu montei, após o período de trial, me custaria em torno de $2,64/hr.

O resultado final me agradou bastante. A interface é bem intuitiva e o desempenho atende perfeitamente o necessário para um ambiente de lab. Além disso, a possibilidade de utilizar templates (VM library) e blueprints (que permite o deploy de um ambiente completo) facilita e agiliza a criação/reprodução de novos ambientes.

Considerações importantes antes de instalar VMware vCenter Server 6.0

2015-03-24T10:21:00.000-03:00

O VMware vSphere 6.0 trouxe algumas mudanças relevantes na sua arquitetura, principalmente no vCenter Server, com a introdução da Platform Services Controller e a junção da maioria dos serviços necessários em uma única instalação (sem a opção de separação desses serviços).

Aqueles que já tiveram a oportunidade de executar uma instalação/atualização de ambiente VMware em versões anteriores (5.x), devem se lembrar que existia uma ordem correta na instalação dos componentes do vCenter Server.

Basicamente você tinha a opção de executar uma instalação simplificada (Simple Install), na qual todos os componentes (vCenter Inventory Service, vCenter Single Sign-On, vCenter Server e vSphere Web Client) eram instalados automaticamente, na ordem necessária e na mesma máquina. E além dessa opção, também era possível instalar cada um desses componentes separadamente, na mesma máquina ou em máquinas diferentes.

No vCenter Server 6.0, essa “estrutura” mudou, e os serviços foram divididos da seguinte maneira:

VMware Platform Services Controller

- Single Sign-On

- vSphere License Service

- VMware Certificate Authority

vCenter Server

- vCenter Inventory Service

- PostgreSQL

- vSphere Web Client

- vSphere ESXi Dump Collector

- vSphere Syslog Collector (no caso do vCenter Server p/ Windows)

- vSphere Syslog Service (no caso do vCSA)

- vSphere Auto Deploy

Todos estes serviços são instalados em conjunto, ou seja, ao instalar o VMware Platform Services Controller, você na verdade está instalando todos os serviços listados anteriormente, assim como no caso do vCenter Server, ao fazer a instalação ou o deploy do vCenter Server Appliance, todos os serviços listados também são automaticamente instalados. Não existe a possibilidade de instalar nenhum desses serviços separadamente, por exemplo: não tem como instalar o vCenter Inventory Server em uma máquina e o vCenter Server em outra máquina, como era possível até o vCenter Server 5.5.

De certa forma essa nova configuração simplificou bastante todo o processo de instalação do vCenter Server. O planejamento que deve ser feito a partir de agora é com relação à Platform Services Controller e o vCenter Server.

Existem duas opções para a instalação do vCenter Server e do VMware PSC:

vCenter Server with an embedded Platform Services Controller: nesta opção o vCenter Server, os componentes do vCenter Server e todos os serviços que compõem a PSC são instalados na mesma máquina.

vCenter Server with an external Platform Services Controller: nesta opção o vCenter Server e os seus componentes são instalados em uma máquina e os serviços que compões a PSC são instalados em uma outra máquina.

Essa escolha deve ser feita com bastante cuidado pois uma vez definida a configuração, para alterá-la após a instalação é bastante complicado.

Existem diversas variações dessa arquitetura, como por exemplo a utilização de uma única PSC para mais de um vCenter Server ou então a utilização de mais de uma PSC. Aqueles que tiverem interesse recomendo a leitura do artigo “vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 1”, no qual o autor mostra várias opções de configuração e diz quais são recomendadas e quais não são.

Aqueles que estão pensando em atualizar o ambiente de uma versão anterior para o vCenter Server 6.0 devem ter ainda mais precaução. Em primeiro lugar é necessário que o seu ambiente já esteja no mínimo em alguma versão do vCenter Server 5.x. Não é possível atualizar diretamente um vCenter Server 4.x ou anterior. Nestes casos será necessário atualizar para uma versão vCenter Server 5.x para então atualizar para o vCenter Server 6.0.

Uma outra questão importante a ser observada, é que dependendo de como foi feita a sua instalação do vCenter Server 5.1 e 5.5, pode acontecer da atualização para o vCenter Server 6.0 resultar em uma topologia (PSC e vCenter Server) não recomendada.

Para maiores detalhes vejam o KB “List of recommended topologies for vSphere 6.0.x (2108548)”

Outra consideração importante é sobre o banco de dados, caso sua instalação atual do vCenter Server 5.x tenha sido feita utilizando o SQL Express (que até então era instalado junto com o vCenter Server, caso não fosse especificado um outro banco de dados), a atualização para o vCenter Server 6.0 efetuará automaticamente uma migração desse banco de dados para um banco Postgres. Esse banco Postgres que vem embutido no vCenter Server suporta até 20 hosts ESXi e 200 VMs, na versão Windows. No vCenter Server Appliance o Postgres pode ser usado para ambientes com até 1.000 hosts ESXi e 10.000 VMs.

Para finalizar, recomendo a leitura do KB “Important information before upgrading to vSphere 6.0 (2110293)”, que contêm diversas considerações relevantes para os que pretendem atualizar o ambiente para o vCenter Server 6.0.

VMware vSphere 6.0 oficialmente disponibilizado para download!

2015-03-12T21:39:00.000-03:00

Pouco mais de um mês após o anúncio oficial, e quase 2 anos após a disponibilização do vSphere 5.5, a VMware lançou oficialmente para download a nova versão da sua plataforma de virtualização, o VMware vSphere 6.0, além de outras soluções, como por exemplo o VSAN 6.0, o SRM 6.0 e os produtos que compõem a suíte vCloud.

Para saber mais sobre algumas das novidades do vSphere 6.0, veja o post “Novidades do VMware vSphere 6.0!!” que fiz na época do anúncio.

Os que tiverem interessem podem fazer o download dos arquivos clicando nos links abaixo (é necessário estar logado no MyVMware. Os que não possuem licença podem se registrar para a avaliação por 60 dias, clicando na opção “Download Trial”):

ESXi 6.0

vCenter Server 6.0 (Includes vCenter Host Gateway Appliance)

vSphere Data Protection 6.0

vSphere Replication 6.0

vRealize Orchestrator Appliance 6.0.1

VMware vCenter Operations Manager Foundation 5.8.5

vCenter Site Recovery Manager 6.0

VMware vRealize Automation 6.2.1

VMware vRealize Operations Manager 6.0.1

VMware vRealize Business 6.1.0 for vSphere

VMware vRealize Infrastructure Navigator 5.8.4

Abaixo toda a documentação que foi disponibilizada junto com o lançamento.

New Features and Release Notes

What's New in VMware vSphere 6.0

VMware vSphere 6.0 Release Notes

Configuration Limits

Configuration Maximums for VMware vSphere 6.0

ESXi and vCenter Server Product Documentation

vSphere Installation and Setup Guide

vSphere Upgrade Guide

vCenter Server and Host Management Guide

vCenter Server Appliance Configuration Guide

vSphere Virtual Machine Administration Guide

vSphere Host Profiles Guide

vSphere Networking Guide

vSphere Storage Guide

vSphere Security Guide

vSphere Resource Management Guide

vSphere Availability Guide

vSphere Monitoring and Performance Guide

vSphere Administration with the vSphere Client Guide

vSphere Troubleshooting

Supplementary Documentation

Setup for Failover Clustering and Microsoft Cluster Service

Command-Line Installation and Upgrade of VMware vCenter Server 6.0 for Windows

Command-Line Installation and Upgrade of VMware vCenter Server Appliance 6.0

Comparing the Configuration of vCenter Server Appliance 5.5 and 6.0

Pacote .zip com toda a documentação reunida:

Release 6.0 Documentation Archive

EMC + VMware EVO:RAIL = VSPEX Blue

2015-03-02T16:13:00.000-03:00

Sem dúvidas o mercado de TI está em constante mudança e evolução, vira e mexe uma nova tendência surge e começa a transformar as coisas. Falando mais especificamente da área de infraestrutura, o surgimento de algumas tecnologias mudou radicalmente a forma de “construírmos” um datacenter, como por exemplo as redes de armazenamento, também conhecidas como SAN (Storage Area Network) e a Virtualização. A última tendência que parece estar indo por esse mesmo caminho, é o que chamamos de infraestrutura hiperconvergente.

Na VMworld 2014, a VMware anunciou um novo produto chamado EVO (EVO:Rail e EVO:Rack), o qual seria distribuído por meio de contratos OEM com outros fabricantes. Na ocasião foram apresentados alguns desses fabricantes, e entre eles estava a EMC.

Se você não sabe exatamente do que se trata o VMware EVO:Rail, veja o post “VMworld 2014 - EVO:RAIL: appliance para infraestrutura hiperconvergente”.

Esse modelo adotado pela VMware para distribuir o EVO:Rail, além de aumentar o leque de possibilidades para o seu usuário final, obrigou os fabricantes a se esforçarem para oferecer algum tipo de diferencial na sua oferta, seja incluindo no pacote um software de backup, uma solução de armazenamento externo integrada ou até mesmo uma oferta diferenciada de serviço/suporte.

No início de Fevereiro/2015 (durante o VMware PEX) a EMC finalmente mostrou o que estava preparando e surpreendeu muita gente com o seu novo produto, o VSPEX Blue. O VSPEX Blue é o appliance de infraestrutura hiperconvergente da EMC, baseado no VMware EVO:Rail.

Por padrão, todo appliance ofertado com o EVO:Rail (independente do fabricante) deve seguir uma especificação de hardware definida pela VMware, portanto nesse sentido o VSPEX Blue não fugiu muito a regra e será ofertado com as seguintes especificações:

Processor Per Node

•Intel Ivy Bridge (Up to 130W)

•Dual Processor

Memory | Processor Per Node

•4 Channels of Native DDR3(1333)

•Up to 8 DDR3 ECC R-DIMMS per server node

Disk

•Integrated 4-Port SAT/SAS controller (SW RAID)

•Up to 16 (4 per node) 2.5” HDD

I/O’s Per Node

•Dual GbE ports onboard

•Optional IB QDR/FDR or 10GbE integrated

•1x 8 PCIe Gen3 I/O Mezz Option (Quad GbE or Dual 10GbE)

•1 x 16 PCIe Gen3HBA slots

•Integrated BMC with RMM4 support

Chassis

•2U chassis supporting 4 hot swap nodes w/half-width MBs.

•2 x 1200W (80+ & CS Platinum) redundant hot-swap PS

•Dedicated cooling / node (no SPoF) –3 x 40mm dual rotor fans

•Front Panel w/separate power control per node

•17.24” x 30.35” x 3.46”

O appliance será oferecido com 2 configurações distintas: a configuração “Standard” que virá com 128GB de RAM em cada um dos nós, e a configuração “Performance” que terá 192GB de RAM em cada nó.

Por enquanto só será possível escalar até 4 appliances VSPEX Blue (16 nós) em um único cluster.

O grande diferencial do VSPEX Blue em relação aos seus concorrentes e a razão por seu lançamento ter sido tão comentado foi justamente a quantidade de ofertas de software e a forma como estes foram integrados na engine do EVO:Rail.

Além dos softwares que já estão inclusos em qualquer oferta do EVO:Rail:

- VMware vSphere Enterprise Plus;

- VMware vCenter Server;

- VMware vCenter Log Insight;

- VMware Virtual SAN;

- VMware EVO:Rail Engine

Também estará incluso no VSPEX Blue:

- VSPEX Blue Manager

Interface de gerência totalmente integrada com a interface do EVO:Rail. Oferece ao usuário a possibilidade de verificar o status dos componentes físicos do appliance. Acesso imediato aos recursos de suporte como a Knowlodge Base da EMC ou chat, por exemplo. Facilita no gerenciamento do applicance automatizando a verificação de atualizações de patches e softwares. Acesso ao VSPEX Blue Market.

- VSPEX Blue Market

A Blue Market foi uma grande sacada da EMC para facilitar a aquisição de soluções que podem ser utilizadas em conjunto com o VSPEX Blue. Funciona como uma loja de aplicativos (tipo um Apple Store ou Google Play) e com o passar do tempo é provável que mais softwares sejam disponibilizados

- EMC Secure Remote Support (ESRS)

O ESRS é o sistema utilizado pela EMC para monitorar remotamente todos os seus equipamentos. Com o ESRS, qualquer falha crítica é automaticamente enviada para a EMC, e se for o caso, um chamado também pode ser aberto. Além disso, o ESRS permite que o suporte da EMC conecte-se remotamente nos equipamentos (com a autorização do cliente) e tome as ações necessárias para resolver algum problema ou verificar pró-ativamente como o ambiente está.

- EMC RecoverPoint for VMs

O RecoverPoint for VMs é o software da EMC que permite a proteção contínua a nível de VM (para retornar a VM para qualquer ponto no tempo) e a replicação das suas VMs para outras localidades. No caso do VSPEX Blue, o RecoverPoint está licenciado para 15 VMs por appliance (4 nós).

- VMware Data Protection Advanced

Solução de backup em disco da VMware que é baseada na tecnologia EMC Avamar. É possível conseguir altas taxas de desduplicação com o VDP. E é possível salvar os dados no próprio appliance ou mandá-los para um appliance Data Domain externo.

- EMC CloudArray

O EMC CloudArray é um software da EMC (proveniente da aquisição da TwinStrata) que permite apresentar para as suas aplicações (por meio dos protocolos iSCSI ou NFS/CIFS) uma área de armazenamento de objetos fornecida por provedores de nuvem pública (AWS S3, vCloud Air, +20 outros provedores). O CloudArray ainda é capaz de armazenar em cache esse conteúdo. Com o VSPEX Blue será disponibilizada uma licença para 10TB de armazenamento e 1TB de cache.

Abaixo o vídeo de lançamento do VSPEX Blue...

A TI tão simples, que até um adulto pode fazer ;)

Prazo para recertificação VCP!

2015-02-24T10:57:00.000-03:00

Em 2014 a VMware anunciou uma nova política de recertificação para os profissionais que possuem a certificação VCP. Aqueles mais atentos devem ter observado que na página “myTranscript” no site VMware Education, desde então exibe (para as certificações VCP), uma linha chamada “Valid through”, informando até quando aquela certificação é válida.

Essa política de recertificação, válida desde 10 de março de 2014, funciona da seguinte maneira:

- Certificações conquistadas antes de 10 de março de 2013, devem ser recertificadas até 10 de março de 2015;

- Certificações conquistadas depois de 10 de março de 2013, devem ser recertificadas em até dois anos após a data do último exame VCP realizado;

Portanto, se você tirou a sua certificação VCP antes de 10 de março de 2013, deve atentar para as opções abaixo para renovar a sua certificação. Caso contrário (se deixar a sua certificação expirar) terá de fazer novamente o curso oficial para poder realizar um novo exame.

1. Fazer o exame mais atual existente na sua trilha de certificação VCP, por exemplo: Se você for um VCP4, pode fazer o exame VCP5-DCV;

2. Tirar uma nova certificação VCP em uma outra trilha de certificações, por exemplo: Se você possui a certificação VCP5-DCV (adquirida antes de 10/03/2013) pode fazer o exame VCP6-DT;

3. Tirar uma certificação de nível avançado VMware Certified Advanced Professional (VCAP), por exemplo: Se você possui a certificação VCP5-DCV pode fazer o exame VCAP5-DCA.

4. E por último, uma opção para aqueles que já possuem a VCP5-DCV (adquirida antes de 10/03/2013), é a realização do exame VCP5-DCV Delta, que estará disponível somente até o dia 10/03/2015. Para os profissionais que já possuem a VCP5-DCV essa é a opção mais rápida (e acredito que também seja a mais fácil) para renovarem o título de VCP. Dentre as vantagens deste exame estão:

O exame pode ser feito online, ou seja, você pode fazê-lo de qualquer lugar, inclusive de casa;
Muito mais barato do que os outros exames;
Existe um curso de 1hr disponibilizado gratuitamente que pode ser feito antes de realizar o exame;

Enfim, se você se encontra nessa situação, você ainda tem 15 dias para decidir entre uma dessas opções, e na minha opinião, vale a pena arriscar escolher qualquer um dos caminhos (de preferência aquele o qual já estava se preparando), para não ter que refazer o curso oficial.

Novidades do VMware vSphere 6.0!!

2015-02-04T17:30:00.000-02:00

Na última segunda-feira (02/02/2015), a VMware anunciou oficialmente o lançamento da nova versão da sua plataforma de virtualização, o vSphere 6.0. O anúncio veio acompanhado de diversas outras novidades, como Virtual SAN 6.0, e também o lançamento do VMware Virtual Volumes (VVOLs).

O vSphere 6.0 já era aguardado desde a VMworld 2014, quando algumas das novidades da versão foram divulgadas. Quem não se lembra pode acessar o post “O que há de novo no vSphere 6.0”, que publiquei naquela ocasião.

Acredito que o intervalo entre o lançamento do vSphere 5.5 e o vSphere 6.0 tenha sido um dos mais longo desde o lançamento do vSphere 4.1, e o motivo pode ter sido as +650 novas funcionalidades do software. Claro que não vai ter como listar aqui todas essas novidades, mas segue um resumo do que mais chamou a atenção no geral.

VMware vSphere 6.0

Escalabilidade

No que diz respeito a escalabilidade e configurações máximas suportadas, os avanços foram realmente surpreendentes, chegando a superar em até 4X a versão anterior.

Disponibilidade

Fault Tolerance (FT)

Uma das grandes mudanças do vSphere 6.0 e talvez uma das mais aguardadas, era a evolução da funcionalidade de Fault Tolerance (FT), que permite proteger uma máquina virtual de maneira extremamente simples e sem a necessidade de nenhuma alteração no S.O ou na aplicação. Desde o seu lançamento o Fault Tolerance era muito limitado, e cheio de “poréns” na sua utilização, como por exemplo a limitação de VMs com apenas 1 vCPU. Com o lançamento do vSphere 6.0 agora é possível proteger uma VM com até 4 vCPUs e até 64 GB RAM.

Outra mudança na característica do FT é que agora uma cópia completa da VM a ser protegida é feita, incluindo os discos, resultando em uma proteção ainda maior da máquina virtual.

O FT está limitado a 8 vCPUs ou 4 VMs protegidas por host.

Virtual Machine Component Protection (VMCP)

O VMCP é uma nova funcionalidade do vSphere 6.0, adicionada ao VMware HA, que adiciona um novo nível de recuperação a falhas no ambiente virtual. Até então o VMware HA não era capaz de identificar e reagir a uma falha no acesso aos subsistemas de armazenamento. Situações conhecidas como APD (All Paths Down) e PDL (Permanent Device Loss) muitas vezes impactavam na disponibilidade das VMs e necessitavam da intervenção do administrador para recuperar o ambiente.

Com o VMCP as máquinas virtuais passam a estar protegidas também contra falhas de conectividade ou configuração no acesso aos volumes compartilhados (datastores). Ao identificar uma situação de APD ou PDL, o VMCP será capaz de identificar as máquinas virtuais impactadas e reiniciá-las em um outro host que esteja funcional.

vSphere Data Protection

A VMware resolveu “acabar” com a versão Advanced da sua solução de backup (vSphere Data Protection) e passou a oferecer todas as funcionalidades junto com VDP, que já está incluso a partir do pacote “vSphere 6 Essential Plus Kit” em diante.

Atualmente é possível ter até 8 appliances VDP por vCenter, sendo que cada appliance suporta até 8TB de dados. O VDP agora também inclui agentes que permitem backups consistentes e restores confiáveis de aplicações como Microsoft SQL Server (inclusive clusters), Microsoft Exchange (inclusive DAGs) e Microsoft Sharepoint.

VMware vSphere vMotion

As capacidades de vMotion foram bastante incrementadas nesta nova versão, e passa a permitir que os usuários façam a migração de VMs entre switches virtuais, entre vCenter Servers e entre distâncias de até 100ms RTT.

Essas novas capacidades aumentam a flexibilidade na hora de arquitetar um ambiente virtual, uma vez que não há mais barreiras limitando o seu tamanho.

Existe a possibilidade de migrar uma VM entre vCenter Servers, inclusive entre a versão Windows e a versão Linux (VCSA). Esse tipo de migração preserva os dados e também as configurações da máquina virtual, como por exemplo UUID, os eventos, alarmes, histórico de tarefas, assim como configurações de shares, limits e reservations. As configurações de HA e DRS também são mantidas (affinity e antiaffinity rules, automation level, start-up priority, e host isolation response). Apenas os dados de desempenho não são levados, uma vez que estão armazenados no banco de dados do vCenter.

Arquitetura do vCenter Server

Existe agora apenas duas maneiras de arquitetar uma instalação do vCenter Server. A primeira é chamada de “embedded”, que inclui o novo serviço PSC (Plataform Services Controller) e o vCenter Server na mesma máquina. E a segunda, “external”, que instala cada um desses serviços em um servidor diferente.

Todos os serviços do vCenter Server, que até então possuíam instaladores independentes, como por exemplo VMware vCenter Inventory Service, VMware vSphere Web Client, Auto Deploy e etc, agora são instalados juntos com o vCenter Server, simplificando a arquitetura combinando diversas funções em uma única máquina. O vSphere Update Manager ainda exige que a sua instalação seja feita em uma máquina Windows independentemente.

Plataform Services Controller

Esse novo serviço na verdade é uma controladora de vários serviços que são comumente usados pela VMware vCloud Suite, incluindo Single Sign-On, Licenciamento e Gerenciamento de Certificados. PSCs são capazes de replicar informações como licenças, roles e permissões, e tags com outras PSCs.

Como as PSCs replicam todas as informações que normalmente são necessárias para a configuração do Linked Mode, o Linked Mode agora já vem habilitado para qualquer instalação do vCenter Server (Windows, VCSA ou ambas) desde que todas façam parte do mesmo domínio do Single Sign-On. Até então não era possível configurar o VCSA para utilizar Linked Mode.

vCenter Server Appliance

Falando de VCSA... agora não há mais diferenças, pelo menos no que diz respeito a escalabilidade, entre a linux e a versão Windows. Confira abaixo uma comparação numérica entre as duas plataformas:

Aqueles que quiserem conferir outras novidades do vSphere 6.0, recomendo a leitura do documento What’s New inthe VMware vSphere 6.0 Platform.

Monitorando a utilização de espaço em disco no VCSA

2015-01-26T14:50:00.000-02:00

A cada dia tenho visto mais e mais administradores optarem por utilizar o vCenter Server Appliance (VCSA) ao invés da versão Windows do vCenter Server. Se você tem dúvidas sobre qual das versões é melhor para o seu ambiente, veja esse post que fiz há algum tempo com algumas considerações que talvez ajudem a escolher.

Uma das coisas que eu já percebi é que quando se utiliza o VCSA, há uma certa tendência em abrir mão do gerenciamento da máquina em si, talvez por ter esse conceito de appliance, e já vir pré-configurado, algumas pessoas tendem a ignorar o gerenciamento e o monitoramento do S.O que roda dentro desse appliance. E esse “descaso” pode acabar gerando situações críticas para o ambiente.

Uma dessas situações pode ser o estouro do espaço em disco no appliance. É importante lembrar que o VCSA conta com um banco de dados vPostgres embutido e que com o passar do tempo e dependendo da maneira como foram configuradas as opções de estatísticas, esse banco pode crescer a ponto de ocupar toda a partição do disco, causando problemas ainda piores.

Infelizmente, ainda não há (e nem sei se algum dia terá) um alarme no vCenter informando sobre a utilização do espaço em disco no appliance. Talvez por isso a VMware tenha disponibilizado um script para os seus usuários que permite que um e-mail seja enviado para o administrador quando uma determinada percentagem do disco tiver sido ocupada.

Para maiores detalhes sobre este monitoramento e para o download do script, veja o KB2058187.

Renomeando máquinas virtuais através do PowerCLI

2015-01-13T16:25:00.000-02:00

Existem algumas situações em que um simples script pode nos ajudar a ganhar um bom tempo na execução de tarefas repetitivas. Recentemente passei por uma situação onde seria necessário renomear uma grande quantidade de máquinas virtuais. As VMs deveriam ser renomeadas tanto no inventário do vCenter como no domínio de rede. Imagina só o trabalho de ter que renomear máquina por máquina no vCenter e também no AD!?!

Procurando uma forma mais ágil para executar a atividade, acabei me deparando com alguns scripts PowerCLI, que depois de alguns testes e adaptações, me pouparam um bom tempo.

Abaixo compartilho com vocês...

- Script para renomear as VMs no inventário do vCenter

Connect-VIServer [vcenter-address] –User [vcenter-user] -Password [user-password]
$csv=Import-CSV "C:\temp\script\rename.csv"
Foreach ($vm in $csv){
Get-VM $($vm.oldname) | Set-vm -name $($vm.newname) -confirm:$false | 
}

O script acima é extremamente simples, basicamente será preciso criar um arquivo do tipo .csv contendo duas colunas, uma com o nome atual da VM no inventário do vCenter e outra com o nome desejado.

O script importa este arquivo .csv e linha por linha vai alterando o nome das respectivas VMs.

Um detalhe importante que deve ser levado em consideração ao renomear VMs no inventário do vCenter é que os arquivos que compõem a máquina virtual, localizados no datastore onde a mesma foi alocada, não são alterados. A única maneira de fazer essa alteração é movimentando a VM para um outro datastore através de uma operação de Storage vMotion. O ideal é fazer essa operação o quanto antes, uma vez que essa diferença na nomenclatura da VM pode dificultar um futuro troubleshooting.

- Script para renomear as VMs Windows no domínio

Connect-VIServer [vcenter-address] –User [vcenter-user] -Password [user-password]
$vms=Import-CSV "C:\temp\script\listavms.csv"
Foreach ($VM in $vms){
$VMInfo = Get-VMGuest ($vm.Name) | select-Object VmName, Hostname 
$VCName = $VMInfo.VmName
$GuestName = $VMInfo.HostName
If ($GuestName -ne $VCName) {
Write-Host "$VCName is currently $GuestName... renaming"
$renamecomputer = "netdom renamecomputer $GuestName /newname:$VCName /userd:[Domain\username] /passwordd:[domain-user-password] /force"
Invoke-VMScript -VM $VCName -GuestUser "[administrador-local]" -GuestPassword "[administrador-local-password]" -ScriptType Bat -ScriptText $renamecomputer
restart-vmguest -VM $VCName -Confirm:$false
}
}

Esse script é um pouco mais complexo que o anterior. O que ele faz é ler a lista das VMs que devem ter o nome de domínio alterado em um arquivo .csv.

Em seguida, para cada máquina virtual da lista, o script compara o nome atual no inventário do vCenter com o hostname (nome do guest OS), e se for diferente, renomeia a máquina no domínio com o mesmo nome utilizado no inventário do vCenter. Essa era a necessidade que eu tinha, mas o bom de se trabalhar com script é que podemos adaptar o código para o que a situação exige.