ドメイン上でカスタムマトリックスルームエイリアスを設定する方法
Matrixルームエイリアスの仕組み、ドメインとSynapseホームサーバーの準備、フェデレーション委任の設定、カスタムエイリアスの作成、そして安全な検証方法について学びましょう。
Galera DB を使用した Nextcloud 高可用性クラスタのセットアップ方法
Galera を使用した Nextcloud の高可用性デプロイメントは、単に 3 台のデータベース サーバーを用意するだけではなく、連携したシステムです。冗長な Nextcloud アプリケーション ノード、共有可能で耐久性のあるファイル データ レイヤー、分散キャッシュとファイル ロック、ロード バランシング、監視、およびテスト済みのバックアップも必要です。Galera は、クォーラムが維持されている場合、データベース ノードの障害発生後もデータベース サービスを継続して利用できますが、他のコンポーネントの高可用性を確保することはできません。
このガイドでは、MariaDB Galeraとリバースプロキシまたはロードバランサーを使用した、ベンダーニュートラルなLinux設計を採用しています。パッケージ名、サービス名、Galeraプロバイダパス、ブートストラップコマンド、プロキシヘルスチェックの統合は、ディストリビューションとMariaDBのリリースによって異なります。デプロイ前に、正確なリリースドキュメントと照らし合わせて確認してください。Nextcloudの現在の安定版管理マニュアルでは、PostgreSQLとMariaDBが推奨データベースエンジンとして挙げられており、サポートされているバージョンは異なると警告しています。実行予定のリリースのNextcloudシステム要件を確認してください。この記事は、2026年10月6日にNextcloud 35安定版マニュアルに基づいて検証されました。
まず、適切な可用性設計を選択してください。
Galeraは、MySQL互換サーバー向けの同期型マルチプライマリレプリケーションです。トランザクションはクラスタ全体で認証されるため、メンバー間の整合性が保たれますが、調整オーバーヘッドが発生し、競合するトランザクションは拒否される可能性があります。データベースノードを追加しても、Nextcloudのスループットが自動的に向上するわけではありません。Nextcloudの開発者向けガイダンスでは、クラスタにはパフォーマンスコストがかかり、データベースとストレージは重要な共有リソースであると指摘しています。
| デザインの選択 | ぴったりフィット | 主なトレードオフ |
|---|---|---|
| MariaDBまたはPostgreSQLサーバー1台 | 最もシンプルな操作で済む小規模な展開 | データベースのメンテナンスや障害によりサービスが中断される可能性があります |
| MariaDBとGalera | データベースノードの冗長性が必要で、クォーラム、ネットワーク、プロキシ、および復旧手順を運用できるチーム | 可動部品の増加、書き込み調整、競合処理、および復旧の複雑さ |
| 2つのデータベースノードと仲裁者 | データベースホストがちょうど2つあるが、クォーラム投票用の障害ドメインが別々になっているサイト | 仲裁人は定足数を確保するのに役立ち、データを保存したり、3つ目のデータベースコピーを置き換えたりはしません。 |
| データベース対応プロキシの背後にあるGalera | 安定した接続エンドポイントと制御されたルーティングを必要とするデプロイメント | プロキシの健全性チェックとルーティングルールは、運用すべき別のサービスとなる。 |
新規インストールの場合、運用チームが対応可能な場合は、独立したホストにまたがる3つのデータノードからなるGaleraクラスタが一般的な出発点となります。Galeraのクォーラムには過半数が必要なため、2ノードクラスタでは1つのノードがダウンしても自動的にフェイルオーバーすることはできません。3ノード構成であれば、1つのノードがダウンしても、残りの2つのノードが接続を維持したまま運用できます。可能な限り障害ドメインをまたいでノードを配置してください。ただし、テストを行わずに高遅延リンクを介した同期レプリケーションは行わないでください。複雑性の低い環境では、サポート対象の単一データベースと、十分にテストされたバックアップおよびリカバリプランを使用することをお勧めします。
インストール前に、「高可用性」の意味を決めましょう。
障害発生時に対応可能な障害（Webプロセス、Webホスト、データベースホスト、ロードバランサー、ストレージエンドポイント、ネットワークパス、またはサイト全体）を書き出してください。それぞれの障害について復旧目標を設定してください。3つのデータベースノードと1つのロードバランサーで構成された設計は、完全な冗長性を備えているとは言えません。また、ユーザーファイルが1つのWebサーバーのローカルディスクにのみ存在するアプリケーションクラスタも同様です。
すべてのアプリケーションノードで、一貫したNextcloudリリース、PHPランタイム、アプリセット、および構成を使用してください。互換性があり、選択したNextcloudリリースでサポートされているMariaDBとGaleraのバージョンを選択してください。Nextcloudのデータベース要件には、InnoDB、READ COMMITTEDトランザクション分離、バイナリログまたはROW形式の無効化が含まれます。現在の要件を確認せずに、別のバージョンからチューニング値をコピーしないでください。
クラスターを12段階でセットアップする
1. ホスト名、アドレス、およびサービスエンドポイントを予約する
各データベースメンバー、各Webノード、キャッシュサービス、共有ストレージ、およびパブリックWebエンドポイントごとに、プライベートDNS名または安定したアドレスを作成します。Nextcloud PHPノード用に、別途安定したデータベースエンドポイントを確保します。インフラストラクチャが許す限り、アプリケーション、レプリケーション、およびパブリックトラフィックは、適切に分離されたネットワークパス上に配置します。ノード名は一意である必要があり、すべてのクラスタメンバーはGaleraピアを一貫して解決する必要があります。
2. 互換性のあるデータベースとGaleraリリースをインストールします。
MariaDBサーバーとGaleraプロバイダは、ご使用のオペレーティングシステムに推奨されるベンダーリポジトリを使用してインストールしてください。すべてのメンバーで同じメジャーサーバーとプロバイダファミリーを使用してください。任意のコミュニティパッケージと、別途ダウンロードしたプロバイダライブラリを組み合わせないでください。インストールを進める前に、そのパッケージセットでサポートされているアップグレードパス、SST方式、サービスユニット、および構成インクルードディレクトリを確認してください。
3. Nextcloudのデータベース要件を適用する
サーバーをInnoDBを使用するように設定し、トランザクション分離レベルをREAD COMMITTEDに設定します。バイナリログが有効になっている場合は、ROWバイナリログを使用します。構成ファイルが含まれていると想定するのではなく、再起動後に有効な値を確認してください。これらの要件については、Nextcloudのデータベース構成ガイドとシステム要件に記載されています。
4. 3つのメンバーすべてでGaleraを統一的に設定する
ベンダーの構成リファレンスを使用して、クラスタ名、ピアアドレスのリスト、各ノードの一意の名前とアドレス、プロバイダライブラリ、および状態スナップショット転送（SST）方法を設定します。SSTは、参加ノードにデータベースの状態をプロビジョニングするプロセスです。一般的なMariaDBクラスタ構成には、次の種類のオプションが含まれます。
[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTED各サーバーでノード固有の値を変更してください。プロバイダーパスとサポートされるSSTメソッドは、インストールされているパッケージによって異なります。ご使用のリリースに対応したドキュメントに記載されているメソッドと認証情報を使用してください。SST認証情報、証明書、およびデータベースパスワードは機密情報として保護してください。空のクラスタアドレスを永続的な設定として使用しないでください。MariaDBのドキュメントによると、空のアドレスを使用すると、サーバーが既存のクラスタに再参加するのではなく、新しいクラスタを起動してしまう可能性があります。
5. 必要なピアのみにネットワークアクセスを制限する
Web 層がデータベース サービス エンドポイントにのみアクセスできるようにし、データベース メンバーが、選択したプロバイダと SST 方式で必要な Galera レプリケーション ポートと状態転送ポートで相互に通信できるようにしてください。一般的な Galera デプロイメントでは、グループ通信に TCP と、プロバイダの設定によっては UDP を使用します。関連するデフォルト値には、レプリケーション用の 4567、増分状態転送用の 4568、状態スナップショット転送用の 4444 が含まれることがよくあります。これらは、バージョンと構成に対して確認するためのチェック リストとして扱い、すべてのポートを広く開放する理由として扱わないでください。SQL ポートは非公開にして、パブリック アクセスを拒否してください。
6. 最初のノードをブートストラップし、他のノードと結合する
ディストリビューションの MariaDB パッケージに記載されているブートストラップ手順を使用して、クラスタを一度だけ初期化してください。最初のメンバーがプライマリ コンポーネントを形成することを確認したら、残りのメンバーを通常どおり起動してプライマリ コンポーネントに参加させ、IST または SST を介して状態を受信します。IST は、利用可能な場合に不足している書き込みセットを転送します。SST は、完全な状態転送を実行します。各ホストを個別にブートストラップしないでください。また、再起動をブートストラップ アクションとして扱わないでください。
データベースメンバーが参加した後、各メンバーに対してこのクエリを実行してください。
SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
'wsrep_connected','wsrep_local_state_comment');各ノードが接続され、準備完了状態であること、プライマリコンポーネントに属していること、想定されるクラスタサイズを報告していること、および同期状態に達していることを確認してください。MariaDB のGalera モニタリングガイドでは、これらの指標について説明しています。
7. 専用のNextcloudデータベースと最小権限アカウントを作成する
現在の Nextcloud インストール ガイドで要求されている文字セットと照合順序を使用してデータベースを作成します。アプリケーション ネットワークに制限された専用のデータベース ユーザーを作成し、Nextcloud のセットアップと通常の操作に必要な権限のみを付与します。ホスト間または信頼できないネットワーク セグメント間の接続には TLS を使用し、デプロイメントがサポートしている場合は証明書を検証します。root 認証情報を に配置しないでくださいconfig.php。
8. 同一のNextcloudアプリケーションノードをデプロイする
各ウェブノードに、同じNextcloudコードリリース、PHP拡張機能、有効化されたアプリ、およびサーバー構成をインストールしてください。ノードごとのファイルで異なるデータベースホストを設定するのではなく、共有データベースエンドポイントを1つ設定してください。すべてのノードで、同じインスタンスID、シークレット、ソルト、信頼済みドメインポリシー、およびその他のインスタンス全体の設定を使用する必要があります。構成は、管理された共有デプロイメントプロセスに保存するか、安全に配布して、更新内容が常に同一になるようにしてください。
ユーザーファイルデータ層は、アプリケーションノード間で共通である必要があります。Nextcloudのバージョンと運用要件に合った、サポートされている共有ファイルシステムまたはプライマリオブジェクトストレージ設計を使用してください。1つのWebホストにローカル専用のユーザーデータがあると、フェイルオーバーが機能しなくなります。別のホストにルーティングされたリクエストでは、同じファイルにアクセスできないためです。アプリケーションコードと書き込み可能なデータパスは明確に区別し、本番環境で使用する前にファイルロックとストレージのセマンティクスを検証してください。
Nextcloudは通常、インストール時にデータベース設定を作成します。データベースエンドポイントと共有ストレージの準備が整ったら、各ノードが同じ値を解決することを確認してください。代表的な設定例は以下のとおりです。実際の認証情報は保護されたシークレット管理ワークフローに保管し、この設定例を既存の運用環境設定に上書きしないでください。
'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'redis.internal',
'port' => 6379,
'password' => 'REPLACE_WITH_SECRET',
],キャッシュバックエンドとデータディレクトリの選択を、お使いのNextcloudリリースでサポートされているオプションに合わせてください。必要に応じて、必要なPHP拡張機能をインストールして設定してください。
9. 分散キャッシュとファイルロックサービスを追加する
必要に応じて、ローカルのホストごとのキャッシュには APCu を使用し、分散キャッシュとトランザクションファイルロックには Redis や Valkey などの共有 Redis 互換サービスを使用してください。すべての Web ノードは、localhost ではなく、同じキャッシュサービスまたはサポートされているキャッシュクラスタを参照する必要があります。Nextcloud のドキュメントには、クラスタ構成の Redis クラスタ構成が記載されており、トランザクションファイルロックはデフォルトではデータベースに依存すると説明されています。キャッシュは、必要に応じてネットワーク制限、認証、および TLS を使用して保護してください。キャッシュの可用性とフェイルオーバー動作については、別途設計が必要です。
10. Galeraの前にデータベース対応エンドポイントを配置する
Nextcloud を、データベースプロキシまたはサポートされている別のルーティングレイヤーによって提供される安定したエンドポイントに向けます。プロキシは、プライマリコンポーネントに属していない、同期されていない、または準備が整っていないノードへの新規接続の送信を停止する必要があります。基本的な TCP ポートチェックでは、ソケットが接続を受け入れることしか証明できず、Galera がアプリケーションを安全に提供できることは証明できません。選択したプロキシのヘルスチェック動作と障害モードを確認してください。シンプルな TCP ロードバランサーを使用する場合は、信頼性の高い Galera 準備状況チェックと保守的なルーティングルールと組み合わせてください。
読み書き分割やラウンドロビンルーティングを安易に追加しないでください。Nextcloudの開発者マニュアルでは、プライマリ/レプリカ接続のサポートについて説明し、データが伝播していない場合やプロキシがトランザクション読み取りを適切なノードに保持できない場合、クラスタ全体に読み取りをルーティングすると整合性の問題が発生する可能性があると警告しています。安定した書き込み可能なエンドポイントから始め、その動作を測定し、整合性とサポートへの影響を理解した上で、特殊なルーティングを導入してください。
11. 冗長なWebロードバランシングと信頼できるプロキシ設定を追加する
ロードバランサーの背後に少なくとも2つのWebノードを配置し、ロードバランサー自体にはマネージドサービス、冗長ペア、テスト済みの仮想IP設計など、別の可用性メカニズムを使用してください。TLS終端、リクエストサイズとタイムアウトの動作、スティッキーセッションの要件は、デプロイメントに合わせて設定してください。Nextcloudリバースプロキシのドキュメントを確認し、trusted_proxies実際のプロキシアドレスを設定してください。任意のクライアント範囲を信頼すると、クライアントIPの処理が弱体化します。
12. 慎重に展開し、障害発生時と復旧時のテストを実施する。
まず、同じトポロジーを持つステージングコピーでアップグレードをテストしてください。アップグレード手順で必要な場合は、Nextcloudをメンテナンスモードにし、すべてのノードに同じアプリケーションリリースを適用し、ヘルスチェックに合格した後にのみノードをサービスに戻してください。定期的なホストメンテナンスでは、一度に1つのWebノードをドレインし、残りの容量が十分であることを確認してください。データベースのアップグレードは、対象となる正確なバージョンに対してサポートされているMariaDB/Galeraのローリングアップグレードプロセスを使用して適用してください。一般的なチュートリアルから独自の手順を作成しないでください。
文書化されたアプリケーション整合性のある手順を使用して、データベースとユーザーファイルデータ層をバックアップしてください。構成、暗号化データ、およびシークレットは、権限のある復旧オペレーターが利用できるようにしてください。Galera レプリカはバックアップではありません。誤って削除したり、論理的に破損したりすると、すべてのメンバーに複製される可能性があります。バックアップはクラスタの障害ドメイン外に保存し、定期的にリストアのリハーサルを実行してください。Galera は、クラスタバックアップガイダンスで状態転送とバックアップに関する考慮事項を文書化しています。採用する手順が、MariaDB リリースをサポートしていることを確認してください。
作業量とチームの能力に応じてデザインを選択してください。
Galeraは、データベースノードの冗長性が必要で、複数の障害ドメインがあり、クォーラムを監視して制御された復旧を実行できる場合に、実用的な選択肢となります。しかし、運用の簡素化が主な目的である場合、データベースのワークロードが競合する書き込みによって支配されている場合、またはチームがクォーラム喪失に安全に対応できない場合は、Galeraは適さない可能性があります。そのような場合は、堅牢なバックアップを備えたよりシンプルなサポート付きデータベースの導入、またはマネージドデータベースサービスの方が、運用上の信頼性を高めることができるでしょう。
小規模なセルフホスト型サービスの場合は、まずアプリケーションノードを相互に交換可能にし、ユーザーファイルを耐久性のある共有ストレージに移動し、共有Redisロックを設定し、バックアップをテストします。Galeraを追加するのは、測定結果からデータベースの単一ノード障害またはメンテナンス期間が許容できないリスクであり、組織が追加のレイヤーを維持できることが示された場合に限ります。意味のある成功テストは「3つのデータベースサーバーすべてが稼働している」ことではなく、計画的なノード障害の間もNextcloudのURLが使用可能であり、Webノード間でアップロードとダウンロードが機能し、データベースがクォーラムを維持し、チームがバックアップからデータベースとファイルデータの両方を復元できることです。
クイック検証チェックリスト
- Nextcloud、MariaDB、PHP、およびGaleraの各バージョンは互換性があり、サポートされています。
- すべてのデータベースノードは、プライマリメンバーシップ、予想されるクラスタサイズ、準備状況、および同期されたローカル状態を報告します。
- アプリケーションサーバーは、同じデータベースエンドポイント、構成、キャッシュ、およびファイルデータシステムを使用します。
- データベース、レプリケーション、キャッシュ、およびストレージのポートはプライベートであり、必要なピアのみに制限されています。
- ウェブプロキシとデータベースプロキシは、真に健全でないバックエンドをサービスから排除します。
- 計画されたウェブノードおよびデータベースノードの障害が、制御された期間内にテストされた。
- データベースとファイルデータのバックアップは、いずれもリハーサルで正常に復元されました。
公式資料
ownCloudサーバーで共有ファイルの所有権を移転する方法
ownCloud Serverの管理者が、共有、バージョン、検証を考慮しながら、occを使用して選択したフォルダまたはすべてのファイルを別のユーザーに転送する方法を学びましょう。
Nextcloudの「一部のファイルが整合性チェックに合格していません」という警告を修正する
Nextcloudのコード整合性警告の診断方法、変更または欠落したコアファイルの復元方法、余分なファイルやアプリ署名エラーの処理方法、そして修復が安全に行われたことを確認する方法を学びましょう。
Nextcloudデスクトップ同期クライアントが「ファイルの処理中」で停止する問題を修正する
Nextcloud Desktopが「ファイルの処理中」のまま止まってしまいますか？データにリスクを与えることなく、ブロックしているファイル、同期設定、ネットワーク、ログ、および安全なリセットオプションを診断します。
OCCを使用してNextcloud管理者パスワードをリセットする方法
occコマンドを使用して、紛失したNextcloud管理者パスワードをコマンドラインからリセットします。正しいインストールパスを見つけて、安全にリセットを実行し、アクセスを確認してください。
Jitsi Meet 用の Jibri 録画およびストリーミングサーバーの設定方法
Jitsi Meet 用に Docker Compose を使用して Jibri をセットアップします。録画の設定、ストレージ権限の保護、サービスの起動、録画と RTMP ストリームのテストを行います。
コマンドラインからownCloudのファイルバージョン履歴を削除する方法
ownCloud Serverの有効期限切れコマンドと完全削除コマンドを比較し、Infinite Scaleの個別のリビジョンワークフローと、クリーンアップを安全に検証する方法を学びましょう。
Jitsiルームの作成を特定の認証済みユーザーのみに制限する方法
Jitsi Meet の設定で、承認された認証済みユーザーのみがルームを開始できるようにし、許可すればゲストも参加できるようにします。Docker の手順と最新の認証ガイダンスが含まれています。
ownCloudで「WebDAVインターフェースが壊れています」エラーを修正する
ownCloudのWebDAV警告のトラブルシューティングを行うには、DAVルート、Apacheのリライト、リバースプロキシ、DNS、TLS、およびサーバー側の接続性を確認してください。
ClamAVまたはFreshClamを使用してZimbraのCPU使用率が高い問題を解決する
ZimbraでCPU使用率が高い原因がclamdかfreshclamのどちらであるかを特定し、適切なログを検査し、一般的な原因を安全に修正し、ウイルス対策サービスの復旧を確認します。