クラスター機能運用¶

クラスター利用時のファイル操作に問題が発生した場合¶

クラスター機能を利用している際に、ファイル操作に問題が発生した場合、 そのノードは 新規コネクションブロックモード へ移行します。

ファイル操作とはログ出力だったり、録画ファイルアーカイブ出力だったりです。

この状態が発生した場合、 ディスク破損、ディスク容量不足、パーミッション間違いなど、 致命的な問題が発生している可能性が高いため、ノードを停止し、問題の解決を行ってください。

クラスターのレギュラーノード数¶

クラスターのテンポラリーノード数¶

テンポラリーノードはレギュラーノードと違いクラスターの維持に影響しないため、最低ノード数の制限はありません。

最大ノード数¶

クラスターを構築するノードの最大数は 100 ノードを想定しています。 これ以上のノード数を検討されている場合はサポートまでご連絡ください。

クラスター利用時のライセンス¶

クラスターの 1 ノードにつき 1 ライセンスが必要になります。 3 台のノードでクラスターを構築する場合は 3 ライセンスが必要になります。

ポートの開放¶

以下のポートを クラスターを組むその他のノードにのみ に対して開放してください。

• epmd（Erlang Port Mapper Daemon）で利用する TCP ポート
  • 4369
• ノード間通信に利用する TCP ポート
  • 49010 - 49020
  • sora.conf の cluster_listen_{min,max}_port にて範囲を指定できます

ノード間通信¶

Sora のノード間通信は TCP/IP を利用しています 。 そのため、安定したプライベートネットワークの利用を強く推奨します。

もし、マルチクラウドなどでノード間通信がパブリックネットワークを利用したクラスターを構築する場合は、 輻輳が発生する可能性があります。

そのため、特別な理由がない限りはプライベートネットワークを利用してください。

ノード間通信の暗号化¶

Sora のノード間通信は 暗号化されておりません 。 そのため、安全なプライベートネットワークの利用を推奨します。

もし、マルチクラウドなどでノード間通信がパブリックネットワークを利用したクラスターを構築する場合は、 ノード間の通信を暗号化する必要があります。その場合は Tailscale などの利用をお勧めします。

Tailscale · Best VPN Service for Secure Networks

参考までに、下記は弊社の Tailscale 利用事例です。

ベアメタルサーバーを利用したクラウドサービスで発生する課題を Tailscale で解決する · Tailscale

テンポラリーノード機能の利用¶

3 ノードや 5 ノードのレギュラーノードで構築したクラスターを拡張する場合は、 テンポラリーノード機能の利用を検討してください。

テンポラリーノードは、クラスター維持に影響しないノードで、気軽に追加・削除できるノードです。

特にリレー機能利用時には、スケールアウト/スケールインが気軽に行えるようになるため、 レギュラーノードとテンポラリーノードを組み合わせてクラスターを構築することを推奨します。

クラスターからの一時的な離脱¶

モード切り替え API を利用し、 新規セッションブロックモード または 新規コネクションブロックモード に切り替えます。 その後、すべての接続がいなくなったタイミングでノードを終了してください。

一時的に離脱したノードは、再起動するとそのままクラスターに参加して動作します。

一時的に離脱したノードを含めるクラスターノード一覧¶

ListClusterNodes API では現在クラスターに登録している全てのノードの一覧が返ります。

クラスターからレギュラーノード情報の完全消去¶

特定のレギュラーノードで障害が起きた後、復旧が難しい場合は PurgeClusterNode API を利用して、 クラスターに参加しているレギュラーノードから、障害が起きたレギュラーノードの情報を完全消去してください。

また、スケールインのためにレギュラーノードを破棄する場合も同様に PurgeClusterNode API を 利用して、破棄したレギュラーノードの情報を完全消去してください。

この作業はクラスターの新鮮さを保つために必要な作業となります。 この作業を行わないと存在していないレギュラーノードが残り続けることで過半数かどうかの判断を誤る場合があります。

クラスターのローリングアップデート¶

1. アップデート対象のノードを ChangeMode API で 新規セッションブロックモード または 新規コネクションブロックモード に切り替えます
   • 必要があれば ListChannels API と DisconnectChannel API を利用して既存接続を切断します
2. すべての接続がなくなったら Sora を停止させます
3. 新しいバージョンの Sora へ入れ替えます
4. 新しいバージョンの Sora を起動します
5. ListClusterNodes API で新しいバージョンの Sora がクラスターに参加できているかを確認します

上の手順を 1 ノードごとに繰り返してください。

クラスターのローリングアップデート中の挙動¶

Sora のバージョンダウン¶

クラスターのローリングアップデート の仕組みを使って、Sora のバージョンを下げることはできません。

そのため、クラスターのアップデート後に何らかの問題が発生し、 以前のバージョンに戻したい場合には、クラスターの再構築を行う必要があります。

再構築の際には、事前に全ノードを停止し、 data/ ディレクトリを削除した上で、 以前のバージョンの Sora を使用してクラスターの構築を行ってください。

Sora のローリングアップデート失敗¶

クラスターのローリングアップデート に失敗した場合は、クラスターの再構築が必要になります。

再構築の際には、事前に全ノードを停止し、 data/ ディレクトリを削除した上で、 新しいバージョンの Sora を使用してクラスターの再構築を行ってください。

クラスター破綻からの再構築手順¶

クラスターのうち、過半数のノードが停止した場合、クラスターのすべてのノードは接続を受け付けなくなります。 この状態からでも、停止したノードを再開させ、過半数のノードが正常に戻ったタイミングで、接続を受け付け始めます。 その場合は、ここで書かれている手順は必要ありません。

ただし、停止したノードがディスク障害などで data/ ディレクトリを失ってしまったときや、使っていた IP アドレスが使えなくなってしまうなどの理由で、再開できないこともあります。

ここでは、3 ノードクラスターを組んでいたものの、うち 2 つのサーバーがディスク障害で data/ ディレクトリを失った状態からの再構築手順を示します。

• まずすべての Sora プロセスを停止状態にします
• ディスク障害がおきたサーバーでは
  • Sora をインストールしなおします
  • 必要に応じて sora.conf 設定を行います
• ディスク障害がおきなかったサーバーでは
  • data/ ディレクトリを削除します
  • これを忘れると正しい再構築ができません、必ず削除してください
• ここまでで、完全にまっさらの Sora クラスターを構築する準備ができたことになります
• すべてのノードを起動します
• InitCluster API を発行し、クラスターを初期化します

以上の手順で、あたらしい 3 ノードのクラスターが動き始めます。

ノード名変更手順¶

sora.conf の node_name を変更する際の手順を示します。

この手順は、例えば Sora が動作するサーバーの IP アドレスが変わり、 node_name の IP アドレス部分を 変更する場合に必要になります。

• 対象のノードを停止します
• data/ ディレクトリを削除します
  • これを忘れるとノード名変更が正しく実行できません、必ず削除してください
• クラスターの起動しているノードのいずれかに対し、 PurgeClusterNode API を発行し、 対象のノードをクラスターから削除します
• sora.conf の node_name を変更します
• 対象のノードを起動します
• RegisterClusterNode API でクラスターにあらたに登録します

ロードバランサーの導入¶

クラスター機能を利用した場合は、シグナリング URL に対してロードバランサーが利用できます。

ただし、ロードバランス自体は Sora が行うため、 ロードバランサーの導入はシグナリング URL の 1 本化が目的となります。

• ロードバランサーは WebSocket に対応している必要があります
• ロードバランサーで TLS 終端はせず TLS で Sora へ接続する必要があります
• Sora はロードバランサー経由以外にクライアントと直接接続できる必要があります
  • これはリダイレクトが発生し、ロードバランサーを経由せずに接続する可能性があるためです
• Sora の WebSocket 通信は 30 秒に 1 回通信を発生させるため、ロードバランサーのタイムアウトは 30 秒以上にする必要があります

もしシグナリング URL の 1 本化を検討している方で、不明点がある場合はサポートまでご連絡ください。

ログの出力¶

クラスターに関するログは log/cluster.jsonl に生成されます。

ログの詳細については ログファイル をご確認ください。

クラスター構成情報ファイル¶

Sora でクラスターを利用する場合、クラスター参加後のノード情報を永続化するためのファイルを data/ ディレクトリ以下に生成します。

クラスターからのレギュラーノードの完全消去について¶

クラスターからレギュラーノードを完全に消去させる場合は bin/sora stop で停止させた後に、 クラスターを構成してる実行中のノードのいずれかに対して、 消去するノードのノード名を target_node_name に指定して PurgeClusterNode API を実行します。

PurgeClusterNode API で完全消去したレギュラーノードの再度の参加¶

クラスターからレギュラーノードを完全消去した場合、そのまま再度参加をすることはできません。 再度クラスターに参加する場合は data/ ディレクトリを削除する必要があります。

PurgeClusterNode API を実行して、さらにそのレギュラーノードの data/ ディレクトリを削除した場合、 そのレギュラーノードは完全に新規のレギュラーノードとして取り扱われます。

この状態になったレギュラーノードは新規レギュラーノードですので、 RegisterClusterNode API を利用してクラスターに登録できます。

クラスターから消去されたレギュラーノードを別クラスターに参加させたい場合¶

あるクラスター A に参加していたレギュラーノードを、A から削除して別のクラスター B に参加させたい状況を考えます。

PurgeClusterNode API で消去されたレギュラーノードは data/ ディレクトリ内のデータに以前参加していたクラスター A のノード群を覚えています。

そのため、再利用する場合には data/ ディレクトリを削除して、クラスター A に関する情報を無くす必要があります。

上記の手順の後は Sora を起動し、クラスター参加の手順に従って、レギュラーノードをクラスターに参加させます。

ネットワーク障害やノード障害¶

Sora のクラスター機能はネットワーク障害やノード障害が発生した際に、 自動で新規接続の受け付けの停止とそこからの復旧を試みます。