エンタープライズ向け分散 DBMS

CAP 定理は分散システム理論の基礎です。 もちろん、この定理をめぐる論争は収まりません。その定義は標準的ではなく、厳密な証明もありません。それでも、日常の常識™ の立場にしっかりと立つと、私たちは定理が正しいことを直感的に理解します。

明らかではない唯一のことは、文字「P」の意味です。 クラスターが分割されると、クォーラムに達するまで応答しないか、使用可能なデータを返すかを決定します。 この選択の結果に応じて、システムは CP または AP のいずれかに分類されます。 たとえば、Cassandra は、クラスター設定ではなく、それぞれの特定のリクエストのパラメーターに応じて、どちらの方法でも動作できます。 しかし、システムが「P」ではなく、分割した場合はどうなるでしょうか?

この質問に対する答えは少々予想外です。CA クラスターは分割できません。
この分割できないクラスターは何ですか?

このようなクラスターに不可欠な属性は、共有データ ストレージ システムです。 ほとんどの場合、これは SAN 経由で接続することを意味するため、CA ソリューションの使用は SAN インフラストラクチャを維持できる大企業に限定されます。 複数のサーバーが同じデータを処理するには、クラスター化されたファイル システムが必要です。 このようなファイル システムは、HPE (CFS)、Veritas (VxCFS)、IBM (GPFS) のポートフォリオで利用できます。

Oracle RAC

Real Application Cluster オプションは、2001 年の Oracle 9i のリリースで初めて登場しました。 このようなクラスターでは、複数のサーバー インスタンスが同じデータベースを操作します。
Oracle は、クラスタ化されたファイル システムと独自のソリューションである ASM (自動ストレージ管理) の両方を使用できます。

各コピーは独自のジャーナルを保持します。 トランザクションは XNUMX つのインスタンスによって実行およびコミットされます。 インスタンスに障害が発生した場合、生き残っているクラスター ノード (インスタンス) の XNUMX つがそのログを読み取り、失われたデータを復元することで、可用性が確保されます。

すべてのインスタンスは独自のキャッシュを維持し、同じページ (ブロック) が複数のインスタンスのキャッシュに同時に存在することができます。 さらに、あるインスタンスがページを必要とし、それが別のインスタンスのキャッシュ内にある場合、ディスクから読み取る代わりに、キャッシュ融合メカニズムを使用して隣接するインスタンスからページを取得できます。

しかし、インスタンスの XNUMX つでデータを変更する必要がある場合はどうなるでしょうか?

Oracle の特徴は、専用のロック サービスがないことです。サーバーが行をロックしたい場合、ロック レコードは、ロックされた行が配置されているメモリ ページに直接配置されます。 このアプローチのおかげで、Oracle はモノリシック データベースの中でパフォーマンスのチャンピオンとなり、ロック サービスがボトルネックになることはありません。 しかし、クラスタ構成では、このようなアーキテクチャはネットワーク トラフィックの集中やデッドロックを引き起こす可能性があります。

レコードがロックされると、インスタンスは他のすべてのインスタンスに、そのレコードを格納するページに排他的保持があることを通知します。 別のインスタンスが同じページ上のレコードを変更する必要がある場合、ページへの変更がコミットされるまで、つまり、変更情報がディスク上のジャーナルに書き込まれるまで待機する必要があります (トランザクションは続行できます)。 また、ページが複数のコピーによって順次変更される場合もあり、その場合、ページをディスクに書き込むときに、このページの現在のバージョンを誰が保存しているかを調べる必要があります。

異なる RAC ノード間で同じページをランダムに更新すると、データベースのパフォーマンスが大幅に低下し、クラスターのパフォーマンスが単一インスタンスのパフォーマンスよりも低くなる可能性があります。

Oracle RAC の正しい使用法は、データを物理的に分割し (たとえば、パーティション表メカニズムを使用して)、専用ノードを介して各パーティションのセットにアクセスすることです。 RAC の主な目的は水平スケーリングではなく、フォールト トレランスを確保することでした。

ノードがハートビートに応答しなくなった場合、最初にハートビートを検出したノードがディスク上で投票手順を開始します。 欠落しているノードがここに記載されていない場合は、ノードの XNUMX つがデータ回復の責任を負います。

• 失われたノードのキャッシュにあったすべてのページを「凍結」します。
• 欠落しているノードのログを読み取り (やり直し)、これらのログに記録された変更を再適用し、同時に他のノードに変更中のページのより新しいバージョンがあるかどうかを確認します。
• 保留中のトランザクションをロールバックします。

ノード間の切り替えを簡素化するために、Oracle にはサービス、つまり仮想インスタンスという概念があります。 インスタンスは複数のサービスを提供でき、サービスはノード間を移動できます。 データベースの特定の部分 (クライアントのグループなど) にサービスを提供するアプリケーション インスタンスは XNUMX つのサービスで動作し、ノードに障害が発生すると、データベースのこの部分を担当するサービスは別のノードに移動します。

IBM Pure Data Systems for Transactions

DBMS 用のクラスター ソリューションは、2009 年に Blue Giant ポートフォリオに登場しました。 イデオロギー的には、これは「通常の」装置上に構築された並列シスプレックス クラスターの後継です。 2009 年に DB2 pureScale がソフトウェア スイートとしてリリースされ、2012 年に IBM は Pure Data Systems for Transactions と呼ばれるアプライアンスを提供しました。 Netezza の名前が変更されたものにすぎない Pure Data Systems for Analytics と混同しないでください。

一見すると、pureScale アーキテクチャは Oracle RAC に似ています。同様に、複数のノードが共通のデータ ストレージ システムに接続されており、各ノードは独自のメモリ領域とトランザクション ログを持つ独自の DBMS インスタンスを実行します。 ただし、Oracle とは異なり、DB2 には一連の db2LLM* プロセスで表される専用のロック サービスがあります。 クラスター構成では、このサービスは別のノードに配置されます。これは、Parallel Sysplex ではカップリング・ファシリティー (CF)、Pure Data では PowerHA と呼ばれます。

PowerHA は次のサービスを提供します。

• ロックマネージャー。
• グローバルバッファキャッシュ。
• プロセス間通信の領域。

PowerHA からデータベース ノードにデータを転送したり、その逆にデータを転送するには、リモート メモリ アクセスが使用されるため、クラスター インターコネクトは RDMA プロトコルをサポートする必要があります。 PureScale は、Infiniband と RDMA over Ethernet の両方を使用できます。

ノードがページを必要とし、このページがキャッシュにない場合、ノードはグローバル キャッシュ内のページを要求し、ページが存在しない場合にのみディスクから読み取ります。 Oracle とは異なり、リクエストは PowerHA にのみ送信され、隣接ノードには送信されません。

インスタンスが行を変更しようとしている場合、その行は排他モードでロックされ、行が配置されているページは共有モードでロックされます。 すべてのロックはグローバル ロック マネージャーに登録されます。 トランザクションが完了すると、ノードはロック マネージャーにメッセージを送信します。ロック マネージャーは、変更されたページをグローバル キャッシュにコピーし、ロックを解放し、他のノードのキャッシュ内の変更されたページを無効にします。

変更された行が配置されているページがすでにロックされている場合、ロック マネージャーは、変更を行ったノードのメモリから変更されたページを読み取り、ロックを解放し、他のノードのキャッシュ内の変更されたページを無効にし、ページ ロックを要求したノードにページ ロックを与えます。

「ダーティ」、つまり変更されたページは、通常のノードと PowerHA (キャストアウト) の両方からディスクに書き込むことができます。

pureScale ノードの XNUMX つで障害が発生した場合、リカバリーは障害時にまだ完了していなかったトランザクションのみに限定されます。完了したトランザクション内でそのノードによって変更されたページは、PowerHA 上のグローバル キャッシュ内にあります。 ノードはクラスター内のサーバーの XNUMX つで縮小構成で再起動し、保留中のトランザクションをロールバックしてロックを解放します。

PowerHA は XNUMX つのサーバー上で実行され、マスター ノードはその状態を同期的に複製します。 プライマリ PowerHA ノードに障害が発生した場合でも、クラスターはバックアップ ノードで動作を継続します。
もちろん、単一ノードを通じてデータ セットにアクセスすると、クラスターの全体的なパフォーマンスが高くなります。 PureScale は、データの特定の領域が XNUMX つのノードによって処理されていることを認識することもでき、その領域に関連するすべてのロックは、PowerHA と通信せずにノードによってローカルに処理されます。 ただし、アプリケーションが別のノードを介してこのデータにアクセスしようとするとすぐに、集中ロック処理が再開されます。

実際の実稼働ワークロードと非常によく似た、読み取り 90%、書き込み 10% のワークロードに対する IBM の内部テストでは、128 ノードまでほぼ線形に拡張できることが示されています。 残念ながら、テスト条件は非公開です。

HPE ノンストップ SQL

Hewlett-Packard Enterprise ポートフォリオには、独自の高可用性プラットフォームもあります。 これは、Tandem Computers によって 1976 年に市場にリリースされた NonStop プラットフォームです。 1997 年に同社は Compaq に買収され、その後 2002 年に Hewlett-Packard と合併しました。

NonStop は、HLR や銀行カード処理などの重要なアプリケーションを構築するために使用されます。 このプラットフォームは、コンピューティング ノード、データ ストレージ システム、通信機器を含むソフトウェアとハ​​ードウェアの複合体 (アプライアンス) の形で提供されます。 ServerNet ネットワーク (最新のシステムでは、Infiniband) は、ノード間の交換とデータ ストレージ システムへのアクセスの両方に役立ちます。

システムの初期のバージョンでは、相互に同期された独自のプロセッサが使用されていました。すべての操作は複数のプロセッサによって同期的に実行され、プロセッサの 86 つでエラーが発生するとすぐにプロセッサがオフになり、XNUMX 番目のプロセッサは動作を続けました。 その後、システムは従来のプロセッサ (最初は MIPS、次に Itanium、最後に xXNUMX) に切り替わり、同期には他のメカニズムが使用され始めました。

• メッセージ: 各システム プロセスには「シャドウ」ツインがあり、アクティブ プロセスはそのステータスに関するメッセージを定期的に送信します。 メインプロセスが失敗した場合、最後のメッセージによって決定された瞬間からシャドウプロセスが動作を開始します。
• 投票: ストレージ システムには、複数の同一のアクセスを受け入れ、アクセスが一致する場合にのみそれらのアクセスを実行する特別なハードウェア コンポーネントがあります。 物理的な同期の代わりに、プロセッサは非同期で動作し、その作業結果は I/O の瞬間にのみ比較されます。

1987 年以来、リレーショナル DBMS は NonStop プラットフォーム (最初は SQL/MP、その後は SQL/MX) 上で実行されてきました。

データベース全体はいくつかの部分に分割されており、各部分は独自のデータ アクセス マネージャー (DAM) プロセスを担当します。 データの記録、キャッシュ、ロックのメカニズムを提供します。 データ処理は、対応するデータ マネージャーと同じノード上で実行される Executor Server プロセスによって実行されます。 SQL/MX スケジューラはタスクを実行者間で分割し、結果を集計します。 合意された変更を行う必要がある場合は、TMF (トランザクション管理機能) ライブラリによって提供される XNUMX フェーズ コミット プロトコルが使用されます。

NonStop SQL は、長い分析クエリがトランザクションの実行を妨げないように、プロセスに優先順位を付けることができます。 ただし、その目的はまさに短期トランザクションの処理であり、分析ではありません。 開発者は、NonStop クラスターの可用性を 5 の XNUMX レベル、つまりダウンタイムが年間わずか XNUMX 分であることを保証します。

SAP HANA

HANA DBMS (1.0) の最初の安定リリースは 2010 年 2013 月に行われ、SAP ERP パッケージは XNUMX 年 XNUMX 月に HANA に切り替わりました。 このプラットフォームは、購入したテクノロジーである TREX 検索エンジン (カラム型ストレージでの検索)、P*TIME DBMS、および MAX DB に基づいています。

「HANA」という言葉自体は、High Performance ANalytical Appliance の頭字語です。 この DBMS は、任意の x86 サーバー上で実行できるコードの形式で提供されますが、産業用の設置は認定された装置上でのみ許可されます。 HP、Lenovo、Cisco、Dell、富士通、日立、NEC からソリューションを入手できます。 一部の Lenovo 構成では、SAN なしでの運用も可能です。共通ストレージ システムの役割は、ローカル ディスク上の GPFS クラスターによって実行されます。

上記のプラットフォームとは異なり、HANA はインメモリ DBMS です。つまり、プライマリ データ イメージは RAM に保存され、災害時の回復のためにログと定期的なスナップショットのみがディスクに書き込まれます。

各 HANA クラスター ノードはデータの独自の部分を担当し、データ マップはコーディネーター ノード上にある特別なコンポーネントであるネーム サーバーに保存されます。 ノード間でデータが重複することはありません。 ロック情報も各ノードに保存されますが、システムにはグローバルなデッドロック検出機能が備わっています。

HANA クライアントがクラスターに接続すると、そのトポロジがダウンロードされ、必要なデータに応じて任意のノードに直接アクセスできます。 トランザクションが単一ノードのデータに影響を与える場合、そのトランザクションはそのノードによってローカルに実行できますが、複数のノードのデータが変更された場合、開始ノードはコーディネーター ノードに接続し、コーディネーター ノードが分散トランザクションを開いて調整し、最適化された XNUMX フェーズ コミット プロトコル。

コーディネーター ノードは複製されているため、コーディネーターに障害が発生した場合は、バックアップ ノードがすぐに引き継ぎます。 ただし、データのあるノードに障害が発生した場合、そのデータにアクセスする唯一の方法はノードを再起動することです。 原則として、HANA クラスターは、失われたノードをできるだけ早く再起動するために予備サーバーを維持します。

出所： habr.com