IBM zEnterprise EC 12メインフレーム上でActive-Activeを実行する地理的に分散したアクティブフェールオーバークラスター

人間の活動の多くの領域では、情報技術によって提供されるサービスのパフォーマンスとアクセシビリティにますます多くの要求が置かれています。 そのような領域の例は、たとえば銀行業です。 国内の大手銀行が数時間のカード処理を拒否した場合、これは全国の数百万人のユーザーの日々のニーズと懸念に影響を与え、そのような信用機関のサービスを拒否する決定が下されるまで忠誠心の低下につながります。 この状況は、他の多くの情報システムのパフォーマンスと可用性と似ています。



パフォーマンスと可用性に関する問題の解決策は、原則として既知です。データ処理を提供するノードを複製し、それらをクラスターに結合します。 同時に、利用可能なリソースの最大負荷を確保し、ノードの1つに障害が発生した場合のシステムのダウンタイムを削減するために、クラスターはActive-Activeスキームに従って動作する必要があります。 また、1つのデータセンターに完全に配置されたクラスターによって提供されるアクセシビリティのレベルは、不十分な場合があります（たとえば、大都市の全域で停電中）。 次に、クラスタノードを地理的に分散する必要があります。



この記事では、フォールトトレラントな地理的に分散したクラスターの構築の問題とメインフレームに基づいてIBMが提供するソリューションについて説明し、ノードが最大70 km間隔のクラスター構成での実際の銀行業務アプリケーションのパフォーマンスと高可用性のテスト結果を共有します。

Active-Activeスキームに従って動作する地理的に分散したクラスターを構築する際の問題

従来、アクティブ/アクティブクラスターを構築する際の問題は、アプリケーションのクラスタリングの問題と、DBMS /メッセージキューサブシステムのクラスタリングの問題に分けることができます。 たとえば、テストしたアプリケーションの場合、1人の参加者からの支払い実行手順を厳守する必要がありました。 Active-Activeクラスターモードでこの要件が満たされるようにすると、アプリケーションアーキテクチャに大幅な変更が必要になることは明らかです。 この問題は、アクティブ/アクティブモードでのパフォーマンスに加えて、標準ミドルウェアまたはオペレーティングシステムソフトウェアの高可用性を確保する必要があるという事実によって悪化しました。 目標をどのように達成したかの詳細は、別の記事に値します。



DBMSのクラスタリングに対する最新のアプローチは、通常、共有ディスクアーキテクチャに基づいています。 このアプローチの主な目的は、共有データへの同期アクセスを提供することです。 実装の詳細は特定のDBMSに大きく依存しますが、最も一般的なアプローチはクラスターノード間のメッセージ交換に基づいています。 このソリューションは純粋にソフトウェアであり、メッセージの送受信にはアプリケーションの中断（オペレーティングシステムのネットワークスタックへのアクセス）が必要であり、共有データへのアクティブなアクセスではオーバーヘッドが大きくなる可能性があり、これは特にアクティブなノード間の距離が長くなると顕著になります。 原則として、このようなソリューションのスケーラビリティ係数は3/4を超えません（各ノードの容量がNである4つのノードのクラスターは、3/4 Nの合計パフォーマンスを提供します）。



クラスターノードが互いに離れている場合、距離はソリューションのパフォーマンスと許容回復時間（RTO）に大きな影響を与えます。 ご存知のように、光学系の光の速度は約200,000 km / sであり、これは光ファイバー1キロメートルあたり10μsの遅延に相当します。

IBMメインフレームアプローチ

IBMメインフレームは、DB2 DBMSとWebSphere MQキューマネージャーをクラスタリングするために、クラスターノード間のプログラムメッセージングに基づいていない異なるアプローチを使用します。 このソリューションはParallel Sysplexと呼ばれ、z / OSオペレーティングシステムを実行する1つ以上のメインフレームで実行される最大32の論理パーティション（LPAR）をクラスター化できます。 新しいz13メインフレームには140を超えるプロセッサーを搭載できるため、達成可能な最大のクラスターパフォーマンスが印象的です。



パラレルシスプレックスの基礎は、特別なクラスターソフトウェアを実行できるプロセッサーを使用する専用論理パーティション（LPAR）であるカップリングファシリティテクノロジー （カップリングファシリティ制御コード（CFCC））です。 メモリー内のカップリング・ファシリティーは、並列シスプレックス・クラスターのノードによって共有される共有データ構造を保管します。 CFと接続システム間のデータ交換は、「メモリとメモリ」（DMAに類似）の原則に基づいて編成されますが、アプリケーションを実行するプロセッサは関与しません。



CF構造の高可用性を確保するために、z / OSオペレーティングシステムとDB2 DBMSを使用して、それらの間で同期および非同期のデータレプリケーションメカニズムが使用されます。



つまり IBMのアプローチは、ソフトウェアではなく、実行中のアプリケーションを中断することなくクラスターノード間のデータ交換を提供するハードウェアとソフトウェアのソリューションに基づいています。 したがって、 ユニティに近いスケーラビリティ係数が達成されます。これは、負荷テストの結果によって確認されます。

クラスター負荷テスト

システムのスケーラビリティを実証し、距離がパフォーマンスインジケータに与える影響を評価するために、一連のテストを実施しました。その結果を共有します。



単一のzEnterprise EC 12物理サーバーをテストベンチとして使用し、2台の論理パーティション（LPAR）MVC1およびMVC2をこのサーバーにデプロイし、それぞれz / OS 2.1オペレーティングシステムを実行し、5つの汎用プロセッサー（CP ）およびDB2 DBMSコードを実行し、Javaアプリケーションを実行するように設計された5つの専用zIIPプロセッサー。 これらの論理パーティションは、Parallel Sysplexメカニズムを使用してクラスター化されました。



カップリング・ファシリティー・メカニズムの操作には、それぞれ2つのICFプロセッサーを含む専用論理区画（LPAR）CF1およびCF2が使用されました。 テストシナリオによる通信チャネル上のCF1とCF2間の距離は、0〜70 kmの範囲で離散的に変化しました。



MVC1はICPタイプの仮想チャネルを介してCF1に接続され、Infinibandタイプの物理チャネルはCF2にアクセスするために使用されました。 MVC2をCF1およびCF2に接続する方法は同じで、ICPチャンネルを介してCF2に接続し、InfinibandをCF1に使用しました。



データストレージには、IBM DS 8870ディスクアレイが使用され、2セットのディスクが作成され、Metro Mirrorテクノロジーを使用してディスク間の同期データレプリケーションが設定されました。 テストシナリオによる通信チャネル上のディスクセット間の距離は、0〜70 kmの範囲で離散的に変化しました。 スタンドのコンポーネント間の必要な距離は、専用のDWDMデバイス（ADVA）と必要な長さの光ファイバーケーブルを使用して提供されました。



論理パーティションMVC1およびMVC2のそれぞれは、2つのFICONチャネルを使用して、8 GB / sのスループットでディスクアレイに接続されました。



スタンドの詳細図（クラスターノード間の距離が50 kmのバージョン）。図に示されています。







テストアプリケーションとして、DB2 z / OS DBMS、WebSphere MQメッセージキューマネージャー、WebSphere Application Server for z / OSアプリケーションサーバーを使用して、 銀行支払いシステムがクラスターノードに展開されました。



テストスタンドのセットアップと支払いシステムのインストールには約3週間かかりました。



それとは別に、アプリケーションの原理と負荷プロファイルについて話す必要があります。 処理された支払いはすべて、緊急と非緊急の2つのタイプに分類できます。 緊急の支払いは、入力キューから読み取られた直後に行われます。 緊急でない支払いを処理するプロセスでは、3つの連続したフェーズを区別できます。 最初のフェーズ- 受信フェーズ -支払いはシステムの入力キューから読み取られ、データベースに登録されます。 2番目のフェーズ（多国間オフセットのフェーズ）は 、タイマーで1日に数回実行され、厳密にシングルスレッドモードで実行されます。 この段階では、受け入れられたすべての緊急ではない支払いが転記されますが、システム参加者の相互の義務が考慮されます（Petyaが500ルーブルをVasyaに転送し、300ルーブルをSvetaに転送し、Vasyaが300ルーブルをSvetaに転送する場合、Svetaのアカウントの価値をすぐに600ルーブル増加することは理にかなっていますとVasya-実際の取引を行うよりも200ルーブル）。 3番目のフェーズ- 通知配布フェーズ -は、2番目のフェーズの完了後に自動的に開始されます。 このフェーズでは、多国間ネッティングに関係するすべてのアカウントに対して情報メッセージ（領収書）の形成と配信が実行されます。 各フェーズは、1つ以上のグローバルトランザクションを表します。これは、WebSphere MQキューマネージャーとDB2 DBMSによって実行される複雑な一連のアクションです。 各グローバルトランザクションは、2フェーズコミット（コミット）で終了します。 複数のリソースがそれに参加します（キュー-データベース-キュー）。



支払いシステムの重要な特徴は、多国間ネッティングを背景に緊急支払いを行う能力です。

テスト中の負荷プロファイルは、実際に動作しているシステムの負荷プロファイルを繰り返しました。 500/1000/5000の支払いのパッケージにまとめられた200万件の緊急でない支払いが入り口に送られ、各パッケージが1つの電子メッセージに対応しました。 これらのパケットは、後続の各メッセージ間で4ミリ秒の間隔でシステム入力に送られました。 同時に、約1万6千件の緊急の支払いが提出されました。それぞれの支払いは、独自の電子メッセージに対応していました。 これらの電子メッセージは10ミリ秒間隔で送信されました。 後続の各メッセージ間。

ストレステスト結果

負荷テスト中、ディスクのセット間およびCFの論理パーティション間の通信チャネルに沿った距離は、0〜70 kmの範囲で離散的に変化しました。 テストを実行すると、次の結果が記録されました。







システムのスケーラビリティを示す最初の2行を比較するのは興味深いことです。 2つのノードのクラスターを使用する場合の第1フェーズの実行時間は1.4倍短縮されます（第1フェーズのスケーリングの「非線形性」は、1人の参加者からの支払い注文に従う要件の実装の特性によって説明されます）、第3フェーズの実行時間はほぼ2倍です。 多国間ネッティングは1つのスレッドで実行されます。 バルクDML操作を実行するときにDB2ロックをCFに転送する必要があるため、クラスターモードでの実行にかかる時間は増加します。



ディスク上のデータレプリケーションのメカニズム（メトロミラー）を有効にすると、各フェーズの実行時間がわずかに3〜4％増加します。 ディスク間および論理パーティションCF間の通信チャネルに沿った距離がさらに増加すると、各フェーズの実行時間がより集中的に増加します。



極端な場合の緊急支払いの処理の時間的特性を比較することは興味深いです：クラスターなしと、ノードが70 km離れているクラスターで。







最大支払い処理時間は40％増加しましたが、平均は7.6％しか変化しませんでした。 同時に、CF構造へのアクセス時間の増加により、プロセッサリソースの使用率がわずかに変化します。

結論

この記事では、Active-Activeモードで動作する地理的に分散したクラスターを構築する際に発生する問題を調査し、IBMメインフレームに基づいてクラスターを構築することでそれらを回避する方法を見つけました。 並列シスプレックスクラスターに基づくソリューションの高いスケーラビリティに関する記述は、負荷テストの結果によって実証されています。 同時に、クラスターノード間の異なる距離（0、20、50、および70 km）でのシステムの動作を確認しました。



最も興味深い結果は、1に近いシステムスケーラビリティ係数と、クラスターノード間の距離に対する支払い処理時間の依存性が明らかになったことです。 距離が短くなると、システムの主要なパフォーマンスインジケータに影響が及ぶほど、クラスターノードが互いに離れることができるため、耐障害性が向上します。



メインフレームの地理的に分散したクラスターを構築するトピックが行商人の間で関心を引く場合、次の記事でシステムの高可用性のテストと得られた結果を詳細に説明します。 メインフレームに関する他の質問に興味がある場合、または単に議論したい場合は、コメントを歓迎します。 また、誰かがフォールトトレラントソリューションを構築した経験を共有する場合にも役立ちます。