Propriamente endereçando arquivos de Swap em ambiente VMware

Não é raro hoje em dia se deparar com VMs com 16, 24, 32 GB de memória, e até mais em muitos casos. A virtualização esta se tornando cada dia mais confiável e sistemas críticos, que demandam alta utilização de recursos, estão sendo virtualizados. Se tratando de VMware, durante a fase de design/planejamento de novos ambientes (ou mesmo da criação de novas VMs) algumas pessoas esquecem que para cada VM existe um arquivo de swap que é criado com o tamanho fixo igual a memória configurada (menos a reserva) por padrão no mesmo local do arquivo de configuração da VM (“working irectory”) o que pode, em alguns casos, comprometer o espaço livre no Datastore (eu costumo usar o threshold de 20% de espaço livre em meus projetos). No final das contas, o arquiteto desenha a solução pensando em 20% de espaço livre, por exemplo, e quando implementado o projeto esses 20% baixaram para 15 ou menos dependendo da configuração das VMs (e quantidade de VMs por Datastore).

Eu pretendo com esse artigo auxiliar em algumas definições para evitar surpresas desagradáveis no decorrer da implementação do projeto.

A regra padrão é: sempre considere a existência do arquivo de Swap pondo na ponta do lápis a configuração de memória de cada VM quando dimensionando a camada de Storage. Eu costumo usar a seguinte fórmula para dimensionar a camada de Storage:

(“Soma dos VMDKs”+ (“Memória Configurada” – “Memória Reservada”))*1,2%

Essa fórmula me garante o espaço necessário para o arquivo de Swap e ainda me proporciona os 20% de espaço livre que eu costumo preservar no Datastore.

É possível armazenar o arquivo de Swap das VMs em locais diferentes do padrão (junto com o arquivo de configuração da VM), porém, alguns cuidados precisam ser tomados:

Quando alterado o local de armazenamento default do arquivo de Swap das VMs selecionando a opção “Datastore specified by host” em “Swap File Location” nas configurações do Cluster, este local alternativo deve ser configurado em cada um dos Hosts ESXi do Cluster. Supondo que um dos Hosts ESXi do Cluster não possua esse local alternativo configurado, se migrada uma VM para ele via vMotion o seu arquivo de Swap será criado no “working directory” da VM (local padrão).

É importante assegurar que o local alternativo possua espaço livre suficiente para acomodar os arquivos de Swap. Caso ao tentar ligar uma VM, não exista no local alternativo definido espaço livre suficiente para a criação do seu arquivo de Swap, o VMware tentará criá-lo no “working directory” da VM (não havendo espaço também no “working directory” a VM não ligará).

Não é recomendado armazenar arquivos de Swap em Datastores replicados, principalmente se a replica for síncrona. Assim como também é recomendado evitar o armazenamento de arquivos de Swap em Datastores que façam uso de tecnologia de Snapshot disponível em alguns Arrays (para evitar mal uso de espaço em disco).

Armazenamento do arquivo de Swap no disco local dos Hosts ESXi é uma alternativa viável para economizar espaço no Storage, entretanto, como o arquivo não esta em um Datastore compartilhado, quando necessário fazer um vMotion da VM para um outro Host ESXi o processo vai demorar um pouco mais visto que um novo arquivo de Swap será criado no disco local do Host ESXi de destino. O arquivo de Swap embora possua tamanho fixo, ele não é “zerado” em sua criação (o que torna o processo de criação desse arquivo mais rápido) e se o arquivo de Swap de origem possuir páginas de memória, essas páginas serão copiadas para o arquivo de destino.

Por fim, uma dica valiosa: Alguns Arrays possuem a capacidade de provisionar LUNs “Thin Provisioned”. Ou seja, o ESXi “enxerga” um tamanho de LUN que na verdade não esta totalmente disponível pelo Array, o qual “entrega” o espaço conforme a necessidade. Visto que o arquivo de Swap não é um arquivo “zerado”, em uma LUN “Thin Provisioned” se ele não possuir páginas de memória significa que ocupará muito pouco espaço (praticamente os metadados, apenas), o que viabiliza se devidamente controlado, uma utilização bastante eficiente do recuro de “Thin Provisioning” na camada do Storage. Mas eu vou reforçar aqui que este recurso precisa ser monitorado e devidamente controlado na camada de Storage para evitar problemas já que se o ESXi não interage com o mecanismo de “Thin Provisioning” do Storage, dessa forma, se o Storage diz para o ESXi que a LUN possui 1000 GB provisionados, o ESXi vai tentar usar esses 1000 GB.

Duvidas? Façam seus comentários, será um prazer ajudar.

Abraços e até o próximo post.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: