今日、対面式の会議は最小限に制限されており、オンライン活動が教師と生徒の相互作用の主な方法として引き継がれています。これにより、既存のオンライン「会議」プラットフォーム（現在のZoomが何であるかを知らない人はいますか？）だけでなく、オンライン学習プラットフォームへのストレスも増大しました。オンラインツールの高可用性はこれまで以上に重要であり、運用チームは環境に合わせて耐久性が高く可用性の高いアーキテクチャを急いで構築しています。
Moodleを使用したことがある人もいるでしょう。これは、オンプレミスにデプロイして組織にオンライントレーニングを提供するために使用できるスタンドアロンのオンライン学習プラットフォームです。前述したように、耐久性があり、可用性の高い方法で機能させることがこれまでになく重要です。非同期レプリケーションとGaleraClusterの両方のバックエンドデータベースとしてMariaDBを含む高可用性ソリューションを提案したいと思います。
Moodleの環境設計の背後にある思考プロセスを説明するプロセスから始めたいと思います。高可用性が必要なため、単一のデータベースノードは機能しません。複数のノードが必要であり、これが最初の設計上の決定につながります。非同期レプリケーションまたはGaleraClusterを使用する必要がありますか？ 2番目の質問は、ワークロードをノード間でどのように分散するかです。 2つ目から始めましょう。
このブログが書かれた時点での最新のMoodleバージョン（3.9）は、セーフリードと呼ばれる優れた機能を導入しました。ここで解決する問題は、書き込み後に読み取られます。 1つのノードを使用する場合、世界は単純な場所です。あなたは書いた後、読んだ。あなたが書いたものは何でもすでにそこにあります。ただし、ノードを追加すると状況が変わります。非同期レプリケーションでは、スレーブは数十秒以上遅れることがあります。マスターに何を書き込んでも、スレーブに適用されるまでに数分かかる場合があります（より極端な場合はそれ以上ではありません）。書き込みを実行してすぐにスレーブの1つから同じデータを読み取ろうとすると、厄介な驚きが生じる可能性があります。データはそこにありません。 Galeraクラスターは「仮想的に」同期レプリケーションを使用します。この特定のケースでは「仮想的に」大きな違いがあります。Galeraは書き込み後の読み取りの問題の影響を受けません。ローカルノードでの書き込みの実行と、クラスタの残りのノードに適用される書き込みセットの間には、常に遅延があります。確かに、それは秒ではなくミリ秒で測定される可能性が高いですが、それでもあなたが書いたものをすぐに読むことができるという仮定を破る可能性があります。書き込み後に安全に読み取ることができるのは、データを書き込んだノードだけです。
Moodleは書き込み後の読み取りに大きく依存しているため、読み取り元のノードを追加するだけでは、読み取りを簡単にスケーリングすることはできません。 Galera Clusterの場合、wsrep-sync-wait構成設定を使用して、読み取りを安全に実行できるようにGaleraに強制することで、問題の軽減を試みることができます。これにより、すべての読み取りが実行される前に書き込みが適用されるのを待機する必要があるため、システムのパフォーマンスに影響があります。これは、非同期レプリケーションではなく、MariaDBクラスター（およびその他のGaleraベースのソリューション）のソリューションでもあります。幸いなことに、Moodleのソリューションはこの問題を解決します。遅れている可能性のあるノードのリストを定義することができ、Moodleは書き込みを最新にする必要のない読み取りにのみそれらを使用します。データが常に最新である必要がある残りのすべての読み取りは、ライターノードに送信されます。したがって、「安全な」読み取りのみをスケールアウトできるため、Moodleのスケーラビリティはある程度制限されます。 3.9の機能を使用することは間違いありません。これが、どの選択をどこに配置するかを決定するための唯一の安全な方法だからです。すべてがMoodleの構成ファイルに記述されていることを考えると、ロードバランサー、できればProxySQLを使用して、読み取り分散を処理するロジックを作成することをお勧めします。
MariaDBクラスターまたは非同期レプリケーションを使用する必要がありますか？実際に両方の使い方を紹介します。どちらの場合も、Moodleの設定はほとんど同じです。どちらの場合も、ロードバランサーとしてProxySQLを利用します。これらのソリューションの主な違いは、フェイルオーバーです。 MariaDBクラスターの処理ははるかに簡単です。1つのノードがダウンした場合、ProxySQLは書き込みトラフィックを残りのノードの1つに移動するだけです。ただし、非同期レプリケーションでは、状況が少し異なります。マスターがダウンした場合、フェイルオーバーが発生する必要があります。これは自動的には発生しません。手動で実行するか、ソフトウェアを使用して実行する必要があります。この例では、ClusterControlを使用して環境を管理し、フェイルオーバーを実行します。したがって、ユーザーの観点からは、非同期レプリケーションとMariaDBクラスターの間に大きな違いはありません。どちらの場合も、ライターの障害は自動的に処理され、クラスターは自動的に回復します。 。
私たちが確立したのは、非同期レプリケーションと仮想同期レプリケーションの両方を紹介することです。 Moodle 3.9の安全書き込み機能を使用し、ロードバランサーとしてProxySQLを使用します。高可用性を確保するには、複数のProxySQLインスタンスが必要になるため、そのうちの2つを使用して、データベースレイヤーへの単一のエントリポイントを作成し、Keepalivedを使用して仮想IPを作成し、使用可能なProxySQLの1つをポイントします。ノード。データベースクラスターは次のようになります。
非同期レプリケーションの場合、これは次のようになります。
MariaDBレプリケーションから始めましょう。 ClusterControlを使用して、ロードバランサーを含むデータベースバックエンド全体をデプロイします。
最初に、ウィザードから「デプロイ」を選択する必要があります：
次に、SSH接続を定義する必要があります。パスワードなしのキーベースのSSHアクセスは次のとおりです。 ClusterControlがデータベースインフラストラクチャを管理するための要件。
これらの詳細を入力したら、ベンダーとバージョンを選択します。 、スーパーユーザーのパスワードを定義し、その他の詳細を決定します。
ここでは、MariaDB10.4を使用します。次のステップとして、レプリケーショントポロジを定義する必要があります。
ノードのホスト名と、ノードがそれぞれにどのように関連するかを渡す必要があります他の。トポロジに満足したら、展開できます。このブログでは、マスターと2つのスレーブをバックエンドとして使用します。
最初のクラスターの準備が整いました。それでは、ProxySQLとKeepalivedをデプロイしましょう。
ProxySQLの導入
ProxySQLの場合、いくつかの詳細を入力する必要があります-インストールするホストを選択してくださいそれをオンにして、ProxySQLのバージョン、管理ユーザーと監視ユーザーの資格情報を決定します。また、既存のデータベースユーザーをインポートするか、アプリケーション用に新しいデータベースユーザーを作成する必要があります。最後に、ProxySQLで使用するデータベースノードを決定し、暗黙的なトランザクションを使用するかどうかを決定します。 Moodleの場合、これは真実ではありません。
次のステップとして、Keepalivedをデプロイします。
監視する必要のあるProxySQLインスタンス、仮想IP、インターフェイスVIPは、デプロイする準備ができていることにバインドする必要があります。数分後、すべての準備が整い、トポロジは次のようになります。
最後のステップは、安全な書き込みを使用するようにMoodleとProxySQLを設定することです。 Moodle構成でデータベースノードをハードコーディングすることは可能ですが、トポロジーの変更を処理するためにProxySQLに依存する方がはるかに良いでしょう。私たちにできることは、データベースに追加のユーザーを作成することです。そのユーザーは、安全な読み取りを実行するようにMoodleで設定されます。 ProxySQLは、そのユーザーから実行されたすべてのトラフィックを使用可能なスレーブノードに送信するように構成されます。
まず、読み取り専用アクセスに使用するユーザーを作成しましょう。
ここではすべての権限を付与していますが、そのリストを制限することは可能です。 。
ProxySQLがそのユーザーとして認証できるようにするには、作成したばかりのユーザーをクラスター内にある両方のProxySQLインスタンスに追加する必要があります。 ClusterControl UIでは、「ユーザーのインポート」アクションを使用できます。
作成したばかりのユーザーを検索できます：
ProxySQLは、ホストグループ（同じ目的を果たすホストのグループ）の概念を使用します。デフォルトの構成では、2つのホストグループがあります。常に現在のマスターを指すホストグループ10と、スレーブノードを指すホストグループ20です。このユーザーにトラフィックをスレーブノードに送信させたいので、デフォルトとしてHG20を割り当てます。
これで、ユーザーはユーザーのリストに表示されます。
ここで、他のProxySQLノードで同じプロセスを繰り返すか、 「インスタンスの同期」オプション。いずれにせよ、両方のProxySQLノードにmoodle_safereadsユーザーを追加する必要があります。
これが完了したら、すべてのトラフィックを一時的にに送信する必要がありますマスター。これは、ProxySQLのすべてのクエリルールを削除することで実現できます。 「moodle」ユーザーはデフォルトのホストグループとしてHG10を持っています。これは、クエリルールがない場合、そのユーザーからのすべてのトラフィックがマスターに転送されることを意味します。 2番目の安全な読み取りユーザーには、デフォルトのホストグループ20があります。これは、必要な構成のほとんどすべてです。
これが完了したら、Moodleの設定ファイルを編集してセーフを有効にする必要があります読み取り機能：
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = '192.168.1.111';
$CFG->dbname = 'moodle';
$CFG->dbuser = 'moodle';
$CFG->dbpass = 'pass';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => 0,
'dbport' => 6033,
'dbsocket' => '',
'dbcollation' => 'utf8mb4_general_ci',
'readonly' => [
'instance' => [
'dbhost' => '192.168.1.111',
'dbport' => 6033,
'dbuser' => 'moodle_safereads',
'dbpass' => 'pass'
]
]
);
$CFG->wwwroot = 'http://192.168.1.200/moodle';
$CFG->dataroot = '/var/www/moodledata';
$CFG->admin = 'admin';
$CFG->directorypermissions = 0777;
require_once(__DIR__ . '/lib/setup.php');
// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!ここで起こったことは、moodle_safereadsユーザーを使用するProxySQLへの読み取り専用接続を追加したことです。このユーザーは常にスレーブを指します。これで、MariaDBレプリケーション用のMoodleのセットアップは完了です。
今回は、MariaDBクラスターをバックエンドとして使用してみます。繰り返しますが、最初のステップは同じです。ウィザードから「デプロイ」を選択する必要があります。
これを行ったら、SSH接続、パスワードなし、キーを定義する必要があります- ClusterControlがデータベースインフラストラクチャを管理するには、ベースのSSHアクセスが必要です。
次に、ベンダー、バージョン、パスワードホストなどを決定する必要があります。設定：
すべての詳細を入力したら、展開します。
ここでさらに続行することもできますが、以降のすべての手順は基本的にMariaDBレプリケーションの場合と同じであるため、上にスクロールして「ProxySQLのデプロイ」セクションとそれに続くすべてを確認するように求められます。 ProxySQL、Keepalivedをデプロイし、再構成し、Moodleの構成ファイルを変更する必要があります。これでほぼ完了です。このブログが、MariaDBクラスターまたはレプリケーションに裏打ちされたMoodleの高可用性環境の構築に役立つことを願っています。