Todos os produtos
Search
Central de documentação

Alibaba Cloud Linux:Usando Shared Memory Communication (SMC)

Última atualização: Jul 04, 2026

Este tópico explica como ativar o Shared Memory Communication (SMC), definir seu escopo de aceleração e configurar suas interfaces para obter desempenho ideal.

Usar o SMC no Alibaba Cloud ECS

Siga estas etapas para usar o SMC-R.

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.

image

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.

image

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.

Controle de negociação SMC com BPF

Na prática, ativar o SMC no nível de net namespace ou de processo pode ser muito abrangente. Por exemplo, um servidor pode ter várias portas de escuta em um único net namespace. Talvez você queira usar o SMC apenas para conexões em portas que exigem aceleração de desempenho, enquanto conexões em outras portas, como as de gerenciamento, devem retornar com segurança para TCP.

Para resolver isso, o Alibaba Cloud Linux 3 suporta o uso de BPF para controlar a negociação SMC das conexões após a ativação da conversão transparente. O processo típico é o seguinte:

  1. Ative e configure políticas BPF para estabelecer um controle granular da negociação SMC.

  2. Ative o SMC no nível de net namespace ou de processo. Para mais informações, consulte Executar aplicações TCP na pilha SMC.

Conforme descrito na Visão geral, as partes comunicantes usam uma opção TCP especial durante o handshake TCP para declarar e confirmar o suporte mútuo ao SMC-R. Se a negociação for bem-sucedida, a transmissão de rede subsequente entre as duas partes ocorrerá via rede RDMA. Caso contrário, a conexão retorna com segurança para a rede TCP.

Por padrão, um socket SMC sempre inicia e responde a essa opção TCP especial. No entanto, é possível usar BPF para obter um controle mais granular sobre a ativação do SMC, aplicando políticas baseadas em portas ou endereços IPv4.

O Alibaba Cloud Linux 3 fornece a ferramenta smc-ebpf (parte do smc-tools) para configurar essas políticas BPF.

Execute o comando abaixo para verificar se o smc-ebpf foi instalado corretamente.

smc-ebpf policy help

Se a saída a seguir for exibida, o smc-ebpf foi instalado com sucesso.

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
Aviso
  • O smc-ebpf não afeta conexões estabelecidas antes do seu carregamento.

  • As políticas configuradas pelo smc-ebpf abrangem todo o sistema e não podem ser definidas para net namespaces específicos (containers).

  • Os recursos do smc-ebpf ainda estão em processo de padronização na comunidade upstream. As interfaces podem mudar no futuro e são consideradas experimentais no momento.

  • 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.

Nota

Todas as políticas de porta e de endereço IPv4 configuradas são combinadas com lógica AND. A negociação SMC só é usada se todas as políticas correspondentes a permitirem. Se qualquer política correspondente negar a negociação SMC, ela não será utilizada.

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.

Nota

As regras de filtragem de endereço IPv4 configuradas controlam apenas a negociação SMC para sockets cliente que se conectam a um servidor; elas não afetam sockets de servidor.

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.

Usar o SMC no Alibaba Cloud ACK

No Container Service for Kubernetes (ACK), é possível ativar o SMC por meio do componente ACK eRDMA Controller. O eRDMA Controller gerencia placas de rede eRDMA, agendamento e capacidades de rede para Pods. Para mais informações, consulte Usar SMC-R para acelerar transparentemente redes de aplicações.

Nota

Assim como ao usar o SMC no Alibaba Cloud ECS, ao usar o SMC no Alibaba Cloud ACK, você também pode configurar políticas granulares de ativação de SMC baseadas em BPF no nó.

Parâmetros

A Pilha de Protocolo SMC fornece interfaces de configuração por meio de sysfs e ferramentas de espaço de usuário como smc-tools. As seções a seguir descrevem os recursos configuráveis do SMC.

Parâmetros Sysfs

Parâmetro do kernel

Descrição

Requisitos de versão do kernel

Recomendações

net.smc.autocorking_size

O SMC-R oferece o recurso autocork, semelhante ao autocork do TCP. Ele agrega vários pacotes de dados pequenos em um pacote maior para uma única transmissão. Isso melhora o throughput para cargas de trabalho de pacotes pequenos sem afetar a latência ping-pong.

O parâmetro autocorking_size define o limite superior para o tamanho dos pacotes agregados.

Valor padrão: 65535.

Valores válidos: 0 a 4294967295. O valor 0 desativa o recurso.

Kernel 5.10.112-11 e posteriores.

Para cargas de trabalho de pacotes pequenos que priorizam largura de banda, ajuste este parâmetro para um valor adequado a fim de obter throughput ideal.

Para cargas de trabalho de envio/recebimento pipeline que priorizam latência, defina este valor como 0 para evitar atrasos introduzidos pelo autocork.

net.smc.autosplit_size

O SMC fornece um recurso autosplit que divide um pacote de dados grande em vários pacotes menores para transmissão em lote. Isso melhora o desempenho de latência em cenários de pacotes grandes. Quando o tamanho de um pacote excede 1,3 vezes o autosplit_size, ele é dividido.

Valor padrão: 131072.

Valores válidos: 32768 a 536870912.

Versões do kernel:

  • 5.10.134-18 e posteriores.

  • 5.10.134-17.3 e posteriores na série 17.

  • 5.10.134-16.5 e posteriores na série 16.

Em cenários sensíveis à latência com pacotes grandes, ajuste este parâmetro para obter a latência ideal.

net.smc.experiment_vendor_options

Opções de recursos experimentais da Alibaba Cloud.

Valor padrão: 4294967295 (0xFFFFFFFF).

Kernel 5.10.134-16 e posteriores.

Recomendamos que você não modifique este parâmetro.

net.smc.global_mem

Controla a marca d'água de memória para SMC em todo o sistema. Quando o tamanho total dos buffers de envio e recebimento mantidos pela Pilha de Protocolo SMC atinge global_mem[2], todas as novas conexões SMC retornarão para TCP.

Valor padrão: [25% da memória total do sistema, 50% da memória total do sistema, 75% da memória total do sistema].

Versões do kernel:

  • 5.10.134-18 e posteriores.

  • 5.10.134-17.3 e posteriores na série 17.

  • 5.10.134-16.5 e posteriores na série 16.

Configure global_mem[2] de acordo com a marca d'água de memória desejada.

net.smc.limit_smc_hs

Controla se deve haver retorno proativo para TCP quando a pressão de estabelecimento de conexão estiver alta.

Valor padrão: 1.

Valores válidos:

  • 0: Desativado

  • 1: Ativado

Versões do kernel:

  • 5.10.134-18 e posteriores.

  • 5.10.134-17.3 e posteriores na série 17.

  • 5.10.134-16.5 e posteriores na série 16.

Recomendamos definir como 1 (ativado).

Em casos específicos em que você não deseja que a pilha de protocolo SMC faça fallback automático com base na pressão de conexão, defina como 0.

net.smc.mem

Controla a marca d'água de memória para SMC no net namespace atual. Quando o tamanho total dos buffers de envio e recebimento de todas as conexões SMC no net namespace atinge mem[2], todas as novas conexões SMC neste net namespace retornarão para TCP.

Valor padrão: [25% da memória total do sistema, 50% da memória total do sistema, 75% da memória total do sistema].

Versões do kernel:

  • 5.10.134-18 e posteriores.

  • 5.10.134-17.3 e posteriores na série 17.

  • 5.10.134-16.5 e posteriores na série 16.

Configure mem[2] de acordo com a marca d'água de memória desejada.

net.smc.rmem

Tamanho padrão do buffer de recebimento para um socket SMC. Este valor é usado quando o tamanho do buffer de recebimento (SO_RCVBUF) não é definido explicitamente usando setsockopt().

Valor padrão: 262144.

Valores válidos:

  • SMC-R: 16384 (16 KB) a 536870912 (512 MB)

  • SMC-D: 16384 (16 KB) a 1048576 (1 MB)

Kernel 5.10.134-14 e posteriores.

  • Se a métrica local Rx/Buffer full estiver alta, aumente o tamanho do buffer de recebimento local.

  • Se as métricas locais Tx/Buffer full(remote) e Tx/Buffer too small(remote) estiverem altas, aumente o tamanho do buffer de recebimento do par.

  • Se os recursos de memória estiverem escassos e a redução do tamanho do buffer não afetar o desempenho da rede, diminua o tamanho do buffer.

Para mais informações, consulte Monitoramento do SMC.

net.smc.wmem

Tamanho padrão do buffer de envio para um socket SMC. Este valor é usado quando o tamanho do buffer de envio (SO_SNDBUF) não é definido explicitamente usando setsockopt().

Valor padrão: 262144.

Valores válidos:

  • SMC-R: 16384 (16 KB) a 536870912 (512 MB)

  • SMC-D: 16384 (16 KB) a 1048576 (1 MB)

Kernel 5.10.134-14 e posteriores.

  • Se as métricas locais Tx/Buffer full e Tx/Buffer too small estiverem altas, aumente o tamanho do buffer de envio local.

  • Se os recursos de memória estiverem escassos e a redução do tamanho do buffer não afetar o desempenho da rede, diminua o tamanho do buffer.

Para mais informações, consulte Monitoramento do SMC.

net.smc.smcr_buf_type

Tipo de memória para buffers de envio e recebimento SMC-R. A memória fisicamente contígua oferece melhor desempenho, mas geralmente é difícil de alocar, o que pode resultar em tamanhos de buffer menores que o esperado. Por outro lado, a memória virtualmente contígua é mais fácil de alocar, mas oferece desempenho ligeiramente inferior.

Alterações neste valor entram em vigor nas conexões SMC transportadas por LGRs recém-criados. LGRs existentes não são afetados.

Valor padrão: 2.

Valores válidos:

  • 0: Memória fisicamente contígua.

  • 1: Memória virtualmente contígua.

  • 2: Priorizar memória fisicamente contígua, mas usar memória virtualmente contígua se não for possível obtê-la.

Kernel 5.10.134-12 e posteriores.

Recomendamos que você não modifique este parâmetro.

net.smc.smcr_max_conns_per_lgr

Número máximo de conexões SMC que um LGR pode transportar no SMC-R.

Valor padrão: 32.

Valores válidos:

  • 1 a 255 (5.10.134-18 e posteriores, 5.10.134-17.3 e posteriores na série 17, 5.10.134-16.5 e posteriores na série 16).

  • 16 a 255 (outras versões).

Kernel 5.10.134-16.1 e posteriores.

Modifique com cautela.

  • Para cenários de alto throughput, reduza adequadamente o número de conexões SMC por LGR para garantir que cada conexão SMC obtenha mais largura de banda RDMA.

  • Não recomendamos aumentar este valor.

net.smc.smcr_max_links_per_lgr

Número de conexões RDMA RC (SMC Links) que um LGR contém no SMC-R.

Valor padrão: 1.

Valores válidos: 1 a 2.

Kernel 5.10.134-16.1 e posteriores.

Recomendamos que você não modifique este parâmetro.

net.smc.smcr_testlink_time

Intervalo de pacotes de heartbeat (em segundos) para uma conexão RDMA RC (SMC Link) no SMC-R. Quando não há transmissão de dados no SMC Link, 16 bytes de dados são enviados a cada smcr_testlink_time segundos para confirmar a disponibilidade do link.

Valor padrão: 30.

Valores válidos: 0 a 2147483647. O valor 0 desativa a verificação de heartbeat.

Kernel 5.10.134-13 e posteriores.

Recomendamos que você não modifique este parâmetro.

net.smc.tcp2smc

Ativa ou desativa a conversão transparente de TCP para SMC no net namespace atual. Quando ativado, novos sockets TCP criados neste net namespace são interceptados no kernel. Isso os converte em sockets SMC substituindo seus parâmetros family e protocol, que então executam na Pilha de Protocolo SMC.

Valor padrão: 0.

Valores válidos:

  • 0: Desativa a substituição SMC do net namespace.

  • 1: Ativa a substituição SMC do net namespace.

Kernel 5.10.134-16 e posteriores.

  • Defina como 1 para ativar a substituição transparente de TCP para SMC no nível de net namespace.

  • Defina como 0 para desativar a substituição transparente de TCP para SMC no nível de net namespace.

Parâmetros EID

Introduzido no protocolo SMCv2, o Enterprise ID (EID) garante que apenas sistemas com um EID correspondente possam se comunicar via SMCv2; caso contrário, eles retornam para TCP. Um sistema pode ter até oito EIDs.

image

No Alibaba Cloud Linux 3, dispositivos eRDMA só podem ser usados com o protocolo SMCv2. Os sistemas Alibaba Cloud Linux 3 são inicialmente configurados com o EID SMCV2-DEFAULT-UEID. Portanto, por padrão, todos os nós do Alibaba Cloud Linux 3 podem se comunicar entre si usando SMCv2 com eRDMA sem nenhuma configuração manual.

Se você precisar controlar o escopo de comunicação modificando o EID em circunstâncias especiais, siga estas etapas.

  1. Visualize os EIDs existentes.

    smcr ueid show
  2. Adicione um novo EID.

    Um EID pode conter até 32 caracteres, incluindo letras maiúsculas (A-Z), números (0-9), hifens (-) e pontos (.). O primeiro caractere deve ser uma letra ou um número, e pontos (.) não podem ser usados consecutivamente.

    sudo smcr ueid add <EID>
  3. Exclua um EID existente.

    sudo smcr ueid del <EID>

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

Parâmetros PNET ID

O tráfego TCP flui através de uma Elastic Network Interface (ENI). Quando esse tráfego é convertido transparentemente para SMC-R, a Pilha de Protocolo SMC-R usa a interface de rede RDMA (ERI) associada a essa ENI.

Essa associação pode ser estabelecida de duas maneiras.

  • A ERI é obtida ativando diretamente a capacidade eRDMA na ENI de destino. Nesse caso, a pilha de protocolo SMC-R associa automaticamente esta ENI à ERI.

    Neste cenário, a pilha de protocolo SMC-R pode identificar e usar automaticamente a ERI associada à ENI, sem necessidade de operações adicionais.

  • A ERI é obtida ativando a capacidade eRDMA em uma ENI diferente. Nesse caso, você deve usar um PNET ID para associar a ERI à ENI de destino.

    Considere o seguinte cenário:

    Um host possui duas interfaces Ethernet, eth0 e eth1. Apenas eth0 tem uma interface RDMA ativada, erdma_0.

    Se o tráfego TCP for enviado e recebido através de eth0, a mudança para SMC-R permite que o sistema encontre automaticamente a erdma_0 associada e use a rede RDMA para comunicação. Este é o cenário de associação automática descrito acima.

    No entanto, se o tráfego TCP for enviado e recebido através de eth1, a mudança para SMC-R falhará ao encontrar a interface erdma_0, causando um fallback para TCP. Para resolver isso, associe eth1 e erdma_0 ao mesmo PNET ID, o que instrui o SMC-R a usar erdma_0 para o tráfego de eth1.

    image

    Siga estas etapas para associar uma ENI e uma ERI usando um PNET ID:

    • Execute os comandos a seguir para configurar o mesmo PNET ID para a ENI e a ERI de destino:

      • Configure um PNET ID para a ENI.

        sudo smc_pnet -a <PNET ID> -I <eth_interface>
      • Configure um PNET ID para a interface eRDMA (ERI).

        sudo smc_pnet -a <PNET ID> -D <rdma_interface>

      Um PNET ID pode ter até 16 caracteres alfanuméricos maiúsculos sem espaços.

    • Execute o comando a seguir para verificar os parâmetros PNET ID configurados.

      # sudo smc_pnet

      Exemplo de saída:

      # sudo smc_pnet
      00163E0CD751 n/a erdma_0 1
      00163E0CD751 eth1 n/a 255

      Neste exemplo, erdma_0 está vinculado ao PNET ID 00163E0CD751, e eth1 também está vinculado ao PNET ID 00163E0CD751. Isso permite que a comunicação TCP que originalmente usava a interface eth1 passe a usar a interface erdma_0 após a ativação do SMC-R.

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.

image

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

Caso de uso: Usar SMC com Redis em uma instância ECS

  1. Crie duas instâncias do Elastic Compute Service (ECS). Uma servirá como cliente Redis e a outra como servidor Redis. Para mais informações sobre os parâmetros, consulte Iniciar instâncias ECS personalizadas.

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

    sudo modprobe smc
    sudo modprobe smc_diag
  3. Execute o comando a seguir em ambas as instâncias para instalar o Redis.

    sudo yum install redis -y
  4. Execute o comando a seguir em ambas as instâncias para configurar EIDs e evitar comunicação SMC-R entre Zonas de Disponibilidade.

    sudo systemctl start aliyunsmc-ueid
  5. Execute os comandos a seguir em ambas as instâncias para configurar políticas BPF baseadas em porta. Isso permite a negociação SMC apenas para conexões onde o endereço IP do servidor está dentro do bloco CIDR do vswitch e a porta de serviço é 6379.

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

      sudo smc-ebpf policy load
    2. Configure uma política baseada em porta para permitir a negociação SMC apenas para a porta 6379.

      sudo smc-ebpf policy config --port 6379 --mode enable
    3. Configure uma política baseada em endereço IPv4 para permitir a negociação SMC apenas para IPs de servidor dentro do bloco CIDR do vswitch.

      sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable
      cidr=$(curl -s -m 1 100.100.100.200/latest/meta-data/vswitch-cidr-block)
      sudo smc-ebpf policy config --ip \
        $(echo ${cidr} | awk -F'/' '{print $1}') --mask \
        $(echo ${cidr} | awk -F'/' '{print $2}') --mode enable
  6. Execute o comando a seguir em ambas as instâncias para configurar a conversão transparente de protocolo no nível de net namespace.

    sudo sysctl -w net.smc.tcp2smc=1
  7. Na instância do servidor Redis, execute o comando a seguir para iniciar o serviço Redis.

    Substitua <IP> pelo endereço IP privado da Elastic Network Interface (ENI) principal da instância do servidor.

    redis-server --bind <IP> --port 6379 --protected-mode no --save
  8. Na instância do cliente Redis, conecte-se ou teste o servidor Redis.

    • Execute o comando a seguir para se conectar ao servidor Redis.

      redis-cli -h <IP> -p 6379
    • Execute o comando a seguir para realizar um teste de benchmark usando redis-benchmark.

      redis-benchmark -h <IP> -p 6379 -n 1000000 -t set -c 100