クラスター機能運用¶
注意
クラスター機能を利用する場合は事前にサポートまでご連絡ください
警告
クラスター機能は 実験的機能 のため、正式版では仕様が変更される可能性があります
不明点がある場合はサポートまでお問い合わせください。
クラスターのノード数¶
最低ノード数¶
Sora は最低 3 ノードのクラスターを構築してください。
1 ノードで構築されたクラスターはクラスターを構築していないのと同様です
2 ノードで構築されたクラスターは片方のノードが停止すると、正常なノードも過半数の条件を満たさなくなるため接続を受け付けなくなってしまいます
ノード数¶
3 ノードの次は 5 ノードのクラスターを構築してください。 4 ノードは 2 ノードがダウンした時点でクラスターが利用できなくなるため、3 ノードと可用性が変わらないためです。
5 ノード以上は、特に制限はありません。
最大ノード数¶
クラスターを構築するノードの最大数は 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 クラスターリレー機能利用時のノード間通信では、大量のネットワーク帯域を消費します。 ノード間通信には 可能な限り プライベートネットワークを利用してください。
ノード間通信の暗号化¶
Sora のノード間通信は 暗号化されておりません 。 そのため、安全なプライベートネットワークの利用を推奨します。
もし、マルチクラウドなどでノード間通信がパブリックネットワークを利用したクラスターを構築する場合は、 ノード間の通信を暗号化する必要があります。その場合は Tailscale などの利用をお勧めします。
Tailscale · Best VPN Service for Secure Networks
参考までに、下記は弊社の Tailscale 利用事例です。
ベアメタルサーバーを利用したクラウドサービスで発生する課題を Tailscale で解決する · Tailscale
リレー機能利用時¶
リレー機能利用時にはノード間通信が大量に発生する場合があるため、暗号化に多くの CPU リソースを消費します。 そのため、プライベートネットワークを利用し、ノード間通信には暗号化を行わないことを推奨します。
クラスターからの一時的な離脱¶
モード切り替え API を利用し、 新規コネクションブロックモード または 新規セッションブロックモード に切り替えます。 その後、すべての接続がいなくなったタイミングでノードを終了してください。
一時的に離脱したノードは、再起動するとそのままクラスターに参加して動作します。
一時的に離脱したノードを含めるクラスターノード一覧¶
ListClusterNodes API では現在クラスターに参加しているノードの一覧が返ります。
注釈
結果に一時的に離脱したノードを含めない場合には、 include_all_known_nodes に false を指定して API を実行します。
クラスターからノード情報の完全消去¶
重要
恒久的にノードを破棄する場合には、必ず、この作業を行ってください。
特定のクラスターノードで障害が起きた後、復旧が難しい場合は PurgeClusterNode API を利用して、 クラスターに参加しているノードから、障害が起きたノードの情報を完全消去してください。
また、スケールインのためにノードを破棄する場合も同様に PurgeClusterNode API を 利用して、破棄したノードの情報を完全消去してください。
この作業はクラスターの新鮮さを保つために必要な作業となります。 この作業を行わないと存在していないノードが残り続けることで過半数かどうかの判断を誤る場合があります。
警告
PurgeClusterNode API はクラスターからノードを完全に消去するための API です。 近い将来に再び参加するノードに対しては基本的に使用しないでください。
クラスターのアップデート¶
注釈
ローリングアップデートを推奨しています。
アップデート対象のノードを ChangeMode API で 新規コネクションブロックモード または 新規セッションブロックモード に切り替えます
必要があれば ListChannels API と DisconnectChannel API を利用して既存接続を切断します
すべての接続がなくなったら Sora を停止させます
新しいバージョンの Sora へ入れ替えます
新しいバージョンの Sora を起動します
ListClusterNodes API で新しいバージョンの Sora がクラスターに参加できているかを確認します
警告
自動でクラスターに参加する処理がエラーになる可能性もあるため、 ListClusterNodes API で新しいバージョンの Sora がクラスターに参加できているかを必ず確認してください。 確認せずに他ノードのローリングアップデートを行った場合、クラスターに参加できていないままのノードが出てしまう 可能性があります。 さらに、複数のノードが参加できずに過半数を割ってしまうと、クラスターがまったく稼働しなくなる可能性もあります。
上の手順を 1 ノードごとに繰り返してください。
Sora のバージョンダウン¶
クラスターのアップデート の仕組みを使って、Sora のバージョンを下げることはできません。
そのため、クラスターのアップデート後に何らかの問題が発生し、 以前のバージョンに戻したい場合には、クラスターの再構築を行う必要があります。
再構築の際には、事前に全ノードを停止し、 data/ ディレクトリを削除した上で、
以前のバージョンの Sora を使用してクラスターの構築を行ってください。
クラスター破綻からの再構築手順¶
クラスターのうち、過半数のノードが停止した場合、クラスターのすべてのノードは接続を受け付けなくなります。 この状態からでも、停止したノードを再開させ、過半数のノードが正常に戻ったタイミングで、接続を受け付け始めます。 その場合は、ここで書かれている手順は必要ありません。
ただし、停止したノードがディスク障害などで data/ ディレクトリを失ってしまったときや、使っていた
IP アドレスが使えなくなってしまうなどの理由で、再開できないこともあります。
ここでは、3 ノードクラスターを組んでいたものの、うち 2 つのサーバーがディスク障害で
data/ ディレクトリを失った状態からの再構築手順を示します。
注釈
data/ ディレクトリを失ってしまうと、「未初期化」状態になるため、再度クラスターへの参加手順が必要です。
注釈
node_name に IP アドレスを使う場合、IP アドレスが変わると node_name も変える必要があります。
その際は 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 でクラスターにあらたに参加します
contact_node_name_list を利用している場合にはこの手順は必要ありません
警告
この手順では、 data/ ディレクトリの削除を含むため、対象のノードは「未初期化」状態になります。
複数のノードの名前変更が必要な場合には、1 ノードずつこの手順を実行することを推奨します。
1 ノードの変更のたびに、 ListClusterNodes を使ってクラスターに正しく
参加したことを確認して次のノードの手順に取り掛かってください。
ノード名を変更する場合の contact_node_name_list の扱い¶
ノード名の変更をするときに、クラスター自動参加を利用する方法を示します。 クラスター自動参加を使わずに RegisterClusterNode API を使う場合は この説明は関係しません。
関連する sora.conf の設定は contact_node_name_list です。 この設定は sora 起動時のときのみ利用されます。 また、一度クラスターに参加して初期化済みとなった場合には、正しいノードリストを知っているため、 この設定は無視されます。
以下、具体的に、3 ノードクラスターがあり、全ノードの IP アドレスが変わる状況を考えます。
状況:
現状のノード名:
sora1@192.0.2.101,sora2@192.0.2.102,sora3@192.0.2.103既にクラスターを組んでいる
それぞれを新規のノード名
sora1@198.51.100.1,sora2@198.51.100.2,sora3@198.51.100.3に変更するまず sora1 を入れ替える
それが成功した後に sora2 を入れ替える
それが成功した後に sora3 を入れ替えと進める
現状のノードでは、既にクラスターを組んでいるため concact_node_name_list は利用されません。
そのため、sora.conf の設定を変更する必要はありません。
新しいノードでは、起動時に contact_node_name_list が利用されます。 入れ替えは順番に実行する必要があるため、現状のノードのみが起動中である状態や 新規ノードのみの状態、または混在している状態がありえます。
最初に sora1 を入れ替える際には、残り2ノードは現状のノード
sora2@192.0.2.102,sora3@192.0.2.103です途中で sora2 を入れ替える際には、残り2ノードは現状のノード
sora3@192.0.2.103と新規sora1@198.51.100.1が混在しています最後に sora3 を入れ替える際には、残り2ノードは新規のノード
sora1@198.51.100.1,sora2@198.51.100.2です
このパターンに対して、ノード個別に contact_node_name_list を設定するのは複雑になってしまいます。
しかし、 contact_node_name_list に指定したノードのうち、起動していないノードは無視されますので、
既存ノードと新規ノードをすべて sora1@192.0.2.101, sora2@192.0.2.102, sora3@192.0.2.103
sora1@198.51.100.1, sora2@198.51.100.2, sora3@198.51.100.3 指定することで、全ノードの入れ替えに対応できます。
注釈
既存と新規の対応するノードが同時に起動することがないようにしてください。
たとえば、 sora1@198.51.100.1 を起動する前には、かならず sora1@192.0.2.101 を停止した上で、
sora1@192.0.2.101 が再び起動することがないようにしてください。
ロードバランサーの導入¶
注意
ロードバランサーを導入する場合は事前にサポートまでご連絡ください。
クラスター機能を利用した場合は、シグナリング URL に対してロードバランサーが利用できます。
ただし、ロードバランス自体は Sora が行うため、 ロードバランサーの導入はシグナリング URL の 1 本化が目的となります。
ロードバランサーは WebSocket に対応している必要があります
ロードバランサーで TLS 終端はせず TLS で Sora へ接続する必要があります
Sora はロードバランサー経由以外にクライアントと直接接続できる必要があります
これはリダイレクトが発生し、ロードバランサーを経由せずに接続する可能性があるためです
Sora の WebSocket 通信は 30 秒に 1 回通信を発生させるため、ロードバランサーのタイムアウトは 30 秒以上にする必要があります
もしシグナリング URL の 1 本化を検討している方で、不明点がある場合はサポートまでご連絡ください。
ログの出力¶
クラスターに関するログは log/cluster.jsonl に生成されます。
ログの詳細については ログファイル をご確認ください。
クラスター構成情報ファイル¶
危険
このファイルは Sora が内部で利用するためのファイルのため、指示がある場合以外は触らないでください。
Sora でクラスターを利用する場合、クラスター参加後のノード情報を永続化するためのファイルを
data/ ディレクトリ以下に生成します。
Sora のバージョンアップ時¶
Sora のバージョンアップ時に data/ ディレクトリをコピーする必要はありません。
このファイルが無い場合、 Sora の起動の際に生成されます。
クラスターからのノードの完全消去について¶
クラスターからノードを完全に消去させる場合は bin/sora stop で停止させた後に、
クラスターを構成してる実行中のノードのいずれかに対して、 消去するノードのノード名を target_node_name に指定して PurgeClusterNode API を実行します。
警告
PurgeClusterNode API はクラスターからノードを完全に消去するための API です。 再度参加するノードに対しては基本的に使用しないでください。
PurgeClusterNode API で完全消去したノードの再度の参加¶
警告
PurgeClusterNode API はクラスターからノードを完全に消去するための API です。 通常は、再度参加するノードに対しては使用しないでください。 ここの説明は、長期間に渡ってクラスターに参加できないため、苦肉の策として PurgeClusterNode API を使った場合の説明です。
警告
PurgeClusterNode APIでクラスターから消去したノードは、 以下に示す手順を経ずに再起動してはいけません。
クラスターからノードを完全消去した場合、そのまま再度参加をすることはできません。
再度クラスターに参加する場合は data/ ディレクトリを削除する必要があります。
PurgeClusterNode API を実行して、さらにそのノードの data/ ディレクトリを削除した場合、そのノードは
完全に新規のノードとして取り扱われます。
この状態になったノードは新規ノードですので、 RegisterClusterNode API をつかうか、
sora.conf の contact_node_name_list を利用してクラスターに参加できます。
クラスターから消去されたノードを別クラスターに参加させたい場合¶
あるクラスター A に参加していたノードを、A から削除して別のクラスター B に参加させたい状況を考えます。
警告
PurgeClusterNode API はクラスターからノードを完全に消去するための API です。 現在参加しているクラスターで再利用するノードに対しては使用しないでください。 Sora が稼働するサーバーを再利用して、別のクラスター B に参加する新規ノードが欲しい場合には、 Sora リリースの tar.gz を展開して、まっさらな状態からの新規ノード構築を推奨します。 ここの説明は、どうしても既存の tar.gz 展開ディレクトリを再利用したい場合の説明です。
PurgeClusterNode API で消去されたノードは以下の 2 点で以前参加していたクラスター A のノード群を覚えています。
sora.conf の contact_node_name_list
sora 起動ディレクトリ以下の
data/ディレクトリ内のデータ
そのため、再利用する場合には下記の手順で、クラスター A に関する情報を無くす必要があります。
contact_node_name_list は新しい別クラスター B のノードのリストに変更するか、または、リストを空にする
data/ディレクトリを削除する
警告
以上の手順を踏まずに別クラスター B に参加させようとすると、最悪の場合には A と B がひとつになった クラスターになってしまう場合があります。
上記の手順の後は Sora を起動し、クラスター参加の手順に従って、ノードをクラスターに参加させます。
ネットワーク障害やノード障害¶
Sora のクラスター機能はネットワーク障害やノード障害が発生した際に、 自動で新規接続の受け付けの停止とそこからの復旧を試みます。
発生しうる問題と新規接続の受け付け停止¶
ネットワーク障害等が発生した場合には、 Sora のノード間で通信ができず、クラスター内の情報の整合性が取れなくなる可能性があります。
たとえば、5 ノードのクラスターが 3 ノードからなるグループ A と 残りの 2 ノードからなるグループ B の 2 グループに分断されるということが起こりえます。 それぞれのグループ内では通信ができるものの、他グループへの通信ができないという状態です。
この状態ですべてのノードが接続を受け付けると、同じチャネル ID を指定していても、 あるクライアントはグループ A に繋がり、別のクライアントは グルーブ B につながる可能性があり、 それぞれのクライアント間で音声と映像が届かなくなります。
このような状況を防止するため、Sora は自分が半数以下のグループに属した場合に、新規接続の受け付けを停止します。 また、ノード数が半数以下のクラスターに参加しているノードは、接続中のすべての接続を切断し、その後は接続を受け入れません。
その後、クラスター自動復旧機能により、通信できるノードが過半数のグループとなった場合には、自動で新規接続の受け付けを再開します。
全ノードが半数以下のグループに所属した場合の挙動¶
ネットワーク障害等が発生したことで、いずれのグループも通信できるノードが半数以下になった場合、 どこグループでも新規接続はまったく受け付けられない状態になります。
この状態でも Sora は、永続化しておいたノード一覧を利用し自動でクラスターの復旧を試みます。 そして、クラスターが復旧して過半数のグループができた場合は新規接続が可能になります。