透過的なプロセス間通信

透過的プロセス間通信（TIPC）は、 Linuxのプロセス間通信（IPC）サービスであり、クラスター全体での操作のために設計されています。^{[ 1 ]}これは、単一のカーネルでのみ動作するよく知られたUnixドメインソケットサービスとは対照的に、クラスタードメインソケット^{[ 2 ]}としても知られています。

特徴

TIPC のいくつかの機能:

サービスアドレス指定と追跡の例

• サービスアドレス指定 - ソケットではなくサービスをアドレス指定する
• サービス追跡 - サービスアドレスのソケットへのバインド/アンバインドをサブスクライブする
• クラスタ全体のIPCサービス - サービスの場所は送信者に対して透過的
• ユニキャスト、エニーキャスト、マルチキャストによるデータグラムメッセージング - 信頼性の低い配信
• コネクション指向メッセージング - 信頼性の高い配信
• グループメッセージング - 信頼性の高い配信によるデータグラムメッセージング
• クラスタトポロジの追跡 - 追加/失われたクラスタノードをサブスクライブ
• 接続性追跡 - ノード間の個々のリンクのアップ/ダウンをサブスクライブ
• 新しいクラスタノードの自動検出
• 2 番目に速い障害検出機能により最大 1000 ノードまで拡張可能
• kernel.org のツリー内カーネルモジュールとして実装

実装

^{TIPCプロトコルは、}主流のLinuxカーネル[ ^{3 ]}のモジュールとして利用可能であり、したがってほとんどのLinuxディストリビューションで利用可能です。TIPCプロジェクトは、Wind RiverのVxWorksやSun MicrosystemsのSolarisなど、他のオペレーティングシステム向けにもプロトコルのオープンソース実装を提供しています。TIPCアプリケーションは通常、C（またはC++）で記述され、AF_TIPCアドレスファミリのソケットを利用します。Go 、D、Perl、Python、Rubyのサポートも利用可能です。

サービスアドレス指定

TIPC アプリケーションでは、3 種類のアドレスを使用できます。

• サービスアドレス。このアドレスタイプは、32ビットのサービスタイプ識別子と32ビットのサービスインスタンス識別子で構成されます。タイプ識別子は通常、ユーザーアプリケーションプログラマによって決定され、ハードコードされますが、その値は、同じクラスタ内に存在する可能性のある他のアプリケーションと調整する必要がある場合もあります。インスタンス識別子は、多くの場合、アプリケーション固有の基準に基づいてプログラムによって計算されます。

TIPC サービス アドレス指定

• サービス範囲。このアドレス型は、同じ種類のサービスアドレスの範囲を表し、そのインスタンス数は下限値と上限値の範囲内にあります。ソケットをこのアドレス型にバインドすることで、複数のインスタンスを表すことができ、多くの場合に有用であることが証明されています。
• ソケットアドレス。このアドレスは、クラスター内の特定のソケットへの参照です。32ビットのポート番号と32ビットのノード番号が含まれます。ポート番号はソケット作成時にシステムによって生成され、ノード番号は設定によって設定されるか、Linux 4.17以降では対応するノードIDから生成されます。このタイプのアドレスは、サービスアドレスと同様に接続やメッセージの送信に使用できますが、参照先のソケットが存在する場合にのみ有効です。

ソケットは複数の異なるサービスアドレスまたは範囲にバインドできます。同様に、異なるソケットを同じサービスアドレスまたは範囲にバインドすることもできます。バインドは可視性スコープ（ノードローカルまたはクラスターグローバルの可視性）によっても修飾されます。

データグラムメッセージング

データグラムメッセージは、1～66,000バイトの長さの個別のデータ単位であり、非接続ソケット間で送信されます。UDPデータグラムと同様に、 TIPCデータグラムは宛先への到達が保証されませんが、それでもUDPデータグラムよりも到達確率ははるかに高くなります。リンク層による配信保証のため、データグラムの配信を制限する要因はソケットの受信バッファサイズのみです。送信側がソケットに適切な配信重要度を設定することで、成功確率を高めることもできます。データグラムは3つの異なる方法で送信できます。

• ユニキャスト。ソケットアドレスが指定されている場合、メッセージはそのソケットに送信されます。TIPCでは、「ユニキャスト」という用語は 、このアドレッシングモードを表すために予約されています。
• エニーキャスト。サービスアドレスを使用する場合、一致する宛先が複数存在する可能性があり、転送方法はエニーキャストと呼ばれるもの、つまり一致する宛先のいずれかが選択される可能性があります。サービスアドレスからソケットアドレスに変換する内部関数は、宛先間の負荷偏りのリスクを軽減するためにラウンドロビンアルゴリズムを使用します。
• マルチキャスト。サービス範囲アドレスタイプは、マルチキャストアドレスとしても機能します。アプリケーションが宛先アドレスとしてサービス範囲を指定すると、メッセージのコピーがクラスター内の一致するすべてのソケットに送信されます。指定されたマルチキャスト範囲内の一致するサービスインスタンスにバインドされたソケットは、メッセージのコピーを1つ受信します。TIPCマルチキャストは、可能な限りUDPマルチキャストまたはイーサネットブロードキャストを利用します。

コネクション指向メッセージング

接続はTCPと同様に、SOCK_STREAMaccept()ソケットとをconnect()介して確立できます。ただし、TIPCでは、クライアントとサーバーはポート番号とIPアドレスの代わりに、サービスアドレスまたはサービスアドレス範囲を使用します。TIPCは、この標準的な設定シナリオに加えて、2つの代替方法も提供しています。

• ソケットは SOCK_SEQPACKET として作成できます。これは、データ交換が最大 66,000 バイトのメッセージ単位で行われる必要があることを意味します。
• クライアントは、受け入れ側のソケットにデータメッセージを送信するだけで接続を初期化できます。同様に、生成されたサーバーソケットは、クライアントにデータメッセージを返して接続を完了できます。このように、TIPCは暗黙的な（ 0-RTTとも呼ばれる）接続確立メカニズムを提供し、多くの場合、特に時間を節約します。

TIPC 接続の最も際立った特性は、アクティブなネイバー ハートビートに頼ることなく、ピア ソケットとの接続が失われた場合に迅速に対応できることです。

• ユーザーまたはプロセスのクラッシュによりソケットが不当に閉じられた場合、カーネル ソケット クリーンアップ コードは独自のイニシアチブでピアに FIN/ERROR メッセージを発行します。
• クラスタノードへの接続が失われると、ローカルリンク層は、そのノードに接続しているすべてのソケットにFIN/ERRORメッセージを発行します。ピアノードの障害検出時間は50ミリ秒まで設定可能で、デフォルト値は1,500ミリ秒です。

グループメッセージ

グループメッセージングは​​、前述のようにデータグラムメッセージングに似ていますが、エンドツーエンドのフロー制御を備えており、配信が保証されます。ただし、いくつか顕著な違いもあります。

• メッセージングは​​、メンバー ソケットの閉じたグループ内でのみ実行できます。

  

  通信グループ内の伝送モード

• ソケットはサービスアドレスを使用してグループに参加します。サービスアドレスのtypeフィールドはグループのIDを示し、instanceフィールドはメンバーのIDを示します。したがって、メンバーは1つのサービスアドレスにのみバインドできます。
• エニーキャストメッセージを送信する場合、検索アルゴリズムは通常のラウンドロビン アルゴリズムを適用しますが、選択する前に潜在的な受信者の現在の負荷 (つまり、アドバタイズされた送信ウィンドウ) も考慮します。
• マルチキャストは範囲ではなくサービス アドレスによって実行されるため、送信されたメッセージのコピーは、まさにそのアドレスでグループに参加しているすべてのメンバーに届きます。
• メンバーの ID を考慮せずに、グループ メンバー全員にメッセージを送信するグループブロードキャストモードがあります。
• 送信モード間でもメッセージの順序性が保証されます。

グループに参加する際、メンバーはグループの他のメンバーの参加イベントまたは離脱イベントを受信するかどうかを指定できます。この機能はサービストラッキング機能を活用し、グループメンバーはメンバーソケットでイベントを受信します。

サービス追跡

アプリケーションは、予約済みのサービスアドレスを使用してTIPC内部トポロジサーバーへの接続を開くことで、追跡サービスにアクセスします。その後、追跡サービスに1つ以上のサービスサブスクリプションメッセージを送信し、追跡対象のサービスアドレスまたは範囲を指定します。これに対し、トポロジサービスは、一致するアドレスがクラスター内のソケットによってバインドまたはアンバインドされるたびに、サービスイベントメッセージをアプリケーションに送信します。サービスイベントには、見つかった一致するサービス範囲と、バインド/アンバインドされたソケットのポート番号とノード番号が含まれます。サービス追跡には、以下の2つの特殊なケースがあります。

• クラスタトポロジの追跡。TIPCは他のノードとの接続を確立すると、予約済みのサービスタイプを使用して、サービスバインディングテーブルにノードローカルバインディングを内部的に作成します。これにより、ノード上のアプリケーションは、到達可能なピアノードをいつでも追跡できます。
• クラスタ接続の追跡。TIPCは、別のノードへの新しいリンクを確立する際に、予約済みのサービスタイプを使用して、ノードのバインディングテーブルにノードローカルバインディングを内部的に作成します。これにより、ノード上のアプリケーションは、ピアノードへのすべての動作中のリンクをいつでも追跡できます。

ほとんどのサービスサブスクリプションはノードのローカルトポロジサーバーに向けられていますが、他のノードのサーバーへの接続を確立し、それらのローカルバインディングを監視することも可能です。これは、例えば、接続サブスクライバーが、ローカルノードから見える範囲だけでなく、クラスター全体のすべての接続のマトリックスを作成したい場合に役立ちます。

クラスタ

TIPC ネットワークは、個々の処理要素またはノードで構成されます。ノードは、物理プロセッサ、仮想マシン、または Docker コンテナの形式などのネットワーク名前空間のいずれかになります。これらのノードは、割り当てられたクラスター IDに従ってクラスターに配置されます。同じクラスター ID を持つすべてのノードは、ネットワークがそれらの間で相互近隣探索を許可するようにセットアップされている場合、互いにリンクを確立します。異なるクラスター内のノードが互いを発見する可能性がある場合にのみ、クラスター ID をデフォルト値から変更する必要があります (たとえば、ノードが同じサブネットに接続されている場合)。異なるクラスター内のノードは、TIPC を使用して相互に通信することはできません。

物理的には相互接続されているが、論理的には分離された 2 つの TIPC クラスター。

Linux 4.17より前のバージョンでは、ノードには一意の32ビットノード番号またはアドレスを設定する必要があり、一定の制限を満たす必要がありました。Linux 4.17以降では、各ノードは128ビットのノードIDを持ち、これはノードのクラスター内で一意である必要があります。ノード番号は、このIDから一意であることが保証されたハッシュとして計算されます。

ノードがクラスタに参加する場合、ユーザーはノードの自動設定機能（最初のインターフェースが接続された際にIDが生成される）を利用するか、ノードのホスト名やUUIDなどからIDを明示的に設定することができます。ノードがクラスタに参加しない場合は、そのIDはデフォルト値の0のままにしておくことができます。

近隣探索は、UDPマルチキャストまたはL2ブロードキャスト（利用可能な場合）によって実行されます。インフラストラクチャにブロードキャスト/マルチキャストのサポートがない場合は、明示的に設定されたIPアドレスによって探索を実行できます。

ノード間リンク

クラスターは、1つまたは2つのリンクで相互接続されたノードで構成されます。リンクは信頼性の高いパケットトランスポートサービスを構成し、「L2.5」データリンク層と呼ばれることもあります。

• すべてのパケットの配信と順序性を保証します。
• ノード間接続のトランクとして機能し、それらを追跡します。

  

  ノードは1つまたは2つのリンクで相互接続されています

  • ピア ノードへのすべての接続が失われると、そのピアに接続されているソケットに通知が送られ、接続を切断できるようになります。
• 各エンドポイントは、サービス バインディング テーブルのローカル レプリカ内のピア ノードのアドレス バインディングを追跡します。
  • ピア ノードへの接続が失われると、そのピアからのすべてのバインディングが消去され、一致するすべてのサブスクライバーにサービス トラッキング イベントが発行されます。
• 定期的なデータ パケット トラフィックがない場合、各リンクはプローブ/ハートビートによってアクティブに監視されます。
  • 障害検出許容値は 50 ミリ秒から 30 秒まで設定可能で、デフォルト設定は 1.5 秒です。
• パフォーマンスと冗長性の理由から、別々のネットワーク インターフェイス上で、ノード ペアごとに 2 つのリンクを確立することが可能です。
  • リンク ペアは、負荷分散またはアクティブ/スタンバイ用に設定できます。
  • リンクに障害が発生した場合、残りのリンクがあれば、そのリンクに障害なくフェイルオーバーが行われます。

クラスターのスケーラビリティ

Linux 4.7以降、TIPCには特許出願中の独自の自動適応型階層型ネイバー監視アルゴリズムが搭載されています。このオーバーラッピングリング監視アルゴリズムは、実際にはリング監視とゴシッププロトコルを組み合わせたもので、最大1000ノードのフルメッシュクラスタを1.5秒の障害検出時間で構築することを可能にします。また、小規模なクラスタでは、さらに短時間で障害検出が可能です。

交通メディア

あらゆる種類のトランスポートメディアを利用できるように設計されていますが、2018年5月現在、実装ではUDP、イーサネット、InfiniBandをサポートしています。VxWorks実装は共有メモリもサポートしており、同一ハードウェア上で同時に実行される複数のオペレーティングシステムインスタンスからアクセスできます。

安全

現在、セキュリティはTIPCを伝送するトランスポートメディアによって提供される必要があります。UDP上で動作する場合はIPSecを使用できますが、イーサネット上で動作する場合はMACSecが最適です。TIPCチームは現在、TLSまたはDTLSをネイティブに、またはOpenSSLへの追加によってサポートする方法を検討しています。

歴史

このプロトコルは、1996年から2005年にかけてEricssonのJon Paul Maloy氏によって開発され、同社では数年間クラスタアプリケーションで使用されていました。その後、オープンソースコミュニティに公開され、主流のLinuxカーネルに統合されました。その後、様々な企業から参加した専任のTIPCプロジェクトチームによって、数々の改良とアップグレードが行われてきました。TIPCの管理ツールは、すべてのLinuxディストリビューションに標準で付属するiproute2ツールパッケージの一部です。

参考文献

1. 「TIPCの紹介」 . tipc.io. 2025年6月22日閲覧。
2. 「第50章 TIPCを使い始める」 . RedHatドキュメント. 2025年7月18日閲覧。
3. 「LinuxリポジトリのTIPC」 . Github . 2025年6月22日閲覧。

外部リンク

• アイプロート2
• IProute2ウェブサイト
• TIPCホームページ
• SourceForgeのTIPCプロジェクトページ
• SourceForge でのデモとユーティリティのダウンロード