Quando você tem um cluster em execução, pode usar a ferramenta ceph
para monitorá-lo. Normalmente, a determinação do estado do cluster envolve verificar o status do OSD, monitor, grupo de posicionamento e servidor de metadados.
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:
cephadm >
ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status
Após iniciar o cluster e antes de começar a leitura e/ou gravação de dados, verifique a saúde dele:
root #
ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3
O cluster do Ceph retorna um dos seguintes códigos de saúde:
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.
Todos os OSDs em uma subárvore específica do CRUSH estão marcados como inativos. Por exemplo, todos os OSDs em um host.
Um OSD é referenciado na hierarquia do mapa CRUSH, mas não existe. O OSD pode ser removido da hierarquia do CRUSH com:
root #
ceph osd crush rm osd.ID
Os limites de uso para backfillfull, nearfull, full e/ou failsafe_full não estão em ordem crescente. Especificamente, esperamos backfillfull < nearfull, nearfull < full e full < failsafe_full. É possível ajustar os limites com:
root #
ceph osd set-backfillfull-ratio ratioroot #
ceph osd set-nearfull-ratio ratioroot #
ceph osd set-full-ratio ratio
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:
root #
ceph df
É possível ver a cota full definida no momento com:
root #
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:
root #
ceph osd set-full-ratio ratio
Adicione o novo armazenamento ao cluster implantando mais OSDs ou apague os dados existentes para liberar espaço.
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:
root #
ceph df
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:
root #
ceph df
Um ou mais flags de interesse do cluster foram definidos. Com exceção de full, é possível definir ou limpar esses flags com:
root #
ceph osd set flagroot #
ceph osd unset flag
Esses flags incluem:
O cluster foi sinalizado como cheio e não pode realizar gravações.
Leituras ou gravações pausadas.
Os OSDs não têm permissão para serem iniciados.
Os relatórios de falha do OSD estão sendo ignorados, portanto, os monitores não marcarão os OSDs como inativos.
Os OSDs já marcados como out não serão remarcados como in quando forem iniciados.
Os OSDs inativos não serão automaticamente marcados como out após o intervalo configurado.
A recuperação ou a redistribuição de dados está suspensa.
A depuração (consulte a Seção 6.5, “Depuração”) está desabilitada.
A atividade de camadas de cache foi suspensa.
Um ou mais OSDs têm um flag de interesse definido por OSD. Esses flags incluem:
O OSD não tem permissão para ser iniciado.
Os relatórios de falha para este OSD serão ignorados.
Se este OSD já foi marcado como out automaticamente após uma falha, ele não será marcado como in quando for iniciado.
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:
root #
ceph osd add-flag osd-IDroot #
ceph osd rm-flag osd-ID
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
.
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).
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:
root #
ceph osd pool set poolname hit_set_type typeroot #
ceph osd pool set poolname hit_set_period period-in-secondsroot #
ceph osd pool set poolname hit_set_count number-of-hitsetsroot #
ceph osd pool set poolname hit_set_fpp target-false-positive-rate
Não há OSDs anterior ao Luminous v12 em execução, mas o flag sortbitwise
não foi definido. Você precisa definir o flag sortbitwise
antes que os OSDs Luminous v12 ou mais recentes possam ser iniciados:
root #
ceph osd set sortbitwise
Um ou mais pools atingiram a cota e não permitem mais gravações. Você pode definir cotas e uso de pool com:
root #
ceph df detail
Você pode aumentar a cota do pool com
root #
ceph osd pool set-quota poolname max_objects num-objectsroot #
ceph osd pool set-quota poolname max_bytes num-bytes
ou apagar alguns dados existentes para reduzir o uso.
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:
root #
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:
root #
ceph tell pgid query
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 com codificação de 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:
root #
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:
root #
ceph tell pgid query
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.
A depuração de dados (consulte a Seção 6.5, “Depuração”) 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.
Depurações recentes de OSD revelaram inconsistências.
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:
root #
ceph osd pool set cache-pool-name target_max_bytes bytesroot #
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.
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.
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.
O valor pg_num
de pools existentes não pode ser reduzido. Porém, o valor pgp_num
pode. Isso efetivamente combina alguns PGs nos mesmos conjuntos de OSDs, atenuando alguns dos impactos negativos descritos acima. É possível ajustar o valor pgp_num
com:
root #
ceph osd pool set pool pgp_num value
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:
ceph osd pool set pool pgp_num pg_num_value
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.
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:
root #
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:
root #
ceph osd pool application enable foo
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:
root #
ceph osd pool set-quota pool max_bytes bytesroot #
ceph osd pool set-quota pool max_objects objects
A definição do valor como 0 desabilitará a cota.
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:
root #
ceph osd osd pool set-quota pool max_bytes bytesroot #
ceph osd osd pool set-quota pool max_objects objects
A definição do valor como 0 desabilitará a cota.
Um ou mais objetos no cluster não estão armazenados no nó em que o cluster deseja que eles sejam armazenados. Isso é uma indicação de que a migração de dados decorrente de 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).
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 online no momento. As solicitações de leitura ou gravação para os objetos “não encontrados” serão bloqueadas. O ideal é que um OSD inativo com a cópia mais recente do objeto não encontrado possa voltar a ficar online. É 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:
root #
ceph tell pgid query
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:
root #
ceph daemon osd.id ops
Você pode ver um resumo das solicitações recentes mais lentas:
root #
ceph daemon osd.id dump_historic_ops
Você pode encontrar o local de um OSD com:
root #
ceph osd find osd.id
Uma ou mais solicitações OSD ficaram bloqueadas por um tempo extremamente longo. 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 de que existe algum problema interno com o OSD.
Um ou mais PGs não foram depurados (consulte a Seção 6.5, “Depuração”) 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:
root #
ceph pg scrub pgid
Um ou mais PGs não foram depurados em detalhes (consulte a Seção 6.5, “Depuração”) recentemente. Normalmente, os PGs são depurados a cada osd_deep_mon_scrub_interval
segundos, e esse aviso é acionado quando esses intervalos de mon_warn_not_deep_scrubbed
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:
root #
ceph pg deep-scrub pgid
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
Você pode detectar o estado imediato do cluster usando o comando ceph -s
. Por exemplo, um cluster do Ceph bem pequeno composto por um monitor e dois OSDs pode imprimir o seguinte quando há uma carga de trabalho em execução:
cluster: id: 6586341d-4565-3755-a4fd-b50f51bee248 health: HEALTH_OK services: mon: 3 daemons, quorum blueshark1,blueshark2,blueshark3 mgr: blueshark3(active), standbys: blueshark2, blueshark1 osd: 15 osds: 15 up, 15 in data: pools: 8 pools, 340 pgs objects: 537 objects, 1985 MB usage: 23881 MB used, 5571 GB / 5595 GB avail pgs: 340 active+clean io: client: 100 MB/s rd, 26256 op/s rd, 0 op/s wr
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
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; e
A quantidade total de dados armazenados.
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, insira qualquer um destes comandos (incluindo ceph -s
) em um loop de espera. Por exemplo:
root
while true ; do ceph -s ; sleep 10 ; done
Pressione Ctrl–C quando estiver cansado de observar.
Para verificar o uso de dados de um cluster e a distribuição de dados entre os pools, você pode usar a opção df
. Esse procedimento é similar ao df
do Linux. Execute o seguinte:
root #
ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
55886G 55826G 61731M 0.11
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
testpool 1 0 0 17676G 0
ecpool 2 4077M 0.01 35352G 2102
test1 3 0 0 17676G 0
rbd 4 16 0 17676G 3
rbd1 5 16 0 17676G 3
ecpool1 6 5708M 0.02 35352G 2871
A seção GLOBAL
da saída apresenta uma visão geral da quantidade de armazenamento que seu cluster usa para os dados.
SIZE
: A capacidade de armazenamento geral do cluster.
AVAIL
: A quantidade de espaço livre disponível no cluster.
RAW USED
: A quantidade usada de armazenamento bruto.
% 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 Capacidade de armazenamento para obter mais detalhes.
Um nível de preenchimento de armazenamento bruto de 70% a 80% indica que um novo armazenamento precisa ser adicionado 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.
NAME
: O nome do pool.
ID
: O ID do pool.
USED
: A quantidade estimada de dados armazenados em quilobytes, exceto quando o número tem M anexado para megabytes ou G para gigabytes.
%USED
: A porcentagem estimada de armazenamento usado por pool.
MAX AVAIL
: O espaço máximo disponível no pool especificado.
OBJECTS
: O número de objetos armazenados por pool.
Os números na seção POOLS são estimativas. Eles não incluem o número de réplicas, instantâneos ou clones. Sendo assim, a soma dos valores USED e %USED não incluirá os valores RAW USED e %RAW USED na seção %GLOBAL da saída.
Para verificar o status de um cluster, execute o seguinte:
root #
ceph status
ou
root #
ceph -s
No modo interativo, digite status
e pressione Enter.
ceph> status
O Ceph imprimirá o status do cluster. Por exemplo, um cluster do Ceph bem pequeno composto por um monitor e dois OSDs pode imprimir o seguinte:
cluster b370a29d-9287-4ca3-ab57-3d824f65e339 health HEALTH_OK monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1 osdmap e63: 2 osds: 2 up, 2 in pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects 115 GB used, 167 GB / 297 GB avail 1 active+clean+scrubbing+deep 951 active+clean
Você pode verificar os OSDs para garantir que estejam ativos e em execução:
root #
ceph osd stat
ou
root #
ceph osd dump
Você também pode ver os OSDs de acordo com a posição deles no mapa CRUSH.
root #
ceph osd tree
O Ceph imprimirá uma árvore CRUSH com um host, os OSDs, se eles estão ativos e o peso.
# id weight type name up/down reweight -1 3 pool default -3 3 rack mainrack -2 3 host osd-host 0 1 osd.0 up 1 1 1 osd.1 up 1 2 1 osd.2 up 1
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:
ceph health HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
ou
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 nós OSD, o que permite ao cluster redistribuir os dados para o armazenamento recém-disponibilizado.
Se você não pode iniciar um OSD porque ele está cheio, é possível apagar alguns dados excluindo diretórios do grupo de posicionamento no OSD cheio.
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.
Se o seu cluster tem vários monitores (mais provável), você deve verificar o status do quorum do monitor depois de iniciar o cluster, antes de ler e/ou gravar dados. Um quorum deve estar presente quando vários monitores estão em execução. Você também deve verificar o status do monitor periodicamente para garantir que ele esteja em execução.
Para exibir o mapa do monitor, execute o seguinte:
root #
ceph mon stat
ou
root #
ceph mon dump
Para verificar o status do quorum para o cluster do monitor, execute o seguinte:
root #
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": "127.0.0.1:6789\/0"}, { "rank": 1, "name": "b", "addr": "127.0.0.1:6790\/0"}, { "rank": 2, "name": "c", "addr": "127.0.0.1:6791\/0"} ] } }
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 Monitorando OSDs e grupos de posicionamento.
O soquete de admin do Ceph permite consultar um daemon pela interface do soquete. Por padrão, os soquetes do Ceph residem em /var/run/ceph
. Para acessar um daemon pelo soquete de admin, efetue login no host que executa o daemon e use o seguinte comando:
root #
ceph --admin-daemon /var/run/ceph/socket-name
Para ver os comandos de soquete de admin disponíveis, execute o seguinte comando:
root #
ceph --admin-daemon /var/run/ceph/socket-name help
O comando de soquete de admin permite mostrar e definir sua configuração em tempo de execução. Consulte Vendo uma configuração em tempo de execução para obter detalhes.
Você também pode definir diretamente os valores de configuração em tempo de execução (o soquete de admin ignora o monitor, ao contrário de ceph tell
daemon-type.id injectargs, que usa o monitor, mas não exige login diretamente no host em questão).