Como otimizar o desempenho de discos permanentes e SSDs locais

Discos permanentes são a opção de armazenamento mais comum devido ao preço, desempenho e previsibilidade. No entanto, é possível criar instâncias com SSDs locais para um desempenho melhor e latência ainda menor, mas sem a redundância e a durabilidade de dados adquiridos com os discos permanentes. Ao configurar uma opção de armazenamento para aplicativos executados nas instâncias, use os seguintes processos:

  • Determine de quanto espaço você precisa.
  • Determine que características de desempenho seus aplicativos exigem.
  • Configure as instâncias para otimizar o desempenho do armazenamento.

Este documento aborda opções de armazenamento em bloco que você pode anexar às instâncias do Compute Engine. Para consultar uma lista completa de opções de armazenamento no Google Cloud Platform, leia Como escolher uma opção de armazenamento.

Comparação de desempenho do armazenamento em bloco

Pense nos requisitos de tamanho e desempenho do armazenamento para ajudar a determinar o tipo e o tamanho corretos de disco para as instâncias. Os requisitos de desempenho para um determinado aplicativo geralmente são divididos em dois padrões distintos de E/S.

  • Leituras e gravações pequenas
  • Leituras e gravações grandes

Para leituras e gravações pequenas, o fator de limitação são operações aleatórias de entrada/saída por segundo (IOPS, na sigla em inglês).

Para leituras e gravações grandes, o fator de limitação é a capacidade.

Discos
permanentes
padrão por zona
Discos
permanentes
padrão regionais
Discos
permanentes
SSD por zona
Discos
permanentes
SSD regionais
SSD local (SCSI) SSD local (NVMe)
IOPS máximas sustentadas
IOPS de leitura por GB 0,75 0,75 30 30 266,7 453,3
IOPS de gravação por GB 1,5 1,5 30 30 186,7 240
IOPS de leitura por instância 3.000 3.000 15.000 - 60.000* 15.000 - 60.000* 400.000 680.000
IOPS de gravação por instância 15.000 15.000 15.000 - 30.000* 15.000 - 30.000* 280.000 360.000
Capacidade sustentada máxima (MB/s)
Capacidade de leitura por GB 0,12 0,12 0,48 0,48 1,04 1,77
Capacidade de gravação por GB 0,12 0,12 0,48 0,48 0,73 0,94
Capacidade de leitura por instância 180 180 240 - 1.200* 240 - 1.200* 1.560 2.650
Capacidade de gravação por instância 76 - 120** 38 - 120** 76 - 400* 38 - 200* 1.090 1.400

* As IOPS de discos permanentes SSD e o desempenho da capacidade dependem do número de instâncias de vCPUs e do tamanho do bloco de E/S. Para ver detalhes, leia Limites de desempenho em disco permanente SSD.

** Os discos permanentes SSD e padrão alcançam maior desempenho de capacidade em instâncias com mais vCPUs. Leia os Limites de saída da rede na capacidade de gravação para mais detalhes.

Como comparar um disco permanente a um disco rígido físico

Ao especificar o tamanho dos discos permanentes, pense em como esses discos se comparam em relação aos discos rígidos físicos tradicionais. As tabelas a seguir comparam os discos permanentes SSD e os padrão quanto ao desempenho típico esperado de uma unidade SATA de 7.200 RPM, que normalmente atinge 75 IOPS ou 120 MB/s.

Tipo de E/S Padrão de E/S Tamanho necessário para atender a uma unidade SATA de 7200 RPM
Disco permanente padrão Disco permanente SSD
Leituras pequenas aleatórias 75 leituras pequenas aleatórias 100 GB 3 GB
Gravações pequenas aleatórias 75 gravações pequenas aleatórias 50 GB 3 GB
Leituras grandes de streaming Leituras de streaming de 120 MB/s 1.000 GB 250 GB
Gravações grandes de streaming Gravações de streaming de 120 MB/s 1.000 GB 250 GB

Resumo de tamanho, preço e desempenho

Ao selecionar o tipo e o tamanho de um volume para o aplicativo, há vários fatores a serem considerados, menos o preço de uso do volume. Não há custos por E/S no disco permanente. Por isso, não é necessário fazer a estimativa mensal para calcular o orçamento do que será gasto em discos.

Os exemplos de cálculo de preços abaixo usam o sistema de preços de disco permanente dos EUA. Nestes exemplos, pense apenas nos custos relativos aos discos permanentes padrão, em comparação com os discos permanentes SSD. Os discos permanentes padrão custam US$ 0,040 por GB e os persistentes SSD custam US$ 0,170 por GB. No entanto, como os limites aumentam com o tamanho do volume, verifique o preço de cargas de trabalho orientadas a IOPS.

Os discos permanentes padrão têm custos aproximados de US$ 0,053 por IOPS em leitura aleatória e US$ 0,0266 por IOPS em gravação aleatória. Os discos permanentes SSD têm custos de US$ 0,0057 por IOPS em leitura aleatória e US$ 0,0057 por IOPS em gravação aleatória. O preço por IOPS para discos permanentes SSD é válido até o ponto em que eles atingem os limites de IOPS da instância ou a contagem de vCPUs dessa instância.

Os discos permanentes SSD atingem o limite de 60.000 IOPS em leitura aleatória a 2.000 GB e de 30.000 IOPS em gravação aleatória a 1.000 GB. Por outro lado, os discos permanentes padrão atingem o limite de 3.000 IOPS em leitura aleatória a 4 TB e de 15.000 IOPS em gravação aleatória a 10 TB.

Os discos SSD permanentes são projetados para latências de milissegundo com um dígito. A latência observada é específica do aplicativo.

Disco permanente padrão

O desempenho padrão do disco permanente é dimensionado de maneira linear até os limites de desempenho da VM. A contagem de vCPUs da instância não limita o desempenho de discos permanentes padrão.

Uma contagem de duas ou mais vCPUs para a instância não limita o desempenho de discos permanentes padrão. Uma contagem de uma vCPU para a instância enfrentará um limite de gravação reduzido porque é restringida pelos limites de saída da rede, que são proporcionais à contagem de vCPUs.

O IOPS do disco permanente padrão e o desempenho em termos de capacidade aumentarão de maneira linear com o tamanho do disco até atingirem os seguintes limites por instância:

  • Capacidade de leitura: até 180 MB/s com um tamanho de disco de 1,5 TB.
  • Capacidade de gravação: até 120 MB/s com um tamanho de disco de 1 TB.
  • IOPS de leitura: até 3.000 IOPS com um tamanho de disco de 4 TB.
  • IOPS de gravação: até 15.000 IOPS com um tamanho de disco de 10 TB.

Para conseguir benefícios em termos de desempenho do disco permanente nas instâncias existentes, redimensione os discos permanentes a fim de aumentar o IOPS e a capacidade por disco permanente.

Tamanho do volume (GB) IOPS aleatório sustentado Capacidade sustentada (MB/s)
Leitura Gravação Leitura Gravação
10 * * * *
32 24 48 3 3
64 48 96 7 7
128 96 192 15 15
256 192 384 30 30
512 384 768 61 61
1000 750 1.500 120 120
1.500 1125 2250 180 120
2048 1.536 3.072 180 120
4000 3000 6.000 180 120
8192 3000 12.288 180 120
10000 3000 15.000 180 120
16384 3000 15.000 180 120
32.768 3000 15.000 180 120
65.536 3000 15.000 180 120

* Use este tamanho de volume somente para volumes de inicialização. O bursting de E/S será considerado para todas as tarefas significativas.

Disco permanente SSD

Ao contrário dos discos permanentes padrão, o desempenho de IOPS dos discos permanentes SSD depende do número de vCPUs na instância.

O desempenho do disco permanente SSD é dimensionado de maneira linear até atingir os limites do volume ou de cada instância do Compute Engine. A consistência da largura de banda de leitura do SSD perto do limite máximo de 1.200 MB/s depende em grande parte da utilização do ingresso na rede. Por isso, alguma variabilidade é esperada.
Consulte a tabela abaixo para mais detalhes.

Contagem de vCPUs na instância IOPS aleatório sustentado Capacidade sustentada (MB/s)
Leitura* Gravação Leitura** Gravação
De 1 a 7 vCPUs 15.000 15.000 240 240
De 8 a 15 vCPUs 15.000 15.000 800 240
De 16 a 31 vCPUs 25.000 25.000 1.200 240
De 32 a 63 vCPUs 60.000 30.000 1.200 400
64+ vCPUs*** 60.000 30.000 1.200 400

* Máximo de IOPS com base em tamanhos de bloco IO de 8 KB ou menores.

** Capacidade máxima com base em tamanhos de bloco de E/S de 256 KB ou maiores.

*** O desempenho máximo pode não ser atingido com a utilização total da CPU.

Para melhorar o desempenho do disco permanente SSD nas instâncias atuais, altere o tipo de máquina da instância para aumentar os limites por VM e redimensione os discos permanentes para aumentar a IOPS e a capacidade por disco permanente.

Tamanho do volume (GB) IOPS aleatório sustentado Capacidade sustentada (MB/s)
Leituras Gravações Leituras Gravações
10 300 300 4,8 4,8
32 960 960 15 15
64 1.920 1.920 30 30
128 3.840 3.840 61 61
256 7.680 7.680 122 122
500 15.000 15.000 240 240
834 25.000 25.000 400 400
1000 30.000 30.000 480 400
1.334 40.000 30.000 640 400
1.667 50.000 30.000 800 400
2048 60.000 30.000 983 400
4096 60.000 30.000 1.200 400
8192 60.000 30.000 1.200 400
16384 60.000 30.000 1.200 400
32.768 60.000 30.000 1.200 400
65.536 60.000 30.000 1.200 400

Leituras e gravações simultâneas

Nos discos permanentes padrão, leituras e gravações simultâneas compartilham os mesmos limites de desempenho. À medida que a instância usa mais IOPS ou capacidade de leitura, ela pode executar menos gravações. As instâncias que usam mais capacidade de gravação podem fazer menos leituras.

Os discos permanentes SSD são capazes de atingir os respectivos limites máximos em termos de capacidade para leituras e gravações simultaneamente. No entanto, para IOPS, os discos permanentes SSD não podem atingir os respectivos limites máximos de leitura e gravação simultaneamente. Para atingir os limites máximos de capacidade durante leituras e gravações simultâneas, otimize o tamanho de E/S de maneira que o volume atenda aos limites de capacidade sem alcançar um gargalo de IOPS.

Limites de IOPS da instância para leituras e gravações simultâneas:

Disco permanente padrão Disco permanente SSD (oito vCPUs) Disco permanente SSD (mais de 32 vCPUs)
Leitura Gravação Leitura Gravação Leitura Gravação
3.000 IOPS 0 IOPS 15.000 IOPS 0 IOPS 60.000 IOPS 0 IOPS
2.250 IOPS 3.750 IOPS 11.250 IOPS 3.750 IOPS 45.000 IOPS 7.500 IOPS
1.500 IOPS 7.500 IOPS 7.500 IOPS 7.500 IOPS 30.000 IOPS 15.000 IOPS
750 IOPS 11.250 IOPS 3.750 IOPS 11.250 IOPS 15.000 IOPS 22.500 IOPS
0 IOPS 15.000 IOPS 0 IOPS 15.000 IOPS 0 IOPS 30.000 IOPS

Limites de capacidade da instância para leituras e gravações simultâneas:

Disco permanente padrão Disco permanente SSD (oito vCPUs) Disco permanente SSD (mais de 32 vCPUs)
Leitura Gravação Leitura Gravação Leitura Gravação
180 MB/s 0 MB/s 240 MB/s* 240 MB/s* 1.200 MB/s* 400 MB/s*
135 MB/s 30 MB/s
90 MB/s 60 MB/s
45 MB/s 90 MB/s
0 MB/s 120 MB/s

* Nos discos SSD permanentes, a capacidade máxima de leitura e de gravação são independentes entre si. Portanto, esses limites são constantes.

Limite de saída de rede na capacidade de gravação

Cada operação de gravação do disco permanente contribui para o limite de saída cumulativo de rede da instância da máquina virtual.

Para calcular o tráfego máximo de gravação do disco permanente que uma instância de máquina virtual pode emitir, subtraia o tráfego de saída de outra rede da instância do limite de rede de 2 Gbit/s/vCPU. O restante representa a capacidade disponível para o tráfego de gravação do disco permanente.

O Compute Engine armazena dados em discos permanentes para que eles tenham redundância integrada. As instâncias gravam dados em discos permanentes três vezes em paralelo para alcançar essa redundância. Além disso, cada solicitação de gravação tem uma certa quantidade de sobrecarga, que usa a largura de banda de saída.

Cada instância de máquina virtual tem um limite de gravação de disco permanente com base nos limites de saída da rede para a máquina virtual. Por exemplo, os seguintes valores são baseadas em uma instância que não tem tráfego IP adicional.

Disco permanente padrão Discos permanentes em estado sólido
Número de vCPUs Limite de gravação do disco permanente padrão (MB/s) Tamanho do volume padrão obrigatório para atingir o limite (GB) Limite de gravação do disco permanente SSD (MB/s) Tamanho do disco permanente SSD obrigatório para atingir o limite (GB)
1 78 650 78 163
2 120 1000 156 326
4 120 1000 240 500
8 120 1000 240 500
16 120 1000 240 500
Mais de 32 120 1000 400 1000

Para entender como os valores dessa tabela foram criados, considere um exemplo simples com uma vCPU e um disco permanente padrão. Nesse exemplo, calculamos que o multiplicador de largura de banda para cada solicitação de gravação é de 3,3x. Isso significa que os dados são gravados três vezes e têm uma sobrecarga total de 10%. Para calcular o limite de saída, divida por 3,3 o limite de saída da rede, que é 2 Gbit/s ou o equivalente a 256 MB/s:

Largura de banda de gravação máxima para uma vCPU = 256 / 3,3 = ~ 78 MB/s para seu disco permanente padrão

Além disso, ao usar o valor da capacidade/GB de gravação do disco permanente padrão fornecido no gráfico de desempenho apresentado anteriormente, você pode derivar a capacidade de disco necessária para alcançar esse desempenho:

Capacidade de disco necessária para alcançar a largura de banda de gravação máxima para 1 vCPU = 78 / 0,12 = ~ 650 GB

De maneira semelhante à dos discos permanentes por zona, o tráfego de gravação de discos permanentes regionais contribui para um limite cumulativo da saída de rede na instância de máquina virtual. Para calcular a rede de saída disponível para discos permanentes regionais, use o fator 6,6, em vez de 3,3 que é usado nos discos permanentes zonais.

Largura de banda de gravação máxima para uma vCPU = 256 / 6,6 = ~ 39 MB/s para seu disco permanente replicado padrão.

Como otimizar o desempenho de discos permanentes e SSDs locais

Você pode otimizar discos permanentes e SSDs locais para processar os dados de maneira mais eficiente.

Como otimizar discos permanentes

Os discos permanentes podem proporcionar o desempenho descrito no gráfico do tipo de disco, mas a máquina virtual precisa destinar uso suficiente para atingir os limites de desempenho. Depois de dimensionar os volumes de disco permanente da maneira apropriada às necessidades de desempenho, o aplicativo e o sistema operacional podem precisar de alguns ajustes.

Nesta seção, descrevemos alguns elementos-chave que podem ser ajustados tendo em vista um desempenho melhor e, em seguida, abordamos como aplicar alguns deles a tipos específicos de cargas de trabalho.

Como desativar a inicialização lenta e ativar comandos DISCARD

Os discos permanentes dão suporte a comandos DISCARD ou TRIM, que permitem aos sistemas operacionais informar os discos quando os blocos deixam de ser usados. O suporte a DISCARD permite ao sistema operacional marcar blocos do disco como não sendo mais necessários sem incorrer no custo de zerar os blocos.

Na maioria dos sistemas operacionais Linux, DISCARD é ativado quando você ativa um disco permanente na instância. As instâncias do Windows 2012 R2 ativam DISCARD por padrão quando você ativa um disco permanente. O Windows 2008 R2 não suporta DISCARD.

Ativar DISCARD pode melhorar o desempenho geral do tempo de execução, além de acelerar o desempenho do disco quando ele é ativado pela primeira vez. Formatar um volume de disco inteiro pode ser demorado. Assim, a chamada "formatação preguiçosa" é uma prática comum. A desvantagem da formatação preguiçosa é que o custo é frequentemente pago na primeira vez em que o volume é ativado. Ao desativar a inicialização lenta e ativar os comandos DISCARD, é possível conseguir formatação e ativação rápidas.

  • Desative a inicialização lenta e ative DISCARD durante a formatação passando os seguintes parâmetros para mkfs.ext4:

    -E lazy_itable_init=0,lazy_journal_init=0,discard
    

    O parâmetro lazy_journal_init=0 não funciona em instâncias com imagens do CentOS 6 ou do RHEL 6. Para essas instâncias, formate os discos permanentes sem esse parâmetro.

    -E lazy_itable_init=0,discard
    
  • Ative comandos DISCARD ao ativar, passe a seguinte sinalização para o comando de ativação:

    -o discard
    

Os discos permanentes funcionam bem com a opção discard ativa. No entanto, você pode opcionalmente executar fstrim periodicamente além ou em vez da opção discard. Se você não usar a opção discard, execute fstrim antes de criar um instantâneo do seu disco. Cortar o sistema de arquivos permite que você crie imagens de instantâneo menores, o que reduz o custo do armazenamento de instantâneos.

Profundidade da fila de E/S

Muitos aplicativos têm configurações que influenciam a profundidade da fila de E/S para ajustar o desempenho. Profundidades maiores de fila aumentam IOPS, mas também podem aumentar a latência. Profundidades de fila menores diminuem a latência por E/S, às vezes, às custas de IOPS.

Cache de leitura à frente

Para melhorar o desempenho de E/S, os sistemas operacionais empregam técnicas como leitura à frente, em que mais do que um arquivo solicitado é lido nessa memória, supondo que leituras subsequentes provavelmente precisarão desses dados. Leitura à frente maior aumenta a capacidade, mas às custas de memória e IOPs. Leitura à frente menor aumenta as IOPS, mas às custas de capacidade.

Em sistemas linux, receba e configure o valor "leitura à frente" com o comando blockdev:

$ sudo blockdev --getra /dev/[DEVICE_ID]
$ sudo blockdev --setra [VALUE] /dev/[DEVICE_ID]

O valor "leitura à frente" é <desired_readahead_bytes> / 512 bytes.

Por exemplo, para um valor "leitura à frente" de 8 MB, 8MB são 8388608 bytes (8 * 1024 * 1024).

8388608 bytes / 512 bytes = 16384

Configure desta forma:

$ sudo blockdev --setra 16384 /dev/[DEVICE_ID]

CPUs gratuitas

No disco permanente, a leitura e a gravação requerem ciclos de CPU da sua máquina virtual. Alcançar níveis de IOPS muito altos e consistentes requer CPUs livres para processar E/S.

Cargas de trabalho orientadas a IOPS

Bancos de dados SQL ou NoSQL têm padrões de uso de acesso aleatório aos dados. Os itens abaixo são sugeridos para cargas de trabalho orientadas a IOPS:

  • Os valores mais baixos de leitura à frente geralmente são sugeridos em documentos de práticas recomendadas para MongoDB, Apache Cassandra e outros aplicativos de banco de dados.

  • Valores de profundidade da fila de E/S de 1 para cada 400-800 IOPS até o limite de 64 em grandes volumes

  • Uma CPU livre para cada 2.000 IOPS de leitura aleatória e 1 CPU livre para cada 2.500 IOPS de gravação aleatória

Cargas de trabalho orientadas à capacidade

Operações de fluxo contínuo, como uma tarefa de Hadoop, se beneficiam de leituras sequenciais rápidas. Assim, tamanhos maiores de bloco podem aumentar o desempenho de fluxo contínuo. O tamanho padrão de bloco nos volumes é 4K. Para cargas de trabalho orientadas à capacidade, valores de 256 KB ou superiores são recomendados.

Otimizar o desempenho do disco permanente SSD

O gráfico de desempenho por tipo de disco descreve os limites de desempenho atingíveis esperados para discos permanentes em estado sólido. Para otimizar os aplicativos e as instâncias de máquina virtual para atingir essas velocidades, use as seguintes práticas recomendadas:

  • Verifique se o aplicativo está emitindo E/S suficiente

    Se o aplicativo estiver emitindo menos IOPS que o limite descrito na tabela acima, você não atingirá aquele nível de IOPS. Por exemplo, em um disco de 500 GB, o limite esperado de IOPS é de 15.000. No entanto, se você emitir menos que isso ou emitir operações de E/S maiores que 8 KB, não atingirá 15.000 IOPS.

  • Certifique-se de emitir E/S com paralelismo suficiente

    Use uma profundidade de fila alta o suficiente para aproveitar o paralelismo do sistema operacional. Se você emitir 1.000 IOPS, mas de forma síncrona com uma profundidade de fila de 1, atingirá muito menos IOPS do que o limite descrito na tabela. No mínimo, o aplicativo precisa ter uma profundidade de fila de pelo menos 1 para cada 400-800 IOPS.

  • Certifique-se de haver CPU suficiente disponível na instância da máquina virtual emitindo a E/S

    Se a instância da máquina virtual tiver pouca CPU, o aplicativo não conseguirá as IOPS descritas acima. Como regra geral, você precisa ter uma CPU disponível para cada 2.000-2.500 IOPS de tráfego esperado.

  • Verifique se o aplicativo está otimizado para uma localidade razoável de dados temporais em discos grandes

    Se o aplicativo acessar dados distribuídos em partes diferentes de um disco em um período curto (centenas de GB por vCPU), você não atingirá o IOPS ideal. Para conseguir um melhor desempenho, otimize para a localidade de dados temporais, ponderando fatores como fragmentação do disco e aleatoriedade das partes acessadas do disco.

  • Verifique se de o programador de E/S no sistema operacional está configurado para atender às necessidades específicas

    Em sistemas baseados em Linux, é possível configurar o programador de E/S como noop para atingir o maior número de IOPS em dispositivos com SSD.

Comparativo de mercado sobre o desempenho do disco permanente SSD

Os comandos abaixo calculam um dispositivo PD-SSD de 2500 GB, se o tamanho do dispositivo for diferente, modifique o argumento --filesize. Esse tamanho de disco é necessário para atingir os atuais limites de capacidade da VM de 32 vCPU.

    # Install dependencies
    sudo apt-get update
    sudo apt-get install -y fio
  1. Preencha o disco com dados diferentes de zero. As leituras de disco permanentes em blocos vazios têm um perfil de latência diferente dos que contêm dados. Recomendamos que você preencha o disco antes de executar qualquer comparação sobre latência de leitura.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=fill_disk \
      --filename=/dev/sdb --filesize=2500G \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=128K --iodepth=64 --rw=randwrite
    
  2. Teste de gravação de largura de banda.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=32 --rw=randwrite
    
  3. Teste de gravação de IOPS. Para atingir o limite de PD de IOPS, é importante manter uma fila profunda de E/S. Por exemplo, quando a latência de gravação for de 1 milissegundo, a VM precisa ter no máximo 1.000 IOPS para cada E/S em andamento. Para atingir 15.000 IOPS, a VM terá que manter pelo menos 15 E/Ss em andamento. Para que o disco e a VM alcancem 30.000 IOPS, o número de E/Ss em andamento terá de ser, pelo menos, 30. Quando o tamanho de E/S for maior do que 4 KB, a VM poderá atingir o limite de largura de banda antes de atingir o de IOPS.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randwrite
    
  4. Teste de gravação de latência. Ao testar a latência de E/S, é importante que a VM não atinja o limite de largura de banda ou IOPS. Caso contrário, a latência de E/S do disco permanente real não será refletida. Por exemplo: quando o limite de IOPS for atingido em uma profundidade de 30 para E/S e o comando "fio" tiver o dobro disso, o total de IOPS permanecerá o mesmo e a latência de E/S relatada será duplicada.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randwrite
    
  5. Teste de leitura de largura de banda.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=256K --iodepth=64 --rw=randread
    
  6. Teste de leitura de IOPS. Para atingir o limite de IOPS de PD, é importante manter uma fila de E/S com profundidade suficiente. Quando o tamanho de E/S for maior do que 4 KB, a VM poderá atingir o limite de largura de banda antes de atingir o de IOPS.

    sudo fio --name=read_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randread
    
  7. Teste de leitura de latência. É importante preencher o disco com dados para receber uma medição de latência realista. Também é importante que a VM não atinja os limites de IOPS ou de capacidade durante esse teste. Quando o disco permanente atinge o limite de saturação, as E/S recebidas são recuadas e isso é refletido como um aumento artificial na latência de E/S.

    sudo fio --name=read_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randread
    
  8. Teste de largura de banda de leitura sequencial.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=16 --rw=read
    

Otimizar SSDs locais

O gráfico de desempenho por tipo de disco descreve os limites de desempenho atingíveis esperados para dispositivos SSD locais. Para otimizar os aplicativos e as instâncias de máquina virtual para atingir essas velocidades, use as seguintes práticas recomendadas:

Usar as otimizações do ambiente convidado Linux para SSD local

Por padrão, um script de otimização será executado automaticamente pela maioria das imagens do Linux fornecidas pelo Compute Engine. Esse script configura a instância para o desempenho máximo do SSD local. Ele também ativa determinadas configurações de arquivos sysfs de fila, melhorando o desempenho geral da máquina e mascarando solicitações de interrupção (IRQs, na sigla em inglês) para CPUs virtuais (vCPUs, na sigla em inglês) específicas. Esse script otimiza apenas o desempenho dos dispositivos SSD locais do Compute Engine.

Ubuntu, SLES e imagens antigas talvez não estejam configurados para incluir essa otimização de desempenho. Caso você esteja usando qualquer dessas imagens ou uma imagem mais antiga que v20141218, instale o ambiente convidado Linux para ativar essas otimizações.

Selecione a melhor imagem para interfaces NVMe ou SCSI

Os SSDs locais funcionam melhor com o tipo de interface NVMe ou SCSI, dependendo da imagem usada no disco de inicialização da sua instância. Escolha uma interface para os dispositivos SSD locais que funcione melhor com a imagem do disco de inicialização. Caso as suas instâncias se conectem a SSDs locais usando interfaces SCSI, ative o SCSI multifilas no sistema operacional convidado, para melhorar o desempenho na interface do SCSI.

Ativar o SCSI multifilas em instâncias com imagens personalizadas e SSDs locais

Algumas imagens públicas são compatíveis com o SCSI multifilas. Caso precise de recursos SCSI multifilas em imagens personalizadas importadas para seu projeto, você terá de ativá-las por conta própria. Suas imagens importadas do Linux usam SCSI multifilas somente quando elas incluem a versão 3.19 ou posterior do kernel.

Para ativar o SCSI multifilas em uma imagem personalizada, importe a imagem com o recurso do sistema operacional convidado VIRTIO_SCSI_MULTIQUEUE ativado e inclua uma entrada na configuração do GRUB:

CentOS

Apenas para o CentOS7.

  1. Importe a imagem personalizada usando a API e inclua um item guestOsFeatures com um valor type de VIRTIO_SCSI_MULTIQUEUE.

  2. Crie uma instância usando sua imagem personalizada e anexe um ou mais SSDs locais.

  3. Conecte-se à instância pelo SSH.

  4. Verifique o valor do arquivo /sys/module/scsi_mod/parameters/use_blk_mq

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Caso o valor desse arquivo seja Y, o SCSI multifilas já estará ativado na imagem importada. Se o valor do arquivo for N, inclua scsi_mod.use_blk_mq=Y na entrada GRUB_CMDLINE_LINUX do arquivo de configuração GRUB e reinicie o sistema.

    1. Abra o arquivo de configuração GRUB /etc/default/grub em um editor de texto.

      $ sudo vi /etc/default/grub
      
    2. Adicione scsi_mod.use_blk_mq=Y à entrada GRUB_CMDLINE_LINUX.

      GRUB_CMDLINE_LINUX=" vconsole.keymap=us console=ttyS0,38400n8 vconsole.font=latarcyrheb-sun16 scsi_mod.use_blk_mq=Y"
      
    3. Salve o arquivo de configuração.

    4. Execute o comando grub2-mkconfig para regenerar o arquivo GRUB e concluir a configuração.

      $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
      
    5. Reinicie a instância.

      $ sudo reboot
      

Ubuntu

  1. Importe a imagem personalizada usando a API e inclua um item guestOsFeatures com um valor type de VIRTIO_SCSI_MULTIQUEUE.

  2. Crie uma instância usando a imagem personalizada e anexe um ou mais SSDs locais usando a interface SCSI.

  3. Conecte-se à instância pelo SSH.

  4. Verifique o valor do arquivo /sys/module/scsi_mod/parameters/use_blk_mq.

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Caso o valor desse arquivo seja Y, o SCSI multifilas já estará ativado na imagem importada. Se o valor do arquivo for N, inclua scsi_mod.use_blk_mq=Y na entrada GRUB_CMDLINE_LINUX do arquivo de configuração GRUB e reinicie o sistema.

    1. Abra o arquivo de configuração GRUB sudo nano /etc/default/grub em um editor de texto.

      $ sudo nano /etc/default/grub
      
    2. Adicione scsi_mod.use_blk_mq=Y à entrada GRUB_CMDLINE_LINUX.

      GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=Y"
      
    3. Salve o arquivo de configuração.

    4. Execute o comando update-grub para gerar novamente o arquivo GRUB e concluir a configuração.

      $ sudo update-grub
      
    5. Reinicie a instância.

      $ sudo reboot
      

Desativar a limpeza do cache de gravação

Os sistemas de arquivos, bancos de dados e outros aplicativos usam a limpeza de cache para garantir que os dados sejam confirmados para armazenamento durável em diversos pontos de verificação. Para a maioria dos dispositivos de armazenamento, esse padrão faz sentido. No entanto, as limpezas do cache de gravação são muito lentas em SSDs locais. Você pode melhorar o desempenho de gravação para alguns aplicativos desativando comandos de limpeza automática nesses aplicativos ou opções de limpeza no nível do sistema de arquivos.

Os SSDs locais sempre limpam gravações em cache dentro de dois segundos, independentemente dos comandos de limpeza que você definiu para os sistemas de arquivos e os aplicativos. Dessa forma, as falhas de hardware temporárias podem fazer você perder, no máximo, apenas dois segundos de gravações armazenados em cache. As falhas de hardware permanentes ainda podem causar perda de todos os dados no dispositivo, mesmo que os dados sejam limpos. Por isso, faça o backup de dados críticos para os discos permanentes ou intervalos do Cloud Storage.

Para desativar a limpeza do cache de gravação em sistemas de arquivos ext4, inclua nobarrier nas opções de ativação ou nas entradas do /etc/fstab. Por exemplo:

$ sudo mount -o discard,defaults,nobarrier /dev/[LOCAL_SSD_ID] /mnt/disks/[MNT_DIR]

em que: [LOCAL_SSD_ID] é o código do dispositivo do SSD local em que quer montar.

Como comparar o desempenho do SSD local

Os valores de desempenho do SSD local fornecidos na seção Desempenho foram conseguidos usando-se configurações específicas na instância do SSD local. Se a instância estiver enfrentando problemas para atingir esses limites de desempenho e você já tiver configurado a instância usando as configurações do SSD local recomendadas, compare os limites de desempenho com os limites publicados replicando as configurações usadas pela equipe do Compute Engine.

  1. Crie uma instância de SSD local que tenha quatro ou oito vCPUs para cada dispositivo, dependendo da carga de trabalho. Por exemplo, para anexar quatro dispositivos SSD locais a uma instância, use um tipo de máquina com 16 ou 32 vCPUs.

    O comando abaixo cria uma máquina virtual com 8 vCPUs e um único SSD local:

    gcloud compute instances create ssd-test-instance \
    --machine-type "n1-standard-8" \
    --local-ssd interface="SCSI"
    
  2. Execute o script a seguir na máquina, que replica as configurações usadas para atingir essas velocidades. O parâmetro --bs define o tamanho do bloco, o que afeta os resultados para diferentes tipos de operações de leitura e gravação.

    # install dependencies
    sudo apt-get update -y
    sudo apt-get install -y build-essential git libtool gettext autoconf \
    libgconf2-dev libncurses5-dev python-dev fio bison autopoint
    
    # blkdiscard
    git clone https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
    cd util-linux/
    ./autogen.sh
    ./configure --disable-libblkid
    make
    sudo mv blkdiscard /usr/bin/
    sudo blkdiscard /dev/disk/by-id/google-local-ssd-0
    
    # full write pass - measures write bandwidth with 1M blocksize
    sudo fio --name=writefile --size=100G --filesize=100G \
    --filename=/dev/disk/by-id/google-local-ssd-0 --bs=1M --nrfiles=1 \
    --direct=1 --sync=0 --randrepeat=0 --rw=write --refill_buffers --end_fsync=1 \
    --iodepth=200 --ioengine=libaio
    
    # rand read - measures max read IOPs with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randread --blocksize=4k --group_reporting
    
    # rand write - measures max write IOPs with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randwrite --blocksize=4k --group_reporting
    

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine