Elastic Compute Service:共有メモリ通信 (SMC) の使用

前提条件

開始する前に、以下の条件を満たしていることを確認してください：

• 弾力的なリモートダイレクトメモリアクセス (eRDMA) 機能を提供する Elastic RDMA Interface (ERI) をサポートする ECS インスタンス。詳細については、「エンタープライズ向けインスタンスでの eRDMA の構成」をご参照ください。

SMC のセットアップ

1. SMC カーネルモジュールをロードします。

sudo modprobe smc
sudo modprobe smc_diag

dmesg を実行して、モジュールが正しくロードされたことを確認します：

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

必要がなくなった場合に SMC をアンロードするには、以下を実行します：

sudo rmmod smc_diag
sudo rmmod smc

2. 運用・保守 (O&M) ツールセットをインストールします。

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

ネットワーク名前空間レベルのソケット変換の有効化

この方法では、sysctl 設定後に作成されるすべての該当する TCP ソケットが変換され、既存のソケットには影響しません。

以下の図は変換プロセスを示しています。

1. 現在のネットワーク名前空間に対して透過的なソケット変換を有効化します：

   sudo sysctl net.smc.tcp2smc=1

   デフォルト値は 0（無効）です。

2. TCP ソケットアプリケーションを通常通り起動します：

   ./<foo>

   <foo> をご利用のアプリケーション名に置き換えます。アプリケーションの TCP ソケットは透過的に SMC ソケットに変換され、SMC-R スタックによって処理されます。「仕組み」でフォールバック動作についてご確認ください。

3. (任意) 現在のネットワーク名前空間について変換を無効化します。新しい TCP ソケットは TCP に戻りますが、既存の変換済み SMC ソケットには影響があります：

   sudo sysctl net.smc.tcp2smc=0

プロセスレベルのソケット変換の有効化

この方法では、smc_run コマンド（smc-tools ツールセットに含まれる）を用いて、単一のプロセスおよびその子プロセスに適用します。

以下の図は変換プロセスを示しています。

ご利用のアプリケーションの実行可能ファイルの先頭に smc_run を付加します：

smc_run ./<foo>

<foo> をご利用のプロセス名に置き換えます。このプロセスが作成する TCP ソケットは透過的に SMC ソケットに変換されます。「仕組み」でフォールバック動作についてご確認ください。

smc-ebpf のインストール

smc-ebpf は smc-tools に含まれています。インストール状況を確認するには、以下を実行します：

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

smc-ebpf のロード

sudo smc-ebpf policy load

正常にロードされた場合の出力例：

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

出力が異なる場合は、以下の手順でトラブルシューティングを行ってください：

• カーネルバージョンが ANCK 5.10.134-016 以降であることを確認します：uname -r

• BPF プログラムのロード権限があることを確認します。コンテナ環境では必要な機能が不足している可能性があります — 環境プロバイダーにお問い合わせください。

ポートポリシー

ポートポリシーは、接続のポートに基づいて SMC ネゴシエーションの使用可否を制御します。

デフォルト動作：smc-ebpf をロード後、マッチするポリシーがないポートは、SMC ネゴシエーションの使用が禁止されます。

マッチしないポートに対してデフォルトで SMC を許可するように変更するには：

# デフォルトを変更: 一致しないポートで SMC を有効化
sudo smc-ebpf policy config --port 0 --mode enable
# ポート 80 を無効化
sudo smc-ebpf policy config --port 80 --mode disable

デフォルトを再び禁止に戻すには：

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

例 1：ポート 80 のみを許可し、その他すべてをブロック

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

# Verify
sudo smc-ebpf policy dump

期待される出力：

# sudo smc-ebpf policy dump
[{
        "key": 80,
        "value": {
            "mode": 2,
            [Other fields that ordinary users do not need to pay attention to]
        }
    }
]

"key": 80 はポート番号を表します。"mode": 2 は SMC ネゴシエーションが許可されることを意味し、"mode": 0 は禁止を意味します。

ポリシーを削除するには：

sudo smc-ebpf policy delete --port 80

例 2：ポート 80 のみをブロックし、その他すべてを許可

# Change default: allow SMC for unmatched ports
sudo smc-ebpf policy config --port 0 --mode enable
# Block port 80
sudo smc-ebpf policy config --port 80 --mode disable

IPv4 アドレスポリシー

IPv4 アドレスポリシーは、クライアントソケットのみに適用されます。これは、クライアントが特定のサーバー IP アドレスへ接続する際に SMC ネゴシエーションを使用するかどうかを制御します。サーバーソケットの動作には影響しません。

すべてのポートポリシーおよび IPv4 アドレスポリシーは論理積（AND）で評価されます。すべてのマッチするポリシーが許可している場合にのみ、SMC ネゴシエーションが使用されます。

デフォルト動作：smc-ebpf をロード後、マッチするポリシーがないサーバー IP は、SMC ネゴシエーションが許可されます。

マッチしない IP に対してデフォルトで SMC をブロックするように変更するには：

# 一致しないIPをブロック
sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable
# 192.168.2.0/24 を許可
sudo smc-ebpf policy config --ip 192.168.2.0 --mask 24 --mode enable

# 確認
sudo smc-ebpf policy dump

デフォルトを再び許可に戻すには：

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

例 1：192.168.2.0/24 のみを許可し、その他の宛先をすべてブロック

# Block unmatched IPs
sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable
# Allow 192.168.2.0/24
sudo smc-ebpf policy config --ip 192.168.2.0 --mask 24 --mode enable

# Verify
sudo smc-ebpf policy dump

期待される出力：

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

"pass" は SMC の許可、"denied" は禁止を意味します。

これらのポリシーを削除するには：

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

例 2：192.168.2.0/24 のみをブロックし、その他の宛先をすべて許可

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

追加の構成は不要です。デフォルトでは、その他のすべてのサーバー IP に対して SMC が許可されます。

すべてのポリシーのクリア

sudo smc-ebpf policy clear

これにより、すべての構成済みポリシーが削除され、デフォルト状態が復元されます：すべてのポートに対して SMC ネゴシエーションは禁止（ポートのデフォルト：禁止）、すべての IPv4 アドレスに対しては許可（IP のデフォルト：許可）となります。ポートポリシーと IP ポリシーは論理積（AND）で評価されるため、すべての接続は最終的に SMC ネゴシエーションの使用が禁止されます。

sysfs パラメーター

EID の構成

Enterprise ID（EID）は SMCv2 プロトコルにおける概念です。同じ EID を共有するシステム同士のみが SMCv2 経由で通信可能であり、それ以外の場合は TCP へフォールバックします。1 つのシステムは最大 8 個の EID をサポートします。

Alibaba Cloud Linux 3 の eRDMA デバイスでは SMCv2 プロトコルが必須です。すべての Alibaba Cloud Linux 3 ノードには、EID SMCV2-DEFAULT-UEID が事前に搭載されているため、EID の手動構成を行わなくてもノード間で SMCv2 経由の通信が可能です。

EID の形式：最大 32 文字、大文字、数字、ハイフン（-）、ピリオド（.）のみ使用可能。先頭は文字または数字で始める必要があります。連続するピリオドは使用できません。

EID の表示、追加、削除を行うには：

# View existing EIDs
smcr ueid show

# Add an EID
sudo smcr ueid add <EID>

# Remove an EID
sudo smcr ueid del <EID>

# Fetch the zone ID from instance metadata and convert to uppercase
ZONE_ID=$(curl -s -m 1 100.100.100.200/latest/meta-data/zone-id | tr "[:lower:]" "[:upper:]")

# Add the zone ID as an EID
sudo smcr ueid add $ZONE_ID

# Remove the default EID
smcr ueid | grep SMCV2-DEFAULT-UEID > /dev/null && sudo smcr ueid del SMCV2-DEFAULT-UEID

sudo systemctl start aliyunsmc-ueid

sudo systemctl enable aliyunsmc-ueid

PNET ID の構成

TCP トラフィックが SMC-R に変換される際、SMC-R スタックは、そのトラフィックを運ぶイーサネットインターフェイスに関連付けられた Elastic RDMA Interface (ERI) を通じてトラフィックをルーティングします。

この関連付けは、eRDMA がイーサネットインターフェイスに直接有効化されている場合に自動的に機能します。ERI が異なるイーサネットインターフェイスに関連付けられている場合は、物理ネットワーク識別子（PNET ID）を手動で使用して関連付けます。

例：ノードに eth0 および eth1 が存在します。eth0 で eRDMA が有効化されており、erdma_0 と関連付けられています。

• eth0 上の TCP トラフィック — SMC-R が自動的に erdma_0 を検出します。PNET ID は不要です。

• eth1 上の TCP トラフィック — SMC-R が ERI を検出できず、TCP へフォールバックします。eth1 を erdma_0 と PNET ID を介して関連付けることで、eth1 トラフィックの RDMA を有効化できます。

PNET ID の形式：最大 16 文字、大文字および数字のみ、スペース不可。

イーサネットインターフェイスと ERI を PNET ID で関連付けるには：

sudo smc_pnet

構成済みの PNET ID を表示するには：

sudo smc_pnet

出力例：

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

PNET ID 00163E0CD751 は erdma_0 と eth1 を関連付けます。eth1 経由の TCP トラフィックは、SMC-R が有効化されている場合に erdma_0 を通じて高速化されます。

eRDMA のイーサネットインターフェイスへのチェックおよび有効化に関するリファレンス：

• ERI の表示

• ERI の作成

• 既存 ENI の ERI ステータスの変更

PNET ID を使用したホスト ERI 共有 Pod の構成

複数の Pod が 1 つ以上のホスト ERI を共有するセルフマネージドコンテナ環境では、Pod の仮想イーサネットインターフェイス（vEth）およびホスト ERI の両方に同じ PNET ID を割り当てます。これにより、カーネルがホスト ERI を検出し、RDMA を使用して Pod トラフィックを高速化できます。

# Assign the PNET ID to the vEth in the pod's net namespace
sudo ip netns exec <pod netns> smc_pnet -a <PNET ID> -I eth0

# Assign the same PNET ID to the host ERI
sudo smc_pnet -a <PNET ID> -D erdma_0