Verificando as configurações RDMA para problemas de conectividade no Linux

As questões de conectividade do RDMA são mais comumente causadas por má configuração. Você pode verificar as configurações do RDMA para garantir que os membros possam se comunicar com a CF.

Antes de iniciar

Você deve garantir que todos os pacotes OFED necessários estejam instalados em todos os hosts, e que todos os softwares necessários atendam aos níveis mínimos suportados. Você pode conferir os pacotes e versões instalados emitindo o comando rpm -qa | grep ofed .

Procedimento

Use as seguintes etapas para verificar suas configurações RDMA :

Examine os estados de porta física executando o comando ibstat -v .

Assegure-se de que o Estado seja Ativo e o Estado Físico seja LinkUp , conforme mostrado no exemplo a seguir:

CA 'mthca0'
        CA type: MT25208 (MT23108 compat mode)
        Number of ports: 2
        Firmware version: 4.7.400
        Hardware version: a0
        Node GUID: 0x0005ad00000c03d0
        System image GUID: 0x0005ad00000c03d3
        Port 1:
                State: Active
                Physical state: LinkUp
                Rate: 10
                Base lid: 16
                LMC: 0
                SM lid: 2
                Capability mask: 0x02510a68
                Port GUID: 0x0005ad00000c03d1
        Port 2:
                State: Down
                Physical state: Polling
                Rate: 10
                Base lid: 0
                LMC: 0
                SM lid: 0
                Capability mask: 0x02510a68
                Port GUID: 0x0005ad00000c03d2

Se o Estado do porto não estiver Ativo, verifique o cabo para conectividade.

Sobre os hosts CF, verifique se o endereço IP associado às portas IB corresponde aos endereços IP utilizados para os nomes líquidos para a entrada CF no arquivo db2nodes.cfg .
1. Visualizar o endereço IP que está associado com as portas IB no host CF.
  Para visualizar o endereço IP que está associado à porta IB, execute o comando ifconfig -a . O endereço IP pode ser encontrado olhando para o endereço que está associado ao campo inet addr conforme mostrado:
```
coralxib20:/home/svtdbm3 >ifconfig -a
ib0       Link encap:UNSPEC  HWaddr 80-00-04-04-FE-80-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.1.120  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::205:ad00:c:3d1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:65520  Metric:1
          RX packets:18672 errors:0 dropped:0 overruns:0 frame:0
          TX packets:544 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:256
          RX bytes:2198980 (2.0 Mb)  TX bytes:76566 (74.7 Kb)
```
  Na saída, ib0 é o nome da interface. O status é UP e o endereço IP é 10.1.1.120.. É importante garantir que o status da interface esteja em alta.
2. Certifique-se dos nomes de rede para a CF na correspondência db2nodes.cfg file com os endereços IP para a porta IB pretendida utilizar para a CF.
  Você também deve garantir que o nome pode ser pingado, e é alcançável a partir de todos os hosts no cluster.
  A partir de cada host membro, execute um comando ping contra os nomes de rede que estão associados com a entrada CF no arquivo db2nodes.cfg . Observe o endereço IP retornado. O endereço IP deve corresponder ao endereço IP que está associado com a configuração de porta IB no host CF, como na saída ifconfig -a .
  
  Nota: Ao efetuar ping de um endereço IP em uma sub-rede diferente, os pings não são bem-sucedidos. Isso ocorre quando você tem várias máscaras de sub-rede para cada interface quando há várias interfaces definidas para a CF. Neste caso, a partir do membro, ping o endereço IP de destino no host CF que possui a mesma máscara de sub-rede que a interface no host membro.
Verifique se a interface uDAPL está configurada no arquivo /etc/dat.conf em todos os hosts e se o valor da porta do adaptador correto é usado.. O arquivo dat.conf não é necessário para o RHEL 8.x e superior.
Como Db2® pureScale® usa uDAPL 2.0, procure a primeira entrada que tenha u2.0 na segunda coluna com o nome da interface correspondente e o número da porta. No Linux®, o valor da porta do adaptador não é usado e é "0". A entrada a seguir pode parecer semelhante à entrada em seu /etc/dat.conf no SLES, ou /etc/rdma/dat.conf no arquivo RHEL:
```
ofa-v2-ib0 u2.0 nonthreadsafe default libdaplofa.so.2 dapl.2.0 "ib0 0" ""
```
Na saída, ofa-v2-ib0 é o nome do dispositivo de transporte exclusivo para a interface uDAPL O u2.0 indica que a entrada é para um aplicativo uDAPL 2.0 . Você deve assegurar que o arquivo libdaplofa.so.2 exista para ele ser a biblioteca compartilhada uDAPL . A saída ib0 0 é os dados de instância específicos do provedor uDAPL Nesse caso, o adaptador é ib0, e a porta é "0", uma vez que não é utilizada.
Se a CF estiver configurada com várias interfaces usando vários netnames no arquivo db2nodes.cfg , você deve garantir que todas as interfaces estejam definidas no arquivo dat.conf .
Nota: O arquivo /etc/dat.conf deve conter apenas entradas para os adaptadores que estão no host local. Normalmente, o arquivo de amostra /etc/dat.conf instalado por padrão contém entradas irrelevantes. Para evitar o processamento desnecessário do arquivo, realize as seguintes mudanças:
- Mova todas as entradas do adaptador relacionadas ao cluster Db2 pureScale para a parte superior do arquivo.
- Comente as entradas irrelevantes ou as remova do arquivo.
Certifique-se de que o valor de porta especificado na solicitação de conexão do cliente corresponda ao valor de porta que a CF atende.
Você deve garantir que os valores da porta CF sejam os mesmos nos arquivos /etc/services para todos os hosts no cluster.
1. Para determinar o valor de porta que é usado para a CF, procure no arquivo de log de diagnóstico CF.
  No arquivo cfdiag_<timestamp>.<id>.log , procure o valor que está associado ao campo CA Port[0] como parte das informações do prolog no início do arquivo de log.
2. Para determinar o valor de porta que é usado pelo membro na solicitação de conexão, procure o evento PsOpen no arquivo de log de diagnóstico do Db2 membro (db2diag.log).
  Procure o valor do campo caport .
Executar um ping RDMA em todo o cluster, executando o seguinte:
```
db2cluster -verify -req -rdma_ping
```