Aplica-se a SUSE Enterprise Storage 7

12 Determinar o estado do cluster #

Quando você tem um cluster em execução, pode usar a ferramenta ceph para monitorá-lo. Normalmente, determinar o estado do cluster envolve verificar o status dos Ceph OSDs, Ceph Monitors, grupos de posicionamento e Servidores de Metadados.

Dica: Modo interativo

Para executar a ferramenta ceph no modo interativo, digite ceph na linha de comando sem argumentos. O modo interativo é o mais prático quando você pretende digitar mais comandos ceph em uma linha. Por exemplo:

cephuser@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat

12.1 Verificando o status de um cluster #

Você pode detectar o estado imediato do cluster usando ceph status ou ceph -s:

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

A saída apresenta as seguintes informações:

ID do cluster
Status de saúde do cluster
A época do mapa do monitor e o status do quorum do monitor
A época do mapa OSD e o status dos OSDs
O status dos Ceph Managers
O status dos Gateways de Objetos
A versão do mapa do grupo de posicionamento
O número de grupos de posicionamento e pools
A quantidade estimada de dados armazenados e o número de objetos armazenados
A quantidade total de dados armazenados.

Dica: Como o Ceph calcula o uso de dados

O valor usado reflete o valor real do armazenamento bruto utilizado. O valor xxx GB/xxx GB indica o valor disponível (o menor número) da capacidade de armazenamento geral do cluster. O número estimado reflete o tamanho dos dados armazenados antes de serem replicados, clonados ou capturados como instantâneos. Portanto, a quantidade de dados realmente armazenados costuma exceder o valor estimado armazenado, pois o Ceph cria réplicas dos dados e também pode usar a capacidade de armazenamento para fazer clonagem e criar instantâneos.

Outros comandos que exibem informações de status imediatas são:

ceph pg stat
ceph osd pool stats
ceph df
ceph df detail

Para obter as informações atualizadas em tempo real, especifique qualquer um desses comandos (incluindo o ceph -s) como um argumento do comando watch:

root # watch -n 10 'ceph -s'

Pressione Ctrl–C quando estiver cansado de observar.

12.2 Verificando a saúde do cluster #

Após iniciar o cluster e antes de começar a leitura e/ou gravação de dados, verifique a saúde dele:

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Dica

Se você especificou locais diferentes do padrão em sua configuração ou no chaveiro, deve especificar estes locais:

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

O cluster do Ceph retorna um dos seguintes códigos de saúde:

OSD_DOWN

Um ou mais OSDs estão marcados como inativos. O daemon OSD pode ter sido parado ou os OSDs peers talvez não conseguem acessar o OSD pela rede. As causas comuns incluem um daemon parado ou com falha, um host inativo ou uma interrupção da rede.

Verifique se o host está saudável, se o daemon foi iniciado e se a rede está funcionando. Se o daemon falhou, o arquivo de registro do daemon (/var/log/ceph/ceph-osd.*) pode incluir informações de depuração.

OSD_tipo de crush_DOWN. Por exemplo, OSD_HOST_DOWN

Todos os OSDs em uma subárvore específica do CRUSH estão marcados como inativos. Por exemplo, todos os OSDs em um host.

OSD_ORPHAN

Um OSD é referenciado na hierarquia do mapa CRUSH, mas não existe. O OSD pode ser removido da hierarquia do CRUSH com:

cephuser@adm > ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

Os limites de uso para backfillfull (padrão definido como 0,90), nearfull (padrão definido como 0,85), full (padrão definido como 0,95) e/ou failsafe_full não são ascendentes. Especificamente, esperamos backfillfull < nearfull, nearfull < full e full < failsafe_full.

Para ler os valores atuais, execute:

cephuser@adm > ceph health detail
HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)
osd.3 is full at 97%
osd.4 is backfill full at 91%
osd.2 is near full at 87%

É possível ajustar os limites com os seguintes comandos:

cephuser@adm > ceph osd set-backfillfull-ratio ratio
cephuser@adm > ceph osd set-nearfull-ratio ratio
cephuser@adm > ceph osd set-full-ratio ratio

OSD_FULL

Um ou mais OSDs excederam o limite de full e impedem o cluster de executar gravações. É possível verificar o uso por pool com:

cephuser@adm > ceph df

É possível ver a cota full definida no momento com:

cephuser@adm > ceph osd dump | grep full_ratio

Uma solução alternativa de curto prazo para resolver a disponibilidade de gravação é aumentar um pouco o valor do limite de full:

cephuser@adm > ceph osd set-full-ratio ratio

Adicione o novo armazenamento ao cluster implantando mais OSDs ou apague os dados existentes para liberar espaço.

OSD_BACKFILLFULL

Um ou mais OSDs excederam o limite de backfillfull, o que impede a redistribuição dos dados no dispositivo. Trata-se de um aviso antecipado de que a redistribuição talvez não possa ser concluída e de que o cluster está quase cheio. É possível verificar o uso por pool com:

cephuser@adm > ceph df

OSD_NEARFULL

Um ou mais OSDs excederam o limite de nearfull. Trata-se de um aviso antecipado de que o cluster está quase cheio. É possível verificar o uso por pool com:

cephuser@adm > ceph df

OSDMAP_FLAGS

Um ou mais flags de interesse do cluster foram definidos. Com exceção de full, é possível definir ou limpar esses flags com:

cephuser@adm > ceph osd set flag
cephuser@adm > ceph osd unset flag

Esses flags incluem:

full: O cluster foi sinalizado como cheio e não pode realizar gravações.
pauserd, pausewr: Leituras ou gravações pausadas.
noup: Os OSDs não têm permissão para serem iniciados.
nodown: Os relatórios de falha do OSD estão sendo ignorados, portanto, os monitores não marcarão os OSDs como inativos.
noin: Os OSDs já marcados como out não serão remarcados como in quando forem iniciados.
noout: Os OSDs inativos não serão automaticamente marcados como out após o intervalo configurado.
nobackfill, norecover, norebalance: A recuperação ou a redistribuição de dados está suspensa.
noscrub, nodeep_scrub: A depuração (consulte a Seção 17.6, “Depurando grupos de posicionamento”) está desabilitada.
notieragent: A atividade de camadas de cache foi suspensa.

OSD_FLAGS

Um ou mais OSDs têm um flag de interesse definido por OSD. Esses flags incluem:

noup: O OSD não tem permissão para ser iniciado.
nodown: Os relatórios de falha para este OSD serão ignorados.
noin: Se este OSD já foi marcado como out automaticamente após uma falha, ele não será marcado como in quando for iniciado.
noout: Se este OSD estiver inativo, ele não será automaticamente marcado como out após o intervalo configurado.

É possível definir e limpar os flags por OSD com:

cephuser@adm > ceph osd add-flag osd-ID
cephuser@adm > ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

O Mapa CRUSH usa configurações muito antigas e deve ser atualizado. Os tunables mais antigos que podem ser usados (ou seja, a versão de cliente mais antiga que pode se conectar ao cluster) sem acionar este aviso de saúde são determinados pela opção de configuração mon_crush_min_required_version.

OLD_CRUSH_STRAW_CALC_VERSION

O Mapa CRUSH usa um método mais antigo que não é o ideal para calcular os valores de peso intermediários para compartimentos de memória straw. O Mapa CRUSH deve ser atualizado para usar o método mais recente (straw_calc_version=1).

CACHE_POOL_NO_HIT_SET

Um ou mais pools de cache não estão configurados com um conjunto de acertos para monitorar o uso, o que impede o agente de camadas de identificar objetos frios para descarregar e eliminar do cache. É possível configurar conjuntos de acertos no pool de cache com:

cephuser@adm > ceph osd pool set poolname hit_set_type type
cephuser@adm > ceph osd pool set poolname hit_set_period period-in-seconds
cephuser@adm > ceph osd pool set poolname hit_set_count number-of-hitsets
cephuser@adm > ceph osd pool set poolname hit_set_fpp target-false-positive-rate

OSD_NO_SORTBITWISE

Não há OSDs anteriores ao Luminous v12 em execução, mas o flag sortbitwise não foi definido. Você precisa definir o flag sortbitwise para que os OSDs do Luminous v12 ou mais recentes possam ser iniciados:

cephuser@adm > ceph osd set sortbitwise

POOL_FULL

Um ou mais pools atingiram a cota e não permitem mais gravações. Você pode definir cotas e uso de pool com:

cephuser@adm > ceph df detail

Você pode aumentar a cota do pool com

cephuser@adm > ceph osd pool set-quota poolname max_objects num-objects
cephuser@adm > ceph osd pool set-quota poolname max_bytes num-bytes

ou apagar alguns dados existentes para reduzir o uso.

PG_AVAILABILITY

A disponibilidade de dados está reduzida, o que significa que o cluster não pode atender a possíveis solicitações de leitura ou gravação para alguns dados no cluster. Especificamente, o estado de um ou mais PGs não permite que as solicitações de E/S sejam atendidas. Os estados dos PGs problemáticos incluem emparelhamento, obsoleto, incompleto e a ausência de ativo (se essas condições não forem resolvidas rapidamente). As informações detalhadas sobre quais PGs são afetados estão disponíveis em:

cephuser@adm > ceph health detail

Na maioria dos casos, a causa raiz é que um ou mais OSDs estão inativos no momento. É possível consultar o estado dos PGs problemáticos específicos com:

cephuser@adm > ceph tell pgid query

PG_DEGRADED

A redundância de dados está reduzida para alguns dados, o que significa que o cluster não tem o número de réplicas desejado para todos os dados (em pools replicados) ou para fragmentos de código de eliminação (em pools codificados para eliminação). Especificamente, um ou mais PGs têm o flag degraded ou undersized definido (não há instâncias suficientes desse grupo de posicionamento no cluster) ou não tinham o flag clean definido durante determinado período. As informações detalhadas sobre quais PGs são afetados estão disponíveis em:

cephuser@adm > ceph health detail

Na maioria dos casos, a causa raiz é que um ou mais OSDs estão inativos no momento. É possível consultar o estado dos PGs problemáticos específicos com:

cephuser@adm > ceph tell pgid query

PG_DEGRADED_FULL

A redundância de dados pode estar reduzida ou em risco para alguns dados devido à ausência de espaço livre no cluster. Especificamente, um ou mais PGs têm o flag backfill_toofull ou recovery_toofull definido, o que significa que o cluster não pode migrar ou recuperar dados porque um ou mais OSDs estão acima do limite de backfillfull.

PG_DAMAGED

A depuração de dados (consulte a Seção 17.6, “Depurando grupos de posicionamento”) descobriu alguns problemas com a consistência de dados no cluster. Especificamente, um ou mais PGs têm o flag inconsistent ou snaptrim_error definido, indicando que uma operação de depuração anterior detectou um problema, ou o flag repair definido, o que significa que um reparo para esse tipo de inconsistência está agora em andamento.

OSD_SCRUB_ERRORS

Depurações recentes de OSD revelaram inconsistências.

CACHE_POOL_NEAR_FULL

Um pool de camada de cache está quase cheio. Neste contexto, “full” é determinado pelas propriedades target_max_bytes e target_max_objects no pool de cache. Quando o pool atinge o limite de destino, as solicitações de gravação para o pool podem ser bloqueadas enquanto os dados são descarregados e eliminados do cache, um estado que normalmente gera latências muito altas e baixo desempenho. É possível ajustar o tamanho do destino do pool de cache com:

cephuser@adm > ceph osd pool set cache-pool-name target_max_bytes bytes
cephuser@adm > ceph osd pool set cache-pool-name target_max_objects objects

As atividades normais de descarregamento e eliminação de cache também podem ficar restritas por redução na disponibilidade ou no desempenho da camada de base ou do carregamento geral do cluster.

TOO_FEW_PGS

O número de PGs em uso está abaixo do limite configurável de mon_pg_warn_min_per_osd PGs por OSD. Isso pode levar à distribuição e ao equilíbrio de dados abaixo do ideal em todos os OSDs no cluster, reduzindo o desempenho geral.

TOO_MANY_PGS

O número de PGs em uso está acima do limite configurável de mon_pg_warn_max_per_osd PGs por OSD. Isso pode levar a um aumento do uso de memória dos daemons OSD, a uma redução do emparelhamento após mudanças no estado do cluster (por exemplo, reinicializações, adições ou remoções de OSD) e a um aumento da carga nos Ceph Managers e Ceph Monitors.

Não é possível reduzir o valor pg_num dos pools existentes, mas é possível reduzir o valor pgp_num. Efetivamente, isso coloca alguns PGs nos mesmos conjuntos de OSDs, atenuando alguns dos impactos negativos descritos acima. É possível ajustar o valor pgp_num com:

cephuser@adm > ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM

Um ou mais pools têm um valor pgp_num menor do que pg_num. Normalmente, isso indica que a contagem de PGs foi aumentada sem aumentar também o comportamento de posicionamento. Isso costuma ser resolvido definindo pgp_num para corresponder a pg_num, o que aciona a migração de dados, com:

cephuser@adm > ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

Um ou mais pools têm um número médio de objetos por PG que é significativamente maior do que a média geral do cluster. O limite específico é controlado pelo valor da configuração mon_pg_warn_max_object_skew. Isso costuma ser uma indicação de que o(s) pool(s) com a maioria dos dados no cluster está(ão) com um número muito baixo de PGs, e/ou que outros pools sem tantos dados têm PGs em excesso. É possível aumentar o limite para silenciar o aviso de saúde ajustando a opção de configuração mon_pg_warn_max_object_skew nos monitores.

POOL_APP_NOT_ENABLED

Existe um pool que contém um ou mais objetos, mas que não foi marcados para uso por determinado aplicativo. Resolva esse aviso identificando o pool para uso por um aplicativo. Por exemplo, se o pool é usado pelo RBD:

cephuser@adm > rbd pool init pool_name

Se o pool é usado por um aplicativo personalizado “foo”, você também pode identificá-lo usando o comando de nível inferior:

cephuser@adm > ceph osd pool application enable foo

POOL_FULL

Um ou mais pools atingiram (ou estão muito próximos de atingir) a cota. O limite para acionar essa condição de erro é controlado pela opção de configuração mon_pool_quota_crit_threshold. É possível aumentar ou reduzir (ou remover) as cotas de pool com:

cephuser@adm > ceph osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd pool set-quota pool max_objects objects

A definição do valor como 0 desabilitará a cota.

POOL_NEAR_FULL

Um ou mais pools estão quase atingindo a cota. O limite para acionar essa condição de aviso é controlado pela opção de configuração mon_pool_quota_warn_threshold. É possível aumentar ou reduzir (ou remover) as cotas de pool com:

cephuser@adm > ceph osd osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd osd pool set-quota pool max_objects objects

A definição do valor como 0 desabilitará a cota.

OBJECT_MISPLACED

Um ou mais objetos no cluster não são armazenados no nó em que o cluster deseja que eles sejam. Isso é uma indicação de que a migração de dados causada por alguma mudança recente no cluster ainda não foi concluída. Os dados incorretamente armazenados não representam uma condição de risco por si só. A consistência de dados nunca está em risco, e as cópias antigas de objetos serão removidas apenas quando houver o número desejado de novas cópias (nos locais esperados).

OBJECT_UNFOUND

Um ou mais objetos no cluster não foram encontrados. Especificamente, os OSDs sabem que uma cópia nova ou atualizada de um objeto deve existir, mas uma cópia dessa versão do objeto não foi encontrada nos OSDs que estão ativos no momento. As solicitações de leitura ou gravação para os objetos “não encontrados” serão bloqueadas. No cenário ideal, o OSD inativo com a cópia mais recente do objeto não encontrado pode ser reativado. É possível identificar os OSDs candidatos com base no estado do emparelhamento referente ao(s) PG(s) responsável(is) pelo objeto não encontrado:

cephuser@adm > ceph tell pgid query

REQUEST_SLOW

O processamento de uma ou mais solicitações OSD está levando muito tempo. Isso pode ser uma indicação de carga extrema, um dispositivo de armazenamento lento ou um bug de software. É possível consultar a fila de solicitações no(s) OSD(s) em questão com o seguinte comando executado do host OSD:

cephuser@adm > ceph daemon osd.id ops

Você pode ver um resumo das solicitações recentes mais lentas:

cephuser@adm > ceph daemon osd.id dump_historic_ops

Você pode encontrar o local de um OSD com:

cephuser@adm > ceph osd find osd.id

REQUEST_STUCK

Uma ou mais solicitações OSD foram bloqueadas por um período relativamente longo. Por exemplo, 4096 segundos. Isso é uma indicação de que o cluster não esteve saudável por um longo período (por exemplo, não há OSDs suficientes em execução ou PGs inativos) ou de que existe algum problema interno com o OSD.

PG_NOT_SCRUBBED

Um ou mais PGs não foram depurados (consulte a Seção 17.6, “Depurando grupos de posicionamento”) recentemente. Normalmente, os PGs são depurados a cada mon_scrub_interval segundos, e esse aviso será acionado após decorrer mon_warn_not_scrubbed segundos sem uma depuração. Os PGs não serão depurados se não forem sinalizados como limpos, o que poderá ocorrer se forem armazenados incorretamente ou estiverem degradados (consulte PG_AVAILABILITY e PG_DEGRADED acima). Você pode iniciar manualmente uma depuração de um PG limpo com:

cephuser@adm > ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

Um ou mais PGs não foram depurados em detalhes (consulte a Seção 17.6, “Depurando grupos de posicionamento”) recentemente. Normalmente, os PGs são depurados a cada osd_deep_mon_scrub_interval segundos, e esse aviso é acionado quando mon_warn_not_deep_scrubbed segundos decorreram sem uma depuração. Os PGs não serão depurados (em detalhes) se não forem sinalizados como limpos, o que poderá ocorrer se forem armazenados incorretamente ou estiverem degradados (consulte PG_AVAILABILITY e PG_DEGRADED acima). Você pode iniciar manualmente uma depuração de um PG limpo com:

cephuser@adm > ceph pg deep-scrub pgid

Dica

Se você especificou locais diferentes do padrão em sua configuração ou no chaveiro, deve especificar estes locais:

root # ceph -c /path/to/conf -k /path/to/keyring health

12.3 Verificando as estatísticas de uso de um cluster #

Para verificar o uso e a distribuição dos dados de um cluster entre pools, use o comando ceph df. Para obter mais detalhes, use ceph df detail.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

A seção RAW STORAGE da saída apresenta uma visão geral da quantidade de armazenamento que seu cluster usa para os dados.

CLASS: A classe de armazenamento do dispositivo. Consulte a Seção 17.1.1, “Classes de dispositivo” para obter mais detalhes sobre classes de dispositivo.
SIZE: A capacidade de armazenamento geral do cluster.
AVAIL: A quantidade de espaço livre disponível no cluster.
USED: O espaço (acumulado de todos os OSDs) alocado exclusivamente para objetos de dados mantidos em dispositivo de blocos.
RAW USED: A soma do espaço “USED” e do espaço alocado/reservado no dispositivo de blocos para finalidade do Ceph. Por exemplo, parte do BlueFS para o BlueStore.
% RAW USED: A porcentagem usada de armazenamento bruto. Use esse número em conjunto com full ratio e near full ratio para garantir que você não atinja a capacidade do cluster. Consulte a Seção 12.8, “Capacidade de armazenamento” para obter mais detalhes.
Nota: Nível de preenchimento do cluster
Quando o nível de preenchimento de um armazenamento bruto está próximo de 100%, você precisa adicionar um novo armazenamento ao cluster. O uso mais alto pode resultar em OSDs únicos cheios e problemas de saúde do cluster.
Use o comando ceph osd df tree para listar o nível de preenchimento de todos os OSDs.

A seção POOLS da saída apresenta uma lista dos pools e o uso estimado de cada pool. A saída dessa seção não reflete réplicas, clones ou instantâneos. Por exemplo, se você armazenar um objeto com 1 MB de dados, o uso estimado será de 1 MB, mas o uso real poderá ser de 2 MB ou mais, dependendo do número de réplicas, clones e instantâneos.

POOL: O nome do pool.
ID: O ID do pool.
STORED: A quantidade de dados armazenados pelo usuário.
OBJECTS: O número de objetos armazenados por pool.
USED: A quantidade de espaço alocado exclusivamente para dados por todos os nós OSD em kB.
%USED: A porcentagem estimada de armazenamento usado por pool.
MAX AVAIL: O espaço máximo disponível no pool especificado.

Nota

Os números na seção POOLS são estimativas. Eles não incluem o número de réplicas, instantâneos ou clones. Como resultado, a soma dos valores USEDe %USED não incluirá os valores RAW USED e %RAW USED na seção RAW STORAGE da saída.

12.4 Verificando o status do OSD #

Você pode verificar os OSDs para garantir que estejam ativos e em execução:

cephuser@adm > ceph osd stat

cephuser@adm > ceph osd dump

Você também pode ver os OSDs de acordo com a posição deles no mapa CRUSH.

O ceph osd tree imprimirá uma árvore CRUSH com um host, os OSDs, se eles estão ativos e o peso:

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

12.5 Verificando se há OSDs cheios #

O Ceph impede você de gravar em um OSD cheio para evitar a perda de dados. Em um cluster operacional, você deve receber um aviso quando o cluster está próximo cota máxima. O padrão do valor mon osd full ratio é de 0,95, ou 95% da capacidade antes de impedir que os clientes gravem dados. O padrão do valor mon osd nearfull ratio é de 0,85, ou 85% da capacidade, quando ele gera um aviso de saúde.

O ceph health relata os nós OSD cheios:

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

A melhor maneira de resolver um cluster cheio é adicionar novos hosts/discos OSD, o que permite ao cluster redistribuir os dados para o armazenamento recém-disponibilizado.

Dica: Evitando OSDs cheios

Depois que um OSD fica cheio (usa 100% do espaço em disco), ele costuma falhar rapidamente sem aviso. Veja a seguir algumas dicas para se lembrar na hora de administrar nós OSD.

O espaço em disco de cada OSD (normalmente montado em /var/lib/ceph/osd/osd-{1,2..}) precisa ser colocado em um disco ou partição subjacente dedicado.
Verifique os arquivos de configuração do Ceph e certifique-se de que o Ceph não armazene o arquivo de registro em discos/partições dedicados para uso por OSDs.
Confirme se nenhum outro processo faz gravações nos discos/partições dedicados para uso por OSDs.

12.6 Verificando o status do monitor #

Após iniciar o cluster e antes da primeira leitura e/ou gravação de dados, verifique o status do quorum dos Ceph Monitors. Quando o cluster já estiver processando solicitações, verifique o status dos Ceph Monitors periodicamente para garantir que estejam em execução.

Para exibir o mapa do monitor, execute o seguinte:

cephuser@adm > ceph mon stat

cephuser@adm > ceph mon dump

Para verificar o status do quorum para o cluster do monitor, execute o seguinte:

cephuser@adm > ceph quorum_status

O Ceph retornará o status do quorum. Por exemplo, um cluster do Ceph com três monitores pode retornar o seguinte:

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

12.7 Verificando estados de grupos de posicionamento #

Os grupos de posicionamento mapeiam objetos para OSDs. Ao monitorar seus grupos de posicionamento, você deseja que eles estejam ativos e limpos. Para ver uma discussão detalhada, consulte a Seção 12.9, “Monitorando OSDs e grupos de posicionamento”.

12.8 Capacidade de armazenamento #

Quando um cluster de armazenamento do Ceph está próximo da sua capacidade máxima, o Ceph impede você de gravar ou ler os Ceph OSDs como medida de segurança para evitar perda de dados. Portanto, permitir que um cluster de produção se aproxime da sua cota máxima não é uma boa prática, porque coloca em risco a alta disponibilidade. A cota máxima padrão está definida como 0,95, que significa 95% da capacidade. Essa é uma configuração muito agressiva para um cluster de teste com um número pequeno de OSDs.

Dica: Aumentar a Capacidade de Armazenamento

Ao monitorar o cluster, fique atento aos avisos relacionados à cota nearfull. Eles indicam que a falha de alguns OSDs pode resultar em interrupção temporária de serviço. Considere adicionar mais OSDs para aumentar a capacidade de armazenamento.

Um cenário comum para clusters de teste envolve um administrador do sistema que remove um Ceph OSD do cluster de armazenamento do Ceph para observar a redistribuição do cluster. Em seguida, ele remove outro Ceph OSD, e assim por diante, até o cluster atingir a cota máxima e ser bloqueado. Recomendamos um pouco de planejamento de capacidade, mesmo com um cluster de teste. O planejamento permite estimar a quantidade de capacidade sobressalente que você precisará para manter a alta disponibilidade. O ideal é planejar uma série de falhas de Ceph OSDs em que o cluster possa se recuperar ao estado ativo + limpo sem substituir os Ceph OSDs imediatamente. Você pode executar um cluster no estado ativo + degradado, mas isso não é ideal em condições normais de operação.

O diagrama a seguir retrata um cluster de armazenamento do Ceph simples contendo 33 nós do Ceph com um Ceph OSD por host, cada um deles lendo e gravando em uma unidade de 3 TB. Esse cluster de exemplo tem uma capacidade máxima real de 99 TB. A opção mon osd full ratio está definida como 0,95. Se o cluster atingir 5 TB da capacidade restante, ele não permitirá que os clientes leiam e gravem dados. Portanto, a capacidade operacional do cluster de armazenamento é de 95 TB, não de 99 TB.

Figura 12.1: Cluster do Ceph #

Nesse tipo de cluster, é normal haver falha de um ou dois OSDs. Um cenário menos frequente, mas considerável, envolve uma falha no roteador do rack ou no fornecimento de energia, o que desligaria vários OSDs ao mesmo tempo (por exemplo, OSDs 7-12). Nesse cenário, você ainda deve recorrer a um cluster capaz de se manter operante e atingir o estado ativo + limpo, mesmo que isso signifique adicionar alguns hosts com outros OSDs a curto prazo. Se o uso da capacidade for muito alto, talvez você não perca os dados. Porém, você ainda poderá colocar em risco a disponibilidade dos dados ao resolver uma interrupção em um domínio de falha, se o uso da capacidade do cluster exceder a cota máxima. Por esse motivo, recomendamos pelo menos algum planejamento de capacidade estimada.

Identifique dois números para o cluster:

O número de OSDs.
A capacidade total do cluster.

Se você dividir a capacidade total pelo número de OSDs do cluster, encontrará a capacidade média de um OSD no cluster. Considere multiplicar esse número pela quantidade de OSDs que podem falhar simultaneamente durante as operações normais (um número relativamente pequeno). Por fim, multiplique a capacidade do cluster pela cota máxima para chegar a uma capacidade operacional máxima. Em seguida, subtraia o número da quantidade de dados dos OSDs que podem falhar para chegar a uma cota máxima razoável. Repita o processo anterior com um número maior de falhas de OSD (um rack de OSDs) para chegar a um número razoável para uma cota quase máxima.

As seguintes configurações aplicam-se apenas à criação de cluster e são armazenadas no mapa OSD:

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Dica

Essas configurações aplicam-se apenas durante a criação do cluster. Depois disso, elas precisarão ser mudadas no Mapa OSD usando os comandos ceph osd set-nearfull-ratio e ceph osd set-full-ratio.

mon osd full ratio: A porcentagem de espaço em disco usado antes que um OSD seja considerado cheio. O padrão é 0,95
mon osd backfillfull ratio: A porcentagem de espaço em disco usado antes que um OSD seja considerado muito cheio para provisionamento. O padrão é 0,90
mon osd nearfull ratio: A porcentagem de espaço em disco usado antes que um OSD seja considerado quase cheio. O padrão é 0,85

Dica: Verificar o peso do OSD

Se alguns OSDs estiverem quase cheios, mas outros tiverem bastante capacidade, talvez você tenha problemas com o peso do CRUSH para os OSDs quase cheios.

12.9 Monitorando OSDs e grupos de posicionamento #

As altas disponibilidade e confiabilidade exigem uma abordagem tolerante a falhas para gerenciar problemas de hardware e software. O Ceph não tem um ponto único de falha e pode processar solicitações de dados no modo "degradado". O posicionamento de dados do Ceph introduz uma camada de indireção para garantir que os dados não sejam diretamente vinculados a determinados endereços de OSD. Isso significa que o monitoramento de falhas no sistema requer encontrar o grupo de posicionamento e os OSDs subjacentes na raiz do problema.

Dica: Acesso em caso de falha

Uma falha em uma parte do cluster pode impedir você de acessar um determinado objeto. Isso não significa que você não pode acessar outros objetos. Em caso de falha, siga as etapas para monitorar os OSDs e grupos de posicionamento. Em seguida, comece a solução de problemas.

Em geral, o Ceph tem a funcionalidade de conserto automático. No entanto, quando os problemas persistem, o monitoramento de OSDs e grupos de posicionamento ajuda você a identificá-los.

12.9.1 Monitorando OSDs #

O status de um OSD é no cluster (“in”) ou fora do cluster (“out”). Ao mesmo tempo, ele é em execução (“up”) ou inativo e não operante (“down”). Se um OSD é “up”, ele pode estar no cluster (você pode ler e gravar dados) ou fora do cluster. Se ele estava no cluster e foi recentemente removido do cluster, o Ceph migra os grupos de posicionamento para outros OSDs. Se um OSD estiver fora do cluster, o CRUSH não atribuirá grupos de posicionamento a ele. Se um OSD é “down”, ele também deve ser “out”.

Nota: Estado não saudável

Se um OSD é “down” e “in”, há um problema, e o estado do cluster não é saudável.

Se você executar um comando, como ceph health, ceph -s ou ceph -w, poderá perceber que o cluster nem sempre retorna HEALTH OK. Em relação aos OSDs, você deve esperar que o cluster não retorne HEALTH OK nas seguintes circunstâncias:

Você ainda não iniciou o cluster (ele não responderá).
Você iniciou ou reiniciou o cluster e ele ainda não está pronto, porque os grupos de posicionamento estão sendo criados e os OSDs estão no processo de emparelhamento.
Você adicionou ou removeu um OSD.
Você modificou o mapa do cluster.

Um aspecto importante do monitoramento de OSDs é garantir que, quando o cluster estiver em execução, todos os OSDs no cluster também estejam funcionando. Para ver se todos os OSDs estão funcionando, execute:

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

O resultado deve indicar o número total de OSDs (x), quantos estão “up” (y), quantos estão “in” (z) e a época do mapa (eNNNN). Se o número de OSDs que estão “in” no cluster for maior do que o número de OSDs que estão “up”, execute o seguinte comando para identificar os daemons ceph-osd que não estão funcionando:

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Por exemplo, se um OSD com ID 1 estiver desativado, inicie-o:

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Consulte o Seção 4.3, “OSDs not running” para ver os problemas associados aos OSDs que estão parados ou que não serão reiniciados.

12.9.2 Atribuindo conjuntos de grupos de posicionamento #

Quando o CRUSH atribui grupos de posicionamento a OSDs, ele analisa o número de réplicas para o pool e atribui o grupo de posicionamento aos OSDs de modo que cada réplica do grupo de posicionamento seja atribuída a um OSD diferente. Por exemplo, se o pool exigir três réplicas de um grupo de posicionamento, o CRUSH poderá atribuí-las a osd.1, osd.2 e osd.3, respectivamente. Na verdade, o CRUSH busca um posicionamento pseudo-aleatório que considera os domínios de falha definidos no seu Mapa CRUSH. Sendo assim, você raramente verá grupos de posicionamento atribuídos aos OSDs vizinhos mais próximos em um cluster de grande porte. Nossa referência é ao conjunto de OSDs que deve incluir as réplicas de um determinado grupo de posicionamento como o conjunto de atuação. Em alguns casos, um OSD no conjunto de atuação está inativo ou, de alguma outra forma, não pode processar as solicitações para objetos no grupo de posicionamento. Nesses tipos de situação, um dos seguintes cenários pode ocorrer:

Você adicionou ou removeu um OSD. Em seguida, o CRUSH reatribuiu o grupo de posicionamento a outros OSDs e, portanto, mudou a composição do conjunto de atuação, provocando a migração dos dados com um processo de “provisionamento”.
Um OSD estava “down”, foi reiniciado e agora está se recuperando.
Um OSD no conjunto de atuação está “down” ou não pode processar as solicitações, e outro OSD assumiu temporariamente as tarefas dele.
O Ceph processa uma solicitação de cliente usando o conjunto ativo, que é o conjunto de OSDs que processará de fato as solicitações. Na maioria dos casos, o conjunto ativo e o conjunto de atuação são praticamente idênticos. Quando não são, isso pode indicar que o Ceph está migrando dados, que um OSD está se recuperando ou que há um problema. Por exemplo, o Ceph costuma retornar o estado HEALTH WARN com a mensagem “stuck stale” em cenários assim.

Para recuperar uma lista de grupos de posicionamento, execute:

cephuser@adm > ceph pg dump

Para ver quais OSDs estão no conjunto de atuação ou no conjunto ativo para um determinado grupo de posicionamento, execute:

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

O resultado deve indicar a época do osdmap (eNNN), o número do grupo de posicionamento (PG_NUM), os OSDs no conjunto ativo (“up”) e os OSDs no conjunto de atuação (“acting”):

Dica: Indicador de problema no cluster

Se o conjunto ativo e o conjunto de atuação não forem os mesmos, isso pode ser um indicador de que o cluster está realizando a própria redistribuição ou de um possível problema com o cluster.

12.9.3 Emparelhamento #

Antes que você possa gravar dados em um grupo de posicionamento, ele deve estar no estado ativo e, de preferência, limpo. Para o Ceph determinar o estado atual de um grupo de posicionamento, o OSD principal do grupo de posicionamento (o primeiro OSD no conjunto de atuação), é emparelhado com os OSDs secundários e terciários para estabelecer um acordo em relação ao estado atual do grupo de posicionamento (considerando um pool com três réplicas do PG).

Figura 12.2: Esquema de emparelhamento #

12.9.4 Monitorando estados de grupos de posicionamento #

Se você executar um comando, como ceph health, ceph -s ou ceph -w, poderá perceber que o cluster nem sempre retorna a mensagem HEALTH OK. Após verificar se os OSDs estão em execução, verifique também os estados do grupo de posicionamento.

É esperado que o cluster não retorne HEALTH OK em várias circunstâncias relacionadas ao emparelhamento de grupos de posicionamento:

Você criou um pool, e os grupos de posicionamento ainda não foram emparelhados.
Os grupos de posicionamento estão se recuperando.
Você adicionou ou removeu um OSD do cluster.
Você modificou seu Mapa CRUSH, e seus grupos de posicionamento estão sendo migrados.
Há dados inconsistentes em diferentes réplicas de um grupo de posicionamento.
O Ceph está depurando as réplicas de um grupo de posicionamento.
O Ceph não tem capacidade de armazenamento suficiente para concluir as operações de provisionamento.

Se uma das circunstâncias mencionadas acima fizer com que o Ceph retorne HEALTH WARN, não se preocupe. Em muitos casos, o cluster se recuperará por conta própria. Em alguns casos, pode ser necessário tomar medidas. Um aspecto importante do monitoramento dos grupos de posicionamento é garantir que, quando o cluster estiver em funcionamento, todos os grupos de posicionamento estejam "ativos" e, de preferência, no "estado limpo". Para ver o status de todos os grupos de posicionamento, execute:

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

O resultado deve indicar o número total de grupos de posicionamento (x), quantos grupos de posicionamento estão em determinado estado, como “ativo+limpo” (y) e a quantidade de dados armazenados (z).

Além dos estados do grupo de posicionamento, o Ceph também retornará a quantidade de capacidade de armazenamento utilizada (aa), a quantidade de capacidade de armazenamento restante (bb) e a capacidade total de armazenamento do grupo de posicionamento. Esses números podem ser importantes em alguns casos:

Você está atingindo a cota quase máxima ou cota máxima.
Seus dados não estão sendo distribuídos por todo o cluster por causa de um erro na configuração do CRUSH.

Dica: IDs dos grupos de posicionamento

Os IDs dos grupos de posicionamento consistem no número do pool (não no nome do pool) seguido de um ponto (.) e no ID do grupo de posicionamento: um número hexadecimal. Você pode ver os números de pool e os respectivos nomes na saída do comando ceph osd lspools. Por exemplo, o pool padrão rbd corresponde ao número do pool 0. Um ID de grupo de posicionamento totalmente qualificado tem o seguinte formato:

POOL_NUM.PG_ID

Normalmente, ele tem a seguinte aparência:

0.1f

Para recuperar uma lista de grupos de posicionamento, execute o seguinte:

cephuser@adm > ceph pg dump

Você também pode formatar a saída em JSON e gravá-la em um arquivo:

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Para consultar um determinado grupo de posicionamento, execute o seguinte:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

A lista a seguir descreve os estados comuns do grupo de posicionamento em detalhes.

CREATING

Quando você cria um pool, ele cria o número de grupos de posicionamento que você especificou. O Ceph retornará “creating” (criando) durante a criação de um ou mais grupos de posicionamento. Quando são criados, os OSDs que fazem parte do conjunto de atuação do grupo de posicionamento são emparelhados. Quando o emparelhamento é concluído, o status do grupo de posicionamento deve ser “ativo+limpo”, o que significa que um cliente Ceph pode começar a gravar no grupo de posicionamento.

Figura 12.3: Status dos grupos de posicionamento #

PEERING

Quando o Ceph está emparelhando um grupo de posicionamento, ele leva os OSDs que armazenam as réplicas do grupo de posicionamento a um acordo em relação ao estado dos objetos e metadados nesse grupo. Quando o Ceph conclui o emparelhamento, isso significa que os OSDs que armazenam o grupo de posicionamento concordam sobre o estado atual desse grupo. No entanto, a conclusão do processo de emparelhamento não significa que cada réplica tem o conteúdo mais recente.

Nota: Histórico de autorização

O Ceph não confirmará uma operação de gravação em um cliente até que todos os OSDs do conjunto de atuação continuem a operação de gravação. Esta prática garante que pelo menos um membro do conjunto de atuação tenha um registro de cada operação de gravação confirmada desde a última operação de emparelhamento bem-sucedida.

Com um registro preciso de cada operação de gravação confirmada, o Ceph pode construir e ampliar um novo histórico de autorização do grupo de posicionamento: um conjunto completo e totalmente organizado de operações que, se executadas, mantêm uma cópia do OSD de um grupo de posicionamento atualizada.

ACTIVE

Quando o Ceph conclui o processo de emparelhamento, um grupo de posicionamento pode se tornar ativo. O estado ativo significa que os dados no grupo de posicionamento geralmente estão disponíveis no grupo de posicionamento principal e nas réplicas para as operações de leitura e gravação.

CLEAN

Quando um grupo de posicionamento está no estado limpo, o OSD principal e os OSDs de réplica foram emparelhados com êxito e não há réplicas perdidas para o grupo de posicionamento. O Ceph replicou o número correto de vezes todos os objetos no grupo de posicionamento.

DEGRADED

Quando um cliente grava um objeto no OSD principal, esse OSD é responsável por gravar as réplicas nos OSDs de réplica. Depois que o OSD principal gravar o objeto no armazenamento, o grupo de posicionamento permanecerá no estado "degradado" até que o OSD principal receba uma confirmação dos OSDs de réplica de que que Ceph criou os objetos de réplica com êxito.

O motivo pelo qual um grupo de posicionamento pode ser “ativo+degradado” é que um OSD pode ser “ativo” mesmo que ainda não armazene todos os objetos. Se um OSD ficar inativo, o Ceph marcará cada grupo de posicionamento atribuído ao OSD como “degradado”. Os OSDs deverão ser emparelhados novamente quando o OSD voltar a ficar ativo. No entanto, um cliente ainda poderá gravar um novo objeto em um grupo de posicionamento degradado se ele for “ativo”.

Se um OSD for “inativo” e a condição “degradado” permanecer, o Ceph poderá marcar o OSD inativo como “fora” do cluster e remapear os dados do OSD “inativo” para outro OSD. O tempo entre ser marcado como “inativo” e como “fora” é controlado pela opção mon osd down out interval, que por padrão está definida como 600 segundos.

Um grupo de posicionamento também pode ser "degradado" porque o Ceph não encontra um ou mais objetos que deveriam estar no grupo de posicionamento. Embora você não possa ler ou gravar em objetos não encontrados, ainda pode acessar todos os outros objetos no grupo de posicionamento “degradado”.

RECOVERING

O Ceph foi projetado para tolerância a falhas em escala, quando os problemas de hardware e software são constantes. Quando um OSD fica “inativo”, o conteúdo dele pode não acompanhar o estado atual das outras réplicas nos grupos de posicionamento. Quando o OSD volta a ficar “ativo”, o conteúdo dos grupos de posicionamento deve ser atualizado para refletir o estado atual. Durante esse período, o OSD pode refletir um estado de "recuperação".

A recuperação nem sempre é comum, porque uma falha de hardware pode causar uma falha em cascata de vários OSDs. Por exemplo, em uma possível falha do switch de rede para um rack ou gabinete, os OSDs de várias máquinas host podem não acompanhar o estado atual do cluster. Cada um dos OSDs deverá se recuperar quando a falha for resolvida.

O Ceph oferece uma série de configurações para equilibrar a contenção de recursos entre as novas solicitações de serviço e a necessidade de recuperar os objetos de dados e restaurar os grupos de posicionamento ao estado atual. A configuração osd recovery delay start permite que um OSD reinicie, emparelhe novamente e até processe algumas solicitações de reprodução antes do início do processo de recuperação. A osd recovery thread timeout define um tempo de espera do thread porque vários OSDs podem falhar, ser reiniciados e novamente emparelhados em fases. A configuração osd recovery max active limita o número de solicitações de recuperação que um OSD processará simultaneamente para impedir falha no processamento do OSD. A configuração osd recovery max chunk limita o tamanho dos blocos de dados recuperados para evitar congestionamento de rede.

BACK FILLING

Quando um novo OSD ingressa no cluster, o CRUSH reatribui os grupos de posicionamento dos OSDs no cluster para o OSD recém-adicionado. Forçar o novo OSD a aceitar os grupos de posicionamento reatribuídos imediatamente pode sobrecarregar o novo OSD. O provisionamento do OSD com os grupos de posicionamento permite que este processo seja iniciado em segundo plano. Quando o provisionamento for concluído, o novo OSD começará a processar solicitações quando estiver pronto.

Durante as operações de provisionamento, você pode ver um dos vários estados: “backfill_wait” indica que uma operação de provisionamento está pendente, mas ainda não está em andamento; “backfill” indica que uma operação de provisionamento está em andamento; “backfill_too_full” indica que uma operação de provisionamento foi solicitada, mas não pôde ser concluída devido à capacidade de armazenamento insuficiente. Quando não é possível provisionar um grupo de posicionamento, ele pode ser considerado “incompleto”.

O Ceph dispõe de várias configurações para gerenciar a carga associada à reatribuição de grupos de posicionamento para um OSD (especialmente um novo OSD). Por padrão, osd max backfills define o número máximo de provisionamentos simultâneos de/para um OSD como 10. A cota máxima de provisionamento permite que um OSD recuse uma solicitação de provisionamento se ele estiver próximo da sua cota máxima (90%, por padrão) e faça a modificação com o comando ceph osd set-backfillfull-ratio. Se um OSD recusar uma solicitação de provisionamento, o osd backfill retry interval permitirá que um OSD repita a solicitação (após 10 segundos, por padrão). O OSDs também podem definir osd backfill scan min e osd backfill scan max para gerenciar intervalos de exploração (64 e 512, por padrão).

REMAPPED

Quando o conjunto de atuação que processa um grupo de posicionamento é modificado, os dados são migrados do conjunto de atuação antigo para o conjunto de atuação novo. Pode levar algum tempo para um novo OSD principal processar as solicitações. Por isso, talvez seja solicitado para o conjunto principal antigo continuar processando as solicitações até que a migração do grupo de posicionamento seja concluída. Quando a migração dos dados for concluída, o mapeamento usará o OSD principal do novo conjunto de atuação.

STALE

Enquanto o Ceph usa os heartbeats para garantir que os hosts e daemons estejam em execução, os daemons ceph-osd também podem entrar em um estado “travado” quando não estiverem relatando estatísticas em tempo hábil (por exemplo, uma falha temporária na rede). Por padrão, os daemons OSD relatam suas estatísticas de grupo de posicionamento, inicialização e falha a cada meio segundo (0,5), que é mais frequente do que os limites de heartbeat. Se o OSD principal do conjunto de atuação de um grupo de posicionamento não puder relatar para o monitor ou se outros OSDs relataram o OSD principal como “inativo”, os monitores marcarão o grupo de posicionamento como “obsoleto”.

Quando você inicia o cluster, é comum ver o estado "obsoleto" até o processo de emparelhamento ser concluído. Depois que o cluster estiver funcionando por um tempo, ver grupos de posicionamento no estado "obsoleto" indicará que o OSD principal para esses grupos está inativo ou não está relatando as estatísticas de grupo de posicionamento para o monitor.

12.9.5 Encontrando o local de um objeto #

Para armazenar dados de objetos no Armazenamento de Objetos do Ceph, um cliente Ceph precisa definir um nome de objeto e especificar um pool relacionado. O cliente Ceph recupera o mapa do cluster mais recente e o algoritmo CRUSH calcula como mapear o objeto para um grupo de posicionamento e, em seguida, calcula como atribuir o grupo de posicionamento a um OSD dinamicamente. Para encontrar o local do objeto, tudo o que você precisa é do nome do objeto e do nome do pool. Por exemplo:

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

Exemplo 12.1: Localizando um objeto #

Como exemplo, vamos criar um objeto. Especifique o nome do objeto “test-object-1”, um caminho para o arquivo de exemplo “testfile.txt” com alguns dados do objeto e o nome do pool “data” usando o comando rados put na linha de comando:

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

Para verificar se o Armazenamento de Objetos do Ceph armazenou o objeto, execute o seguinte:

cephuser@adm > rados -p data ls

Agora, identifique o local do objeto. O Ceph retornará o local do objeto:

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

Para remover o objeto de exemplo, basta apagá-lo usando o comando rados rm:

cephuser@adm > rados rm test-object-1 --pool=data