TRIM, Thin Provisioning, Defrag e como isso afeta seu bolso em VMs Azure

Alguma vez já se deparou com o seguinte erro no event viewer de qualquer VM Windows Server no Azure?

The volume (F:) was not optimized because an error was encountered: Neither Slab Consolidation nor Slab Analysis will run if slabs are less than 8 MB. (0x8900002D)

Apesar do Windows reportar como um erro, você pode seguramente ignorar este problema. Isso acontece porque o Windows foi “impedido” de executar o DFRAG dos volumes. Na verdade, este impedimento vem do fato de que o volume é gerenciado por um agente externo, neste caso, o SAN.

Procurando na internet sobre isso, temos uma explicação bastante clara no artigo de KB2964429:

There’s no need to run Storage Optimizer on thin provisioned LUNs that use an allocation size (also known as slab size) of less than 8 MB. Thin provisioned LUNs that have a smaller slab size manage space more efficiently, and the benefits of defragmenting them are not as great.

When you run the Storage Optimizer with the Analyze switch at a command prompt or a PowerShell prompt (for example, defrag g: /a or Optimize-Volume -Analyze g –Verbose) on a thin provisioned LUN that’s using a small slab size, the command does not execute, and you receive the following error message:

Neither Slab Consolidation nor Slab Analysis will run if slabs are less than 8 MB.

This is expected behavior because slab consolidation and slab analysis has been disabled on thin provisioned LUNs that have a slab size of less than 8 MB.

Basicamente, o Azure utiliza o que chamamos de Thin Provisioning para gerenciar os dados alocados em Storage. Na prática, é como se o espaço alocado para o sistema operacional fosse maior do que realmente há disponível, pois apesar de a aplicação achar que possui determinado espaço para escrever, no fundo esse espaço sequer foi alocado. Além de evitar o desperdício, estes hardwares possuem sistemas de controle de fragmentação pro-ativa que visam garantir o menor nível de fragmentação possível. Sendo assim, um controle de fragmentação a nível de SO seria irrelevante. Além do mais, seria possível até que o processo de defragmentação acabasse por consumir mais espaço ao inves de causar o efeito oposto, prejudicando a otimização realizada pelo SAN.

Bom, mas como todo sysadmin, não queremos ver erros nos logs do Windows Server. Seria seguro simplesmente desabilitar a tarefa agendada para a defragmentação do disco?

Seguro é, mas recomendado não. Isso porque outra função do otimizador de discos do Windows é executar o TRIM dos VHDs, ou seja, dizer ao SO quais blocos de dados não são mais válidos e simplesmente limpá-los. Ao fazer isso, o consumo “faturável” do Storage também diminui. Embora isto seja um procedimento comum em discos SSD, o Storage Standard do Azure também possui esta funcionalidade.

Para verificar se o TRIM está ativo no SO, basta executar o seguinte comando no prompt:

fsutil behavior query DisableDeleteNotify

Se o retorno for 0, então o TRIM está ativo. Se for 1, utilize o comando abaixo para habilita-lo:

fsutil behavior set DisableDeleteNotify 0

Em outras palavras, se você se preocupa em manter os custos do storage sempre o mais baixo possível, é recomendado manter esta tarefa em execução, mesmo que isso gere os erros no log do seu event viewer.

Em útlima instância, caso realmente prefira executar a otimização manualmente, é possível através do seguinte cmdlet de Powershell:

Optimize-Volume -DriveLetter E -ReTrim

Referências:

[1] Storage Optimizer memory use increases when it runs on thin provisioned LUNs

[2] Thin provisioning

[3] About disks and VHDs for Azure virtual machines

[4] Release unused space from your Windows Azure Virtual Hard Disks to reduce their billable size

Leave a Reply

Your email address will not be published. Required fields are marked *