Open edXは、edXの背後にある非常にスケーラブルな学習ソフトウェアテクノロジーを提供するプラットフォームです。 Open edXプロジェクトは、オンラインコースを作成、配信、分析するためのWebベースのプラットフォームです。これは、edx.orgや他の多くのオンライン教育サイトを強化するソフトウェアです。
OpenedXプラットフォームでのMySQLデータベースの高可用性の展開について以前にブログを書きました。前に述べたように、それは複数のコンポーネントをカバーするため複雑なプラットフォームであり、この巨大なプラットフォームの一部は複数のサービスによってカバーされます:
- eコマース:https://github.com/edx/ecommerce
- カタログ:https://github.com/edx/course-discovery
- LMS /スタジオ:https://github.com/edx/edx-platform
- 資格情報:https://github.com/edx/credentials
- インサイト:https://github.com/edx/edx-analytics-dashboard
- Analytics API:https://github.com/edx/edx-analytics-data-api
基本的に、Open Edxは、パンデミックやオンライントレーニングの中でのオンラインコースに最適です。特に、製品認定を取得している場合は、すでに試したり受講したりしている可能性があります。
Open edXアーキテクチャの目玉は、学習管理アプリケーションとコースオーサリングアプリケーション(それぞれLMSとStudio)を含むedxプラットフォームです。そのedxプラットフォームに加えて、プラットフォーム全体を構成する技術サービスは、このソフトウェアの複雑なレベル全体をカバーするさまざまなテクノロジーを含みます。昨年12月のedXチームのプレゼンテーションから抜粋した以下の図を参照してください。
Snowflake、Amazon RDS、MongoDB、Amazon S3、Elasticsearch、Memcachedがあります、およびこの豊富なプラットフォームを具体化するテクノロジーとしてのRedis。それでも、Open edXのインストールとセットアップはさらに困難ですが、このプラットフォームを少し理解するために、簡単な開発環境を構築することができました。
一方で、フォーラム、コース構造、コースアセットのコンテンツを保存するために使用されるMongoDBに焦点を当てましょう。学習者ごとのデータはMySQLに保存されるため、Open edXを使用したMySQLの高可用性を知りたい場合は、こちらをお読みください。
MongoDBのコンテンツの保存
MongoDBは、テキストファイル、PDF、オーディオ/ビデオクリップ、tarballなどの大きなファイルを保存するためにOpen edXが選択したデータベースです。OpenedXに精通していて、特に次のように使用したことがある場合LMSまたはStudioの作成者である場合、OpenedXセットアップにアセットをアップロードするとデータが保存されます。これらのアップロードはいわゆる「コンテンツストア」であり、基本的にはMongoDBがサポートするGridFSインスタンスです。 Open edXは、MongoDBグリッドFSを使用してファイルデータをMongoDBインスタンス内にチャンクで保存し、16MBを超えるサイズのファイルを保存できます。また、ファイル全体ではなく、大きなファイルの一部を提供することもできます。
OpenedXMongoDBデータベースの高可用性の設定
OpenedXプラットフォームのインストールまたはセットアップは大きな課題であることを認めましょう。このプラットフォームやソフトウェアを初めて使用するのは特に難しいですが、非常に優れたアーキテクチャ設計になっています。ただし、MongoDBを使用したセットアップが、プライマリとしての1ノードのレプリカセットスタンドである可能性があります。一方、レプリカセットには、プライマリ以外に少なくともセカンダリノードまたは複数のセカンダリノードが必要です。これは、プライマリが機能しなくなった場合に高可用性のセットアップを提供し、セカンダリレプリカノードがプライマリの役割を引き継ぎます。
これを行うには、少なくとも2つのセカンダリレプリカを追加してセットアップする必要があります。理想は、少なくともレプリカセットに、1つがプライマリである3つのノードがあり、他の2つのノードがプライマリに複製するセカンダリであるということです。これにより、プライマリがセカンダリとの接続を失った場合に、MongoDBレプリカセットが選択を続行できます。これにより、信頼性、冗長性、そしてもちろん高可用性が実現します。これは、MongoDBで高可用性環境を実現するために必要な簡単なセットアップです。
なぜこれが高可用性を提供するのですか? MongoDBのレプリカセットは、同じデータセットを維持するmongodプロセスのグループです。 MongoDBレプリカセットは、選択を使用して、プライマリがダウンしたり、異常終了したり、構成が変更されたりした場合に、どのセットメンバーがプライマリになるかを決定します。レプリカセットは、次のようなさまざまなイベントに応じて選挙をトリガーできます。
- rs.stepDown()やrs.reconfig()などのメソッドを使用してレプリカセットのメンテナンスを実行し、
- セカンダリメンバーは、設定されたタイムアウト(デフォルトでは10秒)を超えてプライマリへの接続を失います。
これで見栄えが良くなりましたが、ホスト名やIPアドレスの変更など、アプリケーションクライアントエンドポイントを処理するには手動で変更する必要があります。 MongoDBレプリカセットはMongoDBの内部で選択を実行するため、HaProxyのようにレプリカセットの上にロードバランサーがある場合は理想的ではありません。
大規模なデータセットを扱う場合は、シャードクラスターが理想的です。シャードクラスターを設計する必要があるという意味ではありませんが、大規模なデータセットを処理する必要があります。 MongoDBはmongosを提供します。これは、アプリケーション層からのクエリを処理し、トランザクションまたはデータベースを完了するためにシャードキーで識別されるシャードクラスター内のこのデータの場所を決定するMongoDBシャード構成のルーティングサービスとして機能するユーティリティです。オペレーション。基本的に、mongosインスタンスは他のMongoDBインスタンスと同じように動作すると考えてください。
では、なぜアプリケーションの前にモンゴを置くのですか?アプリケーションの観点から、選択後にレプリカがプライマリホスト名またはIPを変更する場合は、エンドポイントも変更する必要があります。 mongosを使用する場合は、アプリケーションクライアントをmongosインスタンスの1つにポイントするだけです。アプリケーションクライアントはmongosインスタンスとのみインターフェースし、それだけが重要です。 mongosは、MongoDB Shardセットアップの目的と機能を利用して、クエリリクエストまたはトランザクションを処理するものになります。つまり、Open edx構成ファイルでは、変更を加える必要はありません。 MongoDBレプリカセットからの変更に追いつくために、アプリケーションサーバーを再起動する必要はありません。
たとえば、ClusterControlを使用します。 ClusterControlの使用は、UIを介して実行できるため、非常に複雑なセットアップでの手動構成やインストールを回避できるため、簡単かつ効率的に実行できます。
OpenedXデータベースが存在する既存のMongoDBインスタンスがあるとしましょう
rs0:PRIMARY> show dbs;
admin 0.000GB
cs_comments_service 0.000GB
edxapp 0.087GB
local 0.118GB
rs0:PRIMARY> rs.status()
{
"set" : "rs0",
"date" : ISODate("2021-01-22T14:46:51.398Z"),
"myState" : 1,
"term" : NumberLong(17),
"heartbeatIntervalMillis" : NumberLong(2000),
"members" : [
{
"_id" : 0,
"name" : "192.168.40.10:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 133,
"optime" : {
"ts" : Timestamp(1611326680, 1),
"t" : NumberLong(17)
},
"optimeDate" : ISODate("2021-01-22T14:44:40Z"),
"electionTime" : Timestamp(1611326679, 1),
"electionDate" : ISODate("2021-01-22T14:44:39Z"),
"configVersion" : 2,
"self" : true
}
],
"ok" : 1
}
これを既存のデータベースとしてClusterControlにインポートし、ClusterControlのバックアップ機能を使用してバックアップを取ることができます。または、mongodumpを使用するか、Percona BackupforMongoDBを使用してみてください。
次に、ClusterControlで、新しいデプロイメントとしてMongoDBシャードを作成します。これは、次の手順で実行できます。
-
デプロイメントウィザードダイアログで新しいMongoDBシャードをデプロイします。
-
SSH設定とその構成サーバーおよびルーターをセットアップします。これは、mongosインスタンスが構成サーバーとは別に存在する場所です。
-
シャードを定義します。これらは、レプリカセットのシャードです。必要に応じて。たとえば、この展開では2つのシャードを展開しましたが、特に小規模な展開では、最初に1つのシャードを使用するだけで済みます。
-
データベース設定を定義する
この時点で、デプロイボタンを押して、ClusterControlによってジョブが処理されるのを待ちます。
-
終了したら、mongodumpから取得したバックアップを復元できます。たとえば、ClusterControlを使用してバックアップを作成し、これをソースバックアップとして使用しました。 mongorestoreコマンドを使用するときは、宛先ホストがmongosインスタンスの1つであることを確認してください。この展開例では、192.168.40.233ホストがあります。
$ mongorestore --host 192.168.40.233 --port 27017 --username <username> --password <password> --gzip --archive=BACKUP-2/rs0.gz --authenticationDatabase=admin
2021-01-22T11:17:06.335+0000 preparing collections to restore from
2021-01-22T11:17:06.336+0000 don't know what to do with subdirectory "cs_comments_service", skipping...
2021-01-22T11:17:06.336+0000 don't know what to do with subdirectory "edxapp", skipping...
2021-01-22T11:17:06.337+0000 don't know what to do with subdirectory "admin", skipping...
2021-01-22T11:17:06.337+0000 don't know what to do with subdirectory "", skipping...
2021-01-22T11:17:06.372+0000 restoring to existing collection edxapp.modulestore.definitions without dropping
2021-01-22T11:17:06.372+0000 reading metadata for edxapp.modulestore.definitions from archive 'BACKUP-2/rs0.gz'
2021-01-22T11:17:06.373+0000 restoring edxapp.modulestore.definitions from archive 'BACKUP-2/rs0.gz'
2021-01-22T11:17:06.387+0000 restoring to existing collection edxapp.fs.chunks without dropping
2021-01-22T11:17:06.387+0000 reading metadata for edxapp.fs.chunks from archive 'BACKUP-2/rs0.gz'
…
……
-
これで準備が整い、OpenedX構成ファイルにいくつかの変更を加えることができます。 。私のインストール設定では、/ edx / etc/studio.ymlと/edx/etc/lms.ymlを更新できます。 /edx/app/edxapp/lms.auth.jsonファイルと/edx/app/edxapp/cms.auth.jsonファイルのファイルも変更して、mongosインスタンスの正しいホスト名に置き換える必要がある場合があります。
-
mongosで確認し、データベースがロードされてアクセスできるかどうかを確認します。
[email protected]:~# mongo --host "mongodb://edxapp:[email protected]:27017/?authSource=admin"
MongoDB shell version v4.2.11
connecting to: mongodb://192.168.40.233:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("00a3a395-3531-4381-972e-502478af38d1") }
MongoDB server version: 4.2.11
mongos> show dbs
admin 0.000GB
config 0.002GB
cs_comments_service 0.000GB
edxapp 0.104GB
ClusterControlのWebビューでも、ClusterControlが展開を完了すると、次のようなトポロジが作成されます。
完了したら、OpenedXを管理して管理することができます。あなたのコース!