Camadas de cache | Guia de Administração

documentation.suse.com › Documentação do SUSE Enterprise Storage 5 › Guia de Administração › Operando um cluster › Camadas de cache

ConteúdoConteúdo

Guia de Administração

Navegação←→

Aplica-se a SUSE Enterprise Storage 5

10 Camadas de cache #

10.1 Terminologia de armazenamento em camadas
10.2 Pontos a serem considerados
10.3 Quando usar as camadas de cache
10.4 Modos de cache
10.5 Conjunto de acertos
10.6 Configurando um armazenamento em camadas de exemplo

A camada de cache é uma camada de armazenamento adicional implementada entre o armazenamento de cliente e padrão. Ela foi criada para acelerar o acesso aos pools armazenados em discos rígidos lentos e pools com codificação de eliminação.

Em geral, as camadas de cache envolvem a criação de um pool de dispositivos de armazenamento relativamente rápidos e caros (por exemplo, unidades SSD), configurado para agir como uma camada de cache, e um pool de suporte de dispositivos mais lentos e baratos, configurado para agir como uma camada de armazenamento.

10.1 Terminologia de armazenamento em camadas #

As camadas de cache reconhecem dois tipos de pools: pool de cache e pool de armazenamento.

Dica

Para obter informações gerais sobre pools, consulte o Capítulo 7, Gerenciando pools de armazenamento.

pool de armazenamento

Um pool replicado padrão que armazena várias cópias de um objeto no cluster de armazenamento do Ceph ou um pool com codificação de eliminação (consulte o Capítulo 9, Pools com codificação de eliminação).

O pool de armazenamento algumas vezes é chamado de “suporte” ou de armazenamento “a frio”.

pool de cache

Um pool replicado padrão armazenado em um dispositivo relativamente pequeno, porém rápido, com seu próprio conjunto de regras em um Mapa CRUSH.

O pool de cache também é chamado de armazenamento “a quente”.

10.2 Pontos a serem considerados #

As camadas de cache podem prejudicar o desempenho do cluster para cargas de trabalho específicas. Os pontos a seguir mostram alguns dos aspectos que você precisa levar em consideração:

Dependente da carga de trabalho: A melhoria no desempenho dependerá da carga de trabalho. Como existe um custo associado à adição ou remoção de objetos do cache, talvez seja melhor que a maioria das solicitações acesse o menor número de objetos. O pool de cache deve ser grande o suficiente para capturar o conjunto ativo de sua carga de trabalho para evitar sobrecarga.
Benchmark difícil: A maioria dos benchmarks apresenta baixo desempenho com camadas de cache. O motivo é que elas solicitam um conjunto grande de objetos e leva muito tempo para “aquecer” o cache.
Desempenho possivelmente baixo: Para cargas de trabalho não adequadas às camadas de cache, o desempenho costuma ser menor do que um pool replicado comum sem as camadas de cache habilitadas.
Enumeração de objetos do librados: Se a replicação usa o librados diretamente e executa a enumeração de objetos, as camadas de cache talvez não funcionem conforme esperado. (Isso não é um problema para o Object Gateway, RBD ou CephFS.)

10.3 Quando usar as camadas de cache #

Considere usar as camadas de cache nos seguintes casos:

Você precisa acessar pools com codificação de eliminação por meio do Dispositivo de Blocos RADOS (RBD).
Você precisa acessar pools com codificação de eliminação pelo iSCSI, já que ele herda as limitações do RBD. Para obter mais informações sobre o iSCSI, consulte o Capítulo 12, Ceph iSCSI Gateway.
Você tem um número limitado de armazenamento de alto desempenho e uma grande coleção de armazenamento de baixo desempenho e precisa acessar os dados armazenados mais rapidamente.

10.4 Modos de cache #

O agente de camadas de cache processa a migração de dados entre a camada de cache e a camada de armazenamento de suporte. Os administradores podem configurar o modo de execução dessa migração. Há dois cenários principais:

modo write-back: No modo write-back, os clientes do Ceph gravam dados na camada de cache e recebem uma confirmação (ACK) da camada de cache. No momento certo, os dados gravados na camada de cache são migrados para a camada de armazenamento e eliminados da camada de cache. Conceitualmente, a camada de cache é sobreposta “na frente” da camada de armazenamento de suporte. Quando um cliente do Ceph precisa de dados que residem na camada de armazenamento, o agente de camadas de cache os migra para a camada de cache na leitura e, em seguida, eles são enviados ao cliente do Ceph. Na sequência, o cliente do Ceph poderá executar a E/S usando a camada de cache, até que os dados se tornem inativos. Esse procedimento é ideal para dados mutáveis, como edição de fotos ou vídeo, ou dados transacionais.
modo apenas leitura: No modo apenas leitura, os clientes do Ceph gravam dados diretamente na camada de suporte. Na leitura, o Ceph copia os objetos solicitados da camada de suporte para a camada de cache. Os objetos obsoletos são removidos da camada de cache de acordo com a política definida. Essa abordagem é ideal para dados imutáveis, como apresentação de fotos ou vídeos em uma rede social, dados de DNA ou imagens de raio X, porque a leitura de dados de um pool de cache que possa conter dados desatualizados oferece pouca consistência. Não use o modo apenas leitura para dados mutáveis.

10.5 Conjunto de acertos #

10.5.1 Visão geral #

Os parâmetros de conjunto de acertos permitem o ajuste de pools de cache. Normalmente, os conjuntos de acertos no Ceph são filtros de Bloom e um método eficiente, em termos de uso de memória, para monitorar objetos que já estão no pool de cache.

O conjunto de acertos é uma matriz de bits usada para armazenar o resultado de um grupo de funções de hash aplicadas a nomes de objetos. Inicialmente, todos os bits estão definidos como 0. Quando um objeto é adicionado ao conjunto de acertos, um hash é executado com o nome dele, e o resultado é mapeado em diferentes posições no conjunto de acertos, em que o valor do bit é definido como 1.

Para saber se existe um objeto no cache, um novo hash é executado com o nome do objeto. Se houver algum bit como 0, definitivamente o objeto não estará no cache, e será necessário recuperá-lo do armazenamento a frio.

Os resultados de objetos diferentes podem ser armazenados no mesmo local que o conjunto de acertos. Existe a possibilidade de todos os bits serem 1 sem que o objeto esteja no cache. Portanto, os conjuntos de acertos que trabalham com um filtro de Bloom apenas podem informar se um objeto definitivamente não está no cache e precisa ser recuperado do armazenamento a frio.

Um pool de cache pode ter mais do que um conjunto de acertos monitorando o acesso a arquivos ao longo do tempo. A configuração hit_set_count define quantos conjuntos de acertos estão em uso, e hit_set_period define por quanto tempo cada conjunto de acertos foi usado. Após a expiração do período, o próximo conjunto de acertos será utilizado. Se o número de conjuntos de acertos se esgotar, a memória do conjunto de acertos mais antigo será liberada, e um novo conjunto de acertos será criado. Os valores de hit_set_count e hit_set_period multiplicados um pelo outro definem o período geral de monitoramento do acesso aos objetos.

Figura 10.1: Filtro de Bloom com 3 objetos armazenados #

Se comparado com o número de objetos com hash, um conjunto de acertos baseado em um filtro de Bloom é muito eficiente em termos de uso de memória. Menos do que 10 bits são necessários para reduzir a probabilidade de falsos positivos para menos do que 1%. A probabilidade de falsos positivos pode ser definida com hit_set_fpp. Com base no número de objetos em um grupo de posicionamento e na probabilidade de falsos positivos, o Ceph calcula automaticamente o tamanho do conjunto de acertos.

O armazenamento necessário no pool de cache pode ser limitado com min_write_recency_for_promote e min_read_recency_for_promote. Se o valor for definido como 0, todos os objetos serão promovidos para o pool de cache assim que forem lidos ou gravados, e esse comportamento se manterá até que eles sejam eliminados. Qualquer valor maior do que 0 define o número de conjuntos de acertos que são pesquisados para o objeto, ordenado por data. Se o objeto for encontrado em um conjunto de acertos, ele será promovido para o pool de cache.

10.5.2 Exemplos #

10.5.2.1 Pool de cache grande e pouca memória #

Em caso de muito armazenamento e pouca quantidade de RAM disponível, é possível promover todos os objetos para o pool de cache logo que são acessados. O conjunto de acertos sem mantém pequeno. Veja a seguir um conjunto de valores de configuração de exemplo:

hit_set_count = 1
hit_set_period = 3600
hit_set_fpp = 0.05
min_write_recency_for_promote = 0
min_read_recency_for_promote = 0

10.5.2.2 Pool de cache pequeno e muita memória #

Em caso de uma pequena quantidade de armazenamento, mas uma quantidade de memória disponível igualmente grande, é possível configurar a camada de cache para promover um número limitado de objetos para o pool de cache. Doze conjuntos de acertos, dos quais cada um é usado durante um período de 14.400 segundos, efetuam o monitoramento em um total de 48 horas. Se um objeto foi acessado nas últimas 8 horas, ele é promovido para o pool de cache. Portanto, o conjunto de valores de configuração de exemplo é:

hit_set_count = 12
hit_set_period = 14400
hit_set_fpp = 0.01
min_write_recency_for_promote = 2
min_read_recency_for_promote = 2

10.6 Configurando um armazenamento em camadas de exemplo #

Esta seção mostra como configurar uma camada de cache de SSD rápida (armazenamento a quente) na frente de um disco rígido padrão (armazenamento a frio).

Dica

O exemplo a seguir é apenas para fins de ilustração e inclui uma configuração com uma raiz e uma regra para a parte da SSD que reside em um único nó do Ceph.

No ambiente de produção, as configurações do cluster normalmente incluem mais entradas raiz e de regra para o armazenamento a quente e também nós mistos, com SSDs e discos SATA.

Prepare uma máquina de host com unidades rápidas, como SSDs. Esse nó de cluster servirá como uma camada de cache rápida.
Torne a máquina um nó do Ceph usando o DeepSea. Instale o software e configure a máquina de host conforme descrito na Seção 1.1, “Adicionando novos nós do cluster”. Vamos supor que o nome seja node-4. Esse nó precisa ter 4 discos OSD.
Isso pode resultar em uma entrada como esta no mapa CRUSH:
```
[...]
host node-4 {
   id -5  # do not change unnecessarily
   # weight 0.012
   alg straw
   hash 0  # rjenkins1
   item osd.6 weight 0.003
   item osd.7 weight 0.003
   item osd.8 weight 0.003
   item osd.9 weight 0.003
}
[...]
```

Edite o mapa CRUSH do pool de armazenamento a quente mapeado para os OSDs que residem nas unidades SSD rápidas. Defina uma segunda hierarquia com um nó raiz para as SSDs (como “root ssd”). Mude também o peso e uma regra CRUSH para as SSDs. Para obter mais informações sobre o mapa CRUSH, consulte http://docs.ceph.com/docs/master/rados/operations/crush-map/.

Edite o mapa CRUSH diretamente com as ferramentas de linha de comando, como getcrushmap e crushtool:

Recupere o mapa atual e grave-o como c.map:

cephadm > sudo ceph osd getcrushmap -o c.map

Descompile c.map e grave-o como c.txt:
```
cephadm > crushtool -d c.map -o c.txt
```

Edite c.txt:

[...]
host node-4 {
        id -5  # do not change unnecessarily
        # weight 4.000
        alg straw
        hash 0  # rjenkins1
        item osd.6 weight 1.000
        item osd.7 weight 1.000
        item osd.8 weight 1.000
        item osd.9 weight 1.000
}
root ssd {    # newly added root for the SSD hot-storage
        id -6
        alg straw
        hash 0
        item node-4 weight 4.00
}
rule ssd {
        ruleset 4
        type replicated
        min_size 0
        max_size 4
        step take ssd
        step chooseleaf firstn 0 type host
        step emit
}
[...]

Compile o arquivo c.txt editado e grave-o como ssd.map:
```
cephadm > crushtool -c c.txt -o ssd.map
```

Por fim, instale ssd.map como o novo mapa CRUSH:

cephadm > sudo ceph osd setcrushmap -i ssd.map

Crie o pool de armazenamento a quente que será usado nas camadas de cache. Use a nova regra “ssd” para ele:
```
cephadm > sudo ceph osd pool create hot-storage 100 100 replicated ssd
```

Crie o pool de armazenamento a frio usando a regra “replicated_ruleset” padrão:

cephadm > sudo ceph osd pool create cold-storage 100 100 replicated replicated_ruleset

Em seguida, a configuração de uma camada de cache envolverá associar um pool de armazenamento de suporte a um pool de cache. Neste caso, armazenamento a frio (= pool de armazenamento) a armazenamento a quente (= pool de cache):
```
cephadm > sudo ceph osd tier add cold-storage hot-storage
```
Para definir o modo de cache como “writeback”, execute o seguinte:
```
cephadm > sudo ceph osd tier cache-mode hot-storage writeback
```
Para obter mais informações sobre modos de cache, consulte a Seção 10.4, “Modos de cache”.
As camadas de cache writeback sobrepõem a camada de armazenamento de suporte, portanto, elas requerem uma etapa adicional: você deve direcionar todo o tráfego do cliente do pool de armazenamento para o pool de cache. Por exemplo, para direcionar o tráfego do cliente diretamente para o pool de cache, execute o seguinte:
```
cephadm > sudo ceph osd tier set-overlay cold-storage hot-storage
```

10.6.1 Configurando uma camada de cache #

Há várias opções que você pode usar para configurar camadas de cache. Use a seguinte sintaxe:

cephadm > sudo ceph osd pool set cachepool key value

10.6.1.1 Tamanho e tipo de destino #

As seguintes etapas descrevem como configurar um pool de cache com os valores apresentados na Seção 10.5.2.2, “Pool de cache pequeno e muita memória”.

As camadas de cache de produção do Ceph usam um Filtro de Bloom para hit_set_type:

cephadm > sudo ceph osd pool set cachepool hit_set_type bloom

O hit_set_count e o hit_set_period definem quanto tempo cada conjunto de acertos deve cobrir e quantos desses conjuntos de acertos devem ser armazenados.

cephadm > sudo ceph osd pool set cachepool hit_set_count 12
cephadm > sudo ceph osd pool set cachepool hit_set_period 14400
cephadm > sudo ceph osd pool set cachepool target_max_bytes 1000000000000

Nota

Um hit_set_count maior resulta em mais memória RAM consumida pelo processo ceph-osd.

O min_read_recency_for_promote define em quantos conjuntos de acertos se deve verificar a existência de um objeto ao processar uma operação de leitura. O resultado da verificação é usado para decidir se é para promover o objeto de forma assíncrona. O valor dele deve ser entre 0 e hit_set_count. Se definido como 0, o objeto sempre será promovido. Se definido como 1, o conjunto atual de acertos será verificado. E se esse objeto estiver no conjunto atual de acertos, ele será promovido. Caso contrário, não. Para os outros valores, o número exato de conjuntos de acertos de armazenamento será verificado. O objeto será promovido se for encontrado em qualquer um dos min_read_recency_for_promote conjuntos de acertos mais recentes.

Você pode definir um parâmetro similar, min_write_recency_for_promote, para a operação de gravação:

cephadm > sudo ceph osd pool set cachepool min_read_recency_for_promote 2
cephadm > sudo ceph osd pool set cachepool min_write_recency_for_promote 2

Nota

Quanto maior o período e maior os valores min_read_recency_for_promote e min_write_recency_for_promote, mais RAM o daemon ceph-osd consome. Especificamente, quando o agente está ativo para descarregar ou eliminar objetos do cache, todos os hit_set_count conjuntos de acertos são carregados na memória RAM.

10.6.1.2 Tamanho do cache #

O agente de camadas de cache executa duas funções principais:

Descarregar: O agente identifica objetos modificados e os encaminha ao pool de armazenamento para armazenamento de longo prazo.
Eliminar: O agente identifica objetos que não foram modificados (limpos) e elimina do cache os que estão sem uso há mais tempo.

10.6.1.2.1 Tamanho absoluto #

O agente de camadas de cache pode descarregar ou eliminar objetos com base no número total de bytes ou no número total de objetos. Para especificar um número máximo de bytes, execute o seguinte:

cephadm > sudo ceph osd pool set cachepool target_max_bytes num_of_bytes

Para especificar o número máximo de objetos, execute o seguinte:

cephadm > sudo ceph osd pool set cachepool target_max_objects num_of_objects

Nota

O Ceph não pode determinar o tamanho de um pool de cache automaticamente, portanto, a configuração com base no tamanho absoluto é necessária neste caso. Do contrário, o descarregamento e a eliminação não funcionarão. Se você especificar os dois limites, o agente de camadas de cache iniciará o descarregamento ou a eliminação quando um dos limites for acionado.

Nota

Todas as solicitações de cliente serão bloqueadas apenas quando target_max_bytes ou target_max_objects for atingido.

10.6.1.2.2 Tamanho relativo #

O agente de camadas de cache pode descarregar ou eliminar objetos relativos ao tamanho do pool de cache (especificado por target_max_bytes ou target_max_objects na Seção 10.6.1.2.1, “Tamanho absoluto”). Quando o pool de cache consistir em determinada porcentagem de objetos modificados, o agente de camadas de cache os descarregará para o pool de armazenamento. Para definir o valor cache_target_dirty_ratio, execute o seguinte:

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_ratio 0.0...1.0

Por exemplo, a definição do valor como 0,4 iniciará o descarregamento dos objetos modificados quando eles atingirem 40% da capacidade do pool de cache:

cephadm > sudo ceph osd pool set hot-storage cache_target_dirty_ratio 0.4

Quando os objetos modificados atingirem determinada porcentagem da capacidade, descarregue-os a uma velocidade mais alta. Use cache_target_dirty_high_ratio:

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_high_ratio 0.0..1.0

Quando o pool de cache atingir determinada porcentagem da sua capacidade, o agente de camadas de cache eliminará os objetos para manter a capacidade livre. Para definir o valor cache_target_full_ratio, execute o seguinte:

cephadm > sudo ceph osd pool set cachepool cache_target_full_ratio 0.0..1.0

10.6.1.3 Data do cache #

Você pode especificar a data mínima de um objeto recém-modificado a partir da qual o agente de camadas de cache o descarregará para o pool de armazenamento de suporte:

cephadm > sudo ceph osd pool set cachepool cache_min_flush_age num_of_seconds

Você pode especificar a data mínima de um objeto para ele ser eliminado da camada de cache:

cephadm > sudo ceph osd pool set cachepool cache_min_evict_age num_of_seconds

10.6.1.4 Usar GMT para conjunto de acertos #

As configurações de camada de cache têm um filtro de Bloom denominado conjunto de acertos. O filtro faz um teste para identificar se um objeto pertence a determinado conjunto de objetos a quente ou a frio. Os objetos são adicionados ao conjunto de acertos usando marcações de horário anexadas aos nomes deles.

Se as máquinas de cluster forem colocadas em fusos horários diferentes, e as marcações de horário forem extraídas do horário local, os objetos em um conjunto de acertos poderão ter nomes equivocados indicando marcações de horário futuras ou passadas. Na pior das hipóteses, os objetos podem nem existir no conjunto de acertos.

Para que isso não aconteça, use_gmt_hitset é definido como o padrão “1” nas configurações de camada de cache recém-criadas. Dessa forma, você força os OSDs a usar as marcações de horário GMT (Horário de Greenwich) durante a criação dos nomes de objetos para o conjunto de acertos.

Atenção: Manter o valor padrão

Não modifique o valor padrão “1” de use_gmt_hitset. Se os erros relacionados a essa opção não forem causados pela configuração do cluster, nunca a modifique manualmente. Do contrário, o comportamento do cluster poderá ser imprevisível.

Imprimir esta página