Open edXは、オンライン教育活動のためのプラットフォームです。世界が置かれている状況を考えると、そのようなプラットフォームはすべてより高い負荷に直面しており、その重要性は大幅に高まっています。これらは単なる「ヘルパー」プラットフォームではなく、教育活動が行われる主な方法になることがよくあります。これにより、処理できる負荷やプラットフォームの可用性に関する要件が高くなります。
Open edXは、複数の要素で構成される複雑な製品です。それらの1つはMySQLデータベースです。この短いブログでは、OpenedXプラットフォームの高可用性を向上させる方法について説明します。
明らかに、単一のMySQLデータベースは単一障害点であるため、本番環境への展開に適したアプローチではありません。 MySQLデータベースの可用性を向上させる方法はいくつかあります。
初心者の場合、非同期または準同期レプリケーションを使用してマスター/スレーブセットアップを実行できます。その利点は、マスターが使用できない場合に、スレーブの1つを昇格させて、操作を続行できることです。このような設定の主な欠点は、フェイルオーバーを手動で実行する必要があることです。これにより、ダウンタイムが増加するか、外部ソフトウェア（ClusterControlなど）を使用する必要がありますが、それでも少し時間がかかる場合があります。最後に、あらゆる種類の非同期または準同期レプリケーションは、レプリケーションラグの影響を受けます。これは、アプリケーションがマスターに対して書き込みを実行し、すぐにスレーブからそのデータを読み取ろうとする、書き込み後の読み取りシナリオに深刻な影響を与える可能性があります。
別のアプローチは、GaleraClusterを使用してOpenedXプラットフォームからのデータを保存することです。 3つのノードクラスターから始めることができます。このようなクラスターは、単一ノードの障害を自動的に処理できます。残りの2つのノードは引き続き機能し、アプリケーションからのクエリに応答します。 Galeraのもう1つの利点は、「実質的に」同期している（つまり、ほぼ同期している）にもかかわらず、因果関係チェックを強制し、クラスターを同期モードに強制する方法があることです（パフォーマンスの低下）。
どちらのシナリオでも、トラフィックを処理して適切な宛先にリダイレクトする、ある種のロードバランサーがシナリオの前に必要になります。
ClusterControlが、OpenedXプラットフォームに使用できる一連のロードバランサーを使用してGaleraクラスターをデプロイするのにどのように役立つかを見てみましょう。
MariaDBクラスターのデプロイ
今回は、MariaDBクラスターをバックエンドとして使用してみます。繰り返しますが、最初のステップは同じです。ウィザードから「デプロイ」を選択する必要があります。
これを行ったら、SSH接続、パスワードなし、キーを定義する必要がありますClusterControlの要件はSSHベースのアクセスです。そうでない場合、データベースインフラストラクチャを管理できません。
次に、ベンダー、バージョン、パスワード、ホストなどを決定する必要があります追加設定：
これらすべての詳細が入力されたら、展開を続行できます。
ProxySQLの導入
ProxySQLの場合、ClusterControlにもいくつかの情報を入力する必要があります。インストールするホスト、ProxySQLのバージョン、管理ユーザーと監視ユーザーの資格情報を決定します。これらのユーザーは、ProxySQLを管理し、Galeraクラスターの状態を監視するために使用されます。また、既存のデータベースユーザーをインポートするか、アプリケーション用に新しいデータベースユーザーを作成する必要があります。最後に、ProxySQLで使用するデータベースノードを決定し、暗黙的なトランザクションを使用するかどうかを決定するのはあなた次第です。
次のステップとして、Keepalivedをデプロイします。ここでの考え方は、動作中のProxySQLインスタンスを指す仮想IPを用意することです。このようなVIPは、MySQLデータベース接続のエンドポイントとしてアプリケーションで使用できます。
監視する必要のあるProxySQLインスタンス、仮想IP、インターフェイスVIPは、デプロイする準備ができていることにバインドする必要があります。数分後、すべての準備が整い、トポロジは次のようになります。
デプロイメントに関しては、これでほぼ完了です。 Open edXプラットフォームをVIPおよびポート6033に向けることができます。これは、バックエンドデータベースへの接続を取得するのに十分なはずです。最後に残っているのは、必要に応じて、因果関係チェックを構成することです。それを実行できるwsrep_sync_wait変数があります。読み取り、更新、挿入、削除、置換、SHOWコマンドなどのいくつかのアクセスパターンでテストを有効にできます。 SELECTクエリのみに関心がある場合は、ClusterControl構成管理を使用してこの変数を「1」に設定します。
これにより、すべてのMariaDBクラスターノードでこの変更が実行されます。