Galeraを使用して、回復力の高いNextcloudクラスターを構築する

まずデータベースクラスタを構築し、次にヘルスチェック済みのロードバランサーの背後に複数の同一のNextcloudアプリケーションノードを配置します。安定したセットアップを実現するには、すべてのアプリケーションノードが同じ永続ファイルストレージ、構成、RedisまたはValkeyロックサービス、および書き込みを正常なGaleraメンバーにのみルーティングするデータベースエンドポイントを使用する必要があります。Nextcloudの現在の管理マニュアルでは、MariaDBがサポートされているデータベースとして記載されていますが、Galera固有のデプロイメント手順は公開されていません。本番環境に移行する前に、Nextcloud、MariaDB、Galera、およびプロキシの正確なバージョンをベンダーに確認してください。

2026年10月9日現在、Nextcloud 35のシステム要件ページには、MariaDB 10.11、11.4、11.8、および12.3が記載されており、12.3が推奨バージョンとしてマークされています。これはNextcloudのデータベースバージョン一覧であり、すべてのGaleraまたはプロキシの組み合わせが認証されていることを保証するものではありません。まずはNextcloud 35のシステム要件と、ご使用のMariaDBディストリビューションのGaleraサポートマトリックスをご確認ください。

1. 故障境界を定義する

高可用性クラスタは、単にデータベースを複製するだけではありません。Galeraはデータベース層を保護するだけで、Nextcloudのユーザーファイル、PHPセッション、Redisロック、アプリケーションコードを複製するわけではありません。また、単一の共有データベースでは、ストレージのマウント失敗や、障害が発生したアプリケーションノードにトラフィックを送信し続けるロードバランサーの問題を補うことはできません。

インストール前に以下のコンポーネントを計画してください。

• 少なくとも2台のアプリケーションサーバーが、同じNextcloudリリース、PHPバージョン、有効化されているアプリケーション、およびWeb構成で動作していること。
• 安定した公開ホスト名、HTTPS、およびアプリケーションサーバーのヘルスチェック機能を備えたロードバランサーまたはリバースプロキシ。
• 同じパスでアクセスでき、すべてのアプリサーバーで適切な権限が付与された、共有型の耐久性のあるNextcloudデータストレージ。Nextcloudデータディレクトリはインストール時に設定する必要があります。インストール手順書には、後から移動するのは困難であるとの注意書きがあります。
• 投票データベースノードの数が奇数（通常は3つ）のGaleraクラスタは、1つのホストが故障しても過半数が失われないように配置される。
• 分散キャッシュとトランザクションファイルロックのための、共有型のRedisまたはValkeyサービス。

冗長性とテスト済みの復旧機能を備えたストレージおよびネットワーク設計を選択してください。複数のWebサーバーが共有パスをマウントできるからといって、必ずしも高可用性が確保されるわけではありません。

2. まずMariaDB Galeraをインストールして検証します。

Nextcloudの現在の要件を満たすMariaDBのリリースと、MariaDBベンダーがサポートする対応するGaleraパッケージを選択してください。ノード構成、ネットワークポート、状態スナップショット転送、TLS、および初期ブートストラップについては、 MariaDB Galeraのデプロイメントドキュメントを参照してください。すべての空のノードを新しいクラスタとして起動しないでください。まず1つのノードをブートストラップし、次に他のノードをそのクラスタに参加させてください。

Nextcloudでは、InnoDBとREAD-COMMITTEDMySQLまたはMariaDBのトランザクション分離レベルが必要です。また、Nextcloudのデータベースに関する最新ページでは、行ベースのバイナリログ記録を推奨しています。トラフィックを受信して​​いるノードだけでなく、すべてのデータベースノードでこれらの値を確認してください。NextcloudのMariaDB構成要件については、こちらをご覧ください。

Nextcloud を接続する前に、各ノードでクラスタの状態を確認してください。たとえば、SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';とを実行しますSHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';。クラスタはPrimary、コンポーネント、予想されるクラスタサイズ、およびSynced状態のノードを報告するはずです。MariaDB の説明によると、クォーラムにはクラスタの最後に認識されたメンバーシップの半数以上が必要です。したがって、3 ノードのクラスタは 1 つのノードの損失には耐えられますが、2 つのノードの損失には耐えられません。クォーラムと復旧に関するガイダンスを確認してください。

3. Nextcloudにヘルス状態を認識するデータベースエンドポイントを提供する

Nextcloud を、Galera IP アドレスのラウンドロビン リストではなく、安定したデータベース プロキシ アドレスに接続するように構成してください。Galera は書き込みをクラスタ全体に複製しますが、アプリケーションには予測可能なトランザクション処理が必要です。Galera メンバーシップを監視するプロキシは、利用できないノードや同期されていないノードへのルーティングを停止し、書き込みノードを選択できます。MariaDB MaxScale のGalera Monitorは、ドキュメント化されたオプションの 1 つです。その正確な動作とサポートされるルーティング モードは、MaxScale のバージョンと構成によって異なります。

Nextcloud の接続エンドポイントとして、プロキシのドキュメントに記載されている接続エンドポイントを使用しますdbhost。監視とアプリケーションアクセス用に、権限の最小化された別々のアカウントを作成し、認証情報を保護し、信頼できないネットワークを通過するデータベーストラフィックを暗号化します。パフォーマンス向上の近道として読み書き分割を有効にしないでください。Nextcloud 独自のレプリケーション機能は、読み取りをレプリカに送信し、書き込みと因果読み取りはデフォルトの接続に保持しますが、Galera は通常の非同期レプリカ構成ではありません。スタック専用にテストされたルーティング設計を使用します。

4. すべてのアプリノードが同じNextcloudインスタンスを参照するようにする

各アプリサーバーに同じNextcloudコードとアプリセットをインストールしてください。config.php共有インスタンスの各ノードの設定（データベースエンドポイント、シークレット値、信頼済みドメイン、データディレクトリパスなど）を統一してください。複数のノードで個別にアップグレードを実行しないでください。まずバックアップを作成し、インスタンスをメンテナンスモードにして、制御された単一の方法でアップグレードを行い、すべてのノードで同じバージョンが実行された後にのみトラフィックを再開してください。

すべてのアプリノードで、分散キャッシュとロックに同じ Redis または Valkey サービスを使用するように構成します。APCu などのローカルキャッシュはノードローカルのままにできますが、各サーバーの ではなく、共通のサービスを指す必要がありますmemcache.distributed。たとえば、Nextcloud の Redis 構成では、 と共有 Redis ホストを使用できます。現在のキャッシュ構成ガイドとトランザクションファイルロックガイドに従ってください。Memcached は Nextcloud のトランザクションファイルロックには適していません。memcache.lockinglocalhost'memcache.locking' => '\OC\Memcache\Redis'redis

PHPセッションもRedisで一元管理する場合は、PHPの設定を別途行う必要があります。Nextcloudのマニュアルには、Redisセッションハンドラではセッションロックがデフォルトでは有効になっていないと記載されています。ロック設定を適用し、セッションの動作をテストしてから使用してください。データベースのレプリケーションやファイルロックとセッションの継続性を混同しないように注意してください。

5. 高可用性と呼ぶ前にフェイルオーバーをテストする。

まず、公開ホスト名を使用して正常な動作を確認します。サインインし、テストファイルをアップロードおよびダウンロードして、リクエストが別のアプリケーションノードに到達した後もファイルが表示されることを確認します。次に、一方のWebノードをドレインし、リクエストがもう一方のノードを経由して継続されることを確認します。その後、ノードを復元し、古いコードや構成バージョンを提供することなく再接続できることを確認します。

次に、ベンダーの運用マニュアルに従って、メンテナンスウィンドウを使用してデータベースノードの障害をシミュレートします。プロキシが障害が発生した、または同期されていないメンバーを削除し、Nextcloudが引き続き読み書きでき、復帰したノードがSyncedトラフィックを受け入れる前に到達することを確認します。Galeraプライマリの状態、クラスタサイズ、ノードの同期、プロキシの状態、アプリのエラー、およびストレージのマウント状態を監視します。

クォーラムの喪失は安全停止であり、データが失われたことを証明するものではありません。複数のノードを強制的にブートストラップしたり、ランダムに1つを選択したりしないでください。MariaDBのリカバリガイドでは、最も高度なノードを特定し、そのノードのみをブートストラップしてから、他のノードを再接続するように指示しています。データベースとファイルストレージのバックアップもテスト済みであることを確認してください。Galeraのレプリケーションはデータベースの変更を反映するだけで、特定時点のバックアップを置き換えるものではありません。

結果を確認する

セットアップが本番環境に対応できるのは、通常のファイル操作を中断することなく、1 つのアプリケーション ノードと 1 つのデータベース ノードを取り外すことができ、すべての Galera ノードがプライマリ コンポーネントに残り、共有ファイル ストアと Redis または Valkey サービスにアクセスできる状態が維持されている場合のみです。テストが失敗した場合は、タイムアウトや再試行の設定を変更する前に、どの階層でリクエストの処理が停止したかを特定してください。Nextcloud のマニュアルには、サポートされているデータベースとアプリケーションの設定が記載されています。また、ベンダー互換性マトリックスとフェイルオーバー テストによって、この特定の Galera デプロイメントがサポートされているかどうかを判断できます。