COVID-19の大流行の影響を受けて、多くの中小企業/中小企業がオンラインプラットフォームに移行しています。対面または物理的なクラスもこのパンデミックの影響を受けており、多くの学校や大学もオンラインに移行しており、教育のように生徒や生徒にサービスを提供し続けるために使用できるツールを探しています。邪魔されないように。教育的なオンラインまたはオンライン学習の目的で利用できる有名なプラットフォームの1つはMoodleです。
Moodleは、オンライン学習管理システム、またはGPLライセンスに基づくLMS（仮想学習環境またはVLEとも呼ばれます）用のオープンソースソフトウェアです。これにより、教育者は、いつでもどこでも学習を拡張する動的なコースで満たされた独自のプライベートWebサイトを作成できます。 Moodleは、教師、学生、または管理者が簡単にアクセスでき、機能を備えたすべてのサポートを備えています。
これはオープンソースであり、無料のソフトウェアプラットフォームであるため、他のオープンソースソフトウェアと同じように、このソフトウェアを無料で使用できます。このソフトウェアが有料ホスティングプラットフォームでホストされている場合、またはMoodleクラウドでホストしている場合にのみ費用が発生します。 Moodleは、モバイルやタブレットなどのハンドヘルドデバイスでも利用できます。
高可用性データベースが必要な理由
1990年代に、高可用性（HA）の非常にシンプルなソリューションであるHeartbeatが発明されました。ハートビートクラスターは、基本的に2つのことを実行できます。2つのノード（2つ以下）を監視し、それらの2つのノードで1つ以上のサービスを開始するように構成されました。現在リソースをホストしていたノードがダウンした場合、残りのノードでクラスターリソースを再起動しました。 Heartbeatの最初のリリースでは、リソース自体を監視していませんでしたが、2000年代初頭にHeartbeat 2.0がリリースされ、クラスターへの3つ以上のノードを管理できるようになるまで、この変更が行われました。基本的に、これは、Heartbeat2.0に大部分が基づいているLinuxHAクラスタリングの状態で構成されます。これ以降、多くのHAソリューションが影響を受け、特に重要なリソースのダウンタイムを最小限に抑えるために開発および作成されました。
高可用性は、ダウンタイムを最小限に抑えることを意味するだけではありません。また、提供し、顧客に約束したサービスを継続的に運用および維持できるようにする責任の程度についても説明します。顧客が利用できるということは、彼らが助けを必要とする場合にあなたが彼らに対応できるという意味でもありません。前例のない災害が発生した場合でも、ビジネスアプリケーションとシステムを常に通常の動作状態であるかのように完全に機能させる必要があります。
データベースのメンテナンス中は、Moodleを使用してVLEアプリケーションを操作することはできません。シンプルで軽量なアプリケーションのセットアップで非常に一般的なデータベースサーバーが1つしかない場合、サーバーがダウンすると、アプリケーションは停止します。マスタースレーブレプリケーションを使用するデータベースクラスターがある場合、前例のないインシデントが発生し、そのインシデントの後にアプリケーションが2つのマスターに書き込みを行うと、それは大きな混乱につながる可能性があり、ビジネスアプリケーション全体にデータの破損を引き起こします。データレイヤー。その時点で継続的な支払いが発生した場合、それは大きな災害になる可能性があり、データリカバリを実行する際に多大な作業が必要になります。
では、なぜデータベースの高可用性が必要なのですか？しなければならないからです
- メンテナンスまたは計画的な停止を実行可能に、許可されたメンテナンスウィンドウで実行できる
- 稼働時間は非常に重要であり、必要に応じてダウンタイムを回避する必要があります
- SLAは、高品質の顧客サービスを実現するための高度なレベルに関して重要です。
HAを計画として、またデータベースクラスター、特にPostgreSQLのソリューションとして持つことの重要性を強調したので、高可用性を実現するために、クラスターを上から下に構築することに焦点を当てましょう。 Moodleアプリケーションのセットアップの準備ができている利用可能なセットアップ。
PostgreSQLのインストール
まず、なぜPostgreSQLなのですか？ PostgreSQLには、Moodleでサポートされている他のデータベースと比較して大きな利点があります。 Moodleでサポートされているすべてのデータベースはすべてデータを処理でき、最適化の対象でもあるため、要約する必要があるかどうかは好みの問題です。それはあなたがデータベースをどれだけ熟練して経験しているかに依存します。 PostgreSQLを使用する理由を要約すると、PostgreSQLは信頼性の高いデータベースであり、特にOracleやMSSQLなどのプロプライエタリな他のベンダーと比較できるデータベースでの洗練されたオープンソースソフトウェアです。クエリの並列処理をサポートし、大規模または大規模なデータベースを管理でき、JSONを幅広くサポートします。 PostgreSQLを選択する理由については、ここで確認できます。それでは、PostgreSQLのインストールに進みましょう
このブログでは、Ubuntu 18.04（Bionic Beaver）を使用してPostgreSQL12を使用します。次に、高可用性のセットアップでは、マスターがダウンしたときに引き継ぐプライマリノードと少なくともスタンバイノード（レプリカ）が必要です。
- PG12サーバーをインストールします
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -これはターゲットレプリカでも実行しますが、スタンバイまたはレプリカとして構成する必要があります。または、ClusterControlを使用して、無料でダウンロードすることをお勧めします。プライマリ/スタンバイセットアップのインストールとセットアップがより速く、より速くなります。 ClusterControlと[トポロジビュー]タブを使用したセットアップでは、次のトポロジが得られました。
マスター/スレーブまたはプライマリ/スタンバイのセットアップがある場合、そうではありませんこれは、高可用性データベースクラスターを完全にカバーしていることを意味します。まだ高可用性はありません。プライマリまたはマスターがダウンすると、必ず発生するフェイルオーバーはありません。もう1つは、マスターに向かうクライアントからスレーブへの接続のバランスが取れていないことです。マスター/スレーブ間の負荷分散では、セットアップが必要なわけではありませんが、可用性の高いセットアップを実行するために適用する必要があります。マスター/プライマリとスレーブ/スタンバイの間に負荷分散を行うことで、マスターノードが特に非常に高いトラフィック時間で高い負荷パフォーマンスを強調するのを防ぐことができます。
前述のように、マスターとスレーブ間の負荷分散は、マスターが負荷を分離するのに役立ちます。スタンバイをレプリケーションのみに使用するか、マスターがダウンした場合に引き継ぐ場合は理想的ではありません。それは機能しますが、スタンバイノードの役割をマスターに切り替える必要があるため、マスターがダウンした場合はダウンタイムと手作業が必要になります。これも問題ありませんが、ロードバランサーがあると、書き込みをマスターに送信してから、マスターとスレーブの間で読み取りを送信するのに役立ちます。これは基本的に、読み取り/書き込み分割を提供します。これを行うために、PostgreSQLで選択できるオプションがたくさんあります。基本的に、最も一般的でありながらシンプルなセットアップであり、軽量であるのはHAProxyを使用することです。
ただし、PgBouncerやpgpool-IIの使用などのオプションがあります。このブログを簡単にするために、HAProxyを使用しましょう。 ClusterControlを使用すると、HAProxyをインストールするのは非常に簡単です。 ClusterControlを介してそれを行いましょう。これを行うには、[管理]タブに移動し、以下に示すように[ロードバランサー]を選択します。
PostgreSQLデータベースクラスターの高可用性セットアップが必要なため、少なくとも2つのノードが必要です。したがって、プライマリHAProxyノードがダウンした場合、パッシブまたはスタンバイHAProxyが引き継ぐことができます。私の側ではどのように見えるか見てみましょう
それは良さそうですが。この設定はまだ不十分です。そのトポロジで高可用性のセットアップに適していると思われる場合、HAProxyがポート9600のノード192.168.30.222でダウンした場合、または192.168.30.223:9600がダウンした場合、およびアプリケーションがそのようにセットアップされている場合、フェイルオーバーはありません。ホスト、プロアクティブなセットアップが行われていない場合でもダウンタイムがあります。つまり、手動でセットアップする必要がある場合は、ダウンタイムが発生します。この場合、他のノードで問題が発生した場合にHAProxyインスタンスの正常性とフェイルオーバーを綿密に監視するために、Keepalivedを使用してセットアップします。
データベースの上にロードバランサーがありますが、アプリケーションエンドポイントのプライマリノードがダウンした場合に備えて、HAProxyが常に稼働している必要があります。基本的に、前のセクションのセットアップでHAProxyが実行できることは、アプリケーションが192.168.30.223または192.168.30.222をそれぞれポート5433（読み取り/書き込みポート）および5434（読み取り専用ポート）で使用できることです。これで、他のノードがダウンした場合に切り替える必要がある場合に手間がかかります。さらに、それに対処する自動フェイルオーバーがない場合、ダウンタイムをカバーするため、ビジネスに悪影響を及ぼします。 SLAが非常に低く、RTOとRPOが高い場合を除いて、ここではダウンタイムを回避することが最善の方法です。
このような災害やダウンタイムを軽減するために、HAProxyの上にKeepalivedを設定することをお勧めします。基本的に、HAProxyは読み取りと書き込みの負荷分散を行い、読み取りと書き込みの分割を提供します。Keepalivedは、HAProxyノードの状態のみを監視し、目的の構成に従って最も正常なノードを選択します。 Keepalivedは、HAProxyノードを監視するために使用できるツールですが、データベースの管理はそれほど複雑ではありません。 KeepalivedはVIP（仮想IP）を使用して、デフォルトのプライマリHAProxyノードに割り当て、プライマリHAProxyノードに障害が発生した場合にそのVIPを再割り当てし、後続またはスタンバイHAProxyノードをポイントします。
ClusterControlを使用すると、より高速で簡単に管理できるため、ClusterControlを使用してこれを設定しましょう。これを行うには、基本的にHAProxyの設定方法と同じアプローチですが、代わりに以下に示すようにキープアライブを選択します。
基本的に、Keepalivedを手動でインストールする場合は、プライマリを選択します。プライマリHAProxyに障害が発生した場合のセカンダリ。トポロジビューがどのように表示されるかを見てみましょう。
これは非常に有望に見えるかもしれません。基本的に、Moodleアプリケーションクライアントは、ポート5433（読み取り/書き込みポート）および5434（読み取り専用ポート）でVIP、つまり192.168.30.201に接続します。たとえば、私が持っている外部ホストでそれを確認します。
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)これは、私が持っているライターノードのみがマスターノード、つまり192.168.30.22を指していることを示しています。次に、読み取り専用ポートは、以下に示すように、マスターノードとスレーブノードの両方に接続する必要があります。
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)これにより、プライマリノードとスタンバイノードの両方が「データベースの読み取り」ノードとして識別されていることがわかります。
これは、私が以前に言ったことと同じように、非常に有望に見えます。それでも、実際には非常に重要な部分が欠けている部分があります。このタイプのセットアップに対応できるデータベースフェイルオーバーメカニズムはありません。それでも、HAProxyを監視し、プライマリHAProxyに障害が発生したり停止したりした場合に備えて、VIPを切り替えることでフェイルオーバーを実行するKeepalivedがあります。ただし、Keepalivedは、PostgreSQLのような複雑なセットアップを処理するようにセットアップされていません。非常にまともなものがあり、これを自由に設定できます。サードパーティのレプリケーションシステムであるSlony-Iを使用できます。
PostgreSQLクラスターのフェイルオーバーメカニズムを備えている
PostgreSQLにフェイルオーバーメカニズムを提供する方法があります。 Slony-Iまたは一般にSlonyと呼ばれるものは、使用される一般的なツールの1つです。 Slonyでは、パブリッシャー/サブスクライバーのセットアップが必要なため、セットアップを論理レプリケーションにする必要がありますが、標準のストリーミングレプリケーションを使用している他のセットアップには理想的ではない場合があります。 Slonyを使用することの欠点は、障害が発生したシステムの自動検出が提供されないこと、またはノードフェンシングがサポートされないことです。したがって、一般的に呼ばれるSTONITH（頭の中で他のノードを撃つか、頭の中で失敗したノードを撃つ）は、基本的に、複数のマスターノード（アクティブなライターノード）が書き込みを受け入れるスプリットブレインシナリオを回避しないように失敗をノックオフします同時。これは適切に設定できますが、災害が発生したときにPostgreSQLでどのようなシナリオが発生するかについての経験と洞察が少ない状態で作成すると、時間がかかり複雑になる可能性があります。 Slonyにとって、コミットされたトランザクションを放棄することは、データベースシステムでは実行できないビジネス上の決定です。誰かが以下のコマンドをネットワーク監視システムから自動的に実行されるスクリプトに入れたい場合、それはあなたのデータであり、それはあなたのフェイルオーバーポリシーです。
または、エンタープライズオプションを探していても、妥当な費用でお金を稼ぐことができる場合は、ClusterControlにPostgreSQLクラスターの自動回復機能があります。基本的に、自動回復は上記のSlonyの問題に答えます。自動リカバリはストリーミングレプリケーションで最もよくテストされており、PostgreSQLセットアップのストリーミングレプリケーションタイプでのみサポートされています。それで、それはどのように機能しますか？基本的には、以下のように自動回復ボタンをオンにするだけです。
これはノードフェンシングをサポートします。つまり、障害が発生したノードをノックオフします。予期しない何らかの理由でノードが生き返ります。それとは別に、ClusterControlによる自動リカバリは、ノードとクラスタのリカバリをサポートします。マスターノードまたはスレーブノードが誤ってシャットダウンまたは強制終了された場合、ClusterControlは、特に計画された停止またはメンテナンスウィンドウの外で発生した場合に、それを復活させようとします。この機能は、データベースの恐怖を使い果たしてしまうことを防ぎ、同時に、回復するには手遅れになる前に発生する可能性のある災害を通知するプロアクティブな監視を提供します。
データベースクラスター、特にMoodleの高可用性セットアップは、必要なセットアップのタイプと要件によって異なります。純粋に無料のオープンソーステクノロジーに依存している場合でも、予算に対応できる限り、エンタープライズアプリケーションに投資する価値のある他のオプションがある場合でも、特に焦点を絞りたい場合にのみ、Win-Winの状況を提供できます。管理やDevOpsタイプの作業などの他のツールに焦点を当てるよりも、ビジネスの側面で。