quinta-feira, 25 de agosto de 2016

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

                 

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 3 – Arquitetura VSAN

quarta-feira, 17 de agosto de 2016

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

                 

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

quarta-feira, 10 de agosto de 2016

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

                 

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 3 – Arquitetura VSAN

quinta-feira, 7 de julho de 2016

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}
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: