1

通常、QMGR を回復するには 2 つの方法があります。1つはbackup and restore QMGR data&log、もう1つは ですcreate backup QMGR。私の質問は、QMGR の回復状況に適しているのはどれですか? それとも、両方に独自の使用シナリオがありますか? これに答えるのを手伝ってください。

ありがとう

4

1 に答える 1

1

正確には何からの回復ですか？目標復旧時間または目標復旧時点は? 最適な回答は、これらの要件と、アプリケーションの作成方法によって異なります。アーキテクチャの観点からの最善の方法は、メッセージングをトランスポートのように扱うことです。ネットワーク ルーターをバックアップする場合、たまたまルーター上で処理中のメッセージをバックアップするのではなく、ルーターの構成をバックアップするだけです。キュー マネージャーでも同じことが言えます。オブジェクト定義、承認、ini ファイル、exit および exit parms をバックアップすると、QMgr の空のバージョンを再作成して、古いものを中断したところから再開できます。

残念ながら、ほとんどのアプリケーションは、メッセージング レイヤーがトランスポートではなくデータベースであるかのように設計されています。これは、ダウンした QMgr からメッセージを回復したいということです。それがBackup QMgrの用途です。それが機能する方法は、プライマリ QMgr がリニア ログ ファイルを使用することです。時間の経過とともに、アクティブなログ ファイルが進み、復元に不要になった古いファイルがログ セットの最後に「ロールオフ」されます。これらのファイルは、バックアップ QMgr が存在し、適用される場所に出荷されます。バックアップ QMgr には、そのログ ファイルが最後にアクティブだったときにキューにあったメッセージの正確なコピーが含まれます。

1 次キュー・マネージャー上のメッセージとバックアップ・キュー・マネージャー上のメッセージの間には常にラグがあり、このラグは、1 次および 2 次のアクティブ・ログ・エクステントによって消費されるスペースによって表されます。プライマリおよびセカンダリ ログ エクステントのサイズと数を小さくしておくと、フェールオーバーで失われるメッセージの数を最小限に抑えることができます。この方法ではリカバリ ポイントをゼロにすることはできませんが、ポイント イン タイム バックアップよりもはるかに優れています。

これは、あなたが言及した他のバックアップ方法論につながります。ポイント イン タイム バックアップ (QMgr のキューとログ ファイルのバックアップ) は、QMgr の実行中にバックアップが作成されると機能しません。ビジーな QMgr では、ログとキューは常に書き込まれ、同期している必要があります。ただし、アクティブな状態でこれらのファイルをバックアップすると、バックアップされたログがバックアップされたキューと同期されないことがほぼ保証されます。破損したキューで QMgr が復元されるか、復元後に QMgr が起動しなくなる可能性があります。

このバックアップ戦略が機能するのは、QMgr が停止している場合のみであり、アクティブなシステムではなく、アップグレード後の回復オプションとして最適に使用されます。たとえば、有効なポイント イン タイム バックアップを日曜日の午前 1 時に行ったとします。その後、平日に誰かが QMgr の下からキュー ファイルを削除し、復元する必要があります。ログとの同期が取れず、破損したオブジェクトとして表示されるため、onbe ファイルの復元は機能しません。QMgr 全体を復元する必要があります。返されるのは、先週の日曜日の午前 1 時にすべてのキューにあったすべてのメッセージです。さらに悪いことに、QMgr がクラスターに参加している場合、QMgr を以前の時点に復元すると、クラスター コマンド メッセージのシーケンス番号がリセットされます。QMgr が復元されて正常であるように、クラスターはそれを無視するか、それに加えた変更を無視する場合があります。

最も一般的ですが、投稿では言及されていないバックアップ戦略の 1 つは、QMgr 構成をバックアップすることです。これも：

  • オブジェクト定義
  • 承認
  • 終了ディレクトリ
  • 終了パラメーター
  • iniファイル

これらから、キュー マネージャーの構成を再作成することができ、QMgr の実行中にこれらすべてのバックアップを実行できます。復元すると、アプリケーションが以前と同じように接続できる空の QMgr が生成されます。主な要件は、アプリケーション (または人間のプロセス) が欠落しているメッセージを調整する必要があることです。

復旧ポイントをゼロにする、つまりメッセージを失わないための障害復旧アプローチが 1 つあります。これは、QMgr のファイルの下で同期ディスク レプリケーションを使用します。キューまたはログ ファイルへの各更新は、災害復旧サイトにリアルタイムでレプリケートされるため、DR QMgr はプライマリ QMgr の正確なコピーを保持します。プライマリがダウンすると、レプリケーションが中断され、DR QMgr が開始されます。DNS もフェイルオーバーするように構成されていると仮定すると、すべてのリモート QMgr とプログラムは、DR QMgr をプライマリであるかのように使用します。

いくつかの HA オプションもあります。PowerHA や Veritas Cluster Server などのハードウェア クラスターを使用すると、QMgr のファイルが SAN などの高可用性ディスクでホストされている場合、QMgr をあるサーバーから別のサーバーにフェールオーバーできます。マルチインスタンス QMgr は、ハードウェア クラスター ソフトウェアを使用せずに同様のフェイルオーバーを実行でき、可用性の高い NFS ストレージに基づいています。両方の QMgr インスタンスが同じディスク ストレージを参照するため、これらは両方とも DR ソリューションではなく HA ソリューションです。したがって、それらはそのディスク ストレージから (ネットワークの観点から) 同じ距離に近くなければなりません。 そうしないと、最も離れた QMgr でのパフォーマンスが遅延の影響を受け、スループットが許容できない場合があります。

追加情報は、Infocenter の「可用性、回復、および再始動」トピックで入手できます。

于 2012-08-21T17:51:09.297 に答える