quarta-feira, 21 de setembro de 2016

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

                 

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

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

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

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

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

 Fonte: VMware 

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

- Tipo de disco (SSD, SATA, SAS, FC);
- Tipo de proteção (local, remota)
- Tipo de volume (thin, thick)
- Dedup;

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

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


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

- Number of disk stripes per object
- Flash read cache reservation
- Failures to tolerate
- Fault tolerance method
- IOPS limit for object (QoS)
- Disable object checksum
- Force provisioning
- Object space reservation

Number of disk stripes per object

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

Flash read cache reservation

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

Failures to tolerate

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

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

Fault tolerance method

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

IOPS limit for object (QoS)

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

Disable object checksum

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

Force provisioning

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

Object space reservation

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

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


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


Outros posts da série VMware Virtual SAN 6.2: 
VMware Virtual SAN 6.2 – Parte 4 – VASA e as Políticas de Armazenamento

terça-feira, 13 de setembro de 2016

Novos Labs disponíveis no VMware Hands-on Labs

                 

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

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

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

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

HOL-1701-USE-1 Introduction to the vSphere Optimization Assessment
         
HOL-1701-USE-2 vRealize Operations and vRealize Business: Optimize Compute Utilization

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

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

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

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

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

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

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

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

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

HOL-1706-SDC-5 VMware Cloud Foundation Fundamentals

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

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

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

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

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

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

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

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

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

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

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

HOL-1725-SDC-1 VMware NSX Advanced Consumption

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

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

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

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

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

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

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

HOL-1751-MBL-6 Horizon 7 Advanced Concepts

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

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

HOL-1757-MBL-1 Introduction to VMware AirWatch

HOL-1757-MBL-2 Advanced VMware AirWatch

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

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

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

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

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

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

quinta-feira, 25 de agosto de 2016

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

                 

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

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

Estrutura Física

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

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

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

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

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

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

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

       Fonte: VMware

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

Estrutura Lógica

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

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

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


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

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

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

 
Fonte: VMware

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

Fonte: VMware

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

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

Outros posts da série VMware Virtual SAN 6.2: 

VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN

quarta-feira, 17 de agosto de 2016

VMware Virtual SAN 6.2 – Parte 2 – Licenciamento

                 

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

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

 

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

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

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

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

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

Outros posts da série VMware Virtual SAN 6.2: 
VMware Virtual SAN 6.2 – Parte 1 – Introdução
VMware Virtual SAN 6.2 – Parte 2 – Licenciamento
VMware Virtual SAN 6.2 – Parte 3 – Arquitetura VSAN