Início / server / Perguntas / 1166205
Accepted
Tintin
Asked: 2024-10-06 08:53:26 +0800 CST

Movendo daemons Ceph OSD para uma nova especificação de serviço

  • 772

Eu tinha uma especificação de serviço que atribuía todos os SSDs livres aos OSDs:

service\_type: osd  
service\_id: dashboard-tintin-7634852880  
service\_name: osd.dashboard-tintin-7634852880  
placement:  
  host\_pattern: '*'  
spec:  
  data\_devices:  
rotational: false  
  filter\_logic: AND  
  objectstore: bluestore

Quero mais controle sobre quais unidades cada servidor atribui, então criei algumas novas especificações da seguinte forma:

service_type: osd  
service_id: dashboard-tintin-1715222958508  
service_name: osd.dashboard-tintin-1715222958508  
placement:  
  host_pattern: 'host1'  
spec:  
  data_devices:  
rotational: false  
  filter_logic: AND  
  objectstore: bluestore

No Ceph Dashboard -> Services eu pude ver que meus antigos daemons OSD continuaram a rodar sob o controle das antigas definições de serviço. Eu deletei a antiga definição de serviço. Eu recebi um aviso:

If osd.dashboard-tintin-7634852880 is removed the the following OSDs will remain, --force to proceed anyway ...

Como pensei que manter os daemons funcionando é o que eu quero, continuei com --force. Agora o Ceph Dashboard -> Services lista os OSDs e "Unmanaged" e a nova definição de serviço ainda não os pegou. Como posso mover esses daemons OSD sob a nova especificação de serviço?

Se eu parar os daemons, os novos não serão iniciados pela nova definição de serviço. Se eu reimplantar os daemons, eles ainda serão exibidos como "não gerenciados". A única maneira de fazê-los mover sob a nova definição de serviço é parar o daemon e zap a unidade. No entanto, essa não é uma solução prática, dado o tamanho do cluster.

Considerando que os dados estão presentes e corretos, estou surpreso que não haja uma maneira de fazer com que daemons dispersos se curem. (Eu olhei a documentação sobre daemons dispersos, mas eles apenas fazem referência ao contexto de atualização do cluster para o cephadm).

Isto é parte do meu ceph orch ls osd --export:

service_type: osd
service_id: dashboard-tintin-1706434852880
service_name: osd.dashboard-tintin-1706434852880
unmanaged: true
spec:
  filter_logic: AND
  objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1715222958508
service_name: osd.dashboard-tintin-1715222958508
placement:
  host_pattern: ceph-pn-osd1
spec:
  data_devices:
    rotational: false
  filter_logic: AND
  objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1712545397532
service_name: osd.dashboard-tintin-1712545397532
placement:
  host_pattern: ceph-pn-osd2
spec:
  data_devices:
    rotational: false
  filter_logic: AND
  objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1706421419210
service_name: osd.dashboard-tintin-1706421419210
placement:
  host_pattern: ceph-pn-osd3
spec:
  data_devices:
    rotational: false
  filter_logic: AND
  objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1706421419211
service_name: osd.dashboard-tintin-1706421419211
placement:
  host_pattern: ceph-pn-osd4
spec:
  data_devices:
    rotational: false
  filter_logic: AND
  objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1706425693555
service_name: osd.dashboard-tintin-1706425693555
placement:
  host_pattern: ceph-pn-osd5
spec:
  data_devices:
    rotational: false
  filter_logic: AND
  objectstore: bluestore
ceph

1 respostas

  1. Best Answer

    Uma maneira seria modificar o unit.runarquivo para um OSD e apontá-lo para o service_namelocal desejado:

    head -2 /var/lib/ceph/{FSID}/osd.{OSD_ID}/unit.meta  
{
    "service_name": "osd.my-osd-service",

    Dependendo do intervalo de atualização do orquestrador, o modificado service_nameaparecerá após alguns minutos. Isso pode parecer um pouco hackeado, mas como não está claro por que suas especificações atuais de serviço OSD parecem não funcionar, seria uma solução alternativa razoável.

    • 0

relate perguntas