automation-suite
2023.10
true
Guia de instalação do Automation Suite no Linux
Last updated 11 de nov de 2024

Um cluster do Ceph foi encontrado em um estado degradado após atualização lado a lado

Description

Ocasionalmente, após uma atualização lado a lado, o aplicativo Rook-ceph entra em um estado de "falha de sincronização" no portal do ArgoCD. Isso é devido a um problema do Ceph upstream.

Para identificar o motivo do estado degradado, execute o seguinte comando:

kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph -skubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph -s 

Se você receber uma saída semelhante ao seguinte exemplo, o problema estará relacionado à integridade do Rook-Ceph:

cluster:
    id:     936b2e58-1014-4237-b2a5-6e95449a9ce8
    health: HEALTH_ERR
            Module 'devicehealth' has failed: disk I/O error

  services:
    mon: 3 daemons, quorum a,b,c (age 11h)
    mgr: b(active, since 37h), standbys: a
    osd: 3 osds: 3 up (since 37h), 3 in (since 37h)
    rgw: 2 daemons active (2 hosts, 1 zones)

  data:
    pools:   8 pools, 225 pgs
    objects: 53.57k objects, 26 GiB
    usage:   80 GiB used, 688 GiB / 768 GiB avail
    pgs:     225 active+clean

  io:
    client:   561 KiB/s rd, 61 KiB/s wr, 316 op/s rd, 123 op/s wr  cluster:
    id:     936b2e58-1014-4237-b2a5-6e95449a9ce8
    health: HEALTH_ERR
            Module 'devicehealth' has failed: disk I/O error

  services:
    mon: 3 daemons, quorum a,b,c (age 11h)
    mgr: b(active, since 37h), standbys: a
    osd: 3 osds: 3 up (since 37h), 3 in (since 37h)
    rgw: 2 daemons active (2 hosts, 1 zones)

  data:
    pools:   8 pools, 225 pgs
    objects: 53.57k objects, 26 GiB
    usage:   80 GiB used, 688 GiB / 768 GiB avail
    pgs:     225 active+clean

  io:
    client:   561 KiB/s rd, 61 KiB/s wr, 316 op/s rd, 123 op/s wr

Solução

Para corrigir o problema, siga as seguintes etapas:

  1. No fragmento de saída, identifique o serviço de gerenciamento do mgr com um estado ativo. No exemplo fornecido, mgr: b é marcado como ativo.
  2. Para identificar o nome do pod exato, execute o seguinte comando:

    kubectl -n rook-ceph get pods | grep "rook-ceph-mgr-<active-manager-name>"kubectl -n rook-ceph get pods | grep "rook-ceph-mgr-<active-manager-name>"
    O comando deve retornar uma saída semelhante ao seguinte exemplo, onde rook-ceph-mgr-b-6d7bdb4b54-zz47v é o nome do pod do gerenciador:
    rook-ceph-mgr-b-6d7bdb4b54-zz47v 0/1 Init:0/1 0 3h55mrook-ceph-mgr-b-6d7bdb4b54-zz47v 0/1 Init:0/1 0 3h55m
  3. Exclua o gerenciador ativo executando o seguinte comando:

    kubectl -n rook-ceph delete pod <active-manager-pod-name>
    
    // for example: kubectl -n rook-ceph delete pod rook-ceph-mgr-b-6d7bdb4b54-zz47vkubectl -n rook-ceph delete pod <active-manager-pod-name>
    
    // for example: kubectl -n rook-ceph delete pod rook-ceph-mgr-b-6d7bdb4b54-zz47v

A exclusão do gerenciador ativo o força a reiniciar, tornando o estado do cluster do Ceph Íntegro.

  • Description
  • Solução

Esta página foi útil?

Obtenha a ajuda que você precisa
Aprendendo RPA - Cursos de automação
Fórum da comunidade da Uipath
Uipath Logo White
Confiança e segurança
© 2005-2024 UiPath. Todos os direitos reservados.