Elastic Compute Service:Usando Shared Memory Communication (SMC)

Pré-requisitos

1. Crie uma instância do Elastic Compute Service (ECS) compatível com o recurso Elastic RoCE Infrastructure (ERI).

   Para usar o SMC-R na Alibaba Cloud, você precisa de uma instância do Elastic Compute Service (ECS) com capacidade de Elastic Remote Direct Memory Access (eRDMA). Para mais informações, consulte Ativar eRDMA em uma instância de nível empresarial.

   Importante

   • Atualmente, os dispositivos eRDMA da Alibaba Cloud e o SMC não suportam endereços IPv6. Se sua aplicação usar um endereço IPv6, o SMC fará fallback para TCP. Para mais informações, consulte Fallback do SMC para TCP com endereços IPv6.

   • A partir da versão ANCK 5.10.134-17.3, o SMC suporta endereços IPv4-mapped IPv6.

2. Carregue os módulos de kernel smc e smc_diag.

   sudo modprobe smc
   sudo modprobe smc_diag

   Execute o comando dmesg para visualizar as mensagens de log do kernel. Se a saída for semelhante à abaixo, os módulos foram carregados com sucesso.

   smc: smc: load SMC module with reserve_mode
   NET: Registered protocol family 43
   smc: netns <netns ID> reserved ports [65500 ~ 65515] for eRDMA OOB
   smc: adding ib device erdma_0 with port count 1
   smc:    ib device erdma_0 port 1 has pnetid

   (Opcional) Caso não precise mais dos módulos SMC, descarregue-os executando os seguintes comandos:

   sudo rmmod smc_diag
   sudo rmmod smc

3. Instale os utilitários smc-tools e aliyun-smc-extensions com os comandos abaixo.

   sudo yum install -y smc-tools
   sudo yum install -y aliyun-smc-extensions

Executar aplicações TCP na pilha SMC

O SMC-R no Alibaba Cloud Linux 3 suporta conversão transparente de protocolo de socket em dois níveis.

Conversão de socket no nível de net namespace

O Alibaba Cloud Linux 3 oferece um recurso para converter sockets transparentemente no nível de net namespace. Use a chave sysctl net.smc.tcp2smc para converter todos os sockets TCP de um net namespace em sockets SMC, desde que atendam às seguintes condições:

• A family é AF_INET.

• O type é SOCK_STREAM.

• O protocol é IPPROTO_IP(0) ou IPPROTO_TCP(6).

A figura a seguir ilustra o processo de conversão.

Siga estas etapas para ativar a conversão transparente no nível de net namespace.

1. Execute o comando abaixo para ativar a chave global net.smc.tcp2smc no net namespace.

   Os sockets TCP recém-criados serão convertidos para sockets SMC. Os sockets TCP existentes não são afetados.

   sudo sysctl net.smc.tcp2smc=1

   Por padrão, sysctl net.smc.tcp2smc está definido como 0, o que significa que o recurso está desativado.

2. Execute qualquer aplicação de socket TCP no net namespace atual.

   Substitua <foo> no exemplo pelo nome da sua aplicação.

   ./<foo>

   Os sockets TCP criados pela aplicação foo são substituídos transparentemente por sockets SMC, e a Pilha de Protocolo SMC-R gerencia o comportamento de rede da aplicação. Conforme descrito na Visão geral, se o par também suportar o protocolo SMC-R e a negociação for bem-sucedida, ambas as extremidades transferem dados pela rede RDMA. Caso contrário, a comunicação retorna com segurança para a rede TCP.

3. (Opcional) Execute o comando a seguir para desativar a chave de substituição global do net namespace. Os sockets TCP recém-criados deixarão de ser convertidos. Os sockets SMC existentes não são afetados.

   sudo sysctl net.smc.tcp2smc=0

Conversão de socket no nível de processo

O Alibaba Cloud Linux 3 também fornece conversão transparente de protocolo no nível de processo, habilitada por meio do utilitário smc-tools.

Ao executar uma aplicação com o script smc_run, a variável de ambiente LD_PRELOAD prioriza o carregamento da biblioteca dinâmica libsmc-preload.so. A biblioteca libsmc-preload.so converte em sockets SMC os sockets TCP da aplicação e de seus processos filhos que atendem às seguintes condições:

• A family é AF_INET.

• O type é SOCK_STREAM.

• O protocol é IPPROTO_IP(0) ou IPPROTO_TCP(6).

Nota

O smc_run usa LD_PRELOAD para interceptar a chamada de sistema socket() na glibc. Portanto, ele não funciona para aplicações vinculadas estaticamente ou que não utilizam a glibc.

A figura a seguir mostra o processo de substituição.

Siga estas etapas para ativar a conversão transparente no nível de processo.

Execute o comando abaixo, adicionando o prefixo smc_run antes do comando da sua aplicação foo.

Substitua <foo> no exemplo pelo nome do seu processo.

smc_run ./<foo>

Os sockets TCP criados pela aplicação foo são substituídos transparentemente por sockets SMC, e a Pilha de Protocolo SMC-R gerencia o comportamento de rede da aplicação. Conforme descrito na Visão geral, se o par também suportar o protocolo SMC-R e a negociação for bem-sucedida, ambas as extremidades transferem dados pela rede RDMA. Caso contrário, a comunicação retorna com segurança para a rede TCP.

smc-ebpf policy help

smc-ebpf policy help
 Usage: smc-ebpf policy COMMAND [OPTIONS]
        smc-ebpf policy load [OPTIONS]    load policy
    --init                                load policy with pre-defination config
        smc-ebpf policy stop              stop policy
        smc-ebpf policy unload            unload policy
        smc-ebpf policy init              init policy with default config
        smc-ebpf policy clear             clear all policy config
        smc-ebpf policy dump              display all policy config
        smc-ebpf policy config [OPTIONS]  config policy
        smc-ebpf policy delete [OPTIONS]  delete policy
    --ip [IPv4]                           target IPv4 address
    --port                                target port
    --mode [auto|disable|enable]          target mode
 Examples:
    smc-ebpf policy load
    #disable port 80 to use smc
    smc-ebpf policy config --port 80 --mode disable
    #delete ip xxx.xxx.x.x/24 policy
    smc-ebpf policy delete --ip xxx.xxx.x.x --mask 24

Carregar smc-ebpf

Execute o comando a seguir para carregar o smc-ebpf.

sudo smc-ebpf policy load

• A saída abaixo indica que o comando foi executado com sucesso:

  # sudo smc-ebpf policy load
  Registered smc_sock_negotiator_ops anolis_smc id xxx

• Caso contrário, não será possível usar esse recurso no ambiente atual. Os motivos possíveis incluem:

  • Verifique se a versão do kernel do sistema operacional é ANCK 5.10.134-016 ou posterior. Use o comando uname -r para checar a versão do kernel.

  • Confirme se você tem permissão para carregar programas BPF. Um problema comum é o container do pod não possuir capacidade para carregar programas BPF, ou o nível de privilégio do usuário ser insuficiente. Consulte o provedor do seu ambiente para obter mais informações.

Comportamento padrão das políticas de porta

Por padrão, após o carregamento do smc-ebpf, ele nega a negociação SMC para qualquer porta que não corresponda a uma política.

Por exemplo:

• Se o smc-ebpf for carregado sem nenhuma política de porta configurada, a negociação SMC será negada para todas as portas.

• Se o smc-ebpf for carregado e apenas uma política for configurada para permitir a negociação SMC na porta 80, a negociação SMC será negada para qualquer conexão que use a porta 8080, pois nenhuma política corresponde à porta 8080.

É possível alterar esse comportamento padrão executando o comando abaixo para definir a porta 0 como enable. Com essa configuração, se nenhuma política de porta corresponder a uma porta de destino, a negociação SMC será permitida para essa porta.

sudo smc-ebpf policy config --port 0 --mode enable

Da mesma forma, você pode reverter para o comportamento padrão original definindo a porta 0 como disable. Isso negará novamente a negociação SMC para qualquer porta que não tenha uma política correspondente.

sudo smc-ebpf policy config --port 0 --mode disable

Políticas baseadas em porta

Além do comportamento padrão, é possível adicionar políticas para portas específicas.

Por exemplo:

• Exemplo 1: Permitir a negociação SMC apenas na porta 80 e negá-la para todas as outras portas.

  Execute o comando a seguir para adicionar uma política que permita a negociação SMC na porta 80.

  sudo smc-ebpf policy config --port 80 --mode enable

  Execute o comando abaixo para visualizar a configuração da política de porta.

  sudo smc-ebpf policy dump

  Exemplo de saída:

  • "key": 80 indica que a política se aplica à porta 80.

  • "mode" indica se a negociação SMC é permitida ou negada. 2 significa permitido e 0 significa negado.

  # sudo smc-ebpf policy dump
  [{
          "key": 80,
          "value": {
              "mode": 2,
              [Other fields can be ignored by general users]
          }
      }
  ]

  Se essa política não for mais necessária, execute o comando a seguir para excluir a política da porta 80.

  sudo smc-ebpf policy delete --port 80

  Execute o comando dump novamente. A saída a seguir indica que a configuração foi excluída com sucesso.

  # sudo smc-ebpf policy dump
  []

• Exemplo 2: Negar a negociação SMC apenas na porta 80 e permiti-la para todas as outras portas.

  Execute os comandos a seguir para alterar o comportamento padrão, permitindo a negociação SMC para portas não correspondentes, e adicione uma política para negar especificamente a negociação SMC na porta 80.

  sudo smc-ebpf policy config --port 0 --mode enable
  sudo smc-ebpf policy config --port 80 --mode disable

  Após isso, a negociação SMC será negada apenas para a porta 80. Todas as outras portas que não corresponderem a uma política específica poderão usar a negociação SMC.

Comportamento padrão das políticas de endereço IPv4

Diferentemente das políticas de porta, as políticas de endereço IPv4 aplicam-se apenas a sockets cliente. Elas controlam se um cliente usa a negociação SMC com base no endereço IPv4 do servidor ao estabelecer uma conexão.

Por padrão, após o carregamento do smc-ebpf, ele permite a negociação SMC para qualquer IP de servidor que não corresponda a uma política de endereço IPv4.

Por exemplo:

• Se o smc-ebpf for carregado sem nenhuma política de endereço IPv4 configurada, os sockets cliente poderão usar a negociação SMC ao se conectarem a qualquer IP de servidor.

• Se o smc-ebpf for carregado e apenas uma política for configurada para negar a negociação SMC para a rede 192.168.1.0/24, uma conexão com 192.168.3.11 poderá usar a negociação SMC, pois nenhuma política corresponde a 192.168.3.11.

É possível alterar esse comportamento padrão executando o comando abaixo para definir 0.0.0.0/32 como disable. Com essa configuração, se nenhuma política de endereço IPv4 corresponder a um IP de servidor de destino, a negociação SMC será negada para esse IP.

sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable

Da mesma forma, você pode restaurar o comportamento padrão executando o comando a seguir. Isso permitirá novamente a negociação SMC para qualquer IP de servidor que não tenha uma política correspondente.

sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode enable

Políticas baseadas em endereço IPv4

Além do comportamento padrão, é possível configurar políticas para endereços IPv4 específicos a fim de controlar se um socket cliente usa a negociação SMC ao se conectar a um IP de servidor específico.

Por exemplo:

• Exemplo 1: Permitir que um cliente use a negociação SMC apenas ao se conectar a servidores na rede 192.168.2.0/24. Negar para todos os outros endereços de servidor.

  Execute os comandos a seguir para alterar o comportamento padrão, negando a negociação SMC para IPs de servidor não correspondentes, e adicione uma política para permiti-la na rede 192.168.2.0/24.

  sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable
  sudo smc-ebpf policy config --ip 192.168.2.0 --mask 24 --mode enable

  Execute o comando abaixo para visualizar a configuração da política IPv4.

  sudo smc-ebpf policy dump

  Exemplo de saída:

  • key: O endereço IPv4 de destino da política.

  • value: Indica se a negociação SMC é permitida ou negada. pass significa permitido e denied significa negado.

  # sudo smc-ebpf policy dump
  key:     0.0.0.0/32           value:   "denied"
  key:     192.168.2.0/24       value:   "pass"

  Se essas políticas não forem mais necessárias, execute os comandos a seguir para excluir as políticas para 0.0.0.0/32 e 192.168.2.0/24.

  sudo smc-ebpf policy delete --ip 192.168.2.0 --mask 24
  sudo smc-ebpf policy delete --ip 0.0.0.0 --mask 32

• Exemplo 2: Negar a negociação SMC para um cliente apenas ao se conectar à rede 192.168.2.0/24. Permitir para todos os outros endereços de servidor.

  Execute o comando a seguir para adicionar uma política que desative a negociação SMC para o intervalo de endereços de servidor 192.168.2.0/24.

  sudo smc-ebpf policy config --ip 192.168.2.0 --mask 24 --mode disable

  Nenhuma outra ação é necessária. Por padrão, após o carregamento do smc-ebpf, a negociação SMC é permitida para qualquer IP de servidor que não corresponda a uma política. Portanto, a negociação SMC é permitida para todos os endereços de servidor, exceto aqueles no intervalo 192.168.2.0/24.

Limpar políticas

Execute o comando a seguir para limpar todas as políticas configuradas.

sudo smc-ebpf policy clear

A execução desse comando exclui todas as configurações. O comportamento reverte para o estado padrão: a negociação SMC é negada para todas as portas, mas permitida para todos os endereços IPv4. Devido à lógica AND entre os dois tipos de política, isso impede que todas as conexões usem a negociação SMC.

Parâmetros Sysfs

Caso de uso: Evitar comunicação SMC-R entre AZs com EIDs

Para otimizar a aceleração SMC-R, recomendamos usá-lo para comunicação dentro da mesma Zona de Disponibilidade e usar TCP para comunicação entre Zonas de Disponibilidade. Ao adicionar o ID da Zona de Disponibilidade como um EID, você pode obter esse comportamento automaticamente. Siga estas etapas para configurá-lo.

• Método 1: Configurar o EID passo a passo

  1. Execute o comando a seguir para obter o ID da Zona de Disponibilidade nos Metadados da Instância do Elastic Compute Service (ECS) da Alibaba Cloud. Para mais informações, consulte Metadados da instância.

     ZONE_ID=$(curl -s -m 1 100.100.100.200/latest/meta-data/zone-id | tr "[:lower:]" "[:upper:]")

  2. Execute o comando a seguir para adicionar o ID da Zona de Disponibilidade como um EID.

     sudo smcr ueid add $ZONE_ID

  3. Execute o comando a seguir para excluir o SMCV2-DEFAULT-UEID padrão.

     smcr ueid | grep SMCV2-DEFAULT-UEID > /dev/null && sudo smcr ueid del SMCV2-DEFAULT-UEID

• Método 2: Usar o serviço aliyunsmc-ueid da ferramenta aliyun-smc-extensions para configuração com um clique

  1. Execute o comando a seguir para iniciar o serviço aliyunsmc-ueid. Este serviço adiciona automaticamente o ID da Zona de Disponibilidade como um EID e remove o EID padrão.

     sudo systemctl start aliyunsmc-ueid

  2. (Opcional) Execute o comando a seguir para ativar o início automático do serviço aliyunsmc-ueid na inicialização. Isso é necessário porque a configuração do EID não é persistente e é redefinida na reinicialização do SO.

     sudo systemctl enable aliyunsmc-ueid

Caso de uso: Associar veth do pod ao eRDMA do host

Em cenários onde vários pods em um único host compartilham uma ERI, é possível acelerar o tráfego da interface veth de um pod usando RDMA. Para isso, atribua o mesmo PNET ID à interface Ethernet veth do pod e à interface eRDMA do host. Isso permite que a Pilha de Protocolo do kernel dentro do container encontre corretamente a interface eRDMA do host quando o SMC-R estiver ativado.

Siga estas etapas para configurar.

1. No net namespace do container, configure um PNET ID para a interface Ethernet do container (por exemplo, eth0).

   sudo ip netns exec <pod netns> smc_pnet -a <PNET ID> -I eth0

2. No net namespace do host, configure o mesmo PNET ID para a interface eRDMA (por exemplo, erdma_0).

   sudo smc_pnet -a <PNET ID> -D erdma_0