サーバクラスタ

このページでは、サーバクラスタリングに関する基本的な情報を説明します...

要件

データベースサーバ - ACID準拠のもの。たとえばPostgreSQLやMariaDB
datarootを共有できるメインサーバ - ロックのサポートを推奨。たとえばNFS
ロードバランサ - たとえばNginx
クラスタノード - ウェブサーバ
共有MUCキャッシュ用のRedis（またはMemcached）サーバ

注：このガイドは、Windows OSやその他のMicrosoft技術を対象としていません。

初期インストール

共有データベースおよびdatarootディレクトリを使用して、メインサーバで標準のCLIインストールを実行します。
クラスタノードにウェブサーバをセットアップします。ローカルのdirroot、共有データベースおよびdatarootを使用します。
負荷分散を設定します。

関連するconfig.php設定

$CFG->wwwroot

すべてのノードで同じである必要があり、外部に公開されるURLでなければなりません。動的にすることはできません。

$CFG->sslproxy

wwwrootがhttps://であるものの、SSLの処理をウェブサーバではなくロードバランサが行っている場合に有効にします。

$CFG->loginhttpsとは互換性がないことに注意してください。これは、loginhttpsが機能するには、元のリクエストと、それがhttpとhttpsのどちらであったかを知る必要があるためです。これにより、ログインフォームのみをSSL経由で提供できます。「リバース」プロキシ / ロードバランサを経由したリクエストでは元のリクエストが失われるため、リクエストがどのプロトコルで行われたかを判断できません。そのため、Moodleの大部分をhttpで提供し、ログインページをhttpsで提供することはできません。

サイトを本当に安全にするには、セキュアクッキーのみを有効にしてください。これを有効にしないと、クッキーの窃取は依然として容易です。

$CFG->reverseproxy

ノードに異なるURLでアクセスする場合に有効にします。

$CFG->loginhttpsとは互換性がないことに注意してください。これは、loginhttpsが機能するには、元のリクエストと、それがhttpとhttpsのどちらであったかを知る必要があるためです。これにより、ログインフォームのみをSSL経由で提供できます。「リバース」プロキシ / ロードバランサを経由したリクエストでは元のリクエストが失われるため、リクエストがどのプロトコルで行われたかを判断できません。そのため、Moodleの大部分をhttpで提供し、ログインページをhttpsで提供することはできません。

$CFG->dirroot

$CFG->dirroot（realpath(config.php)によって自動的に設定されます）は、すべてのノードで同じパスにすることを強くお勧めします。ただし、同じ共有ディレクトリを指す必要はありません。これは、一部の低レベルのコードがキャッシュの無効化にdirrootの値を使用する場合があるためです。

最も簡単な解決策は、各クラスタノードで同じディレクトリ構造にし、アップグレードのたびにそれらを同期することです。

dirrootは、apacheプロセスに対して常に読み取り専用にしてください。そうしないと、組み込みのプラグインのインストールおよびアンインストール機能によって、ノード間の同期が崩れてしまいます。

$CFG->dataroot

これは、各クラスタノードがファイルに直接アクセスする共有ディレクトリでなければなりません。非常に高い信頼性が必要です。管理者がファイルを直接操作することはできません。

ロックのサポートは必須ではありません。cachedirまたはmucディレクトリ以外のdataroot内でファイルロックを使用しようとするコードがあれば、それはバグです。

$CFG->alternative_file_system_class

デフォルトでは、アップロードされたすべてのコンテンツファイルは重複排除され、[$CFG->dataroot]/filedir内に保存されます。ただし、これをAWS S3などのクラウドストアのような代替ファイルストアに置き換えることができます。

$CFG->alternative_file_system_class = '\tool_objectfs\xxxxx'; ここで、xxxxxは選択したストレージに置き換える必要があります。 https://github.com/catalyst/moodle-tool_objectfs/

また、local_alternative_file_systemプラグイン https://moodle.org/plugins/local_alternative_file_system という選択肢もあり、実際にはこちらの方がはるかに高速に動作する傾向があります：

注：代替ファイルシステムを使用する場合でも、共有の$CFG->datarootが必ず必要です。

$CFG->tempdir

このディレクトリは、すべてのクラスタノードで共有しなければなりません。ロックが必要です。

$CFG->cachedir

このディレクトリは、すべてのクラスタノードで共有しなければなりません。ロックが必要です。

$CFG->localcachedir

$CFG->cachedirとの違いは、このディレクトリはすべてのクラスタノードで共有する必要がなく、ファイルの内容が変更されないことです。各クラスタノードで高速なローカルファイルシステムを使用してください。

このパスの性質として、ファイルの入れ替わりが非常に遅く、ファイルは長期間保持され、一度書き込まれた後は上書きされることがありません。

$CFG->localrequestdir

デフォルトでは、これは/tmp、またはsys_get_temp_dir()が返すディレクトリの中に作成され、通常はすでにローカルディスクであり、他のノードとは共有されません。このディレクトリには、単一のhttpリクエストの間だけ存在する一時フォルダおよびファイルが保持されます。これを変更する場合は、各クラスタノードで高速なローカルファイルシステムを使用してください。

$CFG->backuptempdir

サーバクラスタでは、backuptempdirに必ず共有ファイルシステムを使用しなければなりません！このディレクトリは非常に大きくなり、高速なIOのバーストが発生しますが、ファイルが一般にここに長く留まることはありません。書き込みが多く、競合はあまり発生しません。

$CFG->alternative_component_cache

これは、Moodleが使用するコンポーネントの非常に低レベルな表現をキャッシュするために使用されます。非常に低レベルであるため、他の高レベルなAPIが利用可能になる前の段階で使用されます。すべてのリクエストで常に読み込まれるため、ローカルディスクに置く方がはるかに優れています。

通常、$CFG->alternative_component_cache = '/local/cache/dir/core_component.php' は、ローカルノードのキャッシュディレクトリを指します。

注：アップグレードの前に、管理者は各ノードで次のコマンドを必ず手動で実行する必要があります：

$ php admin/cli/alternative_component_cache.php --rebuild

または、キャッシュファイルをdirrootに直接配置し、新しいPHPソースファイルと一緒に配布することもできます。さらに別の方法として、アップグレード前にすべてのノードのすべてのローカルキャッシュを削除するか、アップグレード前にすべてのノードのconfig.phpでスクリプト名を変更するだけでもかまいません。または、CI / CDデプロイメントの一環として、これを新しいコンテナに組み込むこともできます。

Moodle 2.6で実装されました。MDL-40475を参照してください。

パフォーマンスの推奨事項

すべてのクラスタノードでOPcache拡張モジュールを使用します。
各ノードで、$CFG->localcachedirを高速なローカルファイルシステムに設定します。
対応しているすべての共有キャッシュに、1台の大きな中央memcachedサーバを使用します。
対応しているローカルキャッシュには、クラスタノード上のローカルmemcachedインスタンスを使用します。
ユーザセッションは、Redisなどの1台の共有サーバに保存します。（詳細はセッションハンドリングを参照してください）
各クラスタノードで、dirrootに高速なローカルディレクトリを使用します。
動的なクラスタノード管理を使用します。
透過型プロキシサーバを使用します。

アップグレード手順

ロードバランサを無効にします。
マスタサーバでdirrootのファイルをアップグレードします。
CLIアップグレードを実行します。
クラスタノードのすべてのキャッシュを手動でリセットします。ウェブサーバの再起動、localcachedirおよびtempディレクトリの削除、memcachedの再起動などを行います。または、すべてのクラスタノードを削除し、新しいテンプレートからノードを作成します。
ロードバランサを有効にします。

Moodle 2.6におけるサーバクラスタリングのステップバイステップガイド

Hardware and performanceフォーラムのスレッド https://moodle.org/mod/forum/discuss.php?d=251547 より

1 キャッシュに関する具体的なニーズを判断します。これには、共有キャッシュかローカルキャッシュか、ディスクベースのキャッシュかサーバベースのキャッシュか、あるいはMemcachedやMongoDBのようなプロトコル固有のキャッシュかといった概念が関係します。
- 1.1 共有ディスクが遅い場合は、ローカルディスクキャッシュが役立つ可能性があります。
- 1.2 Moodleサイトのユーザが少数しかいない場合は、Memcachedによる高速化がユーザエクスペリエンスにとって非常に大きな効果をもたらすとしても、Memcachedサービスをセットアップしなくてもよいかもしれません。
- 1.3 サイトを高速化するためにできることは何でもしたい場合は、MongoDBを検討してもよいでしょう。
2 キャッシュを設定し、テストして検証します。キャッシュ設定の例には改善の余地があります。これがおそらく最も難しいステップです。
3 サーバレベルでキャッシュのサポートをインストールします。これには、phpモジュールのインストールや、phpモジュールの設定が含まれる場合があります。
4 MUCで、次の場所でキャッシュインスタンスを作成します：example.com/cache/admin.php?action=addstore&plugin=memcached
- 4.1 キャッシュインスタンスに任意の名前を付けます。
- 4.2 他のすべてのフィールドにはクリックできるクエスチョンマークがあり、クリックすると、何を入力すべきか、そして構文（非常に重要）を説明する優れたヘルプが表示されます。
- 4.3 結果として、選択した名前の設定済みストアインスタンスができるはずです。
5 最後のステップは、「既知のキャッシュ定義」の一覧で、たとえば「言語ストリングキャッシュ」の「マッピングを編集する」を使用して、作成したキャッシュインスタンスをデプロイすることです。
- 5.1 これを試している間、デフォルト設定が選択された別のブラウザウィンドウを開いておくと、非常に助かることが筆者にはわかりました。そうしておけば、万一サイトとの接続が切れた場合でも、「変更を保存する」ボタンをクリックするだけで設定を元に戻せます。
- 5.2 設定済みストアインスタンスの名前をドロップダウンリストから選択し、「変更を保存する」ボタンをクリックします。
- 5.3 新しいキャッシュ設定をテストします。サイトとの接続が切れたり、サイトの動作がおかしくなったりした場合は、ステップ1のトリックを使用してみてください。緊急の場合は、$CFG->datarootが指すフォルダにあるキャッシュ設定ファイル（muc/config.php）を削除してもかまいません。ファイルがない場合、Moodleは新しいデフォルト設定ファイルを書き込むようです。

Documentation