Vaporネイティブクラスター
Vaporネイティブデプロイメントでは、VaporがOVNデータベース自体を実行します。単一のcentralでも完全なデプロイメントとして機能しますが、3台以上のクラスターを構成することで、1台のホストが失われても動作を継続できます。
このページでは、クラスターの形成とホストの追加について説明します。アクティベーション自体については 仮想ネットワークのアクティベーション を参照してください。
必要なcentralの台数
OVNデータベースはRAFTプロトコルによってレプリケーションされ、書き込みを受け入れる前にメンバーの過半数（クォーラム）の合意が必要です。
| Central台数 | 許容可能な障害数 | 備考 |
|---|---|---|
| 1 | なし | 完全に機能するが、ホストが停止するとデプロイメント全体が停止 |
| 2 | なし | 1台より危険。 いずれかのホストが停止すると過半数を失う |
| 3 | 1台の障害 | 実用上最小のクラスター |
| 5 | 2台の障害 | より大規模なデプロイメント向け |
常に奇数のノード数を使用してください。単一centralのデプロイメントに2台目のcentralを追加すると、3台目を追加するまで可用性は向上するどころか悪化します。
ワークロードのみを実行するホストはcentralにする必要はありません。3台のcentralと20台のシャーシといった構成が一般的です。
クラスターの形成
1台のcentralのみがクラスターを開始（ブートストラップ）し、他のすべてのcentralはその最初のcentralに参加します。
最初のcentral
アクティベーションウィザードで Vapor-native、ロール Central、および Bootstrap a new cluster を選択し、適用（Apply）します。
完了後、OVNステータスカードにはそのホストがデータベースを保持していることが報告され、クラスターページには唯一のメンバーとして表示されます。
centralの追加
追加の各centralは、ジョイントークン（join token）を使用して既存のcentralに対して認証を行います。既存のcentralのOVNステータスカードにある Mint join token をクリックします。トークンは一度だけ表示されます（ダイジェストのみが保存されるため、後から再取得することはできません）。デフォルトでは1時間、1回のみ有効です。
追加するホスト上で、ウィザードを実行して Vapor-native、ロール Central、Join an existing cluster を選択し、以下を実行します：
- 既存のcentralのアドレスを入力（ポートを省略した場合は7770と見なされます）。
- トークンを貼り付け。
- Exchange token with central を押す。
Vaporがcentralに接続し、成功するとデータベースアドレスと参加先クラスターのアドレスが自動入力されます。これらを手動でコピーする必要はありません。
その後、事前チェックを経て適用（Apply）します。
トークンの交換がブラウザではなくホスト上で実行される理由
ブラウザは一方のVaporホストと通信しており、centralは別のホスト（通常は自己署名証明書を使用）に存在します。参加する側のホスト自体が直接通信を行うため、初期参加時に必要となる Skip TLS verification for this exchange オプションが提供されています。centralが参加ホストから信頼される証明書を提示できるようになったら、このオプションをオフにしてください。
シャーシの追加
シャーシはデータベースのアドレスのみを必要とし、RAFTクラスターのメンバーシップは必要ありません。直接アドレスを入力するか、同様にジョイントークンを使用して自動入力させることができます。
既存データベースの置き換え
クラスターを形成または参加すると、そのホストの既存のOVNデータベースファイルが置き換えられます。ホストにすでにデータベースが存在する場合、Allow this host's OVN databases to be replaced にチェックを入れるまでVaporは処理を拒否します。
スタンドアロンで実行されていたホストでは、この警告を重く受け止めてください。ノースバウンドデータベースには、すべてのスイッチ、ルーター、ACL、ロードバランサーなど、論理構成のすべてが含まれています。Vaporは既存ファイルを削除せず、/var/lib/ovn 内にタイムスタンプのサフィックスを付けて退避させますが、続行する前にバックアップを作成してください。
すでに正常なクラスターメンバーであるホストではこの操作は不要であり、再適用してもデータベースが破壊されることはありません。
クラスターのアドレス指定方法
クラスターが形成されると、Vaporは単一のアドレスではなく、すべての メンバーのアドレスを保存します：
tcp:10.0.0.1:6641,tcp:10.0.0.2:6641,tcp:10.0.0.3:6641これは意図的な設計です。OVSDBクライアントは現在のリーダーとしか通信しないため、単一のアドレスを保存していると、リーダーシップが別のメンバーに移行した瞬間に通信が切断されます（まさにクラスターが生き残るべき状況です）。すべてのメンバーをリストしておくことで、クライアント自身がリーダーを見つけ出すことができます。
メンバー上でアクティベーションを再適用するとリストが更新され、新しく追加されたホストが他のホストの構成にも反映されます。
クラスターの状態確認
クラスタービューでは各データベースが個別に報告され、ローカルサーバーのロール、現在のターム（任期）、および全メンバーシップが表示されます。正常な3ノードクラスターでは、両方のデータベースで3人のメンバーと1人のリーダーが表示されます。
リーダーシップがメンバー間を移動することは正常な動作です。ホストの再起動時や一時的な通信途絶後に発生しますが、デプロイメント全体の利用可能性は維持されます。
以下の2点は障害ではありません：
- 論理ポートを持たないホストでトンネルポートが0個であること。 OVNはトンネルをオンデマンドで構築します。
- メンバーが
followerと報告していること。 一度にリーダーになれるのは1台のメンバーのみです。
central間で許可すべきポート
| ポート | 目的 |
|---|---|
| 6641 | ノースバウンドデータベース、クライアント通信 |
| 6642 | サウスバウンドデータベース、クライアント通信（シャーシが接続） |
| 6643 | ノースバウンドクラスターレプリケーション |
| 6644 | サウスバウンドクラスターレプリケーション |
| 6081/UDP | シャーシ間のGeneveトンネル |
central間ではこれらすべてのポートを相互に開放する必要があります。シャーシは、centralへの6642ポートと他のシャーシへのGeneveポートが必要です。
再起動への対応
Vaporは、OVNサービスユニットが読み取る場所にクラスターパラメーターを書き込み、systemdにデータベースプロセスを管理させるため、centralホストは再起動後も人間の介入なしに自動復帰します。Vaporがそれらのユニットを有効化できない場合はログに警告が表示されます。その場合、データベースは実行されていても、再起動後に自動復帰しません。