Azure Local（Azure Stack HCI）では「RDMAを有効にすると速くなる」と聞いても、どこがどう速くなるのかが掴みにくいことがあります。本記事では、RDMAとSMB 3.x（SMB Direct / SMBマルチチャネル）がAzure Local内で担う役割を、ミラーやパリティといった冗長化の裏側まで含めて具体的に整理します。
Azure Localの前提：S2Dは「ローカルディスクを束ねた分散ストレージ」
Azure Local は、複数ノードのWindowsベースのクラスター上で仮想マシン（VM）やコンテナを動かしつつ、同じクラスター内のローカルディスク（NVMe/SSD/HDD）をまとめて共有ストレージとして扱えるハイパーコンバージド（HCI）基盤です。共有ストレージの中核は Storage Spaces Direct（S2D） で、次の特徴があります。
- 外付けSANを前提にせず、各ノード内蔵ディスク をプールして1つのストレージとして利用する
- ボリュームはクラスター共有ボリューム（CSV）として提供され、VMのVHDXはその上に置かれる
- 冗長化（2重/3重ミラー、パリティ等）はソフトウェアで実現し、書き込み時に別ノードへ同期複製する
この「別ノードへ同期複製」こそが、Azure Local で SMB と RDMA が重要になる理由です。ノード間のストレージ通信（いわゆるeast-westトラフィック）が遅いと、冗長化の書き込み待ちが増え、結果としてVMのI/O性能が伸びません。逆に言えば、ストレージeast-westを最適化できると、同じディスク構成でも体感性能が大きく変わります。
| トラフィックの種類 | 主な中身 | よく使われる機能/技術 | 性能への影響 |
|---|---|---|---|
| 管理 | クラスター管理、監視、更新、Azure連携 | TCP/IP（通常のイーサネット） | 帯域より安定性が重要 |
| VM（北南） | VMのクライアント通信、アプリ通信 | vSwitch、VLAN、QoS | 用途により帯域が大きい |
| Live Migration 等 | VMのメモリ/状態の移動（イベント時） | SMB、圧縮、（環境によりSMB Direct） | 移行時だけ大きい |
| ストレージ（east-west） | ミラー/パリティの複製、修復、リバランス、CSV関連通信 | SMB 3.x / SMB Direct / SMBマルチチャネル / RDMA | 常に効く（最重要） |
RDMAの役割：Azure Localでは「ストレージ通信を速く・軽くする」
RDMA（Remote Direct Memory Access） は、ネットワーク越しに相手メモリへ直接アクセスできる仕組み…と説明されることが多い技術です。ただし、Azure Localを理解するうえで押さえるべきポイントは次の1点に集約されます。
RDMAは“VMのメモリを常に同期する仕組み”ではなく、SMB通信を高速化するための土台として使われる、ということです。
RDMAがやらないこと：VMメモリを“同期し続ける”仕組みではない
RDMAという名前から「VMのメモリページをノード間で直接やり取りしているのでは？」と想像しがちですが、Azure Localの通常運用で VMの実行中メモリが常時別ノードへ同期される ような挙動はありません。VMのメモリを別ノードに複製しておき、障害時に即座に同じVMが無停止で継続する、というタイプの仕組み（分散共有メモリのようなもの）とは別物です。
一方で、Hyper-VのLive Migration のように「VMのメモリ内容を別ホストへコピーするイベント」は存在します。このとき転送経路としてSMBを使う構成では、結果的にSMB Direct（＝SMB over RDMA）が効いて転送が速くなることはあります。ただしこれは“移動のための転送”であり、“実行中メモリを同期し続ける”ものではない、という整理が重要です。
RDMAが主戦場になる場所：SMB Direct（SMB over RDMA）
Azure LocalでRDMAが最も価値を発揮するのは、S2Dのノード間ストレージ通信です。S2Dはノード間通信にSMB 3.x を使い、RDMA対応NICがあればSMB DirectとしてRDMAを利用します。
- レイテンシが下がる：同期複製の待ち時間が短くなり、書き込みが伸びやすい
- スループットが上がる：高速なNVMe/SSDの性能をネットワークが足を引っ張りにくい
- CPU負荷が下がる：ネットワーク処理が軽くなり、VMにCPUを回しやすい
RDMAが使えない（または無効）でもS2D自体は動きますが、その場合はSMBがTCPで動作するため、負荷が高いワークロードほどCPUボトルネックやレイテンシ増として影響が見えやすくなります。
| 項目 | 通常のSMB（TCP） | SMB Direct（RDMA） |
|---|---|---|
| データ転送経路 | OSのネットワークスタック経由 | ネットワークスタックを大きくバイパス |
| CPU使用率 | 高くなりやすい（特に大容量I/O） | 低く抑えやすい |
| 遅延 | 相対的に大きい | 小さくしやすい |
| Azure Localでの影響 | ストレージ複製や修復が重くなりやすい | ストレージ複製や修復が軽くなりやすい |
SMB 3.xの役割：Azure Localでは「ファイル共有」より広い
SMB（Server Message Block） は一般に「Windowsのファイル共有プロトコル」という理解で概ね正しいです。ただしAzure Localでは、SMBが担う領域がもう少し広く、クラスター内部のストレージ通信を運ぶ“共通の輸送レイヤー”として使われています。
利用者がエクスプローラーで \\\\server\\share を開くような“ファイル共有”のイメージだけでSMBを捉えると、S2Dの挙動が理解しづらくなります。S2Dは「ノード間でデータを複製・分散する」という目的のために、SMB 3.xの機能（マルチチャネル、Direct、透過フェイルオーバー等）を積極的に活用します。
SMBの主要機能と、Azure Localで効くポイント
| SMB 3.xの機能 | 概要 | Azure Local / S2Dでの効き方 |
|---|---|---|
| SMB Direct | SMBをRDMAで転送 | ミラー/パリティの複製、修復、リバランスなどのeast-west通信を高速化 |
| SMB マルチチャネル | 複数NICを自動で並列利用（合算/冗長） | 帯域をまとめて性能を上げ、片系断でも自動継続（可用性） |
| 透過フェイルオーバー | セッションを保ったまま経路/ノード切替 | ノード障害や一時的な切替時の影響を小さくする方向で働く |
| SMB暗号化/署名 | 改ざん防止・盗聴対策 | 要件次第で有効。ただし性能影響を見て設計（内部専用ネットワークでは要否を整理） |
VMから見たSMB：ゲストOSは“SMB共有”を意識しない
ここも混乱しやすいポイントです。Azure LocalのVMは、一般的なファイルサーバーのように「SMB共有にVHDXを置いている」わけではありません。VMから見えるのは、Hyper-Vホスト上のCSV（NTFS/ReFS）であり、ディスクI/Oはローカルディスクに書いている感覚に近い動きになります。
しかし、その裏側ではS2Dがデータ配置と冗長化を管理しており、必要に応じて別ノードのディスクへデータを書きに行く／別ノードからデータを読み出す状況が発生します。ここで動くノード間通信がSMB 3.xで、RDMAが有効ならSMB Directとして加速されます。つまり、SMBは“ゲストOSが使う共有”ではなく、“ホスト間のストレージファブリック”という位置づけです。
ミラー/パリティの裏側：SMBは「冗長化のためのデータ複製」を運ぶ
Azure Localで「2重ミラー」「3重ミラー」「パリティ」といったレジリエンシーを設定すると、VMからの書き込みI/Oはローカルディスクだけで完結しません。耐障害性を満たすために、別ノード（または別障害ドメイン）へ同期的に複製され、必要なコピー数が揃ってから完了（ACK）になります。
書き込みI/Oのイメージ（2重ミラーの例）
- VMがVHDXへ書き込み（OSから見るとCSV上のファイル書き込み）
- 書き込みデータは、まずローカルノードのストレージスタックへ入る
- 同時に、ミラー要件を満たすために別ノードへ複製される（この複製の輸送にSMB 3.xが使われる）
- ローカルとリモートの両方で“書き込めた”ことが揃ったら完了として返る
つまり、ミラー構成ではネットワークがストレージの一部になります。ここでRDMA（SMB Direct）が効いてくると、同期複製の待ち時間やCPU負荷が減り、結果としてVMの体感I/Oが上がります。
レジリエンシー方式ごとの「ネットワークへの効き方」
| 方式 | 耐障害の考え方 | 書き込み時のコピー数 | east-west通信の特徴 | RDMA/SMB Directの重要度 |
|---|---|---|---|---|
| 2重ミラー | 1台（または1障害ドメイン）故障に耐える | 2コピー | 書き込みごとにリモートへ同期複製 | 高い |
| 3重ミラー | 2台故障に耐える（要件により） | 3コピー | 同期複製の“相手”が増えるため帯域・遅延の影響が出やすい | 非常に高い |
| パリティ | 冗長情報（パリティ）で復元 | データ＋パリティ | 書き込み計算と分散が絡み、ワークロードにより特性が大きく変わる | 高い（特に修復・リビルド時） |
ポイントは、冗長化が強いほど（コピーが増えるほど）ネットワークとCPUの負担が増えやすいことです。S2Dはソフトウェアで最適化しますが、物理的に「流すデータ量」と「待つ回数」は増えます。そのため、Azure Localではストレージ用ネットワークを“速く・安定させる”ことが、冗長化と性能を両立する近道になります。
キャッシュとRDMA/SMBの関係：キャッシュはローカル、複製はネットワーク
「RDMAはキャッシュと関係があるのか？」という疑問もよく出ます。結論から言うと、S2Dのキャッシュは基本的に各ノードのローカル資源（メモリや高速SSD/NVMe）を使って実装され、RDMAがキャッシュそのものを作るわけではありません。
ただし、キャッシュがあることでI/Oの流れ方が変わり、結果としてネットワークに流れるパターンも変化します。ここを整理すると理解しやすくなります。
| 用語 | ざっくり説明 | RDMA/SMBとの関係 |
|---|---|---|
| 書き込みキャッシュ（Write-back） | 一度高速層に受けてから容量層へ後で書く | 複製自体は必要。相手ノード側でも受けるため、SMB Directが効く |
| 読み取りキャッシュ（Read） | よく読むデータを高速層に保持 | ヒットすればネットワーク/ディスクI/Oが減る。ミス時のリモート読み取りでSMBが効く |
| デステージ（Destage） | キャッシュ→容量層へ書き出す処理 | 平常時にバックグラウンドで動く。帯域が細いと詰まりやすい |
要するに、キャッシュは“ノード内で速くする仕組み”、RDMA/SMB Directは“ノード間の複製を速くする仕組み”です。両者は別のレイヤーですが、組み合わさることで全体性能が出ます。
設計のポイント：RDMAをストレージ専用NICで使う理由
Azure Localのネットワーク設計では、RDMAを有効にするNIC（アダプター）をストレージ用として明確に位置づけるのが基本です。理由はシンプルで、ストレージeast-westは「常に・大量に・低遅延が必要」なため、他トラフィックの影響を受けると途端に性能がぶれるからです。
ストレージ用NICの典型構成
- 各ノードにRDMA対応NICを2ポート以上（冗長化と帯域確保）
- 10/25GbE以上を推奨（NVMe構成では25GbE以上が効きやすい）
- スイッチ構成は、要件に応じて「スイッチ接続」または「スイッチレス（直結）」
- RoCEの場合はPFC/ETS等の設計、iWARPの場合はスイッチ要件が比較的軽い
“推奨構成に寄せる”ためのチェックリスト
| チェック項目 | 目安 | 意図 |
|---|---|---|
| RDMA NICは2系統以上 | 各ノード2ポート以上 | SMBマルチチャネルで合算と冗長を両立 |
| ストレージ網の経路は短く | 同一ラック/同一ペアで完結 | 遅延と輻輳ポイントを減らす |
| MTUは揃える | ジャンボを使うなら全経路同一 | 途中で欠けると逆に遅くなるため |
| RoCEはQoS設計が必須 | PFC/ETS等を要件に合わせて | ドロップやポーズ嵐で不安定化しやすい |
| ドライバ/ファームを統一 | ベンダー推奨に揃える | “動くが遅い/不安定”の原因になりやすい |
| 設計項目 | 選択肢 | 考え方（現場目線） |
|---|---|---|
| RDMA方式 | RoCE / iWARP | RoCEは高性能だがスイッチ設定（PFC等）の影響が出やすい。iWARPは運用が楽なことが多いが製品選定が重要。 |
| NIC本数 | 2本以上 | SMBマルチチャネルで帯域を合算しつつ、片系断でも継続できる。1本構成は“動くが弱い”。 |
| ネットワーク分離 | 専用 / 収束（Converged） | 専用は分かりやすく安定。収束は設計力が必要だが配線削減。どちらでも“ストレージ優先”のQoS設計が鍵。 |
| チーミング/仮想スイッチ | SET / 非チーミング等 | RDMAと相性の悪い方式があるため、製品ガイドに従う。Windowsの推奨形（SETやNetwork ATC等）に寄せると事故が減る。 |
SMBマルチチャネルを理解すると設計が一段ラクになる
SMBマルチチャネルは、複数NICを自動的に並列利用する機能です。Azure Localでは「RDMA NICを2本用意しておけば、あとはSMBが賢く使ってくれる」状態を作りやすく、設計上のメリットが大きいです。
- 帯域の合算：2×25GbEなら理屈上は最大50GbE相当まで伸びる（実効は環境次第）
- パス冗長：片側NICやケーブル、スイッチ経路に障害が出ても通信を継続しやすい
- 自動フェイルオーバー：チャネルが落ちても別チャネルへ寄せるため、ストレージI/Oの断を避けやすい
この性質を踏まえると、Azure Localのネットワークは「帯域だけ」ではなく、“2経路以上あること”自体が性能と可用性に直結する、と理解できます。
運用で差が出る：RDMA/SMBの状態を確認するコマンド集
「RDMAを有効にしたつもりなのに、実際にSMB Directで動いているか分からない」というケースは珍しくありません。Azure Localの運用では、定期的に次の観点を確認できると安心です。
| 確認したいこと | 代表的なPowerShell | 見るポイント |
|---|---|---|
| NICがRDMA対応＆有効か | Get-NetAdapterRdma | 対象NICがEnabledになっているか |
| SMBが使うNIC一覧 | Get-SmbClientNetworkInterface | RDMA Capable、LinkSpeed、RSS等 |
| SMBマルチチャネル接続状況 | Get-SmbMultichannelConnection | 複数経路が張れているか、RDMAがTrueか |
| SMBセッションの実体 | Get-SmbConnection | どの相手に張っているか、Dialect（SMBバージョン） |
| クラスターのネットワーク役割 | Get-ClusterNetwork | どのネットワークがクラスター通信/CSVに使われる想定か |
実機での確認では、「RDMA有効」→「SMBがそのNICを認識」→「SMB Multichannelが複数経路を張る」→「RDMA=Trueで通信」の順に、段階的に追うと切り分けが早くなります。
よくあるトラブルと、切り分けの考え方
Azure LocalのRDMA/SMB周りは、性能が出たときのリターンが大きい反面、設計・ドライバ・スイッチ設定の影響を受けやすい領域でもあります。最後に、現場で遭遇しやすい“つまずきポイント”を整理します。
RDMAが有効にならない／SMB Directにならない
- ドライバ/ファームの不整合：OS標準ドライバではなくベンダー推奨に揃える
- NICが想定どおり割り当てられていない：管理用とストレージ用が混在していると確認が難しい
- RoCEのPFC/ETS設計：スイッチ側QoSが未設定だとドロップやポーズ嵐で性能が崩れることがある
- MTU不一致：ジャンボフレームを使うなら全経路で揃える（途中で欠けると逆効果）
帯域が伸びない／CPUが高い
- SMBマルチチャネルが片系しか使っていない：速度差が大きいNICが混ざる、RSS設定、アドレス設計などを見直す
- ストレージと他トラフィックが競合：Live Migrationやバックアップがストレージ網を食い尽くすと、平常時I/Oにも波及する
- 暗号化/署名の影響：セキュリティ要件は大切だが、内部専用網でどこまで必要かを整理し、必要なら性能検証を行う
“動くけど不安定”のときに疑うべきこと
- スイッチのバッファ/輻輳：RDMAは低遅延前提で、輻輳時に挙動が分かりにくい。ポート統計やQoSカウンタも見る
- 経路の非対称：片側だけ遅い/ドロップが多いと、マルチチャネル全体の体感が落ちる
- “最適化し過ぎ”：収束設計でVLAN/QoS/仮想スイッチを盛りすぎると原因切り分けが困難になる。まずは推奨構成に寄せる
まとめ：RDMAとSMBの役割分担を一言で言うと
Azure LocalにおけるRDMAとSMBの関係は、次の比喩で覚えると整理しやすいです。
- RDMA＝高速道路（低遅延・低CPUで運べる“道路”）
- SMB 3.x＝輸送ルールと車両（その道路を使ってデータを運ぶ“プロトコル”）
そして、Azure Local / S2Dで最も重要なのは「ミラー/パリティのためのノード間複製」を、SMB Direct＋SMBマルチチャネルで強くすることです。RDMAはVMメモリを共有するためではなく、分散ストレージを“ローカル並みに扱うための裏方”として効く──この視点を持つと、ネットワーク設計・トラブルシューティング・性能検証が一気に進めやすくなります。
コメント