3

Websphere MQ 本番環境のデプロイメント仕様を準備しようとしています。いつものように、車輪の再発明は嫌いなので、質問: Webshpere MQ 本番環境のデプロイと保守に関して、ベスト プラクティスの記事、仕様はありますか?

ここに私のより具体的な疑問があります：

  • 構成のバージョン管理 (MQSC、dmpmqcfg など)。
  • 新しいオブジェクトのデプロイ (MQSC または手動の指示?)
  • 展開の自動化 (おそらく dmpmqcfg の差分に基づいていますか?)。
  • 構成変更の展開とバージョン管理。

現在、MQ オブジェクトを手動で作成し、dmpmqcfg の出力をバージョン管理しているだけです。ただし、しばらくすると、このように処理するには展開が多すぎます。

4

1 に答える 1

3

これは非常に幅広い質問なので、モデレーターが削除する前に回答するようにします. :-)

答えは、MQ クラスターが使用されているかどうか、高可用性と災害復旧へのアプローチ、セキュリティ要件、QMgr が専用または共有インフラストラクチャとして構成されているかどうかなど、多くのことに依存します。ただし、いくつかのパターンがあります。非本番環境を含め、ほとんどすべての場合に従います。これは、Dev でテストされておらず、Prod で期待どおりに機能しない場合、監視やセキュリティなどの機能がデプロイ時にドロップされる傾向があるためです。

  • qX.509 証明書 (または CSR )の生成などの基本が常に標準に従って行われること、exit または exit parm ファイルが存在すること、特定の SupportPac 実行可能ファイル (. /opt/mqm/bin、循環キューなどに存在します。また、GSKit がインストールされていないなどのマイナス要因もチェックします。
  • すべての QMgr に対して実行されるベースライン スクリプトがあります。このスクリプトは、DLQ、監視エージェントのキューをセットアップし、必要に応じてイベントを有効にし、システム サービスをセットアップし、モニター、リスナーなどをトリガーします。例外は、すべて独自のクラスで処理され、非常に固有の構成を持つ B2B ゲートウェイ QMgr です。内部ネットワークでは使用されません。集まる。
  • 特定の構成要件を持ついくつかのクラスの QMgr があります。これらには、クラスター リポジトリ (プライマリとセカンダリが異なるサブタイプである)、サービス プロバイダー QMgr、およびサービス コンシューマー QMgr が含まれます。これらにはすべて、それらに対して実行されるセカンダリ スクリプトがあります。
  • クラスタリングが使用されている場合に、QMgr に参加または一時停止するためのクラスタごとのスクリプトがあります (v7.1 以降、私にとってはほぼ 100% です)。

これらは QMgr のインフラストラクチャをセットアップします。次に、各アプリケーションのスクリプトを維持します。たとえば、Payroll アプリがある場合、キューと、場合によってはPAYなどのノードを含む名前のトピックがありますPAY.EMPLOYEE.UPDT.REQ.V032.PRD。PAY.**これに対応するのは、すべてのキューに対して単一のスクリプトです。以前はsetmqautコマンド用でもありましたが、これらは現在、オブジェクトと同じスクリプトにあります。スクリプトのバージョンは 1 つしかなく、スクリプトの変更履歴を保持しています。このように、QMgr を再作成する必要がある場合は、すべてのスクリプトを実行するだけです。同様に、PAYオブジェクトを別の QMgr にデプロイする必要がある場合は、スクリプトをそのサーバーにコピーするだけです。

クラスターのオブジェクトを定義するときはDEFINE NOREPLACE、クラスターでキューが有効かどうかなど、すべてのランタイム属性を含む を常に実行します。キューは、クラスター内およびトリガー用に常に無効として定義されていますがNOREPLACE、スクリプトを再実行しても、たとえば 1 か月の状態は変化しません。説明など、構成で実行時ではないものは のALTER直後に処理され、スクリプトが実行されるたびにDEFINE更新されます。これに関する記事がここにあります。

最後に、私が使用するスクリプトは、自己実行型、自己文書化型のものです。たとえば、多くの人はすべての MQSC コマンドをスクリプトに入れ、次のようにします。

runmqsc < payroll.mqsc > payroll.out

ここにはたくさんの問題があります。主なものは、オペレーターが多くのことを知り、スクリプトを常に正しく実行することに依存していることです。たとえば、出力をキャプチャするのを忘れたとします。または、以前の出力を上書きしますか? または、最後にリダイレクトSTDERRを行う必要があり、2>&1リダイレクトをよく知らないために取得できませんか?

したがって、私のスクリプトはすべてksh、出力のすべてのキャプチャーを処理し、時刻と日付のスタンプを完備し、STDERRMQSC と OS コマンドなどを自由に組み合わせることができるように記述されています。その QMgr のスクリプト ディレクトリに移動し、. ./*kshビルド/再ビルドするだけです。 Qマネージャー。

もちろん、定期的な構成ダンプも取得しますが、これらは「このチャネルが定義されている QMgr の数とその場所は?」などのクエリやレポートを実行するためのものです。ものの種類。

また、バックアップを取るとき、ある時点で QMgr をバックアップする正当な理由はほとんどありません。ただし、必要な場合は、最初に QMgr を停止してください。また、証明書をバックアップに取り込むことについても、よく考えてください。多くの人は、証明書ディレクトリをロックしてmqm読み取りのみができるようにすることを得意としていますが、多くの場合、バックアップは保護されていません。本番環境に復元しようとしない限り、多くのショップでは本番/var/mqm/*ファイルを独自のサンドボックスに復元できます。QMgr の KDB ファイルが含まれている場合は、それらを失っただけです。/etc別の方法は、保護されているがQMgrのディレクトリでバックアップされていないディレクトリまたはその他のディレクトリに証明書を配置することです。

于 2013-01-05T20:12:34.600 に答える