Pacemaker を運用していると、次のようなログを目にすることがあります。
notice: High CPU load detected info: New throttle mode debug: New job limit is 1
このログを初めて見たとき、「クラスタに異常が発生したのではないか」と不安に感じる方もいるかもしれません。しかし結論から言うと、これらのログは障害ではありません。クラスタノードの負荷が高くなったため、Pacemaker の 負荷保護機構 (スロットリング) が正常に動作したことを示すログです。
本記事では、Pacemaker の運用で頻繁に遭遇する負荷スロットリングについて、ログの意味を読み解きながら分かりやすく解説します。なお、本記事は Pacemaker 3.0.1 を前提としています。
前回の記事では、スプリットブレインの発生メカニズムおよび Pacemaker/Corosync におけるその対策について解説しました。
本記事では、スプリットブレイン対策の中でも、2 ノードクラスタにおけるクォーラム確立を支援する「クォーラムデバイス」に焦点を当て、その仕組みと基本的な使い方について紹介します。
システムを安定して稼働させるためには、冗長化構成が不可欠です。冗長化構成を採用することで、稼働系サーバに障害が発生してサービスが停止した場合でも、待機系サーバへ自動的に切り替えることができ、ダウンタイムを最小限に抑えられます。
一方で、冗長化によって単一障害点は解消できるものの、クラスタノード間の通信が途絶えた場合には「スプリットブレイン」状態に陥るリスクが残ります。スプリットブレインが発生すると、複数のノードが同時に稼働系として振る舞い、IP アドレスの競合やファイルシステムの二重マウントなどが発生する可能性があります。最悪の場合、データ破損といった深刻な障害につながる恐れもあります。
そのため、クラスタ構成を安定して運用するうえで、スプリットブレイン対策は欠かせないポイントです。
本記事では、Pacemaker/Corosync クラスタで広く利用されているスプリットブレイン対策の仕組みについて解説します。
Pacemaker/Corosync は、Linux 環境で高可用性クラスタを構築するためのオープンソースのクラスタリングソフトウェアです。複数ノードにまたがるリソースの起動、停止、監視を自動的に行い、障害発生時にはフェイルオーバーを実施することで、システムの継続稼働を実現します。
Pgpool-II は、PostgreSQL 専用のクラスタ管理ツールであり、コネクションプーリング、負荷分散、自動フェイルオーバーといった重要な機能を提供することで、PostgreSQL の高可用性と性能向上を実現します。
本記事では、性能向上やサーバリソースの効率的な活用に役立つコネクションプーリングの仕組みについて解説します。あわせて、運用時に押さえておくべき設定のポイントについても紹介します。
分散データベース YugabyteDB は、運用・管理の自動化機能やエンタープライズ向けのサポートが追加された有償版「YugabyteDB Aeon」以外にも、自動化機能やサポートがない代わりに、無償で利用できるオープンソースソフトウェア (OSS) 版も提供されています。
前回の記事では、YugabyteDB OSS版の使い方について紹介しました。
今回は有償版 YugabyteDB Aeon Self-Managed (旧 YugabyteDB Anywhere) の使い方について紹介します。
分散データベース YugabyteDB は、運用・管理の自動化機能やエンタープライズ向けのサポートが追加された有償版「YugabyteDB Aeon」以外にも、自動化機能やサポートがない代わりに、無償で利用できるオープンソースソフトウェア (OSS) 版も提供されています。
以前の記事では、YugabyteDB の概要、ユースケースおよび構成パターンについて紹介しました。
今回は、実際に YugabyteDB を使ってみたい方に向けて、OSS 版の使い方として以下について紹介します。
前回の記事では、分散データベース YugabyteDB のユースケースについて紹介しました。
YugabyteDB はオンプレミスやクラウドはもちろん、マルチクラウドやハイブリッドクラウドも含め、様々な環境に対応しております。また、YugabyteDB では構成パターンや構成オプションが多く用意されており、アプリケーション要件に応じて、柔軟に環境や構成を選ぶことができます。
前回の記事では、分散データベース YugabyteDB の概要や特長、アーキテクチャについて紹介しました。
RDBMS と NoSQL にはそれぞれの得意不得意がありますが、YugabyteDB はそれぞれの不得意な部分を補い、RDBMS と NoSQL の両方の特長を融合して設計されたデータベース技術です。YugabyteDB を使用することで、データの厳密な一貫性を保ちながら、水平方向スケーラビリティ、高可用性を実現できます。
YugabyteDB を導入する前に、YugabyteDB が適したユースケースを理解することが重要ですので、今回の記事では、YugabyteDB のユースケース、従来のデータベースソリューションとの使い分けのポイントについて紹介します。
クラウドネイティブの登場でアプリケーションのアーキテクチャが変化しており、その変化に追随するためにスケーラビリティ、高可用性、アジリティを備えたデータベースが求められるようになっています。長い歴史を持つ RDBMS は ACID 特性という概念に基づいて設計されており、データの一貫性が保証されていますが、拡張困難という弱点があります。一方、NoSQL はデータの一貫性を犠牲にすることで、水平方向拡張性や高い処理性能を実現しています。
RDBMS と NoSQL にはそれぞれの得意不得意がありますが、分散 SQL データベースはこのような拡張性と一貫性のトレードオフをなくし、RDBMS と NoSQL の両方の特長を融合して設計されたデータベース技術です。
現在様々な分散 SQL データベース製品が開発されていますが、その中で PostgreSQL および Cassandra との互換性を持つ、代表的なものとして YugabyteDB という製品があります。本記事では、YugabyteDB の概要、特長、アーキテクチャについて紹介します。