VMware Brasil: 2016
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.
Nesse post vou falar sobre as novidades do vSphere 6.5 com relação ao DRS.
Depois de um bom tempo, finalmente a VMware anunciou algumas mudanças e/ou novidades relativas aos mecanismos do DRS (Distributed Resource Scheduler).
- DRS – New Policies
O DRS (Distributed Resource Scheduler) é a funcionalidade responsável por balancear a utilização dos recursos de um cluster VMware e também por escolher o melhor host para alocar uma VM no momento em que ela é ligada. Nas versões anteriores foram adicionadas algumas opções avançadas que permitiam ajustar a maneira como o DRS deveria balancear as VMs entre os hosts ESXi. Com o vSphere 6.5 algumas dessas opções foram adicionadas à interface gráfica para facilitar para os usuários que desejam tais alterações possam faze-las com mais segurança. Basicamente foram três novas opções:
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.
O que há de novo no vSphere 6.5? - VMFS-6 / Core Storage
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.
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.
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.
às 16:34 2 comentários
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 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.
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:
às 23:48 2 comentários
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.
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.
É 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
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.
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%.
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.
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.
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.
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.
Novos Labs disponíveis no VMware Hands-on Labs
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
New 2017 VMware Hands-on Labs Released!
Transitioning to the 2017 Hands-on Labs
Limitando o número de conexões simultâneas na console de uma VM
É 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}
#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: