VMware Hands-on Labs - HOL-1708-SDC-1-PT


Visão geral do laboratório - HOL-1708-SDC-1 - Introdução ao Virtual SAN

Orientação do laboratório


Observação: a conclusão deste laboratório levará mais de 90 minutos. Espera-se que você termine apenas de 2 a 3 módulos durante o horário disponível para você.  Os módulos são independentes uns dos outros para que você possa começar desde o início de cada módulo e prosseguir de onde parou. Você pode usar o Índice para acessar qualquer módulo de sua preferência.

É possível acessar o Índice no canto superior direito do Manual do laboratório.

Resumo do laboratório:

O objetivo deste laboratório é ajudar a entender os conceitos básicos do VMware Virtual SAN. Este laboratório individualizado está dividido em 5 módulos. Cada módulo destaca etapas importantes relacionadas a configuração, ativação de recursos e solução de problemas do VMware Virtual SAN. Cada módulo contém várias lições sobre tópicos específicos. Os módulos são independentes uns dos outros e podem ser realizados em qualquer ordem de acordo com a preferência do aluno.

Lista de módulos de laboratório:

 Responsáveis do laboratório:  

 

Este manual de laboratório pode ser obtido por download no site de Documentos do laboratório prático que se encontra aqui:

[http://docs.hol.pub/HOL-2017]

Este laboratório pode estar disponível em outros idiomas.  Para definir sua preferência de idioma e ter um manual localizado de acordo com seu laboratório, este documento pode orientá-lo pelo processo:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Local do console principal

 

  1. A área dentro da caixa VERMELHA contém o console principal.  O Manual do laboratório está na guia à direita do console principal.
  2. Um laboratório específico pode ter outros consoles em guias separadas na parte superior esquerda. Se necessário, você será direcionado para abrir outro console específico.
  3. Seu laboratório começa com 90 minutos no cronômetro. Não é possível salvar o laboratório. Você deve fazer todo o seu trabalho durante a sessão do laboratório. No entanto, é possível clicar em EXTEND para estender o tempo. Se você estiver em um evento da VMware, poderá estender o tempo do laboratório duas vezes, por no máximo 30 minutos. Cada clique acrescenta 15 minutos. Fora de eventos da VMware, você pode estender o tempo do seu laboratório por no máximo 9 horas e 30 minutos. Cada clique acrescenta uma hora.

 

 

Solicitação ou marca d'água de ativação

 

Quando você iniciar o laboratório pela primeira vez, talvez observe uma marca d'água na área de trabalho, que indica que o Windows não está ativado.

Um dos principais benefícios da virtualização é que as máquinas virtuais podem ser movidas e executadas em qualquer plataforma.  Os laboratórios práticos utilizam esse benefício, e é possível executá-los em vários data centers.  No entanto, esses data centers podem não ter processadores idênticos, o que aciona uma verificação de ativação da Microsoft pela Internet.

A VMware e os laboratórios práticos estão em total conformidade com os requisitos de licenciamento da Microsoft.  O laboratório que você está usando é um pod autocontido e não tem acesso completo à Internet, o que é necessário para que o Windows verifique a ativação.  Sem o acesso completo à Internet, esse processo automatizado falha e essa marca d'água é exibida.

Esse problema superficial não afeta seu laboratório.

 

 

Métodos alternativos de inserção de dados por teclado

Durante este módulo, digite o texto no console principal. Além da digitação direta, há dois métodos muito práticos que facilitam a entrada de dados complexos.

 

 

Clicar e arrastar conteúdo do manual do laboratório para a janela ativa do console

Você também pode clicar e arrastar textos e comandos da interface de linha de comando (CLI, Command Line Interface) diretamente do Manual do laboratório para a janela ativa no console principal.

 

 

Acesso ao teclado internacional on-line

 

Você também pode usar o teclado internacional on-line do console principal.

  1. Clique no ícone de teclado que fica na barra de tarefas de Início Rápido do Windows.

 

 

Clicar uma vez na janela ativa do console

 

Neste exemplo, você usará o teclado on-line para inserir o sinal "@" usado em endereços de e-mail. Nos layouts de teclado dos EUA, pressione as teclas Shift+2 para inserir o sinal "@".

  1. Clique uma vez na janela ativa do console.
  2. Clique na tecla Shift.

 

 

Clique na tecla @

 

  1. Clique na tecla "@".

Observe o sinal @ inserido na janela ativa do console.

 

 

Observar a parte inferior direita da tela

 

Verifique se foram concluídas todas as rotinas de inicialização do seu laboratório e se ele está pronto para você começar. Se aparecer algo diferente de "Ready", aguarde alguns minutos.  Após cinco minutos, se o laboratório ainda não aparecer como "Ready", peça ajuda.

 

Alternador de módulo


O aplicativo do alternador de módulo ajuda a acessar e se mover pelos diversos módulos de um laboratório.


 

Iniciar o alternador de módulo

 

  1. Abra a pasta chamada "Module Switchers" na área de trabalho
  2. Clique duas vezes no módulo chamado "1 HOL-1708-SDC-1 - VSAN A to Z"

 

 

Como trabalhar com o alternador de módulo

 

 

Módulo 1 - Configuração e ativação do Virtual SAN 6.2 (15 minutos, para iniciantes)

Introdução


O que é o Virtual SAN?

Virtual SAN é a solução de armazenamento convergente da VMware. Foi apresentada como versão beta em 2013 e disponibilizada para o público em março de 2014. A versão 6.2 foi lançada em março de 2016. O Virtual SAN é totalmente integrado ao vSphere, um sistema de armazenamento com base em objetos e uma plataforma para políticas de armazenamento de VMs visando simplificar as decisões de alocação de armazenamento de VMs para os administradores do vSphere. Essa solução é totalmente compatível e integrada aos recursos básicos do vSphere (vSphere High Availability (HA), vSphere Distributed Resource Scheduler (DRS) e vMotion).

Este módulo contém as seguintes lições:


Lição 1: visão geral do Virtual SAN



 

O que é o Virtual SAN

Como um componente do vSphere, o Virtual SAN permite ao hypervisor a criação de pools e abstração de recursos de armazenamento com base em servidores x86, da mesma forma que o vSphere cria pools e abstrai recursos de processamento. Ele foi projetado para ser mais simples, eficiente e econômico em relação aos arrays tradicionais de armazenamento externo. Os usuários do vSphere devem ser capazes de aprender a usar o Virtual SAN e tornar-se produtivos rapidamente.

O Virtual SAN é totalmente integrado ao vSphere e oferece suporte para a maioria dos recursos nativos do vSphere: DRS, HA e vMotion, entre outros. O Virtual SAN também é integrado ao vRealize Suite para entrega de serviços de infraestrutura automatizados.

Os administradores definem políticas de armazenamento e as atribuem às VMs. Uma política de armazenamento define requisitos de disponibilidade, desempenho e aprovisionamento (por exemplo, thin provisioning). Quando uma VM é aprovisionada, o Virtual SAN interpreta a política de armazenamento e configura os dispositivos de armazenamento subjacentes para cumprir a política automaticamente (por exemplo, RAID 1). Quando a política de armazenamento é alterada, o Virtual SAN reconfigura os recursos e componentes automaticamente para cumprir a nova política.

Pontos principais:

 

Características técnicas:

 

 

 

Benefícios para o cliente

Simples

Comparado com soluções tradicionais de armazenamento, o Virtual SAN é extremamente simples de instalar e operar no dia a dia. O armazenamento é apresentado como uma extensão natural da experiência de gerenciamento do vSphere. O gerenciamento baseado em políticas simplifica consideravelmente o aprovisionamento de serviços de armazenamento para VMs.

Alto desempenho

O Virtual SAN fornece integração profunda ao kernel do vSphere e o uso de flash melhora consideravelmente o desempenho de aplicativos, em comparação com soluções tradicionais de armazenamento. Aplicativos que exigem níveis ainda maiores de desempenho previsível podem usar configurações baseadas somente em flash.

Redução do TCO

O Virtual SAN pode reduzir o TCO em at 50% ao usar um modelo de gerenciamento simplificado, assim como componentes padronizados de armazenamento em servidor. A expansão da capacidade ou do desempenho envolve simplesmente a adição de mais recursos ao cluster: flash, discos ou servidores.

 

 

 

 

 

Principais casos de uso

 

 

Lição 2: requisitos do Virtual SAN



 

vCenter Server

O Virtual SAN 6.0 requer o ESXi 6.0 e o vCenter Server 6.0. O Virtual SAN pode ser gerenciado pela versão do vCenter Server para Windows e pelo vCenter Server Appliance (VCSA).

O Virtual SAN é configurado e monitorado pelo vSphere Web Client, que também precisa estar na versão 6.0.

 

 

vSphere ESXi

O Virtual SAN precisa de pelo menos três hosts do vSphere (onde cada host deve contribuir um armazenamento local) para formar um cluster do Virtual SAN compatível. Com isso, o cluster pode satisfazer os requisitos mínimos de disponibilidade para tolerar pelo menos uma falha de host. Os hosts do vSphere devem executar o vSphere 6.0. Com menos hosts, existe o risco de indisponibilidade de máquinas virtuais caso um único host tenha problemas. O número máximo de hosts permitidos no cluster é de 64.

Cada host do vSphere no cluster que contribui para o armazenamento local no Virtual SAN deve ter pelo menos uma unidade de disco rgido (HDD, hard disk drive) e pelo menos uma unidade de disco de estado sólido (SSD, solid state disk drive).

 

 

Disco e rede

IMPORTANTE: todos os componentes (hardware, drivers e firmware) devem estar listados no Guia de compatibilidade do vSphere para Virtual SAN. Nenhuma outra configuração/condição é permitida.

A porta VMkernel é denominada Virtual SAN. Essa porta é usada para comunicação entre os nós do clusters e para leituras e gravações quando um dos hosts for proprietário de uma determinada máquina virtual onde os blocos de dados reais (que formam os arquivos da máquina virtual) estiverem localizados em um host diferente do cluster. Nesse caso, o I/O precisará atravessar a rede configurada entre os hosts do cluster.

 

Lição 3: preparação do cluster do Virtual SAN


Para usar o Virtual SAN, inicialmente você deve criar um cluster com no mínimo 3 hosts e ativar o Virtual SAN nas propriedades do cluster.

Um cluster do Virtual SAN pode incluir hosts com e sem discos de armazenamento.

Siga estas diretrizes ao criar um cluster do Virtual SAN.

Depois que você ativa o Virtual SAN, o provedor de armazenamento do Virtual SAN é automaticamente registrado no vCenter Server e o datastore do Virtual SAN é criado.


 

Abrir o navegador Chrome na barra de tarefas de início rápido do Windows

 

  1. Clique noícone do Chrome na barra de tarefas de início rápido do Windows.

 

 

Fazer login no vSphere Web Client

 

Na tela de login do vSphere Web Client, selecione "Use Windows session authentication"

Clique em Login

 

 

vSphere Web Client

 

A página inicial do vSphere Web Client será exibida.

Para minimizar ou maximizar os painéis Recent Tasks, Alarms to Work In Progress, clique na tachinha.

Selecione Hosts and Clusters

 

 

Ativar o Virtual SAN

 

O Virtual SAN vem desativado por padrão. Nesta lição, mostraremos como ativar o Virtual SAN seguindo algumas etapas fáceis.

Observação sobre o ambiente do laboratório: atualmente, o cluster chamado RegionA01-COMP01 contém três hosts ESXi que contribuirão com o armazenamento na forma de cache e capacidade para formar o datastore do Virtual SAN.

Selecione RegionA01-COMP01 e navegue até Manage > Settings > Virtual SAN > General > Configure

 

 

Ativar o Virtual SAN

 

Verifique se Add disks to storage está definido como Manual

A seleção de Manual permite configurar manualmente os grupos de discos do Virtual SAN. Nesse método, podemos selecionar o disco de cache e os discos de capacidade que formarão o grupo de discos do Virtual SAN.

Nessa tela, temos outras opções como ativar o recurso Deduplication and Compression no datastore do Virtual SANe criar domínios de falha e um cluster estendido. Esses tópicos serão abrangidos em seções posteriores do laboratório. Para obter uma rápida visão geral desses recursos, clique nas informações com o ícone (i) ao lado do recurso.

Na seção Fault Domains and Stretched Cluster, verifique se Do not configure está selecionado

Clique em Next

 

 

 

Validação da rede

 

As verificações foram criadas para conferir se existem adaptadores VMKernel configurados e se o serviço de rede do Virtual SAN está ativado.

Clique em Next

 

 

Reivindicar discos

 

Selecione os discos que devem ser reivindicados para cache e para capacidade no cluster do Virtual SAN.

Os discos são agrupados por modelo e tamanho ou por host. A seleção recomendada foi feita com base nos dispositivos disponíveis no seu ambiente.

É possível expandir as listas dos discos para seleção de discos individuais.

O número de discos de capacidade deve ser maior ou igual ao número de discos de cache reivindicados por host.

Não clique em Next ainda.

 

 

Reivindicar discos

 

Na lista suspensa Group by:, selecione Host

Trata-se de uma visualização do armazenamento do ponto de vista do host.

Clique em Next

 

 

Pronto para concluir

 

Revise e confirme sua seleção.

Aqui podemos determinar que criaremos um datastore do Virtual SAN com capacidade de 120 GB. O datastore do Virtual SAN usa os discos de capacidade para sua própria capacidade. Os discos de cache não são considerados.

No momento, não temos o recurso de eliminação de duplicação e compactação ativado. É um cluster do Virtual SAN baseado somente em flash, onde os discos de cache e capacidade são discos SSD.

Clique em Finish

 

 

Atualizar exibição

 

O Virtual SAN agora está ativado.

Clique no ícone Refresh para ver as alterações. (Se a mensagem Misconfiguration detected for exibida, você talvez precise clicar em Refresh algumas vezes)

Depois de atualizar, você deve ver os três hosts no cluster do Virtual SAN

 

 

 

Tarefas recentes

 

Você pode analisar as tarefas que foram realizadas abrindo o painel Recent Tasks na parte inferior do vSphere Web Client.

Essas tarefas consistem em criar o cluster do Virtual SAN, criar os grupos de discos e adicionar os discos aos grupos.

 

 

Virtual SAN - Gerenciamento de discos

 

Selecione Virtual SAN ->Disk Management

Os grupos de discos do Virtual SAN de cada host ESXi são listados.

Talvez seja necessário rolar para baixo na lista para ver todos os grupos de discos.

Na parte inferior da tela, você pode ver os Tipos de unidade e a Camada de disco que compõem esses grupos de discos.

 

 

 

Propriedades do datastore do Virtual SAN

 

Depois que você cria o cluster do Virtual SAN, um Datastoredo Virtual SAN também é criado.

Para ver a capacidade, navegue até Datastores > RegionA01-VSAN-COmp01 > Manage > Settings > General

A capacidade exibida é um agregado dos dispositivos de capacidade obtido em cada host ESXi no cluster (um pouco menos de sobrecarga do Virtual SAN).

Os dispositivos flash usados como cache não são considerados no cálculo de capacidade.

 

 

Verificar o status do provedor de armazenamento

 

Para que cada host ESXi conheça os recursos do Virtual SAN e faça a comunicação entre o vCenter e a camada de armazenamento, um provedor de armazenamento é criado. Cada host ESXi recebe um provedor de armazenamento assim que o cluster do Virtual SAN é formado.

Os provedores de armazenamento serão registrados automaticamente no serviço de gerenciamento de armazenamento (SMS, Storage Management Service) pelo vCenter. No entanto, é melhor verificar se os provedores de armazenamento de um dos hosts ESXi estão registrados e ativos, e se os outros provedores de armazenamento dos hosts ESXi restantes no cluster estão registrados e no modo de espera.

Navegue até vCenter Server > Manage > Storage Providers para verificar o status.

Nesse cluster de três nós, um dos provedores do Virtual SAN está on-line e ativo, enquanto os outros três estão no modo de espera. Cada host ESXi que participa do cluster do Virtual SAN terá um provedor, mas somente um precisa estar ativo para fornecer informações de capacidade do datastore do Virtual SAN.

Caso o provedor ativo falhe por algum motivo, um dos provedores de armazenamento em espera será ativado.

 

Lição 4: eliminação de duplicidade e compactação do Virtual SAN


O Virtual SAN 6.2 introduz dois novos recursos de redução de dados: eliminação de duplicidade e compactação. Quando ativados no nível do cluster, o Virtual SAN elimina duplicações em cada bloco e compacta o resultado antes de encaminhar o bloco para a camada de capacidade. Esses recursos só estão disponíveis para o Virtual SAN baseado somente em flash.

Não é possível ativar a eliminação de duplicidade e a compactação separadamente. Elas devem ser desativadas ou ativadas juntas. A eliminação de duplicidade e a compactação funcionam no nível do grupo de discos. Em outras palavras, somente os objetos implantados no mesmo grupo de discos podem contribuir para economizar espaço. Se componentes de VMs diferentes, porém idênticas, forem implantados em grupos de discos diferentes, não haverá eliminação de duplicidade de blocos de dados idênticos. No entanto, a eliminação de duplicidade e a compactação são recursos do cluster que estão ativados ou desativados.

Não é possível escolher em quais máquinas virtuais ou grupos de discos eles serão ativados. Para componentes implantados no mesmo grupo de discos com eliminação de duplicidade e compactação ativadas, a eliminação de duplicidade será realizada no nível do bloco de 4 KB. Um grupo de discos usará somente uma cópia desse bloco de 4 KB e todos os blocos duplicados serão eliminados.


 

Eliminação de duplicidade e compactação do Virtual SAN

 

O processo de eliminação de duplicidade é realizado quando o bloco está sendo encaminhado da camada do cache para a camada de capacidade. Para acompanhar os blocos desduplicados, tabelas de hash são usadas. Os dados desduplicados e os metadados da tabela de hash são propragados para os dispositivos de capacidade que fazem parte do grupo de discos. A eliminação de duplicidade não diferencia os componentes do grupo de discos. Ela pode eliminar a duplicidade de blocos no namespace inicial da VM, na troca de VMs, no objeto VMDK ou no objeto delta de snapshot.

Assim que os dados duplicados do bloco são eliminados, o Virtual SAN tenta compactar esse bloco de 4 KB para que fique com 2 KB ou menos. Se o Virtual SAN conseguir compactar um bloco para que fique com < = 2 KB, a cópia compactada será mantida. Caso contrário, o bloco não compactado será mantido.

O processo é relativamente simples. Na etapa 1, a VM grava os dados no Virtual SAN que acessa a camada de cache. Quando os dados ficam frios e precisam ser encaminhados, o Virtual SAN lê o bloco na memória (etapa 2). Essa ação processa os hashes, elimina as duplicações e compacta os blocos restantes antes de gravá-los na camada de capacidade (etapa 3).

Atualmente, o Virtual SAN usa SHA1 para o hash de eliminação de duplicidade e usa LZ4 para a compactação.

 

 

 

Ativar a eliminação de duplicidade e a compactação do Virtual SAN

 

Selecione o cluster chamado RegionA01-COMP01

Selecione Manage -> Settings -> Virtual SAN -> General

A eliminação de duplicidade e a compactação estão atualmente desativadas

Clique em Edit

 

 

Ativar a eliminação de duplicidade e a compactação do Virtual SAN

 

Verifique se Add disks to storage está definido como Manual

Altere Deduplication and compression para Enabled

Também é possível Permitir redundância reduzida

A ativação da eliminação de duplicidade e da compactação requer uma alteração de formato no disco. O Virtual SAN esvazia o grupo de discos, remove e recria esse grupo com um novo formato no disco que é compatível com esses novos recursos.

Você talvez não tenha recursos suficientes no cluster para permitir que o grupo de discos seja totalmente esvaziado. Pode ser um cluster de três nós e talvez não haja nenhum lugar para direcionar a réplica ou testemunha e, ao mesmo tempo, manter a proteção total. Talvez seja um cluster de quatro nós com objetos RAID 5 já implantados. Nesse caso, não há nenhum lugar para mover parte da faixa de RAID 5 (já que os objetos RAID 5 precisam de quatro nós). Isso também pode simplesmente significar que você consumiu uma quantidade considerável de capacidade do disco sem espaço para armazenar todos os dados em menos grupos de discos.

De qualquer maneira, você ainda tem a opção de ativar a eliminação de duplicidade e a compactação, sabendo que correrá algum risco durante o processo, pois não há nenhum lugar para mover os componentes. Essa opção permite que as VMs continuem em execução.

 Clique em OK

 

 

Ativar a eliminação de duplicidade e a compactação do Virtual SAN

 

Aguarde até que a tarefa seja concluída. Na versão de formato no disco, podemos ver que há uma atualização em andamento.

Conforme mencionado antes, o Virtual SAN esvazia o grupo de discos, remove e recria esse grupo com um novo formato no disco que é compatível com esses novos recursos.

 

 

Ativar a eliminação de duplicidade e a compactação do Virtual SAN

 

É possível monitorar a tarefa no painel Recent Tasks.

Aqui, você pode ver o processo de remoção de discos/grupos de discos, conversão do formato de disco e adição dos discos/grupos de discos novamente, para um host de cada vez.

 

 

Ativar a eliminação de duplicidade e a compactação do Virtual SAN

 

A eliminação de duplicidade e a compactação agora estão totalmente ativadas e todos os grupos de discos foram removidos e recriados.

 

Lição 5: dimensionamento horizontal da capacidade do cluster do Virtual SAN


O VMware Virtual SAN é uma arquitetura de armazenamento com dimensionamento horizontal e vertical. Isso significa que é possível adicionar com facilidade outros recursos de armazenamento ao cluster do Virtual SAN. Esses recursos de armazenamento podem ser discos magnéticos (híbridos) ou dispositivos flash (baseados somente em flash) para capacidade adicional, grupos de discos completos incluindo dispositivos de cache e capacidade, mas também podem ser hosts adicionais que contêm capacidade de armazenamento.

Começamos com um cluster do Virtual SAN de três nós. Nesta lição, mostraremos como realizar o dimensionamento horizontal do datastore do Virtual SAN adicionando outro host ESXi que contribuirá com armazenamento para o datastore do Virtual SAN.

 


 

Verificar a capacidade atual do Virtual SAN

 

A adição de hosts ao cluster do Virtual SAN é bem simples. Obviamente, você deve garantir que o host satisfaça os requisitos ou as recomendações do Virtual SAN, como uma porta NIC dedicada de 1 Gb (10 GbE é recomendado) e pelo menos um dispositivo de camada de cache e um ou mais dispositivos de camada de capacidade caso o host precise fornecer mais capacidade de armazenamento. Além das etapas de pré-configuração, uma porta VMkernel para comunicação do Virtual SAN devem ser considerada, embora isso possa ser feito depois da adição do host ao cluster.

Selecione o cluster chamado RegionA01-COMP01

Clique em Summary

Nossa capacidade atual do datastore do Virtual SAN é aproximadamente 112 GB.

 

 

Verificar a configuração do cluster do Virtual SAN

 

  1. Selecione o cluster chamado RegionA01-COMP01
  2. Selecione a guia Manage
  3. Selecione o botão Settings
  4. Selecione General na seção Virtual SAN
  5. Verifique se Add disks to storage está definido como Manual

 

 

Verificar os dispositivos de armazenamento

 

Se o ESXi não reconhecer automaticamente seus dispositivos como flash/SSD, você poderá marcá-los como dispositivos flash/SSD.

O ESXi não reconhece alguns dispositivos como flash quando os fornecedores deles não oferecem suporte para detecção automática de discos flash. A coluna Drive Type dos dispositivos mostra HDD como tipo.

Observação: marcar discos HDD como discos flash pode prejudicar o desempenho de datastores e serviços que os utilizam. Marque os discos como discos flash somente se você tiver certeza de que os discos são flash.

Selecione esx-04a.corp.local -> Manage -> Storage -> Storage Devices

Na lista Storage Devices, você pode ver os dois discos que usaremos para contribuir com armazenamento para o datastore do Virtual SAN. Um dos discos tem 5 GB e será usado como o disco de Cache. O outro disco tem 40 GB e será usado para a camada de Capacidade.

Embora seja um cluster do Virtual SAN baseado somente em flash, ainda precisaremos de um disco SSD para cache e pelo menos um disco SSD para capacidade.

 

 

Adicionar outros nós ao cluster

 

Agora adicionaremos o nó esx-04a.corp.local ao cluster do Virtual SAN.

Arraste e solte esx-04a.corp.local no cluster RegionA01-COMP01

Se a operação de arrastar e soltar não funcionar, clique com o botão direito no host ESXi chamado esx-04a.corp.local e selecione Move to .... Selecione o cluster chamado RegionA01-COMP01.

 

 

Mover o host para o cluster

 

Selecione a opção padrão"Put all of this host's virtual machines in the cluster's root resource pool. Resource pools currently present on the hosts will be deleted."

Clique em OK

Você pode ver mensagens de aviso nos hosts ESXi já no cluster, mas essas mensagens desaparecerão depois de algum tempo.

 

 

Sair do modo de manutenção

 

Agora tiraremos o host ESXi do modo de manutenção.

Clique com o botão direito em esx-04a.corp.local e selecione Maintenance Mode> Exit Maintenance Mode

 

 

 

Configurar a rede

 

Geramos alguns alertas. Isso indica que temos que configurar nossa rede do Virtual SAN corretamente.

 

 

Configurar a rede

 

Selecione esx-04a.corp.local

Selecione Manage -> Networking -> VMkernel adapters

Selecione vmk2

Aqui podemos ver que o serviço Virtual SAN Traffic está desativado nessa porta vmKernel.

Clique no botão Edit (ícone de lápis)

 

 

Configurar a rede

 

Ative o serviço Virtual SAN traffic marcando a caixa.

Clique em OK

 

 

Configurar a rede

 

Aqui podemos ver que o serviço Virtual SAN Traffic está ativado nessa porta vmKernel.

 

 

Capacidade do Virtual SAN

 

Selecione RegionA01-COMP01 -> Summary

A capacidade do Virtual SAN ainda é aproximadamente 112 GB. Tudo que fizemos até agora foi adicionar outro host ESXi ao cluster do Virtual SAN. Como a configuração Add disks to storage está definida como Manual, teremos que criar manualmente o grupo de discos do Virtual SAN nesse host para que ele possa contribuir com armazenamento para o datastore do Virtual SAN.

 

 

Verificar nós adicionais

 

Selecione RegionA01-COMP01

Selecione Manage

Selecione Settings

Selecione Virtual SAN -> Disk MAnagement

O host ESXi chamado esx-04a.corp.local faz parte do cluster do Virtual SAN, mas ainda não contribui com armazenamento.

 

 

Reivindicar disco qualificado para capacidade

 

  1. Selecione RegionA01-COMP01
  2. Selecione Manage
  3. Selecione Settings
  4. Selecione Virtual SAN ->Disk Management
  5. Clique no botão Claim Disks

 

 

 

Selecionar discos disponíveis

 

Aqui podemos ver os discos que estão disponíveis nesse host. Eles são agrupados por Modelo/tamanho do disco. Também é possível agrupá-los por Host

Clique duas vezes na caixa de diálogo para redimensioná-la e para que os botões OK / Cancel fiquem disponíveis

Clique em OK.

 

 

Verificar cluster do Virtual SAN

 

Aguarde a conclusão das tarefas de reivindicação dos discos e expansão da capacidade do cluster.

Pode ser necessário atualizar os grupos de discos para que os recursos sejam atualizados.

Aqui podemos ver o Grupo de discos criado no host esx-04a.corp.local.

 

 

Capacidade do Virtual SAN

 

Selecione a visualização Datastores

Selecione o datastore RegionA01-VSAN-COMP01

Selecione Summary

A capacidade do Virtual SAN agora aumentou para aproximadamente 149 GB. São os 40 GB adicionais que adicionamos do grupo de discos no host ESXi chamado esx-04a.corp.local

 

Conclusão



 

Você terminou o Módulo 1

Parabéns por concluir o Módulo 1.

Continue em qualquer módulo abaixo que seja do seu interesse. [Adicione informações personalizadas/opcionais para o manual do laboratório.]

 

 

Como trabalhar com o alternador de módulo

 

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END (FIM).  

 

Módulo 2 - Recursos baseados somente em flash do Virtual SAN (30 minutos, para iniciantes)

Introdução


Neste módulo, analisaremos alguns recursos baseados somente em flash do Virtual SAN que são ativados por meio do gerenciamento com base em políticas de armazenamento.

Esse módulo abordará mais especificamente os métodos de tolerância de falha, o que determina se o método de gravação/replicação de dados está otimizado para desempenho ou capacidade. O número de falhas a serem toleradas tem uma função importante quando planejamos e dimensionamos a capacidade de armazenamento do Virtual SAN.

A função de codificação de apagamento (Erasure Coding) RAID 5 ou RAID 6 permite que o Virtual SAN tolere a falha de até dois dispositivos de capacidade no datastore. É possível configurar o RAID 5 em clusters baseados somente em flash com quatro ou mais domínios de falha. É possível configurar o RAID 5 ou RAID 6 em clusters baseados somente em flash com seis ou mais domínios de falha. A codificação de apagamento RAID 5 ou RAID 6 requer menos capacidade adicional para proteger seus dados do que o espelhamento do RAID 1. Por exemplo, uma VM protegida pelo valor 1 de Número de falhas a serem toleradas com RAID 1 requer o dobro do tamanho do disco virtual, mas, com RAID 5, ela requer 1,33 vezes o tamanho do disco virtual. A tabela a seguir mostra uma comparação geral entre RAID 1 e RAID 5 ou RAID 6.

Esse módulo também fala sobre objetos de troca das VMs. No Virtual SAN 6.2, uma nova opção avançada do host, SwapThickProvisionDisabled, foi criada para permitir que a opção de objetos de troca da VMs seja aprovisionada como um objeto thin. Se essa configuração avançada for definida como true (verdadeira), os objetos de troca de VMs terão aprovisionamento thinprovisioning.


Preparação do laboratório


Usaremos o aplicativo PowerCLI do alternador de módulo para preparar o ambiente.


 

Alternadores de módulo

 

 

 

Alternador de módulo do laboratório de A a Z do Virtual SAN

 

  1. Clique duas vezes no atalho "1 VSAN A to Z HOL-SDC-1708-1"

 

 

Início do Módulo 2

 

  1. Clique no botão Module 2 Start

Essa rotina de inicialização pode levar 5 minutos. Obrigado pela paciência.

 

 

Monitorar o andamento

 

Monitore o andamento até o final.

 

 

Conclusão da preparação do laboratório

 

O laboratório foi preparado para o Módulo 2.

  1. Clique na janela Close para interromper o alternador de módulo com segurança

 

Lição 1: gerenciamento com base em políticas de armazenamento - Raid 5/6


O método de tolerância a falhas é um novo recurso introduzido no Virtual SAN 6.2 e permite que os administradores optem por configuração RAID 1 ou RAID 5/6 para os objetos de máquina virtual. O método de tolerância a falhas é definido junto com o número de falhas a serem toleradas. A finalidade dessa configuração é permitir que os administradores escolham entre desempenho e capacidade. Se o desempenho for o objeto final escolhido pelos administradores, RAID 1 (que é a opção padrão) será o método de tolerância usado. Se os administradores não precisarem de desempenho máximo e estiverem mais preocupados com uso de capacidade, RAID 5/6 será o método de tolerância usado. A maneira mais fácil de explicar o comportamento é exibir as várias configurações de política e a configuração de objeto resultante.


 

Gerenciamento de políticas com base em armazenamento

 

O Virtual SAN 6.2 acrescenta diversas novas políticas de armazenamento: desativar checksum de objeto, método de tolerância a falhas e limites de IOPS para objeto.

Faremos uma breve descrição de cada política de armazenamento aqui.

Número de distribuições de disco por objeto - O número de dispositivos de capacidade pelo qual cada réplica de um objeto de máquina virtual é distribuída. Um valor maior que 1 pode resultar em melhor desempenho, mas também resulta em maior uso dos recursos do sistema.

Reserva de cache de leitura com base em flash - Capacidade com base em flash reservada como cache de leitura para o objeto de máquina virtual. Especificado como porcentagem do tamanho lógico do objeto de disco de máquina virtual (vmdk). A capacidade com base em flash reservada não pode ser usada por outros objetos. O flash não reservado é compartilhado igualmente entre todos os objetos. Essa opção só deve ser usada para lidar com problemas de desempenho específicos.

Número de falhas a serem toleradas - Define o número de falhas de host e dispositivo que um objeto de máquina virtual pode tolerar. Para n falhas toleradas, n+1 cópias do objeto de máquina virtual são criadas e 2*n+1 hosts que contribuem com armazenamento são necessários.

Forçar aprovisionamento - Se a opção for definida como Sim, o objeto será aprovisionado mesmo que a política especificada na política de armazenamento não possa ser cumprida pelo datastore. Use esse parâmetro em cenários de bootstrapping e durante uma interrupção quando o aprovisionamento padrão não for mais possível.

Reserva de espaço de objeto - Porcentagem do tamanho lógico do objeto de disco de máquina virtual (vmdk) que deve ser reservado ou receber o aprovisionamento completo durante a implantação de máquinas virtuais.

Desativar checksum de objeto - Se a opção for definida como Não, o objeto calculará as informações de checksum para garantir a integridade dos dados. Se essa opção for definida como Sim, o objeto não calculará as informações de checksum. As checksums garantem a integridade dos dados confirmando se cada cópia de um arquivo é exatamente igual ao arquivo de origem. Se for detectada alguma discrepância de checksum, o Virtual SAN reparará os dados automaticamente, substituindo os dados incorretos pelos dados corretos.

Método de tolerância a falhas - Especifica se o método de replicação de dados deve ser otimizado para desempenho ou capacidade. Se você escolher Performance, o Virtual SAN usará mais espaço em disco para colocar os componentes dos objetos, mas fornecerá melhor desempenho para acessar os objetos. Se você selecionar Capacity, o Virtual SAN usará menos espaço em disco, mas reduzirá o desempenho.

Limite de IOPS para o objeto - Define o limite de IOPS para um disco. O IOPS é calculado como o número de operações de E/S, usando um tamanho ponderado. Se o sistema usar o tamanho básico padrão de 32 KB, uma E/S de 64 KB representará duas operações de E/S. No cálculo de IOPS, leitura e gravação são considerados equivalentes, enquanto a taxa de acessos do cache e a sequência não são considerados. Se o IOPS de um disco ultrapassar o limite, as operações de E/S serão controladas. Se o limite de IOPS do objeto for definido como 0, os limites de IOPS não serão impostos.

 

 

Gerenciamento de políticas com base em armazenamento - Raid 5/6 (codificação de apagamento)

 

Existe um requisito quanto ao número de hosts necessários para implementar configurações RAID-5 ou RAID-6 no Virtual SAN.

Para RAID-5, são necessários no mínimo 4 hosts. Para RAID-6, são necessários no mínimo 6 hosts.

Os objetos são implantados no armazenamento de cada host, junto com um cálculo de paridade. A configuração usa a paridade distribuída e, assim, não há nenhum disco de paridade dedicado. Quando ocorre uma falha no cluster que afeta os objetos que foram implantados usando RAID-5 ou RAID-6, os dados ainda estão disponíveis e podem ser calculados usando os dados restantes e a paridade, se necessário.

Uma nova configuração de política foi introduzida para acomodar as novas configurações RAID-5/RAID-6.

Essa nova configuração de política é chamada de Método de tolerância a falhas. A configuração de política considera dois valores: desempenho e capacidade. Quando o valor padrão de desempenho é mantido, os objetos continuam sendo implantados com uma configuração RAID 1/espelhada visando o melhor desempenho. Quando a configuração é alterada para capacidade, os objetos agora são implantados com uma configuração RAID 5 ou RAID 6.

A configuração RAID 5 ou RAID 6 é determinada pela configuração do número de falhas a serem toleradas. Se esse valor for definido como 1, a configuração será RAID 5. Se esse valor for definido como 2, a configuração será RAID 6.

 

 

 

Gerenciamento de políticas com base em armazenamento - Raid 5/6 (codificação de apagamento)

 

Primeiro, precisamos criar uma política de armazenamento de VM que definirá o método de tolerância a falhas de Raid 5/6.

Na página inicial, selecione Policies and Profiles

 

 

Gerenciamento de políticas com base em armazenamento - Raid 5/6 (codificação de apagamento)

 

Selecione Home -> Policies and Profiles -> VM Storage Policies

Selecione Create a New VM Storage policy

 

 

Gerenciamento de políticas com base em armazenamento - Raid 5/6 (codificação de apagamento)

 

Crie uma nova política de armazenamento de VM usando as seguintes informações

Nome: FTT=1-Raid5

Clique em Next

Clique em Next na página de informações Rule-Sets

 

 

Gerenciamento de políticas com base em armazenamento - Raid 5/6 (codificaçatilde;o de apagamento)

 

Crie um novo Rule-Set usando as seguintes informações:

Regras com base em serviços de dados: Virtual SAN
		Regra 1: número de falhas a serem toleradas = 1
		Regra 2: método de tolerância a falhas = Raid-5/6 (codificação de apagamento) - Capacidade

Antes de clicar em Next, verifique o seguinte:

Altere o Método de tolerância a falhas = RAID-1 (espelhamento) - Desempenho

Revise o Modelo de consumo de armazenamento no lado direito da tela. Observe que o Espaço de armazenamento que seria usado é 200 GB com base em um disco virtual de 100 GB.

Agora altere o Método de tolerância a falhas = Raid-5/6 (codificação de apagamento) - Capacidade e você verá que o Espaço de armazenamento agora será reduzido para 133 GB.

Clique em Next

 

 

Gerenciamento de políticas com base em armazenamento

 

A compatibilidade do armazenamento será determinada com base na política de armazenamento de VM.

Aqui podemos ver que vsanDatastoreé compatível com a política de armazenamento de VM que estamos prestes a criar.

Clique em Next

 

 

Gerenciamento de políticas com base em armazenamento - Raid 5/6 (codificação de apagamento)

 

Revise as configurações da política de armazenamento de VM

Clique em Finish

 

 

 

Gerenciamento de políticas com base em armazenamento - Raid 5/6 (codificação de apagamento)

 

Selecione FTT=1-Raid5 -> Manage -> Rule-Set-1:VSAN

Aqui podemos ver as regras que fazem parte da política de armazenamento de VM.

 

 

Capacidade do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Selecione Home -> Hosts and Clusters

Selecione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity

Anote as figuras de capacidade aqui. ( O vsanDatastore está praticamente vazio )

 

 

Clonar VM para o datastore do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Iremos clonar a VM chamada Photon-Temp (que reside atualmente em um datastore NFS) para o datastore do Virtual SAN e aplicar a Política de Armazenamento de VM (FTT=1-Raid5) que acabou de criar.

Clique com o botão direito na VM chamada Photon-Temp e selecione Clone -> Clone to Virtual Machine

 

 

Clonar VM para o datastore do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Nomeie a máquina virtual como FTT=1-Raid5

Clique em Next

 

 

Clonar VM para o datastore do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Selecione o recurso Compute chamado RegionA01-COMP01

Clique em Next

 

 

Clonar VM para o datastore do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Na Política de Armazenamento de VM, selecione FTT=1-Raid5

Na lista resultante dos datastores compatíveis será apresentada, no nosso caso, o vsanDatastore chamado RegionA01-VSAN-COMP01

Na seção inferior da tela, podemos ver que o consumo de armazenamento do Virtual SAN seria de 666,67 do espaço em disco e 0.00 B do espaço flash reservado.

Uma vez tendo uma máquina virtual com um disco de 256 MB e uma Política de Armazenamento de VM do Raid 5, o consumo do disco Virtual SAN será de 666,67 MB.

Clique em Next

Clique em Next nas opções Select clone

 

 

Clonar VM para o datastore do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Clique em Finish

Aguarde até que a operação de clonagem seja concluída.

Verifique às Recent Tasks para obter uma atualização de status na tarefa Clone virtual machine.

 

 

Clonar VM para o datastore do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Assim que a operação de clonagem estiver completa, selecione a VM chamada FTT=1-Raid5

Selecione Summary -> VM Storage Policies

Aqui podemos ver que a VM Storage Policy para esta VM está definida como FTT=1-Raid5 e que a política está em conformidade.

Selecione Summary -> Related Objects

A VM agora está residente na Datastore do Virtual SAN

 

 

Políticas de disco - FTT=1 Raid 5

 

 Selecione a VM FTT=1-Raid5 -> Monitor -> Policies -> Hard Disk 1 -> Physical Disk Placement

Observe com esta Política de Armazenamento de VM, temos um posicionamento de disco Raid 5, feito de 4 componentes.

Há um componente que reside em cada host no Cluster.

 

 

Capacidade do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

 

Para permitir que os administradores controlem onde o consumo de armazenamento está ocorrendo, uma nova capacidade foi introduzida com o Virtual SAN 6.2.

Selecione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity

Focamos primeiramente na Capacity Overview, assim podemos ver o tamanho total do datastore do Virtual SAN. Isto é aproximadamente 160 GB de tamanho. Também é possível ver Deduplication and compression em sobrecarga.

A quantidade de espaço Used  Total no datastore do Virtual SAN refere-se a quanto espaço foi fisicamente escrito (em oposição ao tamanho lógico). Esta é uma combinação de discos virtuais, objetos da home da VM, objetos de swap, objetos de gerenciamento de desempenho e outros itens que podem residir no datastore. Outros itens podem ser imagens ISO, VMs não registradas e modelos, por exemplo.

A visão geral de Eliminação de duplicação e compactação no canto superior direito dá aos administradores uma ideia sobre economia de espaço e taxa de eliminação de duplicação que está a ser alcançado, bem como a quantidade de espaço que pode ser necessário se um administrador decidiu desativar os recursos de eficiência de espaço no Virtual SAN e aumentar novamente quaisquer objetos de eliminação de duplicação e compactados.

A taxa de economia de espaço aumenta quanto mais VMs similares são implementadas.

Isto está nos dizendo que, sem eliminação de duplicação e compressão, ele teria exigido ~ 3,48 GB de capacidade para implementar as cargas de trabalho atuais. Com eliminação de duplicação e compactação, conseguimos ~ 2,02 GB.

 

 

Capacidade do Virtual SAN - Raid 5/6 (codificação de apagamento )

 

Selecione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity

Na parte inferior da Capacity Screen, vamos obter uma repartição dos objetos.

Agrupar por Object Types:

Performance management objects: capacidade consumida por objetos criados para armazenar métricas de desempenho quando o serviço de desempenho está habilitado

File system overhead: qualquer sobrecarga retomada pelo sistema de arquivos no disco (VirstoFS) nas unidades de capacidade, que não é nem atribuída à eliminação de duplicação, compressão e nem sobrecarga de checksum. Quando a eliminação de duplicação e compressão está ativada, a sobrecarga do sistema de arquivos aumenta em 10X para refletir o aumento do tamanho lógico do datastore Virtual SAN.

Deduplication and compression overhead: sobrecarga incorrida para obter os benefícios da eliminação de duplicação e compressão. Isto inclui a tabela de mapeamento associado, tabelas de dispersão e outros mecanismos necessários para a eliminação de duplicação e compressão.

Checksum overhead: sobrecarga para armazenar todas os checksums. Quando a eliminação de duplicação e compressão está ativada, a sobrecarga do checksum aumenta em 10X para refletir o aumento do tamanho lógico do datastore Virtual SAN.

Quando uma VM e um modelo são implementados no datastore do Virtual SAN, mais objetos aparecem:

Virtual disks: capacidade consumida por objetos de discos da máquina virtual (VMDKs) que residem no datastore do Virtual SAN

VM home objects: capacidade consumida por objetos de namespace da home da VM (contendo arquivos da máquina virtual) que residem no datastore do Virtual SAN

Swap objects: capacidade consumida pelo espaço de troca da VM que reside no datastore do Virtual SAN quando uma máquina virtual está ligada.

Vmem capacidade consumida por objetos de memória, criados como resultado ao tirar um snapshot da VM que incluiu a memória da mesma ou de máquinas virtuais suspensas. Note que isto só será visível em VMs que estão usando no mínimo o Virtual Hardware V10.

Other: capacidade consumida por modelos de VM, VMs não registradas, VMDKs autnomas não associadas com VMs, objetos do Virtual SAN criados manualmente e diretórios criados manualmente que armazenam ISOs, por exemplo.

 

 

Implement Raid 6 - Políticas de disco

 

Seu ambiente de laboratório está atualmente executando um 4 Node VSAN Cluster. Para implementar o Raid 6, é necessário no  mínimo 6 hosts no cluster do Virtual SAN.

A Política de armazenamento de VM terá um Método de tolerância a falhas do Raid 5/6 - (Codificação de apagamento) - Capacidade e o Número de falhas a ser tolerado definido para 2.

Em um Raid-6 será consumido x1,5 vezes do armazenamento atribuído para a VM.

 

 

 

Implement Raid 6 - Políticas de disco

 

 

Aqui está um exemplo de VM com uma Configuração de política de armazenamento de VM Raid 6.

Na configuração do Raid 6, há 6 componentes e eles estão espalhados em todo os 6 ESXi hosts no cluster. 

Somente para fins de exemplificação.

 

 

Lição 2: novo objeto Sparse VM Swap



 

Novo objeto Sparse VM Swap

O objeto VM Swap também tem as suas próprias definições de políticas específicas. Para o objeto VM Swap, sua política sempre tem o número de falhas a serem toleradas definido como 1. A principal razão para isso é que a troca não precisa persistir quando uma máquina virtual é reiniciada. Portanto, se o VMware HA reinicia a máquina virtual em outro host em outras partes do cluster, um novo objeto Swap VM é criado. Portanto, não há necessidade de adicionar uma proteção adicional além de tolerar uma falha.

Por padrão, os objetos VM Swap são provisionados 100% de forma automática, sem a necessidade de definí-las manualmente na política. Isto significa, em termos de controle de entrada, que o Virtual SAN não vai implementar a VM a menos que haja espaço no disco suficiente para acomodar o tamanho completo do objeto de swap da VM. No Virtual SAN 6.2, uma nova opção de host avançada, SwapThickProvisionDisabled, foi criada para permitir que este objeto referente a VM seja aprovisionado como um objeto thin. Se essa configuração avançada for definida como true, os objetos VM Swap terão aprovisionamento thin.

 

 

Novo objeto Sparse VM Swap

 

Para mostrar esse exemplo, a única VM que precisamos ligadas em nosso ambiente é a VM chamada FTT=1-Raid5 criada anteriormente.

Se você possui outras VMs sendo executadas no cluster RegionA01-COMP01, desligue-as agora.

Na VM chamada FTT=1-Raid5, podemos ver que temos 512 MB de memória atribuídos.

Observe que o ESXi host em que a VM está sendo executada, pode ser diferente da mostrada.

 

 

Novo objeto Sparse VM Swap

 

Agora, alterne para a CapacityView.

Selecione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity

Role para a parte inferior da CapacityView para a seção Used Capacity Breakdown .

Aqui podemos notar que os Objetos de troca ocupam cerca de 1,01 GB

 

 

Desligar VMs

 

Clique com o botão direito na VM chamada FTT=1-Raid5

Selecione Power -> Power Off

 

 

Novo objeto Sparse VM Swap

 

Agora, volte para a CapacityView.

Selecione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity

Como esperado, não há objetos de troca da VM consumindo espaço no datastore do Virtual SAN.

 

 

 

Novo objeto Sparse VM Swap

 

Selecione a máquina virtual denominada FTT=1-Raid5

Selecione Summary

Anote sobre os ESXi hosts que a VM está registrada contra.

 

 

Novo objeto Sparse VM Swap

 

Abra uma sessão puTTY para o ESXi host o qual a VM FTT=1-Raid5 está registrada.

A primeira coisa a observar é que essa configuração avançada precisa ser configurada para cada ESXi host presente no cluster do Virtual SAN. No nosso ambiente, vamos defini-lo apenas no ESXi host que irá executar a VM.

Observação: é permitido arrastar e soltar o comando a partir do manual ou usar a opção "send text" na parte superior do menu.

A configuração é chamada SwapThickProvisionDisabled e está desabilitada por padrão:

esxcfg-advcfg -g /VSAN/SwapThickProvisionDisabled

Para ativá-lo:

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled

 

 

 

Ativar a VM

 

 

 

Novo objeto Sparse VM Swap

 

Ative a VM chamada FTT=1-Raid5 novamente.

Volte para a Capacity View Screen.

Selecione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity

Agora podemos notar que os Objetos de troca estão consumindo agora somente 12,00 MB do disco, ao invés dos 524 MB originais.

Esse novo recurso pode fornecer uma considerável economia de espaço no espaço da capacidade consumida.

Isso vai depender de quantas VMs você implementou e de quão grande é o espaço de troca de VM (essencialmente o tamanho da memória não reservada atribuída à VM).

 

 

Conclusão


Neste módulo, demonstramos algumas das novas Políticas de armazenamento de VM que fazem parte da versão 6.2 do Virtual SAN.

Começamos mostrando o Método de tolerância de falhas onde podemos especificar se o método de replicação de dados deve ser otimizado para desempenho ou capacidade. Se você escolher "Performance", o Virtual SAN usará mais espaço em disco para colocar os componentes dos objetos, mas fornecerá melhor desempenho para acessar os objetos. Se você selecionar Capacity, o Virtual SAN usará menos espaço em disco, mas reduzirá o desempenho.

Em seguida, olhamos para os Objetos Sparse VM Swap. Esse novo recurso pode fornecer uma considerável economia de espaço em relação a capacidade consumida, ou seja, os objetos VM Swap terão aprovisionamento thin.


 

Você terminou o Módulo 2

Parabéns por concluir o Módulo 2.

Continue em qualquer módulo abaixo que seja do seu interesse.

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END (FIM).  

 

Módulo 3 - Disponibilidade e da continuidade de negócios (30 minutos, avançado)

Introdução


Este módulo se concentra principalmente no cluster estendido (geograficamente disperso) do Virtual SAN, seus requisitos e configurações. Esta capacidade possibilita que as funcionalidades do cluster, VMware vSphere High Availability (HA) e VMware vSphere Distributed Resource Scheduler (DRS) sejam utilizadas.

A característica do cluster estendido do Virtual SAN é pautado nos mesmos conceitos de arquitetura aplicados na criação de um cluster local com Virtual SAN onde, no mínimo, três domínios de falha são necessários para formar um cluster do Virtual SAN com sucesso.

O cluster estendido do Virtual SAN baseia-se em domínios de falha, representados por três zonas ou por três locais distintos (dois locais ativos e um local denominado testemunha). O local testemunha é um conceito único, já que esta localidade é apenas utilizada para armazenar dispositivos virtuais de objetos testemunhas, informações de metadados do cluster e também oferecem serviços de quorum para o cluster durante eventos de falha.

Requisitos de rede entre localidades - DCs ativos (domínios de falha - dados)

Requisitos de rede do serviço testemunha para os DC ativos (domínio de falha - metadados e poder de quorum)


Preparação do laboratório


Usaremos o aplicativo PowerCLI do alternador de módulo para preparar o ambiente.


 

Alternadores de módulo

 

 

 

Alternador de módulo do laboratório de A a Z do Virtual SAN

 

  1. Clique duas vezes no atalho "1 HOL-1708-SDC-1 - VSAN A to Z"

 

 

Início do Módulo 3

 

  1. Clique no botão Module 3 Start

 

 

Monitorar o andamento

 

Monitore o andamento até o final.

 

 

Conclusão da preparação do laboratório

 

O laboratório foi preparado para o Módulo 3.

  1. Clique na janela Close para interromper o alternador de módulo com segurança

 

Lição 1: o cluster estendido do Virtual SAN


As configurações de cluster estendido oferecem a capacidade de balancear recursos das máquinas virtuais (VMs) entre datacenters. Existem diversas razões para que esta situação aconteça, quer seja para evitar desastres ou para a manutenção da localidade, tudo isso sem tempo de inatividade na perspectiva da VM uma vez que recursos de computação, armazenamento e rede estão distribuídos entre as localidades. Além disso, um cluster estendido também possibilita a capacidade balancear ativamente recursos entre os locais sem quaisquer restrições.

 


 

Configurar o cluster estendido do Virtual SAN

 

O cluster estendido do Virtual SAN é construído tendo como fundamento a característica de domínios de falha onde, neste caso, as zonas de falhas necessárias são baseadas em nós físicos e appliance virtual denominado testemunha. O appliance virtual testemunha é exclusivamente projetado com propósito único de fornecer serviços de quorum do cluster (tomada de decisão durante eventos de falha) e armazenar objetos testemunhas e informações de metadados do cluster. A testemunha deve ter conexão com o nó do Virtual SAN master e com o nó do Virtual SAN de backup para se juntar ao cluster.

O appliance testemunha também tem um ícone diferente (azul claro) no vSphere Web Client diferente dos ESXi hosts regulares, o que lhe permite identificar o appliance testemunha rapidamente

Alguns fatos sobre o Virtual appliance testemunha do Virtual SAN:

Já implementamos o VSAN Witness host para você neste ambiente. O ESXi host está registrado como esx-07a.corp.local em um cluster chamado VSAN-Witness-Cluster

Observação: a cor que representa o host Witness é um azul claro, para ajudar a identificá-lo no seu ambiente vSphere.

 

 

Configurar o cluster estendido do Virtual SAN

 

Selecione o ESXi host chamado esx-07a.corp.local

Selecione Manage

Selecione Storage

Selecione Storage Devices

O VSAN Witness host possui uma memória flash 10 GB ( cache ) e um HDD de 15GB ( capacidade ).

Usaremos isto para criar o diskgroup do VSAN Witness host.

 

 

Configurar o cluster estendido do Virtual SAN

 

Selecione o cluster chamado RegionA01-COMP01

Selecione Manage -> Settings -> Virtual SAN -> Fault Domains & Stretched Cluster

O cluster expandido está atualmente Desativado

Clique em  Configure

 

 

Configurar o cluster estendido do Virtual SAN

 

Nomeie o Preferred fault domain e o Secondary fault domain, como os padrões escolhidos, Preferred e Secondary.

Deixe os ESXi hosts esx-01a.corp.local e esx-02a.corp.local no domínio de falha Preferred.

Mude os ESXi hosts esx-03a.corp.local e esx-04a.corp.local para o domínio de falha Secondary.

Clique em Next

 

 

Configurar o cluster estendido do Virtual SAN

 

Expanda o cluster chamado VSAN-Witness-Cluster

Selecione o esx-07a.corp.local como o VSAN witness host.

Os Requisitos para os witness hosts estão listados na tela.

Clique em Next

 

 

Configurar o cluster estendido do Virtual SAN

 

Selecione o disco de 10 GB para o nível Cache.

Selecione o disco de 15 GB para o nível Capacity.

Clique em Next

 

 

Configurar o cluster estendido do Virtual SAN

 

Verifique suas configurações e clique em Finish.

 

 

 

Configurar o cluster estendido do Virtual SAN

 

Revise o painel Recent Tasks.

 

 

Configurar o cluster estendido do Virtual SAN

 

Assim que as tarefas forem concluídas, seu cluster expandido do Virtual SAN será formado.

Podemos ver que o Stretched Cluster foi habilitado, o Preferred fault domain está com o nome Preferred e o VSAN witness host é esx-07a.corp.local

Mais abaixo na tela, podemos ver os 2 domínios de falha que foram criados, cada domínio de falha contendo dois ESXi hosts.

 

 

Integridade dos objetos do Virtual SAN

 

Selecione RegionA01-COMP01

Selecione Monitor

Selecione Virtual SAN

Selecione Health

Temos uma nova região na verificação de integridade para o cluster expandido.

 

 

Verificar integridade do cluster expandido

 

Expanda a verificação de integridade do cluster expandido.

Aqui, poderemos visualizar as verificações de integridade relacionadas ao cluster expandido do Virtual SAN.

Se apresentar erros ou avisos na Verificação de integridade do Virtual SAN, clique no botão Retest para confirmar que eles não são erros transitórios. 

 

 

Solução de problemas da política de armazenamento de VMs

 

Você deve ter notado que os dados da verificação de integridade do Virtual SAN falharam.

Vamos investigar o que aconteceu aqui

 

 

Solução de problemas da política de armazenamento de VMs

 

Vamos primeiro visitar as Políticas de armazenamento de VM que foram aplicadas à VM.

Selecione a máquina virtual denominada FTT-1-Raid5.

Selecione Monitor -> Policies -> Hard Disk 1 -> Physical Disk Placement

Podemos notar que o Compliance Statusé Noncompliant

 

 

Solução de problemas da política de armazenamento de VMs

 

Selecione Monitor -> Policies -> Hard Disk 1 -> Compliance Failures

O que aconteceu aqui é que a Política de armazenamento de VM que aplicamos a esta VM é a configuração Raid 5, o que significa que ela precisa de 4 ESXi hosts, além de 4 domínios de falha (um ESXi também é um domínio de falha). Quando criamos o cluster expandido do Virtual SAN, reduzimos o número de domínios de falha para 2, o que invalida a Política de armazenamento de VM.

 

 

Solução de problemas da política de armazenamento de VMs

 

Selecione Manage -> Policies -> Edit VM Storage Policies

 

 

Solução de problemas da política de armazenamento de VMs

 

Para política de armazenamento de VM, selecione Virtual SAN Default Storage Policy

Clique em Apply to all

Clique em OK

 

 

Solução de problemas da política de armazenamento de VMs

 

Assim, o Status de conformidade continuará Fora de conformidade.

Vamos investigar mais afundo ...

 

 

Solução de problemas da política de armazenamento de VMs

 

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Resyncing Components 

Aqui podemos ver os componentes que estão sendo sincronizados novamente. Aguarde até que a sincronização seja concluída.

Este é um tempo inicial estimado e reduzirá e os Bytes deixados da sincronização também reduzirá.

 

 

Solução de problemas da política de armazenamento de VMs

 

Assim que a sincronização estiver concluída, volte à tela Monitor -> Policies.

Selecione a máquina virtual denominada FTT-1-Raid5.

Selecione Monitor -> Policies -> VM Home -> Physical Disk Placement

Podemos notar que o Compliance Statusé Compliant

Também podemos ver que após a aplicação da nova Política de armazenamento de VM chamada Política de armazenamento padrão do Virtual SAN, os componentes da VM foram colocados como se segue. Um componente em cada domínio de falha e o quorum sendo fornecido pelo VSAN Witness.

 

 

Solução de problemas da política de armazenamento de VMs

 

Selecione RegionA01-COMP01

Selecione Monitor

Selecione Virtual SAN

Selecione Health

A seção de dados da Verificação de integridade do VSAN já passou por todos os testes.

 

Lição 2: Virtual SAN com vSphere HA e DRS



 

Configurações de VMware vSphere High Availability (HA) e VMware vSphere Distributed Resource Scheduler (DRS) para clusters estendidos do Virtual SAN

Para fornecer disponibilidade para máquinas virtuais em um cluster estendido do Virtual SAN, o vSphere High Availability (HA) precisa ser configurado.

Isto permite que as VMs sejam reiniciadas no mesmo local (com regras de afinidade), quando existe uma falha no host, ou sejam reiniciadas remotamente, quando há uma falha total no local. No entanto, há certas configurações que precisam ser definidas de uma maneira específica, que são fundamentais para alcançar alta disponibilidade em um cluster estendido do Virtual SAN.

Nesta tarefa, vamos abranger as configurações recomendadas da VMware e também explicaremos por que estamos recomendando que o vSphere HA seja configurado desta forma em um cluster estendido do Virtual SAN.

Seguindo esta orientação, você terá certeza de que suas máquinas virtuais serão reiniciadas no mesmo local (mantendo a localidade de leitura) quando há uma falha de componente/host em determinado site. Isto também irá garantir o failover de máquinas virtuais e a reinicialização no site remanescente no caso de uma falha total.

 

 

Renomeie a VM

 

Assim que o cluster estendido do Virtual SAN estiver formado, iniciaremos a implementação de máquinas virtuais no cluster do Virtual SAN. Faremos isso renomeando a máquina virtual FTT=1-Raid5.

Clique com o botão direito em FTT=1-Raid5 VM e selecione Rename

A razão pela qual estamos mudando o nome da VM é apenas fins ilustrativos.

Renomeie a VM para VM-Primary 

 

 

Desligar VMs

 

Temos nossa primeira VM disponível, vamos desligá-la agora para usá-la mais tarde nesta lição.

  1. Clique com o botão direito em VM-Primary
  2. Selecione Power > Power Off
  3. Clique em Yes (não mostrado)

Agora, vamos criar uma segunda VM, chamada VM-Secondary.

 

 

Clonar a VM para o site secundário

 

Desta vez iremos clonar a VM Photon-Temp.

Clique com o botão direito na VM Photon-Temp, selecione Clone e selecione Clone to Virtual Machine

 

 

Clonar a VM para o site secundário

 

Nomeie a máquina virtual, chamaremos-a de VM-Secondary, esta VM irá localizar-se no Secondary Site.

Nome da VM: VM-Secondary

Clique em Next

 

 

Clonar a VM para o site secundário

 

Selecione o cluster RegionA01-COMP01, este é onde vamos, inicialmente, colocar a VM.

Clique em Next

 

 

Clonar a VM para o site secundário

 

Aqui, aplicaremos uma Política de armazenamento de VM à VM. Iremos colocar a VM no vsanDatastore.

Selecione a Política de armazenamento de VM a seguir:

Política de armazenamento de VM: Virtual SAN Default Storage Policy

Clique em Next

 

 

Clonar a VM para o site secundário

 

Clique em Next em Select Clone options

 

 

Clonar a VM para o site secundário

 

Verifique suas configurações e clique em Finish

 

 

Configurações de vSphere HA e DRS para o cluster estendido do Virtual SAN

 

Agora, temos nossas 2 máquinas virtuais implementadas no nosso ambiente.

 

 

Configurações do vSphere DRS

 

Já definimos a maior parte das configurações necessárias das funções HA e DRS para o cluster estendido do Virtual SAN, mas vamos visualizar abaixo apenas para relembrar o que precisa ser configurado.

O DRS pode ser configurado no modo totalmente automatizado ou parcialmente automatizado.

Para obter mais informações sobre como configurar o cluster do Virtual SAN, consulte o link a seguir: - http://www.vmware.com/files/pdf/products/vsan/VMware-Virtual-SAN-6.2-Stretched-Cluster-Guide.pdf

Selecione o cluster RegionA01-COMP01

Selecione Manage

Selecione Settings

Selecione vSphere DRS

O vSphere DRS está ativado e está no modo Parcialmente automatizado.

 

 

 

VM/Host Groups

 

Agora, vamos considerar o DRS no cluster estendido do Virtual SAN.

As primeiras considerações de DRS é no relacionamento das regras de afinidade do VM/Host.

O DRS é necessário para o funcionamento das regras de afinidade do VM/Host. Se o DRS não está habilitado, as regras "should" são ignoradas. Então, se você quiser usar as regras "should" de afinidade do VM/Host, precisará do DRS.

Selecione o cluster chamado RegionA01-COMP01

Selecione Manage

Selecione Settings

Selecione VM/Host Groups

Clique em Add

 

 

VM/Host Groups

 

Nomeie o VM/Host Group Primary

Para Type, selecione Host Group

Adicione os 2 ESXi hosts chamados esx-01a.corp.local e esx-02a.corp.local ao VM/Host Group

Clique em OK

 

 

 

VM/Host Groups

 

Selecione Primary

O Primary Host Group contém os ESXi hosts chamados esx-01a.corp.local e esx-02a.corp.local

Clique em Add para criar outro VM/Host Group

 

 

VM/Host Groups

 

Nomeie o VM/Host Group Secondary

Para Type, selecione Host Group

Adicione os 2 ESXi hosts chamados esx-03a.corp.local e esx-04a.corp.local ao VM/Host Group

Clique em OK

 

 

VM/Host Groups

 

Selecione Secondary

O Secondary Host Group contém os ESXi hosts chamados esx-03a.corp.local e esx-04a.corp.local

Clique em Add para criar outro VM/Host Group

 

 

VM/Host Groups

 

Nomeie o VM/Host Group Primary-VM

Para Type, selecione VMGroup

Adicione a VM chamada VM-Primary ao VM Group

Clique em OK

 

 

VM/Host Groups

 

Selecione Primary-VM

O Primary-VM  VM Group contém a VM chamada VM-Primary

Clique em Add para criar outro VM/Host Group

 

 

VM/Host Groups

 

Nomeie o VM/Host Group Secondary-VM

Para Type, selecione VMGroup

Adicione a VM chamada VM-Secondary ao VM Group

Clique em OK

 

 

VM/Host Groups

 

Selecione Secondary-VM

O Secondary-VM  VM Group contém a VM chamada VM-Secondary

 

 

 

Regras VM-Host

 

Selecione o cluster chamado RegionA01-COMP01

Selecione Manage

Selecione Settings

Selecione VM/Host Rules

Clique em Add VM/Host Rules

 

 

Regras VM-Host

 

Nomeie o VM/Host Rule PrimaryVMHosts

Para Type selecione Virtual Machine to Hosts

Para VM Group, selecione Primary-VM e Should run on hosts in group

Para Host Group, selecione Primary

Clique em OK

 

 

Regras VM-Host

 

Nossa primeira VM/Host Rule está criada.

Máquinas virtuais que são membros do VM Group devem ser executadas em hosts que são membros do Host Group.

Clique em Add VM/Host Rules

 

 

Regras VM-Host

 

Nomeie o VM/Host Rule SecondaryVMHosts

Para Type selecione Virtual Machine to Hosts

Para VM Group, selecione Secondary-VM e Should run on hosts in group

Para Host Group, selecione Secondary

Clique em OK

 

 

Regras VM-Host

 

Nossa segunda VM/Host Rule está criada.

Máquinas virtuais que são membros do VM Group devem ser executadas em hosts que são membros do Host Group.

 

 

Habilitar o HA no cluster estendido do Virtual SAN

 

Para fornecer disponibilidade para máquinas virtuais em um cluster estendido do Virtual SAN, o vSphere HA precisa ser configurado. Isto permite que as VMs sejam reiniciadas no mesmo local (com regras de afinidade), quando existe uma falha no host, ou sejam reiniciadas remotamente, quando há uma falha total no local. No entanto, há certas configurações que precisam ser definidas de uma maneira específica, que são fundamentais para alcançar alta disponibilidade em um cluster estendido do Virtual SAN.

Selecione o cluster RegionA01-COMP01

Selecione Manage

Selecione Settings

Selecione vSphere HA

O vSphere HA está atualmente desligado, clique em Edit

 

Pré-configuramos algumas das configurações do vSphere HA para você. Iremos demonstrá-las para sua referência.

 

 

 

Habilitar o HA no cluster estendido do Virtual SAN

 

Selecione Turn On vSphere HA

Expanda Failure conditions and VM response

 

 

Habilitar o HA no cluster estendido do Virtual SAN

 

Para VM restart priority, selecione High a partir da lista suspensa.

Para Response for Host Isolation, certifique-se de que Power off and restart VMs está selecionado.

Desça e expanda Admission Control

 

 

Habilitar o HA no cluster estendido do Virtual SAN

 

Se tivermos uma falha em determinado site, todas as nossas VMs podem ter que ser executadas em um único site, o que é efetivamente metade do cluster geral. Para garantir que as reservas possam ser satisfeitas, precisamos configurar o HA para reservar 50% dos recursos (isto é, um site).

Na seção Admission Control verifique o seguinte:

Define failover capacity by reserving a percentage of the cluster resources:

Reserved failover CPU capacity : 50%
Reserved failover Memory capacity : 50%

Expanda Datastore for Heartbeating

 

 

Habilitar o HA no cluster estendido do Virtual SAN

 

Selecione Use datastores only from the specified list

Expanda Advanced Options

 

 

Habilitar o HA no cluster estendido do Virtual SAN

 

Vamos explicar as configurações da seguinte maneira:

das.ignoreInsufficientHbDatastore: o HA irá reportar um problema de configuração de host se não for capaz de selecionar o número necessário de datastores para um host dado por das.heartbeatDsPerHost. Defina esta opção como true para suprimir este aviso, e false para habilitá-lo.

das.ignoreRedundantNetWarning : o HA irá reportar um problema de configuração em um host se o mesmo não estiver configurado com as redes redundantes para as redes utilizadas pelo HA. Antes do 5.5, o HA só usa redes de gerenciamento, enquanto que no 5.5, se o Virtual SAN estiver habilitado, o HA usará as redes configuradas para o Virtual SAN.

das.isolationAddressX : endereços de IP que um agente FDM utiliza para verificar se há isolamento quando não há tráfego de rede do agente observado na rede(*) usado pelo HA. O HA vai usar o gateway de rede de gerenciamento padrão como um endereço de isolamento por padrão, além dos especificados por esta opção avançada como endereços adicionais a serem verificados. É recomendável adicionar um endereço de isolamento para cada rede de gerenciamento utilizado pelo HA.(*) Antes do 5.5, o HA só usa a rede de gerenciamento, porém no 5.5, quando o Virtual SAN também está habilitado no cluster, o HA usará a rede do Virtual SAN para a comunicação entre agentes.

das.respectVmVmAntiAffinityRules : respeita as regras antiafinidade da vm-vm ao reiniciar as máquinas virtuais após uma falha. Os valores válidos são "false" (padrão) e "true"

das.useDefaultIsolationAddress : se o endereço de isolamento padrão (gateway de rede de gerenciamento) deve ser usado para determinar se um host é isolado da rede. Por padrão, o gateway padrão da rede de gerenciamento é usado. Se o gateway padrão é um endereço sem ping, defina o "das.isolationaddress" para um endereço com ping e desative o uso do gateway padrão definindo esta opção como "false".

Clique em OK para habilitar o vSphere HA

 

 

Habilitar o HA no cluster estendido do Virtual SAN

 

O vSphere será habilitado/ativado.

Se o vSphere HA falhar ao ser habilitado no ESXi host, clique com o botão direito no Host e selecione Reconfigure for HA.

 

 

Verifique o status do vSphere HA host

 

Em alguns casos, podemos encontrar um problema de instalação do agente do vSphere HA em um ou mais ESX hosts neste ambiente de laboratório.

A fim de resolver este problema, avance para corrigir os problemas de instalação do agente HA da seguinte forma:

  1. Navegue para Cluster -> RegionA01-COMP01
  2. Clique na guia Summary.
  3. O nome do host ou hosts encontrados com o erro serão listados aqui.

Avance para corrigir esse problema em cada host(s) listado(s).

 

 

Verificar o status do vSphere HA host

 

  1. Clique no host esx-01a (Neste exemplo, é o host esx-01a, no ambiente do seu laboratório, pode ser esx-02a, esx-03a ou esx-04a)
  2. Clique na guia Resumo para confirmar o problema como "O agente vSphere HA para este host apresenta um erro".

 

 

Verificar o status do vSphere HA host

 

  1. Clique com o botão direito no host.
  2. Clique no "Reconfigure for vSphere HA".

 

 

Verificar o status do vSphere HA host

 

Atualize o vSphere web client para garantir que o erro de HA seja corrigido e exibido na guia de resumo de cada host.

 

 

Configure o HA para respeitar as regras de afinidade da VM para o Host

 

Esta configuração mais uma vez define como o vSphere HA irá se comportar quando houver uma falha total em determinada localidade.

Esta configuração pode ser interpretada da seguinte forma:

Se houver vários hosts em ambos locais, e um host falhar, o vSphere HA irá tentar reiniciar a VM nos hosts restantes da localidade, mantendo afinidade de leitura.

Se houver uma falha total no local, então o vSphere HA tentará reiniciar as máquinas virtuais nos hosts no outro local. Se a opção must respect mostrada acima estivesse selecionada, o vSphere HA seria incapaz de reiniciar as máquinas virtuais no outro local, uma vez que infringiria a regra. Usar uma regra "should" lhe permite fazer exatamente isso.

 

 

Ativar as VMs

 

Ative as duas VMs chamadas VM-Primary e VM-Secondary.

O que você deve observar é que o VM-Primary está sendo executado no esx-01a.corp.local ou esx-02a.corp.local e o VM-Secondary está sendo executado no esx-03a.corp.local ou esx-04a.corp.local

O VM/Host Rules que criamos ditou isso.

Importante:  Anote o host ESXi no qual a VM-Primary está sendo executada, já que vamos precisar dessa informação em uma etapa futura.

 

 

Verifique a alocação do componente para a VM-01

 

Selecione VM-Primary

Selecione Monitor

Selecione Policies

Selecione Hard disk 1

Selecione Physical Disk Placement

O layout mostra que a VM foi implantada corretamente, com um componente por domínio de falha (Local) e com o componente de testemunha no host de testemunha (esx-07a.corp.local).

Como podemos ver claramente, uma cópia dos dados reside no armazenamento em Preferred Fault Domain, uma segunda cópia dos dados reside no armazenamento em Secondary Fault Domain e o componente de testemunha reside no host de testemunha e no armazenamento no local de testemunha.

 

 

 

Verificação de integridade do Virtual SAN

 

Antes de tentarmos algum cenário de falha, confirme se todas as verificações de integridade foram realizadas.

Ignore todos os avisos de integridade de compatibilidade de hardware, pois estamos executando em um ambiente virtualizado e não temos o serviço de desempenho do Virtual SAN ativado nesse cluster.

 

 

Cenário de falha - Reiniciar um único host

 

Aqui simularemos um Cenário de falha de host ESXi único e reiniciaremos um host único que tem um dos componentes da VM.

Selecione o host ESXi que executa a VM VM-Primary e reinicie-o. (O host ESX no seu ambiente pode ser diferente)

Selecione esx-02a.corp.local, clique com o botão direito e selecione Power -> Reboot

 

 

Cenário de falha - Reiniciar um único host

 

Selecione OK para reiniciar o host ESXi.

 

 

Componentes ausentes

 

Aguarde um pouco enquanto o host ESXi reinicia (sem responder) e até a VM VM-Primary poder ser acessada novamente.

Selecione a VM chamada VM-Primary

Selecione Monitor

Selecione Policies

Selecione Hard disk 1

Selecione Physical Disk Placement

Depois de algum tempo, enquanto o host ESXireinicia e a VM VM-Primary executa o failover como parte de um evento HA, você verá o Objeto do Virtual SAN no host em questão passar para o status Absent.

Você precisa ter paciência nessa etapa. Talvez seja necessário atualizar o vSphere Web Client.

 

 

Localização da VM

 

Aqui podemos ver que ocorreu um evento HA do vSphere e que a VM VM-Primary foi ativada no outro host (esx-01a.corp.local), no mesmo domínio de falha do Virtual SAN.

 

 

VM-Primary reiniciada no outro host

 

Altere novamente para a visualização Summary da VM chamada VM-Primary

Observe que a VM foi ativada no outro host ESXi chamado esx-01a.corp.local

 

 

Host ESXi totalmente reiniciado

 

Aguarde os hosts ESXi serem totalmente reiniciados e reconecte-se ao vCenter Server.

 

 

Verificação de integridade do Virtual SAN

 

Selecione RegionA01-COMP01

Selecione Monitor

Selecione Virtual SAN

Selecione Health

Execute novamente a verificação de integridade e observe se agora ela mostra que os testes foram aprovados.

 

 

Cenário de falha - Perda completa do site

 

Nesse cenário, simularemos a perda de um local inteiro. Local inteiro refere-se ao domínio de falha preferencial (esx-01a.corp.local e esx-02a.corp.local)

Selecione RegionA01-COMP01

Selecione Related Objects

Selecione Hosts

Selecione esx-01a.corp.local e esx-02a.corp.local (clique em esx-01a.corp.local, mantenha a tecla Ctrl pressionada e clique em esx-02a.corp.local)

Clique com o botão direito na seleção e selecione Power -> Reboot

 

 

 

Cenário de falha - Perda completa do site

 

Clique em Yes para realizar essa ação nos dois hosts ESXi.

 

 

Cenário de falha - Perda completa do site

 

Selecione All Hosts e clique em OK

 

 

Componentes ausentes

 

Aguarde um pouco enquanto os hosts ESXi reiniciam (sem responder) e até a VM VM-Primary poder ser acessada novamente.

Selecione a VM chamada VM-Primary

Selecione Monitor

Selecione Policies

Selecione Hard disk 1

Selecione Physical Disk Placement

Depois de algum tempo, enquanto o host ESXi reinicia e a VM VM-Primary executa o failover como parte de um evento HA, você verá o Objeto do Virtual SAN no host em questão passar para o status Absent.

Você precisa ter paciência nessa etapa. Talvez seja necessário atualizar o vSphere Web Client.

 

 

Localização da VM

 

Aqui podemos ver que ocorreu um evento HA do vSphere e que a VM VM-Primary foi ativada em um host (esx-04a.corp.local) no domínio de falha secundário do Virtual SAN.

 

 

 

Hosts ESXi totalmente reiniciados

 

Aguarde os hosts ESXi serem totalmente reiniciados e reconecte-se ao vCenter Server.

 

 

DRS - Parcialmente automatizado

 

Selecione RegionA01-COMP01

Selecione Monitor -> vSphere DRS -> Recommendations

Como temos DRS no Partially Automated Mode, DRS cuidará da colocação inicial das máquinas virtuais.  

No entanto, todas as recomendações de migração adicionais serão encaminhadas ao administrador, que decidirá se a máquina virtual deve ou não ser movida.

O administrador pode verificar a recomendação e optar por não migrar a máquina virtual.

Se nenhuma recomendação de DRS for exibida, clique em Run DRS Now.

Clique em Apply Recommendations

 

 

VM-Primary migrada para outro host

 

Selecione a VM chamada VM-Primary

Selecione Summary

Assim que a tarefa de migração estiver concluída, a VM chamada VM-Primary estará em execução no host ESXi chamado esxi-02a.corp.local

 

 

Tarefas do vSphere

 

Selecione Recent Tasks

Aqui podemos ver os resultados da tarefa de migração da máquina virtual, que migrou a VM chamada VM-Primary de esx-04a.corp.local de volta para esx-02a.corp.local.

 

 

Verificação de integridade do Virtual SAN

 

Selecione RegionA01-COMP01

Selecione Monitor

Selecione Virtual SAN

Selecione Health

Execute novamente a verificação de integridade e observe se agora ela mostra que os testes foram aprovados.

 

Conclusão



 

Você terminou o Módulo 3

Parabéns por concluir o Módulo 3.

Continue em qualquer módulo abaixo que seja do seu interesse. [Adicione informações personalizadas/opcionais para o manual do laboratório.]

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END (FIM). 

 

Módulo 4 - Monitoramento e solução de problemas (30 minutos, para iniciantes)

Introdução


Este Módulo discute o conjunto abrangente de ferramentas disponíveis para monitorar e solucionar problemas de um ambiente do Virtual SAN, além de como usar essas ferramentas para investigar e resolver problemas rapidamente no Virtual SAN. O Virtual SAN pode aproveitar as ferramentas já existentes do vSphere, bem como algumas ferramentas incorporadas específicas do Virtual SAN. Este capítulo aborda as seguintes ferramentas:

Verificação de integridade: um recurso incorporado que realiza uma série de testes no cluster do Virtual SAN e relata o que há de errado.

ESXCLI: a interface de linha de comando (CLI) do host ESXi.

Ruby vSphere Console (RVC): uma ferramenta genérica para gerenciar instâncias do vCenter Server, mas que também foi estendida para oferecer suporte ao Virtual SAN.

Serviço de desempenho: um novo recurso disponível no Virtual SAN 6.2 que fornece métricas de desempenho detalhadas sobre todos os aspectos do Virtual SAN.

Observador do Virtual SAN: um utilitário de desempenho on-line que potencializa o RVC.

ESXTOP: ferramenta de monitoramento de desempenho do host ESXi.

 


Preparação do laboratório


Usaremos o aplicativo PowerCLI do alternador de módulo para preparar o ambiente.


 

Alternadores de módulo

 

 

 

Alternador de módulo do laboratório de A a Z do Virtual SAN

 

  1. Clique duas vezes no atalho "1 HOL-1708-SDC-1 - VSAN A to Z"

 

 

Início do Módulo 4

 

  1. Clique no botão Module 4 Start

 

 

Monitorar o andamento

 

Monitore o andamento até o final.

 

 

Conclusão da preparação do laboratório

 

O laboratório foi preparado para o Módulo 4.

  1. Clique na janela Close para interromper o alternador de módulo com segurança

 

Lição 1: verificação de integridade do Virtual SAN



 

Verificação de integridade do Virtual SAN

No Virtual SAN 6.2, existem, por padrão, sete categorias de teste de verificação de integridade no total. São elas:

Se o Virtual SAN for implantado como um cluster estendido, haverá um conjunto adicional de verificações de integridade associado a essa configuração. Vamos analisar essas verificações de integridade em mais detalhes.

 

 

 

Integridade do Virtual SAN

 

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Health

Aqui, poderemos visualizar a lista detalhada de verificações de integridade no Virtual SAN 6.2.

Você pode expandir cada teste para ver os testes individuais que podem ser verificados.

 

 

Verificação de integridade do Virtual SAN - Pergunte para a VMware

 

Outro aspecto muito útil da verificação de integridade é os link "Ask VMware", que está presente em todos os testes. Para quem ainda não está familiarizado com o recurso Ask VMware, esses links levam os administradores diretamente para um artigo da base de conhecimento da VMware com detalhes sobre a finalidade do teste, motivos de uma falha e o que pode ser feito para remediar a situação. Se algum teste falhar, os administradores sempre deverão clicar no botão Ask VMware e ler o artigo associado da base de conhecimento. Em muitos casos, existem etapas que devem ser seguidas para solucionar o problema. Em outros casos, os administradores devem entrar em contato com o suporte VMware para obter mais assistência.

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Health

Expandaa verificação de integridade de dados

Selecione Virtual SAN object health

Observe onde está o botão Ask VMware

Ao clicar em Ask VMware, você acessará um artigo da base de conhecimento da VMware com explicações sobre a verificação de integridade do Virtual SAN e sobre como solucionar e corrigir estados de erro.

Nesse ambiente de laboratório, não temos acesso à Internet e, portanto, não podemos acessar o sistema da base de conhecimento da VMware. No entanto, capturamos um artigo da base de conhecimento de exemplo na próxima etapa para referência.

 

 

Exemplo da base de conhecimento do Virtual SAN

 

Veja um exemplo de um dos artigos da base de conhecimento que você acessa ao clicar em Ask VMware para saber mais sobre a verificação de integridade do Virtual SAN.

 

 

Integridade do Virtual SAN HCL

 

A integridade do Virtual SAN HCL (HCL é a forma abreviada de lista de compatibilidade de hardware) verifica se o hardware do controlador de armazenamento e a versão do driver estão na HCL e se há suporte para eles nessa versão do Virtual SAN. Se o controlador ou driver não estiver na HCL, ou se não houver suporte nessa versão do Virtual SAN (ou seja, a versão do ESXi em que o Virtual SAN está em execução), a verificação de integridade exibirá um aviso.

Outra verificação é executada para conferir se o Virtual SAN HCL DB está atualizado. Em outras palavras, as verificações executadas são feitas com base em uma versão válida e atualizada do banco de dados da HCL.

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Health

Expandaa compatibilidade do hardware

Os testes de driver do controlador e controlador SCSI serão exibidos como falhas em nosso ambiente de laboratório porque estamos executando esses laboratórios em um ambiente aninhado e não no hardware físico.

 

 

Atualização do banco de dados da HCL

 

Como a HCL é atualizada de maneira regular e com frequência, os administradores devem atualizar a versão local do banco de dados dessas verificações. Isso pode ser feito on-line (se o vCenter Server tiver acesso a VMware.com) ou, como alternativa, se o vCenter Server não estiver on-line, você poderá baixar um arquivo HCL DB e atualizá-lo. Para atualizar a versão do HCL DB on-line, basta clicar em "Upload from file" ou "Get latest version online" conforme mostrado no teste de verificação de integridade.

Um método alternativo é navegar até o objeto do cluster do Virtual SAN no inventário do vCenter Server, selecionar Manage, Health e Performance e, em seguida, clicar no botão "Get latest version online" na seção do banco de dados da HCL. O campo "Last updated" agora deve ter mudado para "Today".

 

 

 

Integridade do cluster

 

A verificação do cluster tem diversos testes diferentes associados. Em primeiro lugar, ela verifica se o serviço de verificação de integridade está instalado em todos os hosts do cluster. Em segundo lugar, ela verifica se todos os hosts estão em execução com uma versão atualizada e, finalmente, se o serviço verificação de integridade está funcionando.

Também existe uma verificação de integridade para conferir se alguns parâmetros avançados relacionados ao Virtual SAN estão definidos de maneira consistente em todos os hosts no cluster do Virtual SAN. Isso evitará o aparecimento de problemas relacionados a ter um subconjunto de hosts usando um valor e outro conjunto de hosts usando outro valor para uma determinada configuração avançada. Esse teste não valida se o valor é "bom" ou mesmo se é o valor "padrão". Ele simplesmente verifica se todos os hosts ESXi no cluster do Virtual SAN têm o mesmo valor.

Uma verificação final que vale ressaltar é o teste de ativação de CLOMD. CLOM, o gerenciador de objetos no nível do cluster, executa um daemon chamado clomd em cada host ESXi no cluster. CLOM é responsável por criar, reparar e migrar objetos, além de ser fundamental para processar vários fluxos de trabalho e falhas no Virtual SAN. Se clomd em algum host não estiver respondendo por algum motivo, esse teste falhará.

Várias verificações do cluster adicionais foram introduzidas no Virtual SAN 6.2 para aumentar a eficiência de espaço. Entre as novas verificações, a eficiência de espaço refere-se aos novos recursos de eliminação de duplicação e compactação do Virtual SAN 6.2. Basicamente, essas verificações conferem se todos os hosts e grupos de discos do cluster estão configurados corretamente com relação à eficiência de espaço e destacam os eventuais erros detectados no cluster.

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Health

Expanda Cluster

 

 

 

Integridade da rede

 

A seção de rede das verificações de integridade contém a maioria dos testes. Ela analisa todos os aspectos da configuração de rede, como verificar se cada host do cluster do Virtual SAN tem uma interface VMkernel configurada para o tráfego do Virtual SAN, ser capaz de executar ping entre todos os hosts na interface de rede do Virtual SAN e se todas as interfaces têm configurações de multicast correspondentes.

Também existem verificações de rede que conferem se todos os hosts ESXi no cluster do Virtual SAN estão associados ao vCenter Server, se nenhum host tem problemas de conectividade e se algum host do cluster não está participando do cluster do Virtual SAN. Há também a primeira verificação de integridade para saber se existe uma partição de rede.

Essa verificação de integridade informa quais hosts estão em quais partições, ou se existe uma partição de rede completa e se cada host está isolado um do outro (este último caso geralmente indica que há um problema de multicast na rede).

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Health

Expanda Network

 

 

Integridade dos dados

 

A integridade dos dados contém um teste: verificação do objeto do Virtual SAN. Esse teste verifica se todos os objetos implantados no datastore do Virtual SAN estão íntegros. Esse teste realça os objetos que não estão íntegros. Há alguns motivos por quê isso pode acontecer com um objeto. Isso pode acontecer porque um objeto tem disponibilidade reduzida ou porque os componentes foram recriados ou estão aguardando para serem recriados. Isso também pode ocorrer porque um objeto está completamente inacessível, possivelmente devido a várias falhas no cluster. O teste fornece uma visão geral de integridade do objeto que mostra os vários estados dos objetos. Se o Virtual SAN estiver aguardando o cronômetro de 60 minutos do CLOMD expirar antes de recriar componentes ausentes, um administrador poderá substituir essa configuração e iniciar uma recriação imediata (por exemplo, se um host falhar e não responder logo). Também pode mostrar aos administradores se a recriação dos componentes já está em andamento.

Selecione RegionA01-COMP01

Selecione Monitor - Virtual SAN - Health

ExpandaData

 

 

Integridade de limites

 

A verificação de integridade limita uma série de limites de clusters do Virtual SAN. No teste "current cluster situation", ele verifica o limite do componente, que é atualmente 9.000 por host. Ele também verifica a utilização de espaço do disco e, finalmente, verifica a reserva de cache de leitura, e se algum destes estão acima do limite, um aviso será lançado. Uma verificação de limite adicional examina o impacto que uma falha de host terá sobre os limites do cluster. Se algum dos limites forem ultrapassados quando uma falha de host é levada em conta, outro aviso é lançado. Isto é, em alguns aspectos semelhantes ao controle de admissão no vSphere HA em que auxiliam os administradores no monitoramento se há ou não recursos suficientes para o Virtual SAN se recuperar em caso de uma falha.

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Health

Expande os limites 

 

 

Integridade de disco físico

 

A integridade do disco físico contém um número significativo de verificações que examina vários aspectos do armazenamento Virtual SAN. A verificação de integridade de discos em geral procura várias questões sobre as unidades de disco físicas, incluindo questões superficiais, problemas do controlador, problemas de driver e problemas com a pilha de I/O. Este teste também irá falhar se houver quaisquer erros encontrados nesta verificação de integridade, como a integridade dos metadados, congestão, estado software ou problemas de capacidade de disco. Se este teste falhar, os administradores precisarão procurar porque outros testes não conseguiram determinar a causa principal.

O teste de integridade limite do componente, verifica se o limite superior do número de componentes por disco não foi excedido. Este é um valor muito grande, na região de 50.000, mas este teste de verificação de integridade irá destacar se algum disco atingiu a saturação a partir de uma perspectiva de contagem de componentes. O congestionamento é um outro teste interessante para os administradores. Isso pode ser um indicador de que o Virtual SAN pode estar sendo executado com desempenho reduzido. As razões para o congestionamento são variadas e normalmente requerem uma investigação mais aprofundada. Alguns exemplos são um cluster do Virtual SAN subdimensionado para a carga de trabalho em execução, hardware/driver/firmware ruim no controlador de armazenamento ou até mesmo problemas de software.

A capacidade do disco relata avisos se o uso do disco físico está começando a se tornar um problema. Se o espaço em disco físico estiver abaixo de 80%, em seguida, os relatórios teste estarão marcados como OK (verde). Se o uso do disco situa-se entre 80% e 95%, a integridade irá mostrar um aviso (amarelo). Se o uso estiver acima de 95%, um alerta (vermelho) é lançado pela verificação de integridade. O limite é de 80%, onde o reequilíbrio automático começa a ocorrer.

Um último conjunto de testes para mencionar na verificação de integridade do disco físico são os testes de pool de memória. Embora pouco provável de ocorrer, estes testes verificam para garantir que as pilhas e slabs utilizadas pelo Virtual SAN não estão funcionando baixo. Caso os testes de verificação de integridade mostrem avisos, o conselho é entrar em contato com o suporte do VMware para determinar a razão pela qual. Executar poucas pools de memória pode levar a problemas de desempenho ou até mesmo falhas operacionais.

Selecione RegionA01-COMP01

Selecione Monitor -> Virtual SAN -> Health

Expanda Physical Disk 

 

Lição 2: gráficos de desempenho


Com o lançamento do Virtual SAN 6.2 Performance Service, o VMware está providenciando relatórios de desempenho básicos do Virtual SAN a partir do vSphere Web Client. As metas são ter esse recurso "always on", totalmente integrado com a UI do vSphere Web Client, fáceis de acessar e consumir e manter os dados históricos de desempenho do Virtual SAN.

Um objeto de namespace do Virtual SAN é usado para armazenar um banco de dados de estatísticas (stats DB). O objeto é regular (stats object) e tem uma política associada a ele. A política é escolhida quando o administrador habilitar o serviço de desempenho. Se nenhuma política específica for escolhida, a política de datastore do Virtual SAN padrão será usada. A política padrão possui o NumberOfFailuresToTolerate definido como 1, o que implica que, se houver uma falha no cluster do Virtual SAN, o serviço de desempenho não é afetado e continuará a ser executado. Portanto, o serviço de desempenho não tem nenhum ponto único de falha.

Em cada host ESXi no cluster do Virtual SAN, o serviço de desempenho executa um daemon para coletar métricas de desempenho. As métricas são calculadas em média ao longo de intervalos de 5 minutos. A coleta de estatísticas está sempre ligada. Estas estatísticas são armazenadas no stats DB no stats object. Isto implica que o vCenter server não é necessário para qualquer aspecto da infraestrutura de estatísticas, tais como a configuração, coleta, armazenamento e consulta.


 

Habilitar serviço de desempenho

 

Ao criar um novo cluster do Virtual SAN, o serviço de desempenho está desabilitado. Ative o serviço de desempenho do Virtual SAN para monitorar o desempenho dos clusters, hosts, discos e VMs do Virtual SAN. Ao ativar o serviço de desempenho, o Virtual SAN colocar um Stats database object no datastore para coletar dados estatísticos. A Stats database é um objeto de namespace situado no datastore do Virtual SAN do cluster.

Antes de ativar o serviço desempenho do Virtual SAN, certifique-se de que o cluster está configurado corretamente e que não há problemas de integridade pendentes.

Selecione RegionA01-COMP01

Selecione Manage -> Settings -> Health and Performance

Para habilitar o Serviço de desempenho, clique em Edit

 

 

Habilitar serviço de desempenho

 

Selecione a caixa de seleção Turn On Virtual SAN performance service .

Selecione uma storage policy para o Stats database object.

Selecione o Virtual SAN Default Policy

O Virtual SAN Default Storage Policy é seleciona por padrão. Isto inclui o atributo de política do NumberOfFailuresToTolerate definido como 1, tornando o serviço de desempenho altamente disponível.

Clique em OK

 

 

Habilitar serviço de desempenho

 

Selecione RegionA01-COMP01 -> Manage -> Settings -> Health and Performance

Ao examinar o status de desempenho do serviço, depois de ter sido habilitado, um status semelhante a este deve ser visto.

A partir daqui, é possível Desativar ou Editar a política de armazenamento em uso pelo Serviço de desempenho.

 

 

Cluster - Virtual SAN - Virtual Machine Consumption

 

Selecione RegionA01-COMP01 -> Monitor -> Performance -> Virtual SAN - Virtual Machine Consumption

Você pode usar o serviço de desempenho do Virtual SAN para monitorar o desempenho do seu ambiente de Virtual SAN e investigar possíveis problemas.

O serviço de desempenho recolhe e analisa estatísticas de desempenho e apresenta os dados em um formato gráfico para que você possa determinar a causa principal dos problemas. Você pode visualizar gráficos de desempenho do cluster e de cada host, grupo de disco e disco no cluster do Virtual SAN. Você também pode exibir gráficos de desempenho de máquinas virtuais e discos virtuais.

O Serviço de desempenho do Virtual SAN exibe gráficos de desempenho que você pode usar para monitorar a carga de trabalho e ajudá-lo a determinar a causa raiz dos problemas.

Quando o Serviço de desempenho está ativado, o Resumo do cluster exibe uma visão geral das estatísticas de desempenho do Virtual SAN, incluindo a capacidade, rendimento IOPS e latência do Virtual SAN. No nível do cluster, você pode visualizar gráficos estatísticos detalhados sobre o consumo da máquina virtual e o backend do Virtual SAN.

 

 

Cluster - Virtual SAN - Backend

 

Selecione RegionA01-COMP01 -> Monitor -> Performance -> Virtual SAN - Backend

O Virtual SAN exibe gráficos de desempenho das operações de backend do host, incluindo IOPS, throughput, latência, congestionamento e I/O pendente. Em cada host ESXi no cluster do Virtual SAN, o serviço de desempenho executa um daemon para coletar métricas de desempenho.

As métricas são calculadas em média ao longo de intervalos de 5 minutos.

 

 

Cluster - Virtual SAN - Consumo das Máquinas Virtuais

 

 

 

Cluster - Virtual SAN - Backend

 

 

Lição 3: ESXCLI


O ESXi 5.5 U1 apresentou um novo namespace ESXi CLI (ESXCLI): esxcli vsan. Este tem uma seleção de namespaces adicionais que podem ser utilizados para examinar, monitorar e configurar o cluster do Virtual SAN.


 

Conectando ao host ESXi

 

 

 

ESXCLI VSAN

 

 

 

ESXCLI VSAN DATASTORE

 

O esxcli vsan datastore namespace fornece comandos para configuração do datastore do Virtual SAN. Há muito pouco que pode ser feito aqui além de obter e definir o nome do datastore do Virtual SAN. Por padrão, o nome do datastore do Virtual SAN é vsanDatastore. Se você está pensando em mudar o nome do vsanDatastore, faça isso no nível do cluster através do vSphere Web Client. É altamente recomendável ao gerenciar vários clusters Virtual SAN a partir do mesmo vCenter Server, deste modo os datastores do Virtual SAN recebem nomes únicos, facilmente identificáveis.

Execute o seguinte comando:

esxcli vsan datastore name get

 

 

esxcli vsan network list

 

Este namespace fornece comandos para configuração de rede do Virtual SAN. É um pouco mais útil do que o namespace de datastore anterior, uma vez que permite listar a configuração atual, desmarcar a configuração atual, restaurar a configuração de rede do Virtual SAN (isto é usado durante o processo de inicialização pelo ESXi e não é destinado a invocação do cliente), bem como para remover uma interface a partir da configuração de rede do Virtual SAN,

Execute o seguinte comando:

esxcli vsan network list

O que é interessante de ver aqui é a informação multicast, há uma exigência para permitir o tráfego multicast entre ESXi hosts participantes no cluster do Virtual SAN. Outro ponto interessante a se notar é que a versão inicial do Virtual SAN suportava apenas IPv4. O Virtual SAN 6.2 suporta IPv6. No entanto, são os detalhes do multicast que são de maior interesse. O Agent Group Multicast Port corresponde às portas cmmds abertas no firewall do ESXi quando o VSAN está ativado. O primeiro endereço de IP, 224.2.3.4, é usado pelo master/comunicação de backup, enquanto o segundo endereço, 224.1.2.3, é usado por agentes.

O esxcli vsan network list é um comando útil para visualizar a configuração de rede e status corrente em uma partição de rede.

 

 

 

 

esxcli vsan storage

 

Este namespace é usado para configuração de armazenamento e inclui opções sobre como o Virtual SAN deve reivindicar discos, bem como a capacidade de adicionar e remover discos físicos ao Virtual SAN. O comando esxcli vsan storage automode permite obter ou definir a opção auto reivindicação. Se estiver desativado, o cluster estará no modo manual,

Para exibir os dispositivos da camada de capacidade e de cache que foram reivindicadas e estão em uso pelo Virtual SAN a partir de um determinado ESXi host, você pode usar a opção de lista. Nesta configuração em particular, a qual é uma configuração baseada somente em flash, os SSDs são utilizados para os dispositivos da camada de capacidade e de cache. Todos os dispositivos têm uma marcação "true" no campo "Used by this host", indicando que eles foram reivindicados pelo Virtual SAN. Já o campo "Is SSD" indica o tipo de dispositivo (true para dispositivos flash),

 

 

 

esxcli vsan cluster

 

O comando esxcli vsan cluster permite que o ESXi host no qual o comando é executado para obter informações sobre o cluster do Virtual SAN, bem como permitir que o ESXi host saia ou ingresse em um cluster do Virtual SAN. Isto pode ser muito útil em um cenário onde o vCenter Server não está disponível e um determinado host precisa ser removido do cluster do Virtual SAN. A funcionalidade de restauração não se destina a invocação do cliente e é usado pelo ESXi durante o processo de inicialização, para restaurar a configuração do cluster ativo do arquivo de configuração,

Execute o seguinte comando:

esxcli vsan cluster get

A opção get para neste comando é útil para reunir informações sobre a integridade dos ESXi hosts locais (nós), bem como seu papel no cluster. Você pode observar que este ESXi host é o MASTER e seu status é ÍNTEGRO. Os outros estados são agentes e backup. Esses estados se relacionam com o papel desempenhado pelo host para o serviço de cluster (CMMDS).

Uma peça útil adicional de informação a partir desta saída são os UUIDs membros do subcluster. Existem quatro entradas neste campo, no total, o que indica que este é um cluster de 4 nós. Isto é sempre útil para mostrar quantos nós cada host acha que está participando do cluster quando se trata de questões de solução de problemas de partição. Se você deseja exibir qual host corresponde a qual UUID, você pode usar o comando esxcli system uuid get < uuid >.

Execute o seguinte comando:

esxcli system uuid get 

Isso vai lhe dizer o UUID do nó que você está conectado.

 

 

esxcli vsan faultdomain

 

Os domínios de falha foram introduzidos no Virtual SAN 6.0 e permitem que o Virtual SAN seja "rack aware". Isto significa que os componentes que pertencem aos objetos que são parte da mesma máquina virtual possam ser colocados não apenas em hosts diferentes, mas em diferentes racks ou domínios de falhas. Isto significa que, se um rack inteiro falhar (por exemplo, falta de energia), existe ainda um conjunto completo de componentes de máquinas virtuais disponíveis para que a máquina virtual permaneça acessível.

Execute o seguinte comando:

esxcli vsan faultdomain get

Domínios de falhas também são utilizados por clusters estendidos do Virtual SAN e configurações de 2 nós. Estes já foram discutidos anteriormente no laboratório. É improvável que você vá precisar usar esta namespace esxcli vsan faultdomain para tal configuração. O VMware recomenda usar a UI do vSphere Web Client para todas as configurações de domínios de falha, cluster expandido e 2 nós (ROBO).

 

 

 

esxcli vsan policy

 

O Virtual SAN associa uma política de armazenamento padrão com os objetos de armazenamento da VM, e o namespace esxcli vsan policy é uma maneira de examinar e modificar esta política de armazenamento padrão.

Execute o seguinte comando:

esxcli vsan policy getdefault

Aqui podemos ver os diferentes objetos de armazenamento de VM que compõem uma VM implementada em um armazenamento de dados Virtual SAN, e também podemos ver os valores de política padrão.

A classe vdisk refere-se aos objetos de disco da VM (VMDKs). Abrange também deltas de snapshots. A classe vmnamespace é o namespace inicial da VM onde os arquivos de configuração, arquivos de metadados e arquivos de log pertencentes à VM estão armazenados. A classe política vmswap é, naturalmente, o VM Swap. Uma nota final para vmswap é que ele também possui um valor forceProvisioning. Isto significa que, mesmo se não houver recursos suficientes no cluster do Virtual SAN para atender o requerimento de provisionamento de ambas as réplicas VM Swap, o Virtual SAN ainda irá dispor a VM com uma única instância VM Swap.

 

 

 

esxcli vsan trace

 

esxcli vsan trace é um utilitário de solução de problemas e diagnóstico, e não deve ser usado sem a orientação de serviços de suporte globais da VMware (GSS). Ele é projetado para capturar diagnósticos internos do Virtual SAN para análise posterior.

Execute o seguinte comando:

esxcli vsan trace set -h

 

 

vdq (1)

 

O comando vdq serve para dois propósitos e é realmente uma grande ferramenta de resolução de problemas para se ter no ESXi host. A primeira opção para este comando informa se os discos em seu ESXi host são elegíveis para o Virtual SAN, e se não, qual é a razão para o disco ser inelegível. A segunda opção para este comando é que, uma vez ativado o Virtual SAN, você pode usar este comando para exibir informações de mapeamento do disco, que é essencialmente quais dispositivos SSD (ou Flash) e discos rígidos foram agrupados em um grupo de discos. Vamos primeiro executar a opção de consultar todos os discos de elegibilidade para uso do Virtual SAN.

Execute o seguinte comando:

vdq -q

Como você pode ver, uma série de dispositivos têm sido reivindicados pelo Virtual SAN, enquanto outro disco está inelegível, pois já tem partições. Neste exemplo, o disco não elegível é o disco de inicialização do ESXi host. Ele também aponta qual disco é um disco SSD (IsSSD), se um dispositivo flash está sendo usado como um dispositivo de capacidade em uma configuração somente flash do Virtual SAN (IsCapacityFlash) e se o disco está em um estado de "perda de dispositivo permanente" (IsPDL).

 

 

 

vdq (2)

 

A segunda opção útil para o comando é apresentar os mapeamentos de disco do Virtual SAN. Em outras palavras, dispositivos flash e discos rígidos que estão em um grupo de discos.

Execute o seguinte comando:

vdq -i -H

A saída de exemplo (a qual inclui a opção -H para torná-lo mais legível):

Este comando mostra a relação de SSD com dispositivos de capacidade, sejam dispositivos flash, no caso da configurações All flash ou discos magnéticos em caso de configurações híbridas. Observe que mesmo que estes sejam dispositivos flash, eles são mostrados como HD (discos magnéticos) nesta saída. O campo IsCapacityFlash precisaria ser examinado para ver se esses são dispositivos flash (por exemplo, SSD) ou não. Isto é muito útil se você quiser saber o layout do grupo de disco em um determinado host na linha de comando. Este comando irá informá-lo rapidamente quais discos magnéticos são liderados por cada SSD, especialmente quando você tem vários grupos de discos definidos em um ESXi host.

 

Conclusão



 

Você terminou o Módulo 4

Parabéns por concluir o Módulo 4.

Continue em qualquer módulo abaixo que seja do seu interesse. [Adicione informações personalizadas/opcionais para o manual do laboratório.]

 

 

Como trabalhar com o alternador de módulo

 

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END (FIM). 

 

Módulo 5 - Automação do Virtual SAN (30 minutos, avançado)

Introdução


Existem várias abordagens para a criação de scripts e permissão da automação em ambientes Virtual SAN da VMware.

Neste módulo iremos ilustrar três métodos diferentes:

  1. PowerCLI
  2. ESXCLI
  3. Ruby vSphere Console (RVC)

Preparação do laboratório


Usaremos o aplicativo PowerCLI do alternador de módulo para preparar o ambiente.


 

Alternadores de módulo

 

 

 

Alternador de módulo do laboratório de A a Z do Virtual SAN

 

  1. Clique duas vezes no atalho "1 HOL-1708-SDC-1 - VSAN A to Z"

 

 

Início do Módulo 4

 

  1. Clique no botão Module 5 Start

 

 

Monitorar o andamento

 

Monitore o andamento até o final.

 

 

Conclusão da preparação do laboratório

 

O laboratório foi preparado para o Módulo 5.

  1. Clique na janela Close para interromper o alternador de módulo com segurança

 

Lição 1: PowerCLI/ESXCLI



 

Examinar o cluster Virtual SAN

 

Vamos conectar à nossa instância VirtualCenter e começar a nossa exploração do Virtual SAN PowerCLI.

Dica: os comandos PowerCLI deste laboratório não levam em consideração letras maiúsculas e minúsculas. Se preferir copiar e colar esses comandos, você vai encontrar uma lista completa deles dentro do arquivo 'README HOL-SDC-1708-1.txt' no Desktop.  Alternativamente, você pode simplesmente destacar o comando manual (Copie-o para a área de transferência) e, em seguida, usar o recurso "Enviar texto" dos Hands On Labs que está disponível no canto superior esquerdo do seu Lab.  

Connect-VIServer -Server vcsa-01a.corp.local -User administrator@corp.local -Password VMware1!

Cria uma variável para o primeiro vSphere Host no cluster do Virtual SAN, a fim de tornar os seus comandos de PowerCLI mais fácil de serem gerenciados.

$vmhost = "esx-01a.corp.local"
$vmhost

 

 

Verificar configuração de clusters

 

Examine o estado habilitado do Virtual SAN e o modo de reivindicação de disco do Virtual SAN, emitindo este comando:

Get-Cluster | Select Name, VsanEnabled, VsanDiskClaimMode | Format-List

 Temos 2 clusters do vSphere no nosso ambiente. O cluster do Virtual SAN é chamado RegionA01-COMP01. Aqui, podemos ver que o Virtual SAN está habilitado e o Modo de reivindicação de disco está Manual.

 

 

Verifique as configuração da rede

 

A comunicação de rede do Virtual SAN, entre os hosts no nosso cluster do Virtual SAN, é habilitada através de portas VMkernel redundantes que estão configuradas em um único vSphere Distributed Switch.

Let's examinar esta configuração:

Get-VDSwitch -VMHost $vmhost

Agora, examine os Port groups (pressione a tecla seta para cima uma vez para repetir o comando anterior e leve para o cmdlet abaixo):

Get-VDSwitch -VMHost $vmhost | Get-VDPortgroup

Verifique se o Virtual SAN Traffic está habilitado nas portas do VMkernel dedicadas ao Virtual SAN:

Get-VMHostNetworkAdapter -VMhost $vmhost | select PortGroupName, name, VsanTrafficEnabled | Format-Table -autosize

 

 

Verificar configuração do disco

 

Examine os datastores que estão disponíveis para o nosso host do vSphere usando o Get-Datastore cmdlet.  Filtraremos os resultados em qualquer datastores contendo "Virtual SAN" no seu nome.

Get-Datastore -VMHost $vmhost | where-object {$_.Type -like "vsan"} 

Cria uma variável que contém nossos Grupos de discos do Virtual SAN.  Usaremos a mesma variável $vmhost (esx-01a.corp.local) já utilizada anteriormente.

$dg = Get-VsanDiskGroup -VMHost $vmhost

Examine os conteúdos da variável recém-criada.

$dg

Vamos identificar os discos que fazem parte destes Grupos de discos do Virtual SAN (observe a combinação de SSD e discos rígidos através da coluna 'IsSsd'):

$dg | Get-VsanDisk

 

 

 

Políticas de armazenamento do Virtual SAN

 

Examine as Políticas de armazenamento do Virtual SAN disponíveis no nosso ambiente:

Get-SpbmStoragePolicy -requirement -namespace "VSAN" | Select Name, Description

Observe que nós limitamos a lista usando o [-namespace "VSAN"]. O 'VVol No Requirements Policy' não está relacionado ao Virtual SAN, portanto, não aparece no nosso conjunto de resultados.

 

 

Photon-Temp VM

 

Vamos ativar o vMotion em uma máquina virtual para o datastore do Virtual SAN, para que possamos criar programaticamente e aplicar novas Políticas de armazenamento.

Executaremos uma máquina virtual que usa o mais novo sistema operacional de código aberto baseado em Linux da VMware, "Photon".

Primeiro, vamos definir nossas variáveis para a máquina virtual e o datastore do Virtual SAN:

$vm = "Photon-Temp"
$vsanDatastore = "RegionA01-VSAN-COMP01"

Ligue a máquina virtual:

Start-VM -VM $vm

Migra a máquina virtual para o cluster e datastore do Virtual SAN (isso vai demorar apenas alguns minutos):

Get-VM -Name $VM | Move-VM -Destination $VMhost -Datastore $vsanDatastore

 

 

Novo cenário de política

 

Neste seção iremos criar uma nova Política baseada em armazenamento que a Stripe Width de'1' para '2'.

Esta nova política poderia ser aproveitada para melhorar o desempenho, pois cria um stripe RAID-0 através de dois discos, aumentando assim a quantidade de armazenamento de I/O disponíveis.  Esta política também herdará a configuração "Failures to Tolerate = 1" que indica que qualquer VM com esta política pode sobreviver a pelo menos uma falha de componente Virtual SAN no ambiente.

 

 

Preparar variáveis

 

Lembrete: os comandos PowerCLI estão disponíveis para copiar/colar através do arquivo README.txt no Desktop.

Verifique se sua variável $VM está definida como "Photon-Temp":

$vm

Crie uma nova variável que captura os discos rígidos para a VM Photon-Temp:

$vmHdd = Get-HardDisk $vm

Verifique a Política de armazenamento atual aplicada à nossa máquina virtual Photon e seus discos rígidos virtuais:

Get-SpbmEntityConfiguration $vm, $vmHdd

 

 

 

Criar uma Nova política

 

Crie a nova Política de armazenamento de VM (usando Stripe Width = 2):

New-SpbmStoragePolicy -Name Stripe-Width=2 -RuleSet (New-SpbmRuleSet -Name "Stripe-Width=2" -AllOfRules @((New-SpbmRule -Capability VSAN.stripeWidth 2)))

Use a seta para cima algumas vezes para repetir este comando ou digite novamente para confirmar a criação de políticas:

Get-SpbmStoragePolicy -requirement -namespace "VSAN" | Select Name, Description

 

 

Aplicar nova política

 

Aplicar a política de armazenamento recém-criada para a nossa máquina virtual Photon usando as variáveis previamente criadas:

Set-SpbmEntityConfiguration $vm, $vmHdd -StoragePolicy "Stripe-Width=2" -ErrorAction SilentlyContinue

Observação: o disco rígido da máquina virtual irá inicialmente retornar um status "nonCompliant".  O Virtual SAN está configurando distribuições adicionais de acordo com a política recém-aplicada e esta operação de sincronização pode demorar alguns minutos para ser concluída.

 

 

Conformidade de política de armazenamento de VM

 

Observação: se você quiser verificar novamente o status de conformidade da VM Photon e a nova política de armazenamento que você aplicou, emita este comando:

Get-SpbmEntityConfiguration $vm, $vmHdd -CheckComplianceNow  

 

 

ESXCLI através de comandos PowerCLI

Historicamente, os administradores do vSphere tiveram a habilidade do SSH diretamente para um host do vSphere e resolver comandos do ESXCLI diretamente.

Com o Virtual SAN 6, há novas opções de comandos do ESXCLI que podem ser executadas no namespace do Virtual SAN do ESXCLI.  Nesta seção, vamos 'englobar' estes comandos do esxcli remotos através do PowerCLI(utilizando o 'Get-ESXCLI' Powershell cmdlet).  Isso pode ser feito dentro da janela de comando do PowerCLI existente que abrimos e irá remover a necessidade de SSH para um host remoto.

 

 

Crie o objeto Get-EsxCli

 

Vamos definir uma variável que pode executar comandos futuros contra:

$esxcli = Get-EsxCli -VMhost $vmhost -V2

Entre nossa nova variável e pressione Enter ou Return para exibir todos os namespaces disponíveis:

$esxcli

Acrescente o elemento Virtual SAN à nossa variável para exibir os namespaces específicos do Virtual SAN. Isso nos dará uma lista de todos os comandos esxcli possíveis relacionados com o Virtual SAN.

$esxcli.vsan

 

 

 

Methods Exposed - Cluster

 

Aprofundar ainda mais através da análise do elemento "cluster":

$esxcli.vsan.cluster

Observe que os métodos estão agora disponíveis para nós utilizarmos ("get","join", "leave","new" e "restore").  Vamos utilizar o método get com um parâmetro vazio definido para examinar mais detalhes sobre nosso cluster do Virtual SAN, incluindo o Estado de integridade do host do vSphere:

$esxcli.vsan.cluster.get.Invoke()

 

 

Methods Exposed - Network

 

Examine as configurações de rede:

$esxcli.vsan.network.list.Invoke()

 

 

Methods Exposed - Datastore

 

Recupera o nome do datastore do Virtual SAN:

$esxcli.vsan.datastore.name.get.Invoke()

Isso inclui nossa lição PowerCLI/ESXCLI.

 

Lição 2: Ruby vSphere Console (RVC)


O Ruby vSphere Console (RVC) é uma interface de usuário interativa de linha de comando para o  VMware vSphere e Virtual Center. O Ruby vSphere Console é baseado na popular interface RbVmomi Ruby para a API do vSphere e tem sido um projeto de código aberto nos últimos 2-3 anos. O RbVmomi foi criado com o objetivo de diminuir drasticamente a quantidade de codificação necessária para executar tarefas de rotina, bem como aumentar a eficiência da execução da tarefa, tudo isso enquanto ainda permite o pleno poder da API quando necessário.

O Ruby vSphere Console vem com ambos os vCenter Server Appliance (VCSA) e versão do Windows do vCenter Server. O RVC está rapidamente se tornando uma das principais ferramentas para gerenciamento e resolução de problemas em ambientes Virtual SAN.


 

Recursos

O RVC tem um monte de recursos que você esperaria de uma interface de linha de comando moderna.

 

 

Vantagens

 

 

Uso (1)

 

O Ruby vSphere Console é gratuito e vem com ambos os vCenter Server Appliance (VCSA) e vCenter Server para Windows.  Neste laboratório, vamos conectar à nossa instância do VCSA e explorar alguns recursos relacionados ao RVC do Virtual SAN.

  1. Inicie o Putty através dos atalhos de ferramentas
  2. Role para baixo e clique duas vezes em vcsa-01a.corp.local

 

 

 

Uso (2)

 

Inicie o RVC emitindo o seguinte comando:

rvc localhost 

Digite 'Y' se for solicitado com, "Tem certeza que deseja continuar conectado?"

Digite a senha quando solicitado:  VMware1!

 

 

Navegação

 

O vSphere e a infraestrutura Virtual SAN são apresentados ao usuário como um sistema de arquivos virtual, que pode ser navegado com comandos de listagem de diretório (ls) tradicional e alteração do diretório (cd). Este sistema de arquivos virtual espelha a hierarquia da infraestrutura vSphere e permite que comandos RVC sejam emitidos em cada uma das entidades gerenciáveis e seus componentes individuais (isto é, vCenter, datacenter, cluster, armazenamento, hosts, redes, datastores e VMs).

Navega através da estrutura de diretórios usando os comandos 'cd' e 'ls'.  O texto entre parênteses abaixo serve apenas como referência e não deve ser digitado.  Os comandos 'cd' utilizam os números '1' e '0':

cd 1  (localhost)

Lista os datacenters que estão disponíveis através do comando 'ls':

ls

Muda para o diretório dos datacenters e lista os recursos que estão disponíveis:

cd 0  (RegionA01)
ls

Muda para o diretório dos computadores e lista os Clusters vSphere e vSphere Hosts que estão disponíveis:

cd 1  (computers)
ls

Muda para o diretório do cluster do vSphere e lista os hosts e pools de recursos deste cluster:

cd 1  (RegionA01-COMP01)
ls

Muda para o nosso diretório do host e lista os hosts do vSphere individuais neste cluster, juntamente com os detalhes de CPU e memória:

cd 0  (Hosts)
ls

 

 

Informação do host do Virtual SAN

 

Examine as informações do host para o host esx-04a.corp.local no cluster do VSAN digitando:

vsan.host_info 1

 

 

Informação no nível do cluster do Virtual SAN

 

Tal como mencionado na seção "Vantagens" anterior, o RVC não se limita a trabalhar com um vSphere Host único de cada vez.  Por exemplo, você pode reunir estatísticas de disco para todos os hosts no cluster pelo cd-ing de volta a dois diretórios para o diretório "computador" e, em seguida, comandar a re-emissão de suas estatísticas de disco:

cd ..
cd ..
ls
vsan.disks_stats 1

Observação: Pode ser necessário aumentar o tamanho da janela do Putty, arrastando a alça do canto para que o resultado da tabela definido saia corretamente.

 

 

exec.

 

Há mais de 40 comandos Virtual SAN Namespace diferentes que podem ser usados para gerenciar o ambiente através do Ruby vSphere Console.  Você pode ver os comandos Virtual SAN Namespace, emitindo este comando (e rolar para cima para ver os resultados):

help vsan

Para ver todos os Namespace disponíveis para gerenciar através do Ruby vSphere Console, basta emitir este comando:

help

Quando terminar de explorar, digite "exit" para fechar a sessão do Ruby vSphere Console e digite "exit" novamente para fechar o Putty SSH Session.

 

Conclusão


Conforme ilustrado neste módulo, há uma variedade de ferramentas CLI à sua disposição para interagir programaticamente com o Virtual SAN.

Escolher a melhor ferramenta que funciona para você vai alavancar o princípio fundamental do Software Defined Data Center: Automação.


 

Você terminou o Módulo 5

Parabéns por concluir o Módulo 5.

Se você estiver procurando por informações adicionais sobre Virtual SAN Automation, tente em um destes:

PowerCLI

ESXCLI

Ruby vSphere Console (RVC):

Proceda a qualquer módulo abaixo se você ainda não os tiver concluído ou caso queira revê-los.

 

 

Como trabalhar com o alternador de módulo

 

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END (FIM).  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1708-SDC-1-PT

Version: 20161012-074319