サーバークラスタ

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

必要条件

  • データベースサーバ - ACID準拠、例えばPostgreSQLやMariaDB
  • データルートを共有できるメインサーバー - NFSなどのロックサポートを推奨
  • ロードバランサ - 例えばNginx
  • クラスタノード - Webサーバー
  • 共有キャッシュ用のMemcachedサーバー

注：このガイドは、Windows OSまたはその他のマイクロソフトテクノロジを対象としていません。

初期インストール

  1. 共有データベースとdatarootディレクトリを使用して、メインサーバーに標準CLIインストールを実行します。
  2. クラスタノード上にWebサーバーをセットアップする - ローカルディレクトリと共有データベースおよびデータルートを使用します。
  3. 負荷分散を設定します。

関連するconfig.php設定

$ CFG-> wwwroot

それはすべてのノードで同じでなければならず、それは一般向けのURLでなければなりません。動的にすることはできません。

$ CFG-> sslproxy

https：// wwwrootがあるがSSLがWebサーバーではなくロードバランサによって行われる場合は有効にします。

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

あなたのサイトを本当に安全にするためだけにセキュアクッキーを有効にしてください。

$ CFG->リバースプロキシ

あなたのノードが異なるURLを介してアクセスされる場合に有効にします

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

$ CFG-> dirroot

$ CFG-> dirroot（これはrealpath（config.php）で自動的に設定されます）がすべてのノードで同じパスを含むことを強く推奨します。ただし、同じ共有ディレクトリを指す必要はありません。その理由は、いくつかの低レベルのコードがキャッシュ無効化のためにdirroot値を使うかもしれないからです。

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

そうでなければプラグインのインストールとアンインストールに組み込まれているとノードが同期しなくなるため、dirrootは常にapacheプロセスに対してのみ読み取る必要があります。

$ CFG-> dataroot

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

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

$ CFG-> tempdir

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

$ CFG-> cachedir

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

$ CFG-> localcachedir

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

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

  1. すべてのクラスタノードでOPcache拡張機能を使用してください。
  2. 各ノードで$ CFG-> localcachedirを高速ローカルファイルシステムに設定します。
  3. それをサポートするすべての共有キャッシュに1つの大きな中央memcachedサーバーを使用してください。
  4. それをサポートするローカルキャッシュには、クラスタノード上のローカルmemcachedインスタンスを使用します。
  5. ユーザーセッションを1つの共有memcachedサーバーに保存します。 （詳細はSession_handlingを参照してください）
  6. 各クラスタノードのdirrootに高速ローカルディレクトリを使用します。
  7. 動的クラスタノード管理を使用します。
  8. 透過プロキシサーバーを使用する

アップグレード手順

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

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

ハードウェアおよびパフォーマンスフォーラムのスレッドから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結果は、選択した名前のConfigured Store Instanceになります。
  • 5最後のステップは、既知のキャッシュ定義のリストにある言語文字列キャッシュなどのマッピングの編集によって、作成されたキャッシュインスタンスをデプロイすることです。
    • 5.1これを試しているうちに、デフォルト設定が選択されている別のブラウザウィンドウを開くのが命の恩人であることがわかったので、保存ボタンをクリックして設定を元に戻す必要があります。サイト。
    • 5.2ドロップダウンリストから設定済みストアインスタンスの名前を選択し、[保存]ボタンをクリックします。
    • 5.3新しいキャッシュ設定をテストします。あなたがサイトとの連絡を失ったか、それが奇妙に振る舞うならば、ステップ１のトリックを使ってみてください。緊急の場合には、$ CFG-> datarootによって指されるフォルダーのキャッシュ設定ファイル（muc / config.php）を削除するかもしれません。それが見つからない場合、Moodleは新しいデフォルト設定ファイルを書き込みます。

関連情報

" https://docs.moodle.org/35/en/index.php?title=Server_cluster&oldid=128295 "より作成