Tintin's questions

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

Minha configuração de rede envolve dois firewalls em um grupo Common Address Redundancy Protocol (CARP), cada um conectado a uma configuração MLAG (Multi-Chassis Link Aggregation) de switches Mikrotik. As portas posteriores nos switches são vinculadas usando LACP.

                   VIP (WAN)
                      |
          -------------------------
         |                         |
         |                         |
  ------------     pfSync    ------------
 | Firewall 1 | <---------> | Firewall 2 |
  ------------               ------------
         |                         |
         |                         |
         |                         |
  ------------      MLAG     ------------
 |  Switch 1  | <---------> |  Switch 2  |
  ------------               ------------
         |                         |
          -------------------------
                       |
                   LACP (LAN)

Descrição: Como devem ser configuradas as portas do switch para os firewalls?

O MLAG permite que os switches apareçam para o hardware externo como se fossem um único switch. LAGG são criados nos switches físicos (ou seja, um vínculo LACP terá 1 porta do vínculo em cada switch para que um switch inteiro possa cair e a conexão sobreviver). Como as portas conectadas aos firewalls devem ser interligadas? Claramente, o LACP não está correto porque os firewalls não negociarão isso corretamente, pois os firewalls agem independentemente uns dos outros. Minhas opções parecem ser:

• backup ativo
• transmissão

Backup ativo

O desafio aqui é garantir que o link ativo do switch esteja alinhado com o firewall mestre CARP. Sem um mecanismo automático para alinhar a porta do switch ativa com o mestre CARP, esta configuração pode levar ao desalinhamento onde a porta do switch ativa está conectada ao firewall em espera.

Transmissão

Isso garante que o firewall CARP ativo sempre receba o tráfego, independentemente de qual seja o mestre, mas se um firewall sair do grupo CARP (por exemplo, porque o CARP está desabilitado para manutenção), ele começará a lidar com o tráfego duplicado.