Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 5

4 Determinando o estado do cluster

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.

Dica
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:

cephadm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status

4.1 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:

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:

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:

root # ceph osd crush rm osd.ID
OSD_OUT_OF_ORDER_FULL

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 ratio
root # ceph osd set-nearfull-ratio ratio
root # 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:

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.

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:

root # 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:

root # 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:

root # ceph osd set flag
root # 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 6.5, “Depuração”) 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:

root # ceph osd add-flag osd-ID
root # 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:

root # ceph osd pool set poolname hit_set_type type
root # ceph osd pool set poolname hit_set_period period-in-seconds
root # ceph osd pool set poolname hit_set_count number-of-hitsets
root # ceph osd pool set poolname hit_set_fpp target-false-positive-rate
OSD_NO_SORTBITWISE

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
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:

root # ceph df detail

Você pode aumentar a cota do pool com

root # ceph osd pool set-quota poolname max_objects num-objects
root # 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:

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
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 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
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 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.

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:

root # ceph osd pool set cache-pool-name target_max_bytes bytes
root # 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.

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
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:

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:

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
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:

root # ceph osd pool set-quota pool max_bytes bytes
root # 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:

root # ceph osd osd pool set-quota pool max_bytes bytes
root # 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 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).

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 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
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:

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
REQUEST_STUCK

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.

PG_NOT_SCRUBBED

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
PG_NOT_DEEP_SCRUBBED

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
Dica
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

4.2 Observando um cluster

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.

Dica
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, insira qualquer um destes comandos (incluindo ceph -s) em um loop de espera. Por exemplo:

rootwhile true ; do ceph -s ; sleep 10 ; done

Pressione CtrlC quando estiver cansado de observar.

4.3 Verificando as estatísticas de uso do cluster

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.

    Nota
    Nota: Nível de preenchimento do cluster

    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.

Nota
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. 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.

4.4 Verificando o status do cluster

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

4.5 Verificando o status do OSD

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

4.6 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:

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.

Dica
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.

4.7 Verificando o status do monitor

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"}
           ]
    }
}

4.8 Verificando estados de grupo 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 Monitorando OSDs e grupos de posicionamento.

4.9 Usando o soquete de admin

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).

Imprimir esta página