Red Hat Training

A Red Hat training course is available for Red Hat JBoss Operations Network

JBoss Operations Network を使用したリソースの監視、デプロイ、および管理

Red Hat JBoss Operations Network 3.3

有効な JBoss および IT インフラストラクチャーを維持するための推奨事項および手順

Jared イタリア

zach Rhoads

概要

JBoss Operations Network の主な機能は、リソースのステータスを監視します。監視のコアには、重要な可用性の監視、プラットフォームおよびサーバーパフォーマンスでのメトリックの収集、イベントの追跡が含まれます。JBoss ON は、リソースが正常に動作していないと常にアラートを定義して管理者に通知する手段も提供します。
本ガイドでは、監視情報の表示、イベントの追跡、アラートおよび通知の定義、および操作開始のための GUI ベースの手順を説明します。

第1章 JBoss ON Web インターフェースの使用

JBoss Operations Network には、幅広い機能に対応する、レイヤー構造の豊富な UI があります。本章では、ユーザーがより効果的に管理タスクを実行できるように UI の主なセクションの概要を示します。

1.1. サポートされる Web ブラウザー

JBoss ON は、サーバー GUI にアクセスするためのこれらのブラウザーリリースをサポートします。
  • Firefox 17 以降
  • Internet Explorer 9

1.2. JBoss ON Web UI へのログイン

rhq-server.properties ファイルのマイナー設定以外に、JBoss ON はその Web インターフェースを介して完全に管理されます。
デフォルトでは、JBoss ON サーバーはポート 7080 でリッスンします。(サーバーのインストール時に別のポートを設定できます。また、ポート番号はサーバー設定で変更できます)。 サーバーに接続するには、hostname:port 形式の URL で標準の HTTP ページを開きます。例:
http://server.example.com:7080
次に、有効なユーザー名/パスワードの組み合わせを使用してログインします。デフォルトの管理ユーザーには名前とパスワードがあり rhqadminます。

図1.1 JBoss ON へのログイン

JBoss ON へのログイン

1.3. Internet Explorer の設定

Internet Explorer 設定によっては、JBoss ON のログインページが適切にロードされなくなることがあります。デフォルトでは、Internet Explorer はプルスモードに あり、一部の Web サイトの JavaScript アクセスを無効にします。ログインページがロードできるようにするには、JBoss ON サーバーの IP アドレスを Internet Explorer のホワイトリストに追加します。
  1. Internet Explorer で、右上隅の歯車アイコンをクリックして選択し Internet optionsます。
  2. Security タブを開き、Local intranet アイコンを選択します。
  3. Sites ボタンをクリックします。
  4. ポップアップウィンドウの下部にある Advanced ボタンをクリックします。
  5. Add this webiste to the zone: フィールドに JBoss ON サーバーのホスト名または IP アドレスを入力し、をクリックし Addます。
  6. オプションウィンドウを閉じます。

1.4. ハイレベルックスロー

JBoss ON UI は非常にリッチで、すべてのレイヤーが階層化されている小さな要素が多数あり、JBoss ON サーバーおよびリソースと対話するための非常に詳細で柔軟なインターフェースを提供します。領域の使用を最大化するために、JBoss ON はトップナビゲーションメニュー、サブタブ、アクティブなリンク、およびナビゲーションツリーを使用して JBoss ON リソースと JBoss ON 機能の関係を確立します。非常に一般的なビューでは、いくつかのタイプの視覚的要素が連携して UI を構成することができます。
  • トップメニュー
  • 左側のメニューテーブル
  • ダッシュボード
  • リソースインベントリー、サマリーレポート、検索の結果などのリソースベースのテーブル
  • リソース、グループ、プラグイン、JBoss ON のサーバー設定など、JBoss ON の要素の詳細とアクセスの両方を提供する設定ページ
これらの要素はすべて、繰り返しかつ信頼できるパターンに適合します。

図1.2 UI 要素すべて

UI 要素すべて
表示されるページのタイプを理解すると、JBoss ON UI での移動が容易になり、JBoss ON で何ができるのか理解しやすくなります。

1.4.1. トップメニュー

JBoss ON UI の上部にはメニューバーがあり、JBoss ON の主要な設定エリアに 5 つのタブがあります。

図1.3 トップメニュー

トップメニュー
各メニュー項目は JBoss ON の異なる機能機能に関連します。
  • Dashboard には、JBoss ON およびそのリソースに関するグローバル概要が含まれます。異なる設定可能なスナップショットの要約( ポートレットと呼ばれる)は、検出キュー、最近のアラート、最近の操作、リソース数など、リソースとサーバーのさまざまな側面を示しています。
  • Inventory タブには、リソースとグループの両方が表示されます。
  • Report タブには、事前定義済みのレポートが表示されます。これらはリソース情報のみにフォーカスする Dashboard と若干異なります。レポートは、アラート、操作、メトリクスコレクション、設定履歴などの JBoss ON のサブシステム(または主要な機能領域)の現在のアクションに重点を置いています。
  • Bundles タブは、プロビジョニングおよびコンテンツ機能エリアを開きます。これは、新規アプリケーションのプロビジョニングに使用されるコンテンツバンドルのアップロードおよびデプロイに使用されます。
  • 管理は、JBoss ON サーバー自体の設定に関連するすべてのエリアに送信されます。これには、サーバー設定、プラグイン、ユーザーおよびセキュリティー、エージェント設定が含まれます。

1.4.2. 左側のメニュー

ドロップダウンメニューまたはタブ付きオプションを使用する代わりに、左側のメニューで JBoss ON の設定の多くにアクセスできます。ユーザーおよびグループ、サーバー設定、サーバー/エージェント接続、およびエリアのコンテンツなどの設定の関連 Administration エリアが含まれる個別のテーブルがあり 図1.4「左側のメニュー」 ます。

図1.4 左側のメニュー

左側のメニュー
メニューテーブルの左側にある上矢印または下矢印をクリックすると、テーブルが折りたたまれます。これにより、左側のメニューの移動が容易になります。

図1.5 左側のメニューの折りたたみ

左側のメニューの折りたたみ

1.4.3. Dashboard

Dashboard は、JBoss ON のすべての概要で、最近のアクション(アラートおよび操作の発生)から、新たに検出およびインポートされたリソースへの可用性レポートを行います。このページは、JBoss ON の他の領域とは異なり、カスタマイズ可能なため、表示する情報のコレクションのみを表示できます。情報の各表は ポートレット と呼ばれ、JBoss ON サーバーまたはリソースのビューへの小規模ポートです。異なるポートレットやレイアウトを使用して、複数の Dashboard ビューを設定できます。これらは、Dashboard ページの上部にあるタブによってアクセスされます。

図1.6 ダッシュボードビュー

ダッシュボードビュー
Dashboard は JBoss ON の予定ページで、ログイン後に最初のページが表示されます。

1.4.4. インベントリーブラウザーおよびサマリー

一部のページは基本的には、基本的に同じ方法で提示される長い情報のテーブルです。
  • タブ、さまざまなエリア、詳細情報のサブタブ
  • 結果の表
  • 特定エンティティーの設定またはタスクオプションを開くアイコン
  • エントリーでアクションを実行するボタン(作成、削除、またはその他の特定のアクション)。エントリーが選択されていなければ、これらのボタンの一部がアクティブにならない
のインベントリーインターフェースに 図1.7「インベントリーブラウザー」 は機能が充実しています。リソースとグループの検索バーは、特殊な構文と柔軟な動的検索を使用します。リソース名にマウスを合わせると、そのリソースの詳細情報が含まれる小さなポップアップメッセージが表示されます。エントリー自体の名前をクリックすると、デフォルトのエントリー設定ページが開きます。親の名前をクリックすると、その親リソースの設定ページが開きます。

図1.7 インベントリーブラウザー

インベントリーブラウザー
では 図1.7「インベントリーブラウザー」、リソースが選択されているため、UNINVENTORY SELECTED ボタンがアクティブになります。エントリーがアクティブに選択されていない場合は、アクティビティーボタンがグレーアウトされます。

1.4.5. エントリーの詳細ページ

場合によっては、JBoss ON の最も機能的な領域はエントリーの詳細ページです。
左のナビゲーションエリアには、選択したリソースの階層(developer)と子の両方が表示されます。これにより、リソースに影響するさまざまなサービスおよびサーバーすべてを簡単に移動できます。

図1.8 リソースツリー

リソースツリー
左側のナビゲーションにあるリソースを右クリックし、そのエントリーの設定へのショートカットが開きます。
注記
リソースには、タイプ、インスタンス、またはシステム名、または IP アドレスに基づいて自動的に割り当てられる短縮名があります。これらの名前はインベントリーとツリーナビゲーションで使用されます。
リソースエントリーページ(およびプラグインやテンプレートなどの他の JBoss ON エンティティー)の設定エリアには、そのエントリーで利用可能なすべての機能とタスクを提供する 3 つの情報層があります。
エントリーの設定ページは設定できる各エリアに応じてタブになり、追加の設定オプションのサブタブと、その領域の履歴(アラート、以前のコンテンツの更新、監視データなど)が表示されます。

図1.9 リソースエントリーのタブ

リソースエントリーのタブ
エントリーエリアの次のセクションでは、そのタスクの関連エントリーの一覧が表示されます。たとえば、Operations エリアにはタブの下に利用可能な操作の一覧があります。では Inventory、設定された子リソースの一覧があり、そのリソースの設定されたアラートをすべて Alerts 表示します。これらのエントリーはすべて、JBoss ON UI の他の部分で利用可能な検索結果と同様のテーブルにリストされます。
多くの要素は 詳細 ページと 編集 ページの両方です。つまり、多くのフィールドは自動的にアクティブになります。これにより、別のページを開かずに管理タスクを直接実行できます。

図1.10 リソースエントリーの編集可能なエリア

リソースエントリーの編集可能なエリア

1.4.6. UI のショートカット

トップメニューの右端には、JBoss ON への非常に迅速な対象的な洞察を提供するアイコンの小規模なクラスターがあります。
  • Message Center は、JBoss ON サーバーによって送信された通知をすべて表示します。これには、アラート、設定の変更、インベントリーの変更、またはサーバーまたは UI のエラーメッセージが含まれます。
  • お気に入りボタンを使用すると、選択したリソースやグループへの移動を迅速化できます。一方、リソースページでは、わずかな青の分散を使用して、そのリソースをお気に入りのリストに追加できます。
  • リソースの可用性は、リソースが利用できるかどうかが緑色のチェックマークで、リソースがダウンしている場合は赤い X と表示されます。

図1.11 ショートカット

ショートカット

1.4.7. Red Hat Access Menu

Red Hat Access では、JBoss ON UI 内からヘルプトピックの検索、サポートチケットの送信、および特別な Red Hat の知識、リソース、および機能をすべて利用することができます。
サブスクライバーは、以下の Red Hat Access サービスを利用できます。
  • 便宜上、Red Hat の知識およびソリューションに排他的にアクセスできます。
  • エラーコード、メッセージ、およびその他の情報を検索し、Red Hat カスタマーポータルから関連する情報を表示します。
  • 新しいサポートケースを作成し、既存のサポートケースを表示し、JBoss Enterprise Application Platform 6 インスタンスおよびその他のファイルから収集された JBoss Diagnostic Reporter(JDR)レポートをこれらのケースに添付します。

1.4.7.1. 基本的な使用方法

Red Hat Access の使用を開始するには、Red Hat Access というトップメニュー右上隅のドロップダウンメニューで行います。サブスクライバーは、これらのサービスを有効にするには、Red Hat カスタマーポータルの認証情報を使用してログインする必要があります。「 Red Hat Access」メニューは、ユーザーがログインしていない場合を検出し、必要に応じて Red Hat Access ログインダイアログで提示します。
アカウント/パスワードのリカバリーは、カスタマーポータルの Login Assistance ページを参照してください。

1.4.7.3. サポート

ケース管理機能は、「Red Hat Access」メニューの「Support」サブメニューから起動されます。これらの機能により、サブスクライバーは JBoss ON UI から直接新しいケースを作成するだけでなく、既存のケースを表示および更新できます。

1.4.7.4. サポートケースの新規作成

新しいケース画面は、「Red Hat Access -> Support -> New Case」サブメニューから起動できます。
この画面を開くには、ケース一覧画面の「Open A New Support Case」ボタンをクリックします。検索パネルから送信されると、最新の検索されたテキストが description フィールドに挿入され、適切な製品およびバージョン情報が記述フィールドに挿入されます。さらに、Red Hat Access は「Subject」および「Description」入力フィールドを自動的に分析し、作成されたケースに関連するナレッジベースソリューションを推奨します。
ケースの作成時に、関連するログファイルをケースに割り当てることができます。サーバーファイルのファイルの横にあるチェックボックスをクリックし、接続の更新をクリックして、選択したファイルをアップロードします。
注記
このプロセスは、JBoss ON の他に、他の Red Hat がサポートする製品に対してサポートケースを作成するために使用できます。

1.4.7.5. サポート対象アプリケーションサーバーで新しいサポートケースを作成する

サポートされるアプリケーションサーバーで製品に対する新しいケースを開始するには、インスタンスに移動し、「Open Support Case」を右クリックして「Open Support Case」を選択します。
その後、該当製品に対して JDR レポートを添付するオプションを使用して、そのプロダクトに対してケースを開くことができます。

1.4.7.6. 既存のサポートケースの表示

既存のケースは、「Red Hat Access -> Support -> My Cases」サブメニューから確認できます。
ケース一覧は、検索ボックスの使用、ケースグループの選択、またはドロップダウンを使用して、閉じたケースのオープンや終了したケースの可視性を制御することでフィルタリングできます。

1.4.7.7. ケースの編集

ケース一覧からケースをクリックすると、Red Hat カスタマーポータルと同様にケースを変更することができます。「 Update Details」ボタンをクリックして、そのセクションを永続的に変更します。
ケース作成時にナレッジベースソリューションを推奨する他に、Red Hat Access はケースのメタデータを分析し、関連するナレッジベースソリューションを推奨します。結果は、同様の問題のある Red Hat の以前のエクスペリエンスに基づいており、問題をより迅速に解決するのに役立ちます。既存のケースの表示または編集時に、推奨されるナレッジベースソリューションが表示されます。
推奨されるナレッジベースソリューションのいずれでも、推奨事項の横にあるピンアイコンをクリックして既存のケースに割り当てることもできます。

1.5. Message Center での通知の取得

Message Center は、現在のブラウザーセッションに対して GUI によって返されたメッセージをすべて表示します。これには、UI で実行されたアクション(インベントリーへのリソースの追加、リソースの設定、またはコンテンツをアップロードするなど)が含まれます。また、セッション中に返される可能性のあるエラーメッセージも含まれます。

図1.12 Message Center

Message Center

1.6. テーブルの表示のソートと変更

JBoss ON のほとんどすべての情報は、リソースインベントリーからエージェントのプラグイン一覧までテーブルに表示されます。SmartGWT UI には、テーブル情報をソートして表示する方法において、いくつかの多用途があります。
一部のテーブルでは、数値またはアルファベット順でソートされる列を基にして、非常に単純な昇順/降順を使用します。

図1.13 パーティションイベントリスト上の基本的なテーブルソート

パーティションイベントリスト上の基本的なテーブルソート
UI のほとんどのエリアでは、より複雑な情報を表示することができます。基本的なテーブルと同様に、列名をクリックするとその列が昇順または降順でソートされます。ただし、高度な GWT テーブルには、列の右側にあるメニュー矢印をクリックして、テーブルレイアウトとソートオプションを変更するオプションもあります。

図1.14 サーバーリソース一覧の基本的なテーブルソート

サーバーリソース一覧の基本的なテーブルソート
メニュー矢印を選択すると、その列の並べ替え順序を変更できます。表示される列のサイズや、列の種類を変更することもできます。このオプションは、表に含まれるエントリーの種類に応じて動的に生成されます。

図1.15 サーバーリソース一覧の高度なテーブルソート

サーバーリソース一覧の高度なテーブルソート
ソート順序は、複数の基準を指定することで優先順位を設定することもできます。たとえば、リソースは名前でソートしてから、プラグインで、ID 別に並べ替えることができます。リソースが標準化されたため、名前や親のみでソートしても、エントリーに意味のある順序を付与することは十分ではありません。複数の優先度が付けられた基準があると、テーブルをより正確に表示できます。

図1.16 Sort メソッドの変更

Sort メソッドの変更

1.7. ダッシュボードのカスタマイズ

ダッシュボードは設定可能です。これは個々のポートレットで構成され、これらのポートレットは各ポートレットに表示されるアイコンメニューで再編成したり、個別に更新したりできます。JBoss ON およびそのリソースに異なるビューを提供するために使用できるポートレットを持つ複数のダッシュボードが存在する可能性があります。
注記
ダッシュボードは、グローバルではなくユーザーごとに設定されます。

1.7.1. ポートレットの編集

Dashboard レイアウト内のポートレットを移動するには、ポートレットツールバーの矢印を使用します。現在のポートレットを削除するには、左端の最小アイコンをクリックして折りたたむか、右端の X アイコンをクリックして Dashboard からポートレットを完全に削除します。一部のタイプのポートレットでカスタマイズが可能で、wrench アイコンをクリックしてアクセスできます。

図1.17 ポートレットアイコン

ポートレットアイコン

1.7.2. ダッシュボードの追加および編集

ダッシュボードページには、それぞれ異なるポートレット、列レイアウト、および更新間隔を持つ複数のダッシュボードを実際に含めることができます。これにより、JBoss ON のリソース状態の非常に高速な評価を行う情報の論理的なグループ化が可能になります。複数のダッシュボードを設定すると、UI でタブとして表示されます。

図1.18 タブ付きダッシュボード

タブ付きダッシュボード
新規ダッシュボードを追加するには、以下を実行します。
  1. メインの Dashboard の右端にある New Dashboard ボタンをクリックします。
    注記
    Dashboards を編集および追加するプロセスは非常に似ています。唯一の違いは、Dashboard を編集するには、Edit Mode ボタンをクリックします。
  2. 新しい Dashboard が編集モードで開きます。新しい Dashboard の名前を入力します。
  3. 必要なポートレットを Dashboard に追加します。必要に応じて、ポートレットの数に合わせて列数を変更します。

1.8. お気に入りの設定

お気に入りを使用すると、設定の更新、監視、またはアラートのために管理者がルーチンにアクセスする必要のあるリソースへの移動が容易になります。
各リソースには、詳細ページの右上隅に小さな分散アイコンがあります。このアイコンをクリックして、リソースのお気に入りの一覧に自動的に追加します。

図1.19 お気に入りアイコン

お気に入りアイコン
リソースとグループのお気に入りは、トップメニューの右側 Favorites のショートカットに一覧表示されます。その一覧のリソースをクリックすると、リソースを検索することなく、details ページが自動的に開きます。複数のリソースで名前やプロパティーを共有する場合があるため、お気に入りのリストには、適切なリソースを選択できるように、リソースに関する詳細が含まれるカーソルが含まれています。

図1.20 お気に入りリスト

お気に入りリスト

1.9. エントリーの削除

リソース関連のエントリーは、インベントリーブラウザーまたはグループブラウザーで削除できます。ほとんどの JBoss ON サーバー設定エントリーは削除できません。プラグイン、コンテンツ、ロール、ユーザーなどのユーザー提供の要素のみを削除できます。
項目を削除できる場合は、削除ボタンがテーブル一覧または項目の詳細ページで利用できます。

図1.21 エリアブラウザーの削除された

エリアブラウザーの削除された
注記
ユーザーは何かを 変更 する権限を持っているかもしれませんが、何かを 削除 する権限を暗黙的に付与する訳ではありません。たとえば、設定書き込みパーミッションを持つユーザーは、リソース設定を編集し、設定履歴および設定を表示できますが、設定履歴の要素を削除することはできません。同様の制約は、作成および編集操作およびアラートのパーミッションを持つユーザーにも同様です。リソース履歴で要素を削除する権限はありません。
履歴内の要素を削除するには、インベントリーの管理パーミッションが必要です。

第2章 リソースおよびグループの動的検索

インベントリーエリアには、リソースとグループを検索する動的な検索があります。
動的検索は、JBoss ON のリソースの管理に役立つ追加ツールです。JBoss ON の動的検索を保存すると、お使いのインフラストラクチャーに関連する基準に一致する JBoss ON デプロイメントの迅速かつ再現可能なスナップショットを提供することができます。
動的な検索は、サブシステムビューの検索やクイック検索のいずれかよりも、リソースとグループ(グループメンバーに再帰的に)の両方をチェックします。検索は、リソースの特定の識別属性(名前、親、タイプ、JBoss ON カテゴリーなど)に対して開始し、検索が文字列を処理する方法を設定できます。複数の検索パラメーターを組み合わして、正確な検索と複雑な検索を行うことができます。動的検索は後で保存して再利用できるため、結果が確実に再現可能になります(詳細は「動的検索構文について」 説明されています)。
自動補完、ヒント、強調表示の検索文字列などの動的検索には、制限されたサブ文字列やクイック検索よりも効率的に使用が容易になります。これらは、で説明してい 「検索の推奨」 ます。

2.1. 検索の推奨

動的検索は、単にリソースを見つけるだけで非常に強力なものです。動的検索は、リソース名だけでなく、さまざまなリソース特性の値を使用して実行できます。動的検索は保存することもできます。そのため、それらは繰り返し可能で、アドホックレポートとして使用することができます。
検索の提案により、動的検索を簡単に使用できます。すべての検索のドロップダウンメニューには、3 種類の提案があります。
  • 保存済み検索(以前のカスタム検索文字列と、その検索に一致するリソースの数を含む)
  • 利用できるリソース特性のプロンプトを提供する検索のクエリー
  • テキスト検索。テキストプロンプトに一致するリソースの一部のプロパティーに基づくリソース一覧を提供します。

図2.1 検索推奨のタイプ

検索推奨のタイプ
検索用語がフィールドに入力すると、一致するリソースの一致するサブ文字列が強調表示されます。デフォルトでは、提案はリソースのすべてのサブ文字列またはリソース設定特性と一致することができます。提案は、異なる演算子を使用して、一致する属性の最初または最後の文字列と一致するように制限でき 「動的検索構文について」ます。

図2.2 検索契約の強調表示

検索契約の強調表示

2.2. 動的検索構文について

JBoss ON には動的検索に対する独自の検索構文があります。この構文は、幅広い検索可能な項目をカバーし、異なるフレーズを結合させる一方で、比較的シンプルであることを前提としています。
基本的な動的検索は、一般的なサブストリング検索で検索ボックスにテキストを入力するとどれでも一致しています。検索では、より詳細なターゲットの構文を、以下の形式で許可できます。
[search_area].[search_property] operator value operator additional_search
search_area は、検索しているエントリーのタイプ(リソースまたはグループ)を特定します。検索エリアが検索の場所によって暗示されるため、これは任意の値になります。つまり、Resources エリアの検索はリソース検索を意味するため、検索の resource. 一部を含める必要はありません。

図2.3 リソース特性による検索

リソース特性による検索

2.2.2. プロパティー検索

検索プロパティーを使用すると、エントリーの特定の値または属性タイプを検索すると、検索を絞り込むことができます。たとえば、CPU 使用率が 50%(trait)のリソースが、80()が含まれる ID を持つエントリーを検索する場合とは異なりidます。利用可能なプロパティーは 表2.2「リソース検索コンテキスト」 およびに一覧表示され 表2.3「グループ検索コンテキスト」 ます。
注記
検索エリアと適切なプロパティーを指定して、リソース検索でグループ基準を使用し、逆引きで検索できます。たとえば、groups エリアで検索を実行して、特定のリソースが属するグループの一覧を返すことができます。これは、検索コンテキストと search プロパティーを明示的に渡して行います。たとえば、Groups ページで Postgres プラグインによって管理されるリソースが含まれるグループを一覧表示するには、以下のコマンドを実行します。
resource.type.plugin = Postgres
重要
パラメーターは connection configuration、JBoss ON GUI で trait 使用される名前ではなくプロパティー 名(connection[property_name])の内部 プロパティー名を使用し、内部プロパティー名を使用します。

表2.2 リソース検索コンテキスト

property description
resource.id JBoss ON によって割り当てられるリソース ID 番号。
resource.name UI に表示されるリソース名。
resource.version リソースのバージョン番号。
resource.type.plugin リソースタイプ。リソースの管理に使用するプラグインで定義されます。
resource.type.name 名前でリソースタイプ。
resource.type.category リソースタイプカテゴリー(platform、server、または service)。
resource.availability UP または DOWN のいずれかのリソースの可用性。
resource.pluginConfiguration[property-name] プラグイン内の可能な設定エントリーの値。
resource.resourceConfiguration[property-name] リソース内の可能な設定エントリーの値。
resource.trait[property-name] リソースの測定特性の値。
グループにはリソースよりもシンプルなエントリーがあるため、グループの検索プロパティーは若干少なくなります。

表2.3 グループ検索コンテキスト

property description
group.name グループの名前。
group.plug-in 互換性のあるグループの場合、このグループのリソースタイプを定義するプラグイン。
group.type 互換性のあるグループの場合、このグループのリソースタイプです。
group.category リソースタイプカテゴリー(platform、server、または service)。
group.kind 混在または互換性のあるグループのタイプ。
group.availability UP または DOWN のいずれかのグループでリソースの可用性。
演算子 は、最初に検索結果が検索文字列()と一致する方法を参照します。これには、検索文字列に指定された値以外の値に完全一致が必要になります。演算子 は、次に複数の検索文字列が相互にどのように関係するか(AND または OR)、明示的な AND ステートメントと OR ステートメントおよび括弧の両方が許可されます。複雑な検索については、で対応してい 「複合 AND および OR 検索」 ます。

表2.4 Search String Operator

operator description
= 大文字と小文字を区別しない一致。
== case-exact match。
!= 大文字と小文字を区別しない負の一致(つまり、値は文字列では ありません )。
!== case-exact negative match(つまり、値は文字列では ありません )。

2.2.3. 複合 AND および OR 検索

動的検索バーは、各単語が検索用語であることを前提としています(引用符で囲まれていない限り)。暗黙的に、マルチテキスト検索は AND 検索として処理されます。例:
postgres server myserver
これは一連の AND 用語として扱われます。
postgres AND server AND myserver
動的検索では、パイプ(|)で区切られた OR 検索も可能です。例:
postgres | jbossas
AND 検索と OR 検索の両方を入力できます。また、複数の検索文字列を組み込むことで複雑な検索を作成できます。AND と OR の両方の検索基準がある場合は、AND 用語が最初に処理されます。たとえば、この検索用語は B と C の両方を検索し、次に A または B/C のいずれかを検索します。
a | b c
注記
複雑な検索で使用される AND と OR の用語の両方がある場合は、AND 用語が優先されます。ただし、括弧で囲まれた用語は AND 表現よりも前に評価されるため、括弧を使用して適切な検索設定を上書きすることができます。
検索フレーズは、検索用語をグループ化するために括弧を使用して複数のレベルにネストできます。これらの括弧を使用して、AND マッチの設定を上書きすることもできます。少なくともいくつかの OR 式を最初に処理する必要があります。たとえば、この式は最初に OR 用語を検索し、OR bc OR d を照合してから、2 つの OR 検索の結果で AND 検索を実行します。
(a | b) (c | d)
結果には、c、a d、b cおよび b d などの複数の値の組み合わせが含まれます。
複数のレベルのネストが許可されます。たとえば、この式に AND OR c AND d が必要です。
(a) (b | (c d))
一致するリソースには、c d または b に一致する 値を含めることができます。

第3章 レポートの表示およびエクスポート

JBoss ON の目的は、インフラストラクチャー内のリソースに関する情報を提供することです。UI には、個別のリソースまたは定義されたグループに関する情報が表示される場所が多数あります。
Reports メインタブには、サブセットだけでなく、すべて のリソースのさまざまなエリアへの事前定義の検索およびビューの一覧があります。

3.1. Report の種類

すべてのレポートには、JBoss ON インベントリーのすべてにまたがる情報のリストが表示されます。レポートは JBoss ON server サブシステムエリアの 2 つのカテゴリーに分類され、もう 1 つは異なるインベントリー数に分類されます。
サブシステムレポートは、モニタリング、アラート、ドリフト、および設定のさまざまな要素に対して JBoss ON の 機能 に関連します。ほとんどのサブシステムレポートには、リソースレベルのチャートとの共通点があり、同じ情報が表示されます。サブシステムのレポートには、名前が一意ではないため、リソース名とリソースのancestry(親リソースおよびグランド親リソース)を一覧表示するための追加の列が含まれます。
インベントリーレポートにカウントが表示されます。これらのレポートは、通常リソースタイプ別にブレークダウンし、「subreports」で利用可能な追加のリソース一覧で始まります。

図3.1 インベントリー概要レポート

インベントリー概要レポート

表3.1 Report の種類

レポート名 description フィルターがあるか?
サブシステムレポート
メトリクスの疑わしい 指定のリソースの確立されたベースライン外のメトリクスを一覧表示します。すべてのリソースの疑わしいメトリックがすべて表示されますが、同じタイプのリソース間でも、メトリックをマークするベースラインはリソースごとに異なる場合があります。 いいえ
設定履歴 すべてのリソースの設定変更をすべて表示します。バージョン番号はリソースごとではなく、グローバルに増分されます。設定履歴には、変更のバージョン番号、送信日および完了日、ステータス、変更のタイプ(個別またはグループ経由)が表示されます。 いいえ
最近の操作 操作が送信された時点ではなく(必ずしも実行されるとは限らず)、操作タイプおよびそのステータスを、すべてのリソースのすべての操作を一覧表示します。
最近のアラート リソースに起動されたすべてのアラートを、リソースの名前、起動されたアラート定義、およびアラート条件と共に一覧表示します。
アラート定義 すべてのリソースについて設定済みのすべてのアラート定義をそれらの優先順位および有効にされているかどうかを一覧表示します。 いいえ
最近のドリフト すべてのリソースおよびドリフト定義用のスナップショットの一覧が含まれます。
インベントリーレポート
インベントリーの概要 リソースタイプとバージョン番号別に分類された、インベントリー内のリソースの完全なリストが含まれます。 いいえ
プラットフォームの使用状況 現在の CPU パーセンテージ、実際のメモリー、スワップ領域を表示します。 いいえ
ドリフトコンプライアンス は、ドリフトをサポートし、設定されたドリフト定義の数、およびグループが準拠しているかどうかを示すすべてのリソースタイプの一覧を表示します。リソースタイプをクリックすると、ドリフトに設定されたリソースの一覧と、個別のコンプライアンスステータスが表示されます。 いいえ

3.2. CSV へのレポートデータのエクスポート

この Reports タブは、複雑なスクリプトを使用せずに、GUI や CLI でも簡単にアクセスできない情報を収集します。レポートからの情報は、Export ボタンをクリックして CSV にエクスポートできます。

図3.2 エクスポートされたインベントリーの概要

エクスポートされたインベントリーの概要
レポートに表示されるようにレポートに表示される情報のみが CSV にエクスポートされます。レポートに適用される特定のソート順序がある場合や、表示されるエントリーを制限するフィルターを使用している場合、そのソート順序とそのフィルターはエクスポートされたレポート CSV ファイルに保持されます。

図3.3 日付フィルターを含むレポート

日付フィルターを含むレポート

パート I. インベントリー、リソース、およびグループ

第4章 エージェントおよびリソースのシステムユーザーとの対話

エージェントは特定のシステムユーザーとして実行されるため、JBoss ON によって管理される JBoss や Apache などのサーバーも実行できます。検出などの多くのエージェント管理タスクに関する一般的な仮定は、エージェントユーザーがリソースユーザーと同じであることです。ユーザーが異なる場合は、リソースの検出および管理方法に影響を及ぼす可能性があります。
JBoss ON が管理するサーバーの一般的なタイプは以下のとおりです。
  • JBoss EAP サーバー
  • PostgreSQL データベース
  • Tomcat サーバー
  • Apache サーバー
  • 汎用 JVM
JBoss ON エージェントが開始する一部の管理操作では、エージェントのシステムユーザーは関与することはありません。たとえば、JBoss EAP プラグインは JBoss EAP 自体が管理する認証メカニズムを使用して EAP インスタンスに接続するため、システム ACL やユーザーパーミッションは必要ありません。ユーザーが JBoss EAP インスタンスにアクセスできる限り、すべてが機能します。

表4.1 Agent and Resource Users のスプレッドシート

resource ユーザー情報
PostgreSQL
監視および検出には影響しません。
設定の表示および編集には、エージェントユーザーに PostgreSQL 設定ファイルへの読み取り/書き込み権限が必要です。
apache
監視および検出には影響しません。
設定の表示および編集には、エージェントユーザーに Apache 設定ファイルへの読み取り/書き込み権限が必要です。
Tomcat 同じユーザーを使用する必要があります。またはエージェントを検出できません。
JMX サーバーまたは JVM JMX リモーティングを使用する場合は、ユーザーごとに問題ありません。異なるユーザーやアタッチ API では検出できません。
JBoss AS/EAP
EAP 5 以前: ユーザーはすべて正常ですが、先行ディレクトリーですべての先行ディレクトリーに読み取り権限と実行 run.jar および検索の権限が必要です run.jar
EAP 6 およびそれ以降では、エージェントを実行しているユーザーには、アプリケーションサーバーの設定ファイルへの読み取り権限がなければなりません。

4.1. エージェントユーザー

通常、エージェントは管理リソースと同じユーザーとして実行され、これが設定の最もクリーンなオプションであることを前提としています。
エージェントインストーラーの JAR ファイルから JBoss ON エージェントをインストールする場合、エージェントのインストールファイルを所有するシステムユーザーとグループは JAR をインストールしたユーザーと同じです。したがって、特別なシステムユーザーを作成または選択でき、そのユーザーがエージェントをインストールできます。

4.2. エージェントユーザーおよび検出

エージェントは、PID やプロセス、起動スクリプトなどの特定の共通プロパティーを検索してリソースを検出します。
このエージェントがリソースユーザーとして上位の権限を持っているかどうかは必ずしも問題ありません。
ほとんどのリソースでは、エージェントはそのリソースの設定への読み取りアクセスを必要とします。Apache や Postgres などのリソースでは、エージェントがリソース設定を読み取ることができる限り、リソースを検出できます。
他のリソースに関して、agent ユーザーには、非常に特殊なパーミッションが必要です。
  • JBoss EAP リソースでは、エージェントにファイルに対する読み取り権限が必要です。さらに、run.jar ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になり run.jar ます。
  • RPM から JBoss EAP 6 インスタンスがインストールされている場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。
  • Tomcat サーバーは、JBoss ON エージェントと Tomcat サーバーが同じユーザーとして稼働している場合にのみ検出できます。エージェントが root として実行されていても、Tomcat サーバーがエージェントとは異なるユーザーとして実行されている場合は検出できません。
  • JVM または JMX サーバーが JMX リモーティングで実行されている場合は、エージェントが別のユーザーとして実行されているかどうかを検出できます。ただし、attach API を使用して実行している場合は、リソースを検出するためのエージェントと同じユーザーとして実行する必要があります。

4.3. ユーザーおよび管理タスク

エージェントが実行しているシステムユーザーは、いくつかの一般的なエージェントタスクに影響します。
  • 検出
  • アプリケーションのデプロイ
  • スクリプトの実行
  • 起動、停止、および再起動の操作の実行
  • JBoss ON UI を使用した子リソースの作成
  • リソース設定の表示および編集
実行するタスクと、権限または承認のためにリソースまたはオペレーティングシステムの制限に基づいて、その操作を実行する必要があるタスクを決定することが重要になります。
一部のアクション: 検出、アプリケーションのデプロイ、または子リソースの作成 - エージェントユーザーにパーミッションを付与するシステム ACL を設定するだけで十分です。
操作の実行やスクリプトの実行には、エージェントユーザー以外のユーザーとしてタスクを実行する必要があります。これはを使用して実行でき sudoます。
いずれの方法でも、JBoss ON ユーザーに、操作の実行に必要なすべてのシステムパーミッションを付与することが目的です。

4.4. JBoss ON 操作での sudo の使用

使用の時間は、サービス sudo の起動やプロセス、リソースユーザーが所有するスクリプトなど、長時間実行される操作に使用されます。スクリプトを実行するユーザーは、適切な承認とパーミッションを持つため、リソースユーザーと同じである必要があります。
ユーザーは実際に同じであることや、JBoss ON ユーザーに指定コマンドへの sudo 権限を付与できます。
エージェントユーザーのパーミッションを昇格する場合は、以下の 2 つの項目が true である必要があります。
  • パスワードのプロンプトなしでユーザーとの対話を必要としません。
  • エージェントが変数をスクリプトに渡すことができるはずです。
リソーススクリプトを設定するには sudo、以下を行います。
  1. JBoss ON エージェントユーザーに特定のスクリプトまたはコマンドへの sudo 権限を付与します。たとえば、jbossadmin ユーザーとしてスクリプトを実行するには、以下を実行します。
    [root@server ~]# visudo
    
    jbosson-agent     hostname=(jbossadmin)  NOPASSWD: /opt/jboss-eap/jboss-as/bin/*myScript*.sh
    NOPASSWD オプションを使用すると、パスワードを要求せずにコマンドが実行されます。
    重要
    JBoss ON は、EAP インスタンスの開始時に、コマンドライン引数を start スクリプトで渡します。これは、sudoers エントリーに完全なコマンドラインスクリプト(引数を含む)を含めるか、ラッパースクリプトの sudo -u user コマンドを使用するか、スクリプト接頭辞のいずれかを指定して実行できます。
    2 つ目のオプションには、簡単な sudoers エントリーがあります。
  2. 使用するラッパースクリプトを作成または編集します。リソースのスクリプトを直接呼び出す代わりに、スクリプトの実行 sudo に使用するラッパースクリプトを呼び出します。
    注記
    EAP 起動スクリプトでは、別のラッパースクリプトを作成する代わりに、接続設定にスクリプト接頭辞を設定できます。
    /usr/bin/sudo -u jbosson-agent
    たとえば、開始スクリプトラッパーの場合は、start-myScript.sh以下を行います。
    #!/bin/sh
    # start-myScript.sh
    # Helper script to execute start-myConfig.sh as the user jbosson-agent
    #
    sudo -u jbosson-agent /opt/jboss-eap/jboss-as/bin/start-myConfig.sh
  3. スクリプトで渡す引数または設定を使用して、開始 run.sh スクリプトを作成します。たとえば、start-myConfig.sh以下のようになります。
    nohup ./run.sh -c MyConfig -b jonagent-host 2>&1> jboss-MyConfig.out &

第5章 リソースインベントリーの管理

JBoss ON の インベントリー は、JBoss Operations Network によって管理または監視されるすべてのサーバーおよびアプリケーションが含まれるリポジトリーです。このインベントリーは、管理できるリソースを JBoss Operations Network に指示します。
インベントリーでは、リソースを複数の方法で編成できます。リソースは autogroups の種別で自動的にグループ化でき、リソースはユーザー定義のグループに手動で追加でき、子として別のリソースに手動で追加できます。
本セクションでは、検出、子、およびグループ管理を使用したリソースの識別とインポートのプロセスについて説明します。

5.1. Inventory について: リソース

JBoss ON インベントリー は、JBoss ON サーバーによって認識されるすべての管理リソースの中央リストです。

5.1.1. 管理リソース: プラットフォーム、サーバー、およびサービス

各 JBoss ON エージェントは、サービスおよびサーバーを確認するためにインストールされたプラットフォームを定期的にスキャンします。これは 検出 プロセスです。潜在的なリソースが検出されると、検出スキャン結果に一覧表示され、そこから JBoss ON によって管理されるかどうかを選択できます。リソースを管理する必要がある場合は、JBoss ON サーバーのインベントリーに インポート する必要があります。それ以外の場合は無視できます。
JBoss ON には、以下の 3 つのカテゴリーのリソースがあります。
  1. プラットフォーム(オペレーティングシステム)
  2. サーバー
  3. services
JBoss ON インベントリーのリソース階層は、プラットフォーム上でプログラムとプロセスが物理的に構成される方法を反映します。プラットフォームが最も高いレベルです。プラットフォームには、サーバーとサービスの両方を子として使用することができます。同様に、サーバーには他のサーバーとサービスの両方を子として持つことができますが、サービスはインベントリー内の子として他のサービスのみを持つことができます。

図5.1 リソース階層の例

リソース階層の例
インベントリー内のリソース間の関係を管理するルールの一部
  • リソースには親が 1 つだけ指定できます。
  • サーバーは、プラットフォーム(Linux 上の JBoss AS など)または別のサーバー(JBoss AS に組み込まれた Tomcat など)の子になります。
  • サービスは、プラットフォーム、サーバー(JBoss AS の JMS キューなど)または別のサービス(データベース内のテーブルなど)の子になります。
  • プラットフォーム、サーバー、およびサービスには多くの子サービスがあります。
JBoss ON では、多くの異なるタイプのリソースを管理できます。各管理リソースには、リソースの利用可能なモニタリングメトリクス、操作、およびサポートされるバージョンを定義する対応するエージェントプラグインがあります。
注記
リソースタイプのカスタムプラグインを作成して、追加のリソースを追加できます。

5.1.2. コンテンツバックアップリソース

アプリケーションサーバーの場合、子リソースとサーバーにデプロイされたコンテンツの間に、概念の密接リンクがあります。たとえば、EAR と WAR はアプリケーションサーバーの子リソースで、バージョン管理されたコンテンツで、リポジトリーに保存でき、デプロイを選択してデプロイし、元に戻すことができます。
コンテンツベースのリソース は、インベントリー階層に配置があるリソースとして扱われ、それに対して操作を実行でき、そのリソースに対してメトリクスを収集することができます。ただし、これは JBoss ON コンテンツシステムへアップロードおよび保存され、リポジトリー内で維持されるビットでソフトウェアパッケージとしても管理されます。
コンテンツベースのリソースは、手動で子として追加することも、JBoss ON の外部でデプロイした場合は、パッケージ検出スキャンで検出できます(デフォルトでは 24 時間ごとに実行されます)。これらの子リソースは、JBoss ON のリポジトリーからコンテンツをデプロイして作成および更新することもできます。
コンテンツベースのリソースの管理に関する詳細は、32章JBoss EAP 6 の管理(AS 7) およびを参照してください 31章JBoss EAP 5 の管理
重要
コンテンツベースのリソースは、ディスク領域の要件に大きく影響する可能性があります。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部で、コンテンツベースのリソースを元に戻すことができ、管理することができます。
したがって、バックエンドデータベース(Oracle または PostgreSQL)をホストするシステムでは、リソースの全バージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。

5.1.3. JBoss ON によって使用される Inventory のリソース

一部のリソースはプラットフォームに自動的に追加され、特定の JBoss ON 固有の機能を有効にします。たとえば、Ant バンドルハンドラーリソースは子サービスとしてプラットフォームに追加され、エージェントが Ant レシピを識別および処理できるようにします。[1] Ant bundle handler リソースがない場合、JBoss ON エージェントはそのプラットフォームでプロビジョニングを実行できません。管理者はインベントリーにある JBoss ON 固有の子リソースと直接対話する必要はありませんが、JBoss ON 機能を使用するにはこれらの子リソースが存在する必要があります。これらの子は JBoss ON で必要であるため、プラットフォームで自動的にインポートされます。
その他のリソースを、JBoss ON サーバー、JBoss ON エージェント、JBoss ON エージェント、エージェント JVM、JBoss Cache、エージェント起動スクリプトおよび rhq-agent-env.sh スクリプトなどのエージェントとサーバーに関連する JBoss AS サーバーのインベントリーに追加できます。これらのリソースを JBoss ON インベントリーに追加すると、JBoss ON はデプロイメントのすべてのエージェントおよびサーバーを監視し、管理できます。

5.2. リソースの検出

JBoss ON によってアプリケーションやプラットフォームを管理する前に、インベントリーにインポートする必要があります。リソースの検出方法によっては、リソースをインベントリーに追加する方法は複数あります。

5.2.1. 新しいリソースの検索: 検出

エージェントがインストールされ、起動時に毎回、そのプラットフォーム上のすべてのアプリケーション(サーバー、サービス、またはインベントリーに追加可能なその他の項目)が スキャン されます。潜在的なリソースを検索するプロセスは、discovery と呼ばれます。
リソースのタイプ(プラットフォーム、サーバー、およびサービス)には、さまざまなスキャンがあります。サーバーおよびプラットフォームの高度なスキャンは、エージェントが 15 分ごとに開始します。サービススキャンは、インベントリーにすでにインポートされているサーバーで実行されている低レベルのサービスを検出します。これらのスキャンは、デフォルトで 24 時間ごとに実行されます。これらの間隔は、JBoss ON エージェント設定で設定できます。
エージェントは常に、起動時に新しいリソースのスキャンを実行し、設定済みの間隔で定期的に実行します。親と即時にリソースがインポートされ、低レベルの子を検出するために別の検出スキャンが開始されると遅延が生じます。これにより、リソースが長時間実行される可能性があるため、無視される可能性があります。
注記
すべての検出スキャン間隔は、エージェントの設定ファイルで設定できます。
JBoss ON エージェントは、検出するプラットフォームとサーバーに関する情報を JBoss ON サーバーに送信します。
検出スキャンで子プロセス、サーバー、またはサービスを検出する前に、サーバーをインベントリーにインポートする必要があります。
プラットフォームがインベントリーにインポートされると、その子サーバーとサービスが複数自動的にインポートされます。これには、プラットフォームに不可欠なリソース(CPU、ネットワークアダプター、ファイルシステムなど)や JBoss ON サーバー自体で使用されるリソース(provisioning サブシステムによって使用される Ant バンドルハンドラーリソースなど)が含まれます。
検出はエージェントにより自動的に実行されますが、検出を手動で開始してインフラストラクチャーの変更を即座に取得することもできます。

5.2.2. 検出スキャンの手動実行

検出スキャンはエージェントによって自動的に実行され、プラットフォームに追加された新しいリソースを特定します。サーバーの起動時にエージェントの完全な検出スキャンを実行すると、サーバースキャンは 15 分ごとに実行され、サービスは 24 時間ごとにスキャンされます。検出スキャン間で新しいリソースを追加することができるため、管理者は手動検出スキャンを非同期的に開始できます。
検出スキャンを開始する最も簡単な方法は、エージェントのコマンドプロンプトでエージェントの discovery コマンドを実行することです。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側のメニュー Platforms から選択し、スキャンを実行するプラットフォームを選択します。
  3. Operations タブを開きます。Schedules サブタブで、New ボタンをクリックします。
  4. 左側の Servers - Top Level Resources リンクを開き、エージェントリソースを選択します。
  5. ドロップダウンメニューから Manual Discovery 操作を選択し、詳細な検出(サーバーおよびサービス)または簡単な検出(サーバーのみ)を実行するかどうかを選択します。
  6. この Schedule エリアでラジオボタンを選択してすぐに操作を実行します。
  7. Schedule ボタンをクリックして操作を設定します。

5.2.3. 検出キューからのリソースのインポート

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューで、を選択し Discovery Queueます。
  3. インポートするリソースのチェックボックスを選択します。(プラットフォームなど)親リソースを選択すると、その子も自動的にインポートできます。
  4. UI の下部にある Import ボタンをクリックします。

5.2.4. 検出したリソースの無視

JBoss ON エージェントがインベントリーから無視されるアプリケーションまたはサービスを検出すると、サーバーは検出キュー内のこれらのリソースを無視するよう指示されます。リソースがすでにインベントリーにインポートされている場合は、を参照してください 「インポートされたリソースの無視」
注記
リソースは、親が すでに インベントリーに追加されている場合のみ無視できます。
  1. トップメニュー Inventory から選択します。
  2. 画面の左側にある Resources メニューの下にある Discovery Queue 項目を選択します。
  3. 無視するリソースのチェックボックスを選択します。親リソースを選択すると、その子がすべて自動的に選択されます。
  4. ページ下部の Ignore ボタンをクリックします。
注記
プラットフォームは無視できません。プラットフォームがインベントリーに置くべきでない場合は、そのマシンでエージェントを実行しないでください。

5.2.5. インポートされたリソースの無視

リソースを JBoss ON インベントリーにインポートすると、サーバーと管理エージェントを無視するように設定できます。JBoss ON ユーザーインターフェースには、リソースを無視するように設定した場所が 3 つあります。
  • Inventory Resources ページ
  • 親リソースの Inventory ページ。
  • Groups リソースインベントリーページ。
注記
無視するリソースが発見されてもインベントリーにインポートされていない場合は、を参照してください 「検出したリソースの無視」
注記
プラットフォームは無視できません。プラットフォームがインベントリーに含まれない場合、そのマシンで JBoss ON エージェント を削除する必要があります。

5.2.5.1. Resources ページからのリソースの無視

  1. Inventory メニューから、の該当するリソースビューを選択し Resourcesます。例:
    • Inventory > Resources> All Resources、または
    • Inventory > Resources > Services.
  2. 無視するリソースが含まれる行を選択します。必要に応じて複数のリソースを選択できます。
  3. ページ下部の Ignore ボタンをクリックします。

5.2.5.2. 親リソースの Inventory ページからのリソースの無視

  1. Inventory メニューから、の該当するリソースビューを選択し Resourcesます。例:
    • Inventory > Resources> All Resources、または
    • Inventory > Resources > Services.
  2. リソースリストから親リソースを見つけ、選択します。
  3. 親リソースページで、Inventory タブ を選択します。
  4. 親リソース Inventory タブから Child Resources サブタブ を選択します。
  5. Child Resources 一覧から無視されるリソースを含む行を選択します。必要に応じて複数の行を選択できます。
  6. ページ下部の Ignore ボタンをクリックします。

5.2.5.3. Groups ページからのリソースの無視

  1. Inventory メニューから、の該当するリソースグループを選択し Groupsます。例:
    • Inventory > Groups> All Groups、または
    • Inventory > Groups > Compatible Groups
  2. 無視するリソースが含まれるリソースグループを見つけます。
  3. リソースグループページで、Inventory タブ を選択します。
  4. リソースグループタブから Members サブ Inventory タブ を選択します。
  5. Members 一覧から無視されるリソースを含む行を選択します。必要に応じて複数の行を選択できます。
  6. ページ下部の Ignore ボタンをクリックします。

5.2.6. リソース種別の完全な無視

の手順は、システムで検出された後、特定のリソースを 1 つ 「検出したリソースの無視」 無視します。そのプラットフォームまたは他のプラットフォーム上の同じタイプの他のリソースも検出され、インベントリーに含まれます。1 つのリソースが検出プロセスに影響を与えないことを無視します。
ただし、インベントリーにインポートされない特定のタイプのリソースが存在する可能性があります。たとえば、ファイルシステムリソースは常にプラットフォームで無視され、低レベルの EJB サービスは EAP 6 サーバーで常に無視されます。このようなインスタンスでは、エージェントのリソースを検出するためのメンテナンスのオーバーヘッドがあり、管理者が手動で無視し、それらを無視するリソースとしてインベントリーで維持することができます。
特定の タイプ のリソースが JBoss ON によって監視または管理されない場合、リソースタイプ全体は無視されます。これは基本的に、そのリソースタイプの検出を無効にします。
リソースタイプを無視してグローバルな JBoss ON の設定で、JBoss ON サーバー設定で設定されます。
注記
プラットフォームは無視できません。プラットフォームがインベントリーに置くべきでない場合は、そのマシンでエージェントを実行しないでください。
  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Configuration メニューテーブルで、Ignored Resource Types 項目を選択します。
  3. ロードされたエージェントプラグインに基づいて利用可能なすべてのリソースタイプが Ignored Resource Types ページに表示されます。リソースを無視するには、鉛筆アイコンをクリックします。
    これは、リソースを無視して現在の enabled/disabled 設定をすべて切り替えます。リソースタイプが有効な場合は、エージェントにより検出されます。無効にされている場合は無視されます。
  4. ページの下部までスクロールし、Save ボタンをクリックします。

5.3. 検出に必要なリソース

リソースや、リソースを検出するために JBoss ON エージェントに特定の設定を必要とするリソースタイプがいくつかあります。

5.3.1. EAP インスタンスを検出するエージェントの設定

に記載されているように 4章エージェントおよびリソースのシステムユーザーとの対話、エージェントを実行するシステムユーザーは、エージェントが特定のリソースタイプを管理する方法に直接影響します。EAP インスタンスの場合、エージェントのシステムユーザーに EAP リソースを管理できるように適切なパーミッションが必要です。
  • JBoss EAP 5 以前では、エージェントにはファイルに対する読み取り権限が必要です。さらに、run.jar ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になり run.jar ます。
  • JBoss EAP 6 および 7 の場合、エージェントはアプリケーションサーバーの設定ファイルへの読み取り権限を持っている必要があります。
  • RPM から JBoss EAP インスタンスをインストールする場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。

5.3.2. 検出用 Tomcat/EWS サーバーの設定(Windows)

Tomcat サーバーは Linux および Unix システム上で自動的に検出されますが、Windows システムで検出する前に追加の設定が必要になります。
  1. を実行し regeditます。
  2. Tomcat サーバー、HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun2.0\TomcatVer#の Java 設定キーに移動し\Parameters\Javaます。
  3. Options 属性を編集して、以下のパラメーターを追加します。
    -Dcom.sun.management.jmxremote.port=9876
    -Dcom.sun.management.jmxremote.ssl=false
    -Dcom.sun.management.jmxremote.authenticate=false
  4. Tomcat サービスを再起動します。
数分後、Tomcat インスタンスが Discovery Queue に表示されるはずです。

5.4. 新規リソースの手動によるインポート

検出スキャンは、定義されたスケジュールで実行されます。プラットフォームに新しいサーバーやサービスを追加し、次回のスケジュールされた検出を実行する前に即座に JBoss ON インベントリーに追加するインスタンスがある可能性があります。次の検出スキャンを待たずに、親リソースのインベントリーにインポートすることで、新しい子リソースを手作業で追加できます。
注記
子リソースをインポートするには、親リソースが available の状態である必要があります。
  1. トップメニューの Inventory タブをクリックします。
  2. 新しいリソースの親リソースを検索します。
    2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
  3. 親リソースの Inventory タブをクリックします。
  4. Inventory タブ下部の Import ボタンをクリックして、子リソースの種類を選択します。選択メニューは、その親が可能な子リソースのタイプを一覧表示します。
  5. プロパティーを入力し、新しいリソースを特定して接続します。システム内の各リソースタイプには、必要なプロパティーのセットが異なります。

5.5. 国リソースの作成

JBoss ON では、親リソースに特定のタイプの子リソースを作成できます。たとえば、Postgres サーバーを使用すると、JBoss ON で Postgres ユーザーを作成できます。リソースに許可されるすべての子リソースタイプは、JBoss ON UI を使用して作成できません。通常、これらの子は通常、スクリプト、WAR/EAR ファイル、サーバーユーザーなどのリモートで設定可能なリソースタイプに制限されます。
注記
子リソースを追加するには、親リソースが利用可能である必要があります。
注記
新しいリソースをローカルシステムで作成し、エージェントで検出する必要があるため、新しい子リソースが JBoss ON インベントリーに追加および認識されるまでに数分かかることがあります。リソースの作成時に検出スキャンが実行中である場合、検出スキャンが検出されるまでかかることがあります。
  1. トップメニューの Inventory タブをクリックします。
  2. 新しいリソースの親リソースを検索します。
    2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
  3. 親リソースの Inventory タブをクリックします。
  4. Inventory タブ下部の Create Child ボタンをクリックして、子リソースの種類を選択します。選択メニューは、その親が可能な子リソースのタイプを一覧表示します。
  5. 新しいリソースの名前および説明を記入します。
  6. プロパティーを入力し、新しいリソースを特定して接続します。システム内の各リソースタイプには、必要なプロパティーのセットが異なります。

5.6. リソース情報の表示および編集

すべてのリソースには、名前、説明、バージョンなどの表示可能なサーバーまたはサービスの詳細があります。(特定の情報はリソースタイプごとに異なります。) これらの詳細は通常リソースを表示するときに非表示になりますが、リソース名で矢印をクリックして詳細領域を拡張することで表示できます。

図5.2 リソースエントリーの詳細の拡張

リソースエントリーの詳細の拡張
緑色のテキストのフィールドはすべて編集できます。これにより、管理者はエージェント検出が提供するエリアの詳細や有用な情報(リソース名など)を使用するか、説明や、プラットフォームの物理的な場所など、情報を追加することができます。
フィールドを編集するには、名前にカーソルを合わせ、表示される鉛筆アイコンをクリックします。
編集を行ったら、緑色のチェックマークをクリックして変更を保存します。

5.7. 接続設定の管理

接続設定 は、エージェントをリソースに接続する方法を定義します。これらの設定はエージェントプラグインで定義される設定であるため、リソースタイプごとに異なります。
少なくとも、接続設定は、ポート番号、ディレクトリーパス、ユーザーの認証情報など、エージェントがリソースに接続する方法を提供します。
注記
多くの場合、リソースが実行中でも可用性がダウンしている場合は、接続設定に問題があることになります。エージェントには、ユーザー名や新しいポート番号など、リソースへの接続に必要な情報がない場合があります。エージェントはリソースに接続できないため、停止していることを前提としています。
接続設定は、操作のスクリプトで使用するパスやオプション、イベント監視用のログファイルの場所、リソース設定の編集を可能にする設定ファイルなど、プラグイン記述子で定義されるその他の制御の構成も提供します。
接続設定を編集するには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
    2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
  3. リソースの名前をクリックして、そのエントリーページに移動します。
  4. リソースの Inventory タブを開き、Connection Settings サブタブをクリックします。
  5. リソースの接続情報を変更します。
    フィールドがすぐに編集できない場合は、Unset チェックボックスを選択し、フィールドに新しい情報を入力します。
  6. Save ボタンをクリックします。

5.8. リソースのアンインベントリーおよび削除

リソースは、未使用の(すべてのリソース)いずれかの方法で JBoss ON インベントリーから削除でき、削除することができます(コンテンツベースのリソースまたは設定関連リソース)。

5.8.1. リソースの削除とリソースの比較

リソースを永続的に解除すると、そのリソースに関するすべてのデータが JBoss ON インベントリーから削除されます。これにより、過去の監視データ、設定および操作履歴、アラート、ドリフト定義、およびその他の保存されたデータがすべて削除されます。ただし、リソース自体はそのまま残りますが、マシンに引き続き存在し、後で(新しいリソースとして)再検出できます。
どのリソースも未使用になります。
一方、リソースを削除すると、マシン自体から リソースが完全に削除されます。したがって、EAR リソースを削除すると、親 EAP インスタンスから EAR が削除されます。ただし、そのリソースのインベントリー情報は、履歴的なメトリックデータ、設定履歴、およびバージョン履歴(コンテンツリソース用)はそのまま残り、その子の新規バージョンがデプロイされていれば、元の履歴がすべて保持されます。
検出キュー(デプロイされた EAR ファイルや作成されたデータソースなど)で検出されないリソースのみを削除できます。

5.8.2. リソースの削除時の注意事項の使用

Uninventory Irrevably delete the Resource History and Data(リソース履歴とデータの削除)

リソースのインベントリーを解除すると、そのリソースに対して JBoss ON が必要とするすべてのデータが削除されます。メトリックデータと履歴監視データ、アラート、ドリフトと設定履歴、操作履歴などのデータが削除されます。リソースがインベートされないと、そのデータを復元することはできません。

リソースをすべて削除または削除

JBoss ON から親リソースが削除されると、その子もすべて削除されます。たとえば、EAP サーバーを削除すると、JBoss ON インベントリーからデプロイされた web アプリケーションがすべて削除されます。プラットフォームを削除すると、そのプラットフォーム上のサーバー、サービス、およびリソースがすべて削除されます。

検出される未使用のリソース

リソースが未使用で、JBoss ON のデータが永続的に削除されますが、基礎となるリソースは引き続き存在します。これは、リソースをまだ検出できることを意味します。リソースがインベントリーに検出され、再度追加されないようにするには、にあるようにリソースを無視し 「検出したリソースの無視」 ます。

削除されたリソースに依存するものが失敗しました。

一部のリソースタイプは削除できます。つまり、JBoss ON のインベントリーだけでなく、リソース自体がマシンから削除されます。そのリソースに依存するものはすべて、リソースが削除されるため、エラーが発生する可能性があります。たとえば、EAP サーバーのデータソースが削除されると、データソースは EAP サーバー自体から削除されます。データソースへの接続を試みるアプリケーションは、存在しないため、動作を停止します。

5.8.3. インベントリータブからのインベントリーの解除

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources テーブルにあるリソースカテゴリーを選択し、必要に応じてリソースに対してフィルターをかけます。
  3. 一覧からインベントリーを解除するリソースを選択し、Uninventory ボタンをクリックします。
  4. プロンプトが表示されたら、リソースが適切に行われないようにすることを確認します。
  5. リソースがインベントリーに再インポートされないようにするには、次の検出スキャンで見つかったときにそのリソースを無視します。これは、で説明してい 「検出したリソースの無視」 ます。

5.8.4. 親インベントリーからのインベントリーの未使用

  1. トップメニューの Inventory タブをクリックします。
  2. リソースの親リソースを検索します。
    2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
  3. 親リソースの Inventory タブをクリックします。
  4. 子リソースの行をクリックして、インベントリーを解除します。複数のエントリーを選択するには、Ctrl キーを使用します。
  5. Uninventory ボタンをクリックします。
  6. プロンプトが表示されたら、リソースが適切に行われないようにすることを確認します。
  7. リソースがインベントリーに再インポートされないようにするには、次の検出スキャンで見つかったときにそのリソースを無視します。これは、で説明してい 「検出したリソースの無視」 ます。

5.8.5. グループインベントリーからのインベントリーの解除

リソースがグループのメンバーである場合、グループリソースの管理の一環として、リソースはグループ管理ページを通じて未確定になります。
  1. トップメニューの Inventory タブで、Groups 左側のメニューで互換性のあるグループアイテムまたは混合グループアイテムを選択します。
  2. グループの名前をクリックします。
  3. グループの Inventory タブを開き、Members サブメニューを開きます。
  4. インベントリーを解除するグループメンバーの行をクリックします。複数のエントリーを選択するには、Ctrl キーを使用します。
  5. Uninventory ボタンをクリックします。
  6. プロンプトが表示されたら、リソースが適切に行われないようにすることを確認します。
  7. リソースがインベントリーに再インポートされないようにするには、次の検出スキャンで見つかったときにそのリソースを無視します。これは、で説明してい 「検出したリソースの無視」 ます。

5.8.6. リソースの削除

リソースを削除すると、以下のような操作が行われます。
  • 基礎となるマシンからリソースを削除します。
  • インベントリーからリソースを削除します。
  • JBoss ON から子リソースを削除します。
  • アラート、ドリフト定義、メトリクスデータ、設定および操作履歴など、リソースに対してインベントリー情報を JBoss ON に保存します。
検出キューからインポートされて いない リソースのみを削除できます。これは通常、コンテンツベースのリソース(EAR、WAR、JAR)およびデータソースなどのその他の子リソースを削除できます。
警告
実際のベースとなるリソースは(インベントリーエントリーだけでなく)削除されるため、そのリソースに依存するものはすべて失敗する可能性があります。
  1. トップメニューの Inventory タブをクリックします。
  2. 削除するリソースの リソースを検索します。
    2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
  3. 親リソースの Inventory タブをクリックします。
  4. 子の一覧から削除するリソースを選択します。
  5. Inventory タブの下部にある Delete ボタンをクリックします。

5.9. インベントリーサマリーレポートの表示

JBoss ON のクイック管理ツールの 1 つがインベントリーレポートです。レポートは、リソースタイプ別にグループ化されたインベントリー内のリソースを、要約 5 つにまとめています。
  • リソースタイプ
  • リソースを管理する JBoss ON サーバープラグイン
  • リソースの JBoss ON カテゴリー(プラットフォーム、サーバー、またはサービス)
  • インベントリーのリソースタイプのバージョン番号
  • インベントリー内のそのタイプのリソースの合計数
インベントリーレポートを生成するには、以下を実行します。
  1. トップメニューで、Reports タブをクリックします。
  2. 左側の Inventory メニューテーブルのメニューボックスで、Inventory Summary レポートを選択します。
  3. リソースタイプの名前をクリックして、対象のリソースタイプのインベントリー一覧に移動します。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ inventorySummary.csvます。


[1] プロビジョニング Ant バンドルは、プラットフォームでタスクを実行するエージェントプラグインと、サーバーのバンドルを管理するサーバー側のプラグインにより実装されます。

第6章 グループの管理

グループは、リソースを整理するためのシンプルかつ実用的な方法です。特に、多くのリソースがある場合や、部門、IT 環境、物理的な場所でリソース間に論理的な分割がある場所が考えられます。
JBoss Operations Network のグループは、リソースを一貫して管理する方法を提供します。アラート、操作、設定は個別のリソースまたはリソースのグループ全体に適用できますが、グループは単一のビューから監視できます。

6.1. グループ

グループは、JBoss ON インベントリー内でリソースを整理する手段です。JBoss ON には、に記載されているさまざまなグループがあります。これにより 表6.1「グループの種類」、管理者は異なる柔軟な方法でリソースを管理できます。

表6.1 グループの種類

type description 静的または動的
混合グループ 任意のリソースタイプのリソースが含まれます。混合グループに配置できるリソースの数やタイプには制限はありません。混合グループは、グループ化されたリソースセットに対してユーザーにアクセスパーミッションを付与する際に便利です。 static
互換性のあるグループ 同一タイプのリソースのみが含まれます。互換性のあるグループにより、グループの全メンバーに対して同時に操作を実行でき、同じタイプの複数のリソースを個別にアップグレードする必要がなくなります。また、企業全体のリソースに対して 1 度に他の操作を実行することもできます。 static
再帰グループ グループ内のすべての子リソースが含まれます。再帰グループは、明示的なメンバーの可用性と子リソースの可用性の両方を表示します。 static(メンバー)および動的(children)
autogroups すべてのリソースを、上部のプラットフォームでリソース階層の一部として表示し、プラットフォームの下の子リソースおよび子リソースを表示します。同じタイプの子リソースは自動的に autogroup にグループ化されます。 動的

6.1.1. 動的および静的グループ

グループとは、リソースを整理する方法です。異なるタイプのグループはで説明されていますが 、それらのグループはすべて 2 つのカテゴリーの 1 つに分類されます。グループは、リソースがグループに割り当てられている方法に応じて 静的 または 動的 になります。静的グループには、グループに明示的に割り当てられるリソースがあるため、インベントリーを変更してもメンバーシップは変更されません。動的グループは何らかの検索基準に基づいており、グループメンバーは検索で返されるすべてのリソースです。インベントリーが更新されると、検索結果が変更され、グループメンバーシップが自動的に更新されます。
静的および動的グループは、リソースの管理に役立ち、IT 環境全体を把握することができます。

6.1.2. 自動グループについて

JBoss ON には、リソースを手動で追加する静的グループと、何らかの確立された基準に基づいてリソースが自動的に追加される静的グループという 2 つのタイプのグループがあります。
管理者は、で説明している定義された検索に基づいて動的グループを設定でき 7章動的グループの使用 ます。JBoss ON は、autogroup と呼ばれる異なるタイプの動的グループをサポートし ます。autogroups は、JBoss ON UI でインベントリーナビゲーションツリーを作成するために使用されます。これらは基盤のリソース階層または親子関係に基づいています。また、autogroups はリソースタイプごとにグループ化されます。たとえば、に 図6.1「PostgreSQL 自動グループ」、すべての子に対して Postgres リソースに autogroups があります。これは、子リソースタイプ、データベース、ユーザーを基にしてさらに分割されます。

図6.1 PostgreSQL 自動グループ

PostgreSQL 自動グループ
JBoss ON の他のグループとは異なり、autogroups は JBoss ON ユーザーによって設定できません。自動グループは JBoss ON サーバーの内部で定義され、JBoss ON によって使用されます。

6.1.3. 互換性のあるグループと混合グループの比較

グループを使用すると、複数のリソースを同時に管理できます。互換性のあるグループのタイプまたは混在: グループメンバーで実行できる管理の種類を指定します。
互換性のあるグループは、すべてのメンバーが同じタイプを持つため、単一のリソースと同様に簡単に管理できます。管理者は、リソース設定、起動操作、アラートの設定、およびグループ対応監視データの表示を行うことができます。すべての変更は、1 つのグループメンバー、選択したメンバー、またはグループ全体に対して実行できます。グループメンバーの一覧(グループインベントリー)は Inventory タブから管理されます。

図6.2 互換性のあるグループエントリー

互換性のあるグループエントリー
混合グループには異なるリソースタイプのメンバーを含めることができるため、グループ管理はメンバー(グループインベントリー)を更新し、グループメンバーのアラートおよびイベントの履歴を表示するために限定されます。

図6.3 混合グループエントリー

混合グループエントリー

6.1.4. 再帰グループの使用

互換性のあるグループおよび混合グループは、セットの明示的なメンバーシップを持ちます。この静的構造は信頼できるため、JBoss ON 内にポリシーを作成するのに役立ちます。
互換性のあるグループおよび混合グループは、再帰的 に設定することが可能です。再帰グループはすべてのメンバーのインベントリー下に移動し、暗示的にそのすべての子をグループに追加します。よって、再帰グループにはメンバーの 2 つの層があります。これは、グループへの明示的なメンバーと、子メンバーの暗黙的なセットです。
2 つのレベルのメンバーという概念により、グループは独自のタイプ定義を保持します。つまり、子がメンバーとして追加されているため、互換性のあるグループを混在グループに変更しないことを意味します。明示的なメンバーシップは ルートノード と呼ばれます。グループ操作では、メンバーの追加からメトリクススケジュールの設定から接続設定の変更など、そのルートノードでのみ実施されます。
再帰グループは、多くの方法で役に立ちます。
たとえば、再帰的に互換性のあるグループは、すべての子リソースがタイプによってグループ化されるため、インベントリー内の autocluster のサブセットを確認するために使用できます。これは、すべての子リソースがそれらの親リソースと同様にグループ化されるためです。これにより、リソースのサブセットで簡単に確認できます。(タイプごとにグループ化されない静的なグループは、階層内のルートノードまたは明示的なメンバーのみを表示します。)
より重要な用途の 1 つは、承認制御に再帰グループ(特に混合再帰グループ)を使用することです。これはより詳しく説明されていますが 9章ロールおよびアクセス制御の管理、ユーザーとリソースを同じロールに追加して、リソースを明示的にアクセス権限を付与する必要があります。再帰グループを使用すると、ロールにそれらのリソースの子すべてが自動的に含まれ、ロールのメンテナンスが容易になり、アクセス権限がより正確になります。

6.2. グループの作成

グループを作成するには、ユーザーがグローバルセキュリティーまたはインベントリーパーミッションを持っている必要があります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側のメニューで Groups、互換性があるか、または混在するグループのタイプを選択します。
    互換性のあるグループは、すべて同じタイプのリソースを持ちますが、混合グループは異なるタイプのメンバーを持ちます。メンバーのタイプの違いは、で説明しているように、互換性のあるグループや混合グループを管理する方法が異なることを意味し 「互換性のあるグループと混合グループの比較」 ます。
  3. グループの名前と説明を入力します。
    グループを再帰的にマークすると、特にロールのアクセス制御を設定する際にリソースの管理が容易になります。たとえば、管理者はグループにアクセス権を付与し、メンバーリソースの子リソースを自動的に含めることができます。
  4. グループメンバーを選択します。名前、タイプ、およびカテゴリーに基づいて選択を絞り込むことができます。

6.3. グループメンバーシップの変更

互換性のあるグループと混合グループはいずれも静的メンバーを持ち、一部の属性に基づいて動的に割り当てられるのではなく、リソースはグループに手動で割り当てられます。グループメンバーシップは、JBoss ON のインベントリー変更のリソースとして変更できます。
  1. トップメニューの Inventory タブで、Groups 左側のメニューで互換性のあるグループアイテムまたは混合グループアイテムを選択します。
  2. グループの名前をクリックします。
  3. グループの Inventory タブを開き、Members サブメニューを開きます。
  4. ページ下部の Update Membership ボタンをクリックします。
  5. 左側のボックスからグループに追加するリソースを選択します。メンバーを削除するには、右側のボックスからメンバーを選択します。選択したリソースを移動するには、矢印を使用します。複数のリソースを選択するには、Ctrl+click を使用します。
  6. Save ボタンをクリックします。

6.4. 互換性のあるグループ接続プロパティーの編集

互換性のあるグループは、インベントリーの一部としてグループメンバーの 接続プロパティー を管理します。互換性のあるグループには、同じリソースタイプのメンバーのみを含めることができるため、集計ビューまたは各接続プロパティーの平均を表示することができます。接続設定は、エージェントまたはサーバーがリソースに接続する方法を定義します。
ルールは、互換性のあるグループ接続の値を簡単に行うことができます。
  • グループ内のすべてのリソースにプロパティーの値が同じである場合、グループコネクションプロパティーはその正確な値になります。
  • 1 つのリソースに、グループの残りのリソースとは異なる値がある場合、そのプロパティーには特別なマーカーの値が ~ Mixed Values ~ になります。
コネクションプロパティーを編集するには、以下を実行します。
  1. トップメニューの Inventory タブで、Groups 左側のメニューの Compatible Groups 項目を選択します。
  2. 互換性のあるグループの名前をクリックします。
  3. グループの Inventory タブを開き、Connection Settings サブ項目をクリックします。
  4. プロパティーを編集するには、フィールド別に鉛筆をクリックします。
  5. すべてのリソースを同じ値に変更するには、フィールドの Unset チェックボックスをクリックし Set all values to...ます。特定のリソースを変更するには、そのリソースの Unset チェックボックスをクリックし、新しい値を指定します。
注記
inventory タブを更新すると、グループ内の各リソースの接続プロパティーの 現在 の値が表示されます。更新が完了していなくても、リソースの接続プロパティーの一部が正常に変更された場合は、中間値が表示されます。これらの値を無視します。更新が完了したら、ページを更新して最終的な結果を表示します。
Connection Settings History サブ項目は、接続プロパティーに加えられた変更を表示します。障害が発生した場合は、Date Created コラムの送信をクリックすると、関連するエラーメッセージが表示されます。

第7章 動的グループの使用

動的グループは、インベントリーの検索に使用する検索用語を指定し、グループに属する一致するリソースを特定します。検索結果は、結果が追加および削除されると自動的に変更されるため、グループメンバーシップは常に変更され、常に最新の状態になります。動的グループを使用すると、大規模な履歴の管理タスクを自動化できます。
注記
動的グループは、ニックネーム Dynagroups によって参照され ます
エンタープライズリソースは、クラスター ID、ブロードキャストグループ、論理サービス層、地理的な場所、セキュリティードメイン、またはその他の論理グループを使用してグループ化できます。
個別のリソースは複数のグループに属する可能性がありますが、大規模な資料では、複数のグループ定義が企業リソースにどのように影響するかを知ることが重要です。

7.1. 動的グループ構文

動的グループは、グループ定義 で設定されます。グループ定義は、リソースの検索を定義する と、再計算の間隔などのグループに関するその他の情報を定義します。
動的グループには、動的検索(「動的検索構文について」)に使用される式構文と非常に似ています。

7.1.1. 一般的な式構文

は、属性の特定の値によって、特定のリソース属性を中心とするか、単に属性が存在するだけで特定のリソース属性を中心とした検索条件です。
式は、リソースをグループ化する方法を定義します。
  • 特定のリソース属性または値( 簡単 な式)
  • リソースタイプ(ピボットテーブル
  • 別のグループのメンバー別( 絞り込む 式)
1 つのグループ定義は複数の式を持つことができます。グループ定義の式の順序は問題ありません。たとえば、グループメンバーの計算時に、両方の式が全く同じ解釈されます。
expression 1
exprA1 
exprA2 
groupby exprB1 
groupby exprB2

expression 2
exprA2 
exprA1 
groupby exprB2 
groupby exprB1
注記
複数の式がグループ定義で使用される場合、それらは論理 AND 表現として扱われ、リソースはそのグループに属するすべての基準と一致する必要があります。
dynagroup 定義の式の間の空の行は無視されます。
設定可能なリソースプロパティーは、リソース名、タイプ、プラグイン、バージョン、設定プロパティー、インベントリー ID 番号などのリソース情報を対象とします。

表7.1 動的グループプロパティー

type サポートされる属性
リソース自体に関連する
resource
id
Name
version
parent
grandparent
リソースタイプに関連する
resourceType
plug-in
Name
カテゴリー(プラットフォーム、サーバー、サービス)
リソース設定に関連する
plug-inConfiguration
プラグイン設定プロパティー
resourceConfiguration
すべてのリソース設定プロパティー
リソースモニタリングデータに関連する
traits
任意の監視特性
可用性
UP または DOWN のいずれかの現在の状態
式に structure resource.属性 がある場合、これはグループのメンバーとなるリソースに適用されます。ただし、先祖エントリーまたは子エントリーの属性を使用して、グループメンバーを再帰的に特定することが可能です。
たとえば、リソースをインベントリー ID 10001 としてメンバーとして追加するには、式は以下のようになります。
resource.id = 10001
ID が 10001 のリソースの をすべてグループメンバーとして追加するには、プレフィックスを使用し resource.parentます。
resource.parent.id = 10001
には、表7.1「動的グループプロパティー」 以下のすべてのリソース属性の接頭辞が 4 つあります。
  • resource
  • resource.child
  • resource.parent
  • resource.grandParent
定義が制限され、フィルターに一致するリソースがない場合は、グループは作成されません。JBoss ON は、実際にグループ定義により作成されないようにするため、空のグループになります。空のグループがないため、インベントリーにリストされている余分なグループがないため、実際のインフラストラクチャーを反映して管理が容易になります。

7.1.2. 単純な式: 値の検索

単純な式は、属性と値のペアまたはこの形式でトリドを使用します。
resource.attribute[string-expression] = value
例:
resource.parent.type.category = Platform
リソース属性にはすべて string-expression が追加されているわけではありません。string-expression は基本的にサブ属性です。たとえば、resource.trait は 汎用リソース属性で、partitionName などのサブ属性は実際のパラメーターを 特定 します。
単純な式は通常明示的な値に基づいてリソースを検索しますが、リソースには null 値を持つ属性があり、これらの null 値は単純な式で返されません。empty キーワードは、null 値を持つ特定の属性を持つリソースを検索します。
empty resource.attribute[string-expression]
empty キーワードを使用する場合は、式で指定される はありません。
simple 式は、null ではない限り、属性の値に関係なく、その属性を持つすべてのリソースを検索する not empty キーワードも使用できます。empty キーワードと同様に、すべての値が式と一致するため、式に を指定する理由はありません。
not empty resource.attribute[string-expression]

7.1.3. ピボットテーブル: 属性によるグループ化

簡単な式は検索の特定の結果に基づいて、1 つのグループを作成します。ピボットテーブルは複数のグループを作成 します。これは、属性が存在するかどうかに基づいてグループに属するリソースを特定し、値に基づいてサブグループを作成します。ピボットテーブル式では groupby キーワードを使用します。
groupby resource.attribute
ピボットテーブルの式は、属性値の一意の出現に基づいてグループを作成します。たとえば、parent.name 属性はすべての親リソースに基づいて一意のグループを作成します。
groupby resource.parent.name
のリソースについて 図7.1「リソースおよび親」、ピボットテーブルはリソース階層内で ResourceParentA、ResourceParentB、および✓A2 の 3 つの固有のグループを作成します。

図7.1 リソースおよび親

リソースおよび親
グループ定義全体に null 値を持つリソースが含まれる場合、ピボットテーブル式はこれらのリソースが含まれる特別なサブグループを作成します。

7.1.4. 式の絞り込み: グループのメンバー

式は通常、インベントリー 全体 で評価されます。たとえば、JBoss AS 7 Server リソースタイプのピボットテーブル式を設定すると、EAP 6 または AS 7 インスタンスごとにインベントリーがチェックされます。
特に、アクセス制御またはバンドル管理用に粒度の細かいグループを作成しようとすると、同じタイプのリソースのサブセットを取得するために複雑な式を作成しようとするより、既存のグループのメンバーに対して実行する式を定義する方が簡単です。
これは、memberof キーワードを指定して行われます。これは、グループ名(互換性のあるグループ、複数のグループ、自動グループ、再帰グループ、別の dynagroup であっても)を指定し、そのグループのメンバーのみが他の一致式に対して評価されます。
注記
memberof キーワードはグループ名を指定します。グループが再帰グループの場合、評価のためにすべての再帰メンバーがグループの一部として組み込まれます。
たとえば、管理者は開発チーム、QE、および実稼働チーム向けのアプリケーション開発関連リソースに異なるグループを作成します。これらは、プラットフォーム、Postgre データベース、EAP 6 サーバー、および Web コンテキストの混合グループです。新しいリソースがデプロイされると、CLI スクリプトを実行してリソースをインポートし、リソースグループを自動的に更新します。アクセス制御ルールとロールは、リソースタイプに基づいて、Dev Stack Resource Group、複数のグループ内のサブグループおよび リソースタイプに基づいてメイングループの両方を使用する必要があります。複数のグループおよびロールは、リソースがデプロイまたは削除されるたびに作成および更新するの はなく、まず指定のチームリソースグループに式の範囲を絞り込み、リソースタイプ別にピボットします。Dynagroup の定義は一度だけ設定する必要があります。また、グループが再計算されるたびに、インベントリーの変更で動的に更新されます。
memberof = "Dev Resource Group"
groupby resource.type.name
注記
グループメンバーシップは、他の式と同様に、dynagroup が再計算される時にのみ memberof 変更で更新されます。
グループ定義では複数の memberof 式が許可され、1 つのグループを参照する各 memberof 式を使用できます。複数の memberof 式が使用される場合、それらは AND 式として扱われます。一致するリソースは すべて指定されたすべて のグループのメンバーである必要があります。

7.1.5. 複合式

複数の式を 1 つの dynagroup 定義で使用できます。これらは 複雑な 式です。
複数の式がグループ定義で使用される場合、それらは論理 AND 表現として扱われ、リソースはそのグループに属するすべての基準と一致する必要があります。(Dynagroup 定義の式間の空の行は無視されます。)
たとえば、この基本的な式は、プラットフォームを親として持つすべてのリソースを検索します。
resource.parent.type.category = Platform
これにより、サーバーおよびサービスの非常に長いリストが返されます。その初期リストは、名前でフィルターする別の簡単な式を追加して、さらに絞り込むことができます。
resource.parent.type.category = Platform
resource.name.contains = JBossAS
プラットフォームが親として、JBossAS が名前に指定 リソースのみがグループに追加されます。
ピボットテーブルの式は複合式でも使用することができます。すべての行には groupby キーワードを含める必要があります。最初の行だけでなく、groupby キーワードが必要です。
groupby resource.type.plugin
groupby resource.type.name 
groupby resource.parent.name
複合式には、単純な式とピボットテーブルの両方を含めることができます。これにより、プラットフォーム上の一意のサーバータイプごとに互換性のあるグループが作成されます。
resource.type.category = server 
groupby resource.type.plugin 
groupby resource.type.name 
groupby resource.parent.name
最後に、複合式には空のキーワードを含めることができ、空のキーワードは含まれません。たとえば、簡単な式を使用して、リソースタイプと名前を基にして JBoss サーバーを特定できます。その後、どの JBoss サーバーがセキュアであるかを特定するために、式は空のプリンシパル接続プロパティーで JBoss サーバーのフィルターを実行できます。
resource.type.plugin = JBossAS
resource.type.name = JBossAS Server
empty resource.pluginConfiguration[principal]

7.1.6. サポートされない式

複数の式を一緒に使用する方法には制限があります。

すべての式が同じ設定エリアにある必要があります。

式のすべての設定プロパティーはリソース設定からのみ、またはプラグイン設定のみである必要があります。両方から式を取ることはできません。

各プロパティーは一度だけ使用する必要があります。

プロパティーは、dynagroup 定義で 1 回のみ使用できます。

valid
resource.trait[x] = foo

not valid
resource.trait[x] = foo
resource.trait[y] = bar
たとえば、resource.trait 式は定義で 1 回だけ発生するだけです。
resource.grandParent.trait[Trait.hostname].contains = stage
resource.parent.type.plugin = JBossAS5
resource.type.name = Web Application (WAR)
1 秒未満の時間(またはそれ以上)を使用すると、後続の使用に失敗し、定義が解析されません。
resource.grandParent.trait[Trait.hostname].contains = stage
resource.parent.type.plugin = JBossAS5
resource.type.name = Web Application (WAR)
resource.trait[contextRoot] = jmx-console
これにより、計算エラーが発生します。
There was a problem calculating the results: java.lang.IllegalArgumentException: org.hibernate.QueryParameterException: could not locate named parameter [arg2]
[arg2] エラーは、同じ型の複数の式が使用されており、2 つ目の式によって計算に失敗するという記号です。
これは、プロパティータイプが 異なる リソースコンテキストで使用される場合でも true になります。
resource.parent.trait[x] = foo
resource.grandParent.trait[y] = bar
この例では、グランド親リソースに適用された 1 つの特性と、リソース自体に 1 つの特性が適用されていました。trait プロパティーが異なるリソースであっても 2 回使用されたため、これは失敗しました。

7.1.7. Dynagroup 式の例

1 つのグループ定義には複数の式を含めることができ、1 つの定義で単純な式とピボットされた式を混在させることもできます。これらの例の多くは、定義を完了するために複数の式が必要です。

例7.1 JBoss クラスター

resource.type.plugin = JBossAS 
resource.type.name = JBossAS Server 
groupby resource.trait[partitionName]

例7.2 各プラットフォームタイプのグループ

resource.type.plugin = Platforms 
resource.type.category = PLATFORM 
groupby resource.type.name

例7.3 autogroups

groupby resource.type.plugin 
groupby resource.type.name 
groupby resource.parent.name
注記
これにより、多数のグループが大量に作成される可能性があります。

例7.4 未加工の測定テーブル

resource.type.plugin= Postgres 
resource.type.name = Table 
resource.parent.name = rhq Database 
resource.name.contains = rhq_meas_data_num_

例7.5 マルチキャスト検出のエージェントのみ

resource.type.plugin= RHQAgent 
resource.type.name = RHQ Agent 
resource.resourceConfiguration[rhq.communications.multicast-detector.enabled] =  true

例7.6 イベント追跡を含む Windows プラットフォームのみ

resource.type.plugin= Platforms 
resource.type.name = Windows 
resource.pluginConfiguration[eventTrackingEnabled] =  true

例7.7 マシン別に JBoss AS サーバー

groupby resource.parent.trait[Trait.hostname] 
resource.type.plugin = JBossAS 
resource.type.name = JBossAS Server

7.2. 動的グループの作成

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Groups メニューボックスで、Dynagroup Definitions リンクをクリックします。
  3. New ボタンをクリックして動的グループ定義フォームを開きます。
  4. 動的グループの名前と説明を入力します。グループの作成に使用するロジックを特定するために、定義で作成されたグループに付加されるため、この名前は重要になります。
  5. 検索式を入力します。これを行うには、Expression ボックスに式を直接入力するか、保存された式を使用します。
    保存された式には、式の構築および検証に役立つウィザードがあります。保存された式を作成するには、ドロップダウンメニューのボタンをクリックします。他の選択によって、式がアクティブであるか、非アクティブな式になるオプションもあります。これにより無効な式を防ぐことができます。
    上部の Expression ボックスに現在作成された式が表示されます。
  6. 式を入力したら、動的グループを再帰的にするかどうかを設定します。
  7. オプションの再計算の間隔を設定します。デフォルトでは、動的グループはメンバーを自動的に再計算しないため、再計算値は 0 に設定されます。グループメンバーシップを再計算するには、を Recalculation interval 時間頻度(ミリ秒単位)に設定します。
    注記
    大規模な履歴全体でグループ定義を再計算すると、JBoss ON サーバーのリソース集約となる可能性があるため、再計算の間隔を設定する場合は注意して行ってください。大規模の場合、JBoss ON サーバーのパフォーマンスに影響しないようにするため、1 時間などの長い間隔を設定します。

7.3. グループメンバーの再計算

動的グループは、グループ定義で設定される間隔とは別に再計算できます。グループ定義の再計算間隔は、最終更新時間に基づく相対値であるため、再計算を手動で開始しても、競合したり、通常の再計算に干渉したりしません。指定期間が経過した後に続行されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Groups メニューで、Dynagroup Definitions リンクをクリックします。
  3. dynagroups の一覧で、計算する dynagroup 定義の行を選択します。
  4. テーブルの下部にある Recalculate ボタンをクリックします。

第8章 ユーザーアカウントの作成

ユーザーは、アカウントに個別にアクセス制御が設定されていない場合でも、JBoss ON の完全なセキュリティー計画の一部となります。

8.1. rhqadmin アカウントの管理

JBoss ON がインストールされている場合、デフォルトのスーパーユーザーがすでに作成されてい rhqadminます。このスーパーユーザーにはデフォルトのパスワードがあり rhqadminます。
注記
この rhqadmin アカウントは、他のスーパーユーザーアカウントが作成されていても削除できません。また、のロール割り当ては変更 rhqadmin できず、常にスーパーユーザーアカウントになります。
重要
ユーザーが削除されると、ユーザーが所有するスケジュールされた操作がキャンセルされます。
インストール後に初めて JBoss ON にログインする場合は、スーパーユーザーパスワードを変更します。
  1. トップメニューの Administration タブをクリックします。
  2. 左側の Security 表で、を選択し Usersます。
  3. の名前をクリックし rhqadminます。
  4. ユーザーフォームの編集で、パスワードを新しい複雑な値に変更します。

8.2. 新規ユーザーの作成

  1. トップメニューの Administration タブをクリックします。
  2. 左側の Security 表で、を選択し Usersます。
  3. 現在のユーザーの下部にある NEW ボタンをクリックします。
  4. 新規ユーザーの説明を入力します。新規ユーザーアカウントがアクティブになるよう Yes に、Enable Login 値を設定する必要があります。
  5. Available Roles エリアから必要なロールを選択し、をポイントする矢印をクリックしてロール Assigned Roles を割り当てます。
  6. Save ボタンをクリックして、割り当てられたロールで新規ユーザーを保存します。

8.3. ユーザーエントリーの編集

すべてのユーザーは自身のアカウントの詳細を編集でき、管理者権限(ユーザーエントリーに対する権限が付与されているロールに属するユーザー)を持つユーザーは、他のユーザーのエントリーを編集できます。
  1. トップメニューの Administration タブをクリックします。
  2. Security メニューから、を選択し Usersます。
  3. エントリーを編集するユーザーの名前をクリックします。
  4. 編集ユーザーフォームで、詳細を変更する必要のある内容を変更し、保存します。

8.4. ユーザーアカウントの無効化

ユーザーアカウントを一時的に無効にできます。これは、セキュリティーレビューや何らかの違反があった場合に実行できますが、ユーザーは削除する必要はありません。この Enable Login プロパティーは、ユーザーが JBoss ON UI にログインし、リソースの管理や設定の変更を防ぎます。
  1. トップメニューの Administration タブをクリックします。
  2. 左側の Security 表で、を選択し Usersます。
  3. エントリーを編集するユーザーの名前をクリックします。
  4. ユーザーフォームの編集で、Enable Login ラジオボタンをに変更し Noます。
  5. Save ボタンをクリックして、割り当てられたロールで新規ユーザーを保存します。
この Enable Login 値を再度有効にするには、いつでもユーザーアカウントを有効にでき Yesます。

8.5. ユーザーのロール割り当ての変更

  1. トップメニューの Administration タブをクリックします。
  2. Security メニューから、を選択し Usersます。
  3. 編集するユーザー名をクリックします。
  4. ロールをユーザーに 追加 するには、そのエリアから必要なロールを選択するには、その Available Roles エリアを指す矢印をクリックし Assigned Roles ます。ロールを 削除 するには、右側に割り当てられたロールを選択し、左側の矢印をクリックします。
  5. Save をクリックし、ロールの割り当てを保存します。

第9章 ロールおよびアクセス制御の管理

JBoss Operations Network では、ユーザーおよびロール に設定されたルールを使用してセキュリティーが実装されます。制限は、アクセス可能なユーザーとロールに、実行できる操作に設定されます。

9.1. JBoss ON のセキュリティー

セキュリティーは、ユーザー、リソース、およびユーザーが実行できるタスク間の正確な関係を確立します。ユーザーとリソース間の対話は、定義されたロールでそれらのユーザーとリソースを追加または除外して順序付け、続いてタスクを実行する権限を ロール に付与します。

9.1.1. アクセス制御およびパーミッション

ユーザーが特定の操作を実行できる場合は、パーミッション と呼ばれます。すべてのパーミッションは明示的なリソースに明示的に付与する必要があります。特定のリソースグループにユーザーがパーミッションを付与されていない場合、デフォルトでは、ユーザーにはタスクを実行するパーミッションがある場合でも、そのグループにアクセス権がありません。同様に、ユーザーがグループにアクセスでき、パーミッションが割り当てられていない場合、ユーザーはタスクを実行できません。
JBoss ON に設定したパーミッションはロールに付与され、ロールのメンバーはこれらのパーミッションを継承します。パーミッションの許可または制限は アクセス制御 です。
JBoss ON では、アクセス制御が付与される 2 つのレベルがあります。
  • グローバルパーミッションは JBoss ON サーバー設定に適用 されます。ここでは、ユーザーの作成、ロールの編集、グループの作成、インベントリーへのリソースのインポート、JBoss ON サーバープロパティーの変更などの管理タスクについて説明します。
  • リソースレベルのパーミッション は、ユーザーが JBoss ON インベントリー内の特定のリソースに対して実行できるアクションに適用されます。アラートの作成、監視の設定、リソース設定の変更などのアクションが対象となります。リソースレベルのパーミッションは、JBoss ON 内のサブシステムエリアに関連付けられます。
JBoss ON のパーミッションはすべてに記載されてい 表9.1「JBoss ON のアクセス制御定義」 ます。
リソースレベルの権限については、読み取りおよび書き込みパーミッションは独立して付与されます。ユーザーは、その設定を編集する権限を自動的に付与することなく、リソースデータの表示(読み取り)権限を付与できます。たとえば、ユーザーは、リソースの操作履歴を表示したり、そのロールにこれらのサブシステム領域への edit アクセスが許可されていない 場合でも、ロール内でリソースの設定されたアラートを表示することができます。
デフォルトでは、読み取りアクセスは、すべてのリソースレベルの権限に対してデフォルトで有効になっています。ただし、1 つの例外: リソース設定です。リソース設定はセキュリティーリスクとみなされるため、読み取りアクセスもデフォルトで拒否されます。当然、読み取りアクセス(書き込みアクセスなど)は、リソースレベルのパーミッションに対して有効または無効にできます。

図9.1 アクセスオプションの読み取り

アクセスオプションの読み取り
注記
ロールを 変更 する権限を付与しても、何かを 削除 する権限は暗黙的に付与されません。たとえば、設定書き込みパーミッションを持つユーザーは、リソース設定を編集し、設定履歴および設定を表示できますが、設定履歴の要素を削除することはできません。同様の制約は、作成および編集操作およびアラートのパーミッションを持つユーザーにも同様です。リソース履歴で要素を削除する権限はありません。
履歴内の要素を削除するには、インベントリーの管理パーミッションが必要です。

表9.1 JBoss ON のアクセス制御定義

アクセス制御の種類 description
グローバルパーミッション
セキュリティーの管理
superuser と同等のパーミッションです。Security パーミッションにより、他のユーザー、ロール、リソースなど、JBoss ON のエントリーを作成および編集する権限が付与され、JBoss ON のサーバー設定が変更され、インベントリーを制御することができます。
警告
Security アクセス制御レベルは非常に強力であるため、どのユーザーに割り当てられているかに注意してください。スーパーユーザーの数を必要に応じて制限します。
インベントリーの管理 新しいリソースのインポートを含む、すべての JBoss ON リソースで操作を実行できます。
設定の管理 JBoss ON サーバー設定自体で設定を追加または変更できるようにします。これには、プラグインのデプロイや LDAP 認証の使用などの操作が含まれます。
バンドルグループの管理
ユーザーはバンドルグループのメンバーの追加および削除を許可します。暗黙的には、バンドルを表示するパーミッションが含まれます。これは、リソースの Inventory パーミッションの管理に類似しています。
注記
このパーミッションは、すべてのバンドルレベルの create、deploy、および delete パーミッションに必要です。
バンドルのグループへのデプロイ ユーザーがアクセス可能なリソースグループにバンドルをデプロイできるようにします。
バンドルの表示 バンドルグループ割り当てに関係なく、ユーザーはすべてのバンドルを表示できます。
バンドルの作成 ユーザーがバンドルバージョンを作成および更新できるようにします。バンドルの作成時には、ユーザーが View Bundles パーミッションを持たない限り、バンドルグループに割り当てる必要があります。この場合、ユーザーはバンドルを作成して割り当て解除することができます。
バンドルの削除 ユーザーに、表示権限を持つバンドルの削除を許可します。
バンドルの管理(非推奨)
リソースのプロビジョニングに使用するバンドル(パッケージ)のアップロードおよび管理を許可します。
このパーミッションは非推奨となっています。古いバンドル設定およびユーザーロールと後方互換性のために含まれています。ただし、このパーミッションは、特定のバンドル、グループ、またはリソース(デプロイメント用)へのアクセスを制限する機能を提供しませんでした。この詳細な制御を行わずに、このパーミッションは高レベルの管理者にのみセキュリティーを維持できます。
リポジトリーの管理 ユーザーは、指定した所有者なしで、設定されたリポジトリー(プライベートリポジトリーやリポジトリーなど)にアクセスできます。この権限を持つユーザーは、リポジトリーでコンテンツソースを関連付けることもできます。
ユーザーの表示 JBoss ON の他のユーザーのアカウントの詳細(ロール割り当てを除く)をユーザーに許可します。
リソースレベルのパーミッション
インベントリー リソースの詳細と接続設定をユーザーが編集できるようにします。つまり、JBoss ON インベントリーのリソースに関する情報を表します。リソース設定を編集する権限は付与されません。
測定の管理 ユーザーがリソースの監視設定を構成できるようにします。
アラートの管理 リソースに関するアラートおよび通知の作成を許可します。新しいアラート送信側を設定するとサーバー設定が変更されるため、グローバルパーミッションの関数になり Settings ます。
Control ユーザーがリソースに対して( コントロールアクションとも呼ばれる)操作を実行できるようにします。
設定
JBoss ON を使用して、リソースの設定を変更することができます。
注記
設定変更を可能にするには、ユーザーがリソースに対する適切なパーミッションを持っている必要があります。
このアクセスエリアには、以下の 2 つのオプションがあります。
  • read: リソース設定への読み取り専用アクセスを許可します。
  • write(変更アクセスおよび暗黙的に読み取りアクセスを付与する書き込み)
これらのパーミッションのいずれかがロールに付与されない場合、ロールのユーザーはリソース設定へのアクセスは拒否されます。
誤差の管理 リソースおよびテンプレートのドリフト定義を作成、変更、および削除できます。また、ユーザーは、スナップショットの表示や比較などのドリフト情報を管理できます。
コンテンツの管理 リソースで利用可能なコンテンツプロバイダーおよびリポジトリーを管理できるようになります。
子リソースの作成 指定したリソースタイプの子リソースを手動で作成できるようにします。
リージョンリソースの削除 ユーザーが指定したリソースタイプの子リソースを削除または無効化できるようにします。
バンドルレベルのパーミッション
グループへのバンドルの割り当て ユーザーがバンドルをグループに追加できるようにします。明示的なバンドルグループでは、これが唯一必要なパーミッションです。割り当てられて いない グループ(基本的にすべてのグループメンバーシップから削除)にバンドルを追加するには、グローバル View Bundles パーミッションも必要です。
グループからのバンドルの割り当て解除 グループからバンドルを削除することを許可します。
グループのバンドルの表示 ユーザーがパーミッションを持つグループ内の任意のバンドルを表示できるようにします。
グループへのバンドルの作成 ユーザーがパーミッションを持つバンドルグループ内に新しいバンドルを作成できるようにします。これにより、ユーザーはバンドルグループ内の既存のバンドルのバージョンを更新することもできます。
グループからのバンドルの削除 ユーザーがパーミッションを持つグループに属し、バンドルバージョンとバンドル全体の両方を削除できるようにします。
バンドルのグループへのデプロイ ユーザーは、(作成および削除のパーミッションに関係なく)表示できるバンドルを、パーミッションを持つリソースグループ内の任意のリソースにデプロイすることを許可します。

9.1.2. アクセスとロール

JBoss ON は、ロール を介したリソースと JBoss ON 設定の両方へのアクセスを処理します。ロールには特定のパーミッションが割り当てられており、ロールのメンバーが許可されることを表します。
ユーザーおよびグループというロールに属することができるのは、2 種類の JBoss ON アイデンティティーのみです。
ユーザーは、これらのパーミッションを付与されるロールに割り当てられます。ユーザーを個別にロールに追加したり、LDAP グループのメンバーとして追加したりできます。
リソースグループはロールに割り当てられ、これらのユーザーがアクションを実行できるリソースの一覧を提供します。また、ユーザーには、明示的にアクセス権限が付与されているリソースしか管理できない点が挙げられます。ロールは、このアクセスを定義します。
注記
作成するカスタムロールに割り当てるリソースグループを必ず作成してください。1 つのロールにリソースグループが割り当てられていない場合は、そのロールのメンバーにいずれのリソースも表示されません。グループの作成については、を参照してください 「グループの作成」
デフォルトでは、ロールなしで作成されたユーザーはログインできます。この設定は、トップメニューの「Administration」をクリックし、「Configuration」テーブルの「システム設定」セクションに移動し、「Enable Login Without Roles」設定を更新して変更できます。
ロールの便利な機能の 1 つが、ロール(「LDAP ユーザーグループをロールに関連付ける」)に LDAP グループを割り当てることで、自動的にロールに割り当てることができることです。そのグループに属するすべての LDAP ユーザーは、自動的にロールのメンバーになります。(LDAP ユーザーを使用した LDAP 認証の有効化による JBoss ON ユーザーの作成の簡素化と似てい 「LDAP ユーザー認証の設定」 ます)。
JBoss ON にデフォルトで 2 つのロールが設定されています。
  • superuser ロールは、JBoss ON のすべてのものへの完全なアクセスを提供します。このロールは変更できず、削除できません。JBoss ON サーバーを最初にインストールしたときに作成されたユーザーは、このロールに自動的にメンバーになります。
  • JBoss ON の すべてのリソースに完全なパーミッションを提供するすべての resources ロール が存在します(ユーザーの作成などの JBoss ON の管理機能には含まれません)。これは、JBoss ON によって管理されるリソースの設定を変更したり、JBoss ON によって管理されるリソースのアラートを設定できなくても JBoss ON サーバーやエージェントの設定を要求しない場合など、IT ユーザーにとって有用なロールです。

9.1.3. アクセスとグループ

ロールは基本的に、ユーザー、リソースグループ、バンドルグループ、およびそれらのグループに許可されるパーミッションの交差点です。
Access は関係を定義します。最も直接的な関係はユーザーと異なります。ロールを使用すると、ユーザーは JBoss ON 内の一部のリソースに対して何らかの作業を行うことができます。ただし、ロールへのアクセスは、グループ間 の関係も定義します。
グループ関係関数は 2 つの方法で行います。まず、メイングループとサブグループに異なるタイプのパーミッションを付与することができます。たとえば、すべてのリソースへの表示アクセスを許可し、設定アクセスを一部のリソースのみに制限します。また、2 つの異なるタイプのアクセス権限を付与することもできます。
リソースグループとバンドルグループの両方が異なるグループタイプがある場合、グループ関係はより複雑になります。非常に特殊なタイプのタスク(コンテンツまたはアプリケーションのデプロイメント)に関連していますが、リソースへのさまざまなアクセス、バンドルへのさまざまなアクセス、ライフサイクル内の操作ポイント(create、deploy、delete)に応じて、多くの異なる可能性のある対話があります。
ほとんどのインフラストラクチャーでは、ユーザーは単一のロールに属しず、1 つのロールがタスクセットを実行するすべての対話を定義することはできません。代わりに、ロールは Venn 図のように表示され、お互いに重複してアクセスルールの機能一覧を作成します。

リソースとバンドルへの単一ユーザーのアクセスを定義する 2 つのロール

Bundle Group A                  Resource Group A
     |                                 |
     V                                 V
  Role 1   <---  User A  --->    Role 2
     ^                                 ^
     |                                 |
  Permissions                     Permissions
   - view bundles in group         - deploy bundles to group
   - create bundles

9.2. 新規ロールの作成

注記
作成するカスタムロールに割り当てるリソースグループを必ず作成してください。1 つのロールにリソースグループが割り当てられていない場合は、そのロールのメンバーにいずれのリソースも表示されません。グループの作成については、を参照してください 「グループの作成」
  1. ロールに関連付けるリソースグループを作成します。グループの作成については、を参照してください 「グループの作成」
    デフォルトでは、JBoss ON は リソースグループ のみを使用してロールに関連付けるため、これらが必要です。ただし、LDAP ディレクトリーのオプションのユーザーグループをロールに割り当てることもできます。これにより、グループメンバーは自動的にロールメンバーとして処理されます。LDAP グループ は、の説明に従ってサーバー設定で設定する必要があり 「LDAP ユーザーグループをロールに関連付ける」 ます。
  2. トップメニューで、Administration タブをクリックします。
  3. 左側の Security メニューテーブルで、Roles 項目を選択します。
  4. メインのタスクウィンドウに現在のロールの一覧が表示されます。一覧の下部にある New ボタンをクリックします。
  5. ロールに説明的な名前を付けます。これにより、ロール間でパーミッションの管理が容易になります。
  6. のロールのアクセス権限を設定し Permissionsます。パーミッションには 2 つのカテゴリーがあります。
    • グローバルパーミッションは、JBoss ON サーバーおよび設定のエリアにパーミッションを付与 します。
    • リソースパーミッションには、リソース管理のパーミッションが付与 されます。
    特定のアクセスパーミッションについては、に記載されてい 「アクセス制御およびパーミッション」 ます。
  7. ロールにグループを割り当てる Resource Groups タブを選択します。
    必要に応じて、必要なグループを左の Available Resource Groups 領域から Assigned Resource Groups 右側に移動します。
  8. 下にある Save ボタンをクリックします。
  9. ロールにユーザーを割り当てる Users タブを選択します。
    必要に応じて、必要なユーザーを、左側の Available Users 領域から右 Assigned Users に移動します。
  10. 右上の矢印をクリックして、作成ウィンドウを閉じます。

9.3. 拡張例: ビジネスユーザー向けの読み取り専用アクセス

JBoss ON は読み取りパーミッションと書き込みパーミッションを区別します。JBoss ON のオブジェクトや機能領域には、読み取りアクセスも書き込みアクセスも暗示しません。これにより、管理者はアクセスが許可されている場所と柔軟性が得られます。

設定

例ある管理チームが、インフラストラクチャーのパフォーマンスとメンテナンスの追跡、インシデント対応手順の定義、および機器のアップグレードを行うために JBoss ON データの読み取りおよびアクセスを行うことができます。これらのビジネスユーザーは JBoss ON 情報を表示する必要がありますが、IT および開発部門が処理する設定を編集することはできません。

Tim(IT 管理者)は、ユーザーがリソース設定に「 see but touch」できる特別なビジネスマネージャーロールを作成します。

The Plan

Tim the IT Guy は、最初にビジネスユーザー 実行する必要があるアクションを定義し、すべてを表示できる必要があります。

  • リソースを追加および削除するインベントリーおよび履歴のリソースを表示します。
  • 測定やイベントなどの監視情報を表示します。
  • アラートを表示します。
  • コンテンツ、バンドル、およびリソースへのデプロイメントを表示します。
  • 設定のドリフトを表示します。
  • 設定および操作のすべてのリソース履歴を表示します。
  • ユーザーの詳細を表示して、監査アクションの情報を取得します。
グローバルパーミッションはすべて、JBoss ON およびインベントリーでエントリーの作成と設定管理に関連しています。これは、ビジネスマネージャーがいずれも実行する必要はありません。例外として、view users パーミッションがあります。これにより、通常ユーザーは他のユーザーの詳細を表示できます。操作を実行したり、リソース設定を変更したり、ユーザーがアクションを開始したりするなど、多くのアクションを行う必要があるためです。インフラストラクチャーの変更を適切に監査するには、ユーザー情報を表示する必要があります。
ロールのデフォルト選択は、ユーザーへの読み取りアクセスを付与するすべてのリソースレベルのパーミッションに対するものです(ただし、アクセス権限のない設定権限を除く)。Tim the IT Guy は、マネージャーが設定の履歴を確認することができるように設定への読み取り専用アクセスを付与することを決定します。これは、ポリシー計画に役立ちます。グループには、すべてのリソースおよびレポートなどのアイテムへの読み取り専用アクセスがあります。

結果

ビジネスユーザーは、設定やインベントリーを誤って変更することなく、必要なすべての情報にアクセスできます。

9.4. 拡張例: すべてのリソースの表示、一部のリソースの編集

セキュリティーや管理プラクティスについては、アクセスは特定のユーザーに必要なものに制限する必要があります。セキュリティーは、デフォルトとしてアクセスを制限することで開始され、定義された権限(読み取り、変更、削除)を特定のリソースに明示的に付与します。
ユーザー(またはユーザーのセット)に必要なすべてのものを定義するアクセス制御ルールのセットを作成することは可能ですが、実際にはこれらのルールは複雑で複雑で複雑で、簡単に古い、または不正確です。アクセス制御は関係の定義です。多くの場合、ユーザーが持つさまざまな関係は、1 つのロールで定義することは複雑ではありません。
ロールの効果は累積的です。ユーザーのアクセスレベルの 合計 は、そのロールが属するすべてのロールの合計です。指定したリソースグループ内のすべてのリソースグループ内のリソースへのアクセス(これらのロールに付与されるパーミッション)が含まれます。
この影響は累積的であるため、レイヤー化された方法でアクセス制御を設計することが最も効果的です。これにより、アクセスセットが定義され、これらのロールを段階的にユーザーに追加することができます。
階層化された手法により、管理者は、人員およびインフラストラクチャーの分割に合わせたマクロレベルで、複雑な関係を定義および効果的に維持でき、また異なるリソースとの異なる関係を持つマイクロレベルでは、複雑な関係を定義および効果的に維持できます。

設定

たとえば、Corp. には、IT インフラストラクチャーに関連する 3 つの主要グループがあります(開発、QE、および実稼働環境)。各グループには、構成の管理、パフォーマンス設定の管理、および新規アプリケーションのロールアウトをサポートするために、他のチームからの情報が必要ですが、独自のシステムを管理できます。

各グループ内には、アプリケーションの新規バージョンを更新してデプロイし、最適なパフォーマンスを得るためにシステム設定を管理する 2 つの異なるアプリケーション管理タスクがあります。

The Plan

Tim the IT Guy は、まずアクセス制御内で表現する必要があるさまざまな関係を定義します。

  • インフラストラクチャー内のすべてのスタックのパフォーマンスデータを表示できる必要があります。
  • 各部門には、独自のシステムへの書き込みアクセスが必要になります。
  • 各グループ内の少なくとも一部の管理者には、システム設定を更新する必要があります。
  • 各グループ内の少なくとも一部の管理者には、バンドルを作成およびデプロイして、独自のグループ内でアプリケーションを管理する機能が必要です。
最初のステップは、各グループの最低必要なリソースで必要なグループを定義することです。簡素化された構造では、以下のようになります。
  • 各スタック環境内のすべてのリソースが含まれる混合グループ。スタックには、プラットフォーム、Postgres データベース、EAP サーバー、Web コンテキスト、実稼働環境の管理に使用するその他のリソースが含まれます。
    これにより、Dev Stack、QE Stack、および Production Stack の 3 つのグループが生成されます。
  • 3 つのスタックグループすべてを含む「すべてのスタック」ネストされたグループ。
    このグループは、すべてのリソースに該当せず、スタックグループのみが含まれます。ただし、JBoss ON 関連のリソースや、これらのスタックには関係しないその他の管理リソースが除外されます。
  • これらの環境にはアプリケーション開発が含まれるため、デプロイメントを維持するために各組織に独自のバンドルグループも必要です。
  • 環境間でバンドルをプロモートするためのメクnism が必要です。Tim the IT Guy は、「Promote Bundles」グループを作成し、別の環境に移動する準備ができたときにバンドルを追加できます。
同じ部門内の異なるユーザーが個別のリソースへのアクセスレベルを必要とする場合に、リソースとバンドルグループごとに分類できます。
次に、さまざまなユーザーがアクセスを必要とします。次に、Tim(IT 管理者)は、必要な異なるパーミッションをマッピングします。
  • 設定ビューのみの権限を含む、すべてのリソースへの表示のみ権限
  • スタック内のリソースに対する権限の編集によるモニタリング、アラート、ドリフト、操作、およびインベントリー
  • 設定用にスタック内のリソースに対する権限の編集
  • スタック内のバンドル権限の表示
  • スタック内でのバンドル権限の作成およびデプロイ
各機能グループには基本的に 3 つのタイプのユーザーがあります。
  • 一般ユーザー
  • リソース設定を管理する管理者
  • グループ間のバンドルを作成(昇格)できる管理者
ロールは、各リソースおよびバンドルグループに照合され、そのグループの最小要件(ローカルビューおよび編集)に設定されたパーミッションを持ちます。管理者のために、追加のパーミッション(設定およびプロモートコンテンツ)は、追加のパーミッションのみを持つ追加のロールを作成して追加されます。
通常のユーザーの場合は、スタック内のすべてのリソースおよびバンドルおよびリソースにロールを追加します。
       Dev Stack 
      Bundle Group
           |
       Role BG1
           |
           V
     Regular Joe
      ^         ^
      |         |
   Role RG1  Role RG2                      
      |         |
 "All Stack"   Dev Stack  
  Resource     Resource
  Group        Group
「 all Stack」ロールについて、すべてのインベントリーエリア および 設定に読み取り専用パーミッションを追加します。
      ^
      |      
      Role RG1 <------Permissions        
      |                     |
 "All Stack"              View.alerts
  Resource                View.inventory
  Group                   View.measurements
                          View.etc...
                          View.configuration
スタックグループについて、Tim(Timum)は、管理者ユーザー用に予約される設定を除き、すべての機能領域(measurement、アラート、操作、イベント)を編集するパーミッションを設定します。リソースグループには、バンドルをグループのリソースに デプロイする パーミッションも含まれます。バンドルをデプロイする機能は、バンドルを作成する機能とは異なります。
      ^
      |      
      Role RG2 <------Permissions        
      |                     |
  Dev Stack              Edit.alerts
  Resource               Edit.inventory
  Group                  Edit.measurements
                         Edit.etc...
                         Deploy.bundles
最後に、通常ユーザーのバンドルグループ内でバンドルを表示および作成するパーミッションを追加します。
 Dev Stack 
      Bundle Group
           |
       Role BG1 <-----Permissions
           |                |
    V             View.bundles
                         Create.bundles
この設定では、管理者がスタック内でリソース設定の管理と次のワークグループにバンドルをプロモートする 2 つの追加のタスクがあります。管理者は、通常ユーザーの全ロールと、追加のタスクの追加ロールに追加されます。
Tim the IT Guy は、設定パーミッションを定義するために追加のロールを 1 つ作成します。これにより、管理者が表示できるリソースグループにのみ設定の編集が許可されます(作業グループ内のリソースグループ)。
"Regular Joe" roles
        |
        V
   Group Lead <------Role RG3
                            |
                        Permissions
                            |
                     Edit.configuration
最後に、各管理者は各バンドルグループのロールに追加されます。バンドルグループのロールは、コンテンツの作成のみにバンドルグループへのアクセスを付与し、表示、デプロイ、または削除は行いません。これにより、管理者はワークグループ間でコンテンツをプロモートできますが、デプロイしたり、リソース設定に影響するりすることはできません。
                Dev Stack          Permission:
             Bundle Group          Create.Bundles
                        \          /
                         \        / 
                          Role BG1
                              |
                              V
       Role BG2 ---->    Group Lead    <---- Role BG3 
      /      \                               /     \
     /        \                             /       \
 QE Stack      Permission:        Prod Stack         Permission: 
Bundle Group   Create.Bundles   Bundle Group         Create.Bundles

結果

各グループ内のユーザーには、必要なパフォーマンスや設定情報を表示するアクセス権が付与されますが、変更できるのは指定されたグループ内のリソースのみです。各グループ内の管理者のみが設定変更を行うことができます。

アプリケーションのデプロイメントは、各機能領域(開発、QE、および実稼働環境)に限定されます。他のグループにコンテンツを作成できるが、デプロイできない特定の管理者。

第10章 認証および承認用の LDAP サービスの統合

JBoss ON には LDAP ディレクトリーを組み込み、ロールのユーザー、認証、およびメンバーシップを管理することができます。これにより、JBoss ON でのユーザー管理が簡素化され、既存の組織設定(ユーザーアカウント、グループ、パスワード、アカウントロックアウトポリシー)を活用して、JBoss ON は他のインフラストラクチャー設定をミラーリングします。
重要
LDAP がユーザーアカウント管理に使用される場合、LDAP ディレクトリーはユーザーアカウントの作成および管理の権限を持つソースである必要があります。そうでない場合は、ロールメンバーシップ、アカウント設定、またはその他のユーザーアカウントが競合する状態が生じる可能性があります。を参照してください 「ユーザーストアに LDAP の使用に関連する問題」
重要
マルチドメインの Active Directory 構造を使用する場合は、Universal(グローバル)グループが必要です。Active Directory の権限の問題により、グローバルグループのユーザーにはドメイン間での可視性が制限されています。

10.1. サポート対象のディレクトリーサービス

JBoss ON は、ユーザー認証およびグループ承認の主なディレクトリーサーバーをサポートします。
  • Red Hat Directory Server 8.1、8.2、および 9.0
  • Microsoft Active Directory 2003 および 2008

10.2. ユーザー認証用の LDAP

10.2.1. LDAP 認証およびアカウント作成について

デフォルトでは、JBoss ON は内部データベースに認証情報を保存します。JBoss ON は外部 LDAP リポジトリーを使用してこのユーザー情報を保存することもできます。LDAP 認証では、JBoss ON サーバーはすべてのログインリクエストを LDAP ディレクトリーに送信し、処理します。
まず、JBoss ON サーバーは LDAP ディレクトリーで一致するユーザー名を検索し、指定のユーザー名およびパスワードを使用して LDAP サーバーにログインを試みます。バインドが正常に試行されると、ユーザーは JBoss ON サーバーに正常に認証されます。
JBoss ON サーバーが認証に LDAP を使用するように設定されると、すべてのログイン試行が LDAP サーバーに対して認証されます。
警告
JBoss ON サーバーが認証に LDAP を使用するように再設定されている場合、LDAP 情報は検証されません。LDAP 認証設定のエラーは、ユーザーが UI へのログインを試みるまで表示されません。
注記
LDAP ディレクトリーは JBoss ON ユーザーを自動的に作成できません。ただし、認証に LDAP を使用すると、新しいユーザーが JBoss ON に登録できます。新しいユーザーは、LDAP アカウントがある限り JBoss ON に対して認証できます。最初のログイン時に、追加の JBoss ON ユーザー情報を記録する登録ページにリダイレクトされます。
JBoss ON サーバーは、JBoss ON のユーザー名および LDAP ディレクトリーに関する情報(ディレクトリーツリーの親識別名やユーザーエントリーに使用される naming 属性など)に基づいて LDAP エントリー名を構築します。そこから、JBoss ON にログインするたびに検索フィルターが動的に構築されます。カスタム属性を LDAP スキーマに追加できるため JONUser=true、エントリーの検索が容易かつ正確になります。
LDAP ディレクトリーは、ログイン認証情報 のみ を検証します。LDAP サーバーは他の JBoss ON ユーザーデータは保存せず、JBoss ON のエントリーを作成、削除、または編集しません。同様に、JBoss ON は LDAP ディレクトリーのエントリーを作成、削除、または編集しません。JBoss ON ユーザーアカウントに関連する LDAP データベースの唯一の属性は、ユーザー名とパスワードです。JBoss ON ユーザーエントリーの他の設定は JBoss ON 内部データベース(ユーザーの名前とエンタイトルメント、メールアドレス、ロール割り当てなど)に保存されます。
注記
LDAP ディレクトリーはログインクレデンシャルの確認のみに使用されます。ロールの割り当てを含む JBoss ON ユーザーに関する他の情報は保存されず、JBoss ON ユーザーを作成することはできません。JBoss ON サーバーは LDAP ユーザーも 作成 できないため、LDAP ユーザーを個別に作成する必要があります。
LDAP ディレクトリーには JBoss ON に関連する他の属性が格納されないため、ユーザー証明書を保存できません。そのため、JBoss ON は証明書ベースの認証に LDAP ディレクトリーを使用できないことを意味します。

10.2.2. ユーザーストアに LDAP の使用に関連する問題

LDAP ディレクトリーを統合するには、ユーザーの作成および管理が可能で、ロールのメンバーシップを変更できる別のエリアが導入されます。一方で、これにより、既存ユーザーがシームレスに登録でき、ロールメンバーシップを自動的に更新することで、ユーザーの管理が大幅に容易になります。しかし、JBoss ON でユーザーが作成でき、手動で JBoss ON に追加できるため、ユーザーとロールの管理が堅牢になります。
最初の問題は、ユーザー認証に使用するデータストアを決定することです。LDAP 認証を有効にした後でも、JBoss ON はクレデンシャルを独自のユーザーストアに対してチェックし、最初にデータベースをチェックします。つまり、ユーザーは LDAP データベースにリクエストを送信しなくても JBoss ON に認証できます。LDAP ディレクトリー(特にパスワードポリシーおよびアカウント非アクティブ)のセキュリティー機能は、プライマリー認証メカニズムではないため失われます。
次に、ユーザーアカウントに 2 つのリソースを使用すると、JBoss ON および LDAP ユーザーアカウントを誤ってマッピングしたり、エントリーの重複を作成したり、または ghost エントリーを許可するという問題が生じます。たとえば、Jenson Symage は手動で JBoss ON にユーザーとして追加され、LDAP ユーザーアカウントもあります。まず、別個の 2 つのユーザーエントリーがあります。その後、別の部門に移動して LDAP エントリーが自動的に削除されますが、JBoss ON ユーザーアカウントおよび LDAP ユーザーアカウントはリンクされていないため、JBoss ON ユーザーアカウントは残ります。JBoss ON にログインすることができました。ユーザーアカウントが重複している場合には、同じ名前のアカウントが存在する場合は、他の問題が発生する可能性が あり ます。たとえば、Jane John を JBoss ON ユーザーアカウント(jsmith)およびパスワードを使用して JBoss ON にログインしますが、JBoss ON ユーザー ID が LDAP ユーザー ID と同じである jsmithため、LDAP ユーザーで LDAP ユーザーの JBoss ON ロールメンバーシップに誤って割り当てられ、アカウントが LDAP アカウントに誤ってマップされたため、LDAP グループメンバーシップは誤って割り当てられます。
ユーザーアカウントの維持を試みると、少なくとも管理的な方法ではロールにも影響します。LDAP グループはロールのメンバーとして追加され、グループメンバーはそのロールのユーザーメンバーとして一覧表示されます。ただし、ロールに割り当てられたユーザーの一覧には、それらのユーザーの出所が表示され ませ ん。つまり、ユーザーリストは LDAP グループメンバーと、手動でリストに追加されていた JBoss ON メンバーの組み合わせになります。ユーザーは最終的にユーザーの追加や削除が困難になります。これは、ロールユーザーがどこから送信されるかは明確ではないためです。LDAP グループにロールメンバーシップを制限すると、メンテナンスが簡素化されます。ユーザーが LDAP 側のグループにユーザーを追加または削除すると、それらの変更は JBoss ON ロールに動的に同期されます。

図10.1 LDAP グループ、JBoss ON ロール、およびロールメンバー

LDAP グループ、JBoss ON ロール、およびロールメンバー
これは、認証または承認に LDAP サービスを使用する際に考慮すべき 3 つの点です。
  • 通常のユーザーアカウントだけを 1 カ所で作成してください。LDAP が認証に使用される必要がある場合は、LDAP ディレクトリーでユーザーアカウントを追加または削除するだけです。
  • 理想的には、JBoss ON ユーザーアカウントを特殊管理ユーザーに限定し、通常のアカウントの LDAP ディレクトリーに依存します。
  • LDAP グループを中心にロールを設計しようとします。つまり、これらのロールの JBoss ON ユーザーアカウントは管理アカウントに制限されるべきか、または完全に回避する必要があります。

10.2.3. LDAP ユーザー認証の設定

認証 は、サーバーにアクセスしようとするエンティティーのアイデンティティーを検証するプロセスです。JBoss ON は簡易認証を使用します。つまり、単純なユーザー名とパスワードのペアを使用してアイデンティティーを検証します。
  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Configuration メニューテーブルで、System Settings 項目を選択します。
  3. その LDAP Configuration Properties エリアにジャンプします。
  4. Use LDAP Authentication チェックボックスをチェックして、JBoss ON が LDAP ユーザーディレクトリーをアイデンティティーストアとして使用するようにします。
  5. 特定の LDAP ディレクトリーに接続する接続を設定します。
    • LDAP サーバーの LDAP URL を指定します。これは ldap://hostname[:port] のフォーマットです。例:
      ldap://server.example.com:389
      デフォルトでは、これはポート 389(標準 LDAP ポート)または 636(SSL が選択されている場合はセキュアな LDAP ポート)経由でローカルホストに接続します。
    • セキュアな接続を使用するには、チェック Use SSL ボックスを選択します。SSL を使用する場合、LDAP ディレクトリーが SSL で実際に実行されていることを確認し、接続 URL が適切な SSL ポートおよびプロトコルを参照するようにします。
      ldaps://server.example.com:636
    • サーバーへの接続に使用するバインド認証情報を付与します。ユーザー名は、JBoss ON がディレクトリーにバインドするユーザーの完全な LDAP 識別名です。
      注記
      JBoss ON で LDAP 設定を行う前に、LDAP ディレクトリーにユーザーが存在している 必要 があります。それ以外の場合は、JBoss ON サーバーへのログイン試行は失敗します。
      また、JBoss ON ユーザーには LDAP ディレクトリーのユーザーおよびグループサブツリーへの適切な読み取りおよび検索アクセスがあることを確認してください。
      デフォルトでは、ロールなしで作成されたユーザーはログインできます。ロールについての詳細は、を参照してください 「アクセスとロール」
      注記
      デフォルトでは、ロールなしで作成されたユーザーはログインできます。これは、ユーザーが LDAP に存在する可能性があるが、JBoss ON でロールが割り当てられていないため影響を受けます。ロールについての詳細は、を参照してください 「アクセスとロール」
  6. 一致するユーザーエントリーに対して LDAP ディレクトリーを検索する際に JBoss ON が使用する検索パラメーターを設定します。
    • 検索ベース は、サーバーがエントリーの検索を開始するディレクトリーツリーのポイントです。これはユーザー認証にのみ使用されるか、またはすべての JBoss ON 関連エントリーが同じサブツリーにある場合に、特定のサブツリーを参照できます。
      ou=user,ou=JON,dc=example,dc=com
      ユーザーまたはグループがディレクトリー全体に分散されている場合は、ベース DN を選択します。
      dc=example,dc=com
    • 必要に応じて、特定のエントリーのサブセットを検索するために使用する検索フィルターを設定します。これにより、すべての JBoss ON 関連エントリーがカスタム属性などの共通の LDAP 属性を共有すると、検索パフォーマンスおよび結果が向上し JonUser ます。フィルターはワイルドカード(objectclass=*)または特定の値(JonUser=true)を使用できます。
    • LDAP の命名属性を設定します。これは完全な識別名の左側にある要素です。たとえば uid=jsmith,ou=people,dc=example,dc=com、の left 要素はで uid=jsmith、naming 属性はになり uidます。
      Active Directory のデフォルトの命名属性はです cn。Red Hat Directory Server では、デフォルトの命名属性はです uid
  7. LDAP 設定を保存します。
    注記
    ユーザー認証に Group Filter および Member Property フィールドは必要ありません。にあるように、ロールに割り当てられる LDAP グループを設定するために使用され 「LDAP ユーザーグループをロールに関連付ける」 ます。

10.3. ロールおよび LDAP ユーザーグループ

10.3.1. グループ承認について

多くの LDAP ディレクトリーには、JBoss ON のリソースにアクセスする必要のあるユーザーを含む組織グループがすでに含まれています。JBoss ON を設定してこれらのディレクトリーに接続するように設定すると、JBoss ON では LDAP グループをロールに割り当て、それらのメンバー一覧を動的にプルするため、ロールには既存のメンバーリストが設定されます。すべての LDAP ユーザーが、そのロールのパーミッションを自動的に継承します。
ロールの詳細ページでは、これらの LDAP ユーザーグループはリソースグループから分離されるため、ロールに追加されているグループのタイプを簡単に区別できます。

図10.2 ロールに割り当てられたグループ

ロールに割り当てられたグループ
JBoss ON は、シンプルな検索でユーザーが所属する LDAP グループを決定します。ユーザーが JBoss ON にログインして LDAP 接続が設定されると、JBoss ON は JBoss ON のユーザー名を LDAP ディレクトリーサーバーのユーザーエントリーにマッピングします。ユーザーの特定の LDAP 識別名(DN)は、LDAP グループエントリーで一致するメンバー属性を見つけるために検索の一部として使用されます。つまり、LDAP サーバーはグループエントリーのメンバー一覧を確認して、その DN を持つユーザーが所属するグループを確認できます。
LDAP グループをロールに追加するには、以下の 3 つの項目が必要です。
  • LDAP ディレクトリーサーバー接続を設定する必要があります。
  • グループエントリー を検索するには、LDAP 属性を指定する必要があります。
    Active Directory の場合、これは一般的に group オブジェクトクラスになります。Red Hat Directory Server の場合、これは通常です groupOfUniqueNames。他の標準オブジェクトクラスも利用でき、JBoss ON 固有のオブジェクトクラスであってもカスタムを使用することもできます。
  • グループの メンバー を識別するために LDAP 属性を指定する必要があります。
    一般的なメンバー属性は member およびです uniqueMember
JBoss ON は、サーバー設定のグループオブジェクトクラスと member 属性、およびユーザーがログインしたときに提供されたユーザーの DN を基にして LDAP 検索を構築します。
(&(group_filter)(member_attribute=user_DN))
たとえば、Active Directory グループの member 属性を検索します。
ldapsearch -h server.example.com -x -D "cn=Administrator,cn=Users,dc=example,dc=com" -W -b "dc=example,dc=com" -x &apos;(&amp;(objectclass=group)(member=CN=John Smith,CN=Users,DC=example,DC=com))&apos;
Red Hat Directory Server は member、およびよりも一般的に groupOfUniqueNames グループの uniqueMember 属性を使用し groupます。例:
/usr/lib64/mozldap6/ldapsearch -D "cn=directory manager" -w secret -p 389 -h server.example.com -b "ou=People,dc=example,dc=com" -s sub &quot;(&amp;(objectclass=groupOfUniqueNames)(uniqueMember=uxml:id=jsmith,ou=People,dc=example,dc=com))&quot;
この検索は、ユーザーがメンバーとなっているすべてのグループの一覧を返します。これらの LDAP グループのいずれかが JBoss ON ロールに割り当てられている場合、そのユーザーはその JBoss ON ロールでも自動的にメンバーになります。
注記
カスタム LDAP グループオブジェクトクラスを使用すると、JBoss ON ロールに使用するグループを非常に具体的に指定することができます。

10.3.2. LDAP ユーザーグループをロールに関連付ける

「LDAP ユーザー認証の設定」 LDAP ディレクトリーサーバーが JBoss ON に対してユーザーを認証する方法について説明しています。ユーザーがログインを試みるたびに、その要求(ユーザー名およびパスワードを使用)は、指定の LDAP ディレクトリーに簡単に転送され、認証情報が正しいかどうかを確認します。
LDAP グループのメンバーは、JBoss ON ロールのメンバーとしてプルできます。LDAP グループは JBoss ON ロールに関連付けられ、グループメンバーは JBoss ON ロールが 許可 されるように許可されます。LDAP グループメンバーに加えられた変更は、JBoss ON ロールを編集しなくても自動的に JBoss ON に反映されます。
  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Configuration メニューテーブルで、System Settings 項目を選択します。
  3. その LDAP Configuration Properties エリアにジャンプします。
  4. の説明に従って、LDAP 接続を設定し 「LDAP ユーザー認証の設定」 ます。LDAP ディレクトリーを LDAP 承認を設定するためにアイデンティティーストアとして使用する必要はありませんが、推奨されます。
  5. サーバーが LDAP グループとそのメンバーを検索するために使用するパラメーターを設定します。
    JBoss ON 構成する検索フィルターは以下のようになります。
    (&(group_filter)(member_attribute=user_DN))
    • Group Search Filter フィールドは、グループエントリーの検索方法を設定します。これは通常、オブジェクトクラスで検索するグループのタイプを指定して行います。
      (objectclass=groupOfUniqueNames)
    • この Group Member Filter フィールドは、指定されたグループタイプがメンバーの識別名を保存するために使用する属性を指定します。例:
      uniqueMember
    user_DN は、ユーザーが UI にログインする際に JBoss ON によって動的に提供されます。
  6. LDAP 設定を保存します。

10.4. 拡張例: memberOf および LDAP 設定

設定

認証 は、他のユーザーの ID を検証するプロセスです。承認 とは、アイデンティティーが持つアクセス権限を決定するプロセスです。ユーザーは、ロールの割り当てに付与されたパーミッションに基づいてタスクを実行することが許可されます。

Example Co. のユーザーおよびアイデンティティーはすべて、バックエンド Red Hat Directory Server LDAP データベースに保存されます。単一の中央ユーザーストアを維持するには、Tim(IT 管理者)は JBoss ON の既存の LDAP ユーザーを使用し、グループメンバーシップに基づいて JBoss ON へのユーザーアクセスを決定したいため、基本的には認証ルールと承認ルールの両方が LDAP 設定によって決定されます。

The Plan

認証用にユーザーを特定する方法と、承認のためにユーザーを整理する方法の 2 つの設定があります。

グループは、JBoss ON for Example Co の LDAP 設定を管理する際に、2 段階の役割を果たします。
  • LDAP ディレクトリーで JBoss ON ユーザーを識別する単一グループ
  • JBoss ON へのアクセスレベルを決定するために使用される既存の LDAP グループが複数になる
最初に、Tim the IT Guy が判断したものが、ユーザーを識別する方法です。前述 「LDAP ユーザー認証の設定」 のように、JBoss ON は検索ベースおよびオプションの検索フィルターを使用する LDAP 検索の結果に基づいてユーザーを識別します。検索フィルターは、attribute=value のペアを指定します。ユーザーを特定するのに推奨される方法の 1 つは、カスタムのスキーマ要素を作成することです。これにより JONUser、一致するユーザーの検索が容易になります。
ただし、Tim(IT 管理者)は、Red Hat Directory Server データベースへの管理アクセスを限定しています。グループを作成し、メンバーシップを管理する機能がありますが、スキーマを編集することはできません。JBoss ON ユーザーにフラグを付ける属性を作成する方法がない場合は、Tim(IT 管理者)は他の設定を使用する必要があります。ディレクトリーのレイアウトによっては、ビュー、マネージャー、サービスのクラス(CoS)仮想属性、またはグループメンバーシップなどの他の設定を使用できます。
グループメンバーシップを使用すると、(個別のグループエントリーではなく)1 つのエントリーのみを管理するだけで、ユーザー割り当てを簡単かつ動的に管理できます。Directory Server では、memberOf 属性が自動的にユーザーエントリーに追加され、ユーザーが属するグループを示します。
Tim the IT Guy の機能は、すべての JBoss ON ユーザーと、希望するユーザーに対して特別なグループを設定することです。Directory Server は、メンバーが追加および削除される際に、ユーザーエントリーに memberOf 属性を自動的に追加/削除します。Tim(IT 管理者)は、認証用の検索フィルターとして、そのユーザーアカウントの memberOf 属性のみを使用する必要があります。
dn: uid=jsmith,ou=people,dc=example,dc=com
uid: jsmith
cn: John Smith
...
memberOf: cn=JON User Group,ou=groups,dc=example,dc=com
memberOf: cn=IT Administrators,ou=groups,dc=example,dc=com
JBoss ON LDAP 認証検索フィルターは、その特定の JBoss ON グループの memberOf 属性をターゲットとします。
memberOf='cn=JON User Group,ou=groups,dc=example,dc=com'
グループをアクセス制御に使用するには、JBoss ON 固有のグループ定義を全く異なるグループ定義が必要です。これらのグループは Example Co. 内の機能エリアと関連し、Tim(IT 管理者)は既存の LDAP グループを JBoss ON ロールにマッピングできます。JBoss ON を管理するために、Example Co. には 3 つの関連する LDAP グループがあります。
  • Administrators Group は、インベントリーパーミッションの管理でロールにマップされます。
  • Manager Group は、すべてのリソースおよび view ユーザーのパーミッションで表示(書き込みがない)パーミッションを持つロールにマップされます。
  • Business Manager Group は、すべてのリソース設定、バンドル、ドリフト、測定、操作、およびアラートを読み取るパーミッションを持つロールにマップされますが、書き込み権限はありません。

結果

Tim(IT 管理者)は、JBoss ON のすべての認証とユーザーを設定するために、1 つの LDAP グループである JON Users グループのみを作成して管理する必要があります。LDAP スキーマを変更したり、ユーザーエントリーを直接変更したりする必要がありません。

承認のために、Tim(Timum)は、LDAP ディレクトリーにすでに定義されている機能グループ(例: Co. の組織、IT 管理者、IT マネージャー、およびビジネスマネージャーおよびアクセスレベル)で JBoss ON ロールを設計します。
JBoss ON UI への LDAP ユーザー認証を初めて使用すると、独自の JBoss ON ユーザーの詳細を設定します。認証後、LDAP グループメンバーシップに基づいて適切なアクセスレベルが自動的に付与されます。

パート II. リソース設定の管理

第11章 リソース操作の実行

11.1. オペレーション: 概要

JBoss Operations Network は、スケジュールおよび起動 操作 によってリソースを管理できます。操作は基本的な管理タスクです。利用可能なタスクは、異なるタイプのリソースによって異なります。
リソースリファレンス: Monitoring、Operation、および Configuration Options』 には、各リソースタイプにスケジュールできるすべての操作の完全な参照と、操作用の設定可能なパラメーターが含まれます。操作またはリソースのタイプに関係なく、JBoss ON のリソースと互換性のあるグループの両方で、スケジューリング操作のプロセスは似ています。
JBoss Operations Network を使用すると、管理者はスケジュールおよび起動 操作 によってリソースを管理できます。操作は、サーバーの再起動やスクリプトの実行など、基本的な特定のタスクを開始またはスケジュールすることでリソースを管理します。操作は、インベントリー内のどのリソースでも実行できます。また、JBoss ON エージェント自体でも実行できます。リソースごとに利用できる操作のタイプは、管理されているリソースの種類によって異なります。たとえば、JBoss AS サーバーには cron サービスとは異なる操作があります。リソースでサポートされる操作はエージェントプラグインで定義され、デフォルトの操作はリソース 『リファレンスの Monitoring、Operation、および Configuration Options の各リソースタイプに対して一覧表示されます』。

11.1.1. 操作のメリットの概要

操作は、リソースとタスクキューの両方で定義された順序と追跡可能な方法で、一貫した方法でタスクを実行する方法を提供します。操作はプラグインにより定義されているため、拡張可能です。JBoss ON を使用して特定のタスクを実行することは、管理者には以下のような利点があります。
  • コマンド引数や環境変数など、追加のパラメーターを使用することができます(コマンド引数や環境変数など)。
  • JBoss ON がリソース設定の変更を検証する場合と同様に、操作パラメーター、コマンドライン引数、または環境変数をすべて検証します。
  • これらはすべて同じタイプである限り、リソースのグループで実行できます。
  • 操作は、特定の順序でグループリソースで実行するように順序付けできます。
  • 定期的なスケジュールまたは 1 つの特定のタイミングで実行できます。
  • 操作は、成功と失敗の両方の履歴を保持します。これにより、特定のリソースに対して実行される操作と、そのリソースに対して実行され、そのリソースに対して実行される操作をグループの一部として監査できます。

11.1.2. スケジューリング操作について

操作スケジュールは、即座に実行されるように定義された時間です。
操作をスケジュールするためのパスは 2 つあります。
  • カレンダー設定を使用して時間を選択します。カレンダーを使用してオペレーションをスケジュールする方法は 3 つあります。すぐに、今後設定するか、または繰り返しスケジュールに設定されます。繰り返しスケジュールは無制限にしたり、特定の期間内に実行したりできます。
  • cron 式の使用。これは、ほぼ定期的なジョブに使用され、非常に複雑な実行スケジュールを設定するために使用できます。

図11.1 スケジュールされた操作

スケジュールされた操作
注記
この Schedules タブには、スケジュールされた操作の一覧が表示されます。これは、設定済みですが実行されていない操作を示します。[2]
操作がスケジュールされると、リソースの履歴レコードに新しい操作が追加され、その状態が進行中に設定されます。メッセージはエージェントに送信され、スケジュールの作成時に指定されていた引数を使用して、特定のリソースで特定の操作を開始するように指示されます。エージェントの操作は一度に 1 つの操作のみに実行されるようにキューに入れます。
操作が完了すると、raw 出力がエージェントのリソースプラグインに返信され、最終的に出力が解析され、適切な応答メッセージが表示されます。その後、この応答メッセージがサーバーに送信されます。
リソースで 1 つの操作がハングした場合、一度に 1 つの操作しか実行できないため、他の操作の開始をブロックします。操作にタイムアウト設定を使用すると、エージェントはハング操作を強制終了し、他のキューに登録された操作を実行できます。

11.1.3. 運用に関する説明

操作履歴は、基本的に JBoss ON を介してリソースで実行されるタスクの監査証跡です。
各エントリーには、操作をスケジュールしたユーザーの名前、操作の実行スケジュール時間、ステータス、および結果が表示されます。失敗した場合は、返されたエラーメッセージが含まれる情報メッセージが表示されます。
スケジュールされた操作と最近の操作は Dashboard、および JBoss ON レポートのポートレットに一覧表示されます。これらの操作には、リソースと互換性のあるグループ操作の両方が含まれます。
個別のリソース操作と同様に、グループ操作にはグループの履歴も記録されます。これらの操作履歴は、グループの全リソースで実行される操作の一覧です。したがって、操作履歴には、最初にスケジュールされたグループ操作と、各リソースの実行詳細が表示されます。

11.2. 操作の管理: 手順

11.2.1. スケジューリング操作

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. Operations タブをクリックします。
  4. Schedules タブで、New ボタンをクリックします。
    利用できる操作のタイプは、リソースの特定のタイプによって異なります。
    注記
    この Schedules タブには、スケジュールされた操作の一覧が表示されます。これは、設定済みですが実行されていない操作を示します。スケジュールされた操作がない場合、タブには No items to show を読み取る説明があります。これは、リソースに利用できる操作がないことを意味します。つまり、操作がスケジュールされていないことを意味します。
  5. ポート番号、ファイルの場所、コマンド引数など、操作に必要なすべての情報を入力します。
  6. この Schedule エリアで、操作の実行時を設定します。
    を使用する場合 Calendar、日付ウィジェットから選択したように、指定した時間、または繰り返し可能なスケジュールで操作を実行できます。
    Cron Expression はジョブに基づいて繰り返し発生するジョブに使用され cron ます。これらの式の形式は、日次月分で、0- 59 0- 23 1-31 1-12 1-7 の潜在的な値で、アスタリスクを使用すると任意の値を設定できます。
  7. タイムアウト期間や操作自体にメモなど、操作に他のルールを設定します。
  8. Schedule ボタンをクリックして操作を設定します。
操作が直ちに実行される History ようにスケジュールされている場合、操作の進行中に結果が subtab で利用可能になり、完了します。これがスケジュールされている場合、または繰り返しスケジュールされた場合、操作は Schedules サブタブに表示されます。

11.2.2. 操作履歴の表示

注記
ユーザーは、スケジュールや編集操作への書き込みを持たせることができますが、操作履歴から項目を削除する権限があるわけではありません。
履歴内の要素を削除するには、インベントリーの管理パーミッションが必要です。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. Operations タブをクリックします。
  4. History サブタブをクリックします。
    完了した操作または進行中の操作がすべて表示され、現在のステータスを示すアイコンが表示されます。
  5. 操作の名前をクリックして詳細を表示します。履歴の詳細ページには、操作の開始時間および終了時間、操作またはその他の操作メッセージの標準出力、および操作をスケジュールしたユーザーの名前が表示されます。

11.2.3. 保留中の操作のキャンセル

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. Operations タブをクリックします。
  4. Schedules タブで、キャンセル操作の行をクリックします。
  5. をクリックし Delete、アクションを確認します。
注記
エージェントが操作を開始したら、キャンセルすることはできません。ユーザーが現在進行中の操作をキャンセルしようとすると、リクエストは無視されます。

11.2.4. グループ操作の順序

グループ操作はスケジュールできます。これは、特定の順序で操作を実行する必要がある場合に便利です。
注記
この手順では、グループがすでに設定されていることを前提とします。
  1. トップメニューの Inventory タブで、Groups 左側のメニューの Compatible Groups 項目を選択します。
  2. グループの名前をクリックして、操作を実行します。
  3. にあるように、操作を設定し 「スケジューリング操作」 ます。
  4. この Resource Operation Order エリアで、すべてのリソースに対して同時に(並列)または指定順序で実行されるように操作を設定します。操作が特定の順序で発生する必要がある場合は、すべてのグループメンバーが Member Resources ボックスに一覧表示され、必要に応じてドラッグアンドドロップによって再編成できます。
    オプションで、いずれかのリソースで失敗した場合に操作のグループキューを停止するには、Halt on failure チェックボックスを選択します。

11.2.5. JBoss サーバーの操作としてスクリプトを実行

JBoss ON は、リソースの検出時にリソーススクリプトを自動検出します。スクリプトは、他のリソースと同様に管理して操作を実行できます。オペレーティングシステムに応じて、JBoss ON が検出する 3 つのタイプのスクリプトがあります。
  • .bat Windows の場合
  • .sh Unix および Linux の場合
  • .pl Unix および Linux 用のスクリプト
注記
Linux および Unix システムのスクリプトには、x-bit が設定されている必要があります。
接続プロパティーと環境変数をスクリプトに追加できます。
操作としてスクリプトを実行するには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. Operations タブをクリックします。
  4. Schedules タブで、New ボタンをクリックします。
  5. Operation ドロップダウンメニューから操作タイプ Execute CLI script として選択します。
    注記
    この Execute script オプションは、デフォルトで JBoss AS および JBoss AS 5 リソースに対してのみ利用でき、スクリプトが実行できる場合にのみ利用できます。
  6. Parameters テキストボックスにコマンドライン引数を入力します。
    新しい引数はそれぞれ name=value; の形式を持ち、新しい行に追加されます。変数の値に構文のプロパティーが含まれる場合 %propertyName%、JBoss ON は値をスクリプトの親リソースの接続プロパティーから対応するプロパティーの現在の値として解釈します。
  7. にあるように操作の設定を終了し 「スケジューリング操作」 ます。

11.2.6. 操作タイムアウトのデフォルトの設定

1 つのリソースで同時に実行できる操作は 1 つだけです。オプションのタイムアウト設定は、操作を無期限にハングし、他の操作の実行をブロックしないようにします。JBoss ON のサーバー設定でグローバルのデフォルトタイムアウトを設定すると、タイムアウト期間が特定の操作に設定されていない場合でも、リソースで操作がブロックされないようにすることができます。
注記
このサーバー設定はフォールバック値です。操作プラグインは、プラグイン記述子で独自のタイムアウトを定義するか、個別の操作でタイムアウトを指定できます。この設定はいずれも、サーバーのデフォルトよりも優先されます。
  1. rhq-server.properties ファイルを開きます。
    vim serverRoot/jon-server-3.3.0.GA/bin/rhq-server.properties
  2. rhq.server.operation-timeout パラメーターの値を、動作が終了するまでサーバーが待機する時間(秒単位)に変更または追加します。
    rhq.server.operation-timeout=60

11.2.7. 操作履歴レポート

にあるように、すべてのリソースは独自の個別の操作履歴を追跡し 「操作履歴の表示」 ます。
JBoss ON は、すべてのリソースに対するすべての操作のマスターリストを保持します。これは Reports タブ Operation History Reportに表示されます。
リソースレベルの操作履歴と同様に、操作履歴には操作名、送信日、およびそのステータスが表示されます。すべてのリソースが一覧表示されるため、操作が実行されるリソースに曖昧な作業を行うのに役立つリソース名と、リソース名(および親) Operation History Report も表示されます。

図11.2 操作履歴レポート

操作履歴レポート
操作ステータスと、操作が送信された日付または日付範囲の 2 つの基準で(ソートするだけでなく)フィルターを設定 Operation History Report できます。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートに表示される情報のみがエクスポートされます。が日付またはステータスでフィルターされている場合 Operation History Report は、一致する操作のみがレポートに含まれます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ configurationHistory.csvます。


[2] スケジュールされた操作がない場合、タブには No items to show を読み取る説明があります。これは、リソースに利用できる操作がないことを意味します。つまり、操作がスケジュールされていないことを意味します。

第12章 サマリー: JBoss ON を使用したリソース設定の変更

アプリケーション、サーバー、およびサービスを管理する最も基本的な部分の 1 つは、設定を簡単に変更することです。
JBoss Operations Network を使用すると、プラットフォームのファイルシステムに直接アクセスしなくても、多くのリソースタイプの現在の設定を JBoss ON UI で直接表示できます。さらに、JBoss ON では、単一のリソースまたは互換性のあるリソースのグループ全体に対して設定を直接編集できます。
JBoss ON には、管理者がリソース設定を管理できる 3 つの主要な方法があります。
  • リソース設定を直接編集します。JBoss ON UI は、JBoss ON UI を使用してさまざまな管理リソースの設定ファイルを編集できます。
  • リソース設定の変更を監査および元に戻します。サポートされるリソースに対して JBoss ON が管理する特定の設定ファイルでは、設定プロパティーに対する個別の変更を確認し、以前のバージョンに戻すことができます。
  • 設定のドリフトを定義して監視します。システム設定は、特定の設定ファイルの特定の設定プロパティーよりも、より詳細なエンティティーです。アプリケーションの複数のファイルまたはプラットフォーム全体が連携して、最適な設定が作成されます。ドリフト は、その最適な設定から分析される(不可欠)差です。ドリフト管理を使用すると、希望するベースラインの設定を定義し、そのベースラインからのすべての変更を追跡できます。
本セクションでは、リソース設定を管理する 3 つの方法の概要を説明します。より詳細な説明および手順は、後続のセクションで説明します。

12.1. 簡単で構造化の設定

基本的な設定ファイルは、簡単なキーと値のペアを使用して情報を定義します。
key1 = value1
key2 value2
これらは文字列、数字、またはブール値を表す 単純なプロパティー です。ここでは、キーごとに 1 つの値があります。
JBoss ON は、値のリストまたは値のマップ(リスト表)である 複雑なプロパティー を使用したリソース設定もサポートします。
<default-configuration>
    <ci:list-property name="my-list">
        <c:simple-property name="element" type="string"/>
        <ci:values>
           <ci:simple-value value="a"/>
           <ci:simple-value value="b"/>
           <ci:simple-value value="c"/>
        </ci:values>
    </ci:list-property>
</default-configuration>
JBoss ON は、簡単なプロパティーと複雑なプロパティーの両方の設定ファイルを解析し、JBoss ON GUI で構造化され簡単なフォロー形式をレンダリングします。単純なプロパティーは必要に応じてフィールドまたはラジオボタンと共に表示されますが、複雑なプロパティーはメニューまたはその他の選択オプションと共に表示されます。

図12.1 Samba サーバーの設定フォーム

Samba サーバーの設定フォーム
構造化の設定フォームを使用すると、現在の設定をすばやく確認することが容易になります。
構造化フォームでは、変更を保存する前に JBoss ON が設定プロパティーに有効な形式があることを検証することもできます。
注記
JBoss ON は、指定の値がそのプロパティーで必要な形式と一致することのみを検証します。指定の値が、そのリソースプロパティーに合理的または許可されているかどうかは検証されません。
JBoss ON の設定変更を実行すると、IT 管理者にとって大きな利点があります。
  • UI で設定されるプロパティーの形式には、即時検証があります。
  • すべての設定変更の監査証跡は、外部および JBoss ON-initiated 設定変更のリソース履歴で表示できます。
  • 設定変更は、エラーが発生した場合に以前の安定した状態に戻すことができます。
  • 設定変更は、同じタイプのリソースのグループに対して行うことができるため、複数のリソース(異なるマシンでも含む)を同時に変更することができます。
  • アラートは、設定変更の自動通知を送信するか、設定の変更時に、関連するリソースで操作またはスクリプトを開始する場合に、設定の変更と併せて使用できます。
  • アクセス制御ルールは設定変更に有効であるため、JBoss ON ユーザーは特定のリソースの変更を表示または開始できません。

12.2. 変更可能な設定プロパティーの特定

JBoss ON は、ホストおよび sudoers ファイル、Samba サーバー、Postfix サーバー、データベース、Web アプリケーションコンテキスト、cron タブ、Web サーバー、スクリプトなど、さまざまなリソースの設定変更をサポートします。
JBoss ON による設定変更に対応するリソースには、そのリソースページに Configuration タブがあります。

図12.2 設定タブ

設定タブ
各リソースの設定プロパティーの完全リファレンスは、「 『リソースリファレンス: Monitoring、Operation、および Configuration Options』 」を参照してください。

12.3. リソース設定の変更の監査および取り消し

設定変更の追跡は、システム管理において不可欠なものです。これは、メンテナンス、パフォーマンス、インシデントリカバリー(特に変更を元に戻す場合やインシデントの変更を関連付ける場合)で重要です。
JBoss ON GUI とリソース自体に関係なく、リソース設定に変更が加えられるたびに、変更が JBoss ON によって検出され、リビジョン番号がログに記録されます。JBoss ON の外部で変更が加えられると、変更に注意する必要があります。JBoss ON UI で変更が加えられると、タイムスタンプと変更を行ったユーザーの名前の両方が記録されます。
すべての変更が履歴に記録され、異なる変更セットを表示および比較できます。1 つの変更を選択でき、選択した変更にリソース設定をロールバックできます。
設定履歴を追跡し、変更を元に戻す方法は 「設定変更の追跡および比較」、およびを参照してください 「設定変更を元に戻す」

12.4. 設定項目の追跡

JBoss ON 設定管理の多くは、設定ファイルを編集するか、ファイルおよびパッケージを更新することでリソースの変更を 実装する ように設計されています。しかし、設定を管理する別の要素は、変更を検出 することです。
管理者は、実稼動システムから内部リソースまで、あらゆるタイプの環境でシステムの最適な設定を計画する大量の時間を設定する必要があります。この理想的な構成には、ファイル設定、ソフトウェアバージョン、およびシステム設定が含まれます。リソース設定は徐々に変更しますが、管理者はこれらの変更を追跡して、予定外の変更や望ましくない変更がリソースに影響を与えないようにする必要があります。ベースラインの設定と変更追跡を定義すると、メンテナンス時および障害時にシステムが回復性を維持します。
リソースの設定に発生する予定外の変更は、設定が設計されたベースラインから移動するため、drift と呼ばれます。ドリフトは、特にコロケーション機能や仮想マシンの使用において、ソフトウェアやハードウェアの更新が頻繁に行われるために一般的です。
実稼働、ステージング、開発、およびリカバリーの設定は、一貫性を維持するために同一またはほぼ同一の設定を持つように設計されています。異なる環境内の設定が変更されると、設定の差が生じ ます。最終的に、この構成のギャップは、実稼働システムとバックアップシステムの構成が異なるため、障害復旧の失敗や高可用性の障害につながる可能性があります。
ドリフト監視 は、非常に一般的で、無料 コンテンツの監視 を可能にします。構造化の設定管理ではなく、ドリフト監視は、変更、ファイルの変更、バイナリーファイルの変更を追跡します。
Configuration History v.Configuration Drift
リソースの設定履歴は、その特定のリソースインスタンスのサポートされる設定プロパティーにのみ適用されます。
ドリフト管理には、設定変更に関する外部のビューがあります。ドリフトはプラットフォームや JBoss サーバーなどのリソースに関連付けられますが、そのリソースに制限されず、そのリソースのプロパティーを設定することはできません。
  • 誤差は、追加/削除されたファイルやバイナリーファイルなど、ディレクトリー内のファイル全体を調べます。
  • drift は、ドリフトの監視をサポートするすべてのリソースに適用できるユーザー定義のテンプレートをサポートします。
  • drift は、各変更セット(snapshot)が以前の一連の変更と比較される変更履歴を継続的に保持できます。JBoss ON では、定義されたベースラインスナップショットに対する各変更を比較できます。
基本的に監視する必要のあるディレクトリーとファイルを識別するプロファイルであるドリフト定義。ベースディレクトリーまたはそのサブディレクトリー(ファイルの変更、新規ファイル、削除ファイルなど)に変更が加えられるたびに、ドリフト検出によって変更が認識され、レコードが記録されます。
管理者は、予定の変更、メンテナンスおよび更新、およびサーバーの変更を追跡するために、管理者がドリフト検出を使用できます。変更が発生したことを管理者が認識する必要がある一般的なシナリオが多数あります(また、特定の変更を特定できます)。ただし、通常の JBoss ON 設定トラッキング外のエリアで発生します。
  • システムパスワードの変更
  • システム ACL の変更
  • データベースおよびサーバーの URL の変更
  • JBoss の設定変更
  • アプリケーションによって使用される JAR、WAR、およびその他のバイナリーファイルが変更されました。
  • スクリプトの変更
注記
ドリフトは JBoss ON によって管理されるリソースにバインドされず、制限されません。プラットフォームのドリフト定義を作成し、JBoss ON エージェントが実行するシステムユーザーがそのディレクトリーにアクセスできる限り、JBoss ON インベントリーのファイルまたはディレクトリーを監視するように設定できます。
設定のドリフトの管理については、を参照してください 15章設定項目の管理

第13章 リソースの設定変更

13.1. 単一リソースの設定変更

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リソースの Configuration タブを開きます。
  4. Current サブタブをクリックします。
  5. フィールドを編集するには、Unset チェックボックスが選択されて いない ことを確認してください。この Unset チェックボックスは、JBoss ON がそのリソースの値を送信せず、すべての値がリソース自体から取得されることを意味します。
    次に、設定を変更します。
    使用できる設定プロパティーと説明は、リソース 『リファレンスのリソースタイプ(Monitoring、Operation、および Configuration Options)』 ごとに一覧表示されます。
  6. プロパティーリストの上部にある Save ボタンをクリックします。

13.2. 互換性のあるグループの設定変更

アラートテンプレートなどの JBoss ON の他のテンプレート機能と同様に、設定変更は互換性のあるまたは autogroup で行うことができ、そのグループのすべてのメンバーが同じ設定と同時に更新できるようにします。
注記
グループの現在の設定を変更するには、現在のグループ設定を個別のリソース設定に対して確実に計算できるように、いくつかの条件を満たす必要があります。
  • グループメンバーはすべて同じリソースタイプである必要があります。
  • すべてのグループメンバーリソースが利用可能である必要があります(UP)。
  • グループまたはそのメンバーリソースの他の設定更新要求を続行することはできません。
  • 現在のメンバー設定はエージェントから正常に取得される必要があります。
グループの設定を設定するプロセスは、個々のリソースに設定することと同じです。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側のメニューの Groups ボックスで、Compatible Group リンクを選択します。
  3. 編集するグループを選択します。
  4. Configuration タブを開きます。
  5. Current サブタブをクリックします。
  6. フィールドを編集するには、Unset チェックボックスが選択されて いない ことを確認してください。この Unset チェックボックスは、JBoss ON がそのリソースの値を送信せず、すべての値がリソース自体から取得されることを意味します。
    次に、設定を変更します。
    使用できる設定プロパティーと説明は、リソース 『リファレンスのリソースタイプ(Monitoring、Operation、および Configuration Options)』 ごとに一覧表示されます。
    注記
    フォームを直接編集することで、すべてのメンバーの設定を変更することはできますが、グループメンバーのサブセットの設定を変更することもできます。緑色の鉛筆アイコンをクリックして、メンバーの設定を個別に変更します。
  7. フォームの上部にある Save ボタンをクリックします。

13.3. スクリプト環境変数の編集

スクリプトは、マシン上の他のアプリケーションおよびサービスと同様にサーバー上で自動検出されます。スクリプトは他のリソースと同様に設定および管理できるため、JBoss ON では設定の定義と設定の両方が可能で、インベントリーでスクリプトを実行することができます。
スクリプトが追加 または検出されるかどうかにかかわらず、インベントリーエントリーには 2 つの設定エリアのみがあります。これは、スクリプトへのパスと、階層内にスクリプトを配置するスクリプト、およびスクリプトで設定する必要のある環境変数です。
これらの環境変数は、スクリプトをインポートしても追加および編集できます。
重要
JBoss ON 設定で環境変数を設定する前に、リソースの環境が適切に設定され ていることを確認してください。
  1. トップメニューの Inventory タブをクリックします。
  2. スクリプトリソースを検索します。
  3. スクリプトリソースの Configuration タブを開きます。
  4. プラス記号(+)をクリックして、環境変数を追加します。
  5. 環境変数を入力します。新しい環境変数はそれぞれ name=value; の形式を持ち、新しい行に追加されます。
    変数の値に構文のプロパティーが含まれる場合 %propertyName%、JBoss ON は値をスクリプトの親リソースの接続プロパティーから対応するプロパティーの現在の値として解釈します。
  6. 環境変数をリセットしたら、JBoss ON エージェントを再起動して変更を伝播します。エージェントが再起動しないと、設定が正しい場合でも、新しい変数はリソースに伝播されず、スクリプトの実行時に解決されません。
注記
Windows スクリプト @echo off に行を追加して、実行結果と共に実行したコマンドの echo を防ぎます。

13.4. Configuring Apache for Configuration Management(非推奨)

JBoss ON では、Augeas lens を使用して Apache リソースの設定を管理します。Augeas の特別なバージョンは、Apache 設定管理を可能にする JBoss ON エージェントに含まれています。設定管理が機能するには、Apache リソースで Augeas lens を有効にする必要があります。

13.4.1. Apache Configuration Management に関する考慮事項および注意事項

非推奨の Augeas プラグイン

Apache 設定管理は、Linux インスタンス上の Augeas lens に接続し、管理する特別な Augeas エージェントプラグインを使用してサポートされます。Augeas エージェントプラグインは JBoss ON 3.1.1 で非推奨となり、今後のリリースで削除される可能性があります。

Augeas and Apache Monitoring

Apache 監視には Augeas lens は必要ありません。これは Apache 設定管理にのみ使用されます。Apache リソースは、アラート、操作、およびその他の管理タスクを、追加設定なしで監視できます。Augeas lens は、JBoss ON 経由で Apache 設定ファイルおよび仮想ホストを編集する場合にのみ使用されます。

Apache 設定でサポートされるプラットフォーム

Apache 設定管理は、Linux にインストールされる Apache インスタンスでのみサポートされます。

Apache ディレクトリーの noexec オプションの無効化

/tmp ディレクトリーが fstab ファイルに設定されて noexec いる場合、Augeas lens を適切に初期化できないため、エージェントは例外が発生します。この場合、Configuration タブは Apache リソースで利用できません。

/tmp ディレクトリーがオプションとして noexec 設定されていないことを確認します。
#
# /etc/fstab
#
tmpfs /dev/shm tmpfs defaults 0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

13.4.2. 設定管理の有効化

Apache 設定管理は、エージェントがリソースへの接続方法を設定する Apache リソースの接続設定の 1 つとして設定されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、Apache リソースを検索します。
  3. Apache インスタンスの IP アドレスをクリックします。
  4. Inventory タブを開き、Connections サブタブをクリックします。
  5. Augeas Configuration セクションに移動します。
  6. Augeas lens を有効にするには、Yes ラジオボタンを選択します。

第14章 リソース設定の変更の追跡

改訂番号は、JBoss ON サーバー全体でグローバル番号になります。たとえば、リソース A を編集すると、リビジョン #1 が返されます。次に、リソース B を編集するとリビジョン #2 を取得し、次の編集は #3 になります。
注記
設定を編集または元に戻す権利がありますが、設定履歴から項目を削除する権限があるわけではありません。
履歴内の要素を削除するには、インベントリーの管理パーミッションが必要です。

14.1. 設定変更の追跡および比較

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リソースの Configuration タブを開きます。
  4. History サブタブをクリックします。
  5. 表示または比較する設定バージョンの行を選択します。Ctrl キーを使用して複数のバージョンを選択します。現在の(最新の成功)設定状態は、緑色のチェックマークが付いています。
  6. Compare ボタンをクリックします。
  7. ポップアップウィンドウには、ディレクトリースタイルレイアウトの変更がすべて表示され、各設定エリアはハイレベルディレクトリーになります。変更はすべて red で示され、選択されたバージョンごとに値が表示されます。

14.2. 設定変更を元に戻す

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リソースの Configuration タブを開きます。
  4. History サブタブをクリックします。
  5. ロールバックする設定バージョンの行を選択します。現在の(最新の成功)設定状態は、緑色のチェックマークが付いています。
  6. Rollback ボタンをクリックします。

14.3. 設定履歴レポートの表示

設定をサポートするすべてのリソースは、にあるように、独自の個々の設定変更履歴を追跡し 「設定変更の追跡および比較」 ます。
JBoss ON は、すべてのリソースに対するすべての設定変更のマスターリストを保持します。これは Reports タブ Configuration History Reportに表示されます。
リソースレベルの設定履歴と同様に、構成履歴には、変更のバージョン番号、設定変更の要求および完了時間、ステータス、および要求ユーザーが表示されます。すべてのリソースが一覧表示されるため、変更が発生したリソースに曖昧さを示すため、リソース名とその親(およびグランド親) Configuration History Report も表示されます。

図14.1 設定履歴レポート

設定履歴レポート
は、リソースレベルの設定履歴と同様に比較操作を Configuration History Report サポートします。これは、同じリソースの設定のバージョンだけでなく、異なるリソースの同じ設定プロパティー(同じタイプ)にも比較できるので便利です。これにより、管理者はそれぞれのインフラストラクチャーの場所を特定し、同様のリソースの設定間で変更や変換を特定することができます。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ configurationHistory.csvます。

第15章 設定項目の管理

JBoss ON 設定管理の多くは、設定ファイルを編集するか、ファイルおよびパッケージを更新することでリソースの変更を 実装する ように設計されています。しかし、設定を管理する別の要素は、変更を検出 することです。
管理者は、実稼動システムから内部リソースまで、あらゆるタイプの環境でシステムの最適な設定を計画する大量の時間を設定する必要があります。この理想的な構成には、ファイル設定、ソフトウェアバージョン、およびシステム設定が含まれます。リソース設定は徐々に変更しますが、管理者はこれらの変更を追跡して、予定外の変更や望ましくない変更がリソースに影響を与えないようにする必要があります。ベースラインの設定と変更追跡を定義すると、メンテナンス時および障害時にシステムが回復性を維持します。
リソースの設定に発生する予定外の変更は、設定が設計されたベースラインから移動するため、drift と呼ばれます。ドリフトは、特にコロケーション機能や仮想マシンの使用において、ソフトウェアやハードウェアの更新が頻繁に行われるために一般的です。
実稼働、ステージング、開発、およびリカバリーの設定は、一貫性を維持するために同一またはほぼ同一の設定を持つように設計されています。異なる環境内の設定が変更されると、設定の差が生じ ます。最終的に、この構成のギャップは、実稼働システムとバックアップシステムの構成が異なるため、障害復旧の失敗や高可用性の障害につながる可能性があります。
ドリフト監視は、非常に一般的で、無料 コンテンツベースのモニタリング を提供します。構造化の設定管理ではなく、ドリフト監視は、ローカルファイルシステムのコンテンツの変更を追跡します。これは、バイナリーファイルであってもファイルの変更を意味します。 [3].

15.1. 誤差について

当然ながら、ドリフト監視は変更を確認するだけでは簡単ではありません。コアとなる質問の 1 つが変更点です。その質問には、概念的な部分が 2 つあります。
  • ドリフト監視に関連するディレクトリー(およびそれらのディレクトリー内のファイル)リソースにドリフト定義が定義されていても、実際のドリフト検出はディレクトリーレベルで実行されます。ドリフト監視は、JBoss ON によって管理される外部でも、プラットフォーム上の任意の場所に移動できます。
  • 変更の特定方法これを、作成前のバージョン、または確立されたベースラインと比較するか。
ドリフトを監視する変更を特定したら、JBoss ON を使用してモニタリングとアラートを効果的に設定できます。

15.1.1. ドリフト定義および検出

ドリフト検出の最初の部分は、監視しているものを識別することです。
JBoss ON は、ドリフトモニタリングのターゲットの場所を設定するドリフト定義 を定義します。ターゲットは、リソースの一部の設定要素から特定できます。ファイルシステム上のディレクトリーまたはファイル、リソース設定プロパティー、リソースプラグインパラメーター、または監視特性のいずれかです。このターゲットは ベースディレクトリー です。各リソースには、ファイルシステムの場所を定義する設定エリアが複数あります。ベースディレクトリーは、その情報が含まれる設定タイプを決定し、その情報エリアは 値コンテキスト です。値コンテキストには、以下の 4 つのいずれかの領域を使用できます。
  • プラグイン設定(pluginConfiguration)から。つまり、リソースの接続プロパティーから取得できます。接続プロパティーには、リソースタイプに応じてログファイル、デプロイメントディレクトリー、およびインストールディレクトリーを含めることができます。
  • リソース設定(resourceConfiguration)から。つまり、リソースの設定可能なプロパティーから取得できます。
  • 特性(measurementTrayt)から。特性は、リソースの情報測定プロパティーです。
  • 明示的なファイルシステムの場所。リソースプロパティーに適切な場所がない場合や、ドリフトに別の場所を使用する場合は、ディレクトリーを fileSystem プロパティーに指定できます。
実際の値は 値名 です。
注記
プラグイン設定(接続プロパティー)、リソース設定プロパティー、および各リソースの特性は、『Resource Reference』 に一覧表示されます。
たとえば、のベースディレクトリーには *.conf ファイルの変更のみ /etc/ が含まれる場合、drift 定義の要素は以下のようになります。
Value context: fileSystem
Value name: /etc
Includes: **/*.conf
注記
ドリフト検出は、ファイルシステムレベルで実行されます。これは、ドリフト検出が JBoss ON によって管理されるリソースにバインドされず、制限されないことを意味します。プラットフォームのドリフト定義を作成し、JBoss ON エージェントが実行するシステムユーザーがそのディレクトリーにアクセスできる限り、JBoss ON インベントリーのファイルまたはディレクトリーを監視するように設定できます。
デフォルトでは、ベースディレクトリーの下にあるすべてのサブディレクトリーとファイルは、ドリフトがないか監視されます。includes/excludes オプションは、 明示的に含まれる、またはドリフト監視から明示的に除外されるサブディレクトリーまたはファイルを定義します。含ま れている場合、指定のディレクトリーまたはファイルのみが監視され、その他のすべてが暗黙的に除外され、除外 されます。含まれるディレクトリーおよびファイルは、パスとパターンによって識別されます。パスはベースディレクトリーの下にある開始点で、パターンは監視するファイルと一致します。

表15.1 特定のファイルを含めるための組み合わせ

Drift をモニターするファイル 'includes' パス 'includes' パターン
/etc およびそのすべてのサブディレクトリー blank blank
/etc およびすべてのサブディレクトリーの *.conf ファイルの場合 . **/*.conf [a]
*.conf ファイルについては、/etc ディレクトリーでのみ、サブディレクトリーがない(/etc/*.conf) . *.conf
*.conf ファイルについては、/etc(/etc/*/*.conf)未満のサブディレクトリーでのみ使用されます。 できない できない
/etc の下にある特定のサブディレクトリー(yum.repos.d/)にあるファイル yum.repos.d(サブディレクトリー名) blank
[a] ディレクトリーの部分には、2 つのアスタリスクが必要です。1 つのアスタリスクでは機能しません。
ドリフト定義は、エージェントがドリフトをチェックする頻度に応じて間隔(頻度)も設定します。これは、JBoss ON とデータ管理の両方で非常に重要です。変更が欠落しているリスクが高くなりすぎる頻度を設定するか、または大きな変更(そのため管理が困難)スナップショットに切り替わります。しかし、間隔が低くても JBoss ON エージェントおよびサーバーのパフォーマンスに影響を及ぼします。
ドリフト定義に関する主な事項は、表示する内容と表示頻度を設定することです。
注記
誤差検出はすべて、エージェントプラグインの外部で実行され、リソースの状態に依存しません。リソースが実行されていない場合でも、ドリフト検出スキャンを実行できます。

15.1.2. スナップショット、ターミナルイメージ、およびベースラインイメージ

ドリフト検出の 2 番目の部分は、変更 の定義方法を特定することです。変更は比較です。ファイルの現行バージョンを取り、そのバージョンの以前のバージョンと比較します。ドリフト管理の質問は、比較する以前のバージョンです。
ドリフト定義が最初に作成されると、エージェントはそのベースディレクトリーとサブディレクトリーのすべてのファイルを収集し、それらをサーバーに送信します。このコレクションは初期ファイルセットです。
この時点から、エージェントはファイルの変更情報のみを送信します。各変更セットは スナップショット です。テキストファイルでは、変更情報にはファイルおよび diff の内容(エージェントが送信したパッチを基にして JBoss ON サーバーで構築される)が含まれます。バイナリーファイルでは、ファイルが変更され、SHA およびタイムスタンプが表示されます。スナップショットは、常に実際のリソースからの実際のファイルに基づいています。
注記
エージェントは実際のファイルを JBoss ON サーバーへ送信しません。エージェントは、ファイルの変更に関する情報をサーバーに送信します。これらの更新にはバージョン間の差分のみが含まれ、完全なファイルではありません。これにより、ネットワーク I/O が最小限に抑えられます。
実際の diff は、サーバーを保存するコンテンツからサーバーで生成されます。
スナップショットの作成方法は、現在のファイルをエージェントのバージョンと比較することです。この比較には、2 つの方法があります。
  • これは、ファイルの最新のバージョンと比較できます。
  • これは、定義した安定したベースラインと比較できます。
最初のオプションは ローリングスナップショット です。変更の集計を維持するため、これが最も簡単な設定になります。

図15.1 ローリングスナップショット

ローリングスナップショット
2 つ目のオプションは 固定されたスナップショット です。これは、管理者がドリフトに関する最も洞察と制御を行う方法です。ピニングされたスナップショットは、ベースディレクトリーの一部のイメージに最適な承認の設定があり、このスナップショットがベースラインとして選択されることを意味します。これは必須であり、後続の変更は、相互に比較されるのではなく、その固定されたスナップショットと比較されます。

図15.2 ピニングされたスナップショット

ピニングされたスナップショット
スナップショットは、システムに存在する実際のファイルに基づいているため、リソースレベルで存在します。スナップショットがリソースレベルの定義に固定されると、そのシステムに加えられた変更は、そのスナップショットと比較されます。現在のファイルバージョンが固定されたスナップショットと一致する場合、リソースは 準拠 します。
リソースのスナップショットは、ドリフトテンプレートに固定することもできます。その後、そのテンプレートにアタッチされているすべての定義に適用されます。これは、管理者にとって非常に強力なものです。たとえば、ステージングサーバーまたは開発サーバーを使用して EAP パフォーマンスに最適なシステム設定を作成し、誤差テンプレートに固定して、EAP ベースラインのスナップショットを本番環境のすべての EAP サーバーに適用することができます。定義した理想と相対的に、すべての EAP 設定が即座に表示されます。

15.1.3. 特殊なファイル種別を含む宛先のディレクトリー

ドリフトは、ローカルシステムのファイルとディレクトリーの両方を確認してスナップショットを生成し、変更を特定します。これらのファイルとディレクトリーの大半は実際のファイルになりますが、Unix には特別なファイルタイプがあります。また、誤差操作では、宛先ディレクトリーの処理の一部としてこれらのファイルが直面する可能性があります。特にシンボリックリンクや名前付きパイプには、いくつかの動作に関係があります。
シンボリックリンクでは、ドリフト検出は元のファイルまたはディレクトリーへのリンクに従い、スナップショットにそれらのファイルが含まれます。たとえば、一部のライブラリーにシンボリックリンクが設定されている場合は、以下のコマンドを実行します。
ln -ls /home/dev/libs /usr/share/jbossas/server/libs
JBoss Enterprise Application Platform ホーム libs/ ディレクトリーのディレクトリーにドリフトが設定されている場合は、シンボリックリンクにしたがって /home/dev/libs、ドリフトスナップショットにすべてのファイルを含めます。
重要
シンボリックリンクが含まれるディレクトリーにドリフトを設定する場合は注意してください。リンクされたすべてのファイルは、誤差ターゲットの一部として含まれます。
リンク先のディレクトリーに多数のファイルがある場合、ドリフト検出の実行には予想よりも時間がかかる可能性があります。また、そのシンボリックリンクディレクトリーへの変更は、意図された場合のドリフトと同じ多くの変更を記録することで、ドリフト検出に予期しない影響を及ぼす可能性があります。
ドリフト定義にシンボリックリンクのディレクトリーを含めない場合は、誤差定義の excludes パラメーターを使用してシンボリックリンクを除外します。
Unix システムで一般的な特別なファイルタイプは パイプ です。シンボリックリンクと同様、ドリフト検出の実行はターゲットディレクトリー内の fifo ファイルを検出できます。ただし、シンボリックリンクとは異なり、ドリフトは fifo ファイルを処理できず、ドリフト検出がハングします。
注記
drift 定義の excludes パラメーターを使用して、ターゲットディレクトリー内の名前付きパイプを除外します。

表15.2 ドリフト定義および Unix ファイルタイプ

ファイルタイプ Drift でサポートされますか?
file
ディレクトリー
シンボリックリンク
pipe いいえ
Socket いいえ
device いいえ

15.1.4. ドリフトおよびリソースタイプ

drift がリソースタイプ(で説明 「リソースおよびドリフト定義テンプレートについて」)で定義されるかどうか。drift テンプレートがリソースタイプの rhq-plugin.xml 記述子に定義されている場合、そのリソースタイプは drift をサポートします。テンプレートは開始点です(アラートまたはメトリクスコレクションテンプレートなどの強制された設定ではありません)。
3 つの JBoss ON の標準リソースタイプは drift をサポートします。
  • すべてのプラットフォーム
  • JBoss EAP 6(AS 7)および JBoss AS 5 プラグインを使用するすべてのリソース
  • JBoss AS/EAP 5、および JBoss AS 5 プラグインを使用するすべてのリソース
  • JBoss AS/EAP 4(非推奨)
誤差サポートはプラグイン記述子で定義されているため、これらのリソースタイプのドリフトサポートを追加するカスタムプラグインを作成できます。ドリフトサポートのあるエージェントプラグインを 作成する例は、『カスタム JBoss ON プラグイン 』を参照してください。
注記
drift は、EAR アプリケーションの下に組み込まれた WAR などの組み込み Web アプリケーションでは対応していません。
ドリフト検出は、ディレクトリーレベル で実行されます。特定のリソースには関連付けられていません。つまり、リソースが実行されていない場合でもドリフト検出を実行できます。また、JBoss ON によって管理されていないアプリケーション、サービス、またはファイルがドリフト検出をサポートしないリソースタイプに対しても、ドリフト検出が発生する可能性があります。
サポートされる 3 つのリソース外のエンティティーを監視するには、プラットフォームリソースでドリフト検出を設定し、監視するアプリケーションまたはサービスが使用するディレクトリーパスとしてベースディレクトリーを定義します。

15.1.5. ドリフト監視の領域の考慮事項

ドリフト監視の設定は、ディスク領域の要件に大きく影響する可能性があります。
JBoss ON は複数のスナップショットを保存します。これはバージョン管理の一部で、監視されたディレクトリーへの変更を元に戻すことができ、管理することができます。
したがって、バックエンドデータベース(Oracle または PostgreSQL)をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
サイズに関する考慮事項は、さまざまな方法でドリフト監視の設定に影響を及ぼす可能性があります。
  • 監視するディレクトリーのサイズ。状況によっては、大規模なディレクトリーが 1 つではなく、複数の小さなサブディレクトリーを監視する方が望ましい場合があります。
  • ドリフト検出の実行頻度。変更をキャプチャーする必要とバックアップコピーの数を分散します。
  • ドリフトスナップショットの保存期間。デフォルトでは、未使用のスナップショット(ピニングされていないスナップショット)は 31 日間保存され、その後削除されます。スナップショットの保存期間を変更すると、データベースサイズを管理するのに役に立ちます。
必要な領域を計算する際には、ターゲットディレクトリーのサイズを見積もり、スナップショットが取得される頻度を使用して、スナップショットを保存する数を把握します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。

15.1.6. Drift モニタリングに戻る

ドリフト検出を設定する目的は、システムおよびアプリケーションサーバーの変更方法の明確性を提供することです。JBoss ON では、ドリフトを管理する 2 つの方法を利用できます。

drift Monitoring

ドリフト監視は、ターゲットの場所への変更を追跡する機能です。JBoss ON GUI を使用すると、スナップショットをすべて表示し、スナップショット間で個々のファイルの変更を比較し、現在の設定を表示し、変更の詳細を表示できます。また、インベントリーおよびドリフトレポートも提供し、リソースが関連付けられたピニングされたスナップショットに準拠しているかどうかを一目で示します。

ドリフトアラート

ドリフトが発生するたびにアラートをトリガーする特定のアラート状態が存在する。ローリングスナップショットの場合、分散スナップショットごとにアラートが 1 度(および 1 回のみ)送信されます。ピニングされたスナップショットでは、後続の変更がない場合でも、リソースがコンプライアンス不足であっても、検出が実行されるたびに誤差アラートが発生します。

注記
JBoss ON GUI を介して直接ドリフトを修正する方法はありません。ただし、ドリフトアラートに対応して JBoss ON CLI スクリプトを起動することが可能です。たとえば、理想の EAP 設定のパッチを作成できます。EAP サーバーがその設定からドリフトする場合は、JBoss ON CLI スクリプトを使用して、その EAP パッチバンドルをドリフト EAP サーバーにデプロイできます。

15.2. リソースのドリフト定義の追加

重要
ドリフト検出が実行されるディレクトリーは、定義の作成後に変更する ことはできません。ベースディレクトリーと包含ファイルおよび除外ファイルを適切に設定してから保存してください。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リソースの Drift タブを開きます。
  4. 下をクリックし New て新しい定義を追加します。
  5. 新規定義のベースとして使用するテンプレートを選択します。
    プラグイン定義のテンプレートは、プラットフォームおよび JBoss サーバーリソースと、ドリフトモニタリングをサポートするその他のリソースで定義されます。ユーザー定義のテンプレートも作成および適用できます。
  6. 定義に一意の名前を指定します。name と base ディレクトリーは組み合わされ、JBoss ON 内で定義が特定されます。
  7. 間隔やテンプレートに関連付けられているかどうかなど、定義の設定を定義します。プロパティーはに一覧表示され 表15.3「ドリフト定義プロパティー」 ます。
  8. ベースディレクトリーを設定します。これは、定義に対してドリフト検出が実行される最上部のディレクトリーで、スキャンが再開します。
    テンプレート自体は初期ディレクトリーを定義しますが、より具体的なディレクトリーを設定すると便利な場合があります。
  9. 緑色のプラス(+)記号の付いたボタンをクリックして、include または exclude のサブディレクトリーを追加します。ディレクトリーは、ピリオド(.)をディレクトリーとして指定して、ベースディレクトリーにすることができます。パターンは、明示的に含めるか、または明示的に除外するサービスで、サービスによって認識するディレクトリー内のファイルを特定します。
    このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。たとえば、を使用して、任意のサブディレクトリーに .conf ファイルのみを含める **/*.conf ことができます。
    include/exclude フィルターは複数になる可能性があります。各ディレクトリーとパターンは個別に追加できます。

表15.3 ドリフト定義プロパティー

property description
Name ドリフト検出定義の名前。名前とベースディレクトリーは、定義を一意に識別します。
ベースディレクトリー: 値コンテキスト
ベースディレクトリーの特定に使用される設定プロパティーのタイプ。これは、リソースの要素のタイプを特定し、値を提供します。以下の 4 つのオプションがあります。
  • ファイルシステム。リソース上の絶対ディレクトリーパスです。drift が機能するには、このディレクトリーが存在している必要があります。
  • リソースに定義された設定プロパティーであるリソース設定。
  • 特性。リソースの監視対象の特性の 1 つです。
  • リソースプラグインで定義されるプロパティーであるプラグイン設定プロパティー。
ベースディレクトリー: 値名 ベースディレクトリーコンテキストに使用するドリフト検出定義の実際の値。たとえば、ファイルシステムコンテキストの場合、値はディレクトリーパスになります。
includes
誤差検出に、パターン(ベースディレクトリーとの関連)に一致するディレクトリー、ファイル、またはファイルおよびディレクトリーを明示的に含めます。
このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。
パターンを使用する場合は、パスがベースディレクトリーであっても、パスを指定する必要があります。たとえば、ベースディレクトリーに .conf ファイルのみを含めるには、パターン *.conf とパスがローカルディレクトリーを示すピリオド(.)になります。
excludes
誤差検出から、ベースディレクトリーに対して相対的なパターンに一致するディレクトリー、ファイル、またはファイルおよびディレクトリーを明示的に除外します。
このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。
パターンを使用する場合は、パスがベースディレクトリーであっても、パスを指定する必要があります。たとえば、ベースディレクトリーに .conf ファイルのみを含めるには、パターン *.conf とパスがローカルディレクトリーを示すピリオド(.)になります。
enabled 定義を有効または無効にします。定義を無効にすると、検出スキャンは実行されません。
interval 定義が検出実行の対象となる頻度を秒単位で設定します。これはハード設定ではありません。エージェントの負荷やその他のスケジュールされた操作により、検出の実行は指定された間隔で実行することが保証されていません。
pinned
誤差がローリング方式で決定されるかどうか、またはベースラインスナップショットと関連付けられる(ピニング)されるかどうかを設定します。定義の作成時にこれを設定すると、初期スナップショットがベースラインとして使用されます。
ピニングされたテンプレートにアタッチされている定義はピニング解除できません。ピニングされていないテンプレート、またはテンプレートにアタッチされていない定義は、ピニングされたり、ピニングされていない状態にすることができます。
ドリフト処理モード 誤差の変更がアラート(デフォルト)または予想通りにトリガーされるイベントとして処理されるかどうかを設定します。これにより、アラートがトリガーされないようにします。
テンプレートに添付
リソースレベルの定義がテンプレートに従属するかどうかを指定します。テンプレートにアタッチされている場合には、テンプレートが削除された場合など、テンプレートへの変更がリソース定義に反映されます。
デフォルトでは、定義は作成されたテンプレートに割り当てられます。
description 定義の簡単な説明。

15.3. 誤差定義テンプレートの作成

誤差定義が新たに作成されるたびに、リソースタイプの既存のテンプレートに基づいています。リソースプラグインのリソースタイプ(デフォルトでは、プラットフォームおよび JBoss アプリケーションサーバー)に対して、最低でも 1 つのテンプレートが定義されます。追加のテンプレートはユーザーが作成できます。

15.3.1. リソースおよびドリフト定義テンプレートについて

同じタイプのリソースには、同じ設定または同様の設定が必要になります。特に、構成のドリフトに関して、一貫性は正確かつタイムリーな IT 保守において重要です。JBoss ON では、ドリフト定義テンプレート を使用したこの一貫性が可能になります。アラートおよびモニタリングテンプレートと同様に、ドリフト定義テンプレートはリソース タイプに対して定義され(そのタイプ のリソースが実際に存在するかどうかに関わらず)、インベントリー内の特定のリソースに適用できます。
ドリフトテンプレートは、JBoss ON の他のテンプレートタイプとは若干異なります。まず、ドリフト定義テンプレートは完全に同じです。これは、リソースレベルのドリフト定義の作成時に使用するデフォルト設定および値の概要です。リソースに自動的に適用されません。
さらに、プラグイン定義のテンプレートとユーザー定義のテンプレートの 2 種類のドリフトテンプレートがあります。
1 つ以上の誤差定義テンプレートは、実際にはリソースタイプのプラグインの一部として定義されます。プラグイン記述子でテンプレートを定義することは、リソースタイプがドリフトモニタリングをサポートすることを示します。これらは プラグイン定義の テンプレートです。これらはデフォルトのテンプレートです。
プラグイン定義のテンプレートがあると、JBoss ON エージェントは特定のリソースタイプがドリフト監視に対応していることを認識する方法があります。したがって、プラグイン定義のテンプレートには 2 つの目的があります。JBoss ON では、JBoss ON はドリフトに対応するリソースタイプを把握でき、基本的な入力を提供し、管理者が独自のドリフト定義を開始できるようにします。

例15.1 JBoss Server 誤差定義テンプレート

<drift-definition name="Template-Base Files"
                  description="Monitor base application server files for drift. It defines monitoring for some standard sub-directories of the HOME directory.  Note, it is not recommeded to monitor all files for an application server. There are many files, and many temp files.">
    <basedir>
         <value-context>pluginConfiguration</value-context>
         <value-name>homeDir</value-name>
    </basedir>
    <includes>
 <include path="bin" />
        <include path="lib" />
        <include path="client" />
    </includes>
</drift-definition>
プラグイン定義のテンプレートに加えて、管理者が新しいドリフト定義テンプレートを追加することができます。これらは ユーザー定義 のテンプレートです。これらのテンプレートは、固有のインフラストラクチャーおよびアプリケーション環境を反映できます。
リソースレベルのドリフト定義は、常にドリフトテンプレートに基づいており、作成中に定義にいくつかのデフォルト値を提供します。そのテンプレートはプラグインの定義またはユーザー定義が可能です。リソースレベルのドリフト定義はテンプレートに割り当てる必要はありません。そのため、テンプレートが変更されるたびに変更する必要はありませんが、常に既存のテンプレートに基づいています。
ドリフト定義テンプレートには、以下の点に注意してください。
  • 誤差テンプレート 、JBoss ON の他のテンプレートタイプとは異なり、リソースに自動的に適用されません。誤差テンプレートは、リソースレベルの定義を作成するためのベースとして使用されます。
  • デフォルトのドリフトテンプレートは、プラグイン記述子の一部としてリソースに対して定義されます。カスタムのユーザー定義のテンプレートは、これらのデフォルトと共に追加できます。
  • 誤差の定義は、作成後のテンプレートにアタッチされていなくても、すべてのドリフト定義は最初にテンプレートに基づいています。
  • スナップショット(ドリフト定義に関連付けられたファイルセット)は、常にドリフト定義のリソース上で開始されます。テンプレートに関連付けるコンテンツには、リソースレベルのスナップショットをテンプレートにプロモートする必要があります。ドリフトテンプレートは、スナップショットやファイルを生成しず、リソースにプッシュします。

15.3.2. 誤差定義テンプレートの作成

ドリフトテンプレートの作成フォームは、リソースレベルのドリフト定義とほぼ同じです。ただし、2 つの例外は、作成時にスナップショットに固定できず、別のテンプレートに関連付けることができません。テンプレートは別のテンプレートに依存しません(別のテンプレートから作成 される場合 でも)。 テンプレートをスナップショットに固定できない状態も論理的です。テンプレートの作成時には、リソースとは関連付けられません。したがって、スナップショットを生成することはできません。つまり、テンプレートにピニングするものがないことを意味します。
  1. トップメニューの Administration タブをクリックします。
  2. 左側の Drift Definition Templates メニューテーブルを選択します。
  3. リソースタイプの鉛筆アイコンをクリックしてテンプレートを追加します。すべてのリソースがドリフトに対応しているわけではないため、選択することはできません。
  4. 下をクリックし New て、新しいテンプレートを追加します。
  5. 新規テンプレートのベースとして使用するテンプレートを選択します。
    プラグイン定義のテンプレートは、プラットフォームおよび JBoss サーバーリソースと、ドリフトモニタリングをサポートするその他のリソースで定義されます。ユーザー定義のテンプレートも作成および適用できます。
  6. テンプレートに一意の名前を付けます。name と base ディレクトリーは組み合わされ、JBoss ON 内で定義が特定されます。
  7. 定義の設定(間隔、デフォルトで有効かどうか)を定義します。プロパティーはの表に一覧表示され 「リソースのドリフト定義の追加」 ます。
  8. ベースディレクトリーを設定します。これは、定義に対してドリフト検出が実行される最上部のディレクトリーで、スキャンが再開します。
  9. 緑色のプラス(+)記号の付いたボタンをクリックして、include または exclude のサブディレクトリーを追加します。ディレクトリーは、ピリオド(.)をディレクトリーとして指定して、ベースディレクトリーにすることができます。パターンは、明示的に含めるか、または明示的に除外するサービスで、サービスによって認識するディレクトリー内のファイルを特定します。
    このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。たとえば、を使用して、任意のサブディレクトリーに .conf ファイルのみを含める **/*.conf ことができます。

15.4. 誤差定義の編集

JBoss ON のほとんどのエントリーは、名前をクリックするか、リストで行をダブルクリックして編集します。ただし、ドリフト定義の場合は、名前をクリックすると、定義エントリー自体ではなく、その定義のスナップショット一覧が開きます。
ドリフト検出定義を編集するには、鉛筆アイコンをクリックします。

15.5. スナップショットの変更の表示

注記
初期スナップショットは スナップショット 0 です。carousel のスナップショットはバージョン 1 から開始します。つまり、初期ファイルセットではなく、最初の変更から始まります。
スナップショットが固定され、これがベースラインとして設定される場合、スナップショット 0 はスナップショット 0 であるため、キャローセルにはは表示されません。ただし、定義一覧で固定されたアイコンをクリックすると表示できます。

15.5.2. 誤差変更の比較

変更は、完全なスナップショットレベルではなく、ファイルレベルで分散されます。管理者は、選択したファイルのバージョン間で加えられた特定の変更を表示できます。
注記
テキストファイルの変更のみを比較できます。ドリフト検出は、変更されたバイナリーファイルを特定し、タイムスタンプと SHA を表示しますが、バイナリーファイルのバージョン間でバイナリーファイルの内容や diff の変更は表示されません。
  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
  3. リソースの Drift タブをクリックします。
  4. ドリフト定義の名前をクリックします。
  5. 比較するファイルの名前をクリックします。
  6. をクリックし Compareます。
diff は、ファイル diff の表示に標準のテキスト形式を使用します。

図15.4 セットの違いの変更

セットの違いの変更

15.5.3. スナップショットの詳細表示

  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
  3. リソースの Drift タブをクリックします。
  4. ドリフト定義の名前をクリックします。
  5. スナップショットのサイズで、表示するスナップショットの名前で虫眼鏡をクリックします。
  6. ディレクトリーを展開して、そのスナップショットの変更の一覧を表示します。
  7. 特定の変更の詳細を表示するには、(view) リンクをクリックします。
  8. このファイルの詳細には、ファイルの直前のバージョン、ファイルの変更バージョン、および 2 つのファイル間の diff を表示するリンクが表示されます。
    view リンクをクリックすると、ページタイトルとファイル名が表示されます。たとえば、のバージョン 6 を表示する場合は myfile.txt、タイトルは myfile.txt:6 になります。

15.5.4. タイムラインでのドリフトイベントの表示

誤差が検出されると、リソースのイベントタイムラインのイベントとして表示されます。
  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
  3. Summary タブで Timeline サブタブをクリックします。
  4. 検出は、のタイムラインでドリフトが検出された場合に実行され Drift Detectedます。タイムラインでドリフトイベントのみを表示するには、チェックボックス以外のすべてをクリアし Drift ます。
    期間をリセットして、タイムラインの期間を調整できます。

15.5.5. 誤差スナップショットレポートの確認

スナップショットキャレット(「スナップショットの作成」)は、1 つのリソースに単一のドリフト定義のスナップショットをすべて表示します。すべてのリソースにおけるすべての定義について、スナップショットの一覧を表示するには、Recent Drift Report を確認してください。
  1. 上部の Reports ナビゲーションメニューのタブをクリックします。
  2. レポートリストから Recent Drift Subsystems レポートを選択します。
  3. すべてのドリフトインスタンスが一覧表示され、スナップショットの作成時間別にソートされます。
  4. 必要に応じて、ドリフト変更の一覧をフィルタリングします。フィルターオプションは 4 つあります。
    • 定義名
    • スナップショット番号(ドリフト定義にまたがる)
    • ファイルの追加、削除、または変更に関わらず、スナップショット内の変更タイプです。
    • スナップショット内の変更のパス。このパスは、ディレクトリー、ファイル名、検索式のいずれかです。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートに表示される情報のみがエクスポートされます。が日付、定義、スナップショットまたはバージョン、またはカテゴリーによってフィルターされている場合 Recent Drift Report は、一致する操作のみがレポートに含まれます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ recentDrift.csvます。

15.6. スナップショットのピニングとコンプライアンスの管理

の説明にあるように 「スナップショット、ターミナルイメージ、およびベースラインイメージ」、特定のスナップショットと、その完全な現在のファイルセットを持つスナップショットは、ドリフト定義に関連付けたり、固定 したりすることができます。スナップショットをピニングすると、完全に新しいスタイルのドリフト定義が作成されます。固定されたスナップショットは単に変更を追跡するのではなく、管理者がシステムまたはアプリケーションの明確で正確な設定を確立できます。システム設定が準拠する標準を設定します。

15.6.1. Pinning スナップショットの詳細

スナップショットは、特定のリソースにある実際のファイルに関する図です。スナップショットは、実際のビューです。通常のドリフト状態の場合、各スナップショットは変更を表示する直前に 1 つのスナップショットと比較されます。ただし、特定のスナップショットを固定ベースラインとして選択して、変更を比較することができます。これは 固定のスナップショット です。
ドリフト定義は、ドリフト検出を実行するルールを設定しますが、リソース上のファイルを追加または削除したり、上書きしたりしません。ドリフト定義は、コンテンツを定義したり、ファイルセットが含まれたりしません。コンテンツは定義(または定義テンプレート)に追加する必要があります。スナップショットの作成後に、ファイルセット(スナップショット)をドリフト定義に手動で追加する必要があります。これはピニングです。ピニングは、実際の既存ファイルセットをスナップショットから取得し、リソースのドリフト定義またはドリフト定義テンプレートにリンクします。
ピニングとは、管理者がリソース設定の標準化に使用できる方法の 1 つです。管理者は、1 つのリソースをテストボックスとして使用して、リソースの構成を理想の設定に調整できます。次に、そのファイルセットをテンプレートに固定し、同じタイプの他のリソースに再適用できます。ピニングされたスナップショットは実際のリソースに基づいているため、管理者は、設定が実際の状態で機能していることを確実に確認することができます。
スナップショットのピニングを行うと、JBoss ON のドリフト管理に関する基本的な動作が変更されます。
  • そのスナップショットの前に作成されたスナップショットを削除します。たとえば、管理者はスナップショット 7 のピニングを決定し、スナップショット 6 を介してスナップショット 0(初期イメージ)はすべて削除され、スナップショット 7 が新しいスナップショット 0 になります。
  • 変更の移動集計ではなく、すべての変更と比較するベースラインイメージが作成されます。
  • システム設定が固定されたスナップショットに準拠するまでアラートが継続的に送信されるように、ドリフトアラート(「ドリフトアラートの定義」)の動作を変更します。
  • スナップショットのピニングを解除するまで、固定されている定義は削除できません。
  • スナップショットがテンプレートに固定されている場合は、そのテンプレートに割り当てられるリソースレベルの定義はすべて、ピニングされたスナップショットをベースラインとして自動的に使用します。
  • スナップショットのピニング後に追加された新規ファイル(またはファイルの削除)は、後続のスナップショットごとに新規ファイルとして報告されます。これは、新規スナップショットは常にベースラインのスナップショットと比較されるため、ファイルは常にベースラインに新しいものになります。
    drift で同じ変更が報告されないようにするロジックがあります。追加すると、エージェント file1.txt はスナップショット 1 を作成します。エージェントが次の検出を実行する場合、これ file1.txt はベースラインに含まれていないことを認識しますが、変更さ file1.txt れていない限り、エージェントは新しいドリフトとしてこれを報告せず、新しいスナップショットを作成しません。ただし、変更が加えられた場合、エージェント file1.txt は新しい SHA を認識し、変更したスナップショットを新規ファイルとして送信します。これは、以前のバージョンではなくベースラインと比較 file1.txt されるためです。

15.6.2. When to a Resource and When to a Template

スナップショットが管理者が選択する設定と一致する場合は、ドリフト定義に関連付けることができます。そのスナップショットは、リソースレベルの定義または定義テンプレートに固定でき、もう 1 つまたは別の定義を行う理由がいくつかあります。
  • スナップショットをリソースレベル定義にピニングすると、そのリソースのベースラインが作成されます。これは、理想のベースラインイメージや、他のリソースに移行しない一意の環境では、引き続き理にかなっています。
    リソース定義にピニングすることで、多くの柔軟性が得られます。ピニングおよびアンピン解除して、新しいスナップショットをベースラインとして簡単に選択し、変更が含まれているため、ドリフトイベント、アラート、およびモニタリングへの影響を最小限に抑えた理想的な設定を開発することができます。
  • スナップショットをテンプレートに固定すると、そのテンプレートを使用するすべてのリソースにベースラインを適用でき、1 つのスナップショットを複数のリソースに適用できるようになります。これは、あらゆる種類の繰り返し可能な設定エリアと、一貫した設定が必要となる実稼働または重要なシステムでは理にかなっています。
    テンプレートへのピニングは、理想的な設定が開発されると、インフラストラクチャー全体で一貫性を維持する非常に強力なものです。
ピニングは常に、特定のリソースで作成されたスナップショットを作成してから、その定義のベースラインとなるようにプロモートします。そのため、その質問は、「リソースレベルのスナップショットをテンプレートに固定する必要があるのはなぜですか?」です。テンプレートが独自のスナップショットを作成および使用できないのはなぜですか?
誤差定義テンプレートは、リソース タイプ に関連付けられていることに注意してください。テンプレートは特定のリソースの一部として定義されません。
リソースレベルのドリフト定義では、最初のドリフト検出の実行により、実際のファイルおよび既存ファイルを基にして初期スナップショットが作成されます。初期スナップショットをベースラインとして使用してから、その初期スナップショットはベースライン、ピニングされたスナップショット、またはスナップショットとして自動的に適用できます。
ただし、ドリフト定義テンプレート(「リソースおよびドリフト定義テンプレートについて」)はリソースとは関連付けられません。そのため、テンプレートには操作する実際のファイルセットがなく、使用するスナップショットはありません。誤差テンプレートをスナップショットに関連付けることができる唯一の方法は、リソースレベルのスナップショットがテンプレートに固定されている場合にのみ行います。
よって、スナップショットのピニングには、ドリフト定義の定義に関する後方ワークフローがあります。定義はテンプレートで始まり、その後リソースレベルの定義に移行し、そのリソースのスナップショットを生成します。ピニングは常にリソースのスナップショットで始まり、定義または定義テンプレートに移動します。
注記
ドリフト定義は、ドリフト検出に使用する非常に明確で制限された基準のセットを設定します。スナップショットがドリフト定義テンプレートに関連付けられる場合、テンプレートは、スナップショットを生成した元のリソースレベルのドリフト定義と同じ設定を使用する必要があります。一致するテンプレートが存在しない場合は、その基準を使用して新しいテンプレートを作成できます。

15.6.3. リソースレベルの定義へのピニング

  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
  3. Drift タブをクリックします。
  4. ドリフト定義の名前をクリックします。
  5. スナップショットのキャレットで、ピン留めするスナップショットの名前で虫眼鏡をクリックします。
    注記
    最初のスナップショットは、carousel には表示されません。初期スナップショットを固定するには、ドリフト定義一覧の Pinned コラムにあるサムネックアイコンをクリックします。これにより、初期スナップショットが開きます。
    スナップショットがすでにピニングされている場合は、サムネックアイコンをクリックすると、ピニングされたスナップショットが開きます。
  6. 変更リストの下部にある Pin to Definition ボタンをクリックします。

15.6.4. テンプレートへのピニング

  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
  3. Drift タブをクリックします。
  4. ドリフト定義の名前をクリックします。
  5. スナップショットのキャレットで、ピン留めするスナップショットの名前で虫眼鏡をクリックします。
    注記
    最初のスナップショットは、carousel には表示されません。初期スナップショットを固定するには、ドリフト定義一覧の Pinned コラムにあるサムネックアイコンをクリックします。これにより、初期スナップショットが開きます。
    スナップショットがすでにピニングされている場合は、サムネックアイコンをクリックすると、ピニングされたスナップショットが開きます。
  6. 変更リストの下部にある Pin to Template ボタンをクリックします。
  7. リソースレベルのテンプレートが既存のテンプレートをベースまたは割り当てられている場合には、スナップショットを既存のテンプレートに関連付けることができます。リソースレベルのスナップショットのベースディレクトリーが既存のドリフトテンプレートと一致しない場合は、新しいテンプレートを作成する必要があります。
  8. にあるように、drift テンプレートを作成し 「誤差定義テンプレートの作成」 ます。

15.6.5. 誤差コンプライアンスレポートの確認

コンプライアンスレポートは、インベントリーレポートのバリアントです。これは、誤差定義が現在設定されているすべてのリソースを一覧表示し、それらが準拠しているかどうかを確認します。コンプライアンスは累積的です。リソースに複数のドリフト定義があり、1 つのノードに準拠しない場合は、レポートに準拠していないことが示されます。
  1. 上部の Reports ナビゲーションメニューのタブをクリックします。
  2. レポートリストから Drift Compliance Inventory レポートを選択します。
  3. ドリフト定義を持つすべてのリソースは、タイプおよびアイコンで一覧表示さ れ、それが準拠しているかどうかを確認します( )またはコンプライアンス違反( ).
  4. 特定のリソースに関する情報を取得するには、リソース種別名をクリックします。これにより、メインレポートの下に 2 番目のインベントリーレポートが開きます。このタイプのすべてのリソースは、コンプライアンス状態で一覧表示されます。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ driftCompliance.csvます。

15.6.6. スナップショットのピニング解除

スナップショットは、リソースレベルの定義またはドリフトテンプレートからピニング解除したり、割り当て解除したりできます。スナップショットのピニングを解除すると、定義がローリングドリフト検出モードに戻ります。コンプライアンス不足のリソースは、準拠していないとマークされなくなります。
  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
  3. Drift タブをクリックします。
  4. ドリフト定義のピンアイコンをクリックします。

15.7. 拡張例: 必要な EAP 設定の定義

設定

Tim the IT Guy at Example Corp. には、実稼働環境で稼働中の EAP サーバーが 1 つあります。実稼働環境の負荷により、EAP サーバーは通常のメモリーが不足していたため、パフォーマンスが低下し、Example Corp. の Web サイトのダウンタイムが発生していました。

即時メモリーの問題を解決するには、Tim はすべて EAP インスタンスのヒープサイズ設定を変更するだけです。ただし、Tim は設定の長期管理に別のストラテジーが必要です。新たな実稼働 EAP インスタンスを追加するか、現在の実稼働用の EAP インスタンスを置き換えるために新しいインスタンスをデプロイすると、新しいヒープサイズ設定なしに同じメモリー関連のパフォーマンスの問題が発生します。

操作方法

Tim は、EAP のパフォーマンスを維持したい 3 つの要素があります。

  • EAP インスタンスに一貫して設定を適用する方法を見つけます。
    JBoss EAP インスタンス(「誤差定義テンプレートの作成」)のテンプレートを定義します。一貫性を維持するために、テンプレートは Attach to template 値を true に設定し、各リソースレベルのドリフト定義はその設定を保持します。これにより、テンプレートへの変更が JBoss リソースずれの定義に自動的に適用されます。
  • 現在の実稼働設定を、今後の EAP インスタンスのベースとして使用します。
    テンプレート定義(「テンプレートへのピニング」)により高いヒープ設定で最新のスナップショットをピニングします。すべての EAP インスタンスがそのベースラインと比較されます。したがって、誤ったヒープ設定を持つものはすべて、即座にコンプライアンスから除外されます。
  • 現在の EAP 設定と希望の設定の相違点に注意してください。
    これは、とくに bin/run.conf ファイルをターゲットとするアラート定義(「ドリフトアラートの定義」)を作成します。これにより、ヒープ設定およびその他の JVM 設定が新規インスタンスで間違っているかどうかを正確に認識します。CLI スクリプトを使用して現在の EAP 設定をピニングされたスナップショットと比較し、diff を送信するなど、アラートを使用して EAP インスタンスの設定の方法に関する詳細情報を取得することもできます。

予想される結果

Tim は新しいサーバーをオンラインにし、実稼働環境用の新しい EAP インスタンスを提供します。誤差テンプレートを新しいリソースに適用し、数分以内に、希望の設定に準拠し run.conf ていないという通知を受け取ります。パフォーマンスの低下が変更を書き込むまで待機せずに、新しい EAP インスタンスのヒープ設定を変更します。

15.8. ドリフトアラートの定義

ドリフト変更には独自のアラート条件があります。
注記
リカバリーアラートは、ドリフトについてはサポートされません。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. 一覧のリソース名をクリックします。
  4. リソースの Alerts タブをクリックします。
  5. Definitions サブタブで New ボタンをクリックして新しいアラートを作成します。
  6. General Properties タブで、アラートに関する基本情報を指定します。
    誤差定義に重要な設定ファイルが含まれている場合は、優先度 を設定すると便利です。
  7. Conditions タブで、conditions 一覧から Drift Detection オプションを選択します。すべてのドリフト変更にアラートを使用するには、フィールドを空白のままにしておきます。それ以外の場合は、特定のドリフト定義名と(任意)アラートをトリガーするために変更する必要のあるディレクトリーまたはファイルを入力します。
    注記
    複数の条件セットを使用してアラートをトリガーすることができます。つまり、複数のドリフト定義またはファイルに同じアラートを使用できます。
  8. Notifications タブで Add をクリックし、アラートの通知を設定します。
    Sender オプションでアラート通知を送信するために使用する方法を選択し、必要な情報を入力します。
    Sender オプションは、最初に特定のタイプのアラートメソッド(電子メールや SNMP など)を設定し、適切なフォームを開いてその方法の詳細を入力します。
  9. 必要に応じて、Dampening タブで、ドリフトの通知を送信する頻度について、mensepening(または頻度)ルールを指定します。
    注記
    ピニングされたスナップショットの場合は、ドリフトの問題を修正する前にアラートがあふれるのを防ぎます。
    破損は、固定のスナップショットを使用した定義のみに限定されます。ピニングされた定義は、追加の変更がない場合でも、コンプライアンス不足である限り、すべてのアラートスキャン(すべてのアラートスキャンすべて)でアラートを出力します。ローリング定義は、ドリフトが検出されるとアラートが一度だけ実行されます。
    破損ルールのいずれかを使用できます。最適なゴールは、固定された定義を満たさないリソースに対して同じアラートが設定された回数を制限することです。たとえば、期間は、アラート条件が発生した場合にアラートが発行される期間に制限を設定します。発生を 1 に、かつ 4 時間に設定すると、ドリフトが 1 回検出されると、サーバーはアラートを送信してから次の 4 時間待機してから次のアラートを送信します。
  10. OK をクリックし、アラート定義を保存します。

15.9. 拡張例: バンドルおよびサーバースクリプトを使用した元の設定に戻す

設定

では 「拡張例: 必要な EAP 設定の定義」、Tim the IT Guy が例に記載されています。ずれのテンプレートとアラートを設定して、実稼動の EAP サーバーでの設定を管理します。ただし、解決は手動で行われました。誤差アラートが EAP サーバーがコンプライアンス不足であることを通知すると、ヒープサイズを調整するために run.conf 直接編集しました。

小規模なインフラストラクチャーまたは頻繁に変更されない場合には、手動の更新で問題ありません。ただし、より優れた管理ツールは、ドリフトに必要な修復を自動化することです。

操作方法

この目的は、Tim(IT 管理者)からのアクションを必要とせずに、JBoss ON がドリフトに対してインテリジェントに応答することが目的です。自動応答を許可する 2 つの機能があります。

  • バンドル を使用して、更新されたファイルまたはアプリケーションをプロビジョニングします。バンドルは、Ant レシピと、アプリケーションに必要なコンテンツ(設定ファイルや JAR など)を含む ZIP ファイルです。JBoss ON では、指定のディレクトリーにあるプラットフォームまたは JBoss サーバーにこのコンテンツをプロビジョニングできます。
  • アラートの応答で JBoss ON CLI スクリプトを起動します。可能なアラート通知の 1 つがサーバー側のアラート送信者です。JBoss ON CLI スクリプトはコンテンツとしてロードされ、JBoss ON サーバーに保存されます。アラートが発生すると、指定の保存された CLI スクリプトが開始されます。

バンドルおよび CLI スクリプトを使用して修正する手順はいくつかあります。
  1. ピニングされたスナップショット設定に基づいてバンドルファイルを作成します。バンドルの内容は、デプロイメントのニーズにより異なります。この設定ファイルには、のような特定の設定ファイルを使用でき bin/run.conf、完全な EAP サーバーになります。
    注記
    バンドルに完全な EAP サーバーが含まれている場合は、初期 EAP サーバーの作成に使用できます。
  2. バンドルを完全な EAP サーバーと共にデプロイし、新しい EAP インスタンスを作成します。または、バンドルに設定ファイルのみが存在する場合は EAP インスタンスを作成します。
  3. 新しい EAP インスタンス用に、以前に設定したテンプレート(「拡張例: 必要な EAP 設定の定義」)に基づいてドリフト定義を設定します。
  4. 指定されたバンドルを適切な宛先に自動的にデプロイする JBoss ON CLI スクリプト(JavaScript で)を作成します。の例は次のとおりです 例15.2「fix-eap.js スクリプト」。そのスクリプトでは、destinationId および bundleVersionId を JBoss ON の宛先エントリーおよびバンドルバージョンエントリーの実際の ID 番号に置き換えます。
  5. ドリフト検出条件でトリガーされ、作成した JavaScript ファイルを参照する CLI スクリプト通知タイプを使用するアラート定義を作成します。

予想される結果

EAP サーバーでドリフトが検出されると、にあるようにアラートがトリガーされ 「拡張例: 必要な EAP 設定の定義」 ます。この場合、アラートは CLI スクリプトを応答して起動し、承認された EAP 設定がすでにあるバンドルをリソースに自動的にデプロイします。つまり、EAP サーバーはコンプライアンスから数分以上発生せず、1 つのアラートスキャンの長さが大きくなります。IT 保証Tim の介入なしにすべて。

例15.2 fix-eap.js スクリプト

/**
 * If obj is a JS array or a java.util.Collection, each element is passed to
 * the callback function. If obj is a java.util.Map, each map entry is passed
 * to the callback function as a key/value pair. If obj is none of the
 * aforementioned types, it is treated as a generic object and each of its
 * properties is passed to the callback function as a name/value pair.
 */
function foreach(obj, fn) {
  if (obj instanceof Array) {
    for (i in obj) {
      fn(obj[i]);
    }
  }
  else if (obj instanceof java.util.Collection) {
    var iterator = obj.iterator();
    while (iterator.hasNext()) {
      fn(iterator.next());
    }
  }
  else if (obj instanceof java.util.Map) {
    var iterator = obj.entrySet().iterator()
    while (iterator.hasNext()) {
      var entry = iterator.next();
      fn(entry.key, entry.value);
    }
  }
  else {   // assume we have a generic object
    for (i in obj) {
      fn(i, obj[i]);
    }
  }
}

/**
 * Iterates over obj similar to foreach. fn should be a predicate that evaluates
 * to true or false. The first match that is found is returned.
 */
function find(obj, fn) {
  if (obj instanceof Array) {
    for (i in obj) {
      if (fn(obj[i])) {
        return obj[i]
      }
    }
  }
  else if (obj instanceof java.util.Collection) {
    var iterator = obj.iterator();
    while (iterator.hasNext()) {
      var next = iterator.next();
      if (fn(next)) {
        return next;
      }
    }
  }
  else if (obj instanceof java.util.Map) {
    var iterator = obj.entrySet().iterator();
    while (iterator.hasNext()) {
      var entry = iterator.next();
      if (fn(entry.key, entry.value)) {
        return {key: entry.key, value: entry.value};
      }
    }
  }
  else {
    for (i in obj) {
      if (fn(i, obj[i])) {
        return {key: i, value: obj[i]};
      }
    }
  }
  return null;
}

/**
 * Iterates over obj similar to foreach. fn should be a predicate that evaluates
 * to true or false. All of the matches are returned in a java.util.List.
 */
function findAll(obj, fn) {
  var matches = java.util.ArrayList();
  if ((obj instanceof Array) || (obj instanceof java.util.Collection)) {
    foreach(obj, function(element) {
      if (fn(element)) {
        matches.add(element);
      }
    });
  }
  else {
    foreach(obj, function(key, value) {
      if (fn(theKey, theValue)) {
        matches.add({key: theKey, value: theValue});
      }
    });
  }
  return matches;
}

/**
 * A convenience function to convert javascript hashes into RHQ's configuration
 * objects.
 * <p>
 * The conversion of individual keys in the hash follows these rules:
 * <ol>
 * <li> if a value of a key is a javascript array, it is interpreted as PropertyList
 * <li> if a value is a hash, it is interpreted as a PropertyMap
 * <li> otherwise it is interpreted as a PropertySimple
 * <li> a null or undefined value is ignored
 * </ol>
 * <p>
 * Note that the conversion isn't perfect, because the hash does not contain enough
 * information to restore the names of the list members.
 * <p>
 * Example: <br/>
 * <pre><code>
 * {
 *   simple : "value",
 *   list : [ "value1", "value2"],
 *   listOfMaps : [ { k1 : "value", k2 : "value" }, { k1 : "value2", k2 : "value2" } ]
 * }
 * </code></pre>
 * gets converted to a configuration object:
 * Configuration:
 * <ul>
 * <li> PropertySimple(name = "simple", value = "value")
 * <li> PropertyList(name = "list")
 *      <ol>
 *      <li>PropertySimple(name = "list", value = "value1")
 *      <li>PropertySimple(name = "list", value = "value2")
 *      </ol>
 * <li> PropertyList(name = "listOfMaps")
 *      <ol>
 *      <li> PropertyMap(name = "listOfMaps")
 *           <ul>
 *           <li>PropertySimple(name = "k1", value = "value")
 *           <li>PropertySimple(name = "k2", value = "value")
 *           </ul>
 *      <li> PropertyMap(name = "listOfMaps")
 *           <ul>
 *           <li>PropertySimple(name = "k1", value = "value2")
 *           <li>PropertySimple(name = "k2", value = "value2")
 *           </ul>
 *      </ol>
 * </ul>
 * Notice that the members of the list have the same name as the list itself
 * which generally is not the case.
 */
function asConfiguration(hash) {

 config = new Configuration;

 for(key in hash) {
  value = hash[key];

  if (value == null) {
   continue;
  }

  (function(parent, key, value) {
   function isArray(obj) {
    return typeof(obj) == 'object' && (obj instanceof Array);
   }

   function isHash(obj) {
    return typeof(obj) == 'object' && !(obj instanceof Array);
   }

   function isPrimitive(obj) {
    return typeof(obj) != 'object';
   }

   //this is an anonymous function, so the only way it can call itself
   //is by getting its reference via argument.callee. Let's just assign
   //a shorter name for it.
   var me = arguments.callee;

   var prop = null;

   if (isPrimitive(value)) {
    prop = new PropertySimple(key, new java.lang.String(value));
   } else if (isArray(value)) {
    prop = new PropertyList(key);
    for(var i = 0; i < value.length; ++i) {
     var v = value[i];
     if (v != null) {
      me(prop, key, v);
     }
    }
   } else if (isHash(value)) {
    prop = new PropertyMap(key);
    for(var i in value) {
     var v = value[i];
     if (value != null) {
      me(prop, i, v);
     }
    }
   }

   if (parent instanceof PropertyList) {
    parent.add(prop);
   } else {
    parent.put(prop);
   }
  })(config, key, value);
 }

 return config;
}

/**
 * Opposite of <code>asConfiguration</code>. Converts an RHQ's configuration object
 * into a javascript hash.
 *
 * @param configuration
 */
function asHash(configuration) {
 ret = {}

 iterator = configuration.getMap().values().iterator();
 while(iterator.hasNext()) {
  prop = iterator.next();

  (function(parent, prop) {
   function isArray(obj) {
    return typeof(obj) == 'object' && (obj instanceof Array);
   }

   function isHash(obj) {
    return typeof(obj) == 'object' && !(obj instanceof Array);
   }

   var me = arguments.callee;

   var representation = null;

   if (prop instanceof PropertySimple) {
    representation = prop.stringValue;
   } else if (prop instanceof PropertyList) {
    representation = [];

    for(var i = 0; i < prop.list.size(); ++i) {
     var child = prop.list.get(i);
     me(representation, child);
    }
   } else if (prop instanceof PropertyMap) {
    representation = {};

    var childIterator = prop.getMap().values().iterator();
    while(childIterator.hasNext()) {
     var child = childIterator.next();

     me(representation, child);
    }
   }

   if (isArray(parent)) {
    parent.push(representation);
   } else if (isHash(parent)) {
    parent[prop.name] = representation;
   }
  })(ret, prop);
 }
 (function(parent) {

 })(configuration);

 return ret;
}

/**
 * A simple function to create a new bundle version from a zip file containing
 * the bundle.
 * 
 * @param pathToBundleZipFile the path to the bundle on the local file system
 * 
 * @return an instance of BundleVersion class describing what's been created on 
 * the RHQ server.
 */
function createBundleVersion(pathToBundleZipFile) {
 var bytes = getFileBytes(pathToBundleZipFile)
 return BundleManager.createBundleVersionViaByteArray(bytes)
}

/**
 * This is a helper function that one can use to find out what base directories
 * given resource type defines.
 * <p>
 * These base directories then can be used when specifying bundle destinations.
 * 
 * @param resourceTypeId
 * @returns a java.util.Set of ResourceTypeBundleConfiguration objects
 */
function getAllBaseDirectories(resourceTypeId) {
 var crit = new ResourceTypeCriteria;
 crit.addFilterId(resourceTypeId);
 crit.fetchBundleConfiguration(true);
 
 var types = ResourceTypeManager.findResourceTypesByCriteria(crit);
 
 if (types.size() == 0) {
  throw "Could not find a resource type with id " + resourceTypeId;
 } else if (types.size() > 1) {
  throw "More than one resource type found with id " + resourceTypeId + "! How did that happen!";
 }
 
 var type = types.get(0);
 
 return type.getResourceTypeBundleConfiguration().getBundleDestinationBaseDirectories();
}

/**
 * Creates a new destination for given bundle. Once a destination exists,
 * actual bundle versions can be deployed to it.
 * <p>
 * Note that this only differs from the <code>BundleManager.createBundleDestination</code>
 * method in the fact that one can provide bundle and resource group names instead of their
 * ids.
 * 
 * @param destinationName the name of the destination to be created
 * @param description the description for the destination
 * @param bundleName the name of the bundle to create the destination for
 * @param groupName name of a group of resources that the destination will handle
 * @param baseDirName the name of the basedir definition that represents where inside the 
 *                    deployment of the individual resources the bundle will get deployed
 * @param deployDir the specific sub directory of the base dir where the bundles will get deployed
 * 
 * @return BundleDestination object
 */
function createBundleDestination(destinationName, description, bundleName, groupName, baseDirName, deployDir) {
 var groupCrit = new ResourceGroupCriteria;
 groupCrit.addFilterName(groupName);
 var groups = ResourceGroupManager.findResourceGroupsByCriteria(groupCrit);
 
 if (groups.empty) {
  throw "No group called '" + groupName + "' found.";
 }
 
 var group = groups.get(0);
 
 var bundleCrit = new BundleCriteria;
 bundleCrit.addFilterName(bundleName);
 var bundles = BundleManager.findBundlesByCriteria(bundleCrit);
 
 if (bundles.empty) {
  throw "No bundle called '" + bundleName + "' found.";
 }
 
 var bundle = bundles.get(0);
 
 return BundleManager.createBundleDestination(bundle.id, destinationName, description, baseDirName, deployDir, group.id);
}

/**
 * Tries to deploy given bundle version to provided destination using given configuration.
 * <p>
 * This method blocks while waiting for the deployment to complete or fail.
 * 
 * @param destination the bundle destination (or id thereof)
 * @param bundleVersion the bundle version to deploy (or id thereof)
 * @param deploymentConfiguration the deployment configuration. This can be an ordinary
 * javascript object (hash) or an instance of RHQ's Configuration. If it is the former,
 * it is converted to a Configuration instance using the <code>asConfiguration</code>
 * function from <code>util.js</code>. Please consult the documentation of that method
 * to understand the limitations of that approach.
 * @param description the deployment description
 * @param isCleanDeployment if true, perform a wipe of the deploy directory prior to the deployment; if false,
 * perform as an upgrade to the existing deployment, if any
 * 
 * @return the BundleDeployment instance describing the deployment
 */
function deployBundle(destination, bundleVersion, deploymentConfiguration, description, isCleanDeployment) {
 var destinationId = destination;
 if (typeof(destination) == 'object') {
  destinationId = destination.id;
 }
 
 var bundleVersionId = bundleVersion;
 if (typeof(bundleVersion) == 'object') {
  bundleVersionId = bundleVersion.id;
 }
 
 var deploymentConfig = deploymentConfiguration;
 if (!(deploymentConfiguration instanceof Configuration)) {
  deploymentConfig = asConfiguration(deploymentConfiguration);
 }
 
 var deployment = BundleManager.createBundleDeployment(bundleVersionId, destinationId, description, deploymentConfig);
 
 deployment = BundleManager.scheduleBundleDeployment(deployment.id, isCleanDeployment);
 
 var crit = new BundleDeploymentCriteria;
 crit.addFilterId(deployment.id);
 
 while (deployment.status == BundleDeploymentStatus.PENDING || deployment.status == BundleDeploymentStatus.IN_PROGRESS) {
  java.lang.Thread.currentThread().sleep(1000);
  var dps = BundleManager.findBundleDeploymentsByCriteria(crit);
  if (dps.empty) {
   throw "The deployment disappeared while we were waiting for it to complete.";
  }
  
  deployment = dps.get(0);
 }
 
 return deployment;
}


var destinationId = 10002;
var bundleVersionId = 10002;
var deploymentConfig = null;
var description = "redeploy due to drift";
// NOTE: It's essential that isCleanDeployment=true, otherwise files that have drifted will not be replaced with their
//       original versions from the bundle.
var isCleanDeployment = true;
deployBundle(10002, 10002, deploymentConfig, description, true);

15.10. 手動でドリフト検出の実行

定義に設定された間隔に応じて、ドリフト検出スキャンが定期的に実行されます。(デフォルトは 1800 秒または 30 分)。 ディレクトリーのファイルが変更されたことを認識し、直ちにスナップショットを作成する必要があるものの、間隔を永続的に変更したくない場合があります。検出スキャンを手動で実行するだけです。
  1. トップメニューの Inventory タブをクリックします。
  2. リソースを検索します。
  3. Drift タブをクリックします。
  4. スキャンを実行するためにドリフト定義を選択します。
  5. Detect Now ボタンをクリックします。

15.11. 計画的な変更の設定またはドリフト定義の無効化

ドリフト監視の背後にある仮定は、プラットフォームまたはアプリケーションに識別され、特定の設定があり、設定を保持する必要があることです。したがって、変更は望ましくないため、監視する必要があります。
ただし、計画的なメンテナンスやアップグレードの期間など、変更が想定される場合がある場合があります。このような状況では、ドリフトモニタリングを一時停止して、ドリフトアラートで不要な静的を作成しないようにする利点があります。
ドリフトの監視を一時停止する方法は 2 つあります。
  • 誤差処理モードを 計画変更 に設定します。これにより、ドリフト検出のスキャンおよび変更が記録されます。ただし、変更は想定されているため、ドリフト検出イベントはトリガーされないため、ドリフトアラートは発行されません。
  • 実際 にドリフト定義を無効に します。これにより、ドリフトイベントだけでなく、定義に対してドリフト検出が実行されます。
にあるように、誤差処理モードとドリフト定義の enable オプションは、definition エントリーで編集でき 「誤差定義の編集」 ます。

図15.5 ドリフト処理モードおよびオプションの有効化

ドリフト処理モードおよびオプションの有効化

15.12. 長期リンクスナップショットの保存方法の変更

ドリフトスナップショットは、限られた期間(31 日間)を JBoss ON データベースに保管します。これにより、承認されていない変更を修正するのに十分な時間を確保できますが、保存されるデータ量に対するリソース制限の一部を維持します。
時間の制限に達すると、未使用 のスナップショットが削除されます。未使用のスナップショットは、ピニングされていないスナップショットか、無効または削除されたドリフト定義(孤立)に関連付けられます。
ベースラインのスナップ(スナップショット 0)とピニングされたスナップショットは常に保存されます。
  1. Configuration メニューで System Settings 項目を選択します。
  2. Data Manager Configuration Properties セクションまでスクロールします。
  3. ドリフトスナップショットのストレージ時間を変更します。未使用のスナップショットは固定されておらず、孤立したスナップショットは無効化の定義に関連します。

15.13. ドリフトおよび JBoss ON エージェントおよびサーバーについて

15.13.1. drift Inventory

JBoss ON エージェントと JBoss ON サーバーの両方で、ドリフトが監視されるリソース、ディレクトリー、およびファイルの独自の履歴が維持されます。エージェントが起動すると、そのインベントリーがサーバーインベントリーと比較されます。
ドリフト情報は、agentRoot/rhq-agent/data/ ディレクトリーに他のエージェントデータとともに保存されます。このディレクトリーの情報は、エージェントが新規設定(--cleanconfig)で開始されたり、意図的にパージされた場合(--purgedata)を削除します。ドリフト情報が失われると、エージェントは JBoss ON サーバーから最後のスナップショットを要求します。
エージェントは常に最新の変更セットをスナップショットとしてサーバーに送信します。サーバーがある期間オフラインになり、更新が失われた場合、エージェントは最新のスナップショットを送信します。これにより、複数のドリフト検出を実行する際に変更が蓄積された場合でも、すべての変更を 1 つのスナップショットに効果的にロールバックします。

15.13.2. ドリフトサーバープラグイン

サーバープロセスは、サーバー側のプラグインを介して変更をドリフトします。このプラグインは、サーバーがエージェントから送信されるドリフトデータを認識し、処理するために有効にする必要があります。
他のサーバー側のプラグインと同様に、ドリフトプラグインを無効にすることができます。ただし、これにより、そのサーバーでのドリフト監視を完全に無効化し、ドリフト情報が処理または保存されません。これは、他のサーバーサブシステムの動作とは若干異なります。たとえば、個別のアラート送信者は無効にできますが、アラート検出は実行され、アラート情報は JBoss ON サーバーによって処理され、保存され、表示されます。
警告
ドリフトサーバー側のプラグインが無効になっている場合、サーバーは着信ドリフトレポートを無視します。誤差サーバー側のプラグインが再有効化されている場合でも、プラグインが無効になっている間に送信される情報は失われます。


[3] JBoss ON は、バイナリーファイルへの変更を検出します。バイナリーファイルの表示や、バイナリーファイルのバージョン間の変更または diff の変更は、テキストファイルのみを表示しません。

パート III. 監視

第16章 リソースアクティビティーの監視と応答

JBoss Operations Network のコア機能の 1 つは、管理者が JBoss サーバー、プラットフォーム、および IT 環境全体の状態を認識できる点です。
個々のサーバーおよびアプリケーションの現在の状態は、トラフィックと使用状況、設備の障害、サーバーのパフォーマンスに関する重要な情報を IT スタッフに提供します。JBoss Operations Network は、インベントリー内のリソースを自動的に 監視 することで、これらの重要なデータをより明確に把握できます。
管理の最も強力な側面は、リソースがどこにあるかを正確に把握し、常に変化する状況に反応させることです。

16.1. データの監視および種類

モニタリングにより、特定のマシン、アプリケーション、またはサービスが実行されている方法についての洞察が提供されます。JBoss ON は、管理リソースの異なるネイティブおよび外部ソースとは異なるタイプの情報を収集します。
JBoss Operations Network はリアルタイムモニターやデータポイントまたはプロファイラーのアーカイブではありません。JBoss ON の機能は、一時的、フィルター、およびプロセスによって生データの処理を行い、長期的な傾向、操作パラメーター、およびパフォーマンス履歴(監視の目的)がデータから明確かつアクセス可能になるようにします。JBoss ON は スケジュール を使用して、収集する情報と頻度(30 秒から時間)を定義します。これは、リソースのパフォーマンス情報を優先し、重要な情報の表示と一貫性を持たせます。
収集される正確な情報はリソースタイプによって異なりますが、監視データのカテゴリーはいくつかあります。各カテゴリーは、異なる場所から情報を取得し、リソースの動作が異なる部分を判断するのに役立ちます。
可用性または「スケールダウン」の監視
これは、basic と critical の両方です。可用性は、実行中または停止 状態であるかに関わらず、リソースのステータス 情報です。
数値メトリクス
メトリックは、リソースのコアのパフォーマンスデータです。ほとんどのソフトウェア製品は、チェックできる測定可能なファセットに関する情報を公開します。通常、この数値の情報は JBoss ON によって定義されたスケジュールで収集されます。
メトリック情報はサーバーによって処理されます。使用されるモニタリングデータの状態は 3 つあります。
  • Raw データ。エージェントがスケジュールどおりに収集され、サーバーに送信される読み取りです。
  • サーバーが処理したデータを 1 時間、6 時間、および 24 時間平均して集計 し、リソースのベースラインおよび通常の操作範囲を計算するために使用されます。これらの集計データはモニタリンググラフに表示される情報であり、メトリクスとして CLI で返されます。
  • メトリクスの現在の値に対するアドホック要求であるライブ 値。
    メトリック値は、リソース状態のローリングライブストリームです。基本的に、エージェントが事前定義のスケジュールの読み取りを実行するスナップショットになります。その後、これらのデータは、リソースのパフォーマンスを追跡するのに使用する手段および平均に集約されます。
    ライブ値は、即時、集計、メトリクス値の現在の読み取りです。
メトリクス情報は特に重要になります。これは収集され、長期保存されるためです。これにより、リソースパフォーマンスに関する履歴ビューや最近のビューが可能になります。
ログファイルメッセージ(イベント)
JBoss ON はログビューアーではありませんが、指定のログを監視し、ログメッセージ内の重大度または文字列に基づいて重要なログメッセージの有無を確認できます。これは イベント 監視で、JBoss ON はリソースのインシデントを識別し、アラート通知を送信し、必要に応じて通常のメトリクス外部の動的な情報に基づいて修正措置を取ることができます。
応答時間メトリクス
特定のタイプのリソース(Web サーバーまたはセッション Bean の URL)は、全体的なパフォーマンスのコンポーネントとして応答に依存します。応答時間または呼び出し時データは、URL またはセッション Bean がクライアントリクエストに応答する速度を追跡し、アプリケーション全体が実行しているかどうかを判断するのに役立ちます。
説明文字列(特性)
ほとんどのリソースには、インスタンス名、ビルド日、バージョン番号など、リソース自体を記述する比較的静的な情報があります。この情報は 特性です。リソースの他の属性と同様に、これを監視できます。特性は、バージョンの更新など、基礎となるアプリケーションへの変更を特定するのに役立ちます。

16.2. 条件の変更に対するアラートおよび応答

監視の重要な部分は、望ましくないイベントが発生したときに認識することです。アラートは JBoss ON 管理の他の機能(データと設定のドリフト検出の監視)で機能し、アラートをトリガーする 条件 を定義します。
アラート条件が満たされると、JBoss ON のアラートには 2 つの重要な機能があります。
  • アラートは、管理者が 定義したパラメーターに基づいて問題があったことを通知します。
  • アラートはインシデントに自動的に応答 します。管理者は操作を自動的に開始し、JBoss ON CLI スクリプトを実行して JBoss ON またはリソース設定の変更、コンテンツの再デプロイ、またはシェルスクリプトの実行が、アラート条件に対応して実行できます。
    管理者定義のアラートに対する自動応答により、管理者はインフラストラクチャーの問題に迅速に対応し、停止の影響を軽減することができます。
アラートは、メトリクス情報、コールタイムデータ、可用性、およびイベント、すべての通常のモニタリング要素に基づいています。アラートは、設定のドリフトを追跡するドリフト定義で定義される、リソースに対する重要な変更を基にすることもできます。リソースの設定を監視データと共に追跡することで、管理者は、予定外の、または望ましくないシステムの変更を簡単に、一貫して修正できます。

16.3. サーバーパフォーマンスに影響を及ぼす可能性のある影響

理論的には、収集できるメトリクスの数や発生する可能性のあるアラートの数に制限はありません。
実際には、IT 環境には、監視とアラート設定の両方を制限するという制約があります。
  • データベースのパフォーマンス(ほとんどの環境では主要な要素)
  • ネットワーク帯域幅
JBoss ON のアラートおよびモニタリング設定はリソースの数、メトリクス数、収集頻度、アラート数により異なるため、JBoss ON のアラートおよびモニタリング設定にはハード制限はありません。
経験上、パフォーマンスのしきい値は以下のとおりです。
  • 最大メトリクスを毎分収集できます。
  • 最大 9000 個のアラートを 1 日あたり最大 4000 に発生する(毎分約 70 個)
メトリクスの収集およびアラートの実装方法を計画します。メトリクススケジュールを有効にし、コレクションの頻度を設定する際に、リソースの優先順位を決定し、それらのリソースから必要な情報を設定します。次に、これらの優先順位に基づいて必要なアラートを計画します。
監視およびアラートのクリアストラテジーは、重要な情報を収集している最中にパフォーマンスを維持するのに役立ちます。
注記
収集したメトリクスの量を拡張するために、追加のストレージノードをストレージクラスターに追加できます。
ストレージノードは、JBoss ON の設計の一部として永続的に行うか、既存のノード上のアラート状態を使用して新規ノードのデプロイメントをトリガーして動的に作成できます。
追加ノードの作成については、を参照してください 「ストレージノードのデプロイおよび管理」

16.4. 異なるリソースタイプに基づくモニタリングとの相違点

利用可能なメトリクス、イベント、特性、およびその他の監視設定は、プラグイン記述子の各リソースタイプに対して定義されます。
完全に異なるタイプのソフトウェアは、異なる監視設定を持ちます。
ただし、モニタリング設定は、同じソフトウェアのリリース間で異なる場合があります。異なるメトリクスが利用可能であるか、または同じメトリクスに異なる設定名がある場合があります。たとえば、JBoss EAP 4 と 5 のメトリクスは、EAP サーバーの JVM、スレッド、およびトランザクションの監視に関連するメトリクスと同じです。JBoss EAP 6 では管理構造が異なるため、メトリクスは EAP 6 ドメインのサーバー間の管理リクエストに関連して異なります。
リソースリファレンス: Monitoring、Operation、および Configuration Options には、公式の JBoss ON エージェントプラグインで利用可能なメトリクスの完全なリファレンスがあります。本ガイドを参照して、リリースバージョン間の違いを確認します。

第17章 レポートおよびデータの監視

JBoss ON のモニタリング情報は簡単に検索できます。リソースとグループには、最新のメトリクス値のスナップショットビューと一連のグラフおよびテーブルのスナップショットビューが含まれるダッシュボードの両方があり、所定の時間枠で異なるメトリクス値が分散されます。
モニタリング情報は複数のエリアで利用できます。
  • 個別のリソース、互換性のあるグループ、メインダッシュボードのメトリクスポートレットを含むダッシュボード
  • 収集したすべてのデータ、イベント、設定、操作、およびその他の変更を集約するタイムライン
  • メトリクスのリソースレベルのチャートおよびテーブル
  • 範囲外のメトリクスまたは範囲外のメトリクスについてのメトリクスレポート

17.1. ダッシュボードとポートレット

監視およびアラート情報を表示する最も高速な場所は、JBoss ON のダッシュボードの 1 つです。ダッシュボードは、ほぼすべての監視、イベント、アラート、および操作データを単一の場所に収集します。
各データセットは、Dashboard に表示される個別のボックスまたは ポートレット で収集されます。これらのポートレットは、Dashboard から編集、追加、削除できます。これは 『管理者: Resource Inventory、Groups、および Users の初期セットアップ』 で説明されています。

17.1.1. resource-Level Dashboards

個別のリソース(または互換性のあるグループ)の Summary > Activity タブには、新規パッケージおよびコンテンツ、インベントリーの変更、イベント、操作、アラートなどのリソースに対する最近のアクションのスナップショットが表示されます。また、リソースのプライマリーメトリクスの最新の検出された値を表示するポートレットもあります。

図17.1 リソース概要タブ

リソース概要タブ
Resource: Measurements ポートレット内のメトリック名をクリックすると、メトリクスグラフが開きます。see more... リンクをクリックすると、メトリクスチャートが Monitoring タブに表示されます。

17.1.2. メインのダッシュボード

Dashboard メインページには、インベントリー内のすべてのリソースのグローバルビューがあります。デフォルトでは、このページにはアラートデータと利用できないリソースのみが表示されます。ただし、これは、モニタリングデータの異なるポートレットを表示するようにカスタマイズ Dashboard できます。また、メインページには複数のダッシュボードを含めることができるため、ダッシュボードを作成して、同じリソースの異なるメトリクス、異なるリソースの同じメトリクス、または関連リソースのグループに関連するメトリクスの組み合わせ(設計する場合)を確認できます。
メインダッシュボードには、特にデータを監視するためのいくつかのタイプのポートレットがあります。
  • プラットフォーム使用率: 空きメモリー、CPU 使用率、およびプラットフォームのパフォーマンスに関する他のメトリクスを表示します。
  • alerted または Unavailable Resources: アラートを発行した最新の 5 つのリソースの一覧を表示するか、または停止として報告されたリソースを表示します。
  • 日付/時刻、名前、および優先度でフィルタリングできる最新のアラートおよびイベント。
  • 互換性のあるグループの特定のメトリクス用のグラフ。
  • リソースの特定のメトリクス用のグラフ。

図17.2 MONItoring Data のあるダッシュボードの Portlets

MONItoring Data のあるダッシュボードの Portlets

17.1.3. メインダッシュボードへのモニタリングメトリクスの追加

リソースの特定のメトリクスのチャートを Dashboard に追加できます。これにより、アラートを設定したり、リソースエントリーをチェックすることなく、一般的なリソースまたは重大なリソースの重要な読み取りの現在の状態を即座に確認することが容易になります。

手順17.1 モニタリングメトリクスを Dashboard に追加する

  1. トップメニューの Inventory タブをクリックし、Resource に移動します。
  2. Monitoring タブで Metrics サブタブを選択します。
  3. 一覧からメトリクスを選択し、Add to Dashboard をクリックします。
特定のリソースの特定のメトリクスのチャートが、選択したダッシュボードに自動的に追加されます。

17.2. サマリータイムライン

タブの Timeline サブ Summary タブには、リソースのすべてのアクティビティーの費用チャートが表示されます(すべてのメトリクスコレクションは Monitoring タブおよびチャート下にあります)。は、すべての設定変更、インベントリーの変更、ドリフト、イベント、コンテンツおよびバンドルの変更、操作、およびアラートを Timeline 集約します。あるポイントをクリックすると、その特定のアクションの詳細が表示されます。

図17.3 サマリータイムライン

サマリータイムライン
すべての情報が 1 つのタイムラインにあるため、インシデントとイベントを関連付けることが容易になり、そのリソースに関する全体的なアクティビティーをよりよく理解できるようになります。

17.3. リソースレベルのメトリクスチャート

リソースの Monitoring タブ(または互換性のあるグループの場合)には一連の異なるサブタブがあり、それぞれ異なるタイプの監視データにマークされます。各データグループには、独自のモニタリングチャートがあります。
Metrics サブタブは、最初にテーブルを表示し、メトリックのベースライン期間の最大、最小、および平均値、メトリックの最新の読み取り、およびトレンドラインを設定します。任意のメトリクスを拡張すると、同じ情報で視覚的に表示されるグラフが表示されます。

図17.4 メトリクスチャート

メトリクスチャート
任意のデータポイントにマウスオーバーすると、その集計されたポイントの値が表示されます(これはグラフのサイズを表す期間に対応します。1 分の 1/60)。グラフの合計期間は 1/60 です。たとえば、60 時間グラフの場合はデータポイントは 1 時間です。

図17.5 データポイントへのマウスオーバー

データポイントへのマウスオーバー
Metrics タブの上部にボタンが表示され、表示されるデータの日付範囲を変更します。さらに、グラフの一部をドラッグし、空き選択範囲に基づいて新しいグラフを生成することもできます。

図17.6 グラフのサブセットの選択

グラフのサブセットの選択

17.4. Depend Metrics Report

で説明されているように 「baselines and Out-of-Bounds Metrics」、メトリクスが数回収集されると、JBoss ON はその特定リソースの通常の操作範囲と、その特定のメトリクスの計算を開始します。これにより、最小値と最大値に基づいて範囲が作成されます。
メトリクスデータポイントが、その中にある通常の範囲上または下限にある場合、これは 疑わしいメトリクス です。メトリクスコレクションの障害があるか、またはリソースの問題を示す可能性があります。
各リソースにはタブにポートレットがあり、その Summary タブには、疑わしい、または範囲外のメトリクスが一覧表示されます。

図17.7 範囲外ポートレット

範囲外ポートレット
疑わしいメトリクスを持つすべてのリソースがレポートにリストされます。Suspect Metrics レポートには、メトリクス、通常の範囲、疑わしい読み取り、およびメトリックの外部からのどの程度が通常の読み取りから送られるかの要因またはパーセンテージが表示されます。

図17.8 Depend Metrics Report

Depend Metrics Report
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ suspectMetrics.csvます。

17.5. プラットフォーム使用状況レポート

一般的なインフラストラクチャーの監視では、プライマリーリソースがプラットフォームです。Platform Utilization レポートには、現在のシステムパフォーマンスを 3 つのメトリクスで示して、インベントリー内のすべてのプラットフォームの健全性についての非常に迅速なスナップショットが表示されます。
  • 現在の CPU パーセンテージ
  • 利用可能な物理メモリー、バッファー、およびキャッシュに基づく実際のメモリー使用量。
  • swap

図17.9 プラットフォーム使用状況レポート

プラットフォーム使用状況レポート
注記
このレポートは、メイン Dashboard またはリソースレベルの Summary ダッシュボードにポートレットとして追加することもできます。
注意事項がいくつかあります。利用可能な プラットフォームのみが一覧表示されます。available 状態の他のプラットフォームは一覧表示されません。また、使用率は最新のライブデータに基づいており、平均や履歴値ではありません。これにより、プラットフォームリソースを確認することができます。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ platformUtilization.csvます。

第18章 可用性

監視で最も基本的な要素の 1 つは、サーバーまたはアプリケーションが実行されているかどうかを把握することです。可用性 監視は、特定のプロセスが実行中で最小限の応答状態にあることを管理者に指示します。

18.1. コア "Up and down" の監視

監視に関する最初の質問は、リソースが稼働していることですか?リソースの可用性は、全体的なパフォーマンスの確認、サービスレベルの特定、およびインフラストラクチャーの維持にあたり、リソースの可用性です。
可用性(「 up または down monitoring」と呼ばれることもあります)は、リソースが 稼働 しているか、または他の状態にあるかを決定します。
up は、リソースが実行中であり、規定された時間内にエージェントに応答することを意味します。
可用性はリソースによって異なります。プロセス ID または JVM をチェックする可能性があります。リソースタイプの可用性は、プラグイン記述子で定義されます。そのため、プラグインコンテナーはリソースとエージェント間の仲介になります。エージェントは、プラグインコンテナーでリソースの可用性をチェックします。コンテナーはリソースコンポーネントから取得します。
通常、可用性チェックには数秒かかります。特定のリソースや特定の環境では、時間がかかる場合があります。可用性スキャンのタイムアウト期間が、デフォルトで 5 秒に設定されています。リソースが実行中で、その 5 秒間以内に可用性スキャンに応答すると、リソースが稼働していることになります。
可用性(「スケールダウン」または「スケールダウン」)- IT 管理者にとって監視が非常に重要であるため、JBoss ON における可用性の状態は非常に大きく表示されます。可用性は、リソースの詳細ページ、すべてのリソース一覧、グループ、およびモニタリングレポートに表示されます。これは、リソースが稼働しているかどうかを判断するには glance のみを取る必要があります。

図18.1 リソースの可用性

リソースの可用性
可用性は実際の監視メトリックではありませんが、Monitoring > Metrics ページには、リソースが稼働状態にある表示期間内の時間の割合が示されます。これは、エージェントが収集したその他すべてのメトリクスに影響を与えるため、可用性(および同時稼働時間)が影響を受けるためです。

図18.2 可用性のアップタイムパーセント

可用性のアップタイムパーセント
注記
多くの場合、リソースが実行中でも可用性がダウンしている場合は、接続設定に問題があることになります。エージェントには、ユーザー名や新しいポート番号など、リソースへの接続に必要な情報がない場合があります。エージェントはリソースに接続できないため、停止していることを前提としています。

18.1.1. 長いスキャン時間と非同期アベイラビリティーコレクション

可用性スキャンは、定義されたリソースタイプに対してリソースプラグイン自体によって実行され、プラグインコンテナーに報告されます。
通常、可用性チェックは 1 秒で非常に高速ですが、可用性チェックにかかる時間が長くなる可能性があります。プラグインコンテナーは、不正なプラグインがエージェントによって管理されるその他すべてのリソースの可用性レポートを遅延しないようにするために、可用性チェックを 5 秒に制限します。
特定のプラグインまたはリソースタイプが 5 秒のタイムアウト期間よりも長いスキャンを行うインスタンスが存在する可能性があります。
カスタムプラグインの場合、プラグイン作成者は 非同期の可用性チェックを設定できます。基本的に、非同期の可用性チェックでは、リソースコンポーネントは独自の独立したスレッドを作成し、可用性チェックを実行します。そのスレッド内では、可用性チェックは、完了する必要がある限り時間がかかります。可用性チェックは、デフォルトで 1 分ごとに非常に頻繁に実行され、完全なチェックの完了までにかかる場合でも可用性の状態が現在の状態であることを確認することもできます。
コンポーネントによってキャッシュされ、最新の可用性の結果がプラグインコンテナーに報告されます。保存される最後の可用性は、プラグインコンテナーが想定する秒数で非常に迅速に提供されます。
Async 可用性チェックは、以下により実装されます。 AvailabilityCollectorRunnable JBoss ON プラグイン API のクラス。このクラスの詳細は、『 Plug-in API』および『Writing Custom Plug-ins Guide』を参照してください。
注記
また、エージェント設定自体のスキャンタイムアウト期間を拡張することで、長時間の可用性チェックに対処することもできます。たとえば、新しいタイムアウト期間を rhq-agent-env.sh ファイルの ADDITIONAL_JAVA_OPTIONS パラメーターに追加します。
RHQ_AGENT_ADDITIONAL_JAVA_OPTS="$RHQ_AGENT_ADDITIONAL_JAVA_OPTS -Drhq.agent.plugins.availability-scan.timeout=15000"
ただし、このタイムアウト期間は、特定の特定の、低速なプラグインの 1 つのプラグインだけでなく、プラグイン 全体 に適用されます。低速な可用性チェックを実行している複数のプラグインがある場合、可用性レポートが完了するのに時間がかかりすぎる可能性があるため、エージェントが遅延したり、JBoss ON サーバーへ利用可能なレポートを送信できない状態になったりすることがありました。
通常、すべてのプラグインのスキャン間隔をリセットするのではなく、カスタムプラグインで非同期の可用性を設定することが推奨されます。

18.1.2. 同期の可用性

可用性スキャンは、デフォルトで、定義されたスケジュールで、1 分から 20 分間隔で実行されます。つまり、ほとんどの可用性データは非同期です。これは可用性のタイムライン、レポート、およびほとんどの UI で(最新の(現時点では限りない)値に基づいて)表示されます。
リソースの Monitoring タブを表示することで、同期、ほぼリアルタイムの可用性の情報を取得できます。Monitoring タブが開いている限り、可用性の読み取りは設定されたコレクションスケジュールではなく、15 秒ごとにチェックされます。これは、リアルタイムの可用性の情報にできるだけ近いものです。
注記
可用性を収集するためにこのスケジュールが変更されると、リソースのアラートに対するルールが低下する可能性があります。
たとえば、特定の状態が 3 つ(3)発生後にアラートを発生させるために、可用性を 10 分ごとにチェックする場合、アラートの意図は条件が持続する期間が 30 時間 後にのみ実行される場合でも、特定の状態が読み込まれる場合でも、アラートは 1 分未満のアラートを発生させる可能性があります。

18.1.3. 可用性の状態

up と not up の間にはグレーエリアがあります。リソースが起動しない場合がありますが、異なる理由で起動していない可能性があります。たとえば、エージェントを再起動すると、リソースの状態が認識されない可能性があります。または、メンテナンスのためにリソースがオフラインになっている可能性があるため、可用性レポートが送信されません。
異なるリソースの状態がに記載されてい 表18.1「可用性の状態」 ます。

表18.1 可用性の状態

状態 description icon
利用可能な(UP) リソースが実行され、可用性ステータスチェックに応答します。
down リソースは可用性チェックに応答しません。
Unknown エージェントには、リソースの状態を記録しません。これは、リソースがインベントリーに新たに追加され、最初の可用性チェックがないか、またはエージェントがダウンしているためです。
disabled リソースは、管理者が利用できないとマークされています。リソース(実際には)が実行中または停止している可能性があります。リソースを無効にすると、サーバーがエージェントからの可用性レポートを無視して、(既知の)停止状態または循環状態に基づいて不必要なアラートが発生しないようにします。
混在(グループのみ) [a]
グループのリソースには、可用性の状態が異なります。
[a] リソースの詳細ページの上部で、リソースの可用性の横に同様の警告マークが表示されます。この警告は、リソースに対してエラーメッセージや疑わしいメトリクスが返されたことを示しています。リソースの可用性が警告状態にあるわけではありません。

18.1.4. 親およびバックフィル

可用性は、リソースのツリーの上部から下向きに評価されます。たとえば、アプリケーションサーバーがダウンしている場合は、すべての依存 webapp 子もダウンしていると仮定できます。
これはバックフィルと呼ば ます。親の状態は、各子に対して追加の可用性スキャンを実行せずに、子に伝播されます。Backfilling は、子の状態を down、unknown、または disabled の状態に設定することができます。
場合によっては、バックフィルには up 状態も含まれます。一部の依存子リソース(親が実行中の場合のみ実行される優先順位の低いサービス)には、デフォルトで個別に評価される独自の可用性もない場合があります。子の可用性チェックが無効になっている場合、子は前もって親の状態を使用します。親が稼働している場合は、これらの子を起動することが想定されます。
バックフィルにはわずかな違いがあります。プラットフォームがダウンとマークされている場合は、プラットフォームがダウンしている場合は、エージェントがダウンしているのと同じです。つまり、エージェントがサーバーに報告されていないことを意味します。そのため、実際にオフライン状態のサーバーやサービス以外に、複数の理由が考えられます。この場合、プラットフォーム(機能的にエージェント)がダウンするように設定されますが、子には unknown に設定されます。

18.1.5. コレクション間隔とエージェントのスキャン間隔

が示すように、可用性の読み取りはメトリクスコレクションと同じではありません。不適切な類似点がいくつかあり、主にスケジュールに収集され、それら両方がリソースパフォーマンスに関連していることが挙げられます。
内部的には、可用性とメトリクスの処理が異なります。可用性は、異なる機能により呼び出され、個別に報告されます。また、より重要な可用性レポートは、監視レポートを含む、エージェントが送信した他のレポートよりも優先順位が高くなります。
可用性レポートは最初の優先度メッセージとして送信されますが、リソース自体には可用性スキャンの異なる優先度があります。優先度が高い(より重要)リソースはデフォルトで、可用性がより頻繁にチェックされます。
  • エージェントのハートビート ping(プラットフォームの可用性に分析)は、1 分ごとにサーバーに送信されます。
  • サーバーの可用性は毎分チェックされます。
  • サービスの可用性は 10 分ごとにチェックされます。
エージェント自体は、可用性スキャンを 30 秒間隔で実行します。すべてのリソースがスキャンごとにチェックされるわけではありません。エージェントスキャンが実行されると、確認するようにスケジュールされたリソースのみがチェックされます。そのため、機能的に 2 つの可用性スケジュールが連携し、エージェントスキャンの間隔とリソース収集スケジュールが連携します。たとえば、サーバーの可用性チェック用に 60 秒間隔で設定され、エージェントスキャンの期間が 30 秒である場合、サーバーは 2 つのスキャンごとに確認することができます。つまり、サーバーは 60 秒間チェックされますが、これはベストエフォートの予測です。エージェントが負荷が大きい場合、またはリソースが多数ある場合、エージェントは 30 秒よりも長いスキャンを実行する可能性があるため、特定のリソースがチェックされるまでの 間隔 が長くなります。
管理リソースの 1 つに可用性状態が変更された場合に限り、エージェントは可用性レポートをサーバーに送信します。
エージェントが停止すると、(デフォルト)エージェントの quiet の期間が 5 分以内にダウン状態が表示されます。エージェントが正常にシャットダウンすると、JBoss ON サーバーは約 1 分以内に状態変化を認識します。サーバーがエージェントがダウンすると、そのエージェントのインベントリー(「親およびバックフィル」)内のすべてのリソースの状態をバックフィルします。
ダウンサーバーは、通常、ダウンから 1 分から 2 分後にダウン状態を記録します。これは必ずしもリアルタイムではありませんが、ほとんどのインフラストラクチャーでは、信頼できるパフォーマンスのベースラインを確立でき、サービスレベルとアップタイムも計算できます。90 秒という期間が短いと、ほとんどのリソースのサイクをキャッチできます。
デフォルトのエージェントスキャン間隔は 30 秒ですが、リソースのスケジュールによっては、一部のサービスがダウンすると 10 分以上かかる可能性があります。管理者が状態が変更されたと疑われる場合は、インタラクティブエージェントプロンプトを介してエージェントのすべてのリソースに対して即時可用性スキャンを強制することが可能です。
> avail -- force
avail コマンドを使用して、すべてのリソースではなく、次回のスケジュールされたリソースのチェックを実行します。
さらに、リソースプラグインを作成して、状態の変更を引き起こす可能性のある操作(start、stop、restart 操作など)が操作の終了時にリソースの可用性チェックを自動的に要求するように設定できます。

18.2. リソースの可用性チャートの表示

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
  3. リスト内のリソースの名前をクリックします。
  4. リソースの Monitoring タブを開きます。
リソースの Availability チャートには、リソースの状態が変わるタイミングおよび期間が表示されます。これには、可用性が変更され、リソースが up および down の状態に費やされた時間の合計数に関するタイムスタンプが含まれます。

図18.3 可用性チャート

可用性チャート

18.3. 詳細なディスカッション: 可用性の期間とパフォーマンス

監視メカニズムとしての可用性には、2 つの重要なファセットがあります。変更時の影響と、可用性の変更がリソースパフォーマンスを反映している状況の観点です。
履歴的な観点では、可用性の期間 が紹介されます。特定の状態のリソース期間。どの頻度が変更するか?

図18.4 可用性数

可用性数
リソースの実行方法を正確に把握するには、可用性期間の概念が重要です。この情報を JBoss ON が破損する方法は複数あります。
  • up、down、および disabled 状態の合計時間
  • 稼働時間、ダウン状態、および無効な状態の時間の割合
  • リソースがダウン状態または無効状態にある回数
  • 障害(MTBF)と平均リカバリー時間(MTTR)の平均時間。
注記
未知の状態は、リソースの全体的な可用性履歴の計算には含まれません。
最後の要素は、可用性を考慮してリソースのパフォーマンスを評価する上で特に重要になります。障害間の平均期間 は、リソースが起動し、次に停止するまでの時間です。これは、平均です。 [4] すべてのアップ期間。これにより、システムがどの程度安定しているかがわかります。リカバリーの平均時間は、耐障害性または耐障害性を示すリソースがどの程度停止する かを把握します。MTBF および高 MTTR の低い場合は、メンテナンスの問題や、リソースに対するアプリケーションの不安定性を示します。

図18.5 アップアンドダウンの監視

アップアンドダウンの監視
監視パースペクティブでは、特に機器の置き換えやアップグレードの計画時に、履歴の観点が重要です。
即時応答の観点から、アラートの観点から、可用性の変更のみを行います。
first および最も明確なアラート状態は、状態の変更のみに基づいてアラートを発行します。
ただし、リソースは、リソースの全体的なパフォーマンスや、実行している機能に影響を及ぼすことはありませんが、リソースにアクセスできない数秒または数分かかる場合があります。リソースは特定の状態に達し、状態が重要になる前に一定期間そこに留まる必要があります。

図18.6 可用性の期間アラート

可用性の期間アラート
注記
可用性アラートは、リソースが down 状態に切り替わった際に発生する可用性アラートなどの状態が変更し続け、その後も引き続き利用できるため、可用性アラート自体は輻輳状態になります。リソースが循環している場合は、そのリソースで数回停止して稼働し、毎回新しいアラートをトリガーする場合がありますが、リソースで同じパフォーマンスの問題に関連する可能性があります。
輻輳の代わりに、アラートで無効を設定すると、で説明されているように管理者が承認するまでアラートの定義が 1 度実行され、そのアラート定義が無効になり 「詳細なディスカッション: アラートの自動無効化およびリカバリー」 ます。(この場合、対応するリカバリー設定を設定しないでください。リソースがサイクリングの場合は、すべての UP 読み込みによってアラートがリセットされ、次の DOWN レポートが別の通知を発生させます。基本的に、警告が承認されるまで無効にする不利な影響が取り消されます。)


[4] これは、統計的意味で意味を持ちます。収集したすべてのアップタイムの長さの中間データポイントです。

18.4. 詳細なディスカッション: "Not Up" Alert Conditions

リソースには、以下の 4 つの可用性状態があります。
  • Up
  • down
  • Unknown
  • disabled
以下で説明されてい 「可用性の状態」 ます。
リソースのコア監視要素の 1 つがその可用性を把握しているため、どの可用性状態の変更でもアラートを定義できます。
通常、条件は任意の明示的な状態でアラートを送信するように設定できます。たとえば、可用性の状態 が DOWN に変更した場合に限り、ダウン 状態が警告されます。その他の状態の変更は無視されます。

図18.7 可用性変更条件

可用性変更条件
ただし、重要なプラットフォームやリソースについては、UP 以外の可用性が 変更 されても、アラートのトリガーが必要になる場合があります。DISABLED のような既知の状態が変わります。
稼働しない条件は、UP 以外の可用性状態に変更がある場合にアラートをトリガーします。したがって、DOWN、UNKNOWN、および DISABLED 条件の論理 OR の組み合わせになります。
注記
可用性の変更条件は、復旧アラート の使用に適しています。リソースがダウンした場合(または稼動しない)アラートが発生すると、管理者に通知し、リソースが再び利用できるときに通知するコンパニオンアラートを有効に(またはリカバリー)できます。

18.5. グループの可用性の表示

グループの可用性を表示するには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Groups メニューで、互換性のあるグループまたは混合グループアイテムを選択します。
  3. グループの名前をクリックします。
  4. グループの Inventory タブをクリックします。
グループの可用性は、メンバーリソースの状態が複雑です。すべてのリソースが 1 つの状態または別の状態にある場合、グループ全体はその状態になります。リソースの状態が異なる場合、グループの状態はリソース状態の組み合わせに基づいて決定されます。

図18.8 グループの可用性

グループの可用性
注記
可用性の状態は「ダウン」で評価されます。 リソースがダウンした場合(無効)、または不明な場合は、その状態にある子も即座に想定されます。

表18.2 グループアベイラビリティーの状態

リソースの状態が ... である場合は、. ... Group State Is ...
空のグループ(不明) empty
すべての Red(Down) 赤い(Down)
Down または Unknown yellow(Mixed)
一部の Orange(Disabled) アジア(Disabled)
All green(Up) 緑色の(Up)

18.6. メンテナンス用のリソースの無効化

リソースを無効にすると、基本的に JBoss ON サーバーのビューからリソースが無効になります。リソースがオフラインになる理由が多数ある可能性があります。マシンを新しいコロケーション機能に移動するか、プラットフォームをアップグレードするか、またはハードウェアの変更が生じる可能性があります。IT 管理者は、リソースが利用できないことを認識すると、可用性チェックがないため、不必要な報告がトリガーされる可能性があります。リソースを 無効 にすることはできます。
リソースを無効にする際に、以下の 2 つの点を記憶する必要があります。
  • エージェントが稼働している場合は、リソースの可用性が報告されます。JBoss ON サーバーによってのみ無視され、可用性の計算には含まれません。
  • 親リソースを無効にすると、その親リソースも自動的に無効になります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
  3. 一覧でリソースを選択します。
  4. ページ下部の Disable ボタンをクリックします。
  5. プロンプトが表示されたら、リソースを無効にする必要があることを確認します。
無効なリソースには、その状態を示すアイコンがあります。

図18.9 無効なリソース

無効なリソース
注記
リソースが再度有効にすると、次回のスケジュールされた可用性スキャンまで、未知の状態になります。

18.7. リソースの自動無効化および有効化プラグインの許可

子または依存しているリソースによっては、常に disabled 状態を使用し、リソースが非アクティブであることを示す場合があります。たとえば、JBoss EAP 6 ドメインの管理対象サーバーや mod_cluster 下の Web コンテキストは非アクティブであるためオフラインである可能性があり、これは明示的にダウンするとは別の方法で処理する必要があります。この場合、親リソースは依存する子を自動的に起動または停止できます。
リソースプラグイン自体は、を使用して依存するリソースを自動的に無効にし、有効にできます。 AvailabilityContext.disable() および AvailabilityContext.enable() メソッドは、コンポーネント JAR ファイルの可用性定義の一部として使用します。
重要
リソースプラグインによるリソースの自動有効または無効化を許可する場合は注意してください。これにより、管理者が設定した状態をプラグインが上書きできる可能性があります。
リソースプラグインの 『作成に関する詳細は、「開発: カスタムプラグインの作成」を参照してください』。

18.8. アベイラビリティーチェック間隔の変更

可用性チェックは厳密にはメトリクスではありませんが、他のメトリクスコレクションスケジュールで編集できるコレクションスケジュールがあります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
  3. リソースエントリーの Monitoring タブをクリックします。
  4. Schedules サブタブをクリックします。
  5. Availability メトリクスを選択し、必要なコレクション期間を適切な時間単位(秒 Collection Interval、分、または時間)で入力します。
    注記
    可用性スケジュールは、互換性のあるグループまたはリソースタイプのテンプレートに設定できます。グループまたはリソース種別レベルで設定すると、複数のリソースが同時に変更されます。
  6. をクリックし Setます。

18.9. エージェントの可用性スキャン期間の変更

サーバーでの可用性が処理されるため、エージェントが多数あり、数千にもなるほど、サーバーとパフォーマンスが低下する可能性があります。この場合、デフォルトのスキャン間隔が短すぎる可能性があり、スキャン間隔が長いと JBoss ON サーバーのパフォーマンスが向上する可能性があります。
注記
JBoss ON パフォーマンスに影響するコアエージェントまたはサーバー設定を変更する場合は、Red Hat サポートサービスまでご連絡ください。
  1. エージェントの設定ファイルを開きます。
    vim agentRoot/rhq-agent/conf/agent-configuration.xml
  2. XML ファイルの行をコメント解除し、新しいスキャン時間(秒単位)を設定します。
    <entry key="rhq.agent.plugins.availability-scan.period-secs" value="60"/>
  3. 端末のフォアグラウンドでエージェントを再起動します。この --cleanconfig オプションを使用して、エージェントが設定ファイルから新しい設定を読み取るように強制します。
    agentRoot/rhq-agent/bin/rhq-agent.sh --cleanconfig

第19章 メトリックおよび測定値

すべてのオペレーティングシステム、アプリケーション、およびサーバーには、パフォーマンスを測定するためのメカニズムがあります。データベースにはページのヒットやミスがあります。サーバーはオープン接続数を持ち、プラットフォームはメモリーと CPU 使用率を持ちます。これらのパフォーマンス測定は、JBoss Operations Network によって メトリクス として監視できます。

19.1. リソースに関する直接情報

メトリックは、リソースのパフォーマンスや負荷を測定する方法です。主な用語は測定です。メトリクスとは、ソフトウェアが公開するデータポイントで、そのソフトウェアの運用や目的に関連するもので、そのソフトウェアの量的な動作についての洞察を提供します。

図19.1 メトリクスグラフ

メトリクスグラフ
リソースのタイプごとに、リソースタイプに関連する独自のメトリクスセットがあります。メトリクスは、そのリソースタイプのプラグイン記述子で定義されます。プラグイン記述子は、そのリソースに対して許可される測定タイプを一覧表示します。これは、リソースに対して実際に収集されるメトリクスと同じとは限りません。メトリクス自体を(リソースごとまたはメトリクステンプレートごとに)有効にし、スケジュールどおりに収集する必要があります。

19.1.1. Raw Metrics、Displayed Metrics、および Storing Data

メトリック情報の最新(および未処理)の読み取りは 生データ です。この raw データはバックエンドサーバーに保存されますが、Web UI に表示される情報ではありません。
Web UI に表示される情報は 集計されたデータ です。つまり、JBoss ON に表示され、モニタリングチャートに使用されるメトリクスは、生のデータポイントではなく、計算された値です。ジョブは 1 時間ごとに実行され、メトリクスの値を 1 時間に圧縮します。これらの集計には、集計期間の測定されたデータの最小、最大値、および平均値が含まれます。アグリゲートは、6 時間と 24 時間のウィンドウでも作成されます。
これらのアグリゲートは、グラフの範囲と表示領域のサイズに応じて、UI に表示されるデータの計算に使用されます。Web UI にはディスプレイ領域が制限されており、60 x ✓ セグメントに分割されます。JBoss ON サーバーは、生データを平均して、表示時間に関するデータポイントを作成します。たとえば、表示範囲が 60 時間の場合、各 x 方向セグメントは 1 時間、その 1 時間セグメントで収集されるすべての読み取りの平均になります。この集計は、チャートビューに指定された監視ウィンドウに応じて動的になります。
前述のように、ベースライン計算自体は生データの集計 「baselines and Out-of-Bounds Metrics」 で、1 時間、6 時間、および 24 時間表示のウィンドウを使用して、最小、最大、および平均のベースラインを設定します。UI が集約するとは異なり、これらの集計データが計算され、サーバーデータベースに監視データとして保存されます。
raw データはデフォルトで 1 週間のみ保存されますが、集約された値は最大 1 年間保存されます。データストレージ時間は設定可能です。

19.1.2. 現在の値

上記の 「Raw Metrics、Displayed Metrics、および Storing Data」 ように、JBoss ON に表示される情報のほとんどは集計されます。これは、監視期間に収集される複数のデータポイントの累積的な結果であり、指定のチャート内で処理および表示されます。
JBoss ON はリアルタイムモニターではありませんが、継続的にデータを収集します。最後に収集された値はリソースの Monitoring タブに表示されます。指定のメトリクスの最後の raw 値が表示されます。

図19.2 ライブ値の列

ライブ値の列
Monitoring タブが開いている限り、メトリクスが収集され、設定されたコレクションスケジュールではなく、Web UI の更新設定と共にライブ値(およびその他の平均データ)が更新されます。(可用性は、リフレッシュスケジュールよりもさらに頻繁にチェックされ、15 秒ごとにチェックされます。) つまり、リソースのメトリクスを表示すると、最新の情報が常に収集および表示され、その情報は毎分すぐに更新されます。
注記
メトリクスを収集するためにこのスケジュールが変更されると、リソースのアラートに対するルールが強化された可能性があります。
たとえば、特定の状態が 3 つ(3)発生後にアラートを発生させるために、メトリクスが 10 分ごとに収集されるようにスケジュールされ、UI の更新間隔が 1 分で、特定の条件が読み取られる場合でも、アラートは 3 分後に実行されます。アラートの意図は、状態が 持続 するだけでのみ発生する場合でも、3 分後にアラートを出力できます。

19.1.3. メトリクスのカウント: 動的な値と値

分かりやすいかもしれませんが、メトリクスデータを理解するには、データがどのようにカウントされるかを理解することが含まれます。カウントされる値には、以下の 2 つのタイプがあります。
  • 動的値 は、現在の状態であり、一時的な変更可能な値を示しています。これには、アプリケーションサーバーへの接続の現在の数や、プラットフォーム上の CPU 使用率などが含まれます。
  • 傾向値 は、リソースが開始した時点の合計、またはその有効期間を超えた合計数です。これらの値は 1 つの方向でのみ続行されます(通常は、常に高い値になるわけではありません)。
たとえば、エージェントの measurement サブシステムには、収集されるメトリクスと 毎分 のメトリクスの 2 つの同様のメトリクスがあります。後者は動的メトリクスです。つまり、最後の 1 分で実際に収集されたメトリクスの数に応じて、その値がアップおよび減少します。収集されたメトリック(最初のメトリクス)は累積的です。開始してから、エージェントが収集したメトリクスの合計数です。そのため、同じデータをカウントしても、2 つのメトリクスの値が非常に異なります。
前述のように 図19.3「メトリックの動的な値および値」、トレンドデータの平均を計算することは可能ですが、その値は意味がありません。同様に、トレンド値の「最小」は選択した期間の開始値であり、「最大」は選択した期間の最後の値になります。他の自動計算(out-of-bound values やベースラインなど)は、トレンドデータとは無意味ですが、動的データで重要になります。

19.1.4. baselines and Out-of-Bounds Metrics

メトリクスが確実に収集されると、JBoss ON はメトリクスの ベース ラインを自動的に算出します。ベースラインは、そのリソースのメトリックに対する通常の操作範囲です。ベースラインは、デフォルトで集約されたデータを使用して、3 日ごとに収集されます。ベースラインは、データのローリングウインドウを使用します。
ベースラインメトリックは、実際のデータの変更をベースライン値と比較します。ベースラインは、効果的な傾向分析、SLA 管理、およびアプリケーションの健全性評価を障害管理の形式として活用できます。
ベースラインにより、JBoss ON は高基準値と低いベースラインの外部(範囲外)で収集されるメトリクス値を識別できます。範囲外のメトリクスは 問題メトリクス として報告されます。
注記
メトリクスの値に応答してアラートがトリガーされると、アラートイベントは問題メトリクスとして追跡されます。
ベースラインがない場合は、計算されていないか、またはメトリクスがトレンドメトリクス(累積値)であるため、範囲外の要素は計算されません。
ベースラインには、最小値と最大値の違いがある 帯域幅 があります。違い は、問題メトリックがベースライン外にある絶対量です。範囲外の値を比較できるようにするには、範囲外の要素 を帯域幅で分割することで計算されます。これにより、通常の操作の範囲が、問題メトリクスがどの程度まであるかを比較して示するための比率が作成されます。
Suspect Metrics レポートでは、ベースラインは 最小、最大 数として報告され、範囲外のメトリクスは外部として一覧表示され ます。ベースラインとエビリアーの違いは、パーセンテージとして示されます。これは、基準値で除算され、直近のベースラインに対する差です。

図19.4 Depend Metrics Report

Depend Metrics Report
注記
ベースラインの計算では、1,2)の帯域として意図しない結果を出力できます。3 の外部値は、帯域(100, 200 MB)よりも少なく、250 MB を超える値であると考えられます。前者では実際には 100% 予想される帯域幅ですが、後者は 50% のみになります。

図19.5 アウトオブバウンドファクトリー

アウトオブバウンドファクトリー
範囲外の要素は、計算ジョブの期間中に 1 時間ごとに再計算されます。ジョブはアグリゲートを評価し、以前よりも深刻な状況が発生するかどうかを判断します。チャートには、常に最も深刻な範囲が表示されます。
メトリックのベースラインが変更されると、記録されたすべての範囲外の値が無効になり、古いベースラインに対して範囲外の測定が計算されるためです。

19.1.5. コレクションのスケジュール

メトリクスコレクションスケジュールは、リソースタイプのプラグイン記述子内の各メトリクスに対して個別に定義されます。
メトリクスの頻度についてのルールはありません。ほとんどのメトリクスでは、デフォルトの間隔は 10 分から 40 分の範囲です。一般的にはメトリクス(プラットフォームでの空きメモリーや CPU 使用率など)がありますが、多くのメトリクスの重要性は、IT および実稼働環境の一般的な環境とリソース自体によって異なります。妥当な間隔を設定して、リソースの実際のパフォーマンスを適切に反映する頻度で重要なメトリクスを収集します。
設定可能な最も短い間隔は 30 秒ですが、報告されたメトリックのボリュームがデータベースのパフォーマンスに影響を与える可能性があるため、短時間間隔を慎重に使用すべきです。

19.1.6. メトリクススケジュールおよびリソースタイプテンプレート

リソースに固有のその他のタイプのモニタリングデータ(可用性、イベント、特性)とは異なり、メトリクスは、そのタイプのすべてのリソースに対して汎用的なものになります。
メトリクスコレクションスケジュールは、リソースに許可されるメトリクスが実際に有効かどうか、コレクションの間隔を定義します。スケジュールはリソースレベルで設定されますが、メトリクスコレクションテンプレートを使用して、管理者が定義したデフォルト設定をタイプのすべてのリソースに 適用できます
テンプレートはサーバーの設定です。メトリクスは、アクティブなメトリクスと、特定タイプのすべてのリソースについてのコレクションスケジュールを定義します。テンプレートが使用されると、プラグイン記述子に提供されるデフォルトのメトリクス設定をすべて省略します。(メトリクステンプレートは、メトリクスが有効かどうかとその間隔のみを定義します。プラグイン記述子のみにより、リソースタイプで使用できるメトリクスのみを定義します。)
これらの設定は、必要に応じてリソースレベルで上書きできます。依然として、メトリクスコレクションテンプレートは、リソースおよびマシン全体でメトリック設定を一貫して適用する簡単な方法を提供します。

19.2. メトリクスおよびベースラインチャートの表示

監視のコアとなるのは、リソースに対して収集されるメトリック情報です。各リソースには異なるメトリクスがあります(これらについては、「 『リソースリファレンス: Monitoring, Operation, and Configuration Options』」に記載されます)。3 つのモニタリングチャートで同じ情報が表示されますが、パースペクティブと異なる詳細レベルが表示されます。
  • リソースレベルのサマリー
  • グラフ
  • テーブル
JBoss ON インベントリー全体の Dashboard と同様に、リソースの Summary タブには異なるリソース情報を示すポートレットがあります。ほとんどのリソースには、測定、イベント、および範囲外のメトリックの 3 つのポートレットがあります。Measurements ポートレットには、現在の読み取りとメトリクスの傾向を示す小さなサムネイルチャートがあります。
メトリクスのいずれかをクリックすると、そのメトリクスのベースラインチャートが開きます。で説明されているように 「baselines and Out-of-Bounds Metrics」、ベースラインは一定期間の読み取りの平均値を計算します。この期間における高い測定値と低い数値は、上限と下限を作成します。ベースラインは、デフォルトでは、前述の 7 日間のデータを使用して、3 日ごとに計算されます。ベースラインの測定は、管理者がリソースのアラートを効果的に設定できるように、動作規則の確立に不可欠です。

図19.6 個別のメトリックグラフ

個別のメトリックグラフ
Monitoring タブの Metrics エリアには、表内のすべてのメトリクスが表示され、高い読み取り、低、および現在の読み取りの列が表示されます。各メトリクスのアクティブなアラートの数を示す列もあります。

図19.7 メトリクステーブル

メトリクステーブル
メトリックを拡張すると個々のメトリクスグラフが開き、過去 8 時間の傾向が得られます。これにより、サマリーまたはベースラインのチャートよりも粒度の細かい詳細が提供され、各コレクションの読み取りと正確な読み取りが表示されます。

図19.8 テーブル内のメトリクスグラフ

テーブル内のメトリクスグラフ

19.3. メトリクスコレクションの定義

19.3.1. ベースラインのプロパティーの設定

モニタリングベースラインには、自動メトリックベースラインの計算 方法 を定義する 2 つの設定プロパティーがあります。これらのプロパティーは値を設定せず、基準平均に使用される期間を設定します。
  1. Configuration メニューで System Settings 項目を選択します。
  2. Automatic Baseline Configuration Properties セクションまでスクロールします。
  3. 設定を変更して、計算に使用するウィンドウを定義します。
    • ベースラインの頻度 は、ベースラインの再計算頻度(日数)を設定します。デフォルトは 3 日です。
    • ベースラインデータセットは、ベースラインの計算に使用する期間(日数)を設定します。デフォルトは 7 日です。

19.3.2. 特定のリソースのコレクション間隔の設定

メトリクスは、コレクションスケジュールで指定された間隔で収集されます。すべてのメトリクスがミッションに重要でないか、または変更される可能性もあるため、JBoss ON には異なるメトリクスの収集スケジュールが異なります。また、重要なメトリクスはより頻繁に収集されます。
ほとんどの環境では、日次コレクションスケジュール(24 時間ごとに)を設定するだけで十分です。
特定のメトリックのコレクション間隔を変更するには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
  3. リソースエントリーの Monitoring タブをクリックします。
  4. Schedules サブタブをクリックします。
  5. モニタリング頻度を変更するメトリクスを選択します。複数のメトリクスが同じ頻度に変わる場合は、それらを選択することができます。
  6. 適切な時間単位(秒、分、時間)で、目的のコレクション期間を Collection Interval フィールドに入力します。
  7. をクリックし Setます。

19.3.3. 特定リソースのメトリクスの有効化および無効化

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リソースエントリーの Monitoring タブをクリックします。
  4. Schedules サブタブをクリックします。
  5. 有効または無効にするメトリクスを選択します。
  6. Enable または Disable ボタンをクリックします。

19.3.4. メトリクステンプレートの変更

リソースタイプに対して収集されるメトリクスは、リソースタイプの モニタリングテンプレート で定義されます。各リソースタイプには、デフォルトで一部のメトリクスが無効になっているため、手動で有効にする必要があります。同様に、デフォルトで有効にされているメトリクスを無効にすることができます。
注記
メトリクステンプレートは、既存のリソースと新しいリソースに適用するためにチェックボックスを選択しない限り、そのリソースの新規リソースにのみ適用されます。
  1. トップナビゲーションでメニューを開き、Administration Configuration メニューを開きます。
  2. Metric Collection Templates メニュー項目を選択します。これにより、プラットフォームおよびサーバータイプ両方のリソースタイプが長いリストが開きます。
  3. テンプレート定義を作成するリソースのタイプを見つけます。
  4. 鉛筆アイコンをクリックして、メトリクスコレクションスケジュールテンプレートを編集します。
  5. 有効または無効にする必要のあるメトリクスを選択し、Enable または Disable ボタンをクリックします。
  6. メトリクスが収集される頻度を編集するには、Update schedules for existing resources of marked type チェックボックスを選択してから Collection Interval for Selected: フィールドに時間枠を入力します。
  7. Set ボタンをクリックします。

19.3.5. PostgreSQL Query をメトリクスとして追加

SQL クエリーは、子リソースとして PostgreSQL データベースに追加できます。そのエントリーは、その PostgreSQL データベースのカスタムメトリクスになります。
クエリーメトリクスには、JBoss ON エージェントがクエリーのデータを収集できるようにする 2 つの列が 必要 です。
  • metricColumn
  • count(id)
クエリーは、それらの 2 つの列を持つ単一の行を返す必要があります。最初の列は、収集されたメトリクスであることを示唆し、2 つ目はメトリクスのカウントを示します。
たとえば、ログインしたユーザーを追跡するには、以下を実行します。
SELECT 'metricColumn', count(id) FROM my_application_user WHERE is_logged_in = true
SELECT ステートメントは、JBoss ON エージェントのメトリクスを定義します。残りのクエリーはデータベースからデータを収集します。簡単です。
クエリーに基づいてメトリクスを追加するには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. PostgreSQL リソースを検索します。
  3. PostgreSQL データベースの Inventory タブをクリックします。
  4. Inventory タブ下部の Import ボタンをクリックし、を選択し Queryます。
  5. クエリーメトリクスのプロパティーを入力します。特に 3 つのフィールドが重要になります。
    • Table は、データベース内にデータが含まれるテーブルを示します。これはクエリーの FROM ステートメントに含まれるものになります。
    • には、実行する完全なクエリー Metric Query が含まれます。SELECT ステートメントは、JBoss ON エージェントがメトリクスとして解釈されるようにクエリーを正しく 'metricColumn',count(id) フォーマットする必要があります。
      SELECT 'metricColumn', count(id) FROM my_application_user WHERE is_logged_in = true
    • メトリクスの設定ではこの Name フィールドは重要ではありませんが、後でメトリクスの特定が重要になります。
クエリーが作成されると、エージェントはデータのカウントを収集します。

図19.9 Query: ログイン済みユーザー数の合計

Query: ログイン済みユーザー数の合計

第20章 イベント

メトリクスデータはスケジュールに従って収集されます。ただし、突然のシステムのシャットダウンなど、リソースが散在的に発生するアクションもあります。これらは イベント です。イベントデータは無作為に生成される可能性があるため、イベントは検出されるとすぐにエージェントに送信されます。

20.1. イベント、ログ、およびリソース

操作および一部のサーバータイプは、独自のログファイルを保持し、単純なデバッグ情報から重大なエラーまで、そのリソースのインシデントに関する情報の定常的なストリームを登録します。メトリクスは(以降)設定されたスケジュールで収集されます。イベントは、実際のアクションに基づいて行われるため、完全にランダムです。その後、イベントはリソースのパフォーマンスを異なる観点にすることができます。
イベント監視は、それらのストリーミングログファイルメッセージを追跡します。つまり、JBoss ON イベント監視はフィルターされたログビューアーです。イベントが有効になると、JBoss ON のイベントビューアーを介してすべてのログメッセージが送信されます。しかし、JBoss ON が記録して表示するメッセージのタイプはイベント設定で制限され、特定の文字列に一致するメッセージやメッセージのみがイベントビューに含まれるようにします。
数少ないリソースタイプのレコードと表示イベント。
  • Linux(syslog)
  • Windows(Windows イベントログ)
  • Apache サーバー(ログファイル)
  • JBoss EAP サーバー(ログファイル)
注記
イベントは、リソースがアクティブになる前に有効にして設定する必要があります。
デフォルトのイベントは標準のログファイルから取得されます。カスタムリソースタイプは、ログまたは JMX 通知や JMS メッセージングシステムなどの非同期メッセージングシステムでイベントソースを特定できます。

20.2. イベント日付の形式

JBoss ON では、ログメッセージが log4j ログパターンを追跡することを想定します。
date severity [class] message
イベントの監視が有効になっている場合、日付 形式は設定可能です。カスタムログの場合、カスタムパターンを追加できます。日付形式を指定しないと、log4j で使用される 3 つの標準形式が試行されます。
YYYY-mm-dd HH:mm:ss,SSS
HH:mm:ss,SSS
dd MM yyyy HH:mm:ss,SSS
次に重大度を設定する必要があります。プレーン、括弧で囲まれたり、括弧で囲まれたりできます。
date SEVERITY [org.foo.bar] my message
date [SEVERITY] [org.foo.bar] my message
date ( SEVERITY ) [org.foo.bar] my message
重大度の後には、ログエントリーの形式に対する実際の制約はありません。クラスまたはその他の識別子が渡される場合、それらは適切に表示されます。

20.3. 新規イベントの定義

イベントは、ログに記録される特定のサービスに対してイベントログが適切に有効になっている場合にのみ監視サービスによって認識されます。これには、ログまたはシステムサービスのログイベントを作成し、リソースでログパスを指定し、ログの形式に一致する日付形式を設定する必要があります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リソースエントリーの Inventory タブをクリックします。
  4. Connection Settings サブタブを選択します。
  5. Events Log セクションの下にあるプラスアイコンをクリックして、監視するログインスタンスを追加します。
  6. イベントログコレクションを有効にします。
  7. イベントログコレクションのパラメーターを設定します。
    設定されているリソースに応じて、イベントログ設定には若干異なるオプションがあります。すべてのリソースを使用すると、異なるフィルターで以下が含まれるログメッセージを特定できます。
    • エラーメッセージの最小重大度。
    • ログメッセージ文字列で使用する正規表現またはパターン。
    また、アプリケーションサーバーと Linux では、さまざまなログの場所を指定できます。(Windows リソースはシステムイベントログを使用します。) カスタムログの場所に加え、他のロギングサービスも使用できます。Linux では、プラットフォームとプログラムログの両方を監視できます。アプリケーションサービスでは、メッセージングサービス内のログをチェックできます。
    で説明されているように 「イベント日付の形式」、ロギングに使用できる日付の形式は異なります。log4j 以外のものを使用すると、エージェントがログエントリーを読み取りできるようにパターンを指定できます。

    図20.1 EAP イベントログの設定

    EAP イベントログの設定
    アプリケーションサーバーや Windows のいずれかとは異なり、Linux システムは、システムファイル または リスナーにイベントをログに記録できます。rsyslog サーバーまたはローカル syslog リスナーが設定されている場合は、リスナー(ローカルファイルではなく)を選択し、リモートサーバーのリスナーポートおよびバインドアドレスを追加できます。

    図20.2 Linux イベントログの設定

    Linux イベントログの設定

20.4. イベントの表示

  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リソースエントリーの Events タブをクリックします。イベントは重大度(debug、info、warn、error、および fatal)でフィルターできます。
  4. 詳細については、特定のイベントをクリックします。
注記
最近のイベントは、「Recent Events」ポートレットを使用して Dashboard から直接監視することもできます。ダッシュボードにポートレットを追加する方法は、本ガイドの 「ダッシュボードの追加および編集」 セクションを参照してください。

20.5. 詳細ディスカッション: イベントの相関

IT インフラストラクチャーには多くの移動部分がありますが、ある変更により結果の送付が原因となる可能性があります。イベントに応答し、インフラストラクチャーを管理できる要因の 1 つが、イベントの原因と関連付ける機能です。
イベントまたはアラートの原因となった変更を特定する方法はありませんが、関連する JBoss ON 要素(アラート、設定変更、イベントログ、ドリフト検出、またはインベントリーの変更)がどのように関連するかを視覚化するのに役に立ちます。各リソースには Summary タブ上の Timeline エリアがあります。これは、JBoss ON を介して、または JBoss ON によって検出されたリソースで発生した主要な操作をすべて収集します。
検索する内容はクラスターです。たとえば、JBoss サーバーで設定が変更され、重大なアラートがあり、JBoss サーバーログに同時エラーが発生していました。これは、設定変更によりパフォーマンスの問題が発生したことを示す妥当な情報です。

図20.3 リソースタイムラインクラスター

リソースタイムラインクラスター

第21章 URL 応答時間の監視

Web アプリケーションのパフォーマンスの一部は、リクエストに対する応答の仕組みによって決まります。JBoss Operations Network は、URL がリクエストに 応答するのにかかる時間を測定する応答時間フィルター と呼ばれる追加の監視設定を提供します。

21.1. URL の呼び出し時間(または応答時間)の監視

Web アプリケーションのパフォーマンスは、簡易可用性よりも複雑です。アプリケーションが実行しているかどうかと同様に、アプリケーションがリクエストに応答できる速度が重要になります。
アプリケーションが何らかの要求に応答するのにかかる時間は、呼び出し時間 または 応答時間 データです。
2 種類のリソースはデフォルトで呼び出し時データをサポートします。
  • EJB メソッド呼び出しのセッション Bean。
  • URL 応答の Web サーバー(スタンドアロンまたはアプリケーションサーバー埋め込み)。Web サーバーには、応答時間に測定する URL リソースの設定に関する追加の応答時間フィルターが必要です。
応答時間監視は、単一のデータポイントをキャプチャーすることよりもパフォーマンスに基づいています。応答または呼び出し時データは集計として表示され、URL またはメソッドごとの最大、最小、および平均の応答時間を表示します。

21.2. 呼び出し時間メトリクスの表示

セッション bean リソースと Web サーバーリソースには、という追加の Monitoring サブタブがあり Calltimeます。URL リソースまたはメソッドごとに、呼び出し時データまたは応答時間データ範囲(最小、最大、および平均)がすべて表示されます。新しい URL またはメソッドにアクセスすると、それらは動的に results テーブルに追加されます。

図21.1 Web サーバーの URL メトリクス

Web サーバーの URL メトリクス

21.3. 拡張例: Web サイトのパフォーマンス

設定

サンプル Co. のビジネス、サービス、およびサポートは Web サイトに関連付けられています。お客様は、購入した製品へのアクセス、トレーニングまたはコンサルティングのスケジュール、およびほとんどのサポートとサポートを受けることができる必要があります。このサイトの速度が遅い、または一部のリソースにアクセスできない場合は、直ちに否定的な経験があります。

ゴールは、Web サーバーが実行中かどうかを監視することですが、Web アプリケーションが応答し、Example Co. のお客様として実行されるかどうかを監視します。

操作方法

Tim the IT Guy は、Web アプリケーションのパフォーマンス情報を取得する 3 つの異なる方法を識別します。

  • 個々の URL の応答時間
  • リクエストおよび応答の合計数などのスループット情報
  • 重要な HTTP レスポンスコードのカウント
監視とアラートはいずれも、応答時間およびスループットメトリックのみに基づいて設定できます。ただし、Web サイトのパフォーマンスは、Web サーバーまたはその関連するデータベースに関する根本的な問題を示します。そのため、Tim は Web サイトのパフォーマンスが低下した場合だけでなく、一部のパフォーマンスメトリックを基礎となるサーバーおよびデータベースのパフォーマンスと、応答の低下を軽減する起動操作と関連付けたいと考えました。
Tim は、Web サイトや Web サーバーのパフォーマンスの低下を引き起こす一般的なシナリオと、IT スタッフが問題を分析するまで JBoss ON が実行できる簡単な操作を計画します。Tim は、潜在的な原因を絞り込み、パフォーマンスを低減しようとします。1 つの条件に対してアラートを発行したり、条件の組み合わせに対してアラートを発行できます。Tim の場合、パフォーマンス上の問題(「リソースに対するアラート設定の基本的な手順」)の基礎となる原因の異なる組み合わせに基づいて、3 つの異なるアラートを作成します。
  • 応答時間が十分で、多数の HTTP エラー 500 応答がある場合は、Web サーバー(「詳細なディスカッション: 操作の開始」)を再起動する操作でアラートを設定できます。
  • 応答時間が十分で、多数の HTTP エラー 404 応答がある場合は(リソースが適切に配信されない可能性がある)、データベースを再起動するようにアラートが設定されます。
  • 応答時間が十分で、1 分あたりの合計リクエスト数が多い場合は、サーバーへの負荷が大きすぎる可能性があります。アラートは、負荷分散に役立つ別の Web サーバーインスタンスを作成するように設定できます。JBoss ON CLI スクリプトを使用すると、JBoss ON CLI スクリプトを使用すると、必要に応じて新しいリソースを作成し、適切な web アプリケーションのバンドル(「詳細なディスカッション: リソーススクリプトの開始」)をデプロイすることができます。
最も重要な要因は応答時間です。これは、すべてのアラートの要因です。各アラートには呼び出し時間データに基づく条件が 1 つあります。特に、呼び出し時データは特定のしきい値を経過します。
Tim はパフォーマンスのために約 15 秒の合理的なしきい値を選択します。パフォーマンスが低下し、HTTP Response Time メトリクスがページをロードするのに 20 秒を超える値を返す場合、JBoss ON はアラートを発行します。
単純な呼び出し時間の変更を警告できる。呼び出し時の変更により、確立されたベースラインからの変更に関するアラートが発生します(最小値、最大値、または平均値)。あらゆる種類を変更すると、パフォーマンスが低下するか、パフォーマンス 向上します。しきい値は、特定の変更についてのみ警告します。
次に、Tim は AND 演算子を持つ他の条件を、設定する各アラートに追加します。
また、ほとんどの Web アプリケーション関連のメトリクスはデフォルトで有効になっていません。Tim は、1 分あたりのリクエストの合計数、分あたりの合計応答数、各 Web サーバー()のメトリクスごとの 404 応答数、および各 Web サーバー(「メトリクステンプレートの変更」)に対する 500 応答数を有効にします。
また、Tim はすべてのアラートに対して、他の応答と共にメール通知も設定し、IT スタッフのメンバーが Web サイトのパフォーマンスの問題を評価し、必要に応じて追加のアクションを実行できるようにします。

21.4. EJB 呼び出し時メトリクスの設定

EJB メソッドの呼び出し時間測定は、デフォルトでは収集されません。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Services メニューテーブルを選択し、EJB リソースに移動します。
    注記
    名前でセッション Bean を検索する方が、できるかもしれません。
  3. EJB リソースエントリーの Monitoring タブをクリックします。
  4. Schedules サブタブをクリックします。
  5. Method Execution Time メトリクスを選択します。このメトリクスは呼び出し時間 タイプ です。
  6. 一覧の Enable 下部にあるをクリックします。

21.5. JBoss EAP の応答時間メトリクスの設定

JBoss ON は、応答してデプロイされたアプリケーションがクライアントリクエストにどのように反応するかをテストすることで、アプリケーションのパフォーマンスを監視できます。特に、JBoss ON はアプリケーションがリクエストに応答する速度を決定することができます。これは 応答時間測定 と呼ばれます。
JBoss EAP サーバーの応答時間メトリクスを収集するには、最初に応答時間フィルターのサーブレット JAR をインストールし、Web サーバーがこれを使用するように設定します。次に、Web リソースのメトリクスコレクションを有効にします。

21.5.1. JBoss EAP 6 の応答時間フィルターのインストール

注記
応答時間メトリクスを収集するには、サーバー http(s)管理インターフェースに接続するために EAP 6 エージェントプラグインを設定する必要があります。

JBoss EAP での応答時間フィルターのインストール方法

以下の手順に従って、JBoss EAP 6 に応答時間フィルターを正しくインストール

前提条件

手順21.1

  1. JBoss ON UI から JBoss の応答時間パッケージをダウンロードします。応答時間フィルターは AS 7 モジュールとしてパッケージ化されます。以下を取得するモジュールは 2 つあります。
    rhq-rtfilter-module.zip
    rhq-rtfilter-subsystem-module.zip
    注記
    これは、wget以下のコマンドを使用してコマンドラインから行うこともできます。
    [root@server ~]# wget http://server.example.com:7080/downloads/connectors/rhq-rtfilter-module.zip
    [root@server ~]# wget http://server.example.com:7080/downloads/connectors/rhq-rtfilter-subsystem-module.zip
    1. トップメニューの Administration タブをクリックします。
    2. 左側の Configuration メニューボックスで、Downloads 項目を選択します。
    3. rhq-rtfilter-module.zip および rhq-rtfilter-subsystem-module.zip リンクをクリックし、ディレクトリーなどのアクセス可能なディレクトリーにファイルを保存し /tmp ます。
  2. JBoss EAP 6 インスタンスの modules/ ディレクトリーを開きます。例:
    [root@server ~]# cd /opt/jboss-eap-6.0/modules/
  3. rhq-rtfilter-module.zip アーカイブを展開して、応答時間フィルター JAR と関連する module.xml ファイルをインストールします。
    [root@server modules]# unzip /tmp/rhq-rtfilter-module.zip
  4. サーバーの設定ファイル domain.xml またはを開き standalone.xmlます。
  5. <subsystem> 要素内のグローバルモジュールのリストにモジュールを追加して、応答時間モジュールをグローバルにデプロイします。ファイルが完了したら、保存します。
    <profile...
    	<subsystem xmlns="urn:jboss:domain:ee:1.1">
    		<global-modules>
    		    <module name="org.rhq.helpers.rhq-rtfilter" slot="main"/>
    		</global-modules>
    	</subsystem>
    </profile>
  6. rhq-rtfilter-subsystem-module.zip アーカイブを展開してサブシステムの応答時間フィルター JAR と関連する module.xml ファイルをインストールします。
    [root@server modules]# unzip /tmp/rhq-rtfilter-subsystem-module.zip
    これにより、フィルターがアプリケーションサーバーまたは個別の Web アプリケーションのサブシステムとしてインストールされます。
  7. フィルターをインストールしたら、JBoss EAP 6 サーバーをサーバーを使用するように設定する必要があります。
    応答時間フィルターは、EAP/AS インスタンスがホストするすべての Web アプリケーションに対してグローバルにデプロイすることも、特定の Web アプリケーションに対して設定することもできます。
    フィルターをグローバルサブシステムとしてデプロイするには、以下を行います。
    1. サーバーの設定ファイル domain.xml またはを開き standalone.xmlます。
    2. 応答時間フィルターに <extensions> 要素を追加します。
      <extension module="org.rhq.helpers.rhq-rtfilter-subsystem"/>
  8. 要素の下に <subsystem> <profile> 要素を追加します。
    応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <subsystem> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.1「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。
    オプションのパラメーターが設定されていない場合でも、<subsystem> 要素を追加する必要があります。
    <subsystem xmlns="urn:rhq:rtfilter:1.0">
        <!-- Optional parameters.
    
           <init-param>
               <param-name>chopQueryString</param-name>
               <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>logDirectory</param-name>
              <param-value>/tmp</param-value>
           </init-param>
           <init-param>
               <param-name>logFilePrefix</param-name>
               <param-value>localhost_7080_</param-value>
           </init-param>
           <init-param>
               <param-name>dontLogRegEx</param-name>
               <param-value></param-value>
           </init-param>
           <init-param>
              <param-name>matchOnUriOnly</param-name>
              <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>timeBetweenFlushesInSec</param-name>
               <param-value>73</param-value>
           </init-param>
           <init-param>
               <param-name>flushAfterLines</param-name>
               <param-value>13</param-value>
           </init-param>
           <init-param>
               <param-name>maxLogFileSize</param-name>
               <param-value>5242880</param-value>
           </init-param>
    -->
    </subsystem>

手順21.2 JBoss EAP 6 で個別の Web アプリケーションに応答時間フィルターを設定する方法

  1. Web アプリケーションの web.xml ファイルを開きます。
    [root@server ~]# vim WARHomeDir/WEB-INF/web.xml
  2. フィルターを追加し、設定に応じてマッピング要素をファイルにフィルターします。これにより、応答時間フィルターが有効になります。
    応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <filter> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.1「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。
       <filter>
           <filter-name>RhqRtFilter</filter-name>
           <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter</filter-class>
    
    <!-- Optional parameters.
    
           <init-param>
               <param-name>chopQueryString</param-name>
               <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>logDirectory</param-name>
              <param-value>/tmp</param-value>
           </init-param>
           <init-param>
               <param-name>logFilePrefix</param-name>
               <param-value>localhost_7080_</param-value>
           </init-param>
           <init-param>
               <param-name>dontLogRegEx</param-name>
               <param-value></param-value>
           </init-param>
           <init-param>
              <param-name>matchOnUriOnly</param-name>
              <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>timeBetweenFlushesInSec</param-name>
               <param-value>73</param-value>
           </init-param>
           <init-param>
               <param-name>flushAfterLines</param-name>
               <param-value>13</param-value>
           </init-param>
           <init-param>
               <param-name>maxLogFileSize</param-name>
               <param-value>5242880</param-value>
           </init-param>
    -->
    
       </filter>
    
       <!-- Use this only when also enabling the RhqRtFilter in the filter
       <filter-mapping>
           <filter-name>RhqRtFilter</filter-name>
           <url-pattern>/*</url-pattern>
       </filter-mapping>
       -->
  3. JBoss EAP サーバーを再起動して、新しい web.xml 設定を読み込みます。

表21.1 ユーザー定義の <filter> Settings に使用できるパラメーター

パラメーター
description
chopQueryString
このパラメーターが true に設定されている場合、クエリーの URI 部分のみがログに記録されます。それ以外の場合は、クエリー行全体がログに記録されます。デフォルトは true です。
logDirectory
ログファイルが書き込まれるディレクトリー。デフォルト設定は {jboss.server.log.dir}/rt/ (通常は server/xxx/log/rt)です。このプロパティーが定義されていない場合は、フォールバックは {java.io.tmpdir}/rt/ (/tmp/ on)になります。 UNIX®および ~/Application Data/Local Settings/Temp - TEMP 環境変数が使用されることを確認します。この init パラメーターを指定すると、ディレクトリーは作成 rt/ されませんが、指定したディレクトリーは文字どおりに取得されます。
logFilePrefix
ログファイルの前に配置される接頭辞。デフォルトは空の文字列です。
dontLogRegEx
クエリー文字列に適用される正規表現。See java.util.regex.Pattern.パラメーターが指定されていない場合や、空の文字列は適用されません。
matchOnUriOnly
dontLogRegEx はクエリーの URI 部分(true)またはクエリー文字列(false)全体に適用される必要があります。デフォルトは true です。
timeBetweenFlushesInSec
ログ行はデフォルトでバッファーされます。指定の秒数を超え、新しいリクエストを受け取ると、(を参照)後にフラッシュする行数がまだ到達していない場合でも、バッファーされた行はディスクにフラッシュされます。デフォルト値は 60 秒(1 分)です。
flushAfterLines
ログ行はデフォルトでバッファーされます。指定された行がバッファーされると、ディスクにフラッシュされます。デフォルト値は 10 行です。
maxLogFileSize
ログファイルの最大許容サイズ(バイト単位)。ログファイルがこの制限を超えると、フィルターは切り捨てられます。デフォルト値は 5242880(5 MB)です。
vHostMappingFile
このプロパティーファイルは、Tomcat プロセスクラスパスに存在する必要があります。たとえば、../conf/vhost-mappings.properties のようになります。ファイルには、「着信」 vhost(サーバー名)から応答時間のログファイル名の接頭辞として使用する vhost へのマッピングが含まれます。マッピングがない場合(ファイルまたはエントリーの応答時間が設定されていない場合)、受信 vhost(サーバー名)が使用されます。例:
pickeldi.users.acme.com=pickeldi
pickeldi=
%HOST%=
最初のマッピングでは、受信 vhost が 'host1.users.acme.com' の場合は、ログファイル名に「host1」の vhost をプレフィックスとして取得し、コンテキストルート部分から _ で区切ります。2 つ目のマッピングでは、「incoming」 vhost が「host1」で、接頭辞なし、_ を使用しない場合が示されます。3 つ目のマッピングは、特別な左端トークンである%HOST%' を使用します。このマッピングでは、「incoming」 vhost が localhost の表現である場合、接頭辞なし、_ を使用すべきです。
%host% は、InetAddress.getLocalHost()の実装によって返されるホスト名、または正規のホスト名または IP アドレスに一致します。
2 つ目のマッピングは空の右側の例ですが、vhost も提供しました。
これはワンタイム置換です。1 行目の結果が 2 番目の行に適用されるという形式の再帰はありません。

21.5.2. JBoss EAP 7 の応答時間フィルターのインストール

注記
応答時間メトリクスを収集するには、JBoss EAP 7 エージェントプラグインを設定してサーバー http(s)管理インターフェースに接続する必要があります。

JBoss EAP での応答時間フィルターのインストール方法

以下の手順に従って、JBoss EAP 7 に応答時間フィルターを正しくインストール

前提条件

手順21.3

  1. JBoss ON UI から JBoss の応答時間パッケージをダウンロードします。応答時間フィルターは AS 7 モジュールとしてパッケージ化されます。取得するモジュールは 2 つあります。両方は 1 つの zip アーカイブに含まれます。
    rhq-rtfilter-wfly-10-dist.zip
    注記
    これは、wget以下のコマンドを使用してコマンドラインから行うこともできます。
    [root@server ~]# wget http://server.example.com:7080/downloads/connectors/rhq-rtfilter-wfly-10-dist.zip
    1. トップメニューの Administration タブをクリックします。
    2. 左側の Configuration メニューボックスで、Downloads 項目を選択します。
    3. rhq-rtfilter-wfly-10-dist.zip リンクをクリックして、ディレクトリーなどのアクセス可能なディレクトリーにファイルを保存し /tmp ます。
  2. JBoss EAP 7 インスタンスの modules/ ディレクトリーを開きます。例:
    [root@server ~]# cd /opt/jboss-eap-7.0/modules/
  3. rhq-rtfilter-wfly-10-dist.zip アーカイブを展開して JAR と関連する module.xml ファイルをインストールします。
    [root@server modules]# unzip /tmp/rhq-rtfilter-wfly-10-dist.zip
  4. サーバーの設定ファイル domain.xml またはを開き standalone.xmlます。
  5. <subsystem> 要素内のグローバルモジュールのリストにモジュールを追加して、応答時間モジュールをグローバルにデプロイします。domain:ee サブシステムのバージョンは JBoss EAP のバージョンごとに異なることに注意してください。ファイルが完了したら、保存します。
    <profile...
    	<subsystem xmlns="urn:jboss:domain:ee:1.1">
    		<global-modules>
    		    <module name="org.rhq.helpers.rhq-rtfilter" slot="main"/>
    		</global-modules>
    	</subsystem>
    </profile>
  6. フィルターをインストールしたら、JBoss EAP 7 サーバーをサーバーを使用するように設定する必要があります。
    応答時間フィルターは、JBoss EAP インスタンスがホストするすべての web アプリケーションに対してグローバルにデプロイすることも、特定の web アプリケーションに設定することもできます。
    フィルターをグローバルサブシステムとしてデプロイするには、以下を行います。
    1. サーバーの設定ファイル domain.xml またはを開き standalone.xmlます。
    2. 応答時間フィルターに <extensions> 要素を追加します。
      <extension module="org.rhq.helpers.rhq-rtfilter-wfly-10-subsystem"/>
  7. 要素の下に <subsystem> <profile> 要素を追加します。
    応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <subsystem> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.2「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。
    オプションのパラメーターが設定されていない場合でも、<subsystem> 要素を追加する必要があります。
    <subsystem xmlns="urn:rhq:rtfilter:1.0">
        <!-- Optional parameters.
    
           <init-param>
               <param-name>chopQueryString</param-name>
               <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>logDirectory</param-name>
              <param-value>/tmp</param-value>
           </init-param>
           <init-param>
               <param-name>logFilePrefix</param-name>
               <param-value>localhost_7080_</param-value>
           </init-param>
           <init-param>
               <param-name>dontLogRegEx</param-name>
               <param-value></param-value>
           </init-param>
           <init-param>
              <param-name>matchOnUriOnly</param-name>
              <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>timeBetweenFlushesInSec</param-name>
               <param-value>73</param-value>
           </init-param>
           <init-param>
               <param-name>flushAfterLines</param-name>
               <param-value>13</param-value>
           </init-param>
           <init-param>
               <param-name>maxLogFileSize</param-name>
               <param-value>5242880</param-value>
           </init-param>
    -->
    </subsystem>

手順21.4 JBoss EAP 7 で個別の Web アプリケーションに応答時間フィルターを設定する方法

  1. Web アプリケーションの web.xml ファイルを開きます。
    [root@server ~]# vim WARHomeDir/WEB-INF/web.xml
  2. フィルターを追加し、設定に応じてマッピング要素をファイルにフィルターします。これにより、応答時間フィルターが有効になります。
    応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <filter> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.2「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。
       <filter>
           <filter-name>RhqRtFilter</filter-name>
           <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter</filter-class>
    
    <!-- Optional parameters.
    
           <init-param>
               <param-name>chopQueryString</param-name>
               <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>logDirectory</param-name>
              <param-value>/tmp</param-value>
           </init-param>
           <init-param>
               <param-name>logFilePrefix</param-name>
               <param-value>localhost_7080_</param-value>
           </init-param>
           <init-param>
               <param-name>dontLogRegEx</param-name>
               <param-value></param-value>
           </init-param>
           <init-param>
              <param-name>matchOnUriOnly</param-name>
              <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>timeBetweenFlushesInSec</param-name>
               <param-value>73</param-value>
           </init-param>
           <init-param>
               <param-name>flushAfterLines</param-name>
               <param-value>13</param-value>
           </init-param>
           <init-param>
               <param-name>maxLogFileSize</param-name>
               <param-value>5242880</param-value>
           </init-param>
    -->
    
       </filter>
    
       <!-- Use this only when also enabling the RhqRtFilter in the filter
       <filter-mapping>
           <filter-name>RhqRtFilter</filter-name>
           <url-pattern>/*</url-pattern>
       </filter-mapping>
       -->
  3. JBoss EAP サーバーを再起動して、新しい web.xml 設定を読み込みます。

表21.2 ユーザー定義の <filter> Settings に使用できるパラメーター

パラメーター
description
chopQueryString
このパラメーターが true に設定されている場合、クエリーの URI 部分のみがログに記録されます。それ以外の場合は、クエリー行全体がログに記録されます。デフォルトは true です。
logDirectory
ログファイルが書き込まれるディレクトリー。デフォルト設定は {jboss.server.log.dir}/rt/ (通常は server/xxx/log/rt)です。このプロパティーが定義されていない場合は、フォールバックは {java.io.tmpdir}/rt/ (/tmp/ on)になります。 UNIX®および ~/Application Data/Local Settings/Temp - TEMP 環境変数が使用されることを確認します。この init パラメーターを指定すると、ディレクトリーは作成 rt/ されませんが、指定したディレクトリーは文字どおりに取得されます。
logFilePrefix
ログファイルの前に配置される接頭辞。デフォルトは空の文字列です。
dontLogRegEx
クエリー文字列に適用される正規表現。See java.util.regex.Pattern.パラメーターが指定されていない場合や、空の文字列は適用されません。
matchOnUriOnly
dontLogRegEx はクエリーの URI 部分(true)またはクエリー文字列(false)全体に適用される必要があります。デフォルトは true です。
timeBetweenFlushesInSec
ログ行はデフォルトでバッファーされます。指定の秒数を超え、新しいリクエストを受け取ると、(を参照)後にフラッシュする行数がまだ到達していない場合でも、バッファーされた行はディスクにフラッシュされます。デフォルト値は 60 秒(1 分)です。
flushAfterLines
ログ行はデフォルトでバッファーされます。指定された行がバッファーされると、ディスクにフラッシュされます。デフォルト値は 10 行です。
maxLogFileSize
ログファイルの最大許容サイズ(バイト単位)。ログファイルがこの制限を超えると、フィルターは切り捨てられます。デフォルト値は 5242880(5 MB)です。
vHostMappingFile
このプロパティーファイルは、Tomcat プロセスクラスパスに存在する必要があります。たとえば、../conf/vhost-mappings.properties のようになります。ファイルには、「着信」 vhost(サーバー名)から応答時間のログファイル名の接頭辞として使用する vhost へのマッピングが含まれます。マッピングがない場合(ファイルまたはエントリーの応答時間が設定されていない場合)、受信 vhost(サーバー名)が使用されます。例:
pickeldi.users.acme.com=pickeldi
pickeldi=
%HOST%=
最初のマッピングでは、受信 vhost が 'host1.users.acme.com' の場合は、ログファイル名に「host1」の vhost をプレフィックスとして取得し、コンテキストルート部分から _ で区切ります。2 つ目のマッピングでは、「incoming」 vhost が「host1」で、接頭辞なし、_ を使用しない場合が示されます。3 つ目のマッピングは、特別な左端トークンである%HOST%' を使用します。このマッピングでは、「incoming」 vhost が localhost の表現である場合、接頭辞なし、_ を使用すべきです。
%host% は、InetAddress.getLocalHost()の実装によって返されるホスト名、または正規のホスト名または IP アドレスに一致します。
2 つ目のマッピングは空の右側の例ですが、vhost も提供しました。
これはワンタイム置換です。1 行目の結果が 2 番目の行に適用されるという形式の再帰はありません。

21.5.3. 呼び出し時メトリックの有効化

応答時間メトリクスは、ライブアプリケーションのデプロイメントで設定されます。デプロイメントリソースは、スタンドアロン EAP 6 サーバーまたはサーバーグループのいずれかの子です。

図21.2 Web ランタイムリソース

Web ランタイムリソース
  1. トップメニューの Inventory タブをクリックします。
  2. Servers - Top Level Imports 項目をクリックし、JBoss EAP 6 リソースを選択します。
  3. デプロイメントリソースに移動し、web サブシステムにアプリケーションを展開します。
  4. Web リソースエントリーの Monitoring タブをクリックします。
  5. Schedules サブタブをクリックします。
  6. Response Time メトリクスを選択します。このメトリクスは呼び出し時間 タイプ です。
  7. 一覧の Enable 下部にあるをクリックします。
  8. Web エントリーの Inventory タブをクリックします。
  9. Connection Settings サブタブを選択します。
  10. 応答時間設定のチェックボックスの設定を解除し、Web アプリケーションに適した値を入力します。
    • 特定の Web アプリケーションによって使用される応答時間ログ。ログファイルは、call-time データコレクションが機能するのに必須の設定です。
    • 応答時間の測定から除外するファイル、要素、またはページ。応答時間ログは、Web サーバーが処理するすべてのリソースの時間を記録します。これには、CSS ファイルやアイコン、背景イメージなどのサポートファイルが含まれます。
    • URL で渡された異なるパラメーターを使用して同じページにアクセスできます。この Response Time Url Transforms フィールドは、渡されたパラメーターのストライピングや置き換えに使用できる正規表現を提供します。

21.6. Apache、EWS/Tomcat、および JBoss EAP 5 への応答時間監視の設定

応答時間監視は、デフォルトではアプリケーションや Web サーバーから利用できません。特別なモジュールをインストールして、JBoss ON が応答時間メトリクスを収集するようにする必要があります。
モジュールのインストール後に、リソースに対して HTTP メトリックを有効にできます。

21.6.1. parameters for User-Defined <filter>s

管理者は、アプリケーションおよび Web サーバーに対して応答時間メトリックを収集する方法のルールを設定できます。これは応答時間 フィルター です。
JBoss、Apache、および EWS/Tomcat に応答時間監視を行うには、応答時間フィルターがインストール済みである必要があります。これらのデフォルトフィルターに追加して、リソースのモニタリングをカスタマイズできます。

表21.3 parameters for User-Defined <filter>s

パラメーター
description
chopQueryString
このパラメーターが true に設定されている場合、クエリーの URI 部分のみがログに記録されます。それ以外の場合は、クエリー行全体がログに記録されます。デフォルトは true です。
logDirectory
ログファイルが書き込まれるディレクトリー。デフォルト設定は {jboss.server.log.dir}/rt/ (通常は server/xxx/log/rt)です。このプロパティーが定義されていない場合は、フォールバックは {java.io.tmpdir}/rt/ (/tmp/ on)になります。 UNIX®および ~/Application Data/Local Settings/Temp - TEMP 環境変数が使用されることを確認します。この init パラメーターを指定すると、ディレクトリーは作成 rt/ されませんが、指定したディレクトリーは文字どおりに取得されます。
logFilePrefix
ログファイルの前に配置される接頭辞。デフォルトは空の文字列です。
dontLogRegEx
クエリー文字列に適用される正規表現。See java.util.regex.Pattern.パラメーターが指定されていない場合や、空の文字列は適用されません。
matchOnUriOnly
dontLogRegEx はクエリーの URI 部分(true)またはクエリー文字列(false)全体に適用される必要があります。デフォルトは true です。
timeBetweenFlushesInSec
ログ行はデフォルトでバッファーされます。指定の秒数を超え、新しいリクエストを受け取ると、(を参照)後にフラッシュする行数がまだ到達していない場合でも、バッファーされた行はディスクにフラッシュされます。デフォルト値は 60 秒(1 分)です。
flushAfterLines
ログ行はデフォルトでバッファーされます。指定された行がバッファーされると、ディスクにフラッシュされます。デフォルト値は 10 行です。
maxLogFileSize
ログファイルの最大許容サイズ(バイト単位)。ログファイルがこの制限を超えると、フィルターは切り捨てられます。デフォルト値は 5242880(5 MB)です。
vHostMappingFile
このプロパティーファイルは、Tomcat プロセスクラスパスに存在する必要があります。たとえば、conf/vhost-mappings.properties ファイルではです。ファイルには、「着信」 vhost(サーバー名)から応答時間のログファイル名の接頭辞として使用する vhost へのマッピングが含まれます。マッピングがない場合(ファイルまたはエントリーの応答時間が設定されていない場合)、受信 vhost(サーバー名)が使用されます。例:
pickeldi.users.acme.com=pickeldi
pickeldi=
%HOST%=
最初のマッピングでは、受信 vhost が 'host1.users.acme.com' の場合は、ログファイル名に「host1」の vhost をプレフィックスとして取得し、コンテキストルート部分から _ で区切ります。2 つ目のマッピングでは、「incoming」 vhost が「host1」で、接頭辞なし、_ を使用しない場合が示されます。3 つ目のマッピングは、特別な左端トークンである%HOST%' を使用します。このマッピングでは、「incoming」 vhost が localhost の表現である場合、接頭辞なし、_ を使用すべきです。
%host% は、InetAddress.getLocalHost()の実装によって返されるホスト名、または正規のホスト名または IP アドレスに一致します。
2 つ目のマッピングは空の右側の例ですが、vhost も提供しました。
これはワンタイム置換です。1 行目の結果が 2 番目の行に適用されるという形式の再帰はありません。

21.6.2. JBoss EAP/AS 5 への応答時間フィルターのインストール

JBoss EAP/AS 5 サーバーの応答時間メトリクスを収集するには、最初に応答時間フィルターのサーブレット JAR をインストールし、Web サーバーがそのサーバーを使用するように設定します。
  1. JBoss ON UI から JBoss の Response Time パッケージをダウンロードします。
    注記
    これは、wget以下のコマンドを使用してコマンドラインから行うこともできます。
    [root@server ~]# wget http://server.example.com:7080/downloads/connectors/connector-rtfilter.zip
    1. トップメニューの Administration タブをクリックします。
    2. 左側の Configuration メニューボックスで、Downloads 項目を選択します。
    3. connector-rtfilter.zip リンクをクリックしてファイルを保存します。
  2. コネクターの展開
    [root@server ~]# unzip connector-rtfilter.zip
  3. プロファイルの lib/ ディレクトリーに rhq-rtfilter-バージョン.jar ファイルをコピーします。
    [root@server ~]# cp connector-rtfilter/rhq-rtfilter-version.jar JbossHomeDir/server/profileName/lib/
    JBoss EAP/AS には commons-logging.jar ファイルがすでに含まれており、応答時間のフィルターにも必要です。
  4. 次に、EAP/AS インスタンス web.xml 用に設定します。
    応答時間フィルターは、EAP/AS インスタンスがホストするすべての Web アプリケーションに対してグローバルにデプロイすることも、特定の Web アプリケーションに対して設定することもできます。
    これをグローバルに設定するには、グローバル web.xml ファイルを編集します。
    [root@server ~]# vim JbossHomeDir/server/configName/deployers/jbossweb.deployer/web.xml
    単一の Web アプリケーション用に設定するには、任意の Web アプリケーションの web.xml ファイルを編集します。
    [root@server ~]# vim WARLocation/WEB-INF/web.xml
  5. フィルターを追加し、設定に応じてマッピング要素をファイルにフィルターします。これにより、応答時間フィルターが有効になります。
    応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <filter> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 「parameters for User-Defined <filter>s」 ます。
       <filter>
           <filter-name>RhqRtFilter</filter-name>
           <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter</filter-class>
    
           <!-- Optional parameters. 
          
           <init-param>
               <param-name>chopQueryString</param-name>
               <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>logDirectory</param-name>
              <param-value>/tmp</param-value>
           </init-param>
           <init-param>
               <param-name>logFilePrefix</param-name>
               <param-value>localhost_7080_</param-value>
           </init-param>
           <init-param>
               <param-name>dontLogRegEx</param-name>
               <param-value></param-value>
           </init-param>
           <init-param>
              <param-name>matchOnUriOnly</param-name>
              <param-value>true</param-value>
           </init-param>
           <init-param>
               <param-name>timeBetweenFlushesInSec</param-name>
               <param-value>73</param-value>
           </init-param>
           <init-param>
               <param-name>flushAfterLines</param-name>
               <param-value>13</param-value>
           </init-param>
           <init-param>
               <param-name>maxLogFileSize</param-name>
               <param-value>5242880</param-value>
           </init-param>       
           -->
       </filter>
    
       <!-- Use this only when also enabling the RhqRtFilter in the filter
       <filter-mapping>
           <filter-name>RhqRtFilter</filter-name>
           <url-pattern>/*</url-pattern>
       </filter-mapping>
       -->
  6. JBoss EAP/AS サーバーを再起動して、新しい web.xml 設定を読み込みます。
  7. の説明に従って HTTP メトリクスを有効にし 「HTTP 応答時間メトリクスの設定」、JBoss ON はアプリケーションサーバーで応答時間メトリクスをチェックします。

21.6.3. 応答時間メトリクス向けの Apache サーバーの設定

  1. Response Time モジュールを使用するには、Apache サーバーが共有オブジェクトサポートでコンパイルされている必要があります。Red Hat Enterprise Linux システムおよび EWS サーバーでは、これはデフォルトで有効になります。
    共有オブジェクトサポートで Apache サーバーがコンパイルされていることを確認するには、apachectl -l コマンドを使用してコンパイル済みモジュールを一覧表示し、mod_so.c モジュールを探します。
    [root@server ~]# apachectl -l
    Compiled in modules:
      core.c
      prefork.c
      http_core.c
      mod_so.c
    - -enable-module=so オプションを使用します。
    [jsmith@server ~]$ ./configure - -enable-module=so
    [jsmith@server ~]$ make install
  2. JBoss ON UI から Apache バイナリーをダウンロードします。
    1. JBoss ON UI にログインします。
      https://server.example.com:7080
    2. トップメニューの Administration タブをクリックします。
    3. 左側の Configuration メニューボックスで、Downloads 項目を選択します。
    4. connector-apache.zip リンクをクリックしてファイルを保存します。
  3. Apache コネクターを展開します。
    [root@server ~]# unzip connector-apache.zip
  4. Response Time モジュールをコンパイルします。
    注記
    apxs ユーザー PATH にインストールされ、インストールされている make 必要があります。
    [root@server ~]# cd apacheMOduleRoot/apache-rt/sources
    [root@server sources]# chmod +x build_apache_module.sh
    [root@server sources]# ./build_apache_module.sh 2.x apache_install_directory/bin/apxs
  5. 次に、Apache サーバーに Response Time モジュールをインストールします。
    [root@server sources]# cp apache2.x/.libs/mod_rt.so apache_install_directory/modules
  6. httpd.conf ファイルを開きます。例:
    [root@server ~]# vim apache_install_directory/conf/httpd.conf
  7. この行をファイルの最後に追加して、Apache の httpd.conf ファイルでモジュールを有効にします。
    LoadModule  rt_module  modules/mod_rt.so
    LogFormat  "%S"  rt_log
    ログ形式を設定する場合、変数に %S は大文字 S が含まれます。
  8. メインの Apache サーバーに応答時間ロギングを設定するには、ファイルのトップレベルに以下の行を追加します。
    CustomLog  logs/myhost.com80_rt.log  rt_log
    仮想ホストの応答時間ロギングを設定するには、<VirtualHost> ブロック内の以下の行を追加します。
    CustomLog  logs/myhost.com8080_rt.log  rt_log
    メインサーバーと仮想ホストで応答時間ログファイルの名前が異なることを確認します。host _port などのファイル名を形成するのに使用する ServerName ディレクティブのホストおよびポートを使用することを検討してください_rt.log
  9. Apache サーバーを再起動します。
    [root@server ~]# apachectl -k restart
  10. Response Time モジュールが正常にインストールされたことを確認するには、CustomLog ディレクティブで設定した応答時間ログファイルが存在することを確認します。
  11. の説明に従って HTTP メトリクスを有効にし 「HTTP 応答時間メトリクスの設定」、JBoss ON はアプリケーションサーバーで応答時間メトリクスをチェックします。

21.6.4. Tomcat に対する応答時間フィルターのインストール

  1. JBoss ON UI から Tomcat の Response Time パッケージをダウンロードします。
    1. トップメニューの Administration タブをクリックします。
    2. 左側の Configuration メニューボックスで、Downloads 項目を選択します。
    3. connector-rtfilter.zip リンクをクリックしてファイルを保存します。
  2. 応答時間コネクターの展開
    unzip connector-rtfilter.zip
    パッケージには 2 つの JAR ファイル(version.jar および commons-logging-version rhq-rtfilter-)が含まれ.jarます。Tomcat 5 サーバーは commons-logging-バージョン.jar ファイルのみを使用しますが、Tomcat 6 サーバーには両方のファイルが必要です。
  3. 適切な JAR ファイルを Tomcat 設定ディレクトリーにコピーします。ディレクトリーの場所は、Tomcat または JBoss インスタンス(組み込み Tomcat の場合)によって異なります。
    たとえば、スタンドアロン Tomcat 5.5 で以下を行います。
    cp commons-logging-version.jar /var/lib/tomcat5/server/lib/
    Tomcat 6 の場合:
    cp rhq-rtfilter-version.jar /var/lib/tomcat6/lib/
    cp commons-logging-version.jar /var/lib/tomcat6/lib/
    たとえば、埋め込み Tomcat インスタンスでは以下のようになります。
    cp rhq-rtfilter-version.jar JBoss_install_dir/server/default/deploy/jboss-web.deployer/
    cp commons-logging-version.jar JBoss_install_dir/server/default/deploy/jboss-web.deployer/
  4. web.xml ファイルを開き、フィルター定義を追加します。ファイルの場所は、サーバーインスタンスや、スタンドアロンサーバーか組み込みサーバーかによって異なります。一般的な場所がいくつか一覧表示され 表21.4「web.xml 設定ファイルの場所」 ます。
  5. Tomcat サーバーに Response Time フィルターを設定するために、<filter> または <filter-mapping> エントリーを追加します。a <filter> または a のどちらかは <filter-mapping> 使用できますが、両方を使用することはでき ません
    最も基本的なフィルター定義は、<filter> 要素の Response Time フィルター名とクラスのみを参照します。これにより、すべてのデフォルト設定で応答時間フィルターが読み込まれます。
    <filter>
            <filter-name>RhqRtFilter </filter-name>
            <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter </filter-class>
    </filter>
    フィルターの定義は、<init-param 要素を追加することでユーザー定義の設定値で拡張できます。これにより、すべてのデフォルト設定で応答時間フィルターが読み込まれます。
    <filter>
            <filter-name>RhqRtFilter </filter-name>
            <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter </filter-class>
            <init-param>
                    <description>Name of vhost mapping file. This properties file must be in the Tomcat process classpath.</description>
                    <param-name>vHostMappingFile</param-name>
                    <param-value>vhost-mappings.properties</param-value>
            </init-param>
    ...
    </filter>
    利用可能なパラメーターはに記載されてい 「parameters for User-Defined <filter>s」 ます。
    監視される URL を照合するために使用する <filter-map> エントリーを設定します。
    <filter-mapping>
            <filter-name>RhqRtFilter </filter-name>
            <url-pattern>/* </url-pattern>
    </filter-mapping>
    注記
    設定されたフィルターの前に Response Time フィルターを付け、応答時間メトリックに他の応答時間の合計合計が含まれるようにします。
  6. Tomcat インスタンスを再起動して、新しい設定を読み込む。
  7. の説明に従って HTTP メトリクスを有効にし 「HTTP 応答時間メトリクスの設定」、JBoss ON はアプリケーションサーバーで応答時間メトリクスをチェックします。

表21.4 web.xml 設定ファイルの場所

Tomcat バージョン 埋め込みサーバータイプ ファイルの場所
Tomcat 6 スタンドアロンサーバー /var/lib/tomcat6/webapps/project/WEB-INF/web.xml
Tomcat 5 スタンドアロンサーバー /var/lib/tomcat5/webapps/project/WEB-INF/web.xml
Tomcat 6 EAP 5 JBOSS_HOME/server/config/deployers/jbossweb.deployer/web.xml
Tomcat 6 JBoss 4.2、JBoss EAP4 JBOSS_HOME/server/config/deploy/jboss-web.deployer/conf/web.xml
Tomcat 5.5 JBoss 4.0.2 JBOSS_HOME/server/config/deploy/jbossweb-tomcat55.sar/conf/web.xml
Tomcat 5.0 JBoss 3.2.6 JBOSS_HOME/server/config/deploy/jbossweb-tomcat50.sar/conf/web.xml
Tomcat 4.1 JBoss 3.2.3 JBOSS_HOME/server/config/deploy/jbossweb-tomcat41.sar/web.xml

21.6.5. HTTP 応答時間メトリクスの設定

応答時間メトリックの設定は、イベントの設定に類似しています。JBoss ON エージェントは Web サーバーが保持する特定のログファイルをポーリングして、Web サーバーが提供する異なるリソースのパフォーマンス時間を特定します。
  1. Web サーバーの応答時間フィルターをインストールします。
    Apache では、フィルターをインストールするだけです。Tomcat の場合は、web.xml ファイルにフィルターエントリーを設定するために追加の設定が必要になります。
    必要な場合は、web.xml ファイルにフィルターエントリーを設定します。を参照してください 「Apache、EWS/Tomcat、および JBoss EAP 5 への応答時間監視の設定」
  2. トップメニューの Inventory タブをクリックします。
  3. 左側の Servers メニューテーブルを選択し、Web アプリケーションに移動し、応答時間監視を実行する Web アプリケーションコンテキストを選択します。
  4. web アプリケーションコンテキストリソースの Connection Settings タブをクリックし、Response Time configuration セクションまでスクロールします。
  5. Web サーバーの応答時間プロパティーを設定します。エージェントは、Web サーバーが応答時間データを記録するのに使用するログファイルを認識する必要があります。
    オプションで、サーバーは収集したデータに対して特定の変換を実行できます。
    • 応答時間ログは、Web サーバーが処理するすべてのリソースの時間を記録します。これには、CSS ファイルやアイコン、背景イメージなどのサポートファイルが含まれます。これらのリソースは、Response Time Url Excludes フィールドの応答時間の計算から除外できます。
    • URL で渡された異なるパラメーターを使用して同じページにアクセスできます。この Response Time Url Transforms フィールドは、渡されたパラメーターのストライピングや置き換えに使用できる正規表現を提供します。
  6. Save ボタンをクリックします。
  7. Web サーバーリソースエントリーの Monitoring タブをクリックします。
  8. Schedules サブタブをクリックします。
  9. HTTP Response Time メトリクスを選択します。このメトリクスは呼び出し時間 タイプ です。
  10. 一覧の Enable 下部にあるをクリックします。

第22章 リソース特性

リソースについて収集される情報のカテゴリーの 1 つは 特性です。特性は説明的な情報で、通常はあまり変更されない情報です。
たとえば、プラットフォームの特性には、オペレーティングシステム名とバージョン、ディストリビューション、そのアーキテクチャー、およびホスト名が含まれます。ほとんどのリソースには、バージョン番号やベンダー情報など、同様の識別情報があります。
特性は間近な情報です。これらは検出可能で、JBoss ON エージェントの監視プロセスによって検出されます。ただし、これらは一般的な説明情報でもあります。特性情報は、リソースの詳細ページにも表示されます。

図22.1 リソースの詳細

リソースの詳細
収集される特性はリソースプラグインで定義されるため、この情報は UI で閲覧可能ではありませんが、設定できません。各リソースタイプの特性の一覧は、「 『リソースリファレンス: Monitoring、Operation、および Configuration Options』 」で説明されています。

22.1. コレクション間隔

デフォルトでは、ほとんどのリソースタイプでは特性は 24 時間ごとにチェックされます。特性は頻繁に変更されないため、頻繁に収集する必要はありません。
特性収集間隔は、メトリクスコレクションの間隔と同じように設定されます。特性のコレクション間隔を変更するには、を参照してください 「特定のリソースのコレクション間隔の設定」

22.2. 特性の表示

リソースの Monitoring タブの Traits サブタブには、以下の 3 つの情報が表示されます。
  • 特性名。リソースに対して監視される特性は、リソースタイプのプラグイン記述子の他の監視設定と定義されます。
  • trait 値。
  • 特性情報の変更が検出された最後のコレクションの時間。

図22.2 特性チャート

特性チャート

22.3. 拡張例: Alerting and Traits

設定

特性情報は静的である傾向があります。特性は変更し、頻繁に行うことができます。また、状態データや動的な測定値ではなく、リソースの説明的な情報を提供する特性であるため、IT 管理者は密接に追跡することが重要ではありません。

ただし、ほとんどのリソースが収集する特性がバージョン情報であるため、管理者はリソース上の一部の設定またはパッケージが変更されたタイミングを管理者が把握できるため、特性情報が役に立つ場合があります。バージョン番号が変更された場合、ベースとなるリソースで一部の更新が発生しています。

操作方法

たとえば、Tim(IT Guy)には、Red Hat Enterprise Linux 開発および QA サーバー向けに自動更新が設定されています。実稼働環境でアプリケーションおよびシステムの更新が制御されているため、それらのサーバーに対する自動更新はありません。

Tim はバージョン変更について通知しますが、必ずしも大きな問題とは限りません。JBoss ON は、Trait Value Change 状態の変更時にアラートを発行できます。(cf 「リソースに対するアラート設定の基本的な手順」..)

図22.3 特性のアラート条件

特性のアラート条件
開発および QA システムのアラートはシンプルです。
  • これは、OR 演算子を使用して 2 つの条件を設定します。アラートは、ディストリビューションバージョンが変更され たり、オペレーティングシステムのバージョンが変更された場合にトリガーされます。これにより、オペレーティングシステムまたはカーネルへのマイナー更新とメジャー更新の両方がキャッチされます。
  • 優先度が低いため、情報的には重要ではありませんが、重要ではありません。
  • Tim はアラート通知が JBoss ON ユーザーに送信されることを判断するため、ログイン時に通知が表示されます。また、優先順位の高いリソースのメール通知を設定することもできます。
Tim の実稼働リソースでは、アラートの優先度を高く設定し、複数の IT 管理者にメール通知を使用して、実稼働システムへの変更をすぐに認識できるようにします。

第23章 監視のための特別な設定が必要なリソース

Web サーバー(Tomcat および Apache リソース)では、これらのリソースを管理および監視するために JBoss ON に追加の設定が必要になります。

23.1. 監視のための Tomcat/EWS サーバーの設定

JBoss Operations Network の監視に Tomcat または Red Hat JBoss Web Server(JWS)を設定する手順は、『 JBoss ON での Red Hat JBoss Web Server のモニタリング』の「 JBoss Web Server のインストールガイド」の章を参照してください。
注記
Tomcat の設定に関する詳細は、Tomcat のドキュメントを参照してください。

23.2. Apache SNMP モジュールの設定

Red Hat JBoss Web Server の仮想ホストを検出し、そのメトリックを収集するには、その Red Hat JBoss Web Server で SNMP モジュールを設定する必要があります。
Apache HTTP Server 2.2 は、Red Hat Enterprise Linux および Windows Server でサポートされています。
重要
JBoss ON を使用して Apache HTTP Server を監視するには、の手順に従う前に SNMP モジュールをコンパイルする必要があり 「Apache HTTP Server で使用する Apache SNMP モジュールの準備」 ます。
SNMP プラグインはすでに JBoss ON 3.3 でインストールされ、有効になっています。また、SNMP モジュールは Red Hat JBoss Web Server 内に事前インストールされています。JBoss ON とのモニタリングに Red Hat JBoss Web Server を設定するには、以下を行います。
  1. 編集する httpd.conf ファイルを開きます。
    $ sudo vim JWS_install_directory/conf/httpd.conf
    
  2. Dynamic Shared Object Support セクションの下にある httpd.conf ファイルにこれらの行を追加して、モジュールを有効にします。
    LoadModule snmpcommon_module JWS_install_directory/modules/snmpcommon.so
    LoadModule snmpagt_module JWS_install_directorymodules/snmpmonagt.so
    		
    SNMPConf   JWS_install_directory/conf
    SNMPVar    JWS_install_directory/var
    
    Windows Server の場合:
    LoadModule snmpcommon_module modules/libsnmpcommon.so
    LoadModule snmpagt_module modules/libsnmpmonagt.so
    		
    SNMPConf   conf
    SNMPVar    var
    
  3. httpd.conf ファイルの主な設定セクションと、各 <VirtualHost> 設定ブロックにポートがある ServerName ディレクティブが含まれていることを確認します。SNMP モジュールはこのディレクティブを使用して、メインサーバーと各仮想ホストを一意に識別するため、各 ServerName ディレクティブに一意の値が含まれている必要があります。例:
    ServerName main.example.com:80
    ...
    		
    <VirtualHost vhost1.example.com:80>
    ServerName vhost1.example.com:80
    ...
    </VirtualHost>
    
  4. 同じマシン上に複数の Apache インスタンスがある場合は、インスタンスごとに異なる SNMP ファイルを使用できます。
    1. 各 Web サーバーインスタンスには独自の httpd.conf ファイルがあります。各ファイルの SNMPConf ディレクトリーを独自の SNMP 設定ディレクトリーに設定します。たとえば、instance1 の場合は以下のようになります。
      $ sudo vim instance1-httpd.conf
      
      SNMPConf /opt/apache-instance1/conf
      次に、たとえば 2 の場合は以下のようになります。
      $ sudo vim instance2-httpd.conf
      
      SNMPConf /opt/apache-instance2/conf
      snmpd.conf ファイルは、指定したディレクトリーに置く必要があります。
    2. JWS_install_directoryagentaddress プロパティーを編集して、各インスタンスの値/conf/snmpd.conf が異なるエージェントアドレスとポートの値を持つようにし、インスタンス間で競合が発生しないようにします。
      このプロパティーの構文の説明は、snmpd.conf ドキュメントを参照してください。
  5. Restart Red Hat JBoss Web Server.
    $ sudo apachectl -k restart
  6. Red Hat JBoss Web Server エラーログを確認して SNMP モジュールがインストールされ、設定されていることを確認します。
    $ grep SNMP JWS_installation_dir/logs/error_log
    
    [Wed Mar 19 09:54:34 2008] [notice] Apache/2.0.63 (Unix) CovalentSNMP/2.3.0 configured -- resuming normal operations
    [Wed Mar 19 09:54:35 2008] [notice] SNMP: CovalentSNMP/2.3.0 started (user '1000' - SNMP address '1610' - pid '26738')
    
JBoss ON ユーザーインターフェースを使用して JBoss ON 監視リソースに HTTP Server を追加するには、Inventory タブを選択して Resources メニューの Discovery Queue 下にある順に選択できるようになりました。

23.2.1. Apache HTTP Server で使用する Apache SNMP モジュールの準備

サポートされるバージョンの Apache HTTP Server(Red Hat JBoss Web Server 2.x 以外の)に SNMP コネクターが必要な場合は、ソースからコンパイルし、インストールする必要があります。
重要
Response Time モジュールを使用するには、Apache サーバーが共有オブジェクトサポートでコンパイルされている必要があります。Red Hat Enterprise Linux システムおよび Red Hat JBoss Web Server サーバーでは、これはデフォルトで有効になっています。
Apache HTTP Server が共有オブジェクトサポートでコンパイルされていることを確認するには、apachectl -l コマンドを使用してコンパイル済みモジュールを一覧表示し、mod_so.c モジュールを探します。
$ sudo apachectl -l
						
	Compiled in modules:
		  core.c
		  prefork.c
		  http_core.c
		  mod_so.c
共有オブジェクトがサポートされる Apache HTTP Server をコンパイルするには、以下の --enable-module=so オプションを使用します。
$ ./configure --enable-module=so
$ make install
  1. Apache コネクターは、にあるソースファイルから Solaris などの他のプラットフォームに対してコンパイルでき connector-apache.zipます。
  2. JBoss ON UI から Apache モジュールのソースファイルをダウンロードします。
    1. JBoss ON UI にログインします。
      https://server.example.com:7080
    2. トップメニューの Administration タブをクリックします。
    3. 左側の Configuration メニューボックスで、Downloads 項目を選択します。
    4. にスクロールし Connector Downloadsconnector-apache.zip リンクをクリックして Apache コネクターをダウンロードします。
    注記
    SNMP モジュールのソースファイルを含む zip ファイルは、を参照してください JON_SERVER_INSTALL_DIR/modules/org/rhq/server-startup/main/deployments/rhq.ear/rhq-downloads/connectors/connector-apache.zip
  3. SNMP モジュールをコンパイルするには、、、perl make automake およびパッケージをインストールする必要があります libtool
    sudo yum install perl make automake libtool
    また、Apache インストールの一部として apxs 使用してください。
  4. Apache コネクターを展開し、ビルドスクリプトを実行します。
    $ sudo unzip connector-apache.zip
    $ sudo cd apache-snmp/sources/
    $ sudo chmod 755 ./build_apache_snmp.sh
    $ sudo ./build_apache_snmp.sh 2.0 [APACHE_INSTALL_DIR/sbin/apxs]
    
  5. 配置 build_apache_snmp.sh されているディレクトリーからモジュールをインストールします。例:
    $ sudo cd snmp_module_#
    $ sudo cp module/* apache_install_directory/modules
    $ sudo cp conf/* apache_install_directory/conf
    $ sudo mkdir apache_install_directory/var
    # は Apache バージョン(2.0 または 2.2 のいずれか)です。
    Windows Server の場合:
    > xcopy /e JON_AGENT_INSTALL_DIR\product_connectors\apache-snmp\binaries\x86
  6. これで、で説明されている Red Hat JBoss Web Server のモジュールの設定プロセスと同じプロセスを使用して Apache SNMP モジュールを設定する準備が整いました 「Apache SNMP モジュールの設定」

23.3. Apache および SNMP でのメトリック収集に関する考慮事項

Apache インスタンスを SNMP モジュールで監視する場合に、3 つのメトリクスでゼロの値が表示されます。
  • GET リクエストごとに受信されたバイト数
  • POST リクエストごとに受信されたバイト数
  • 1 分あたりに受信された合計バイト数
これは、SNMP がリクエスト本文から情報を解釈する方法により生じます。まず、SNMP はリクエストボディーにさまざまな長さの値を提供し、GET リクエストにはボディーがないため、GET 応答は計算されず、値をゼロにします。次に、リクエストチャンクがある場合、Apache はリクエストボディーサイズを計算しません。

第24章 モニタリングデータの保存

JBoss ON のモニタリング情報は、現在の測定値と履歴傾向と平均の両方を示しています。JBoss ON では、データをスケジュールで集計し、圧縮する cascade の種類があります。これにより、モニタリングデータのサイズを減らさずにデータの傾向が維持されます。データは、次のように処理されます。
  • Raw メトリクスは、数分ごとに収集され、1 時間あたりのローリング平均で集計され、最小値、平均、および最大値が生成されます。
  • 1 時間の値は合計され、6 時間の期間に平均されます。
  • 6 時間の期間が、24 時間(1 日)のウィンドウに組み合わされます。

24.1. モニタリングデータのストレージの長さの変更

24.1.1. デフォルトのストレージの長さ

未処理の測定値、1 時間間隔、および 6 時間の期間は、事前定義 された時間用に JBoss ON データベースに保持されます。

表24.1 データのストレージ時間

data 時間の長さ 設定可能またはハードコーディング SQL またはNoSQL データベース
Raw 測定値 7 日 hardcoded NoSQL
1 時間アグリゲート 14 日 hardcoded NoSQL
6 時間アグリゲート 31 days hardcoded NoSQL
24 時間アグリゲート 365 日 hardcoded NoSQL
traits 365 日 設定可能 SQL
可用性データ 365 日 設定可能 SQL
Events データ 14 日 設定可能 SQL
response-time metrics 31 days 設定可能 SQL
注記
raw メトリクスのストレージサイズは、非常に迅速に増大する可能性があります。データベースのサイズやインベントリー全体で収集されるすべてのメトリックの数と頻度を考慮するために、raw メトリックのストレージ時間を調整する場合は注意してください。
長期間生データを保存する必要がある場合は、データベースから生データをエクスポートし、個別にアーカイブすることを検討してください。
注記
収集されたすべてのメトリックは、指定のストレージノードに、NoSQL データベースに保存されます。リソース数や収集されたメトリクスの増加により、クラスターで他のシステムに追加することができます。
その他のすべての監視データ(および JBoss ON によって保存および使用される他のすべてのデータ)は、バックエンド SQL データベースに保存されます。

24.1.2. 異なるモニタリングデータのストレージ時間の変更

  1. Configuration メニューで System Settings 項目を選択します。
  2. Data Manager Configuration Properties セクションまでスクロールします。
  3. 異なるタイプのモニタリングデータのストレージ時間を変更します。
    直接監視データを格納するために関連する 4 つの設定があります。
    • Web サーバーおよび EJB リソースの応答時間データ。これは、デフォルトで 1 カ月(31 日)保持されます。
    • イベント情報(リソースのエージェントによって生成されたすべてのログファイル)。イベントログのデフォルトストレージ時間は 2 週間です。
    • リソースの特性。デフォルトの時間は 1 年間(365 日)です。
    • 可用性情報デフォルトの時間は 1 年間(365 日)です。

24.2. Raw データのエクスポート

Raw 監視データは、デフォルトでは、週ごとにデータベースからパージされます。生データを保存するには、CLI を使用してエクスポートします。
The MeasurementDataManager クラスには、特定のリソースのメトリック値を特定の時間範囲内で検索する方法があります。
findDataForResource(resourceId,[metricId],startTime,endTime,numberOfRecords)
たとえば、ID 10003 およびメトリクス ID が 10473 のリソースの場合:
exporter.file = '/export/metrics/metrics.csv'
exporter.format = 'csv'
var start = new Date() - 8* 3600 * 1000;
var end = new Date()
var data = MeasurementDataManager.findDataForResource(10003,[10473],start,end,60)
exporter.write(data.get(0))

24.3. ストレージノードのデプロイおよび管理

未加工のメトリックデータと集約されたメトリックデータは、専用のスケーラブルな分散データベースに保存されます。JBoss ON サーバーと同様に、クラスター内には複数のストレージノードが存在することがあります(サーバーとは別にインストール)。クラウドからノードを簡単に追加およびドロップできるため、環境のニーズに応じてメトリクスストレージを動的に拡張できます。

24.3.1. High-Speed Metrics Storage

これに進むと 「サーバーパフォーマンスに影響を及ぼす可能性のある影響」、メトリクスを収集し、アラートの生成はリソース集約型になります。これにより、バックエンドデータベース上でのほぼコンスタント書き込み操作が可能になります。これにより、パフォーマンスの低下に遭遇する前に収集できるメトリクスの数の許容しきい値(minute per minute)を作成します。
注記
毎分の メトリクスの許容しきい値は、内部のパフォーマンステストに基づいています。このしきい値は、システムリソースと全体的な負荷によって異なります。
JBoss ON は 2 つのデータベースを使用して情報を保存します。1 つは、JBoss ON サーバーおよびエージェント、すべてのリソースインベントリーデータ、リソース設定、およびその他のデータに関するすべての設定を格納する中央リレーショナルデータベース(PostgreSQL または Oracle)です。他のデータベースは、すべての数値監視データを保存する分散データベース(ストレージノードのクラスター)です。つまり、収集したすべてのメトリクスです。
メトリクスストレージノードは、独自の専用マシンにインストールできます。これにより、データベースに対する書き込みパフォーマンスが大幅に向上します(これにより、モニタリングのパフォーマンスが向上します)。
  • 専用 CPU
  • 利用可能な物理メモリーがさらに必要です。
  • 高速ディスク
  • より多くのディスク領域
これは、JBoss ON サーバーとは別のマシンにリレーショナルデータベースをインストールする場合と同じパフォーマンス上の考慮事項です。2 つのデータベースを使用することで、書き込み集約型のリソース集約型のメトリックストレージをリソース集中型の構成データ(Dributing snapshots やバンドル設定など)から移動することもできます。
さらに、分散データベースは、クラスター内の複数のノードを使用して拡張できます。負荷に応じてノードを追加することは、管理者にとって重要な管理ツールです。1 分あたりに収集される │ メトリックのハードウェア駆動な制限に遭遇する代わりに、パフォーマンスを向上させるために追加のノードを追加できます。
ストレージノードクラスターは JBoss ON によって作成および管理されます(メトリクスストレージノード管理のオーバーヘッドも最小限に抑えられます)。rhqctl install --storage コマンドを使用して、ストレージノードがシステムにインストールされている。ストレージノードには、常にコンパニオンエージェントが必要です。
JBoss ON によって少なくとも 1 つのストレージノードを作成して管理する必要があります(これにより、外部ツールが必要ないため、メトリクスストレージノードの管理オーバーヘッドが最小限に抑えられます)。
メトリクスデータを処理する通信のパスは複数あり、すべて並行して動作します。
  1. エージェントはストレージノード設定を JBoss ON サーバーに送信します。その後、JBoss ON サーバーは更新されたストレージクラスター情報をストレージノードに関連付けられたすべてのエージェントに送信します。
    その後、コンパニオンエージェントは、新しいノードの rhq-storage-auth.confホスト名または IP アドレスでストレージクラスター設定を更新します。(同様に、ノードが削除されると、サーバーは各エージェントに情報を送信し、エージェントはローカルストレージノードの rhq-storage-auth.conf ファイルのリストからホスト名または IP アドレスを削除します)。
  2. サーバーは、(ストレージノードに関連するものだけでなく)すべてのエージェントから監視データを受信し、その情報を利用可能なストレージノードに送信して保存します。
  3. ストレージノードは、高可用性と整合性を確保するために、相互に監視データを複製します。

図24.1 サーバー、エージェント、およびメトリクスストレージノードの通信

サーバー、エージェント、およびメトリクスストレージノードの通信
ノードのクラスター通信には 3 つの要素が必要です。
  • に保管されているすべてのストレージノードのホスト名または IP アドレス rhq-storage-auth.conf
  • JBoss ON サーバーがストレージノード(クライアントポート)との通信に使用する一般的な ポート番号。
  • 相互にデータの同期に使用するクラスター内の他のストレージノード用の共通のポート番号( ゴシップポート
メトリクスストレージは、以下の 2 つの方法でデータのバックアップを作成することで、データの可用性と整合性を提供します。
  • ストレージノード間のデータの複製(ゴシップポート上)
  • ローカルスナップショットの取得およびローカルデータのバックアップ

24.3.2. ストレージノードのデプロイおよびアンデプロイ

JBoss ON 環境に複数のメトリクスストレージデータベースが存在する可能性があります。JBoss ON サーバーと同様に、クラウドで操作でき、複数のストレージノードが相互に通信し、クラスターで機能します。
ノードを管理者がクラスターに追加および削除したり、環境の変更に対応して JBoss ON スクリプトを動的に使用したりできます。
デフォルトのクラスター設定では、ノードが JBoss ON サーバーにインストールおよび設定されるとすぐにデプロイされます。これらは、実際には 2 つの手順です。
  1. ビットはローカルシステムにインストールされ、ストレージノードが JBoss ON サーバーに登録されます。
  2. 新しいノード情報はクラスターにデプロイされます。
環境のプロビジョニングおよびモニタリングの要件により、ノードを自動にデプロイするか、または手動で判断できるかどうか。

24.3.2.1. ストレージノードの要件

ノードをデプロイするには、2 つの重要な要件があります。
  • すべてのストレージノードのホスト名および IP アドレス、JBoss ON サーバーおよびエージェントのホスト名およびバインドアドレスはすべて DNS で完全に解決できる必要があります。ストレージノード、サーバー、またはエージェントの IP アドレスおよびホスト名が DNS で適切にフォーマットされていない場合は、異なる JBoss ON コンポーネント間の通信はすべて失敗します。
  • ファイアウォールは、ストレージノードで使用される 2 つのポートでの通信を許可する必要があります。デフォルトでは、ポートはサーバー/クライアントの 9142 と 7100、ゴシップポートの場合はそれぞれ 9142 と 7100 です。

24.3.2.2. 追加ノードのインストール

新しいストレージノードを作成する際には、ストレージノードとコンパニオンエージェントの 2 つのコンポーネントが常にインストールされます。ノードをセットアップするのに必要な唯一の情報は JBoss ON サーバーの IP アドレスです。エージェントはサーバーに登録してから、ストレージノードのホスト名または IP アドレスを送信します。その後、サーバーは他のエージェント間でその情報を配布し、クラスターに伝播されます。
クラスターがカスタムクライアントおよびゴシップポートを使用している場合は、インストールスクリプトを実行する前に正しいポートで rhq-storage.properties ファイルを編集します。
--agent-preference オプションを指定してインストールスクリプトを実行し、サーバーバインドアドレスを指定します。例:
[root@server ~]# serverRoot/jon-server-3.3.0.GA/bin/rhqctl install --storage --agent-preference="rhq.agent.server.bind-address=0.0.0.0"
注記
Linux にインストールする場合は、root で rhqctl コマンドを実行する必要があります。Windows では、オプションを使用してコマンドプロンプトを開く必要があり Run as Administratorます。
新規ノード情報は既存ノード間で伝播されるため、デプロイメント操作が完了するまで数分かかる場合があります。deploy 操作が完了するまで、ノードには Joining のステータスが表示されます。

図24.2 クラスターの参加

クラスターの参加
警告
ノード一覧をクラスター設定にデプロイし、許可 れるホストはストレージクラスター内のデータにアクセスできます。
許可されたホスト一覧を変更できないように、rhq-storage-auth.conf ファイルへのアクセスを制限して、攻撃者がクラスターおよび保存されたデータにアクセスできるようにします。

24.3.2.3. ノードの手動によるデプロイ

デフォルトでは、新しいストレージノードがインストールされると、自動的にクラスターにデプロイされます。ただし、自動デプロイメントを無効にするクラスター設定があります。これは、マシンがプロビジョニングされ、(仮想環境など)繰り返しオフラインにする場合や、ノードが特定の期間中のみオンラインになる必要がある場合に便利です。
警告
ノード一覧をクラスター設定にデプロイし、許可 れるホストはストレージクラスター内のデータにアクセスできます。
許可されたホスト一覧を変更できないように、rhq-storage-auth.conf ファイルへのアクセスを制限して、攻撃者がクラスターおよび保存されたデータにアクセスできるようにします。
ノードを手動でデプロイするには、以下を実行します。
  1. rhqctl install コマンドを使用してノードをインストールします。
  2. トップナビゲーションバーの Administration タブをクリックします。
  3. 左側の Topology エリアで Storage Nodes 項目を選択します。
  4. Nodes タブで、デプロイするノードの行を選択します。
  5. Deploy ボタンをクリックします。
ストレージノードリソースで Deploy 操作を実行して、ノードをデプロイすることもできます。
注記
ストレージノードは、JBoss ON CLI とスクリプトを使用してデプロイできます。これは、インフラストラクチャーに新しいシステムをプロビジョニングする場合に便利です。
例:
// deploy a storage node 
nodes = StorageNodeManager.findStorageNodesByCriteria(StorageNodeCriteria()); 
node = nodes.get(0); StorageNodeManager.deployStorageNode(node);
これは、インフラストラクチャーの要求に応じてストレージノードを動的に追加する際にキーとなることができます。ノードを事前にインストールしてから、必要に応じてホットデプロイおよび削除することができます。

24.3.2.4. ノードの削除

ストレージノードをアンデプロイすると、クラスターからリソースが削除され、インベントリーからリソースが削除され、ストレージノードのビットがマシンからアンインストールされます。
  1. トップナビゲーションバーの Administration タブをクリックします。
  2. 左側の Topology エリアで Storage Nodes 項目を選択します。
  3. Nodes タブで、削除するノードの行を選択します。複数の行を選択するには、Ctrl キーを保持し、希望の行をクリックします。
  4. Undeploy Selected ボタンをクリックして操作を確認します。
また、ストレージノードリソースで Undeploy 操作を実行してノードを削除することもできます。
注記
ストレージノードは、JBoss ON CLI およびスクリプトを使用して削除することもできます。これは、インフラストラクチャーからシステムのプロビジョニングおよび削除を行う場合に便利です。
例:
// undeploy a storage node 
nodes = StorageNodeManager.findStorageNodesByCriteria(StorageNodeCriteria()); 
node = nodes.get(0); StorageNodeManager.undeployStorageNode(node);

第25章 アラートの定義

25.1. アラートのプランニング

アラート とは、管理者がリソースに発生したことを管理者が通知する構成です。状態と通知は、リソースの アラート定義 で一緒に設定されます。
アラート定義には、主に 3 つのコンポーネントがあります。

25.1.1. 4 つの質問におけるアラートストラテジー

アラートは基本的なことであり、IT インフラストラクチャーで行われていることについて即座に通知することができます。アラートは複雑なシナリオや詳細な応答も定義できるため、管理者はリソース内の問題に自動的に、プロアクティブに対応できます。
環境、管理プロセス、およびプランに応じて、どちらのアプローチも同じように有効かつ同様に便利です。簡単で複雑なアラートのプランニングに少し努力すると、全体的な管理が非常に容易になります。

25.1.1.1. What's the Condition?

これは、判断すべき最も重要な点です。確認したいイベント
アラート定義には 1 つの条件または複数の条件を含めることができ、これらの条件は 1 つのみが true であるか、またはすべてが true の場合にのみアラートをトリガーできます。最も簡単なことの 1 つは、報告する必要のあるシナリオを説明し、後方操作して、そのシナリオに最も適した条件または条件セットを判断することです。
アラートは、(変更があった)非常に一般的なか、または非常に具体的なものにすることができます。一般的な条件はより詳しい情報です。非常に特殊な条件により、非常に特殊な応答が可能となります。つまり、管理者が確認および介入するまで、詳細かつ有用な応答を自動化できます。
設定可能なアラート定義の数には、妥当なパフォーマンス制約を除き、制限はありません。単純なメトリクス値の変更のために通知を送信するアラートが 1 つある可能性が高くなります。また、一連のアラートは、異なるメトリクスに関連するメトリクスの変更などを確認し、他の要素に関連する特定の JBoss ON CLI スクリプトを実行します。

25.1.1.2. What's the Frequency?

複数の監視スキャンで状態が発生し、再帰する可能性があります。同じ状態を通知する必要のある回数。
考慮すべき多くの要因があります。どのタイプの応答が行われるか、保持する必要のある監査証跡、一般的な状態である可能性、条件が存在する期間などです。
アラート定義の要因には、ネットワークルールや、アラート設定の無効化/修復など、送信される通知の数をスロットリングします。
注意すべき点として、アラート通知は、JBoss ON サーバーがアラートのトリガー時に実行するすべての応答であることを認識します。これは、電子メールを送信したり、UI にメッセージを投稿したり、CLI スクリプトを実行したり、操作を開始したりすることができます。
一般的には、優先順位が低いアラートはおそらく単一の通知で十分であるため、おそらく単一の通知で十分であるため、スパム化や無効化のルールを設定して、電子メールを使用したスパム化や最近のアラートポートレットのフラッドを防ぐことができます。
頻繁に発生する問題、重大な障害、または優先度の高いリソースについては、アラート通知の頻度は、実行する必要のあるアクションによって異なります。情報アラートは条件が持続するに従って送信される可能性がありますが、CLI スクリプトの実行などの積極的な応答を持つアラートは 1 回のみ実行し、無効にして同じスクリプトを繰り返し実行しないようにできます。

25.1.1.3. What's the Response to take?

アラートへの応答には、即時応答と長期的な軽減策の 2 つのフェーズがあります。
リソース上の特定の条件またはイベントについてのアラートが発生したら、最も最初に発生するべきことは何ですか?管理者にメールがあるか?JBoss ON サーバーがリソースを管理するために何らかのアクションを実行する必要がありますか?JBoss ON は SNMP トラップをサポートするため、SNMP 通知を外部監査/監視アプリケーションに送信するか。
条件と同様に、アラートの発生時に送信できる通知の数に制限はありません。JBoss ON が管理者にメールし、リソースを再起動すると、複数の応答が妥当になる場合があります。
操作と CLI スクリプトを使用すると、管理者は応答を自動化できます。特にビジネスクリティカルなシステムの場合、JBoss ON は管理者が問題に認識する前にすぐに対応できます。
(JBoss ON または管理者によって)即座にアクションが発生したら、管理者は警告を承認でき、基本的には拒否されます。最後のステップは、管理者がアラートを確認し、その原因を特定し、解決策を探したことを示す重要な手順になります。
JBoss ON タスクとしてだけでなく、実際のイベントについて確認およびサインアウトする方法があり、IT 問題を処理し、全体的なメンテナンスストラテジーを改善するための信頼できる手順を確立します。

25.1.1.4. 数多くのリソースがこの影響を及ぼすか?

アラート定義は、個別のリソース、互換性のあるリソースのグループ、またはリソースタイプ全体に対して設定できます。
複数のリソースに同じ定義を適用できるため、複雑な定義の管理が簡単であるために便利です。
注記
リソースタイプのアラートテンプレートは、そのタイプの既存のリソースおよび新規リソースすべてに自動的に適用されます。
ただし、同じタイプの異なるリソースをアラートする必要があるかどうかについて認識してください。たとえば、実稼働サーバーでは、非常に高レベルのレポート、メトリクスの監視、および自動応答が必要になります。QA または開発サーバーで必要となるのは、スクリプトや高度な応答がほとんどない一般的なアラート情報のみです。実稼働システムで収集されるメトリクスの数、頻度、およびメトリクスのタイプは、QE または開発システムで収集されるものとは異なる可能性があり、アラート定義に使用できる条件に影響を及ぼします。
グループ化はアセットです。Qe、development、staging、および production リソースは、それぞれに適切な監視およびアラートのレベルを設定して、異なるグループに分類できます。

25.1.2. リソースに対するアラート設定の基本的な手順

注記
アラートの状態やアラート通知の設定後には編集できません。アラート定義の条件または通知を変更するには、条件または通知を削除し、新規のアラートを作成します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. 一覧のリソース名をクリックします。
  4. リソースの Alerts タブをクリックします。
  5. Definitions サブタブで New ボタンをクリックして新しいアラートを作成します。
  6. General Properties タブで、アラートに関する基本情報を指定します。
    • 名前。特定のアラート定義の名前を指定します。これはリソースに対して一意である必要があります。
    • 説明。アラートのオプションの説明が含まれます。これは、同じリソースに対してさまざまな種類のアラート応答をトリガーする場合に非常に便利です。
    • priority。この定義によってトリガーされるアラートに提供される優先度または重大度を設定します。
    • Enabledアラート定義がアクティブであるかどうかを設定します。アラート定義を無効にして、リソースにネットワークの停止や定期的なメンテナンスウィンドウがある場合などに不必要で、誤ったアラートを防ぎます。
  7. Conditions タブで、アラートをトリガーするメトリクスまたは課題を設定します。Add ボタンをクリックして条件フォームを表示します。
    注記
    アラートをトリガーするために複数の条件が設定されている可能性があります。たとえば、CPU の CPU が 25% を超え、利用可能なメモリーが 25MB を下回る場合にのみ サーバーの通知を受け取ることができます。条件の ALL 設定では、両方の基準が満たされる場合にのみアラート通知が通知に限定されます。いずれかの状況を把握して、ネットワークの負荷分散設定を即時に変更することができます。この場合、1 つの条件 ANY しきい値が満たされるとすぐに通知が出力されます。
    1. Add a new condition ボタンをクリックします。
    2. 初期ドロップダウンメニューから、条件のタイプを選択します。条件のカテゴリーと 「アラートの調整の理由」、すべてのリソースに設定できる正確な条件は、『Resource Monitoring Reference』 に一覧表示されます。
    3. 条件の値を設定します。
  8. Notifications タブで Add をクリックし、アラートの通知を設定します。
    1. Sender オプションでアラート通知を送信するために使用するメソッドを選択します。
      Sender オプションは、最初に特定のタイプのアラートメソッド(電子メールや SNMP など)を設定し、適切なフォームを開いてその方法の詳細を入力します。
    2. アラート送信メソッドに必要な情報を入力します。この方法では、選択した内容に応じて、連絡先、SNMP 設定、操作、またはスクリプトが必要になる場合があります。
  9. Recovery タブで、リソースの状態が復旧するまでアラートを無効にするかどうかを設定します。必要に応じて、このアラートの発生時に別のアラートを選択し(またはリカバリー)。
    リカバリーアラートは無効なアラートを取得し、再度有効にします。これは、可用性がダウンしてからバックアップされるタイミングを示すアラートのペアなど、状態の変更を示す 2 つのアラートに使用されます。
  10. Dampening タブで、同じアラートイベントの通知を送信する頻度について、細分化(または頻度)ルールを付けます。
    アラートを送信する頻度は、リソースの想定される動作によって異なります。アラートの送信が多すぎる場合と、数が多いアラートを送信するには、バランスが必要です。周波数の設定は複数あります。
    • 連続 している。条件がメトリック計算のために特定の回数で発生する場合にアラートを送信します。たとえば、これが 3 に設定される場合、アラートを発生させるには、3 つの連続するメトリクスコレクション期間で条件を検出する必要があります。これが 1 に設定されている場合は、条件が発生するたびにアラートを送信します。
    • 最後の N 評価これは、アラートを送信する前に、特定の数のモニタリング評価サイクルで条件が発生する回数を設定します。
    • 期間。他の 2 つの破損ルールは、JBoss ON のモニタリングサイクルに基づいて再帰を設定しました。これにより、特定の期間に基づいてアラートルールが設定されます。
  11. OK をクリックし、アラート定義を保存します。

25.1.3. アラート定義の有効化および無効化

アラート定義が無効の場合、その一連の条件についてのアラート通知はトリガーされません。定義を無効にすると、リソース(アップグレードやメンテナンスなど)がオフラインにされ、その間にトリガーされるアラートが間違っている場合に非常に便利です。アラートの定義は後で簡単に再度有効にできます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. Alerts タブをクリックします。
  4. Definitions サブタブで、いずれかの定義を選択して有効または無効にします。
  5. Enable または Disable ボタンをクリックします。
  6. アクションを確認します。

25.1.4. グループアラートおよびアラートテンプレート

ほとんどのアラートは、同じタイプの複数のリソースに対して一貫して定義できます。そのためには、JBoss ON の 2 つの方法があります。
  • アラートテンプレート
  • 互換性のあるグループのアラート
アラートテンプレートは、JBoss ON サーバーの設定です。アラートは、特定のリソースタイプに対して設定されます(そのタイプのリソースがインベントリーにまだ存在していない場合も含む)。リソースが追加されると、JBoss ON 設定のアラートテンプレートがそのリソースに自動的に適用されます。アラートテンプレートは、ローカルの変更を可能にするように設定できます(例: リソース A には異なるベースラインや予想される動作があるため、アラートの状態を変更することができます)。テンプレートは厳密に実施できるため、そのタイプのすべてのリソースに全く同じ設定が含まれるようにします。
注記
リソースタイプのアラートテンプレートは、そのタイプの既存のリソースおよび新規リソース すべて に自動的に適用されます。これは、テンプレートの編集時に選択解除され、変更が新しいリソースにのみ適用されるようにできます。
アラートは互換性のあるグループに設定できます。アラートテンプレートと同様に、互換性のあるグループのアラート定義は、グループメンバーの残りの部分に複雑になります。リソースがグループに追加されると、アラートは自動的にリソースに追加されます。グループからリソースが削除されると、アラートは自動的に削除されます。グループアラートは、手動グループと動的グループの両方で機能します。アラートテンプレートと同様に、グループアラートはローカルの変更を許可したり、グループのアラート設定を適用したりできます。
テンプレートを使用すると、設定が一貫して頻繁に適用され、JBoss ON では一般的なリソースタイプに基づいてアラートにテンプレートを設定できます。
アラートテンプレートなどのグループアラートは、互換性のあるグループのすべてのメンバーに同等に適用されます。ただし、検索フィルターに基づいてリソースに手動で、または選択できるため、グループアラートはアラート定義を持つリソースをより細かく制御できます。リソースがグループに参加または退出すると、アラート定義が自動的に更新されます。

25.1.4.1. アラート定義テンプレートの作成

アラートテンプレートは、JBoss ON の管理対象リソースタイプ向けに作成される、条件から通知メソッドまで、完全に定義されたアラート定義です。同じタイプのサーバーまたはアプリケーションには、空きメモリーや CPU 使用率など、適用されるアラート条件と同じセットがあります。アラート定義テンプレートは、リソースの一般タイプ に基づいてアラートを作成します。そのため、Windows、Linux、および Solaris サーバー、Tomcat サーバー、Apache サーバー、sshd や cron などのサービスに関するアラートテンプレートを使用できます。対象のリソースが追加されるたびに、事前に定義された設定でアラート定義がリソースに自動的に追加されます。テンプレートを使用してリソースに割り当てられたアラートは、そのリソースに対してローカルで編集できるため、これらのアラート定義は柔軟かつカスタマイズ可能です。
注記
リソースタイプのアラートテンプレートは、そのタイプの既存のリソースおよび新規リソース すべて に自動的に適用されます。これは、テンプレートの編集時に選択解除され、変更が新しいリソースにのみ適用されるようにできます。
アラート定義テンプレートを作成するには、以下を実行します。
  1. トップナビゲーションでメニューを開き、Administration Configuration メニューを開きます。
  2. Alert Templates メニュー項目を選択します。これにより、プラットフォームおよびサーバータイプ両方のリソースタイプが長いリストが開きます。
  3. テンプレート定義を作成するリソースのタイプを見つけます。
  4. New ボタンをクリックしてグローバルアラート定義を作成します。アラートを単一のリソースのアラートを設定する場合と全く同じように設定します(を参照 「リソースに対するアラート設定の基本的な手順」)。
  5. テンプレートを保存します。
その後、テンプレートの定義は、そのタイプの現在および新規リソースすべてに適用されます。

25.1.4.2. グループアラートの設定

グループアラートは、互換性のあるグループにのみ設定できます。
  1. トップメニューの Inventory タブで、Groups 左側のメニューの Compatible Groups 項目を選択します。
  2. メインウィンドウでグループを選択し、アラートを追加します。
  3. グループの Alerts タブをクリックします。
  4. Definitions サブタブで、New ボタンをクリックします。
  5. にあるように、基本的なアラート定義および通知を設定し 「リソースに対するアラート設定の基本的な手順」 ます。

25.2. アラート条件

監視(19章メトリックおよび測定値)はより大きなワークフローでアラートに密接に関連付けられ、管理者がネットワーク内で何が起きているかを認識させるようにします。アラートは 条件 に基づいて、アラートを発行すべきシグナルです。
条件は、非常に簡単です。A の場合、B を実行する場合や、アラートの開始前に複数の条件または読み取りの組み合わせと共に複雑になる可能性があります。

25.2.1. アラートの調整の理由

この 条件 は、特定のしきい値を超えるリソースの状況、イベント、またはレベルです。基本的に、条件はリソースの「正常な」動作またはパフォーマンスにパラメーターを設定します。この境界を超えると、JBoss ON はアラートを発行します。これは、望ましくないレベル、イベント、または繰り返し発生するメトリック読み取りに変更したメトリクスの値になります。
アラート定義を使用したアラートは、個別のリソースまたはリソースの互換性のあるグループに対して定義されます。アラート定義は、アラートをトリガーする条件と、トリガーする必要のある通知のタイプおよび設定を指定します。
アラートが登録されると、アラートはトリガーされたアラート定義(アラート状態を識別する)と、アラートの事前処理を行うメトリクスまたはイベント値を特定します。
アラート条件は、What、who および where の 4 つの質問 回答します。アラート トリガーするしきい値または 条件 です(たとえば、空きメモリーが特定の時点を下回る)。定義された組み込まれた ルール を使用してアラートを送信する頻度またはタイミングを設定する 場合。また、管理者にアラートの 通知 方法を制御する ユーザー および 場所
1 つの条件でアラートを発行できる場合や、アラート定義では、複数の条件が同時に満たされる場合にのみアラートを発行する必要があります。これにより、アラートの発行時に非常に粒度の細かい制御が可能になり、アラート情報がより重要かつ適切なものになります。
条件は、に一覧表示されている検出可能な監視またはシステムメトリックを基にでき 「アラートの調整の理由」 ます。これらのアラート条件は、そのタイプのリソースで利用可能なモニタリングメトリクスに直接対応します。各リソースタイプに使用できるすべてのメトリクスは、「リソースモニタリングリファレンス」に一覧表示さ 『れます』。

表25.1 アラート条件のタイプ

条件のタイプ description
メトリクス 確認される特定の監視エリアと、応答をトリガーするその領域のしきい値。通常、メトリクスは何らかの数値の応答です(CPU の使用率、要求数、またはキャッシュヒット比率など)。
trait 特定の設定の値の変更。特性は通常文字列の値です。
可用性 このリソースが利用できるかどうかが突然変更されています。
operation リソースで実行される特定のアクションまたはタスク。
イベント 特定のタイプのエラーメッセージが記録されます。イベントはシステムまたはアプリケーションのログファイルからフィルターされ、JBoss ON で認識されるイベントのタイプは、リソースのイベント設定によって異なります。
drift 事前定義された設定からリソースが変更されました。

25.2.2. 詳細なディスカッション: 条件のある Ranges、AND、および OR 演算子

アラートは、監視情報に基づきます。これは、管理者が通知を受け取るか、特定のイベントまたはメトリクスの値が発生した場合に実行するアクションを定義するエクステンションです。
アラートをトリガーするモニタリングポイントはアラート状態です。最も分かりやすく、アラート状態は単一のイベントまたは読み取りです。X が発生した場合は、アラートがトリガーされます。
実際、X はアラートを保証するほど不十分な場合や、リソースの状態を適切に記述できない場合があります。異なる条件で同じ応答が必要となる場合や、複数の条件が true の場合のみ重要となる場合があります。アラートは、これらの条件間で確立された関係で複数の条件を定義できるため、柔軟性が非常に高くなります。
次のレベルの複雑さは、X または Y のいずれかが true の場合にアラートを送信することです。アラート定義では、これは論理 OR の ANY オプションです。アラート定義はこれらの条件のいずれかをチェックしますが、それらの条件は相互に関連しません。
最後の複雑さのレベルは、アラートの発行のために条件が相互に関連する必要がある場合です。これは、論理 AND である ALL オプションです。アラートを発行するには、X と Y の両方が必要です。この場合、ある条件が発生すると、サーバーはその定義をロックし、2 つ目の条件が発生するまで待機を開始します。2 つ目の条件が発生すると、アラートが発行されます。
AND 演算子は異なるメトリクスに対して非常に有効ですが、条件が同時に発生する必要がないため、単純な AND 演算子は 同じ メトリクスに意味を持ちません。
たとえば、Tim(IT 管理者)では、ユーザーの負荷が │ から 60% の間にある場合に限りアラートの発行を希望します。これは、プラットフォームの負荷をわずかに増やすことを示します。AND 演算子の使用を試みると、負荷が │(上記の │ 条件を 3 回)上で増加し、15% にフォールバックすると、(以下の 60% 条件未満の 60% 条件がトリガー)にフォールバックすると、異常値が返されます。
この場合、Tim は range 条件を使用します。範囲には、指定された境界内にある同じメトリクスの 2 つの値が必要です。範囲には、内部の値(40 ~ 60%)を指定するか、または外部範囲(low └ および 60%)を指定できます。

図25.1 アラート条件の範囲

アラート条件の範囲

25.2.3. 詳細なディスカッション: ログファイルメッセージに基づく条件

イベント(20章イベント)はフィルターされたログメッセージです。JBoss ON の特定のリソースは、プラットフォームや JBoss EAP サーバーなどのエラーログを維持します。JBoss ON では、これらのエラーログをスキャンして、特定のパターンに一致する特定の重大度またはイベントのイベントを検出できます。これにより、JBoss ON の管理者は、重要なエラーメッセージを特定し、表示できます。
JBoss ON はログイベントを検出できるため、JBoss ON はログイベントをアラートできます。イベントベースの状況には、ログファイルメッセージの重大度と、オプションで特定のメッセージと照合するために使用するパターンが必要です。

図25.2 ログファイルの条件

ログファイルの条件
重大度が「重大」のイベントに重大度を設定するアラートのみを設定します。これは、致命的なエラーや致命的なエラーに役に立ち、これは比較的頻度がないため、すぐに注意を促す必要があります。
注記
一般的なエラーメッセージでは、パターンを使用して特定のエラータイプをフィルターします。次に、リソース操作または CLI スクリプトを使用して、リソースの再起動や新しい Web アプリケーションの起動など、特定のエラーに対応するための特定のアクションを実行します。

25.2.4. 詳細ディスカッション: フレームワーク

依存関係はアラート状態を定義しませんが、JBoss ON サーバーに対して定期的な条件の処理方法を指示します。
アラートは、条件が満たされるたびにアラートを発行するか、管理者が承認するまでアラートを発行して無効にすることができます。状態 を破損させると、継続中の単一の状況に対して、複数のアラートおよび通知が送信されるのを防ぐのに役立ちます。

図25.3 Dampening Filter

Dampening Filter
たとえば、Tim(IT Guy)は、プラットフォーム CPU の使用率が 50% を超えるかどうかをユーザーに通知するためにアラートを設定します。監視スキャンが実行されるたびに、メトリクスは再び true と判断され、新規インスタンスおよび個別インスタンスとして処理されます。メトリクススケジュールが 10 分間設定され、アラートに応答するのに 1 時間かかる場合、応答する前に 6 つまたは 7 つのアラート通知がある可能性があります。アラート応答のみがメールである場合、これは問題ではありません。
しかし、Tim(Tim)の IT Guy に、EAP 接続数が特定の時点よりも大きい場合に新しい JBoss サーバーを作成するアラート応答がある場合に、実際に 1 回実行すべき場合は、同じ応答が 6 回または 7 回取得され、条件が実際に解決されます。
依存関係は、別のアラートをトリガーする前に条件を評価する方法についてのもう 1 つの命令セットです。これは、これらのモニタリングデータを解釈する方法を JBoss ON に指示します。
  • JBoss ON は、条件が発生するたびにアラートを送信できます。この場合、CPU のパーセンテージがバウンスした場合に複数のアラートが発行されますが、これに一時的にヒットまたはヒットした場合にアラートが送信されるのは 1 つのアラートだけです。
  • JBoss ON は、条件が連続して、または Y 回のポーリング数の X 回数で発生した場合にのみアラートを送信できます。この場合、繰り返しまたは持続された問題のみがアラートをトリガーします。通知を出力するには不十分です。
    状態は、問題になるために短期間に複数回発生する必要がある場合がありますが、一度は問題ではありません。たとえば、サーバーが数分で 7 つの CPU から 80% までの CPU をバウンスする可能性があり、数秒で 1 分の 1 に達する可能性があります。あるいは、8 分の 1 に達する可能性があり、そこに留まる可能性があります。この条件は、CPU のヒット率 20% が残り、他の読み取りは無視されます。
  • 設定した期間内に問題が発生した場合にのみ通知が送信されます。これは、繰り返し発生する問題の頻度を追跡したり、状態が持続する期間を追跡するのに便利です。
注記
ハイフンは、変数で何らかの基準と比較されるメトリクスにのみ関係します。しきい値および値の変更のあるメトリクスの監視は動的であるため、各読み取りは以前の読み取りと一致しても実際の状態になります。次に、複数の同様の読み取りを制御します。
ステータス変更と直接関係する条件は、自身をベースラインと比較するのではなく、以前の状態としか比較しません。たとえば、ドリフトテンプレートからシステム設定を変更した場合や、可用性が変更した場合は 1 回限りの変更になります。その後、リソースのステータスは新しい状態になり、今後の変更が新しいステータスと比較されるため、ある意味が異なる条件となります。
ハイフンは、ドリフトと可用性の変更に概念的には適用されません。

25.2.5. 詳細なディスカッション: アラートの自動無効化およびリカバリー

同じ確認された状態に対してアラート通知が送信される頻度を制限するには、いくつかの方法があります。1 つの方法では、破損したルールがあります。別の方法として、アラートの初回起動時にアラートを無効にし、管理者が手動で実行するか、または 条件自体がリセットされた場合にのみアラートを再度有効にします。2 番目のオプション - 無効にしてからリセットする - アラートを回復します。
リカバリーアラートは 、実際には、条件の変更時に関連するアラートを無効にし、有効にするために調整を行うアラートのペアです。
いくつかのワークフローは、復旧アラートで一般的に使用されます。
  • アラートのペアは、相互トグルスイッチとして機能します。あるアラートがアクティブな場合、もう 1 つは無効になります。Alert A が起動すると、指定した Alert B をリカバリーするように設定できます。したがって、Alert B は基本的にその代わりに使用されます。
  • アラートは CAScade の種類として機能します。Alert A が起動すると、Alert B が有効になり、Alert C が有効になります。場合によっては、特定の状態が問題にならない可能性がありますが、短期間に連続して発生すると問題になります。

図25.4 アラートの無効化およびリカバリー

アラートの無効化およびリカバリー
たとえば、Alert A は、リソースの可用性がダウンするとアラートをトリガーします。Alert A が発生すると、それ自体が無効(または有効化)されます。Alert B は、リソースの可用性が起動するとアラートを出力します。Alert B も実行すると、それ自体を無効にし、A を復旧します。
リカバリーアラートは、問題が発生してから、解決時に管理者に通知します。可用性の例では、最初のアラートにより、管理者はリソースがオフラインであることを確認できますが、2 つ目のアラートにより、そのリソースがオンラインに戻ることを管理者が通知します。

Setup: Toggle Recover Alerts for Availability

Tim(IT 管理者)には、電子メールのルーティングやその他のオペレーションに使用する複数のサーバーがあり、バックアップとして予約している複数のマシンがあります。

プライマリーメールサーバー mail-server-a.example.com があり、オフライン時のみ mail-server-b.example.com オンラインにしたいだけです。その後、戻るときには予約の mail-server-a 状態に戻したいと考え mail-server-a ます。

The Plan

Tim は、メールサーバー間の移行を処理するため、アラート定義のセットを作成します。

  • mail-server-a プラットフォームの可用性の状態が ダウンすると、最初のアラート定義が 実行されます。
    この通知は、以下の点をいくつか行います。
    • 最新のメールサーバー設定でバンドルを別のプラットフォームにデプロイする mail-server-b
    • コマンドラインスクリプトを実行し、メールサービス mail-server-b を起動します。
    • Email Tim the IT Guy to know that mail-server-a is unavailable.
    リカバリーでは、アラートは以下の 2 つの処理を行います。
    • 現在のアラートを無効にします。バックアップサーバーをオンラインにするには、一度だけ起動する必要があります。
    • JBoss ON がバックアップを待機するよう mail-server-a に、アラート B を回復(または有効化)します。
  • 2 つ目のアラート定義 Alert B は、mail-server-a がオフライン時 にのみ有効です。このアラートは、可用性の状態 mail-server-b 変更されるとすぐに実行されます。
    • このアラート定義は、基本的にダウンして mail-server-a いる限り待機します。オンラインに mail-server-a 戻ると、Alert B の通知は、メールサービスを停止する mail-server-b ためのコマンドラインスクリプトの実行です。
    • アラート B は、Tim the IT Guy に通知メールを送信し、再び mail-server-a 利用できることを通知します。
    リカバリーでは、アラートは以下の 2 つの処理を行います。
    • 現在のアラートを無効にします。Alert A と同様に、Alert B は、プライマリーサーバーが復元するとすぐにバックアップを停止する必要があります。
    • アラート A をリカバリー(または有効化)するので、JBoss ON は再びダウン mail-server-a するまで待機します。

25.3. アラートへの対応

アラート条件は、アラートがトリガーされる タイミング を定義します。アラート通知は、アラート通知の通信 方法 を定義します。アラート通知は、管理者およびユーザーに状況を知らせる方法になりますが、JBoss ON 自体が問題に対処する方法である可能性もあります。
単一のアラートには複数の応答があり、潜在的な問題の管理が容易になります。
重要
アラート通知は、アラート定義に追加された後に編集できません。アラート通知を変更するには、元の通知を削除して、希望の設定で新しい通知を作成します。

25.3.1. 管理者への通知およびアラートへの応答

すべてのアラートは JBoss ON GUI で記録され、表示できます。ただし、アラートには、アラートの発行時に外部通知を送信するオプションの設定があります。
インシデントが発生したら、システム管理者に問題に対応させる手段が必要です。これは、通知 を設定して行います。アラート通知は、アラートの通信方法とアラートに対する対応アクションという 2 つのカテゴリーに分類されます。
デフォルトでは、アラートが発生したことを通知する方法は 3 つあります。
  • 1 つ以上のアドレスへの電子メール
  • SNMP トラップ
  • JBoss ON ユーザーへのメッセージ
JBoss ON がアラートに応答するデフォルトの方法もいくつかあります。
  • リソース操作(アラートリソースまたはインベントリー内の他のリソース上)の実行
  • リソーススクリプトの実行(特定タイプのリソース操作)
  • JBoss ON CLI スクリプト
注記
サーバー側のプラグインとして実装されるカスタムアラートメソッドを作成することもできます。カスタムプラグインの作成については、『JBoss Operations Network Plug-ins Writing Guide を参照してください』。
アラート通知は クラスター化 できます。つまり、同じアラートが同時に複数の異なる方法でブロードキャストできることを意味します。たとえば、公開 Web サイトがダウンした場合、ある会社では通知をユーザーのヘッド Web 管理者に送信し、Web サーバーを同時に再起動させることができます。
注記
1 つのアラートは複数の通知を開始できます。アラート通知は、アラート定義に一覧表示される順序で実行されます。

25.3.2. 詳細なディスカッション: 操作の開始

アラートへの並列応答は、操作 を開始することです。リソース操作(メトリクスなど)は、トリガーされたアラートに応じて通知などの起動されるリソースタイプエージェントプラグインで実行されます。アラート操作は、アラートを発行したリソース、またはインベントリー内の他のリソースで実行することができます。これにより、アラート条件に対する即時の自動応答が可能になります。たとえば、JVM がメモリー不足であるため、JBoss サーバーが不適切な実行を開始することがあります。JVM はアラートを発行するリソースですが、エージェントによる応答は JBoss サーバーを再起動することです。
特定のアラート条件が発生すると、リソースで操作を開始することで JBoss ON エージェントが応答できます。これはアラート定義設定の一部ですが、アラートへの応答を管理するのに便利です。アラートが発生するたびに、エージェントはサーバーを再起動するなど、何らかのアクションを実行できます。これは、アラートを発行したリソースまたは別のリソースで実行できます。
リモート操作は、非常に便利な(および汎用性)を超えることができます。たとえば、JVM がメモリー不足であるため、JBoss サーバーが不適切な実行を開始することがあります。JVM はアラートを発行するリソースですが、エージェントによる応答は JBoss サーバーを再起動することです。
通常の操作は、即座に開始するか、特定の設定リソースの定義されたスケジュールで実行されます。アラート操作は、以下の 2 つの理由により通常の操作よりも柔軟性があります。
  • アラート操作は、すべてのアラートまたはイベントに対応するために応答的に実行されます。
  • アラート操作は、JBoss ON インベントリーの 任意 のリソースで開始できます。アラート操作は、アラートを送信したリソースのみに限定されます。つまり、同じホストサーバーで、または全く異なるサーバーでも、異なるアプリケーションに対して操作を実行できます。
アラートに対して実行される操作は、リソースで実行するようにスケジュールできる操作と同じです。アラートに使用できる操作は、操作が実行されるターゲットリソースによって異なります。アラートが設定されているリソースではありません。
アラート操作送信者は、リモートリソースでスクリプトを実行できます。たとえば、リソースがダウンした場合、親プラットフォームで診断スクリプトを実行でき、別のリソースがオンラインになり、適切に実行するように設定できます。

25.3.2.1. アラート操作でのトークンの使用

アラート操作は、トークンを使用してイベントに関する情報を送信するか、またはイベントに関する情報を提供できます。たとえば、トークンを使用して、コマンドラインスクリプトにリソース情報を提供できます。
アラート操作は、トークンを受け入れ、特定の値を自動的に入力できます。これらのトークンの形式は以下のとおりです。
<%space.param_name%>
この 領域 は、値が派生する JBoss ON 設定エリアを提供します。これは一般的に、alert またはのいずれかになり resourceます。param_name は、指定されているエントリー値を指定します。たとえば、特定の発生するアラートの URL を参照する場合、トークンはリソース名をプル <%alert.url%>する場合に、トークンはになり <%resource.name%>ます。
JBoss ON には、起動されたアラートに関連する事前定義済みのトークン値、アラートを発行したリソース、オペレーションのターゲットであるリソース、および操作が開始された操作に関する事前定義済みのトークン値があります。これらはに記載されてい 表25.2「利用可能なアラート操作トークン」 ます。これらの潜在的なトークン値はすべて Java プロパティーで、オペレーションの親 JBoss ON サーバーに属します。
アラート操作プラグインは、アラート操作が処理されて値を見つける際にトークンの値自体を解決します。この値はスクリプトサービスに送信され、最終的にその値をコマンドラインの引数またはスクリプトにプラグインし、トークンを参照したスクリプトにプラグインします。

表25.2 利用可能なアラート操作トークン

... に関する情報 token description
Started Alert alert.willBeDisabled アラート定義は、起動後に無効にするか。
Started Alert alert.id この特定アラートの ID
Started Alert alert.url アラートの詳細ページの URL
Started Alert alert.name 定義するアラート定義の名前
Started Alert alert.priority このアラートの優先度
Started Alert alert.description このアラートの説明
Started Alert alert.firedAt アラートの発生時間
Started Alert alert.conditions このアラートの原因となった条件のテキスト表現
アラートリソース resource.id リソースの ID
アラートリソース resource.platformType リソースが有効なプラットフォームのタイプ
アラートリソース resource.platformName リソースが置かれているプラットフォームの名前
アラートリソース resource.typeName リソースタイプ名
アラートリソース resource.name リソースの名前
アラートリソース resource.platformId リソースが有効なプラットフォームの ID
アラートリソース resource.parentName 親リソースの名前
アラートリソース resource.parentId 親リソースの ID
アラートリソース resource.typeId リソースタイプ id
ターゲットリソース targetResource.parentId ターゲットの親リソースの ID
ターゲットリソース targetResource.platformName ターゲットリソースがオンになっているプラットフォームの名前
ターゲットリソース targetResource.platformId ターゲットリソースがオンになっているプラットフォームの ID
ターゲットリソース targetResource.parentName ターゲットの親リソースの名前
ターゲットリソース targetResource.typeId ターゲットリソース ID のリソースタイプ
ターゲットリソース targetResource.platformType ターゲットリソースがオンになっているプラットフォームのタイプ
ターゲットリソース targetResource.name ターゲットリソースの名前
ターゲットリソース targetResource.id ターゲットリソースの ID
ターゲットリソース targetResource.typeName ターゲットリソースのリソースタイプ名
operation operation.id 実行された操作の ID
operation operation.name 操作が実行された名前

25.3.2.2. アラート操作の設定

注記
1 つのアラートは複数の操作を開始できます。すべてのアラート操作は、すべてのアラート通知と同様に、アラート定義に一覧表示される順序で実行されます。
Notifications タブには Resource Operations メソッドがあります。

図25.5 送信元

送信元
操作には 2 つの部分があります。最初に、操作を実行するリソースを選択します。リソースタイプは、利用可能な操作を決定します。
デフォルトは、アラートが設定されているリソースで、別の特定のリソースや検索の結果に設定することもできます。

図25.6 リソースの選択

リソースの選択
重要
相対 リソースを選択し、特定のリソース名を入力し ない 場合、操作は相対パスでそのリソースタイプに一致する すべて のリソースで実行されます。一致するリソースがない場合は、監査証跡にログインしてアラートプロセスが続行します。
相対リソースでは、リソース名は必要ありません。特定のリソースでは、になります。
2 つ目の半分は操作タイプを選択します。使用できる操作と設定パラメーターは、操作のターゲットとして選択されるリソースの種類によって異なります。

図25.7 操作の設定

操作の設定

25.3.3. 詳細なディスカッション: リソーススクリプトの開始

シェルや bat スクリプトなどのスクリプトは JBoss ON インベントリーにインポートでき、リソース(「新規リソースの手動によるインポート」)として管理できます。このスクリプトには、起動スクリプト、設定スクリプト、または診断スクリプトを含めることができます。
で説明されているように 「アラート操作の設定」、アラート通知はリソース(アラートをトリガーしたリソースとは異なるリソースも含む)で操作を実行できます。特定の使用方法のシナリオでは、リソーススクリプトを操作として実行します。
注記
スクリプトをリソースにアップロードし、アラート操作で使用する前に JBoss ON インベントリーに追加する必要があります。これは、で説明してい 「新規リソースの手動によるインポート」 ます。
リソーススクリプトの実行は、操作の実行と同じです。リソーススクリプトは操作のリソースとして選択され、スクリプトの start または restart 操作が設定され、必要に応じてスクリプトに渡すコマンドライン引数がすべて設定されます。

図25.8 リソーススクリプト設定

リソーススクリプト設定
重要
相対 リソースを選択し、name filter フィールドに特定のスクリプト名を入力し ない 場合、コマンド引数を使用して相対パスにある すべて のスクリプトリソースで操作が実行されます。一致するスクリプトがない場合は、監査証跡にログインしてアラートプロセスが続行します。
相対リソースでは、リソース名は必要ありません。特定のリソースでは、になります。スクリプトの実行を単一の特定のスクリプトに制限するには、特定のリソースオプションを選択し、一覧から正確なスクリプトを選択します。

25.3.4. 詳細ディスカッション: アラートからの JBoss ON CLI スクリプトの起動

JBoss ON には、Web UI がサーバーを管理するのと同じ方法でサーバーインスタンスを管理するために使用できる独自のコマンドラインクライアントがあります。アラート条件に対応してスクリプトリソースの実行や操作を開始するのと同様に、サーバー CLI スクリプトはアラート状態に対して実行できます。

25.3.4.1. CLI スクリプト通知の使用に関する注意事項

CLI スクリプトがコンテンツである

リソーススクリプトとは異なり、CLI スクリプトはインベントリーのリソースとして扱われません。これらのツールは、JBoss ON サーバー自体が利用でき、(指定リソースには限定されず、関連付けるものではありません)。

サーバー CLI スクリプトを実行するには、リポジトリー内のコンテンツとしてサーバーにアップロードする必要があります。

CLI スクリプトおよびリモート API

CLI スクリプトは、サーバーで操作を実行するには適切な API を使用する必要があります。JBoss ON には、実行するタスクに応じて複数の異なる API セットがあります。サーバーに接続し、スクリプトを実行するには、サーバーでコマンドをリモートで実行できる リモーティング API が必要です。

CLI スクリプトでのアラートオブジェクトの参照

CLI スクリプトは、事前定義された アラート 変数を使用してスクリプトをトリガーするアラートオブジェクトのアラートオブジェクトを参照できます。

この alert 変数は、アラート定義と発生する特定のアラートインスタンスを暗黙的に識別します。これにより、そのアラートスクリプトを使用するリソースに適用できるスクリプトにプロキシーリソース定義を作成できます。
var myResource = ProxyFactory.getResource(alert.alertDefinition.resource.id)
リソース ID は起動されたアラートからプルされ、スクリプトはそこからリソースを参照できます。

CLI スクリプトの制限

リソース自体には、CLI スクリプトを実行できる場所や実行できる操作に制限が生じる場合があります。たとえば、セキュリティー上の理由から、CLI スクリプトはローカルリソース(CLI スクリプトを実行しているサーバーでルックアップを実行する)で JNDI ルックアップを実行できませんが、リモート JNDI ルックアップを実行できます。もう 1 つの一般的な問題は、JBoss ON サーバーがそれ自体で再起動操作を実行できないことです。

CLI スクリプトをアラート応答として使用する場合は、潜在的なセキュリティーへの影響やリソースの制約に注意してください。

25.3.4.2. アラート関連の CLI スクリプトの作成

サーバー側のスクリプトは、強力かつ多用途のスクリプトです。サーバー機能や、リソース、グループ、またはその他のオブジェクトにほぼすべてのサーバーに影響を及ぼすことができ、一連のコマンドを実行できます。この汎用性により、CLI スクリプトはプロアクティブな方法でアラートに応答するのに非常に便利ですが、アラートが特定の条件で通知するように計画され、スクリプトがその特定の状況に応答するように設計される必要があります。
つまり、アラートを固有にし、CLI スクリプトに関連するものにします。
このスクリプトは、Web アプリケーションの最近の監視統計を確認し、接続に問題がある場合は Web サーバーデータベースを再起動します。
var myResource = ProxyFactory.getResource(alert.alertDefinition.resource.id)

var definitionCriteria = new MeasurementDefinitionCriteria()
definitionCriteria.addFilterDisplayName('Sessions created per Minute')
definitionCriteria.addFilterResourceTypeId(myResource.resourceType.id)

var definitions = MeasumentDefinitionManager.findMeasurementDefinitionsByCriteria(definitionCriteria)

if (definitions.empty) {
   throw new java.lang.Exception("Could not get 'Sessions created per Minute' metric on resource "
      + myResource.id)
}

var definition = definitions.get(0)

var startDate = new Date() - 8 * 3600 * 1000 //8 hrs in milliseconds
var endDate = new Date()

var data = MeasurementDataManager.findDataForResource(myResource.id, [ definition.id ], startDate, endDate, 60)

exporter.setTarget('csv', '/the/output/folder/for/my/metrics/' + endDate + '.csv')

exporter.write(data.get(0))

var dataSource = ProxyFactory.getResource(10411)

connectionTest = dataSource.testConnection()

if (connectionTest == null || connectionTest.get('result').booleanValue == false) {
    //ok, this means we had problems connecting to the database
    //let's suppose there's an executable bash script somewhere on the server that
    //the admins use to restart the database
    java.lang.Runtime.getRuntime().exec('/somewhere/on/the/server/restart-database.sh')
}
JBoss ON CLI のコマンド、オプション、および変数は、「 JBoss ON のコマンドラインスクリプト 」に記載されています
アラートスクリプトのサンプルは、serverInstallDir のサーバーファイルに含まれてい ます/alert-scripts/

25.3.4.3. CLI スクリプト通知の設定

  1. スクリプトをコンテンツリポジトリーにアップロードします。
    注記
    アラート CLI スクリプト用に個別のリポジトリーを作成します。
  2. リソースを検索し、にあるように基本アラート定義を設定し 「リソースに対するアラート設定の基本的な手順」 ます。
  3. アラート定義の Notifications タブで、通知メソッドに名前を付け、Alert Senders ドロップダウンメニューから CLI Script メソッドを選択します。
  4. まず、スクリプトを実行するときに JBoss ON ユーザーを選択します。デフォルトは、通知を作成するユーザーです。
  5. CLI スクリプトが含まれるリポジトリーを選択します。新しいスクリプトをアップロードする場合は、スクリプトを追加するリポジトリーです。
  6. ドロップダウンメニューから使用する CLI スクリプトを選択します。指定したリポジトリーのすべてのスクリプトが一覧表示されます。Upload ボタンをクリックして、ローカルマシンのスクリプトを参照します。
  7. OK をクリックし、通知を保存します。Notifications タブ内の行には、スクリプト、リポジトリー、および実行されるユーザーが表示されます。

25.3.5. 通知用の SNMP の設定

SNMP アラートを送信するよう JBoss ON を設定するには、以下の 2 つの部分があります。
  • サーバーの SNMP アラートプラグインの設定。
  • SNMP 通知を使用して実際のアラートを設定する。

25.3.5.1. JBoss ON SNMP 情報

JBoss ON は、アラート通知の一部として SNMP トラップを他の管理用システムに送信することができます。送信されたデータには、トリガーされたアラート名やリソース名など、アラートに関する詳細が含まれます。
他の SNMP 通知と同様にトラップに含まれるデータは、serverRoot の JBoss ON MIB ファイルで定義され ます/etc/RHQ-mib.txt。MIB のデフォルト設定がに表示され 例25.1「JBoss ON MIB のデフォルトのアラートオブジェクト」 ます。JBoss ON アラートのベース OID は 1.3.6.1.4.1.18016.2.1 (org.dod.internet.private.enterprise.jboss.rhq.alert)です。

例25.1 JBoss ON MIB のデフォルトのアラートオブジェクト

--internet(1.3.6.1) 
+--private(4) 
| +--enterprises(1) 
| +--jboss(18016) 
| +--rhq(2) 
| +--alert(1) 
| | +-- r-n DisplayString alertName(1) 
| | +-- r-n DisplayString alertResourceName(2) 
| | +-- r-n DisplayString alertPlatformName(3) 
| | +-- r-n DisplayString alertCondition(4) 
| | +-- r-n DisplayString alertSeverity(5) 
| | +-- r-n DisplayString alertUrl(6) 
| | +-- r-n DisplayString alertHierarchy(7) 
| +--alertNotifications(2) 
| | +--alertNotifPrefix(0) 
| | +--alertNotification(1) [alertName,alertResourceName,alertPlatformName,alertCondition,alertSeverity,alertUrl,alertHierarchy] 
| +--rhqServer(3) 
+--snmpV2(6) 
+--snmpModules(3) 
+--rhqMIB(1) 
+--rhqTraps(3) 
+--rhqTrapPrefix(0)
注記
デフォルトの MIB ファイルでは、各トラップはアラート定義名、リソース名、プラットフォーム、アラート条件、重大度、および URL をアラートの詳細ページに送信します。変換された MIB を表示するには、MIB の場所を SNMP トラップサーバーに渡すことができます。たとえば、NetSNMP を使用します。
[root@server ~]# snmptrapd -m RHQ-MIB -M/opt/local/share/mibs/ietf
-M では、SNMP サーバーの MIB ディレクトリーへのパスを指定します。
この場合、アラート通知は以下のようなトラップに記録されます。
Jul 8 15:13:31 snert snmptrapd[42372]: 127.0.0.1: Enterprise Specific Trap (.0) Uptime: 0:00:00.00, RHQ-MIB::alertName = STRING: test, RHQ-MIB::alertResourceName = STRING: snert, RHQ-MIB::alertPlatformName = STRING: snert, RHQ-MIB::alertCondition = STRING: 
- Condition 1: Free Memory < 1.024,0MB 
- Date/Time: 2013/07/08 15:13:05 MESZ 
- Details: 12,9MB 
, RHQ-MIB::alertSeverity = STRING: medium, RHQ-MIB::alertUrl = STRING: http://localhost:7080/coregui/CoreGUI.html#Resource/10001/Alerts/History/12204, RHQ-MIB::alertHierarchy = STRING: snert
の出力はで tcpdump、同じ行すべてに似ています。
22:06:19.043208 IP localhost.56445 > localhost.snmptrap: Trap(352) E:18016.2.3 0.0.0.0 enterpriseSpecific s=0 0 E:18016.2.1.1="test" E:18016.2.1.2="snert" E:18016.2.1.3="snert" E:18016.2.1.4="^J- Condition 1: Free Memory < 4,0GB^J- Date/Time: 2013/07/10 22:06:01 MESZ^J - Details: 179,2MB^J" E:18016.2.1.5="medium" E:18016.2.1.6="http://localhost:7080/coregui/CoreGUI.html#Resource/10001/Alerts/History/10038" E:18016.2.1.7="snert"

25.3.5.2. SNMP アラートプラグインの設定

SNMP アラート送信プラグインは、通知方法を使用する前に追加の設定を必要とする唯一のアラート通知プラグインです。SNMP プラグインは、適切な SNMP バージョンと SNMP エージェント情報で設定する必要があります。
  1. トップメニューで、Administration タブを選択します。
  2. System Configuration メニューで ServerPlugins 項目を選択します。
  3. リスト内の SNMP プラグインの名前をクリックします。
  4. プラグインの詳細ページで Plugin Configuration セクションを展開します。
  5. 必要な SNMP 設定を入力します。
    • 適切な SNMP バージョンを選択します。
    • SNMP トラップサーバーのホスト名、ポート番号、およびトランスポートプロトコルを指定します。デフォルトの設定は、JBoss ON サーバーおよびポート 162 の localhost を参照します。
    • トラップ OID を設定します。これはデフォルトでは RHQ OID です。
    • SNMP 1 および 2 の場合コミュニティーに名前を付けます。
    注記
    これにより、SNMP アラート通知のグローバルデフォルトが設定されます。アラート定義の作成時に、個別のアラート通知に異なる設定を指定することができます。
  6. SNMP バージョン 1 およびバージョン 3 には、表25.3「SNMP v1 構成設定」 およびに記載されている追加設定が必要です 表25.4「SNMP v3 構成設定」。バージョン固有の設定セクションを展開し、SNMP エージェントに関する情報を入力します。
    フィールドを編集するには、チェックボックスの選択を Unset 解除する必要がある場合があります。

表25.3 SNMP v1 構成設定

フィールド description
汎用 ID トラップの ID。SNMP 標準は 0-6 の数字を定義します。6 は企業固有を意味します。これはデフォルトです。
Enterprise OID JBoss ON サーバー自体の OID。デフォルト値は RHQ MIB から SMIv2.enterprise.jboss.rhq.rhqServer として取得されます
特定の OID トラップ通知で使用するカスタム OID。これは空にすることができます。
エージェントアドレス アラート送信者の IP アドレス(JBoss ON サーバーの IP アドレス)。

表25.4 SNMP v3 構成設定

フィールド description
Auth プロトコル 認証要求の暗号化アルゴリズム。これを設定するには、対応する認証パスフレーズを設定する必要があります。パスフレーズがない場合、この値はである必要があり noneます。
プライバシープロトコル トラップメッセージで使用する暗号化方法を設定します。これは認証プロocol に使用されます。
エンジン ID
ターゲットコンテキスト名
認証パスフレーズ 認証に使用されるパスワードを設定します。最小長は 8 文字です。これは、Auth Protocol 値が設定されている場合に必要になります。
プライバシーパスフレーズ 暗号化通信の管理に使用するパスワードを設定します。これは、認証が使用される場合に必要になります。
セキュリティー名 トラップレシーバーへの認証に使用するユーザー名を指定します。

25.3.5.3. SNMP アラート通知の設定

JBoss ON が SNMP 通知を送信する前に、サーバーに SNMP トラップを設定する必要があります。
アラートを設定する場合は、SNMP Trap 通知タイプを選択し、JBoss ON SNMP 情報を入力します。

図25.9 JBoss ON SNMP トレース情報

JBoss ON SNMP トレース情報
  • SNMP マネージャーのホスト名。これが設定されていない場合、グローバル設定のデフォルトが使用されます。
  • SNMP マネージャーのポート番号。これが設定されていない場合、グローバル設定のデフォルトが使用されます。
  • 変数バインディングのプレフィックス。オプション。これにより、指定の文字列がトラップによって送信される個々の変数の先頭に追加されます。これは、トラップを送信する JBoss ON サーバー、リソース、またはアラートを識別する方法になります。デフォルトは RHQ MIB で設定され SMIv2.enterprise.jboss.rhq.alertます。
  • トラップ OID。これは、トラップ定義で使用する特定の OID です。これが設定されていない場合、グローバル設定のデフォルトが使用されます。デフォルトでは、これは RHQ-MIB です 1.3.6.1.4.1.18016.2.1

25.4. アラートデータの表示

アラート通知がトリガーされると、JBoss ON はそのアラート履歴にリソースの アラート履歴 を記録します。履歴には、アラートの送信時間と、トリガーした状態が含まれます。重要な点として、JBoss ON はアラートが承認されたかどうかを示し、それが発生した場合はどのユーザーに対処したかを示します。
監視とアラートは連携して、管理者がリソースに関する問題を即座に認識できるようにしますが、アラート履歴はリソースのパフォーマンス IT スタッフの応答に多くのビューを提供します。これまでにどのアラートがトリガーされているかを把握し、時折、原因分析、インシデント応答、およびメンテナンスポリシーの支援を行えます。

25.4.1. アラート定義レポートの表示

特定のリソースのアラート定義は、そのリソースエントリーを表示することで常に利用できますが、アラート定義レポートで JBoss ON で設定されたすべてのアラート定義を表示することもできます。
  1. トップナビゲーションバーの Reports タブを選択します。
  2. 左側の Subsystems メニューボックスで、を選択し Alert Definitionsます。
  3. 定義レポートには、インベントリー内のすべてのリソースに設定されたすべての定義の一覧が表示されます。
    結果表は、定義に最も基本的な情報を提供します。
    • リソース(Name)。
    • 親または ancestry。リソースが階層的に編成されるため、親はサーバーのようなハイレベルリソースに関連するすべてのサービスとアプリケーションのアラート定義をすべて検索する際に非常に便利です。
    • アラートの説明。
    • アクティブ(有効)であるかどうか。
注記
アラート定義を作成および編集するための書き込みが必要ですが、ユーザーがアラート履歴からアイテムを削除する権限があるわけではありません。
履歴内の要素を削除するには、インベントリーの管理パーミッションが必要です。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ alertDefinitions.csvます。

25.4.2. アラートの表示

アラート履歴は、リソース、リソースのグループ、親、または JBoss ON サーバー全体について確認できます。

25.4.2.1. 特定リソースのアラート詳細の表示

注記
ユーザーはアラート定義を作成および編集できますが、ユーザーがアラート履歴からアイテムを削除する権限があるわけではありません。
履歴内の要素を削除するには、インベントリーの管理パーミッションが必要です。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  3. リスト内のリソースをクリックします。
  4. タブをクリックし、History サブ Alerts タブが選択されていることを確認します。
  5. 一覧で、発生するアラートのタイムスタンプまたはアラート定義名をクリックします。
  6. アラートページには、アラートの詳細に関するタブがあります。これには、トリガーされたアラート定義、トリガーされた状態、結果として起動された操作が含まれます。

25.4.2.2. Fired Alerts レポートの表示

  1. トップナビゲーションバーの Reports タブを選択します。
  2. 左側の Subsystems メニューボックスで、を選択し Recent Alertsます。
JBoss ON のすべてのリソースのアラートはすべて結果テーブルに一覧表示されます。分析に役立つ要素がいくつかあります。
  • リソース(Name)
  • 親(ancestor)
  • アラートをトリガーした定義の名前
  • アラートを発生させた条件
  • アラートの送信時のリソースの値
  • 日付: アラート通知を外部イベントと関連付ける際に役立ちます。
注記
アラート定義を作成および編集するための書き込みが必要ですが、ユーザーがアラート履歴からアイテムを削除する権限があるわけではありません。
履歴内の要素を削除するには、インベントリーの管理パーミッションが必要です。
注記
レポートは CSV にエクスポートできます。これは、オフィスシステムや他のデータ操作に使用できます。
レポートをエクスポートするには、Export ボタンをクリックするだけです。レポートはのように自動的にダウンロードされ recentAlerts.csvます。

25.4.2.3. Dashboard でのアラートの表示

デフォルトでは、最近送信されたアラートはすべて、最近のアラートポートレットの JBoss ON の Dashboard ページにリストされます。

図25.10 最近のアラートポートレット

最近のアラートポートレット
ポートレットに表示されるアラートは、さまざまな条件に対してフィルターできます。
  • アラートが発生した時点の時間範囲
  • アラートの Name 内のサブ文字列
  • アラートの優先度(アラート定義で最初に設定される)
これらの条件は 順番 に評価され、論理結合(AND)として適用されます。つまり、アラートは時間、名前、優先度、およびすべてのフィルター条件に基づいて最初にフィルターされます。
Dashboard ページのアラートポートレットの条件を設定するには、以下を実行します。
  1. トップメニューでをクリックし Dashboardます。
  2. Recent Alerts ポートレットで歯車アイコンをクリックして、ポートレット設定ページを開きます。
  3. 必要に応じて表示基準を変更します。
注記
フィルター設定はダッシュボードに永続化され、セッション全体で維持されます。アラートが Recent Alerts ポートレットに期待どおりに表示されない場合は、フィルター設定を確認してください。

25.4.3. アラートの承認

アラートの承認は、アラートをトリガーした状態が何らかの方法で対処されたことを識別する方法です。アラートが承認されると、アラートを承認したユーザーの名前が記録されます。確認応答者の名前を記録すると、必要に応じてアクションを後で監査できます。
アラートを確認する方法は複数あります。
  • Recent Alerts レポート経由
  • グループ経由
  • リソースエントリー経由
Recent Alerts Report を使用すると、一度に複数のアラートを確認でき、複数のリソースタイプについて確認できるので便利です。アラートの承認はアラートを閉じる必要がありませんが、インシデント応答を監査する場合や、問題が対処されたことを確認するために有用です。
  1. トップナビゲーションバーの Reports タブを選択します。
  2. 左側の Subsystems メニューボックスで、を選択し Recent Alertsます。
  3. 確認応答するアラートを選択します。
  4. Acknowledge ボタンをクリックし、プロンプトが表示されたらアクションを確認します。
注記
アラートの詳細ページで単一のアラートを確認することもできます。
アラートが承認されると、はアラートを承認(およびおそらく解決)したユーザーの名前を Status 表示します。

図25.11 アラートの承認

アラートの承認

パート IV. アプリケーションとコンテンツのデプロイ

第26章 サマリー: JBoss ON を使用したアプリケーションのデプロイおよびコンテンツの更新

JBoss Operations Network のコア管理ツールの 1 つは、管理対象リソースからコンテンツを作成、更新、または削除することです。コンテンツ は、テキストファイル、JAR、EAR、WAR、パッチ、XML ファイルなどのバイナリーファイルなど、リソースや設定に関連するものをすべて使用できます。このコンテンツは、管理されたリソースにデプロイして、そのリソースの設定を更新したり、子リソースを作成したり、または全く新しいアプリケーションをデプロイしたりできます。
リソースのコンテンツを管理する方法は 2 つあります。
  • タブを介したリソースレベルの Content コンテンツ
  • バンドルを使用したアプリケーションのプロビジョニング
リソースレベルのコンテンツにより、特定の管理リソース(通常は JBoss アプリケーションサーバーまたは Web サーバー)を名前付きリポジトリーに保存およびバージョン管理されたパッケージに関連付けることができます。これらのパッケージは JBoss ON にアップロードできるため(基本的に JBoss ON はコンテンツリポジトリー)、外部リポジトリーからプルでき、エージェントプラグインを介して検出することもできます。つまり、リソースレベルのコンテンツ管理が実行できるアクションは 3 つあります。
  • リソースにパッケージ、更新、およびパッチを提供できます。
  • リソースにコンテンツをデプロイしたり、新しい子リソースを作成したりすることもできます。これは、異なるコンテキストを子として持つことができる Web やアプリケーションサーバーで特に役に立ちます。
  • リソースにインストールされた現在のパッケージを検出し、管理者がそのアセットの管理に使用できるパッケージダイジェストを作成できます。
リソースレベルのコンテンツ管理は、リソースの作成に使用できる範囲に制限されます。そのため、JBoss ON にはコンテンツをデプロイする別のシステムがあり、このシステムでは完全なアプリケーションサーバーをデプロイしたり、複数のリソース間でコンテンツを一貫して適用したりできます( バンドルを介したプロビジョニング )。
バンドルは JBoss ON サーバーに追加されるため、バンドルは単一のリソースに制限されません。これらは、プラットフォームまたは JBoss サーバー(またはプラグイン記述子でバンドルターゲットを定義する他のリソースタイプ)のいずれかの互換性のあるリソースグループにデプロイされます。これにより、同じコンテンツを使用して、複数のリソースを一度に更新できます。
バンドルプロビジョニングでは、より柔軟で複雑なデプロイメントオプションも使用できます。
  • Ant 呼び出しを使用してバンドルのデプロイ前後の操作を実行します。
  • ユーザー定義の値を許可するか、バンドルがプロビジョニングされるときに設定に編集できるようにします。
  • 複数のバージョンのコンテンツバンドルがデプロイされ、deployable がリソースに同時にデプロイされている。
  • 以前のバンドルバージョンに戻す

第27章 バンドルへのコンテンツおよびアプリケーションのデプロイ

27.1. コンテンツバンドルのプロビジョニングの概要

プロビジョニングは、管理者が開発から実稼働環境までアプリケーションを定義し、制御できる方法です。プロビジョニングシステムの影響は、アプリケーションのデプロイ方法を単純化することです。管理者は、同じアプリケーション定義( バンドル定義)内で、異なるコンテンツソースから異なるリソースにデプロイされるアプリケーションのバージョンを制御できます。リソースを別のバージョンに戻すことも、デプロイメントを進めることもできます。
プロビジョニング は 1 つのファイルセット(バンドル)を取得し、これをプラットフォームまたはアプリケーションサーバー(宛先)にプッシュします。コンテンツ、宛先、およびデプロイメントのルールを定義するより複雑な方法がありますが、プロビジョニングがコンテンツを処理する際のコアとなる方法は、バージョンが付けられたバンドルを取り、これを指定されたリソースに送信する方法です。
プロビジョニングは、個別のリソースではなく、互換性のあるグループと連携します。管理者は、さまざまな環境に基づいてグループを定義し、すべてのグループメンバーにアプリケーションの変更(アップグレード、新規デプロイメント、または変換)を同時に適用できます。
また、デプロイ可能なコンテンツのタイプは柔軟です。バンドルには、raw 設定ファイル、スクリプト、ZIP アーカイブ、JAR ファイル、または完全なアプリケーションサーバーを含めることができます。コンテンツ の定義は非常に緩やかです。
これは、JBoss ON のリソースレベルのコンテンツ管理とは異なります。コンテンツのタイプは比較的制限されています。パッチまたは設定はリソースごとに適用されます。新しいアプリケーションは、既存リソースの子としてのみデプロイでき、別のリソースタイプである必要があります。
プロビジョニングは、純粋なリソース 管理ではなく、アプリケーション管理 に重点を置いています。

27.1.1. バンドル: コンテンツおよびレシピ

バンドル は、アーカイブにパッケージ化されるコンテンツのセットです。実際、バンドルは通常アプリケーションですが、アプリケーションまたはリソースの設定に必要な設定ファイル、スクリプト、ライブラリー、またはその他のコンテンツを含めることもできます。
バンドルの目的は、定義されたコンテンツのセットを取り、JBoss ON がリモートリソースにコピーすることです。プロビジョニングプロセスは基本的にターゲットリソースでアプリケーションをビルドするため、バンドルはアプリケーションディストリビューションです。各バンドルバージョンには、JBoss ON に、バンドルに存在するファイル、デプロイメントの実際の値を必要とする トークン、およびリモートマシン上のバンドルおよび既存ファイルの処理方法が通知される独自の レシピ があります。
レシピ、設定ファイル、およびコンテンツはすべてバンドルにまとめてパッケージ化されます。これは通常、プロビジョニング中にエージェントが展開する ZIP ファイルです。
JBoss ON で管理される他のコンテンツと同様に、バンドルはバージョン管理されます。異なるバージョンを異なるリソースにデプロイできます。このリソースは、異なる環境でさまざまなアプリケーションストリームを処理するのに適したものです(例: QA および実稼働環境)。また、バージョンバンドルを使用すると、JBoss ON はバンドルを簡単に元に戻すか、またはアップグレードできます。
バンドルにはほぼすべてのコンテンツを含めることができますが、JBoss ON によって適切にデプロイされるように特定の構造に従う必要があります。レシピは呼び出された Ant ビルドファイルです deploy.xml。これは常にバンドルアーカイブの最上位に置く必要があります。
レシピの配置以降、バンドル内のファイルやディレクトリーはアーカイブのどこにでも配置できます。実際、ファイルは必ずしもバンドルファイルに組み込まれる必要がありません。バンドルの作成時には、バンドルのファイルまたはすべてのファイルを URL からプルできます。これにより、コンテンツが SVN または GIT リポジトリー、FTP サーバー、または Web サイトから取得できるようになります。

図27.1 バンドルレイアウト

バンドルレイアウト
バンドルアーカイブには、JAR、WAR、ZIP ファイルなどの他のアーカイブを含めることができます。プロビジョニングは Ant を使用してターゲットマシンにバンドルをビルドするため、Ant がバンドルの一部として処理できるファイルをすべて処理できます。Ant プロビジョニングシステムは WAR、JAR、および ZIP アーカイブファイルを処理できます。

27.1.2. 宛先(およびバンドルデプロイメント)

バンドルを JBoss ON にアップロードしてもバンドルはどこにもプッシュされないため、自動的にリソースまたはグループとは関連付けられません。(コンテンツとは異なり、バンドルはリソースに依存しません。JBoss ON では、インベントリーとは別に独自の定義として存在します。 バンドルが実際にプロビジョニングされる場合、プロビジョニングウィザードにより、管理者が 宛先 を定義するように求められます。
宛先は、バンドルがデプロイされる場所です。宛先は、3 つの要素の組み合わせです。
  • 互換性のあるリソースグループ(プラットフォームまたは JBoss サーバーのいずれか)
  • ベースの場所。バンドルのデプロイに使用するルートディレクトリー。リソースプラグインは、<bundle-target> 要素内の特定のリソースタイプのベースの場所を定義します。これは、ルートディレクトリーや、プロファイルディレクトリーなどの共通のディレクトリーである JBoss サーバーになります。利用可能なベースの場所が複数ある可能性があります。
  • deployment ディレクトリー。バンドルのコンテンツが実際に送信されるベースディレクトリー下のサブディレクトリーです。
たとえば、管理者は deploy/myApp/ ディレクトリー内の JBoss EAP 5 サーバーに web アプリケーションをデプロイします。JBoss AS5 プラグインは、インストールディレクトリー用と profile ディレクトリー用のベースの場所を 2 つ定義します。アプリケーションは展開形式の JAR ファイルであるため、管理者はプロファイルディレクトリーを選択します。次にエージェントは、これらの 3 つの要素からアプリケーションの実際の絶対パスを取得します。
JBoss AS group + {$PROFILE_DIR} + deploy/myApp/
PROFILE_DIR がの場合 /opt/jbossas/default/server/、宛先は以下のようになります。
/opt/jbossas/default/server/deploy/myApp/
同じリソースグループに Windows サーバーで実行されている JBoss EAP インスタンスが含まれる場合、PROFILE_DIR を持つパスは C:\jbossas\server\、プラットフォームに適したパスが若干異なります。
C:\jbossas\default\server\deploy\myApp
エージェントは、そのインベントリーのプラットフォームおよびリソース情報に基づいて作成され、バンドルをデプロイする宛先の絶対パスを決定します。
バンドルが実際に宛先にデプロイされると、その関連付け(バンドルバージョンおよび宛先)がバンドルデプロイメントになり ます。

図27.2 バンドル、バージョン、および宛先

バンドル、バージョン、および宛先

27.1.3. プロビジョニング中のファイル処理

デプロイメントにおける動作

バンドルファイルには、リソースにプッシュする必要があるファイルおよびディレクトリーのセットが含まれます。ただし、プロビジョニングプロセスでは、単にファイルをデプロイメントディレクトリーにコピーする訳ではありません。プロビジョニングはバンドルを、基本的にターゲット(root)ディレクトリーのコンテンツ構造全体を定義するテンプレートとして扱います。

たとえば、バンドルには以下のファイルが含まれます。
app.conf
lib/myapp.jar
root ディレクトリーがの場合 deploy/myApp/、最終的な設定は以下のようになります。
deploy/myApp/app.conf
deploy/myApp/lib/myapp.jar
デフォルトでは、ファイルにファイルがある場合は deploy/myApp/、バンドルがコピーされる前に削除されます。これにより、デプロイメントディレクトリーはバンドルの設定方法が完全に表示されます。
のようなアプリケーション固有の宛先では、定義されたアプリケーションコンテンツがそのディレクトリーにある唯一のコンテンツであるため deploy/myApp/、この動作は完全に許可されます。ただし、バンドルにはさまざまなコンテンツを含めることができ、ほぼプラットフォームや JBoss サーバー内にデプロイできます。実際のインフラストラクチャーの多くは、バンドルがデプロイされるディレクトリーには既存のデータを保持する必要がある場合があります。
deployment ディレクトリーはバンドルの ルートディレクトリー です。バンドルのレシピは、プロビジョニングプロセスにそのルートディレクトリー内のデータを処理する方法を指示するパラメーターを定義できます。特に、root ディレクトリー内の既存ファイルおよびサブディレクトリーを無視し(preserve)するか、root ディレクトリーを 管理 してバンドル構造と一致するようにする必要があります。
レシピ コンプライアンスオプションは、すべてのものを削除して、ディレクトリーがバンドルコンテンツに一致するように強制するかどうかをプロビジョニングシステムに指示します。デフォルトは 満杯 になります。バンドルはルートディレクトリーのコンテンツと構造を定義します。そのディレクトリーのデータを保存する必要がある場合は、compliance オプションを filesAndDirectories に設定できます。つまり プロビジョニングはバンドルを通じてコピーされ、適切なファイルおよびサブディレクトリーを作成しますが、ディレクトリー内の既存のコンテンツを管理(削除)しません。
警告
プラットフォームや、などの重要なディレクトリーにバンドル /etc をデプロイする場合 deploy/ conf/、そのディレクトリーにある既存ファイルおよびサブディレクトリーがすべて削除されます。これにより、パフォーマンスの問題やデータ損失が発生する可能性があります。

バンドルおよびサブディレクトリー

compliance オプションが filesAndDirectories に設定されていても バンドルに含まれるサブディレクトリーやファイルは、バンドルのデプロイ前に存在していた場合でも常にバンドルによって管理されます。

たとえば、deploy/ ディレクトリーには、バンドルがデプロイされる前にこのレイアウトがあります。
deploy/
deploy/notes.txt
deploy/myApp1/
deploy/myApp2/
deploy/myApp2/first.txt
バンドルは以下のレイアウトで作成されます。
myApp2/
myApp2/foo.txt
myApp2/bar.txt
filesAdDirectories に設定する 、そのディレクトリー compliance はバンドルによって定義されるため、myApp2/ サブディレクトリーに ある 既存ファイルは deploy/ 変更されません。つまり、ディレクトリーの最終的なレイアウトは以下のようになります。
deploy/ (ignored)
deploy/notes.txt (ignored)
deploy/myApp1/ (ignored)
deploy/myApp2/ (managed)
myApp2/foo.txt (managed)
myApp2/bar.txt (managed)
注記
root ディレクトリー内の既存のコンテンツは削除前にバックアップされるため、後で復元できます。
バックアップディレクトリーは resourceID /home/.rhqdeployments/です/backup

バンドルのデプロイ後に追加されたファイル

初回のデプロイメント後に、ログファイルや追加のデータなど、デプロイメントディレクトリーにファイルが追加されるインスタンスが存在する可能性があります。

デプロイメントディレクトリー内では、プロビジョニングプロセスにより、バンドルに関連付けられたファイルを最新バージョンに上書きし、バンドルに含まれていないファイルを削除します。ログファイルおよびその他のデータ - ルートディレクトリーと同様に、アップグレード間で保持する必要があります。既知のファイルとディレクトリーは、<rhq:ignore> 要素を使用してレシピで呼び出すことができます。これにより、デプロイメントディレクトリー のファイルを無視してプロビジョニングプロセスに指示します。
レシピでこれらのオプションを設定する方法は、を参照してください 「警告: 管理対象(ターゲット)のディレクトリーおよび上書き/保存ファイル」

27.1.4. 要件およびリソースタイプ

デフォルトでは、3 つのリソースタイプがバンドルをサポートします。
  • プラットフォーム、全タイプ
  • JBoss EAP 6(AS 7)スタンドアロンサーバー [5]
  • JBoss AS 5 プラグインを使用する JBoss EAP 5 およびすべてのサーバー
  • JBoss EAP 4(非推奨)
バンドルサポートはプラグイン記述子で定義されるため、これらのリソースタイプのバンドルサポートを追加するカスタムプラグインを作成できます。バンドルサポートのあるエージェントプラグインを 『作成する例は、「カスタム JBoss ON プラグイン』 」を参照してください。

27.1.5. Provisioning and Agent User System Permission

バンドルがデプロイされると、エージェントが実行しているシステムユーザーにそのディレクトリーへの書き込み権限がある限り、プロビジョニングプロセスでバンドルファイルをシステム上の任意のディレクトリーに書き込むことができます。
で説明されているように 4章エージェントおよびリソースのシステムユーザーとの対話、エージェントが使用するシステムユーザーは、JBoss ON のパフォーマンス全体において重要です。1 つ目は、システムユーザーが適切なグループに参加し、リソースを効果的に管理するための適切な書き込みアクセスを付与する必要があります。一方、特に、バンドルを使用してシステムコンテンツや設定を処理する場合は、エージェントユーザーに過剰なパーミッションが付与されていないか、またはプロビジョニングプロセス自体が不正に使用されている可能性があることが重要です。
エージェントユーザーが持つ権限に関係なく、プロビジョニングシステムとデプロイされたバンドルは使用できます。デプロイされたバンドルには、エージェントユーザーの全システム権限があります。
エージェントがインストールされている場合は、必要なシステムパーミッションを評価することが重要です。また、デプロイされたアプリケーションまたは設定ファイルが望ましくないシステムの変更や不正使用を防ぐために、エージェントユーザーが持つ権限を評価し、バンドル自体のデプロイメントパスを計画することが重要です。

27.1.6. プロビジョニングおよびロール

バンドルグループレベルおよびグローバルパーミッションのセットは、バンドルのさまざまな管理ポイントに必要です。バンドルを管理し、アプリケーションをデプロイできるように、ユーザーに適切なパーミッションを付与する必要があります。
バンドル管理は、バンドルバージョンの作成およびリソースへのバンドルのデプロイという 2 つのタイプのタスクに分類されます。これらの各プロセスのワークフローは、組織構造、開発プロセス、および実稼働環境のルールで非常に明確に定義されます。たとえば、環境によっては、新しいバンドルを作成および削除したり、アクセス可能なリソースにコンテンツをデプロイしたりすることが許可されている場合があります。他の組織では、バンドル管理を特定のユーザーに制限したり、タスクを分割して、別のユーザーグループがバンドルをデプロイしている間に 1 つのグループがバンドルを作成できるようにする必要がある場合があります。
バンドルパーミッションはに一覧表示されますが 「アクセス制御およびパーミッション」、さまざまなグループのパーミッションを計画する一般的な例はに記載されてい 「拡張例: すべてのリソースの表示、一部のリソースの編集」 ます。
これは、一連のロールを作成して、希望のバンドルデプロイメントワークフローを並行して配置することです。つまり、ワークフローが明確に定義され、理解される必要があることを意味します。プロビジョニングプロセスのさまざまな部分には、主に 2 つの関係があります。バンドルの作成(JBoss ON データベースにアップロード)は、バンドル/ユーザー関係を定義します。バンドルのデプロイ(リソースへのコンテンツのコピー)は、バンドル/リソース関係を定義します。定義されたロールとパーミッションは、これを反映する必要があります。
リソースと同様に、バンドルは最初に バンドルグループのメンバーとしてロールで定義され、グループ 自体がロールに追加されます。デフォルトでは、すべてのバンドルは、作成時に少なくとも 1 つのグループに追加する必要があります。それらのグループは、アクセス権限を持つロールに属するグループに属するまで表示およびデプロイできません。例外として、グローバルビューバンドルパーミッションを付与することができます。これにより、どのグループにも属さない バンドル を作成できます。バンドルは 未割り当て という保持状態のままで、view バンドルパーミッションを持つユーザーのみがそれを確認できます(適切なパーミッションがあることを前提として、グループに追加できる場合のみ)。バンドルグループの作成については、を参照してください 「バンドルグループの管理」
「拡張例: プロビジョニングプロセスでのバンドルグループおよびアクセス制御の使用」 基本的な権限モデルをいくつか説明し、さまざまな潜在的なバンドル/ユーザーとバンドル/リソース関係を定義します。

27.1.7. バンドルの領域に関する考慮事項

バンドルは、ディスク領域の要件に大きく影響します。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部であるため、バンドルへの変更を元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。
したがって、バックエンドデータベース(Oracle または PostgreSQL)をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。

27.1.8. バンドルおよび JBoss ON Server およびエージェントプラグイン

27.1.8.1. リソースサポートおよびエージェントリソースプラグイン

プロビジョニングがサポートされるかどうかは、リソース種別で定義されます。プロビジョニングを許可するリソースタイプの場合、リソースプラグイン記述子は バンドルターゲット を定義する必要があります。これは、プロビジョニングがサポートされるエージェントへの示唆です。
<bundle-target> 要素は、バンドル定義のベースディレクトリーとして使用できるリソースの許可されるベースディレクトリーを定義します。
<server name="JBossAS:JBossAS Server" ...>
   <bundle-target>
      <destination-base-dir name="Library Directory" description="Where the jar libraries are">
         <value-context>pluginConfiguration</value-context>
         <value-name>lib.dir</value-name>
      </destination-base-dir>
      <destination-base-dir name="Deploy Directory" description="Where the deployments are">
         <value-context>pluginConfiguration</value-context>
         <value-name>deploy.dir</value-name>
      </destination-base-dir>
   </bundle-target>
</server>
リソースプラグイン記述子はすべて、プロビジョニング設定とは別に、ベースディレクトリー、すべてのデプロイメントのルートを定義します。プラットフォームの場合は、root ディレクトリーです。サーバーの場合、通常はインストールディレクトリーになります。すでに設定されたベースディレクトリーを使用 <bundle-target> できますが、別のディレクトリーが使用できるように設定できます。この例では、ディレクトリー deploy/ とディレクトリーの 2 つがサポート対象のベース lib/ ディレクトリーとして提供されます。バンドル定義が作成されると、ウィザードは使用するディレクトリーを選択できます。

27.1.8.2. レシピタイプのサーバー側のプラグインおよびエージェントプラグイン

デフォルトでは、JBoss ON は Ant ビルドファイルという 1 種類のレシピをサポートします。ただし、他のタイプのレシピは、レシピの種別がサーバー用およびエージェント用のプラグインのペアで定義されているためです。
サーバー側のプラグインは、JBoss ON サーバーに、そのタイプのレシピのバンドルと宛先を管理する方法を指示します。
エージェントプラグインは、プラットフォームまたはターゲットリソースでプロビジョニング操作を実行するために使用されるプラットフォームの子リソースを作成します。たとえば、Ant バンドルは、特定の JBoss ON リソースである Ant Bundle Handler によって実際にデプロイされます。このリソースは子リソースとしてプラットフォームに自動的に追加され、Ant ベースのプロビジョニングが有効になります。
注記
レシピタイプのサポートは特別なリソースを介してエージェント側で実装されるため、プロビジョニングを実行するにはそのリソースは JBoss ON インベントリーに存在する必要があります。たとえば、プラットフォームのインベントリーに Ant bundle ハンドラーがないと、JBoss ON はそのプラットフォームでプロビジョニングを実行できません。
管理者は Ant バンドルハンドラーリソースと直接対話する必要はありませんが、Ant プロビジョニングが機能するには、子リソースがプラットフォームのインベントリーに存在する必要があります。

27.1.9. JBoss ON CLI を使用したバンドルの管理およびデプロイ

JBoss ON にバンドルをアップロードし、リソースへのバンドルのデプロイは JBoss ON CLI を使用して実行できます。
新しいアプリケーションサーバーのコンテンツまたは設定の更新を JBoss ON 全体の他のリソースでのアクティビティーに基づいて自動的にデプロイできるため、バンドルデプロイメントをスクリプト化する機能は非常に強力なものです。これは、アラートに対応して JBoss ON CLI スクリプトを使用する場合に特に便利です。
  • 既存の JBoss サーバーのパフォーマンスが大きい場合やパフォーマンスが低下すると、新しい JBoss アプリケーションサーバーをデプロイすることができます。
  • 選択したスナップショットイメージの設定ファイルは、ドリフトアラートに対応して、プラットフォームまたは JBoss サーバーに即座にデプロイして、設定のドリフトを再処理できます。
  • 新しい Web コンテキストは、mod_cluster ドメイン内で別の Web が無効になっている場合にデプロイできます。
スクリプトにより、QE 環境への日次または週ごとの更新のスケジュールなど、スケジュールに更新を適用することもできます。また、ビルドシステムが使用する GIT または SVN リポジトリーからバンドルコンテンツを最初にプルし、その後のテストにデプロイできるために役立ちます。
バンドル API は、の API ガイドを参照してください https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Operations_Network/3.3/index.html

27.2. 拡張例: Common Provisioning Use Cases(およびどのように処理ファイルがあるか)

「コンテンツバンドルのプロビジョニングの概要」 バンドルおよびプロビジョニングシステム内のさまざまな要素について説明しますが、プロビジョニングとは何か?プロビジョニングが実際の環境でどのように機能するかを示す一般的なユースケースがいくつかあります。
  • 完全なアプリケーションサーバーのデプロイメント
  • アプリケーションサーバーへの Web アプリケーションのデプロイメント
  • 設定ファイルのデプロイ
重要
すべての点に注意する点として、バンドルはポイント A(JBoss ON)からコンテンツを取り、ポイント B(宛先)に送信することです。これは単純なコピー操作(「プロビジョニング中のファイル処理」)ではありません。デフォルトでは、プロビジョニングシステムは、宛先ポイント B を、バンドルのディレクトリーのレイアウト方法と完全に一致させます。これは、ファイルの追加または編集、サブディレクトリーの作成または削除、および宛先から既存のコンテンツを削除することを意味します。
宛先のレイアウトと内容を管理するという概念は、コンテンツのデプロイ方法と影響に影響します。

27.2.1. フルアプリケーションサーバーのデプロイメント

バンドルの詳細

これは、プロビジョニングシステムにおける、アプリケーションサーバー全体のデプロイのコアとなる方法です。このバンドルには、JBoss EAP のようなサーバー(Tomcat または Apache)などのサーバーの完全な設定スタックが含まれます。バンドルには、アプリケーションが使用するすべてのファイル(EAP サーバーの JAR と設定ファイルおよびスクリプト)、およびその EPA インスタンスにデプロイするすべての EAR または WAR Web アプリケーションが含まれます。すべてのアプリケーションサーバーと Web アプリケーションファイルおよびディレクトリーはアーカイブに圧縮され、Ant レシピを deploy.xml 定義します。

ファイル処理の詳細

これは完全なアプリケーションサーバーであるため、などの新しい(または空の)ディレクトリー内にデプロイされ /opt/my-applicationます。そのディレクトリーはアプリケーションサーバー専用となるため、バンドルによって完全に 管理 されます。

バンドルシステムにコンテンツのデプロイ方法を指示する compliance と呼ばれるレシピには属性があります。完全なアプリケーションサーバーをデプロイする場合、バンドルシステムはディレクトリーを完全に制御する必要があるため、フル に設定 compliance されます。これは、以下のようになります。
  • バンドルディストリビューションファイルのファイルおよびサブディレクトリーのみがルートディレクトリーに置かれます。
  • 既存のファイルまたはサブディレクトリーは削除されます。
  • ファイルまたはサブディレクトリーがルートディレクトリーに追加されると、そのファイル(レシピでの設定)が明示的に無視されない限り、バンドルの更新時または再デプロイ時にファイルが削除されます。

27.2.2. Web アプリケーションのデプロイ

完全なアプリケーションサーバーをデプロイする代わりに、Web アプリケーションをアプリケーションサーバーにデプロイできます。ただし、アプリケーションサーバーと Web アプリケーションの両方のディレクトリーレイアウトを理解します。
たとえば、これはアプリケーションサーバーのデプロイメントディレクトリーパスです。
/opt/my-application/deploy
目的は、新しい Web アプリケーションを deploy/ ディレクトリー myApp1.war にデプロイすることです。
/opt/my-application/deploy/myapp1.war/

バンドルの詳細

この場合、バンドルファイルには WAR ファイルと deploy.xml レシピのみが含まれます。

ファイル処理の詳細

アプリケーションサーバーとは異なり、Web アプリケーションをデプロイする際には、他の Web アプリケーションも deploy/ ディレクトリーにあります。バンドルシステムは、ルートディレクトリーを管理しないでください。つまり、バンドルに含まれていない場合でも、既存のファイルまたは新しいファイルは root ディレクトリー内で許可する必要があります。

ここでの目的は、ディレクトリーのコンテンツの管理ではなく、WAR ファイルをデプロイしてそのコンテンツに追加することです。したがって、レシピは compliance=fileAndDirectories、バンドル外のディレクトリー内の既存ファイルを残すようにプロビジョニングシステムに指示する必要があります。
注記
設定すると、バンドルデプロイメント以外のファイル compliance=filesAndDirectories のみが保存されます。bundle ディレクトリーがの場合 deploy/myApp/、バンドルのデプロイ時に、などのファイル deploy/myApp/ やサブディレクトリーのファイルはすべて deploy/myApp/WEB-INF/ 上書きまたは削除されます。バンドルディストリビューション で定義されるサブディレクトリーは、バンドルシステムによって完全 に管理されます。
1 つの検討事項として、ルートディレクトリーに 1 つのバンドルしかデプロイできない点が挙げられます。同じ EAP サーバーに複数の Web アプリケーションをデプロイし、それらすべてがプロビジョニングシステムで管理される場合は、2 つのオプションがあります。
  • 同じバンドルディストリビューションに含まれるすべての Web アプリケーションを含めます。たとえば、myApp2.war deploy/ ディレクトリーにデプロイ myApp1.war およびデプロイするには、同じバンドルに WAR ファイルを追加し、deploy/myApp1.war/ deploy/myApp2.war/ 同時にデプロイすることができます。
  • すべての web アプリケーションを同じバンドルにロールできない場合があります。root ディレクトリー deploy/ として使用する代わりに、サブディレクトリーをルートディレクトリーとして使用するバンドルディストリビューションが 2 つあります。たとえば、最初の Web アプリを使用して、最終的 deploy/myApp1/ なデプロイメントができ deploy/myApp1/myApp1.war/、2 つ目のアプリケーションが使用すると deploy/myApp2/、結果になり deploy/myApp2/myApp2.war/ます。
    これにより、2 つの Web アプリケーションをデプロイ、更新、および元に戻すことができます。

27.2.3. 設定ファイルのデプロイ

別の一般的なシナリオでは、バンドルを使用してアプリケーションサーバー(またはプラットフォームなどの別のリソース)に設定ファイルをデプロイすることです。
これは、Web アプリケーションのデプロイと非常に似ています。JBoss ON が指定のディレクトリーにバンドルをデプロイする場合、そのディレクトリーのコンテンツとバンドルに定義されたサブディレクトリー内のすべてのコンテンツを管理することが予想されます。設定ファイルでは、バンドルまたは重要なファイルの すべて の設定ファイルを把握し、含めることが重要です。
たとえば、管理者は以下の 2 つの設定ファイルをデプロイするためのバンドルを作成します。
  • の新しいログイン設定 server/default/conf/login-config/xml
  • 新しい JMX コンソールユーザー server/default/conf/props/jmx-console.properties
root ディレクトリーは、アプリケーションサーバーの conf/ ディレクトリーです。

バンドルの詳細

バンドルには、管理者が使用する 2 つの新規ファイルだけでなく、conf/props/ サブディレクトリー conf/login-config/ とサブディレクトリーにあることが予想される すべて のファイルが含まれている必要があります。さらに、レシピの compliance パラメーターを filesAndDirectories に設定して、ルートディレクトリー内の既存の設定ファイルがすべて保持される よう にする必要が conf/あります。

ファイル処理の詳細

Web アプリケーションをデプロイする場合と同様 に、既存のコンテンツを置き換えるのではなく、新しいコンテンツを追加することが意図されています。設定すると、バンドルデプロイメント以外のファイル compliance=filesAndDirectories のみが保存されます。ただし、バンドルには 2 つのサブディレクトリーが定義されているため、JBoss ON はこれらのサブディレクトリーのコンテンツをすべて管理します。これは、以下のようになります。

  • レシピは、conf/ ルートディレクトリー内の他のファイルを保持するためにバンドルを compliance=filesAndDirectories 設定する必要があります。
  • バンドルのサブディレクトリー内のファイルは conf/log-config/、バンドルのデプロイ時 conf/props/ に上書きされます。プロビジョニングプロセスは root ディレクトリー内のファイルを無視しますが、バンドルで特定されたサブディレクトリーのファイル(例: 更新、追加、または削除)ファイルを常に管理し、バンドルの内容に一致させます。
  • conf/log-config/ および conf/props/ サブディレクトリーの既存のファイルはバンドルディストリビューションに含める必要があります。
注記
バンドルディストリビューションにすべての設定ファイルを追加することもできます。
新しいファイルのみを含むバンドルは、のように別のディレクトリーにデプロイでき /opt/bundle/ます。次に、Ant インストール後のタスクは、root ディレクトリーからアプリケーションサーバーのディレクトリーに設定ファイルをコピーするレシピで定義でき conf/ ます。

27.3. 拡張例: アプリケーションを JBoss EAP サーバーへのプロビジョニング(計画)

設定

Tim the IT Guy at Example Co. は、Example のオンライン帯域管理アプリケーションである──App の完全なアプリケーションライフサイクルを管理する必要があります。QA には 2 つの環境があり、もう 1 つはライブサイト用です。どちらの環境にも、Windows サーバーと Linux サーバーが混在しています。

Tim は、開発の GIT リポジトリーで最新のビルドに基づいて、週に最新の開発バージョンを QA 環境にデプロイすることを希望しています。静的パッケージに基づいて、最も安定したバージョンのアプリケーションを実稼働環境にデプロイすることを希望します。

操作方法

Tim にとって最適な計画は、自分の理想的な QA と実稼働環境の設定を希望する方法から、後方作業を行うことです。

Tim の最初のステップは、その環境に基づいて目的のある目的を特定することです。2 つの環境があるため、独立したグループを 2 つ作成します。1 つ目は QA と実稼働環境用です。✓App は JBoss サーバー上で実行されるため、プラットフォームではなく JBoss AS/EAP リソース用の互換性のあるグループになります。
また、各環境に対するニーズは異なります。
  • QA 環境が必要...
    • 新規ビルドは、週ごとに GIT リポジトリーから直接作成します。
    • すべてのデプロイメントから開始する完全にクリーンなディレクトリー。
    • サンプル Co. の web アプリケーションにはそれぞれ個別の QA 環境があるため、特定のサーバーで実行している唯一のアプリケーションになります。
  • 実稼働環境では必要なもの
    • JBoss ON で安全に保存できる安定したビルド。
    • 履歴データを保存するには、以下を実行します。実稼働環境には、ログディレクトリーとユーザー提供のデータディレクトリーの両方があり、アプリケーションのアップグレード後も維持する必要があります。
    • 同じ実稼働サーバーで複数の異なる Web アプリケーションが実行されます。
アプリケーション自体は両方の環境で同じです。インスタンス固有の設定(ポート番号、アプリケーション名、マシン IP アドレス)は、アプリケーションがデプロイされる際に有効なトークンに基づいています。バンドルに含まれる JAR ファイルは、アプリケーションがデプロイされるときに抽出する必要があります。ただし、ローカルにインストールするか、または起動できるクライアントが 1 つのクライアントを除きます。
Tim は、同じバンドルの異なるバージョンを使用することを決定し、QA バージョンに devel と production バージョンのラベルを付け ます
devel と安定したバンドルレシピにはいくつかの類似点があります。
  • deploy/ ディレクトリーにデプロイする必要がありますが、実行するアプリケーションではないので、独自の webapp コンテキストサブディレクトリーを持ちます。これは、devel 環境では必須ではありませんが(⋮App が唯一のアプリケーションである場合)、最終的なデプロイメント先との一貫性を維持します。
  • どちらのレシピも MusicApp.jar、アプリケーション JAR ファイルのデプロイ時に展開されるように設定します。
  • クライアントアーカイブファイルは展開さ MyMusic.jarれません(<rhq:file ... exploded="false">)。
  • トークンは、raw 設定ファイルとポート番号、IP アドレス、およびアプリケーション名のレシピで定義されます。
また、レシピには、devel および stable のバージョンが既存のファイルを処理する方法との違いがあります。
  • QA 環境には、常にプルーニングのデプロイメントが必要です。これには 3 つの設定が必要です。
    • この compliance 値は常に 満杯 になるため、初回のデプロイメント時に既存のファイルは保持されません。
    • <rhq:ignore> 要素は設定されないため、アップグレード中に生成されたファイルは保持されません。
    • cleanDeployment オプションは、デプロイメントを自動化する JBoss ON CLI スクリプトで常に設定されます。これにより、新規バンドルをデプロイする前に、ディレクトリー内のバンドルに関連付けられたファイルがすべて削除されます。
  • 実稼働環境では、アップグレード間で既存のデータを保持する必要があります。これには 2 つの設定が必要です。
    • この compliance 値は常に filesAndDirectories で 初回のデプロイメント時に既存のファイルを保存します。
    • 2 つの <rhq:ignore> 要素は、ログディレクトリー用と、サイトメンバーのアップロードを含むデータディレクトリー用に設定されます。
最後の重要なアクションは、バンドルが実際に JBoss ON にアップロードされると発生します。
アプリケーションのバージョン 1 はすでに安定していて完了したため、Tim は安定したバージョンとして最初のバンドルを作成します。ZIP ファイルで他のアプリケーションファイル deploy.xml とともにパッケージ化し、バンドル全体を JBoss ON ON に直接アップロードするため、JBoss ON データベースに保存されます。
バージョン 2 は devel バージョンです。QA 環境には、GIT の最新ビルドに基づく更新が頻繁に必要になります。Tim は deploy.xml 個別にアップロードしますが、関連するすべてのパッケージの GIT URL にプロビジョニングウィザードをポイントします。バンドルがデプロイされると、JBoss ON はリポジトリーからパッケージを取得します。

結果

Tim はバンドルのバンドル 1 を本番環境にデプロイし、バージョン 2 を QA 環境にデプロイしました。

つまり、Tim が、異なるソースからプルされた同じアプリケーションの異なるバージョンを、異なるリソースにデプロイしたことを意味します。実稼働サーバーに問題が発生した場合、最後の安定したバージョンに戻すことができます。
さらに、QA 環境へのバンドルデプロイメントをスクリプト化できるため、テストを完全に自動化できます。

27.4. バンドルの作成およびデプロイに関するワークフロー

  1. アプリケーションサーバー、個別の Web アプリケーション、ドリフト管理用の設定ファイルなど、アーカイブに含まれるファイルを特定します。
  2. バンドルをデプロイする場所の処理方法を決定します。既存のファイルおよびディレクトリーは、レシピの定義に応じて上書きまたは保持できます。これは 「プロビジョニング中のファイル処理」 およびで説明されてい 「警告: 管理対象(ターゲット)のディレクトリーおよび上書き/保存ファイル」 ます。
  3. デプロイされたコンテンツがポート番号、ホスト名、またはその他の設定を必要とするかどうかなど、デプロイメント固有の情報を特定します。これらの値の一部は設定ファイルでトークンを使用でき、プロビジョニングプロセスではデプロイメント時に特定の値を対話的に要求できます。
    トークンはで説明されてい 「Templatized 設定ファイルの使用」 ます。
  4. デプロイされるコンテンツを作成します。
  5. という名前の Ant レシピを作成し deploy.xmlます。レシピは、バンドルに含まれるコンテンツと設定ファイルと、コンテンツをバンドル宛先にデプロイする方法を定義します。インストール前およびインストール後のターゲットがサポートされます。したがって、ローカルシステムに追加の処理を行い、必要に応じてサービスを設定または開始できます。
    ANT レシピとタスクについては、「Ant Recipe の内訳」 およびで説明されてい 「Ant Task の使用」 ます。
  6. バンドルコンテンツ、設定ファイル、およびレシピを作成したら、それらのファイルをすべてバンドルアーカイブに圧縮します。これには、ディレクトリーの最上位に deploy.xml レシピファイルが必要で、そのファイルに対して相対的なディストリビューション内の他の deploy.xml ファイルが必要です。これは、を参照してください 「バンドル: コンテンツおよびレシピ」
    注記
    JBoss ON では、バンドルアーカイブの JAR および ZIP 形式が許可されます。
  7. 必要に応じて、バンドルのデプロイヤーツールを実行して、バンドルが正しくフォーマットされていることを確認します。これは、で説明してい 「バンドルパッケージのテスト」 ます。
  8. バンドルをデプロイするリソースのグループを作成します。
  9. の説明に従って、バンドルを JBoss ON サーバーにアップロードし 「バンドルの JBoss ON へのアップロード」 ます。
  10. の説明に従って、バンドルをターゲットグループにデプロイし 「リソースへのバンドルのデプロイ」 ます。

27.5. Ant Bundles の作成

バンドル は、サーバーに保存され、エージェントがダウンロードしてプラットフォームまたはリソースにデプロイするアーカイブファイルです。バンドルディストリビューションは 2 つの要素で構成されます。
  • Ant レシピファイルの名前 deploy.xml
  • 関連するアプリケーションファイル。これらのアプリケーションファイルは、あらゆるものになりますが、一般的には 2 つのカテゴリーに分類されます。
    • アーカイブファイル(JAR または ZIP ファイル)
    • バンドルのデプロイ時にユーザーが値を定義するトークンが含まれる raw テキスト設定ファイル
注記
Ant レシピを実際に作成するプロセスおよびガイドラインは、本書の対象外です。本書では、JBoss ON プロビジョニングシステムと連携するために 特に Ant レシピを使用するためのオプションおよび要件について説明します。
Ant タスクを記述するための基本的な手順、オプション、およびチュートリアルは、の Apache Ant ドキュメントを参照してください http://ant.apache.org/manual/index.html

27.5.1. サポート対象の Ant バージョン

表27.1 Ant および Ant Task Versions

ソフトウェア version
ant 1.8.0
Ant-Contrib 1.0b3

27.5.2. 追加の Ant References

プロビジョニングは Ant 設定およびタスクに依存するため、Ant ビルドプロセスについての適切な理解は有益です。追加の Ant 情報には、複数のリソースがあります。

27.5.3. Ant Recipe の内訳

JBoss ON バンドルの Ant レシピは、標準の Apache Ant ファイルと同じ基本ファイルで、JBoss ON の統合された Ant ビルドシステムによって処理されます。この Ant レシピファイルは、ディストリビューションの ZIP ファイルの top ディレクトリーにバンドルして名前を付ける必要があり deploy.xmlます。
JBoss ON Ant レシピでは、Ant ビルドで利用可能なすべての標準タスクが可能で、複雑なアプリケーションのデプロイメントを柔軟にスクリプト化できます。JBoss ON Ant レシピは、プロビジョニングプロセスによって使用されるデプロイメントに関する追加情報も提供 する必要 があります。これには、宛先に関する情報と、アプリケーション自体に関するメタデータが含まれます。

例27.1 Simple Ant Recipe

Ant レシピは、Ant ターゲットを呼び出してプロビジョニング後の操作を行うことができますが、Ant レシピは true スクリプトファイルよりも多くの定義ファイルです。その他の Ant スクリプトと同様に、JBoss ON Ant レシピは <project> ルート要素と定義されたターゲットとタスクを持つ標準の XML ファイルを使用します。この <rhq:bundle> エリアで定義された要素は、プロジェクトのビルド時にメタデータを JBoss ON プロビジョニングシステムに渡します。
ファイルの最初の部分は単に deploy.xml ファイルをスクリプトとして識別し、provisioning Ant 要素を参照します。
<project name="test-bundle" default="main" 
 xmlns:rhq="antlib:org.rhq.bundle">
次の要素は、特定のバンドルファイル自体を特定します。プロビジョニングシステムは、同じアプリケーションの複数のバージョンを管理およびデプロイできます。この <rhq:bundle> 要素には、バンドルの特定バージョンに関する情報が含まれます(ただし、実際には、オプションのバージョン番号が含まれます)。
    <rhq:bundle name="Example App" version="2.4" description="an example bundle">
レシピに 必要な のは、アプリケーションの名前を定義する <rhq:bundle> 要素のみです。ただし、bundle 要素にはアプリケーションに関する情報がすべて含まれ、プロビジョニングシステムがアプリケーションに含まれるコンテンツを処理する方法が重要になります。
address の最初の項目は、設定ファイルで使用される テンプレート化されたプロパティー です。これは、で説明してい 「Templatized 設定ファイルの使用」 ます。設定ファイルで使用されるトークンは、プロビジョニング時に(値を提供するため)レシピで定義する必要があります。で定義された port トークンでは 「Templatized 設定ファイルの使用」<rhq:input-property> 要素はレシピで識別します。name 引数は token の input_field 値で、description 引数は UI で使用されるフィールドの説明と、値が必要であるかどうか、許可される構文、および指定するデフォルト値を設定します。(これはトークン自体を使用するファイルを一覧表示せず、トークン自体のみを使用します。)
 <rhq:input-property
            name="listener.port"
            description="This is where the product will listen for incoming messages"
            required="true"
            defaultValue="8080"
            type="integer"/>
バンドルによってデプロイされたすべてのコンテンツ(要素)を識別する単一の <rhq:deployment-unit> 要素があります。アプリケーション全体(ZIP または JAR ファイル、設定ファイル、Ant ターゲット)は、すべて <rhq:deployment-unit> 親要素で定義されます。
名前と Ant ターゲットは、<rhq:deployment-unit> 直接の引数として定義されます。これにより、がで、preinstall ターゲットと appserver、インストール後のターゲットが 1 つ設定されています。
        <rhq:deployment-unit name="appserver" preinstallTarget="preinstall" postinstallTarget="postinstall" compliance="filesAndDirectories">
要素には、他の重要な <rhq:deployment-unit> 要素が 1 つあり compliance ます。プロビジョニングは単にファイル上のコピーを行うのではなく 「プロビジョニング中のファイル処理」、で説明しているようにディレクトリーを再作成します。バンドルのデプロイ時にデプロイメントディレクトリーに既存のファイルがある場合は、デフォルトで削除されます。filesAndDirectories compliance設定 すると、プロビジョニングプロセスでデプロイメントディレクトリーを管理し ませ ん。つまり、バンドルのデプロイ時に既存のファイルは単独で残されます。
root ディレクトリー内の既存のコンテンツは削除前にバックアップされるため、後で復元できます。バックアップディレクトリーは resourceID /home/.rhqdeployments/です/backup
すべての設定ファイルは <rhq:file> 要素で識別されます。nameバンドル内の設定ファイルの 名前で、destinationFile はデプロイ後のファイルの相対パスおよびファイル名になります。
 <rhq:file name="test-v2.properties" destinationFile="conf/test.properties" replace="true"/>
バンドルには、ZIP または JAR ファイルのいずれかのアーカイブファイルを含めることができます。すべてのアーカイブファイルは deployment-unit 内の <rhq:archive> 要素で識別されます。<rhq:archive> 要素は以下の 3 つのことを行います。
  • 名前でアーカイブファイルを特定します。
  • アーカイブの処理方法を定義します。簡単に説明すると、アーカイブをコピー先にコピーしてそのままにするか、アーカイブをアーカイブとしてそのままにするか、またはデプロイ後にアーカイブを抽出するかどうかを設定します。これはアーカイブの展開 呼ばれます。アーカイブが展開される場合は、必要に応じて、postinstall タスクを呼び出してファイルを移動するか、または編集できます。
  • 永続する必要のあるトークンが含まれるアーカイブ内のファイルを特定します。これは子要素です <rhq:fileset>。これにより、ワイルドカードを使用してサブディレクトリーにファイルの種類やファイルを追加したり、処理するファイルを明示的に記述したりできます。
            <rhq:archive name="MyApp.zip" exploded="true">
                <rhq:replace>
                    <rhq:fileset>
                        <include name="**/*.properties"/>
                    </rhq:fileset>
                </rhq:replace>
            </rhq:archive>
もう 1 つの子要素は、バンドルの一部ではないデプロイメントディレクトリー内のファイルの処理方法を設定します。たとえば、アプリケーションはログファイルを生成したり、ユーザーがコンテンツをアップロードできる場合もあります。デフォルトでは、プロビジョニングプロセスはバンドルがプロビジョニングされるたびに、バンドル以外のコンテンツからディレクトリーをクリーンアップします。ただし、ログ、ユーザー提供のデータ、およびその他の種類のファイルは、プロビジョニング後もそのまま維持されるデータです。プロビジョニングプロセス(つまり保持)によって無視されるべきファイルまたはサブディレクトリーは、<rhq:ignore> 要素で識別されます。この場合、logs/ ディレクトリー内の *.log ファイルはすべて保存されます。
            <rhq:ignore>
                <rhq:fileset>
                    <include name="logs/*.log"/>
                </rhq:fileset>
            </rhq:ignore>
        </rhq:deployment-unit>
    </rhq:bundle>
これは、バンドルのアップグレードのみに適用され、初回のデプロイメント にのみ適用されます。
最後の要素は、<rhq:deployment-unit> 引数で最初に特定されたように、コンテンツのデプロイ前または後に実行する Ant タスクを設定します。一般的な Ant タスクの大半は(を参照 「Ant Task の使用」)サポートされます。これは、preinstall タスクを使用して、バンドルがデプロイされているディレクトリーと、操作が成功したかどうかをプリントします。postinstall タスクは、デプロイメントが完了するとメッセージを出力します。
<target name="main" />

    <target name="preinstall">
        <echo>Deploying Test Bundle v2.4 to ${rhq.deploy.dir}...</echo>
 <property name="preinstallTargetExecuted" value="true"/>
 <rhq:audit status="SUCCESS" action="Preinstall Notice" info="Preinstalling to ${rhq.deploy.dir}" message="Another optional message"> 
  Some additional, optional details regarding 
  the deployment of ${rhq.deploy.dir} 
 </rhq:audit> 
    </target>

    <target name="postinstall">
        <echo>Done deploying Test Bundle v2.4 to ${rhq.deploy.dir}.</echo>
        <property name="postinstallTargetExecuted" value="true"/>
    </target>
</project>
「JBoss ON Ant Recipe 要素のリファレンス」 Ant レシピファイルのさまざまな JBoss ON 要素を一覧表示します。標準の Ant タスクの詳細は Apache Ant のドキュメントを参照してください

27.5.4. Ant Task の使用

Ant バンドルディストリビューションファイルは、ant レシピとその関連ファイルです。前述のように 「Ant Recipe の内訳」、Ant レシピは JBoss ON 固有の要素が含まれる想定される deploy.xml ファイルです。Ant バンドルディストリビューションファイルは、Ant タスクやターゲットを含むより複雑な Ant 設定をサポートします。

27.5.4.1. サポート対象の Ant Task

標準の Ant タスクは、Ant バンドルプロビジョニングの一部として実行できます( <antcall> およびを除く <macrodef>)。これには echo、、、、mkdir、、などの一般的 touch なコマンドが含まれます。
重要
Ant レシピでは <antcall> 要素を使用 できませんdeploy.xml ファイル内のターゲットを <antcall> 呼び出し、再度呼び出しを行う <antcall> タスクを再度呼び出す deploy.xml ファイルに対してループします。これにより無限ループが作成されます。
と同じ操作を実行するには <antcall><ant> タスクを使用してカスタム Ant ターゲットが含まれる別の XML ファイルを参照します。これは、で説明してい 「Ant ターゲットの呼び出し」 ます。
重要
macrodef 呼び出し、つまりマクロ定義は Ant バンドルではサポートされません。
標準の Ant タスクに加えて、Ant バンドルレシピはオプションの Ant タスクを使用できます。

27.5.4.2. デフォルト、インストール前、およびインストール後のターゲットの使用

他の Ant タスクと同様に、プロビジョニングシステムで必要となるデフォルトのターゲットを <project> 許可します。Ant レシピは主にプロビジョニングプロセスで使用されるファイルのメタデータを定義し、特定するため、これは no-op です。他の操作は必要ありません。このターゲットは、no-op ターゲットであっても Ant で必要です。ターゲットの pre- および post-install ターゲットを使用して、展開される前および後にバンドルでタスクを実行します。
例:
<target name="main" />
さらに、JBoss ON のプロビジョニングタスクは、インストール前およびインストール後のターゲットの両方を定義することができます。これにより、単純な進捗メッセージやプロパティーの設定などのカスタムタスクが可能になります。

27.5.4.3. Ant ターゲットの呼び出し

の説明にあるように 「サポート対象の Ant Task」、Ant バンドルレシピで <antcall> は使用は機能しません。自己参照的にその <rhq:bundle> タスクを無限ループで呼び出します。ただし、デフォルトのターゲット にあるタスクを処理することは可能です。これは、インストール前およびインストール先(「デフォルト、インストール前、およびインストール後のターゲットの使用」)を使用して実行できます。
  1. Ant レシピ deploy.xml では、Ant ターゲットを識別する <rhq:deployment-unit> 要素を追加します。
    <rhq:deployment-unit name="jar" postinstallTarget="myExampleCall">
  2. 次に、ターゲットを定義します。
        <target name="myExampleCall">
           <ant antfile="another.xml" target="doSomething">
              <property name="param1" value="111"></property>
           </ant>
        </target>
    
  3. another.xml ファイルと同じディレクトリーに別の deploy.xml ファイルを作成します。このファイルには Ant タスクが含まれます。
    
    <project name="another" default="main">
        <target name="doSomething">
           <echo>inside doSomething. param1=${param1}</echo>
        </target>
    </project>
    

27.5.5. Templatized 設定ファイルの使用

バンドルには、アプリケーションの設定ファイルを含めることができます。これらの設定ファイルはハードコーディングされた値を使用でき、バンドルが実際にデプロイされる際に(自動またはユーザー提供の値)に入力された トークン を使用できます。
注記
ユーザー定義トークンを生成するには、バンドルデプロイメントウィザードが Ant レシピの <rhq:input-property> キーを使用して値を要求するようにレシピで参照する必要があります。例については、「rhq:input-property」 およびを参照してください 「Ant Recipe の内訳」
ユーザー定義のトークンはプロパティーにすることができます。値はプロビジョニング UI で提供され、templatized 設定ファイルに挿入されます。
トークンキーは単純な属性/値のアサーションで、input_field が UI の要素となり、プロパティー は設定ファイルの値になります。ユーザー定義トークンのプロパティーには、英数字、アンダースコア(_)、ピリオド(.)のみを含める必要があります。他の文字は使用できません。
input_field=@@property@@
たとえば、設定ファイルにポート番号トークンを設定するには、プロパティーを定義します。
port=@@listener.port@@
次にユーザー定義のトークンをレシピで記載する必要があります。これにより、プロビジョニングプロセスでフレーズが認識されるようにします。Ant レシピでプロパティーを設定するには、Ant XML ファイルに <rhq:input-property> キーを追加します。
例:
<rhq:input-property
    name="listener.port"
    ... />
プロビジョニングウィザードでは、レシピで参照されるユーザー定義トークンすべての値の入力が求められます。

図27.3 プロビジョニング中のポートトークン

プロビジョニング中のポートトークン
レシピファイルで指定できるユーザー定義の変数とともに、レシピが暗黙的に使用できる変数があります。これらのトークンは、レシピ自体でトークンテンプレートを定義することなく、ユーザー定義の変数としてテンプレート化ファイルで使用できます。

表27.2 JBoss ON によって定義される変数

token description
rhq.deploy.dir バンドルがインストールされるディレクトリーの場所。
rhq.deploy.id 特定のバンドルデプロイメントに割り当てられる一意の ID。
rhq.deploy.name バンドルデプロイメントの名前。
また、一部のトークンは、ローカルシステムからのプロビジョニングプロセスプル情報によって起動できます。に一覧表示されるこれらの値は 表27.3「システム定義トークン」、Java API または Java システムプロパティーのいずれかから取得されます。レシピに対応するエントリーを配置することなく、設定ファイルをテンプレート化された設定ファイルに直接挿入できます。例:
@@rhq.system.hostname@@

表27.3 システム定義トークン

トークン名 取得元... Java API
rhq.system.hostname Java API SystemInfo.getHostname()
rhq.system.os.name Java API SystemInfo.getOperatingSystemName()
rhq.system.os.version Java API SystemInfo.getOperatingSystemVersion()
rhq.system.os.type Java API SystemInfo.getOperatingSystemType().toString()
rhq.system.architecture Java API SystemInfo.getSystemArchitecture()
rhq.system.cpu.count Java API SystemInfo.getNumberOfCpus()
rhq.system.interfaces.java.address Java API InetAddress.getByName(SystemInfo.getHostname()).getHostAddress()
rhq.system.interfaces.network_adapter_name.mac Java API NetworkAdapterInfo.getMacAddress()
rhq.system.interfaces.network_adapter_name.type Java API NetworkAdapterInfo.getType()
rhq.system.interfaces.network_adapter_name.flags Java API NetworkAdapterInfo.getAllFlags()
rhq.system.interfaces.network_adapter_name.address Java API NetworkAdapterInfo.getUnicastAddresses().get(0).getHostAddress()
rhq.system.interfaces.network_adapter_name.multicast.address Java API NetworkAdapterInfo.getMulticastAddresses().get(0).getHostAddress()
rhq.system.sysprop.java.io.tmpdir Java システムプロパティー  
rhq.system.sysprop.file.separator Java システムプロパティー  
rhq.system.sysprop.line.separator Java システムプロパティー  
rhq.system.sysprop.path.separator Java システムプロパティー  
rhq.system.sysprop.java.home Java システムプロパティー  
rhq.system.sysprop.java.version Java システムプロパティー  
rhq.system.sysprop.user.timezone Java システムプロパティー  
rhq.system.sysprop.user.region Java システムプロパティー  
rhq.system.sysprop.user.country Java システムプロパティー  
rhq.system.sysprop.user.language Java システムプロパティー  

27.5.6. JBoss ON プロパティーおよび Ant プロパティーの処理

で説明されているように 「Templatized 設定ファイルの使用」、JBoss ON は <rhq:input-property> タグで独自のレシピプロパティーを定義します。これらは入力プロパティーです。バンドルのデプロイ時には、サーバーはファイルの設定を解析し、入力プロパティーの入力を要求します。その後、これらのユーザー定義の値を使用してバンドルをデプロイします。
JBoss ON は Ant <property> タグの使用もサポートしますが、通常の Ant ビルドシステムよりも限定的な方法です。
バンドルをデプロイするには、JBoss ON サーバーにバンドルエンティティーを作成し、JBoss ON エージェントを介してそのバンドルを管理対象リソースにインストールするという 2 つの手順があります。通常の Ant ビルドシステムとは異なり、以下のステップは異なるマシンで行わ れます。
システムを理解することが重要です。したがって、この 2 つのビルドステップを実行する環境は異なります。これはバンドルの全体的な処理ワークフローに影響し、Ant ビルドプロセスの制限を行います。
バンドルがアップロード(作成)の場合、JBoss ON サーバーは Ant レシピをチェックして必要なバンドルファイルを確認します。これは <rhq:archive>、アーカイブファイルの <rhq:bundle> 要素と、その他の関連するコンテンツを処理することを意味します。
この時点で、サーバーはバンドル設定を処理せず、JBoss ON 入力プロパティーまたは Ant proprities のいずれかのプロパティーを評価します。これは、多くの JBoss ON 入力プロパティーが環境固有で、これらのプロパティーの拡張を試みると、バンドルが最終的に管理対象プラットフォームにデプロイされるときに必要なものとは異なるバンドル設定(Java バージョン、オペレーティングシステムバージョン、ファイルシステムの場所など)が異なります。
Ant プロセスのすべてを JBoss ON エージェントプラットフォームに移動すると、Ant プロパティーの処理方法は通常の Ant ビルドサーバーとは異なります。一般的な Ant 実装では、Ant プロパティーを使用して、ファイル名やバージョン番号などのレシピのコア要素を初期化できます。ただし、Ant スクリプトは JBoss ON サーバーで実行されないため、テンプレート化されたプロパティーを拡張することはできません。つまり、必要な設定(アーカイブ名、他のファイル、名前、バージョン番号など)は Ant プロパティーまたは JBoss ON 入力プロパティーのいずれかで概念化できません。サーバーが値を要求するには、明示的に指定するか、空のままにする必要があります。別の方法では、スクリプトの実行時に使用されるプロパティーは無視されますが、必要なプロパティーの前に定義された値が必要です。設定内のこの時点でのテンプレート化された値はリテラル値として処理されます。

27.5.7. Ant Recipes の制限および考慮事項

27.5.7.1. サポートされない Ant Task

に記載されているように 「サポート対象の Ant Task」、ほとんどの標準の Ant タスクはバンドルレシピで使用するためにサポートされていますが、サポートされないタスクがいくつかあります。
  • <antcall> (代わりに、<ant> を使用して、Ant ターゲットを含むバンドルの個別の XML ファイルを参照するのに使用します)。
  • <macrodef> マクロ定義

27.5.7.3. 警告: 管理対象(ターゲット)のディレクトリーおよび上書き/保存ファイル

Ant レシピで考慮すべき重要な点として、deployment ディレクトリー内のファイルを処理する方法が挙げられます。(これはオンになってい 「プロビジョニング中のファイル処理」 ます。)
デフォルトでは、バンドルのデプロイまたは更新は、バンドルを上書きまたは削除して、デプロイメントディレクトリーのすべての内容に置き換わります。ファイル処理ルールは、RPM パッケージのアップグレードルールと非常に似ています。これは非常に簡素化されますが、プロビジョニングプロセスはデプロイメントディレクトリーの既存のファイルに対して 2 つのいずれかの方法で応答します。
  1. 現行ディレクトリーのファイルもバンドルに含まれます。この場合、バンドルファイルは常に現在のファイルを上書きします。(これに 1 つの例外があります。バンドルのファイルが更新されず、ローカルファイルと同じバージョンであるものの、ローカルファイルが変更されている場合。この場合、ローカルファイルは保持されます。)
  2. 現在のディレクトリーのファイルはバンドルに存在しません。この場合、バンドルは現在のディレクトリーのファイルを削除します。
ファイルの削除時に #2 の動作は、Ant レシピの設定により変更できます。
プロビジョニング時にファイルの保持方法(、compliance、および)を管理する方法は 3 つあります <rhq:ignore> cleanDeployment

コンプライアンス

デプロイするアプリケーションに関する情報はすべて、バンドルレシピの <rhq:deployment-unit> 要素で定義されます。<rhq:deployment-unit> 要素の compliance 属性は、プロビジョニングプロセスが deployment ディレクトリー内の既存のファイルを処理する方法を設定します。

デフォルト値は compliance=full です。これは、プロビジョニングプロセスで root ディレクトリー内の他のファイルをすべて削除することを意味します。
注記
root ディレクトリー内の既存のコンテンツは削除前にバックアップされるため、後で復元できます。
バックアップディレクトリーは resourceID /home/.rhqdeployments/です/backup
または、この値を filesAndDirectories に設定することもできます。これは、バンドルに対応するファイルがない場合に、root ディレクトリー内の既存ファイルをすべて無視するようにプロビジョニングプロセスに指示します。
この compliance 属性は初期デプロイメントとアップグレード操作の両方に適用されるため、これによりバンドルがデプロイされる前にディレクトリーに存在する可能性があるファイルを保存することができます。
を参照してください 「rhq:deployment-unit」
注記
リソースでバンドルが使用されなくなった場合は、ファイルシステムから完全に削除できます。これは パージ と呼ばれます。バンドルミラーをパージする際に、プロビジョニングシステムがファイルを処理する方法(システムのプロビジョニング時にファイルを処理する方法)。デフォルトでは、バンドルをパージすると、デプロイメントディレクトリーにあるすべてが削除されます。コンプライアンスオプションがバンドルの filesAndDirectories に設定 れている場合、プロビジョニングプロセスによりバンドルに関連付けられたファイルおよびディレクトリーがすべて削除され、関連しないファイルやディレクトリーがそのまま残されます。

<rhq:ignore>

バンドルのデプロイメント後も保持する必要のあるバンドルとは別に、アプリケーションによって使用または作成されるファイルが存在する可能性があります。これには、ログファイル、インスタンス固有の設定ファイル、イメージなどのユーザー提供のコンテンツなどが含まれます。これらのファイルはプロビジョニングプロセス中に無視でき、ファイルを削除するのではなく保存されます。

ファイルを保存するには、<rhq:ignore> 要素を使用し、保存するディレクトリーまたはファイルをリストします。
<rhq:ignore>
    <rhq:fileset>
        <include name="logs/*.log"/>
    </rhq:fileset>
</rhq:ignore>
<rhq:ignore> 要素はバンドルが更新される場合にのみ適用されます。バンドルが最初にプロビジョニングされている場合は適用されません。
また、<rhq:ignore> 要素はバンドル外部に存在するファイルにのみ適用されます。バンドルのファイルはすべて、<rhq:ignore> 要素で指定されていてもデプロイメントディレクトリーの対応するファイルは上書きされます。
を参照してください 「rhq:ignore」

デプロイメントのクリーニング

compliance および <rhq:ignore> はいずれもレシピで設定されます。バンドルが実際にプロビジョニングされる時点で、クリーンなデプロイメント を実行するオプションがあります。clean デプロイメントオプションは、デプロイメントディレクトリーのすべてのものを削除し、レシピの compliance および <rhq:ignore> 設定にかかわらず、バンドルをクリーンディレクトリーにプロビジョニングします。

27.5.8. JBoss ON Ant Recipe 要素のリファレンス

27.5.8.1. rhq:bundle

Ant バンドルレシピに必要な主な JBoss ON 関連の Ant タスクの定義が含まれます。この要素はバンドルの基本情報を定義し、バンドルの内容およびプロビジョニング方法に関する固有のすべての詳細の親要素です。

表27.4 要素の属性

attribute description Optional または Required
Name バンドルに指定された名前。 必須
version この特定のバンドルのバージョン文字列。バンドルには同じ名前を付けることはできますが、その名前の各バンドルには固有のバージョン文字列を指定する必要があります。これらのバージョン文字列は通常、1.0 またはなどのバージョン管理の OSGi スタイルに従い 1.2.FINALます。 必須
description この特定のバンドルバージョンの分かりやすい説明。 任意

例27.2 rhq:bundle

<rhq:bundle name="example" version="1.0" description="an example bundle">

27.5.8.2. rhq:input-property

バンドルのデプロイ時にユーザーによって提供された値が必要なテンプレートトークンを定義するバンドルタスクにプロパティーを追加します。これは標準の Ant プロパティーと似ています。
注記
に記載されているシステムプロパティーおよび Ant 固有のトークン 「Templatized 設定ファイルの使用」 はすべて、<rhq:input-property> 定義を設定 せず にバンドル設定のテンプレートトークンとして使用できます。
すべての入力プロパティーは、バンドルがリソースでプロビジョニングされるときにユーザーによって定義される値を持つ一部のパラメーターを設定し、これらの値を入力するフィールドは JBoss ON UI バンドルデプロイメントウィザードに自動的に生成されます。

表27.5 要素の属性

attribute description Optional または Required
Name ユーザー定義プロパティーの名前。レシピ内では、このプロパティーを ${property_name の形式でこの名前で参照でき}ます。 必須
description プロパティーの読み取り可能な説明。これは、バンドルのデプロイ時に JBoss ON バンドル UI に表示されるテキスト文字列です。 必須
type
ユーザー定義の値で使用できる構文を設定します。以下のオプションは複数あります。
  • string
  • longString
  • long
  • password
  • file
  • ディレクトリー
  • ブール値
  • 整数
  • float
  • double
必須
必須 設定にプロパティーが必要であるか、または任意かを設定します。デフォルト値はで false、プロパティーは任意です。この引数を指定しない場合は、プロパティーが任意であることを前提とします。 任意
defaultValue バンドルのデプロイ時にユーザーが値を定義しない場合に、使用するプロパティーの値を指定します。 任意

例27.3 rhq:input-property

<rhq:input-property
    name="listener.port"
    description="This is where the product will listen for incoming messages"
    required="true"
    defaultValue="8080"
    type="integer"/>

27.5.8.3. rhq:deployment-unit

バンドルによってデプロイされるアプリケーションや設定ファイルなどのバンドルコンテンツを定義します。デプロイメントユニットは、単純なテキストファイル、アーカイブ、またはアプリケーションサーバー、Web サーバー、またはデータベースを含む完全なソフトウェア製品です。デプロイメントユニットには、複数のアーカイブおよび設定ファイルを関連付けることができます。
一度に 1 つのデプロイメントユニットのみがプロビジョニングプロセスによりプロビジョニングされるため、バンドルレシピには 1 つの <rhq:deployment-unit> 要素のみを使用できます。

表27.6 要素の属性

attribute description Optional または Required
Name アプリケーションの名前。 必須
コンプライアンス
JBoss ON がバンドルがデプロイされているトップルートディレクトリー(デプロイメントディレクトリー)のすべてのファイルを管理すべきかどうかを設定します。filesAndDirectories の場合、トップデプロイメントディレクトリー(バンドルに含まれ ない ファイル)にある関連ファイルはすべて無視され、今後のバンドル更新のデプロイ時に上書きまたは削除されません。デフォルトは full です。これは、プロビジョニングプロセスがすべてのファイルおよびディレクトリーを管理し、バンドルにないものを削除または上書きすることを意味します。
root ディレクトリー内の既存のコンテンツは削除前にバックアップされるため、後で復元できます。バックアップディレクトリーは resourceID /home/.rhqdeployments/です/backup
任意
preinstallTarget デプロイメントユニットのインストール前に呼び出される Ant ターゲット。 任意
postinstallTarget デプロイメントユニットのインストール後に呼び出される Ant ターゲット。 任意

例27.4 rhq:deployment-unit

<rhq:deployment-unit name="appserver" preinstallTarget="preinstall" postinstallTarget="postinstall">

27.5.8.4. rhq:archive

アプリケーションのデプロイに関連するアーカイブファイルを定義します。アーカイブは ZIP または JAR ファイルになります。バンドルはアーカイブファイルを必要としないため、この要素は任意です。
注記
この名前には、明示的な値が必要です。Ant ${} プロパティー定義は処理されません。

表27.7 要素の属性

attribute description Optional または Required
Name
バンドルに追加するアーカイブファイルのファイル名。
重要
アーカイブファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイルのアーカイブファイルの場所への 相対パス を含める name 必要があります。
必須
Exploqued アーカイブのコンテンツがバンドル宛先ディレクトリー(true)に抽出および保存されるかどうか、または name 属性(false)に指定されるファイルと同じ相対ディレクトリーに保存するかどうかを設定します。ファイルが展開される場合、デプロイメントディレクトリーから展開されます。インストール後のターゲットは、展開後にファイルを移動するために使用できます。 任意
destinationDir このアーカイブまたは展開形式の結果がコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。この属性は、コピー先のファイルのディレクトリーを設定します。実際のファイル名は name 属性に設定されます。 任意

例27.5 rhq:archive

<rhq:archive name="file.zip">
    <rhq:replace>
         <rhq:fileset>
               <include name="**/*.properties"/>
         </rhq:fileset>
    </rhq:replace>
</rhq:archive>

27.5.8.5. rhq:url-archive

指定の URL を使用してアクセスするリモートアーカイブを定義します。これは、サーバーがバンドルディストリビューションファイルにアーカイブを直接組み込むのではなく、ネットワーク経由でアーカイブにアクセスする rhq:archive 点が異なります。

表27.8 要素の属性

attribute description Optional または Required
url
アーカイブファイルの場所に URL を指定します。アーカイブがデプロイメントディレクトリーにダウンロードされ、インストールされます。
注記
バンドルが正常にデプロイされるようにするには、このバンドルがデプロイされるすべてのエージェントマシンから URL にアクセスできる必要があります。エージェントが URL にアクセスできない場合、アーカイブをプルダウンできず、これをマシンにデプロイすることができません。
必須
Exploqued true の場合、アーカイブのコンテンツは展開され、バンドル宛先ディレクトリーに保存されます。false の場合、zip ファイルは圧縮され、最上位の宛先ディレクトリーに保存されます。
注記
ファイルが展開される場合、デプロイメントディレクトリーから展開されます。インストール後のターゲットは、展開後にファイルを移動するために使用できます。
任意
destinationDir このアーカイブまたは展開形式の結果がコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。この属性は、コピー先のファイルのディレクトリーを設定します。実際のファイル名は name 属性に設定されます。 任意

例27.6 rhq:url-archive

<rhq:url-archive url="http://server.example.com/apps/files/archive.zip">
    <rhq:replace>
         <rhq:fileset>
               <include name="**/*.properties"/>
         </rhq:fileset>
    </rhq:replace>
</rhq:url-archive>

27.5.8.6. rhq:file

アプリケーションの設定ファイルを特定し、処理するための情報が含まれます。これには、トークンの値が必要です。通常、設定ファイルはバンドルパッケージからデプロイメントディレクトリーに直接コピーされます。<rhq:file> 要素は、宛先にコピーされる前に処理を必要とするファイルを呼び出します。<rhq:file> 要素の属性は、バンドルディストリビューションの ZIP ファイルの raw ファイルの名前と、コピー先のターゲットファイルの名前を設定します。
raw ファイルは、アプリケーションのプロパティーまたは設定が含まれるアーカイブファイルに追加できます。これらの設定ファイルは、に記載されるようにユーザー定義トークンまたはシステム定義トークンでテンプレートすることができ 「Templatized 設定ファイルの使用」 ます。テンプレート化されたバンドルディストリビューションファイルに含まれるテンプレート化されたファイルは、それらを処理し、トークンが永続化されるように Ant レシピにリストする必要があります。
注記
この名前には、明示的な値が必要です。Ant ${} プロパティー定義は処理されません。

表27.9 要素の属性

attribute description Optional または Required
Name
未編集設定ファイルの名前。
重要
設定ファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイル内のファイルの場所への 相対パス を含める name 必要があります。
必須
destinationFile
宛先リソースのファイルの完全なパスおよびファイル名。相対パスは、最終的なデプロイメントディレクトリー(バンドルのデプロイ時に rhq.deploy.dir パラメーターで定義)への相対パスである必要があります。ディレクトリーとファイル名の両方が指定されていれば、絶対パスを使用することもできます。
注記
destinationDir 属性が使用されると、destinationFile 属性は使用 できません
必須(destinationDir を使用しない場合)
destinationDir
このファイルがコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。
この属性は、コピー先のファイルの ディレクトリー を設定します。実際のファイル名は name 属性に設定されます。
destinationFile 属性が使用されると、destinationDir 属性は使用 できません
必須(destinationFile を使用しない場合)
replace ファイルがテンプレート化され、トークンの値を取得するために追加の処理が必要であるかどうかを示します。 必須

例27.7 rhq:file

<rhq:file name="test-v2.properties" destinationFile="subdir/test.properties" replace="true"/>
destinationDir destinationFile 属性も使用しない場合、raw ファイルはバンドルディストリビューションの場所として deployment ディレクトリー配下の同じ場所に置かれます。

27.5.8.7. rhq:url-file

にあるように rhq:file、にあるように、トークンの値を持つアプリケーションの設定ファイルを特定して処理するための情報が含まれます。このオプションは、バンドルアーカイブに含めるのではなく、指定の URL からダウンロードされるリモートファイルを指定します。

表27.10 要素の属性

attribute description Optional または Required
url
テンプレートファイルに URL を指定します。このファイルは、デプロイメントディレクトリーにダウンロードされ、インストールされます。
注記
バンドルが正常にデプロイされるようにするには、このバンドルがデプロイされるすべてのエージェントマシンから URL にアクセスできる必要があります。エージェントが URL にアクセスできない場合、アーカイブをプルダウンできず、これをマシンにデプロイすることができません。
必須
destinationFile
宛先リソースのファイルの完全なパスおよびファイル名。相対パスは、最終的なデプロイメントディレクトリー(バンドルのデプロイ時に rhq.deploy.dir パラメーターで定義)への相対パスである必要があります。ディレクトリーとファイル名の両方が指定されていれば、絶対パスを使用することもできます。
注記
destinationDir 属性が使用されると、destinationFile 属性は使用 できません
この属性には、パス名とファイル名の両方を指定する必要があります。
必須(destinationDir を使用しない場合)
destinationDir
このファイルがコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。
この属性は、コピー先のファイルの ディレクトリー を設定します。実際のファイル名は name 属性に設定されます。
destinationFile 属性が使用されると、destinationDir 属性は使用 できません
必須(destinationFile を使用しない場合)
replace ファイルがテンプレート化され、トークンの値を取得するために追加の処理が必要であるかどうかを示します。 必須

例27.8 rhq:url-file

<rhq:url-file url="http://server.example.com/apps/files/test.conf" destinationFile="subdir/test.properties" replace="true"/>
destinationDir destinationFile 属性も使用しない場合、raw ファイルはバンドルディストリビューションの場所として deployment ディレクトリー配下の同じ場所に置かれます。

関連項目

27.5.8.8. rhq:property

注記
<rhq:property> タスクは標準の Ant 1.8 <property> タスクの拡張で、すべてのプロパティーをサポートします。標準の Ant 1.8 <property> タスクの詳細は、公式の Ant 1.8 ドキュメントを参照してください。
バンドルレシピは、標準の Ant 1.8 <property> タスクを使用するか、<rhq:property> タスクのいずれかを使用して追加のパラメーターを設定できます。
<rhq:property file=""> を使用してロードされるプロパティーは、ファイルへのパスは、デプロイメント前にバンドルが展開される作業ディレクトリーに関連していることを前提としています。このパスは未定義であるため、ユーザーはこの値に依存しません。ターゲットマシンで既知の絶対パスまたは親ディレクトリーにアクセスできない相対パスを使用することが推奨されます(「..」を使用)。
<property> または <rhq:property> によって参照されるファイルは、デフォルトでデプロイされず、必要なバンドルファイルです。プロパティーのロードに使用され、宛先にデプロイするファイルも、デプロイメントユニットの <rhq:file> タスクを使用して参照する必要があります。
<property> の既存の Ant 属性の他に、<rhq:property> タスクは <command>relativeToDeployDir</command> 属性もサポートします。

表27.11 要素の属性

attribute description Optional または Required
relativeToDeployDir
file 属性も使用され、相対パスである場合にのみ該当します。
デフォルトは false です。
true の場合、ファイルはバンドルのデプロイメントが実行される作業ディレクトリーの代わりにバンドルのデプロイディレクトリーに対して解決されます。
任意
この relativeToDeployDir 属性は、file 属性の相対ファイル参照を許可し、作業ディレクトリーではなくバンドルのターゲットデプロイディレクトリーに相対的な解決を行います。

27.5.8.9. rhq:audit

プロビジョニングプロセス中に使用するカスタム監査証跡メッセージを設定します。これは、追加のカスタムタスクを実行する複雑なレシピで便利です。タスクが処理される際に、rhq:audit 設定は追加の処理手順とその結果に関する情報をサーバーに送信します。

表27.12 要素の属性

attribute description Optional または Required
status 処理のステータス。使用できる値は SUCCESS、WARN、および FAILURE です。デフォルトは SUCCESS です。 任意
action 処理ステップの名前。 必須
info アクションのターゲット名や影響を受けるファイル名など、アクションの実行内容の短い概要。 任意
message アクションに関する追加情報を提供する簡単なテキスト文字列。 任意

例27.9 rhq:audit

<rhq:audit status="SUCCESS" action="Preinstall Notice" info="Preinstalling to ${rhq.deploy.dir}" message="Another optional message"> 
 Some additional, optional details regarding 
 the deployment of ${rhq.deploy.dir} 
</rhq:audit>

27.5.8.10. rhq:replace

は、アーカイブのデプロイ時にトークンの値を保持する必要があるアーカイブに含まれる子 <rhq:fileset> 要素の一時的なファイルを一覧表示します。
トークンを使用するファイルは、実際の値に置き換える必要があるファイルは、テンプレートファイルです。プロビジョニングプロセスが実行されると、token の値は定義された値に置き換えられます。この要素は、テンプレート化されたすべてのファイルを一覧表示します。トークン置換用のプロビジョニングシステムによって処理される唯一のファイルは、<rhq:replace> 要素に一覧表示されるファイルのみです。

例27.10 例

<rhq:archive name="file.zip">
    <rhq:replace>
        <rhq:fileset>
            <include name="**/*.properties"/>
        </rhq:fileset>
    </rhq:replace>
</rhq:archive>

27.5.8.11. rhq:ignore

新しいバンドルのデプロイ時に削除すべきではないデプロイメントディレクトリーのファイルを一覧表示します。これは、バンドルの初期デプロイメントには適用されず、アップグレード操作にのみ適用されます。
アプリケーションがデプロイされると、データファイルやログなどのインスタンス固有のファイルは作成でき、アプリケーションがアップグレードされた場合は保持する必要があります。のようなこの要素には <rhq:replace>、保存するインスタンス内のファイルまたはディレクトリーの一覧が含まれます。
注記
ファイルがレシピで無視される場合、バンドルのデプロイ時にファイルは削除されません。ただし、バンドルに同じ名前のファイルが存在する場合は、ローカルファイルは上書きされます。
バンドルにパッケージ化されているファイルを無視しないでください。ログやデータファイルなどのアプリケーションによって生成されたファイルのみがプロビジョニングプロセスによって無視される必要があります。これは、アップグレードされたインスタンス用に保持される必要があるためです。
重要
あるバンドルを別のバンドルのサブディレクトリーにデプロイできます(バンドル A はデプロイされ /opt/myapp、バンドル B にデプロイされます /opt/myapp/webapp1)。
この場合、Bundle A のレシピを設定して、Bundle B がデプロイされるディレクトリーを無視します。これにより、バンドル A の更新または再バージョンが Bundle B の設定を上書きするのを防ぎます。

例27.11 rhq:ignore

<rhq:ignore>
    <rhq:fileset>
        <include name="logs/*.log"/>
    </rhq:fileset>
</rhq:ignore>

関連項目

27.5.8.12. rhq:fileset

ファイルの一覧を提供します。
2 つの JBoss ON 要素: <rhq:replace> および <rhq:ignore> : アーカイブファイルまたはデプロイメントディレクトリーにファイル一覧を定義します。この要素にはファイルの一覧が含まれます。

表27.13 要素の属性

子要素 description
<include name=filename /> ファイルのファイル名。この場合 <rhq:replace>、これはアーカイブ(JAR または ZIP)ファイル内のファイルで、テンプレート化され、トークンの値が含まれる必要があります。これは <rhq:ignore>、アプリケーションのデプロイメントディレクトリーにあるファイルで、バンドルのアップグレード時に無視され、保持されるはずです。

例27.12 rhq:fileset

<rhq:replace>
     <rhq:fileset>
         <include name="**/*.properties"/>
     </rhq:fileset>
</rhq:replace>

27.5.8.13. rhq:system-service

プロビジョニングプロセスの一部として起動するスクリプトファイルを参照します。これは通常、init ファイルまたは同様のファイルで、デプロイされたアプリケーションがアプリケーションをシステムサービスとして設定するために使用できます。

表27.14 要素の属性

attribute description Optional または Required
Name スクリプトの名前。 必須
scriptFile スクリプトのファイル名スクリプトファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイルのファイルの場所への 相対パス を含める scriptFile 必要があります。 必須
configFile スクリプトによって使用される設定またはプロパティーファイルの名前。設定ファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイルのファイルの場所への 相対パス を含める configFile 必要があります。 任意
overwriteScript 既存の init ファイルを上書きしてアプリケーションをシステムサービスとして設定するかどうかを設定します。 任意
startLevels アプリケーションサービスの実行レベルを設定します。 任意
startPriority アプリケーションサービスの起動順序または優先度を設定します。 任意
stopPriority アプリケーションサービスの停止順序または優先度を設定します。 任意

例27.13 rhq:system-service

<rhq:system-service name="example-bundle-init" scriptFile="example-init-script"
      configFile="example-init-config" overwriteScript="true"
      startLevels="3,4,5" startPriority="80" stopPriority="20"/>

27.5.8.14. rhq:handover

バンドルコンテンツのハンドオーバーの目的は、バンドルターゲットのリソースコンポーネント、バンドルアーカイブに含まれるデプロイメントコンテンツの一部またはすべてに委譲することです。「ハンドオーバー」の名前は、バンドルコンテンツが実際にリソースコンポーネントに「処理」されているという概念から生じます。
ハンドオーバーの意図は、バンドルのターゲットコンポーネントがバンドルデプロイメントに参加できるようにすることです。これは、リソースがコンテンツをデプロイするためにファイルシステムの変更に依存しないインスタンスで特に役に立ちます。ハンドオーバーにより、定義されたアクションおよびアクションパラメーターと共にバンドルコンテンツをターゲットリソースコンポーネントに送信できます。
たとえば、アプリケーションを JBoss Enterprise Application Platform 6 ドメインにデプロイすることを検討してください。エージェントプラグインは、そのリソースすべてとの通信方法、これらのリソースにコンテンツをアップロードする方法をすでに把握しており、デプロイも行います。バンドルレシピにより、JBoss ON は JBoss Enterprise Application Platform 6 の JBoss ON プラグインをアプリケーション送信し、そのアプリケーションで実行するアクションを渡します(例: この Web アプリケーションをドメイン内の特定のサーバーグループにデプロイする)。
JBoss ON JBoss Enterprise Application Platform 6 プラグインは、コンテンツがオーバーすると多くのことを行う可能性があるため(バンドルをアプリケーションとしてデプロイ、CLI スクリプトとして実行など)、ハンドオーバーを使用する場合はアクションおよびアクションパラメーターが必要になります。
注記
プラグインのドキュメントを参照して、サポートするアクションおよび関連するパラメーターの一覧を表示します。JBoss Enterprise Application Platform 6 プラグインの詳細は、にナビゲートでき Administration > Configuration > Agent Plugins > JBoss Application Server 7.xます。また、バンドルターゲットリソースがすべてバンドルコンテンツのハンドオーバーに対応しているわけではない点に注意してください。
重要
バンドルパーミッションは、セットアップ中に慎重に検討する必要があります。コンテンツはバンドルコンテンツのハンドオーバーを使用して移動すると、システムが危険にさらされる可能性があります。たとえば、JBoss ON の JBoss Enterprise Application Platform 6 プラグインにスーパーユーザーのクレデンシャルが設定されていると、バンドル開発者は拡張パーミッションを持つ JBoss Enterprise Application Platform 6 CLI スクリプトを実行できます。JBoss ON サーバーにアップロードする前に、バンドルコンテンツとレシピを確認することが推奨されます。
JBoss ON バンドルサブシステムはファイルシステム指向であるため、実際の「uninstall」メカニズムはありません。元に戻すと、JBoss ON は実際にバックアップされたファイルを格納し、以前のバンドルレシピを再起動します。
パージに関して、JBoss ON はデプロイメントユニットのコンプライアンス属性値に従ってバンドル宛先ディレクトリーのみをクリーンアップします。
そのため、継承される内容は、従来の意味で元に戻したりパージされることはありません。JBoss ON では「move forward」のみが可能で、コンテンツのアンデプロイが後方に移動することができません。

表27.15 要素の属性

attribute description Optional または Required
action ターゲットリソースコンポーネントが実行するアクションの名前。 必須
FailOnError ターゲットリソースコンポーネントが失敗を報告すると ANT レシピビルドが失敗するかどうか。true または false。デフォルトは true です。 任意
以下のタグには(一意の) <rhq:handover> 子タグがある場合があります。
  • <rhq:file>
  • <rhq:url-file>
  • <rhq:archive>
  • <rhq:url-archive>
バンドル内の 2 つの部分をターゲットリソースコンポーネントに渡す必要がある場合は、バンドルレシピで宣言されたのと同じ順序で送信されます。

例27.14 rhq:handover

<rhq:file name="prepareDatasource.cli" replace="true">
   <rhq:handover action="execute-script" failonerror="false"/>
 </rhq:file>
 <rhq:archive name="website.war">
   <rhq:handover action="deployment">
  <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/>
  <rhq:handover-param name="serverGroup" value="${server.group}"/>
   </rhq:handover>
 </rhq:archive>
prepareDatasource.cli ファイルの内容は、website.war アーカイブコンテンツの前に常にターゲットリソースコンポーネントに渡されます。

27.5.8.15. rhq:handover-param

表27.16 要素の属性

attribute description Optional または Required
Name パラメーターの名前 必須
値の名前。 必須
<rhq:handover> 要素にはゼロ、1 つ以上の rhq:handover-param 子タグを持つことができます。

例27.15 rhq:handover-param

<rhq:file name="prepareDatasource.cli" replace="true">
  <rhq:handover action="execute-script" failonerror="false"/>
</rhq:file>
<rhq:archive name="website.war">
  <rhq:handover action="deployment">
    <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/>
    <rhq:handover-param name="serverGroup" value="${server.group}"/>
  </rhq:handover>
</rhq:archive>

関連項目

27.6. バンドルパッケージのテスト

ANT レシピは複雑になる可能性があるため、バンドルをデプロイする前に重要な(かつ有用)です。JBoss ON には、Ant プロビジョニングバンドルを迅速にテストするために使用できるコマンドラインツールが含まれています。

27.6.1. Bundle Deployer Tool のインストール

このツールは、JBoss ON サーバーまたはエージェントとは関係なく、どのマシンにもダウンロードおよびインストールできます。
  1. トップメニューの Administration タブをクリックします。
  2. 左側のメニューテーブル Downloads でを選択します。
  3. Bundle Deployer Download セクションまでスクロールし、パッケージのダウンロードリンクをクリックします。
  4. などのバンドルツールをインストールするディレクトリーに .zip ファイルを保存し /opt/ます。
  5. パッケージを展開します。
    cd /opt/
    
    unzip rhq-bundle-deployer-version.zip

27.6.2. Bundle Deployer ツールの使用

重要
このバンドルのデプロイメントツールは、プロビジョニングプロセスおよびデプロイされたアプリケーションをテストする場合に のみ 行われます。このツールは JBoss ON サーバーまたはエージェントと対話しないため、JBoss ON はこのツールでデプロイされたアプリケーションは認識されず、それらを管理できます。
  1. バンドルディストリビューションパッケージを展開して確認します(または、アプリケーションファイルが含まれる未展開ディレクトリーをコピーします)。例:
    mkdir /tmp/test-bundle
    cd /tmp/test-bundle
    unzip MyBundle.zip
  2. deploy.xml Ant レシピファイルがあるバンドルディストリビューションの最上位ディレクトリーを開きます。
  3. PATH にバンドルデプロイヤーツールの場所を設定します。
    PATH="/opt/rhq-bundle-deployer-3.0.0/bin:$PATH"
  4. bundle deploy ツールを実行し、-Dinput_properties 形式を使用して値を定義済みファイルのユーザー定義トークンに渡します。例:
    rhq-ant -Drhq.deploy.dir=/opt/exampleApp -Dlistener.port=7081
    これにより、アプリケーションにインストールされ /opt/exampleApp、ポート値の 7081 が設定されます。
    注記
    必要に応じて、rhq.deploy.id 属性を使用してデプロイメントの識別子を設定します。デフォルトは 0 で、新規デプロイメントを意味します。バンドルが UI にデプロイされると、サーバーは固有の ID をデプロイメントに割り当てます。新しいデプロイメントで rhq.deploy.id 属性を使用すると、サーバーの ID 割り当てがシミュレートされます。
    以前のデプロイメントがある場合には、rhq.deploy.id 属性を使用してバンドルのアップグレードパフォーマンスをテストすることができます。アップグレードを実行するには、新しい一意の ID 番号が必要です。

27.7. Provisioning Bundles

27.7.1. バンドルグループの管理

バンドルグループは、JBoss ON のアクセス制御を定義するのに不可欠なものです。バンドルはバンドルグループに属するまでデプロイできません。バンドルは、適切に設定されたロールに割り当てられます。

27.7.1.1. バンドルグループの作成

リソースグループは、で説明されてい 6章グループの管理 ます。リソースグループは、メンテナンス操作を統合するか、アクセス制御を維持することで、個々のリソースを整理し、全体的な管理を簡素化します。
バンドルグループはリソースグループに類似しています。バンドルグループはデプロイメント操作を統合し、アプリケーションライフサイクルの制御を容易にします。さらに重要なのは、バンドルグループは 2 つのファセットでアクセス制御のレベルを提供します。この 2 つのファセットでは、バンドルの作成およびデプロイバンドルとリソース制限の両方へのユーザーアクセスの制御によるバンドルのデプロイ先を制御することができます。
  1. トップメニューの Bundles タブをクリックします。
  2. 下部の Bundle Groups エリアで、New ボタンをクリックします。
  3. グループの名前と説明を入力します。
  4. グループメンバーを選択します。バンドルがアップロードされている場合は、作成時にそのバンドルをグループに追加できます。
    バンドルは、作成、更新、またはグループの編集時にバンドルグループに追加できます。
  5. Save ボタンをクリックします。

27.7.1.2. バンドルグループへのバンドルの割り当て

バンドルアップロードウィザード(新規バンドルおよび更新の両方)には、バンドルをバンドルグループに追加または削除するステップが含まれます。バンドルはいつでもバンドルグループから追加または削除することもできます。
バンドルがバンドルグループに属する場合、そのバンドルは階層内のそのバンドルグループの下に一覧表示されます。この組織は、バンドルの開発およびデプロイメントライフサイクルの定義に役立ちます。
ユーザーは、ユーザーが権限を持つバンドルグループに属するバンドルのみを認識できます。グローバルビューバンドルパーミッションを持つユーザーのみが 例外です。これらのユーザーは、グループ割り当て(グループに属さないバンドルを含む)に関係なく、すべてのバンドルを表示できます。バンドルがグループに属していない場合は、割り当てられていないグループ あります。グループに割り当てられると、階層内の場所が更新されます。

図27.4 バンドル階層のバンドルグループおよび未割り当てバンドル

バンドル階層のバンドルグループおよび未割り当てバンドル
重要
バンドルは、適用するアクセス制御のバンドルグループに所属する必要があります。つまり、バンドルはユーザーが表示したり、リソースにデプロイする前にバンドルグループに所属する必要があります。
  1. トップメニューの Bundles タブをクリックします。
  2. 下部の Bundle Groups エリアで、編集するバンドルグループの名前をクリックします。
  3. グループメンバーを選択して、グループから追加または削除します。ボックスでバンドルを選択すると、対応する矢印がアクティブになり、他のボックスに移動します。
  4. Save ボタンをクリックします。

27.7.2. バンドルの JBoss ON へのアップロード

レシピ、JAR、ZIP、設定ファイルなど、ディストリビューションに関連するすべてのファイルは JBoss ON からアクセスできる必要があります。ファイルをアップロードして JBoss ON データベースに保存するか、サーバーによってパッケージをダウンロードできる URL を設定する必要があります。
注記
ファイルすべてがアップロードする単一の ZIP ファイルに組み合わされている場合は、レシピファイルはパッケージの最上位になければなりません。
  1. トップメニューで、Bundles タブをクリックします。
  2. Bundles セクション下部で、New ボタンをクリックします。
  3. ディストリビューションパッケージまたはレシピファイルをアップロードします。
    JBoss ON サーバーでバンドルディストリビューションを利用する方法は 3 つあります。
    • URL FTP サイトや SVN または GIT リポジトリーなどの URL を参照し、利用可能な完全なバンドルディストリビューションファイルがあります。リポジトリーに認証が必要な場合は、サーバーがサイトに対して認証できるように、ユーザーアカウントのユーザー名とパスワードを指定できます。
      注記
      SVN または GIT リポジトリーを使用すると、ビルドシステムからパッケージを直接プルできます。
    • Upload ローカルシステムから JBoss ON サーバーに単一のバンドルディストリビューションファイルをアップロードします(すべての関連ファイルを含む)。
    • Recipe レシピファイルのみをアップロードしてから、バンドルに必要な追加のファイルは別々にアップロードされます。このオプションには、サーバーに送信される前にアップロードしたレシピを編集できる編集フィールドが含まれます。
  4. バンドルを割り当てる左側のボックスでグループを選択し、矢印をクリックして Assigned ボックスに移動します。
    バンドルグループはアクセス制御に必要です。グループ割り当てがないと、バンドルの表示や(グローバルビューバンドルパーミッションがない場合は)バンドルの表示やバンドルのデプロイができなくなります。
  5. 以前アップロードされなかった関連ファイルをアップロードします。URL およびについては、通常 Upload、すべてのファイルが 1 つのファイルにアップロードされるため、この画面では何もする必要はありません。Recipe オプションでは、レシピに記載されているすべてのファイルを、このステップで手動でアップロードする必要があります。
  6. 最後の画面には、新しいバンドルのすべての情報が表示されます。Finish をクリックし、新しいバンドルを保存します。

27.7.3. リソースへのバンドルのデプロイ

バンドルは、バンドルを JBoss ON グループ にデプロイして リソース にデプロイされます。バンドルをサポートするリソース(デフォルトではプラットフォームおよび JBoss AS リソース)が含まれる互換性のあるグループは、宛先のオプションとして自動的に一覧表示されます。
プラットフォームの場合、グループに異なるオペレーティングシステムおよびアーキテクチャーを含めることはできません。ただし、プロビジョニングプロセスでは、プラットフォームのアーキテクチャーに一致するようにデプロイメントディレクトリーとプロビジョニングファイルが自動的にフォーマットされるため、同じバンドルディストリビューションファイルとプロパティーをどのプラットフォームにも使用することができます。
  1. トップメニューで、Bundles タブをクリックします。
  2. ウィンドウの下部までスクロールし、Deploy ボタンをクリックします。
    インポートし、一覧にあるバンドルの名前をクリックし、バンドルページの上部にあるデプロイボタンをクリックします。
  3. 左側の一覧からデプロイするバンドルを選択し、矢印を使用して右側のボックスに移動します。
  4. バンドルを選択したら、宛先情報を定義します。
    宛先は、バンドルがデプロイされているリソースと、デプロイされるディレクトリーの組み合わせです。各宛先は各バンドルに対して一意に定義されます。
    宛先を定義するには、まず Resource ドロップダウンメニューからリソースグループを選択します。リソースグループはバンドルがデプロイされるリソースのタイプを識別し、リソースタイプは他のデプロイメントパラメーターを定義します。グループを選択すると、ベースの場所が 定義されます。プラットフォームの場合は、root ディレクトリーです。JBoss AS インスタンスでは、インストールディレクトリーになります。カスタムリソースの場合、ベースの場所はプラグイン記述子に定義されます。
    注記
    互換性のあるグループを作成していない場合や、このバンドルデプロイメント専用の新規グループを作成する場合は、+ アイコンをクリックしてグループを作成します。次に、プロビジョニングプロセスで続行します。
    バンドルをデプロイする実際のデプロイメントディレクトリーを設定します。このディレクトリーは、プラグイン定義のベースロケーションへの相対パスです。
  5. デプロイするバンドルのバージョンを選択します。利用可能なバンドルのバージョンが複数ある場合は、これらのバージョンのいずれかを選択できます。また、最新バージョンまたは現在デプロイされたバージョンをデプロイする簡単なオプションもあります。
  6. ユーザー定義のプロパティーがある場合は、次のページのフィールドに入力されます。ユーザー定義のプロパティーは、トークンを使用してバンドルレシピで設定されます。
  7. 特定のデプロイメントインスタンスに関する情報を入力します。このチェックボックスは、既存のデプロイメントディレクトリーのコンテンツを上書きするかどうか、または既存のファイルを保持するかどうかについてのオプションを設定します。
  8. 最後の画面には、パッケージのデプロイの進捗が表示されます。デプロイメント Finish を完了するには、をクリックします。

27.7.4. バンドルデプロイメント履歴の表示

バンドルには 2 つの情報エリアがあります。1 つはバージョンと、その宛先(デプロイ場所)用です。メインバンドルエントリーは、バージョンと宛先という 2 つのもののみを表示します。バージョンエリアはバンドル のコンテンツを追跡および制御 する方法であり、 宛先エリアはバンドルのデプロイプロセス を追跡し、制御する方法です。

図27.5 バンドル、バージョン、および宛先

バンドル、バージョン、および宛先
メインバンドルエントリーでバージョンを選択すると、レシピ( Summary タブ上)と、その特定のバージョン( Files タブ上のファイル)に関連する全ファイルが表示されます。Deployments タブには、バンドルの特定バージョンがデプロイされたすべての宛先とタイムスタンプとコメントが表示されます。

図27.6 バージョンのデプロイメント情報

バージョンのデプロイメント情報
宛先エントリーは、その宛先にデプロイされたバージョンの一覧のみを表示します。つまり、宛先エリアはアプリケーションの監査履歴を追跡するのに最適なエリアです。宛先へのバンドルバージョンの各デプロイメントは、宛先の下に表示され、ライブバージョンがマークされます。また、再バージョンには、デプロイメントがダウングレードされたバージョンが示されます。

図27.7 宛先のデプロイメント履歴

宛先のデプロイメント履歴
宛先エリアは、デプロイメントおよび更新の履歴を示す他に、新規バージョンを最も直接デプロイまたは元に戻すことができる場所です。

27.7.5. デプロイ済みバンドルの元に戻す

ant バンドルは、以前のバージョン番号またはそのバンドルの以前のデプロイメントにロールバックできます。これにより、特にテストおよび実稼働システム向けのアプリケーションのデプロイおよび管理を行う際に、追加の保護と柔軟性が得られます。
  1. トップメニューで、Bundles タブをクリックします。
  2. 左側のナビゲーションウィンドウでバンドルノードを展開し、その下の Destinations フォルダーを開きます。
  3. 左側のナビゲーションから宛先を選択します。
  4. 宛先のメインウィンドウで、Revert ボタンをクリックします。
  5. 次のページには、現在のデプロイメントの概要と、以前のデプロイメントの概要が表示され、元に戻されます。
  6. revert アクションに注記を追加します。必要に応じて、チェックボックスを選択してデプロイメントディレクトリーを消去し、以前のバージョンを新規にインストールします。
  7. 最終画面 Finish をクリックしてロールバックを完了します。

27.7.6. バンドルのクリーニング宛先へのデプロイ

バンドルは、アプリケーション、ファイル、または以前のバンドルデプロイメントがある宛先にデプロイできます。新規バンドルをデプロイする場合、プロビジョニングプロセスによる更新の処理方法は 2 つあります。
クリーンディレクトリーにバンドルをデプロイするには、のデプロイメントウィザードで実行 Clean Deploy する場合のチェックボックスを選択し 「リソースへのバンドルのデプロイ」 ます。

27.7.7. リソースからのバンドルの削除

バンドル を削除すると、バンドルに関連付けられたすべてのファイルが、すべてのターゲットリソースから削除されます。しかし、JBoss ON データベースからバンドルを削除しないため、後で他のリソースに簡単に再デプロイできます。
重要
パージされたミラーの正確なファイルは、バンドルがデプロイメントディレクトリーの管理方法になります。デフォルトでは、パージにはデプロイメントディレクトリー(compliance=full)の削除が含まれます。デプロイメントディレクトリーがアプリケーションサーバーディレクトリーなどの他のアプリケーションによって使用される場合は、他 deploy/ のアプリケーションやファイルも削除されます。パージ後には、ライブデプロイメントはなく、元に戻すものはありません。
  1. トップメニューで、Bundles タブをクリックします。
  2. 左側のナビゲーションウィンドウでバンドルノードを展開し、その下の Destinations フォルダーを開きます。
  3. 左側のナビゲーションから宛先を選択します。
  4. 宛先のメインウィンドウで、Purge ボタンをクリックします。
  5. プロンプトが表示されたら、バンドルされたアプリケーションおよび設定をターゲットリソースから削除する必要があることを確認します。

27.7.8. Ant Bundle のアップグレード

バンドルのアップグレードプロセスでは、ファイルの MD5 ハッシュコードを比較することで、アプリケーションのデプロイメントディレクトリー内のファイルをアップグレード(つまり上書き)するかどうかを決定します。アップグレードシナリオは複数あります。
  • 新しいファイルのハッシュコードが元のファイルとは異なり、ローカルの変更がない場合は、JBoss ON は既存ファイルに新しいファイルをインストールします。
  • 新規ファイルのハッシュコードが元のファイルとは異なり、ローカルの変更がある場合 、JBoss ON は元のファイルをバックアップし、新しいファイルをインストールします。
  • 新規ファイルのハッシュコードと元のファイルが同じで、元のファイルに ローカル な変更がある場合は、プロビジョニングプロセスにより元のファイルが保存されます。
  • 以前のバンドルにファイルがない場合、新しいバンドルにファイルがある場合には、新しいファイルが使用され、手動で追加したファイルはバックアップされます。
バックアップしたファイルは、デプロイメントの宛先 backup/ ディレクトリー内のディレクトリーに保存されます。元のファイルがアプリケーションのディレクトリーの外部にある場合(例: 相対的な場所ではなく絶対的な場所に基づいて保存されている場合)、これはデプロイメントの宛先 ext-backup/ ディレクトリー内のディレクトリーに保存されます。
注記
ファイルがレシピで無視される場合、ファイルは変更されません。バンドルにパッケージ化されたファイル 無視しないでください。ログやデータファイルなどのアプリケーションによって生成されたファイルのみがプロビジョニングプロセスによって無視される必要があります。これは、アップグレードされたインスタンス用に保持される必要があるためです。
完全に新規インストールが必要な場合は、クリーンなデプロイメントを実行できます。これは、で説明してい 「バンドルのクリーニング宛先へのデプロイ」 ます。

27.7.9. JBoss ON Server からのバンドルの削除

バンドルを削除すると、そのレシピと関連するファイルが JBoss ON データベースから削除されます。また、バンドルが属するバンドルグループから削除されます。
デプロイされたアプリケーションまたは設定はターゲットリソースではそのまま維持されます。
  1. トップメニューで、Bundles タブをクリックします。
  2. 左側のナビゲーションウィンドウでバンドルノードを展開し、その下の Destinations フォルダーを開きます。
  3. 左側のナビゲーションから宛先を選択します。
  4. 宛先のメインウィンドウで、Delete ボタンをクリックします。
  5. プロンプトが表示されたら、バンドルを削除することを確認します。

27.8. 拡張例: プロビジョニングプロセスでのバンドルグループおよびアクセス制御の使用

ロールは、異なるエンティティー間の対話(リソースグループ経由)、ユーザー、およびバンドル(バンドルグループ経由)を定義します。注記のように 「Provisioning and Agent User System Permission」、プロビジョニングでは、これらの関係がプロビジョニングライフサイクルのさまざまな部分の行に分類されます。バンドル/ユーザー関係はバンドルバージョンの作成に最も重要になりますが、バンドル/リソース関係はバンドルのデプロイに最も重要になります。
ロールはレイヤー化できます。有効なアクセス制御は、ユーザーが割り当てる全ロールの 累積 ルールです。これは、1 人のユーザーがそれぞれ異なるリソースグループへのアクセスを許可する複数のロールに属する場合、ユーザーはそれらのロールに一覧表示されている すべて のリソースグループにアクセスできます。バンドルグループも同様です。
つまり、ロールで定義されたリソースグループおよびバンドルグループは、ユーザーの許可されるプロビジョニングパスを定義するために機能することを意味します。この関係は、この関係 「アクセスとグループ」 に関連します。たとえば、ユーザーがリソースグループ A へのアクセスを許可するロールとバンドルグループ B へのアクセスを許可する別のロールにユーザーが属する場合、ユーザーはバンドルグループ B のバンドルをリソースグループ A のリソースにデプロイできますが、他のバンドルやその他のリソースにはデプロイできません。
このビルディングブロックのアプローチは、ロールのすべてのユーザーに対して、非常に複雑なリソース、バンドル、およびその他のユーザー間の非常に複雑な関係を非常に管理可能な方法で定義します。
注記
1 つのロールの設定を可能な限り制限します。リソースグループ/パーミッションおよびバンドルグループ/パーミッションに完全に異なるロールを使用することが有益である場合があります。これにより、特定のロールがどのアクセスを付与するかをより明確にすることができます。これにより、ユーザーに維持しやすくなります。
バンドルのデプロイには、アクセス制御の変更が多数あります。バンドルパーミッションを定義するロールは、エコーしてプロビジョニングワークフローを実行し、バンドルをデプロイするユーザー、および環境を指定します。
これらの例では、簡単な代表的なワークフローについて説明します。これらは、インフラストラクチャー、アプリケーションライフサイクル、およびユーザーグループに適用できます。

27.8.1. global v.作成およびデプロイを行うためのグループパーミッション

グローバルバンドルパーミッションにより、関連するグループに関係なく、システム上の全バンドルへのアクセス権が付与されます。
グローバルビューおよび作成パーミッションにより、バンドルグループとは独立してバンドルを作成できます。グローバルデプロイパーミッションにより、ロールと関連付けられていない場合でも、ユーザーが閲覧できるリソースグループにバンドルをデプロイできます。

例27.16 User Deploys Bundles anywhere

Role R1 <--- User U
   |
   v
View Bundles
Create Bundles
Deploy Bundles
グローバルデプロイパーミッションでは、ユーザーには、ユーザーが参照できるリソースグループを定義するロールが依然として必要です。ただし、このようなリソースグループは bundle ロールで指定する必要はありません。
グループパーミッションは、指定されたアクションをロール自体に指定されたグループに限定します。これは、バンドル作成パーミッション(グループ内のバンドルの作成)およびバンドルデプロイパーミッション(リソースグループへのデプロイバンドル)の両方に該当します。
デプロイメントを指定のリソースグループに制限するには、deploy を使用してロールの明示的なリソースグループ を必要とするパーミッションをグループ化します。

例27.17 Deploy Bundles to a Specific Resource Group: Single Role

Resource Group X ---> Role R <--- User U
                        ^
                        |
                 View Bundles
   Deploy Bundles To Group
グローバルパーミッションビューバンドル により、 ユーザーはシステム上の任意のバンドルを確認でき、単にバンドルを単一のリソースグループにデプロイする機能を制限するだけです。グローバルパーミッションは別の 方法で設定できますが、リソースグループはパーミッションをグループ 化するデプロイバンドルと同じロールに指定する必要があります。

例27.18 Deploy Bundles to a specific Resource Group: Two Roles

Resource Group X ---> Role R1 <--- User U    -->  Role R2
                         ^                           ^
                         |                           |
                Deploy Bundles To Group        View Bundles

27.8.2. Permissions and the Application Development Workflow

アプリケーションのプロビジョニングワークフローには、JBoss ON でバンドルバージョンを作成し、それらのバージョンを選択したリソースにデプロイするという 2 つの部分があります。
この 2 つのタスクは、組織内の異なるグループに分けることができます。たとえば、開発グループがバンドルを作成できるが、実稼働グループがバンドルのデプロイを行います。または QE のリードは JBoss ON でバンドルを作成し、QE チームはそれらをテストシステムにデプロイします。
グローバルなデプロイおよび作成パーミッションを設定できますが、予想以上の方法では、実際の環境は、ほとんどのユーザーを特定グループ内のアクションに制限します。
最初の概念的な部分は、ユーザーが特定のグループにバンドルを作成できるようにするパーミッションを作成します。このパーミッションは、異なるバンドルグループを持つ複数のユーザーに論理的に適用できるため、すべてのバンドルを表示するためのグローバルパーミッションは 2 番目のロールで設定できます。(これは、各ロールを可能な限り簡単に維持する原則です。)

例27.19 特定のバンドルグループでのバンドルの作成

Bundle Group A ---> Role R1 <--- User U --->  Role R2 
                         ^                         ^
                         |                         |
                Create Bundles In Group     View Bundles
複数のチームメンバーが相互のバンドルを更新する場合や、コミュニティーバンドルを維持する場合、これらのユーザーは指定のバンドルグループに対して同じ作成ロールに簡単に追加できます。この例では、削除パーミッションも指定します。

例27.20 複数ユーザーが各他のユーザーのバンドルを更新する

Bundle Group A
     |
     v
  Role R1 <--- User U1, User U2, User U3
     ^
     |
Create Bundles In Group
Delete Bundles From Group
このロールの配置は egalitarian で、同じバンドルグループ内で、他のロールユーザーのバンドルに対するロールの各メンバーが同等です。
多くのワークフローでは、バンドルの維持を担当するユーザーまたはセットが、別のグループがバンドルのデプロイを担います。この場合、1 つのグループは、指定の バンドルグループ へのグループパーミッションでグループパーミッションを持つロールに属し、ユーザーの個別のセットは、その バンドルグループおよび指定されたリソースグループに対するグループパーミッションへ のデプロイバンドルを持つロールに属します。

例27.21 Team Lead Creates Bundles - Team Members Deploy Bundles

Bundle Group A                                    Bundle Group A
     |                                                   |
     v                                                   v
  Role R1 <--- User TeamLeader   Resource Group X ---> Role R2 <--- Users TeamMember1, TeamMember2
     ^                                                   ^
     |                                                   |
Create Bundles In Group                         Deploy Bundles To Group
この方法では、アプリケーションのプロビジョニングサイクルの作成とデプロイ要素が分割されます。
ユーザーを個別のロールに 配置 し、パーミッションタイプの分割が重要です。単一のバンドルグループまたはリソースグループにロールを制限するのではなく、グローバルパーミッションで同じ方法を行うことができますが、その責任の分割は引き続き存在します。


[5] EAP 6 ドメインには、サーバーの定義済みデプロイメントディレクトリーがありません。他のメカニズムにより、デプロイメントは一元的に処理されます。

第28章 リソースレベルのコンテンツ更新の管理

JBoss Operations Network を使用すると、コンテンツをリソースに保存およびデプロイできます。これは、(JBoss AS サーバーと同様に)更新およびパッチを適用するか、アプリケーションのプロビジョニングおよびカスタムソフトウェアのデプロイに使用するリポジトリーを設定します。

28.1. コンテンツ

リソースのコンテンツは、WAR ファイルや EAR ファイル、設定ファイル、スクリプトなどのほとんどすべてのものになります。JBoss ON は、インベントリーのコンテンツ、リポジトリー、およびリソースを関連付けるための集中型フレームワークを提供します。

28.1.1. コンテンツの概要: パッケージ

パッケージ は、プラットフォームまたはサーバーやアプリケーションにインストールされているものです。これは、JAR ファイルまたは設定ファイルになります。パッケージは、リソースに何らかの形式のコンテンツを提供します。パッケージは JBoss ON-recognized リポジトリーを介してリソースに送信することも、JBoss ON サーバーにパッケージをアップロードしてからリソースに送信することもできます。
リソースは、リソースプラグインが利用可能なコンテンツと、サポートされるコンテンツの種類を認識している場合にのみ、コンテンツの関連付けまたは管理できます。たとえば、JBoss AS/EAP や Tomcat などのアプリケーションサーバーや Tomcat は EAR、WAR、JAR ファイルをコンテンツとしてサポートしますが、PostgreSQL などのデータベースではコンテンツタイプはサポートされません。
つまり、コンテンツは、リソースに関連するソフトウェアビット、スクリプト、設定ファイル、およびリソース自体の両方になります。コンテンツがリソースに追加されると、JBoss ON 階層の子リソースになりますが、新しいソフトウェアビットをアップロードすることで管理、元に戻す、更新、置き換えが可能です。親リソース(アプリケーションサーバーなど)はコンテンツをサポートします。子リソースは コンテンツバッキングリソースです。
コンテンツは、子リソースを手動で作成し(パッケージをアップロード)、またはパッケージをコンテンツソースに追加して親リソースにデプロイすると、リソースに追加できます。また、エージェントは、検出スキャンの一部として新規コンテンツをアクティブに チェック し、検出されたコンテンツをインベントリーに追加します。エージェントの繰り返しパッケージ検出スキャンには、サービススキャンのようにデフォルトの 24 時間間隔があります。

28.1.2. Content comes From: Providers and Repositories

コンテンツソース は、開発者およびコンテンツの配布元です。ソースは、外部のサードパーティーのソフトウェア開発者またはカスタムコンテンツを作成する内部開発チームになります。ソースから利用できるコンテンツのタイプには、ソフトウェアパッケージ(設定スクリプトなど)と更新(バージョンアップグレード、パッチ、エラータ)の両方が含まれます。
リポジトリー は、ユーザー定義のソフトウェアパッケージのコレクションで、1 つまたは複数のコンテンツソースから取得できます。リポジトリーには、アプリケーションやアプリケーションファミリーのパッケージや、ノートパソコン設定用リポジトリーや Web サーバーのインストールリポジトリーなど、特定の目的でパッケージが含まれる場合があります。
リポジトリーは、パッケージ用のコンテナーを別々に分離したものではありません。基本的には、利用可能なパッケージのサブセットを示すビューです。すべてのパッケージは JBoss ON データベースに保存されます。JBoss ON リポジトリーは、これらのパッケージをグループ化して、リソースを使用した管理を容易にし、ユーザー(「リポジトリーおよびパッケージの認可」)のアクセス制御のメカニズムを提供する方法です。
リソースを JBoss ON に設定したコンテンツリポジトリーにサブスクライブできます。これにより、一貫性のある管理者が設定されたコンテンツをリソースに配信するためのスムーズで信頼できるメカニズムが提供されます。

28.1.3. パッケージバージョンと履歴

パッケージは JBoss ON 内でバージョン管理され ます。パッケージがリソースまたはコンテンツソースに追加されると、インストーラーはバージョン番号の入力を求められます。これは UI のディスプレイ番号として使用されます。
この表示バージョン番号は必要ありません。指定されていない場合、JBoss ON サーバーは、パッケージの計算された SHA-256 チェックサム、および META-INF/MANIFEST.MF ファイル内の仕様バージョンおよび実装バージョン(EAR および WAR 用)を基に番号を取得します。
SPEC(IMPLEMENTATION)[sha256=abcd1234]

図28.1 パッケージバージョン番号

パッケージバージョン番号
たとえば、バージョン番号が記載された META-INF/MANIFEST.MF ファイルの場合:
Manifest-Version: 1.0
Created-By: Apache Maven
Specification-Title: My Example App
Specification-Version: 1.0.0-GA
Specification-Vendor: Example, Corp.
Implementation-Title: My Example App
Implementation-Version: 1.x
Implementation-Vendor-Id: org.example
Implementation-Vendor: Example, Corp.
...
これにより、次のようなパッケージのバージョン番号が作成されます。
1.0.0-GA(1.x)[sha256=abcd1234]
この META-INF/MANIFEST.MF ファイルに仕様バージョンまたは実装バージョンのいずれかが含まれていない場合には、その 1 つのバージョンのみが使用されます。たとえば、実装バージョンのみが指定される場合:
(1.x)[sha256=abcd1234]
バージョン番号が指定されていない場合、SHA が識別子として使用されます。SHA は内部的に識別子として使用されます。
[sha256=abcd1234]
展開形式の WAR および EAR の場合、計算された SHA-256 チェックサムが MANIFEST.MF ファイルに追加されます。これにより、エージェントは検出スキャン中にファイルを確認して、パッケージのバージョンを迅速に検証できます。
Manifest-Version: 1.0
Created-By: Apache Maven
RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
...
アーカイブされていないコンテンツの場合、チェックサムはすべてのパッケージ検出スキャンで再計算され、インベントリー内のチェックサムと比較されます。
注記
展開形式の WAR および EAR は JBoss サーバーおよび Tomcat サーバーにデプロイできます。コンテンツデプロイメントプロセスにより META-INF/MANIFEST.MF ファイルを編集するため、デプロイされたコンテンツはアップロードされたコンテンツパッケージと全く同じではありません。
明確なバージョン管理システムでは、パッケージライフサイクルを明確かつ効果的な方法で処理できます。更新されたコンテンツはデプロイ時に追跡でき、更新は一貫して適用でき、パッケージを以前のバージョンに戻すことができます。同じリポジトリーに同じパッケージの異なるバージョンを含めることもできます。そのため、異なるリソースに異なるバージョンを適用することが可能です。
注記
異なるコンテンツソースのパッケージバージョンを同じリポジトリーに関連付けることができます。
リソースにパッケージがインストールされると、そのリソースおよびパッケージのコンテンツ履歴に記録されます。1 つのパッケージに関連するファイルが複数あるため、コンテンツ履歴に複数のファイルが記録され、そのパッケージバージョンに関連付けられます。
注記
バージョン管理は、EAR や WAR などのリソースと共にコンテンツニットのみに重要になります。コンテンツソース(アラートに使用される CLI スクリプトなど)に保存されているその他のタイプのコンテンツはバージョンを追跡しません。バンドルにデプロイされたコンテンツは、コンテンツシステムではなく、バンドル定義でバージョン管理を処理します。

28.1.4. リポジトリーおよびパッケージの認可

ユーザーがリポジトリーのコンテンツにアクセスできるようにする必要がある理由は多くあります。最も一般的なのは、リソース上のパッケージを管理することですが、リポジトリーでサーバー CLI スクリプトを使用してアラートに応答するなど、その他の理由があります。
JBoss ON では、プライベート情報や機密情報を保護する必要性を考慮して、コンテンツへのクリアかつ簡単なアクセスの必要性をバランスを取ることができます。JBoss ON は、コンテンツリポジトリーの明確な 承認 ルールを定義します。
すべてのユーザーは、そのユーザーのパーミッションに関係なく、リポジトリーを作成し、パッケージをそのユーザーにアップロードする機能があります。
リポジトリーの作成時に、リポジトリーへのアクセスを制御する設定があります。
  • 所有者 は、リポジトリーへの書き込みアクセスを設定します。特定のユーザーに属するリポジトリーを割り当てます。ユーザーの指定がない場合は、manage リポジトリーパーミッションを持つユーザーのみが、これらのリポジトリーにアクセスする権限を持ちます。
  • リポジトリーへの読み取り (download)アクセス。これは、リポジトリーの管理権限を持つ所有者とユーザーのみが、リポジトリーを表示できるかどうかを設定します。所有者に関係なく、パブリックリポジトリーはすべてのユーザーが参照できます。

図28.2 リポジトリーの所有者とアクセス設定

リポジトリーの所有者とアクセス設定
リポジトリーマネージャー(リポジトリーの管理権限を持つユーザー)は、リポジトリーの所有権およびプライバシー設定を変更できます。リポジトリーの管理権限を持たないユーザーはプライバシー設定を変更できますが、所有権を変更することはできません。リポジトリーは常に所有するか、リポジトリーマネージャーによって管理されます。
注記
パブリックリポジトリーをプライベートに切り替えるときは、十分に注意してください。アラートに対応してサーバー CLI スクリプトを実行するなど、これらのリポジトリーに依存する操作は、ユーザーの権限がリポジトリーにアクセスするのに不十分な場合に機能しなくなります。
JBoss ON は リポジトリー のアクセス制御パーミッションを使用して、リポジトリーへの管理者アクセス権限を定義します。このパーミッションを持つユーザーは、リポジトリーの所有者に関係なく、設定されたリポジトリーを管理できます。所有者のないリポジトリーは、リポジトリーパーミッションを持つユーザーのみが管理できます。最後に、このパーミッションを持つユーザーのみがコンテンツソースをリポジトリーに関連付けることができます。他のすべてのユーザーは、パッケージをリポジトリーに手動で追加する必要があります。

28.1.5. コンテンツの領域に関する考慮事項

コンテンツは、ディスク領域の要件に大きく影響する可能性があります。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部で、コンテンツベースのリソースを元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。
したがって、バックエンドデータベース(Oracle または PostgreSQL)をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。

28.2. コンテンツソースの作成

コンテンツソースは、JBoss ON にソフトウェアパッケージを提供するメカニズムであり、JBoss ON のコンテンツ管理をリソースに提供します。JBoss ON は複数の異なる種類のコンテンツソースをサポートします。

表28.1 コンテンツソースのタイプ

ソースタイプ description 認証情報が必要ですか?
リモート URL リモート URL からダウンロードします。これは、FTP などの複数の異なるプロトコルを使用できます。 いいえ
HTTP
Remote URL コンテンツソースと同様に、ネットワーク接続をソースに接続します。これは特に HTTP プロトコルを使用します。
HTTP コンテンツソースは HTTP プロキシーに接続することもできます。
HTTPS はサポートされません。
オプションで、認証情報が指定の HTTP サイトまたはプロキシーサーバーにログインできるようになります。 [a]
JBoss Customer Portal Feed(RSS) リモート URL コンテンツソースと同様に、JBoss の累積パッチのカスタマーポータルの RSS フィードで特別に機能します。
[a]
ローカルディスク (ローカルシステムまたは NFS マウント上にある)単一のローカルディレクトリーに接続し、ダウンロードする指定されたタイプおよびアーキテクチャーのパッケージを探します。 いいえ
[a] コンテンツソース設定のパスワードは、JBoss ON データベースで難読化されます。

28.2.1. コンテンツソースの作成(一般)

  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Content Sources 項目を選択します。
  3. 現在のコンテンツソースの一覧の下にある CREATE NEW ボタンをクリックします。
  4. ソースからコンテンツの配信方法を定義するコンテンツソースタイプを選択します。では、異なるコンテンツソースを 「コンテンツソースの作成」 記述します。
  5. コンテンツソースタイプを選択すると、フォームが自動的に開き、リソースの基本的な詳細および設定が入力されます。これらの基本詳細は JBoss ON サーバーのコンテンツソースを特定し、各コンテンツソースタイプについて同じですが、コンテンツソースタイプに固有の設定です。
    • コンテンツソースプロバイダーの名前とオプションの説明を指定します。
    • スケジュールは、JBoss ON データベースのコンテンツがコンテンツソースによって更新される頻度を設定します。これは標準の Quartz Cron Syntax を使用します。
    • lazy ロード設定は、インストール時(Yes)またはすべてのパッケージをすぐにダウンロードする必要がある場合にのみパッケージをダウンロードするかどうかを設定します。
    • ダウンロードモードは、コンテンツの JBoss ON の保存方法を設定します。デフォルトはで DATABASE、すべてのパッケージを JBoss ON データベースインスタンスに保存します。その他のオプションは、パッケージをネットワークファイルシステムに保存するか、パッケージを全く保存しないことです。
  6. コンテンツソースの他の設定情報を入力します。必要な情報は、コンテンツソースのタイプによって異なります。これには、URL、ディレクトリーパスなどの何らかの接続情報や、ユーザー名とパスワードなどの認証情報が必要になります。
    注記
    コンテンツソースに保存されたパスワードは JBoss ON データベースで難読化されます。

28.2.2. コンテンツソースの作成(ローカルディスク)

ローカルディスクコンテンツソースは、の説明どおりにセットアップされていますが 「コンテンツソースの作成(一般)」、コンテンツソースのセットアップ リポジトリー設定の両方の値は、コンテンツ同期が機能するのに重要です。
単一のコンテンツソースは複数のリポジトリーに関連付けることができますが、これはローカルディスク設定で該当します。ローカルディスクプロバイダーの場合、コンテンツソースはルートディレクトリーを定義し、リポジトリー名はパッケージを含むサブディレクトリーを特定します。

図28.3 ローカルディスク構造

ローカルディスク構造
この構造により、複数のリポジトリーでコンテンツプロバイダーで同じベースディレクトリーを使用できます。
JBoss ON は、コンテンツソース設定(root ディレクトリー)とリポジトリー設定(subdirectory)の組み合わせに基づいて、ローカルディスクの情報を取得します。sync が機能するには、リポジトリーの名前がパッケージを含むサブディレクトリーと同じである必要があります。
重要
各サブディレクトリー名は、ルートディレクトリーツリーの階層により一意である必要があります。たとえば、/export/myContentSource/test とというディレクトリーは使用しないでください /export/myContentSource/subdir/test
同じ名前のディレクトリーが 2 つあると、パッケージの同期動作が予測できない場合があります。
ローカルディスクプロバイダーを設定するには、以下を実行します。
  1. のように、コンテンツソースを設定し 「コンテンツソースの作成(一般)」 ます。
    注記
    同期するサブディレクトリーがすでに存在する場合、コンテンツソースの設定では、サブディレクトリー名に基づいてローカルディスクプロバイダーに関連付けるリポジトリーが要求されます。
  2. ルートディレクトリーパスを入力します。
  3. JBoss ON サーバーがコンテンツストレージにプルするパッケージを特定するために使用するコンテンツパッケージ情報を入力します。
  4. にあるようにリポジトリーを作成し 「リポジトリーの作成」、使用するサブディレクトリーの名前を記入します。
    重要
    各サブディレクトリー名は、ルートディレクトリーツリーの階層により一意である必要があります。たとえば、/export/myContentSource/test とというディレクトリーは使用しないでください /export/myContentSource/subdir/test
    同じ名前のディレクトリーが 2 つあると、パッケージの同期動作が予測できない場合があります。
  5. ローカルシステムにサブディレクトリーを作成し、JBoss ON コンテンツシステムに追加する必要のあるパッケージでコピーします。

28.3. リポジトリーの管理

リポジトリーは基本的にコンテンツソースのデータと JBoss ON インベントリー内の特定のリソース間のマッピングになります。

28.3.1. リポジトリーの作成

  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Repositories 項目を選択します。
  3. 現在のリポジトリーの一覧の下にある CREATE NEW ボタンをクリックします。
  4. 名前と説明を入力します。また、リポジトリーの所有者およびパブリックまたはプライベートのどちらの所有者を設定して、リポジトリーの認可制限を設定します。
    所有者を設定できるのは、リポジトリー権限を持つユーザーのみです。リポジトリーのパーミッションのないユーザーが作成するすべてのリポジトリーは、そのユーザーに自動的に適用されます。
  5. をクリックし Saveます。
  6. Repositories ページの新しいリポジトリーの名前をクリックします。
  7. オプション。デフォルトの同期スケジュールを変更するには、Edit ボタンをクリックし、その Sync Schedule フィールドに cron 形式の新しいスケジュールを入力します。
  8. にあるように、コンテンツソースをリポジトリーに提供するコンテンツを追加し 「コンテンツソースのリポジトリーへの関連付け」 ます。
    複数のコンテンツソースは、リポジトリーにコンテンツを提供できます。
  9. にあるように、リソースをリポジトリーに関連付け 「リソースのリポジトリーへの関連付け」 ます。リソースは、リポジトリーと関連付けられている場合に限り、リポジトリーからパッケージを受信できます。
    注記
    特定のリソースまたはタイプのリソースを検索し、複数のリソースを一度にサブスクライブできます。

28.3.2. コンテンツソースのリポジトリーへのリンク

リポジトリーを正しいコンテンツソースにマップする方法は複数あります。リポジトリーの設定を編集すると、リポジトリーを複数のコンテンツソースにサブスクライブできます。コンテンツソースをインポートすると、コンテンツソースを複数のリポジトリーに同時に追加できます。

28.3.2.1. コンテンツソースのリポジトリーへの関連付け

  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Repositories 項目を選択します。
  3. Repositories ページで、リストにあるリポジトリーの名前をクリックします。
  4. リポジトリーの詳細ページの Content Sources セクションで、Associate ボタンをクリックして既存のコンテンツソースをリポジトリーに追加します。
  5. リポジトリーに関連付けるコンテンツソースの横にあるチェックボックスを選択します。
  6. ASSOCIATE SELECTED ボタンをクリックします。

28.3.2.2. コンテンツソースのリポジトリーへのインポート

同じコンテンツソースが複数のリポジトリーに関連付けられる場合は、コンテンツソースを同時にすべてのリポジトリーにインポートできます。
  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Repositories 項目を選択します。
  3. Repositories ページで、IMPORT ボタンをクリックします。
  4. インポートするコンテンツソースの名前でラジオボタンを選択します。
  5. コンテンツソースを選択すると、そのコンテンツソースで利用可能なリポジトリーの一覧が自動的に開きます。この Available repositories.... エリアで、コンテンツソースに関連付ける各リポジトリーの名前でチェックボックスを選択します。
  6. IMPORT SELECTED ボタンをクリックします。
注記
で説明されているように 「Content comes From: Providers and Repositories」、リポジトリーは JBoss ON データベースに保存されているパッケージのサブセットについてユーザー定義のビューです。リポジトリーは別のコンテナーではありません。
UI を使用してパッケージを 1 つのリポジトリーに追加すると、パッケージが指定されたリポジトリーにない場合でも、すでにパッケージが存在することを要求して失敗する可能性があります。これは、同じ名前のパッケージが のリポジトリーに存在し、データベースで競合が発生するためです。
現在、2 つのリポジトリーで同じパッケージを持つことや、リポジトリー間でパッケージを移動したり、共有したりすることはできません。
CLI スクリプトを使用すると、この問題を回避できます。JBoss ON CLI スクリプトは、パッケージバージョンデータに自動的にパッケージをアップロードするユーザーのユーザー名を保存します。アップロードしたすべてのパッケージにユーザーがアクセスできる場合は、どのリポジトリーにパッケージが含まれるかを予測して、そのパッケージを管理することができます。

28.3.3. リソースのリポジトリーへの関連付け

コンテンツは、そのリソースが最初にリポジトリーと関連付けられている場合にのみリソースに送信できます。リソースとリポジトリーの関連付けは、リソースエントリーを編集するか、またはリポジトリーエントリーを編集して実行できます。

28.3.3.1. リポジトリーへのリソースの追加

  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Repositories 項目を選択します。
  3. Repositories ページで、編集するリポジトリーの名前をクリックします。
  4. Resources セクションで、SUBSCRIBE ボタンをクリックしてリソースをリポジトリーに追加します。
  5. リポジトリーに関連付けるリソースの横にあるチェックボックスを選択します。名前またはタイプ別にリソースの一覧を絞り込むことができます。
  6. SUBSCRIBE SELECTED ボタンをクリックします。

28.3.3.2. リソースのリポジトリーの管理

プラットフォームなどの一部のリソースタイプには、コンテンツサブスクリプションの制御を可能にするコンテンツタブがあります。
  1. 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
  2. リソースの Content タブをクリックします。
  3. Subscriptions サブタブを開きます。
  4. この Available Repositories セクションには、リソースがサブスクライブしていないリポジトリーの一覧があります。すべてのリポジトリーのチェックボックスをクリックして、リソースをサブスクライブします。
  5. をクリックし ADD SUBSCRIPTIONSます。
同じプロセスを使用して、コンテンツリポジトリーからリソースのサブスクライブを解除できます。

28.4. パッケージのアップロード

パッケージはコンテンツソースから取得できますが、個別のパッケージは JBoss ON サーバーに直接アップロードすることもできます。JAR ファイル、基本スクリプト、JBoss ON CLI スクリプト、パッチなど、さまざまなパッケージタイプがサポートされます。
  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Repositories 項目を選択します。
  3. Repositories ページで、リストにあるリポジトリーの名前をクリックします。
  4. ページの下部までスクロールし、Upload Packages セクションまでスクロールします。
  5. Upload File ボタンをクリックして、パッケージをアップロードします。
  6. ポップアップウィンドウで、Add ボタンをクリックしてパッケージを参照し、Upload ボタンをクリックします。
  7. パッケージに関する情報には、名前やデフォルトの UI バージョン番号など、自動的に入力されます。パッケージタイプ、アーキテクチャー、およびその他の必要な情報を設定します。
    バージョン番号が設定されている場合、この値は UI に表示されます。そうでない場合は、の MANIFEST.MF (EAR および WAR の場合)の仕様バージョンおよび実装バージョン、またはパッケージ自体について計算された SHA-256 値を基にして、バージョン番号が算出されます。内部では、パッケージは SHA 値で識別されます。
    SPEC(IMPLEMENTATION)[sha256=abcd1234]
    注記
    EAR および WAR の展開形式のコンテンツについては、計算された SHA-256 バージョン番号が MANIFEST.MF ファイルに書き込まれます。
  8. CREATE PACKAGE ボタンをクリックして、パッケージをリポジトリーに追加します。

28.5. コンテンツソースまたはリポジトリーの同期

元のコンテンツソースは JBoss ON に含まれており、コンテンツパッケージは JBoss ON にプルされ、保存されます。元のコンテンツソースで加えられた変更は、2 つのソースを 同期 して JBoss ON にプルする必要があります。
同様に、ソースとリポジトリーが同期されると、コンテンツソースの変更がリポジトリーに送信されます。

28.5.1. スケジューリングの同期

同期はすでに JBoss ON の content source エントリーでスケジュールされています。このスケジュールには、標準の cron 形式があります。
*     *    *    *     *  [sync-command]
-     -     -     -     -
|     |     |     |     |
|     |     |     |     +----- Day of Week (0=Sunday ... 6=Saturday)
|     |     |     +------- Month (1 - 12)
|     |     +--------- Date (1 - 31) 
|     +----------- Hour (0 - 23)
+------------- Minute (0 - 59)
たとえば、火曜日と金曜の 3am でソースを JBoss ON と同期するには、以下を実行します。
0 3 * * 2,5
Quartz ドキュメント では、cron 構文の詳細を説明します。
ソースのスケジュールの同期時間を編集するには、以下を実行します。
  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Content Sources またはRepositories 項目を選択します。
  3. 編集する項目の名前をクリックします。
  4. Sync Schedule フィールドの cron スケジュールをリセットします。
  5. をクリックし Saveます。

28.5.2. コンテンツソースまたはリソースの手動同期

コンテンツソースに大きな変更が加えられると、手動で同期を開始して変更を JBoss ON サーバーに手動で送信できます。
  1. トップメニューで、Administration タブをクリックします。
  2. 左側の Content メニューテーブルで、Content Sources または Repositories 項目を選択します。
  3. 編集する項目の名前をクリックします。
  4. Synchronize ボタンをクリックします。同期試行はすべて、操作の結果とともに画面下部に表示されます。
注記
ソースまたはリポジトリーへの接続をテストするには、Test Connection ボタンをクリックします。これにより、パッケージをプルダウンする前に JBoss ON サーバーがコンテンツソースに接続できるようになります。
複数のソースを同期するには、メインのコンテンツソースまたはリポジトリーページに移動し、同期する各コンテンツソースのチェックボックスを選択して、Sync Selected ボタンをクリックします。

28.6. リソースのコンテンツバージョンの追跡

リポジトリーを介してパッケージがリソースにインストールされるたびに、その操作が表示されます。これには、インストールの失敗も含まれます。リソースのコンテンツパッケージの履歴は、History サブタブの下にある Content タブで確認できます。

図28.4 リソースのパッケージ履歴

リソースのパッケージ履歴
パッケージ履歴には、操作の開始および完了時間と、開始したユーザーの両方が表示されます。これは、監査、インシデントと応答の関連付け、リソース設定の追跡に役立ちます。

パート V. JBoss リソースの管理

第29章 JBoss ON による JBoss リソースの管理方法

JBoss Operations Network は、JBoss サーバーインスタンスの管理に役立つ追加のツールを提供します。これらの管理ツールは、JBoss インベントリーを手動で設定し、JBoss パッチを適用することをすべて取り上げます。

29.1. JBoss ON の JBoss ソフトウェアの使用方法

JBoss AS/EAP はアプリケーションサーバーであるため、そのコアゴールは web コンテンツの配信です。JBoss アプリケーションを効果的に管理するために、JBoss ON はアプリケーションサーバー自体と、提供するコンテンツの両方を管理します。
JBoss ON はサーバーレベルでは、他のタイプの管理リソースと同様に JBoss サーバーおよびサービスをリソースとして処理します。EAP、SOA-P、Data Services、Business Rules Management などの各主要な JBoss サーバータイプはエージェントリソースプラグインで実装されます。これらのプラグインは、個別にインストールされるプラグインパックで利用でき ます。これらのプラグインは、メインのサーバータイプをサポートするさまざまな関連サービスおよびプロジェクトを定義します。たとえば、EAP プラグインパックには、EAP、Hibernate、Cache Service、JMS、JMX のエージェントプラグインが含まれます。
JBoss ON は以下を管理および監視することで、アプリケーションサーバーおよびサービスのサポートを提供します。
JBoss ON では、JBoss リソースと JBoss コンテンツには非常に密接な関係があります。EAR、WAR、Web コンテキストなどの Web コンテンツは、ハイブリッドタイプのリソースとして処理されます。親子階層が定義され、インスタンスの起動/停止、メトリックとアラート、その他のタイプのリソースとしての設定プロパティーなどの管理タスクがあります。
ただし、コンテンツベースのリソースは、更新履歴、コンテンツリポジトリー、以前のバージョンに戻す機能などとともに、ソフトウェアパッケージとして処理されます。
その後、JBoss コンテンツリソースの管理は、コンテンツとアプリケーションサーバーの関係に重点を置いています。
(リソースおよびコンテンツの)管理の鍵は、すべてが JBoss アプリケーション全体、ドメイン全体、およびマシン全体に統一される点です。

29.2. 本ガイドの「対象」

非常に一般的な点で、JBoss ON は JBoss リソースを他のリソースと同様に処理し、監視とアラートを提供し、設定とドリフトを管理し、インベントリーを表示および制御します。
別のレベルでは、JBoss 製品と JBoss ON との密接な統合により、JBoss ON は JBoss サーバーを管理する独自の方法を提供します。JBoss ON は、JBoss リソースで直接実行しようとするよりも簡単な方法で一般的な操作を合理化できます。また、集約型であり、JBoss リソースに中心的なビューを提供します。
そのため、本ガイドの目的は、通常 JBoss ON の使用方法を推測することではありません。本ガイドは、JBoss ON を使用して JBoss リソースで特定のタスクを実行する方法を中心に説明します。したがって、JBoss リソースをより効果的に管理する方法を説明します。これには、以下が含まれます。
  • EAR および WAR およびその他の Web アプリケーションのコンテンツ管理
  • JBoss サーバークラスターの管理
  • JBoss サーバードメインの管理
  • JBoss インスタンスの監視
JBoss ON を使用するための概念および一般的な手順は、で設定したドキュメントを参照してください http://docs.redhat.com/docs/en-US/JBoss_Operations_Network/index.html

29.3. JBoss プラグインパックのインストール

すべてのリソースは、エージェントプラグインを使用してサーバーとエージェントに識別さ れます。エージェントプラグインは、サポートされるメトリクス、操作、設定のプロパティー、リソースバージョンなどのサポートリソースを定義しました。
JBoss 製品は、個別のプラグインパックで利用可能な独自の特別なプラグインを使用してサポートさ れます。これらのプラグインパックは、JBoss 製品を検出および管理する前にインストールする必要があります。
JBoss プラグインのインストールおよび削除については、JBoss ON インストールガイド で説明されています。
JON サポートされる構成マトリックスは、 https://access.redhat.com/articles/112523

第30章 一般的なタスク

30.1. 検出用のカスタム JVM の設定

Generic JMX プラグインは Java プロセスを検出します。これは非常に簡単なプラグインです。一部のタイプの JVM を除外する機能以外に、プラグインは 適切 に設定された Java プロセスを検出し、JMX サーバーとしてインポートします。汎用 JMX サーバーでは、ロギング、スレッド、メモリーなどのサブシステムも JMX サーバーの子としてインポートされます。
この背景情報はすべて、Resource Reference: Monitoring, Operation, and Configuration Options』の JMX リソースドキュメントで 説明されています。カスタムプラグインの作成については、「カスタムプラグイン」 で説明されています
JBoss ON では、リソースを検出してインベントリーに追加できるように JVM リソース自体を設定する必要があります。

30.1.1. Discovery に必要な JVM 設定

エージェントは、特定のパラメーターを基にしてリソースを特定し、検出された設定に基づいてエージェントに接続してリソースを検出し、管理します。汎用 JMX プラグインを使用して Java プロセスを検出するには、以下のいずれかの方法で接続するように設定する必要があります。
  • Sun JMX リモーティングが有効になり、コマンドラインでポートシステムプロパティーが指定されます。
    -Dcom.sun.management.jmxremote.port=12345 com.xyz.MyAppMain
  • Sun/Oracle 互換の Java プロセスには、 com.sun.tools.attach API およびリソースキーはコマンドラインでシステムプロパティーとして指定されます。
    -Dorg.rhq.resourceKey=KEY com.xyz.MyAppMain

30.1.2. 検出からの Java プロセスの除外

Generic JMX プラグインは、カスタムプラグインをベースにして特定のタイプの Java プロセスを検出し、管理できるように拡張するように設計されています。たとえば、Java プロセスとして JBoss ON エージェントは通常 Generic JMX プラグインによって検出されますが、Generic JMX プラグインを停止する Agent プラグインによって検出されます。同様に、JBoss EAP サーバーおよび Tomcat サーバーは、一般的なプラグインではなく、サーバー固有のプラグインによっても検出されます。
別のプラグインが検出できるリソースは、Generic JMX Server 検出から除外する必要があります。または、エージェントログに誤った競合エラーが記録されている可能性があります。
検出スキャンから除外する Java プロセスは、JBoss ON エージェント設定で定義されます。エージェントには Java オプションがあります。これは rhq.jmxplugin.process-filters、Generic JMX Plug-in 検出スキャンで特に無視する文字列を一覧表示します。Java プロセスにフィルターに文字列が含まれる場合は、JMX サーバーとして検出から除外されます。 [6].
デフォルトのエージェント設定は、エージェント、JBoss ON サーバー、および Tomcat サーバーのクラスをフィルターします。
RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Drhq.jmxplugin.process-filters=org.rhq.enterprise.agent.AgentMain,org.jboss.Main,catalina.startup.Bootstrap"
除外フィルターを追加するには、以下を指定します。
  1. エージェントの設定ファイルを開きます。
    [jbosson-agent@server ~]$ vim agentRoot/rhq-agent/conf/agent-configuration.xml
  2. RHQ_AGENT_ADDITIONAL_JAVA_OPTS リンクで、除外する文字列を rhq.jmxplugin.process-filters オプションに追加します。これは、指定のプロセスのコマンドラインにあるクラス名またはその他の識別文字列になります。
    例:
    RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Drhq.jmxplugin.process-filters=org.rhq.enterprise.agent.AgentMain,org.jboss.Main,catalina.startup.Bootstrap,com.abc.OtherAppMain"
    rhq.jmxplugin.process-filters 値は文字列のコンマ区切りリストです。
  3. --config オプションを指定してエージェントを再起動して、新しい設定を読み込む。
    [jbosson-agent@server ~]$ agentRoot/rhq-agent/bin/rhq-agent.sh --config

30.1.3. JVM リソースの手動インポート

前述 「Discovery に必要な JVM 設定」 のように、エージェントによって自動的に検出される Java プロセスに使用する接続設定が 2 つだけあります。特に、これらの 2 つの接続設定はいずれも、リモーティングまたはアタッチに Sun 管理 API を使用します。
Java プロセスは、サポートされる形式で JMX リモーティング(Sun または IBM リモーティングを意味する)を有効にする限り、自動検出に想定される設定を使用していない場合でも、手動でインベントリーにインポートできます。
注記
リソースの検出およびインポートを実行するには、JVM インスタンスを実行する必要があります。
  1. トップメニューの Inventory タブをクリックします。
  2. platform リソースを選択します。
  3. プラットフォームの Inventory タブをクリックします。
  4. Inventory タブ下部の Import ボタンをクリックして JMX サーバーリソースタイプを選択します。
  5. JVM のタイプを選択し、選択した JVM のタイプに応じて、すべての接続プロパティーを正しく設定します。
  6. JVM の接続情報を入力します。これは JVM タイプによって異なりますが、URL やポートなどのオプション、クライアントライブラリーのディレクトリーパス、クラス用のディレクトリーパス、ログイン認証情報が含まれます。
  7. をクリック Finish し、インスタンスのインポートを行います。

30.2. セキュアな JMX サーバーに接続するためのエージェントの有効化

デフォルトでは、JBoss EAP の JMX サーバーがセキュアモードで実行されます。ただし、エージェントはセキュアなモードで JMX サーバーを 検出 できますが、適切な認証情報を検出できないため、セキュアな JMX サーバーに 接続 できません。
たとえば、JMX サーバーには以下のシステムプロパティーがあります。
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=5222
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=/jmxremote.access
エージェントの JMX プラグインは、JMX サーバーのプロセスのコマンドラインを検査します。JMX サーバーへの接続に使用するポートを検出しますが、JMX サーバーの認証情報を取得するためにパスワードおよびアクセスファイルを読み取ることはできません。
注記
エージェントは JMX サーバーに接続できないため、サーバーが問題なく動作している場合でも、リソースに DOWN 可用性状態を割り当てます。
エージェントが JMX サーバーに接続できるようにする方法は複数あります。

jmx-console-users.properties ファイルを編集します。

通常、エージェントは JbossASInstallDir/server/default/conf/props/ ディレクトリーの jmx-console-*.properties ファイルから接続認証情報を 読み取ります。

JMX サーバーがセキュリティー保護されている場合は、jmx-console-users.properties ファイルにエントリーがないため、エージェントが認証情報を取得する方法がありません。
  1. 編集する jmx-console-*.properties ファイルを開きます。例:
    [root@server ~]# vim JbossASInstallDir/server/default/conf/props/jmx-console-users.properties
  2. admin ユーザーの行をアンコメントまたは追加します。
    admin=admin
動作しない場合は、リソースの接続設定を編集します。

リモートアクセスファイルを使用するように接続設定の編集

デフォルトでは、エージェントはアクセス jmx-console-*.properties ファイルではなくユーザー名にファイルを使用します。JMX サーバーのコマンドラインで指定したリモートエンドポイントを経由して、エージェントがアクセスファイルを使用するようにリソースの接続設定を変更することができます。

  1. トップメニューの Inventory タブをクリックします。
  2. Servers Inventory、または JBoss EAP インスタンスを開き、その子に移動し、JMX サーバーインスタンスを見つけます。
  3. JMX サーバーのエントリーページでタブを開き、Connection Settings サブ Inventory タブを選択します。
  4. JMX リモートアクセスファイルに設定するユーザー名とパスワードを入力します。
  5. Save ボタンをクリックします。

親リソースから接続するための接続設定の編集

JBoss ON は親リソースに接続し、それを使用してリモーティングエンドポイント経由で接続するのではなく、JMX サーバーに接続できます。親は内部認証を使用して子リソースに接続できるため、ユーザークレデンシャルを使用する必要はありません。

  1. トップメニューの Inventory タブをクリックします。
  2. Servers Inventory、または JBoss EAP インスタンスを開き、その子に移動し、JMX サーバーインスタンスを見つけます。
  3. JMX サーバーのエントリーページでタブを開き、Connection Settings サブ Inventory タブを選択します。
  4. プロパティー 以外 のすべての接続プロパティーの設定を解除し Type ます。
  5. Type プロパティーで、Parent 値を選択します。
  6. Save ボタンをクリックします。


[6] 除外されたプロセスは、別のエージェントプラグインで引き続き検出できます。

第31章 JBoss EAP 5 の管理

31.1. JBoss EAP/AS 5 サーバーの検出

ほとんどの JBoss Enterprise Application Platform は、設定なしで子リソースの検出と監視を可能にする方法で設定されます。エージェントがリソースの検出および管理を試みる際に、一般的な設定に基づいて特定の仮定を使用してこれらのリソースを特定し、接続します。JBoss Enterprise Application Platform にこれらの仮定とは異なる設定がある場合、JBoss ON がそのシステムを完全管理できない可能性があります。
ここでは、特定の JBoss Enterprise Application Platform リソースタイプを検出または管理するために必要な設定を説明します。

31.1.1. JBoss AS/EAP 5 JVM の検出および管理

JBoss EAP リソースに対して JVM リソースおよびそのサブシステム(メモリー、スレッド、ロギングなど)を検出する JBoss ON エージェントでは、MBean を登録する場所としてプラットフォーム MBean サーバーを使用するよう JBoss EAP インスタンスを設定する必要があります。
必要に応じて JBoss Enterprise Application Platform 起動スクリプトを編集して、プラットフォーム MBean サーバーを使用します。
  1. run.conf ファイルを開きます。たとえば、Red Hat Enterprise Linux の場合は以下のようになります。
    [root@server ~]# vim jbossInstallDir/bin/run.conf
  2. プラットフォーム MBean サーバーを使用するための JAVA_OPTS 設定を追加します。
    Red Hat Enterprise Linux の場合:
    JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
    Windows の場合:
    set JAVA_OPTS=%JAVA_OPTS% -Djboss.platform.mbeanserver
  3. JBoss Enterprise Application Platform を再起動します。

31.1.2. JMX およびプロファイルサービスへのリモートアクセスの有効化

監視や実行操作などの管理タスクでは、エージェントが JBoss EAP/AS インスタンスの JMX サーバーに接続できる必要があります。そのため、リモート JMX アクセスを有効にする必要があります。
  1. JBoss Naming Protocol サーバー(JNP)がデプロイされていることを確認します。(デフォルトではデプロイされます。)
    jboss-service.xml ファイルを開きます。
    [root@server ~]# vim jbossInstallDir/server/config/conf/jboss-service.xml
    次に、JNP コネクターを有効にする行があることを確認します。
    <mbean code="org.jboss.naming.NamingService"> ... </mbean>
  2. 必須ではありませんが、JNP サービスの認証を有効にすることが推奨されます。(これはデフォルトで有効になっています。)
    1. jmx-invoker-service.xml ファイルを開きます。
      [root@server ~]# vim jbossInstallDir/server/config/deploy/jmx-invoker-service.xml
    2. JMX コネクター認証の行を追加します。
      <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
                           securityDomain="java:/jaas/jmx-console"/>
    3. 管理ユーザーが JMX ユーザーのプロパティーファイルに一覧表示されていることを確認します。新しい JBoss EAP リソースが検出されると、エージェントはこのファイルから JMX ユーザー名とパスワードを読み取り、検出された JBoss EAP リソースの接続設定に保存します。これらの設定は、EAP サーバーの JNP サービスに接続するために使用されます。
      [root@server ~]# vim jbossInstallDir/server/config/conf/props/jmx-console-users.properties
    4. ユーザー情報をアンコメントまたは追加します。これは、単純なキー/値のペア username=password です。例:
      admin=admin
  3. JBoss Enterprise Application Platform を再起動します。

31.1.3. 起動スクリプト引数、環境変数、および JAVA_OPTS の設定

31.1.3.1. スクリプト検出と設定の開始

JBoss EAP 5 サーバーの検出の一環として、JBoss ON はサーバーが実行されている環境の検出を試みます。特に、検出プロセスはランタイム環境の検出を試行します。
  • 検出プロセスでは、EAP サーバーの起動に使用された開始スクリプト(カスタム起動スクリプトか、またはカスタム起動スクリプト)が特定 run.sh|bat または試行されます。
  • Discovery は、開始スクリプトが機能するために必要な run.conf ファイルまたは親プロセスに設定された環境変数のサブセットを検出します。
    注記
    検出プロセスで一部の環境変数が検出されますが 、検出スキャンは JAVA_OPTS 値になりません。
    開始スクリプトの接続プロパティーは意図的に JAVA_OPTS 値のために run.conf ファイルに移されます。
  • 検出は、開始スクリプト自体に渡される引数を検出しようとします。
検出された設定は、EAP 5 リソースの Start Script Environment Variables および Start Script Arguments 接続設定に保存されます。
検出スキャンが一部のスクリプト設定を検出できない場合(エージェントは EAP 5 サーバーとは異なるユーザーとして実行され、親プロセスの読み取りができない場合)、正常に失敗します。可能な情報をすべて収集し、空の値を無視します。
注記
Start Script Environment Variables および Start Script Arguments 接続設定は、リソースの初回検出時に 1 回だけ検出されます。その後、接続設定設定で接続設定を変更することはできますが、ローカルシステムで行った変更は検出されません。たとえば、サーバーが特定の値(など -XX:PermSize=256M)で検出されると、サーバーが別の設定値で後で再起動すると、引数の値は更新されません。
スクリプト引数と環境変数は、開始スクリプトの実行時にエージェントによって使用される唯一の変数です。これらの引数および環境変数は、他の設定や親プロセスに追加されません。EAP 5 接続の開始スクリプト設定は決定論的です。
以前のバージョンのプラグインでは、EAP/AS 5 サーバーには、起動スクリプトの特定および実行の一環として、エージェントによって使用される Java ホームディレクトリーの設定およびバインドアドレス(hostname または IP)が含まれていました。
Script Arguments フィールドが空の場合、バインドアドレスと Java ホームディレクトリー [7] 起動スクリプトを呼び出す際にも使用されています。スクリプト引数が設定 れている場合は、バインドアドレスと Java ホームの値は無視されます。
スクリプト引数の値は、その他の開始スクリプトの接続設定を上書きします。

31.1.3.2. スクリプト引数およびドリフト監視の開始

JBoss ON はディレクトリーや特定のファイルを監視して、設定の ドリフト を確認することができます。詳細はを参照してください 15章設定項目の管理
管理者は重要なリソースを管理するのに、ドリフト監視は重要ですが、いくつかの設定で必要になるか、または有益である場合もあります。start スクリプト引数を使用すると、ドリフトアラートをトリガー せず に EAP 5 サーバーの定義設定をオーバーライドできます。
開始スクリプトのオプションはすべての接続設定であるため、すべての変更は変更履歴に記録され、簡単に表示および元に戻されます。これにより、システムプロパティーと Java 設定がトレース可能となり、必要な場合は修正が可能になります。

例31.1 ドリフト定義を自動化せずにシステムプロパティー

Tim the IT Guy は、すべての実稼働 EAP 5 サーバーが環境を使用する特定の設定セットを作成します。その後、テンプレートに設定が加わるモニタリングおよび関連付けまたはピン用にドリフト定義テンプレートを作成します。
テンプレートのドリフトを使用する EAP 5 サーバーは、これらの構成設定に準拠する必要があります。Tim the IT Guy は、実稼働サーバーが特定の設定からドリフトした場合に通知するアラートを作成します。これは、Example Co. の実稼働アプリケーションサーバーに対する重要な安全対策です。
ただし、実稼働サーバーでは、動作中のハードウェアやその他のアプリケーションが若干異なるため、効果的に実行するために異なるヒープサイズが必要になります。
TI Guy が別のヒープサイズを使用するようにシステムプロパティーを追加する場合、一定のドリフトアラートを受信するか、サーバー側の自動スクリプトを実行してドリフト設定を修正すると、編集した設定が上書きされる可能性があります。
開始スクリプトで異なるヒープ設定を設定すると、Tim は設定ファイルを編集せずにそのシステムの正しい設定を適用できるため、アラート可能な設定のドリフトはありません。

31.1.3.3. 起動スクリプト設定の変更

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 5 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Inventory タブを開き、Connection Settings サブタブを選択します。
  5. Operations セクションを展開します。
  6. 開始スクリプトの設定を変更または追加します。これらは、EAP 5 サーバーで起動または再起動の操作を実行する際に JBoss ON エージェントが使用するスクリプトおよび設定です。
    • カスタムの開始スクリプトを使用するには、パスとスクリプト名を入力します。
    • 必要に応じて、開始スクリプトの実行時にスクリプトで使用する接頭辞を入力します。
    • 各行に 1 つずつ環境変数を設定します。
    • スクリプト引数を設定します(行ごとに 1 つ)。通常の JAVA_OPTS の場合、これらの引数は通常 -X -D、またはです -P。便利な -XX 引数の一部は、Sun の JVM オプションのドキュメントに記載されています。
      EAP 5 のデフォルト起動スクリプトは - 形式の run.shスクリプトを使用するため、引数はその形式を使用します。カスタムスクリプトは、異なる引数またはオプションを使用できます。
  7. ページ上部の Save ボタンをクリックします。

31.2. JBoss EAP 5 つのリソースの作成

31.2.1. データソースの作成

注記
新しいリソースを作成してエージェントプラットフォームで検出する必要があるため、新しい子リソースが JBoss ON インベントリーに追加され、認識されるまでに数分かかることがあります。
  1. データソースをデプロイする JBoss サーバーインスタンスを検索します。
  2. 選択した JBoss サーバーインスタンスの詳細ページで、Inventory タブを開きます。
  3. Create New ドロップダウンメニューで、の項目を選択し - Data Sourcesます。
  4. データソースのテンプレートを選択します。データソースに共通の情報を入力するためのデータソーステンプレートは 3 つあります。
    • デフォルトのテンプレートは、PostgreSQL や MySQL などの SQL データベースで使用されます。
    • Oracle Local TX は、ローカルトランザクションを含む Oracle データベースに使用されます。
    • Oracle XA テンプレートは、XA トランザクションを使用する Oracle データベースに使用されます。
  5. リソース名などの分かりやすい設定と共に、デプロイする特定の子リソースの情報を入力します。
    • 作成するデータソースのタイプ(No TX データソース、ローカル送信データソースまたは XA データソース)
    • バインドに使用する DataSource ラッパーの一意の JNDI 名。
    • たとえば、JDBC ドライバーまたは DataSource クラスの完全修飾名。 org.postgresql.Driver
    • などの JDBC ドライバー接続 URL 文字列。 jdbc:postgresql://127.0.0.1:5432/foo
    • データソースへの接続に使用するユーザー名およびパスワード
    • このデータソースの接続プールの最大サイズおよび最大プールサイズ
    Advanced Settings このエリアでは、その他の設定が可能です。

31.2.2. 接続ファクトリーの作成

注記
新しいリソースを作成してエージェントプラットフォームで検出する必要があるため、新しい子リソースが JBoss ON インベントリーに追加され、認識されるまでに数分かかることがあります。
  1. 接続ファクトリーをデプロイする JBoss サーバーインスタンスを検索します。
  2. 選択した JBoss サーバーインスタンスの詳細ページで、Inventory タブを開きます。
  3. Create New ドロップダウンメニューで、の項目を選択し - Connection Factoryます。
  4. リソース名などの分かりやすい設定と共に、デプロイする特定の子リソースの情報を入力します。
    • tx-connection-factory(トランザクション)または no-tx-connection-factory(トランザクションなし)のいずれかで作成する接続ファクトリーのタイプ。
    • バインドに使用する DataSource ラッパーの一意の JNDI 名。
    • データソースへの接続に使用するユーザー名およびパスワード
    • このデータソースの接続プールの最大サイズおよび最大プールサイズ
    Advanced Settings このエリアでは、その他の設定が可能です。

31.2.3. JMS キューおよびトピックの作成

JMS キューと JMS トピックは、JBoss サーバーインスタンスの子である JBossMQ サービスまたは JBossMessaging サービスリソースの子リソースです。
注記
新しいリソースを作成してエージェントプラットフォームで検出する必要があるため、新しい子リソースが JBoss ON インベントリーに追加され、認識されるまでに数分かかることがあります。
  1. JMS キューまたはトピックをデプロイする JBoss メッセージングサービスを検索します。
  2. 選択した JBoss メッセージングサービスの詳細ページで、Inventory タブを開きます。
  3. Create New ドロップダウンメニューで、- JMQ JMS Topic またはを選択し - JMQ JMS Queue ます。
  4. リソース名などの明確な設定以外に、JMS Queue または JMS Topic エントリーには 2 つの追加パラメーターが必要です。
    • JMX オブジェクト名として使用するキューまたはトピックの名前。
    • バインドに使用する DataSource ラッパーの一意の JNDI 名。
    Advanced Settings このエリアでは、その他の設定が可能です。

31.3. アプリケーションのデプロイ

JBoss サーバーにデプロイされたアプリケーションは、特別なタイプのリソースです。JBoss ON インベントリーにはサイトがあり、JBoss AS/EAP サーバーの子です。この方法では、リソースとして検出または作成することができます。ただし、一部の JBoss 子リソース(EAR および WAR)はコンテンツであるため、保存されたソフトウェアパッケージとして処理され、JBoss サーバーにデプロイされます。これらのアプリケーションでは、パッケージを JBoss サーバーにアップロードすることで、子リソースが最初に作成されます。その後、それらはコンテンツのように管理され、更新されたパッケージがコンテンツリポジトリーに追加され、JBoss サーバーに適用されます。

31.3.1. アプリケーションをデプロイするための領域に関する考慮事項

コンテンツベースのリソースをデプロイすると、ディスク領域の要件に大きく影響する可能性があります。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部で、コンテンツベースのリソースを元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。
したがって、バックエンドデータベース(Oracle または PostgreSQL)をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。

31.3.2. EAR ファイルおよび WAR ファイルのデプロイ

重要
新たにデプロイされたコンテンツは、正常に作成された場合でも 24 時間以上 JBoss ON インベントリーに表示されない場合があります。デフォルトでは、サービスの検出スキャンは 24 時間ごとにのみ行われます。
即座に表示するには、エージェントで 実行プロンプトのコマンド 操作を実行し、discovery コマンドを入力します。これで検出スキャンが実行されます。
  1. EAR または WAR をデプロイする JBoss サーバーインスタンスを検索します。
  2. 選択した JBoss サーバーインスタンスの詳細ページで、Inventory タブを開きます。
  3. 下部の Create New メニューで、- Web Application (WAR) またはの項目を - Enterprise Application (EAR)適宜選択します。
  4. バージョン番号を入力します。
    これはリソースには使用されません。実際のバージョン番号は、に含まれる spec バージョンおよび実装バージョン(指定されている場合) MANIFEST.MF、またはパッケージ自体に対して計算される SHA-256 値に基づいて算出されます。
    SPEC(IMPLEMENTATION)[sha256=abcd1234]
    のバージョン番号が定義されていない場合は MANIFEST.MF、SHA 値が使用されます。SHA 値は常にパッケージバージョンを内部的に識別するために使用されます。
    注記
    EAR または WAR ファイルがデプロイ後に展開されると、MANIFEST.MF ファイルが更新され、計算された SHA バージョン番号が組み込まれます。例:
    Manifest-Version: 1.0
    Created-By: Apache Maven
    RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
    ...
    パッケージのバージョン管理の詳細は、を参照してください 「パッケージバージョンと履歴」
  5. EAR/WAR ファイルをアップロードします。
  6. デプロイするアプリケーションに関する情報を入力します。
    • ファイルがデプロイ時に展開(未展開)されるかどうか。
    • EAR パッケージまたは WAR パッケージをデプロイするディレクトリーへのパス。宛先ディレクトリーは JBoss サーバーインスタンスのインストールディレクトリーに相対的です。このディレクトリーには絶対パスが含まれたり、親ディレクトリーに移動したりすることはできません。
    • ターゲットディレクトリーの同じ名前の既存ファイルをバックアップするかどうか。
EAR/WAR ファイルの確認が完了すると、新しい子リソースがタブの Child History サブ Inventory タブに表示されます。

図31.1 WARE リソース

WARE リソース

31.3.3. アプリケーションの更新

EAR または WAR リソースの作成後、変更は更新されたコンテンツパッケージのように処理されます。EAR/WAR リソースの更新は、その EAR/WAR リソースエントリーに新しいパッケージをアップロードして適用するのと同じです。
  1. JBoss ON UI で EAR または WAR リソースを参照します。
  2. EAR または WAR リソースの詳細ページで Content タブを開き、New サブタブをクリックします。
  3. UPLOAD NEW PACKAGE ボタンをクリックします。
  4. UPLOAD FILE ボタンをクリックします。
  5. ポップアップウィンドウで Add ボタンをクリックし、アップロードする更新された WAR または EAR ファイルにローカルファイルシステムを参照します。
  6. UPLOAD ボタンをクリックしてファイルを読み込み、ウィンドウを終了します。
  7. メイン形式で、WAR または EAR ファイルパッケージを保存するリポジトリーを選択します。存在する場合は、そのリソースに既存のリポジトリーまたはサブスクライブされたリポジトリーを選択します。それ以外の場合は、新規リポジトリーを作成します。
  8. 必要に応じて、EAR/WAR パッケージのバージョン番号を設定します。
    これが設定されている場合、この値は UI に表示されます。そうでない場合は、に含まれる spec バージョンおよび実装バージョン(指定されている場合) MANIFEST.MF、またはパッケージ自体に対して計算される SHA-256 値に基づいて、バージョン番号が算出されます。内部では、パッケージは SHA 値で識別されます。
    SPEC(IMPLEMENTATION)[sha256=abcd1234]
    パッケージのバージョン管理の詳細は、を参照してください 「パッケージバージョンと履歴」
  9. 新しいパッケージの詳細を確認してから、をクリックし CONTINUEます。
パッケージが正常にアップロードされると、UI は Content タブの履歴ページにリダイレクトします。

図31.2 リソースのデプロイメント履歴

リソースのデプロイメント履歴

31.3.4. アプリケーションの削除

EAR/WAR アプリケーションを削除することは、その EAR/WAR リソースエントリーに関連付けられた現在デプロイされているパッケージを削除するのと同じです。
  1. JBoss ON UI で EAR または WAR リソースを参照します。
  2. EAR または WAR リソースの詳細ページで Content タブを開き、Deployed サブタブをクリックします。
  3. EAR/WAR パッケージでチェックボックスを選択し、DELETE SELECTED ボタンをクリックします。

31.4. パッチ RSS フィードバックからの JBoss パッチの適用

コンテンツ管理を使用して、累積パッチを JBoss EAP 4 に適用できます。デフォルトでは、JBoss ON サーバーは JBoss Patch Content Source および JBoss Patch Repository で事前設定されています。
注記
JBoss Enterprise Application Platform 5 以降では、Patch RSS フィードバックを使用したパッチ更新はサポートされません。

31.4.1. JBoss リソースのパッチ適用方法の計画

JBoss ON は JBoss カスタマーポータル(CP)で利用可能なパッチを自動的に適用できます。パッチがリリースされると、カスタマーポータルの RSS フィードが更新され、GUI の最新のパッチを提供および一覧表示する JBoss ON が監視されます。
パッチの適用方法の計画には、以下の 2 つの部分があります。
  • コンテンツソースの特定および設定
  • 手動手順の実行方法の計画

31.4.1.1. コンテンツソースの特定

コンテンツソース は、JBoss ON サーバーを何らかのコンテンツ配信メカニズムに接続します。JBoss 製品では、コンテンツソースはカスタマーポータルで、すべての JBoss 製品のパッチがすべて含まれています。(コンテンツソースは、製品および環境に応じて別のコンテンツリポジトリーになります。)
コンテンツソースは、場所を特定します。JBoss ON 内の リポジトリー は、コンテンツソースをパッチが適用されるインベントリーのリソースにマップします。
JBoss パッチでは、デフォルトのコンテンツプロバイダーは JBoss カスタマーポータルポータルによって提供される累計パッチに接続します。コンテンツプロバイダーに関連付けられたデフォルトのリポジトリーは、パッチに関するメタデータとパッチ自体が JBoss ON ON に格納されます。
JBoss ON エージェントは、リソースでパッチプロセスを実行するエンティティーです。エージェントは更新を通知され、サーバーから情報をプルし、管理された JBoss インスタンス内のローカル JAR およびクラスファイルを更新します。パッチ適用プロセスは、サーバー設定プロファイルまたはベース設定とは独立して実行されます。
JBoss Enterprise Application Platform(EAP)4 は、JBoss ON の JBoss カスタマーポータルでパッチの更新を受け取り、適用できます。
注記
EAP 5 以降ではパッチを利用できません。
注記
カスタマーポータルでは、製品または製品の特定のバージョンにのみ利用できるのは、カスタマーポータルにその製品のパッチがある場合に限り利用できます。JBoss ON は、JBoss カスタマーポータルに依存してパッチ情報を提供します。

31.4.1.2. 手動ステップのプランニング

パッチによっては、XML 設定ファイルを編集するなど、追加の手動変更が必要になります。手動の介入が必要な状況がいくつかあります。
  • パッチが適用されるファイルは設定に表示されません。
  • 手動で削除する必要があるファイルがあります。
  • XML や Java プロパティーファイルなどの設定ファイルには、手動で適用する必要のあるパッチが必要です。
  • Seam が使用されており、手動でパッチを当てる必要があります。
基本的に、カスタム設定でのマージやカスタムライブラリーの更新など、デフォルト設定以外のものを解決するには、管理者の介入が必要です。
JBoss ON は、JBoss インスタンスにパッチを適用するのに必要な標準ステップを実行しますが、設定の変更を解析およびマージする方法はありません。JBoss ON はカスタムの変更の決定、値の適用を試みません。このようなヒューリスティックは、管理者が行うのが最も適しています。
パッチの完了に必要な手動手順はすべて、パッチの適用後にコンテンツ更新の概要に記載されています。

31.4.2. デフォルトの JBoss パッチコンテンツソースの有効化

パッチストリームは EAP 4 サーバーでサポートされ、パッチとコンテンツの更新を提供します。
注記
JBoss Enterprise Application Platform 5 以降では、Patch RSS フィードバックを使用したパッチ更新はサポートされません。
  1. トップメニューの Administration タブでメニューを開き、Content Sources 項目を選択 Content します。
  2. JBoss Customer Portal Patch Feed ソースをクリックします。
  3. Customer Portal Feed Settings エリアの下部にある Edit ボタンをクリックして、コンテンツソースを変更します。
  4. 必要な接続情報を入力します。
    • カスタマーポータルのユーザー名およびパスワード。
      注記
      カスタマーポータルのパスワードは、JBoss ON データベースに格納されると難読化されます。
    • コンテンツソースの URL(https://access.redhat.com/jbossnetwork/restricted/feed/software.html?product=all&downloadType=all&flavor=rss&version=&jonVersion=2.0)。
    • アクティベーションの状態。これは、自動パッチ Yes を有効にする必要があります。
    スケジュールなどのほとんどのデフォルト設定は保持できます。
    重要
    Lazy Load チェックボックスをアクティベートするか、または RSS feed で定義されたすべてのパッチ(データの 1 GB)は JBoss ON サーバーによって事前にダウンロードされます。
  5. をクリックし Saveます。
  6. 必要に応じて、Synchronize ボタンを使用してコンテンツソースを強制的に実行し、最新の RSS フィードをプルし、ローカルデータと同期します。同期試行の履歴がに記載されてい Synchronization Results sectionます。
  7. パッチの適用を終了するには、手動の手順(「手動ステップのプランニング」)を実行します。

31.4.3. 特定のリソースのデフォルトの JBoss パッチリポジトリーへのサブスクライブ

パッチストリームは EAP 4 サーバーでサポートされ、パッチとコンテンツの更新を提供します。
  1. トップメニューの Resources 項目で、Servers 項目に移動します。
  2. リポジトリーにサブスクライブする JBoss インスタンスを検索します。
  3. JBoss サーバーリソースのエントリーページでタブを開き、Subscriptions サブ Content タブを選択します。JBoss パッチリポジトリーはサブスクリプションで利用できます。
  4. JBoss パッチリポジトリーの横にあるチェックボックスを選択し、SUBSCRIBE ボタンをクリックします。割り当てが完了すると、リポジトリーはではなく Current Resource Subscriptions エリアに一覧表示され Available Repositoriesます。

31.4.4. 複数の JBoss リソースのデフォルトの JBoss パッチリポジトリーへのサブスクライブ

リポジトリーはコンテンツソース(適用可能なパッチ)に関連付けられ、リソースがこのリポジトリーにサブスクライブされます(パッチの適用先)。
パッチストリームは EAP 4 サーバーでサポートされ、パッチとコンテンツの更新を提供します。
注記
JBoss Enterprise Application Platform 5 以降では、Patch RSS フィードバックを使用したパッチ更新はサポートされません。
  1. トップメニューの Administration タブでメニューを開き、Repositories 項目を選択 Content します。
  2. をクリックし JBoss Patch Channelます。
    JBoss パッチリポジトリーは、デフォルトで JBoss パッチコンテンツソースに関連付けられます。リポジトリーを別のコンテンツソースに関連付けるには、ASSOCIATE... ボタンをクリックしてコンテンツソースを割り当てます。
  3. リポジトリーのメインページで、SUBSCRIBE... ボタンをクリックして JBoss リソースをパッチリポジトリーにサブスクライブします。
  4. 検索エリアで、ドロップダウンメニュー Server でを選択します。
  5. このリポジトリーにサブスクライブするすべての JBoss サーバーインスタンスリソースを選択します。

31.4.5. パッチの適用

JBoss サーバーに適用されるパッチは、最初に JBoss コンテンツリポジトリーにサブスクライブする必要があります。
パッチストリームは EAP 4 サーバーでサポートされ、パッチとコンテンツの更新を提供します。
注記
オフ時間または予定されているメンテナンス期間中にパッチのインストールを実行します。
  1. JBoss インスタンスを停止します。
  2. トップメニューの Resources 項目で、Servers 項目に移動します。
  3. パッチを適用する JBoss インスタンスを検索します。
  4. JBoss サーバーリソースのエントリーページでタブを開き、New サブ Content タブを選択します。これにより、特定のリソースタイプで利用可能なパッケージおよびパッチがすべて一覧表示されます。
  5. インストールするパッチが適用された名前の横にあるチェックボックスを選択し、DEPLOY SELECTED ボタンをクリックします。
  6. このページの情報を確認し、すべてが正しいことを確認します。Instructions 列の VIEW リンクをクリックし、パッケージのインストールプロセス中に実行する手順を確認します。
  7. 必要に応じて、注記を入力し、パッチのデプロイメントまたは環境を記述します。
  8. CONTINUE ボタンをクリックして更新をインストールします。パッチプロセスはバックグラウンドで実行されます。進捗は、タブの History サブ Content タブで表示できます。
  9. インストールプロセスが完了すると、Completed Requests このエリアにパッチジョブが表示されます。VIEW ボタンをクリックすると、プロセスで実行されたステップと、完了、失敗、またはスキップされたステップが表示されます。
  10. パッチプロセスが完了したら、JBoss インスタンスを起動します。


[7] JBoss EAP/AS 5 サーバーの Java ホームディレクトリーは、起動スクリプトの値が設定されている場合、エージェント Java 設定をオーバーライドします。

第32章 JBoss EAP 6 の管理(AS 7)

JBoss Enterprise Application Platform 6 はモジュール型で柔軟性があり、環境に応じて設定およびデプロイメントオプションの数は無制限です。
これらの章では、JBoss ON を通じて可能な管理オプションやタスクをすべて説明しません。代わりに、EAP 6 に固有のタスクまたは設定や、EAP 6 の管理に使用する際に特別な考慮が必要なタスクまたは設定を取り上げます。

32.1. JBoss EAP 6 の構造

JBoss EAP 6 の主要な機能は、モジュラークラスローディング構造と、単一のコントローラーで設定を一元化するドメインフレームワークです。これら 2 つの機能には、柔軟性という 1 つの大きなアセットがあります。この概念は、小規模で軽量のアプリケーションサーバーから開始し、必要な機能およびサーバーインスタンスのモジュールに追加して、分散したシステム用のサーバーインスタンスを追加するという概念です。
JBoss ON はそのシステムの変更可能性内で機能し、モジュール化された分散リソースがどのように関係しているかを明確にし、管理制御と情報の可視性をさらに高めています。
JBoss ON では JBoss EAP 6 のインストールには階層と構造がありますが、その構造を適用する前に、EAP 6 自体の順番を理解するのに役立ちます。
注記
スタンドアロンサーバーおよびドメインサーバーの JBoss EAP 6 トポロジーは、JBoss AS 7 プロジェクトドキュメントに 記載されています。

32.1.1. 「classic」構造: スタンドアロンサーバー

JBoss EAP 6 サーバーのほとんどの機能は、独立したクラスまたは サブシステム を介して実装されます。サーバーが使用するサブシステムとその設定プロパティーまたは設定されたインスタンスは、プロファイル で定義されます。
EAP 6 のスタンドアロンインスタンス(EAP 5 と同様)は、定義されたサブシステムのコレクションで、通信、ネットワークインターフェース、およびその他の設定を定義するソケットバインディングのセットです。
サーバーインスタンス全体が standalone.xml ファイルに定義されます。そのファイルのほとんどすべてのエントリーは、サーバーの子として識別されます。たとえば、以下のサブシステムエントリーは ee、サーバーの jmx 子リソースを作成します。
<subsystem xmlns="urn:jboss:domain:ee:1.1"/>
<subsystem xmlns="urn:jboss:domain:jmx:1.1">
    <show-model value="true"/>
    <remoting-connector/>
</subsystem>
同様に、ソケットバインディング、ネットワークインターフェース、およびデプロイ済みのコンテンツ(設定ファイルに定義されているコンテンツ)はリソースとして検出されます。
データソースやロギング設定などのサブシステムには複数のインスタンスを定義できます。これらはすべてサブシステムの子リソースとして設定されます。EAP 6 サーバーのモジュールの性質上、サブシステムは正確なサブシステムであるため、JBoss ON の正確な子は、設定ファイルのサブシステムや他の定義により異なります。
全体的には、サブシステムやその他の設定の数により、スタンドアロンサーバーには非常に幅広くフラットなインベントリーツリーがあります。JBoss ON では、スタンドアロンサーバー構造に追加の階層が設定されていません。サーバーの設定方法を反映してい standalone.xmlます。

図32.1 スタンドアロンサーバー設定

スタンドアロンサーバー設定
スタンドアロンサーバーの管理および操作は自己完結型です。 スタンドアロンサーバーのすべての子ノードは、設定とそのランタイム環境(監視、アラート、および操作)を同じ場所に組み合わせます。データソースの設定を変更するには、データソースエントリーを直接編集します。すべてのスタンドアロンサーバーは、同じクラスターまたは同じマシンであっても、他のサーバーとは別々に管理されます。
これらはすべて JBoss EAP 5 サーバーの構造と機能に類似しており、インベントリー組織には若干の違いがあります。

32.1.2. 設定とリアルタイム操作の分離: ドメイン

ドメインの構造は、よりモジュール型設計の観点から完全に異なります。
ドメインは、アプリケーションサーバーをサーバー設定とランタイム操作という 2 つの概念的な方法で分割します。
設定はドメインコントローラーに一元化されます。ドメインコントローラーは、プロファイルおよびサブシステムの設定、JVM の設定、インターフェース、およびその他の設定を単一の場所で定義します。
アプリケーションサーバーの機能は、複数のマシンにインストールできる 管理 サーバーによって実行されます。これらの管理サーバーは、独自の設定を定義しません(例外は除く)。ドメインからのプロファイル構造を受け入れ、ドメインを介してデプロイされた web アプリケーションを提供します。
組織ドメインとサーバー グループ と呼ばれる管理サーバーのセカンダリーレベルがあります。サーバーグループはドメイン設定の一部として定義されます。管理対象サーバー用に環境を作成します。それらは設定ノードです。ドメインには複数のプロファイル、JVM 定義、Web アプリケーションを含めることができます。すべての設定の中央リポジトリーです。特定の設定とコンテンツのみがサーバーグループに割り当てられ、その特定の設定が管理対象サーバーに適用されます。

図32.2 簡易ドメイン構造

簡易ドメイン構造
ドメイン設定は domain.xml ファイルに定義されます。これにより、設定されたプロファイルおよびサブシステム、サーバーグループ、ソケットバインディング設定、システムプロパティー、デプロイメント、およびその他の設定がすべて一覧表示されます。スタンドアロンサーバーと同様に、ほぼすべてのエントリーが検出され、リソースとしてインベントリーに追加されます。たとえば、これにより、子デプロイメントリソースとサーバーグループの子 JVM リソースを持つサーバーグループリソースが作成されます。

例32.1 Server Group domain.xml エントリー

        <server-group name="main-server-group" profile="full">
            <jvm name="default">
                <heap size="1303m" max-size="1303m"/>
                <permgen max-size="256m"/>
            </jvm>
            <socket-binding-group ref="full-sockets"/>
            <deployments>
                <deployment name="sample2.war" runtime-name="sample2.war"/>
            </deployments>
	</server-group>
操作を実行するインスタンスは、host.xml ファイルで識別されます。これらの管理サーバーは実質的には独自の設定を持ちません。ドメインで使用する元のサーバーグループ設定に戻るだけです。
    <servers>
        <server name="server-one" group="main-server-group"/>
        <server name="server-two" group="other-server-group">
            <!-- server-two avoids port conflicts by incrementing the ports in
                 the default socket-group declared in the server-group -->
            <socket-bindings port-offset="150"/>
        </server>
    </servers>
ドメイン(プロファイルとそのサーバーグループ)は、全体の設定を定義します。管理されたサーバーは、その設定下のワーカーです。これは、設定と操作(特に個々のメンバーではなく、ドメインの機能全体)を EAP 6 管理コンソールに反映します。Profile および Servers エリアは、現在の統計とデプロイされた Web アプリケーションを Runtime 表示し、ドメイン設定を管理します。フォーカスは常にドメイン設定とドメイン情報に重点が置かれます。

図32.3 EAP 6 コンソール

EAP 6 コンソール
JBoss ON でドメインリソースを管理することは、設定の管理が情報を管理するよりも少なくなります。JBoss ON インベントリー構造の強度の 1 つは、ドメインのコンポーネントを非常に明確に公開し、それらのリソース間の関係を説明するのに役立ちます。

図32.4 ドメインリソース

ドメインリソース
たとえば、管理対象サーバーのエントリーは、そのサーバーグループのプロファイルに定義されているすべてのサブシステムを一覧表示し、ホストコントローラー定義を一覧表示し、それにデプロイされた管理 web アプリケーションを一覧表示します(サーバーグループを介して)。これにより、1 つのワーカーインスタンスに適用される設定情報がすべて統合され、管理されたサーバーの監視情報がより重要になります。
JBoss ON インベントリーには、ドメイン関係を維持するため、実用性が高くなります。ドメインは単一のオーバーアーキテクチャーエンティティーですが、ドメインのコンポーネントはこれらのプラットフォームの複数のプラットフォームおよびリソースにまたがることができます。ドメインコントローラーは、プラットフォームに関係なく、すべてのドメインリソースの親リソースとみなされます。これは、でヒントとなり 図32.5「JBoss ON インベントリーのドメインコンポーネント」 ます。ドメインコントローラーと 2 台の管理サーバーがプラットフォーム 2 にある場合でも、ドメインコントローラーは 1 つです。ホストコントローラーと管理リソースは、ドメインコントローラーと管理リソースがドメインリソースの子として表示されます(プラットフォーム 1 上)。

図32.5 JBoss ON インベントリーのドメインコンポーネント

JBoss ON インベントリーのドメインコンポーネント

32.1.3. JBoss ON の EAP 6 リソース

、、、またはの EAP 6 のすべての設定エリア standalone.xmldomain.xml host.xml、リソースタイプとして解釈されます。EAP 6 では設定コンポーネントと運用コンポーネントの違いがあるため、JBoss ON の EAP 6 リソースタイプは異なることを行います。また、リソースによっては設定を定義し、監視、アラート、および操作に使用されます。
ドメインでは、ドメインのプロファイル、ソケットバインディング、およびネットワークインターフェースはすべて設定エントリーです。そのため、JBoss ON では、対応するリソースタイプによって設定が定義されます。
ドメインでは、管理対象サーバーは機能するインスタンスです。これらのリソースはアクティブであるため、JBoss ON では管理対象サーバーリソースは操作を実行し、メトリクスを監視し、アラートをトリガーできます。
設定リソースと機能の運用リソースとの間に重複はありません。たとえば、プロファイル下のデータソースリソースには設定がありますが、監視またはアラートはありません。管理対象サーバーのデータソースはモニタリングメトリクスを収集し、アラートを定義し、操作を実行します。これらのリソースは関連しています。管理対象サーバーデータソースリソースはプロファイルデータソースの設定を参照しますが、それらは異なります。
スタンドアロンサーバーでは、同じリソースで設定および管理が有効になります。スタンドアロンサーバーは基本的に、プロファイルリソース(設定)と管理対象サーバーリソース(management)の組み合わせです。スタンドアロンサーバーのデータソースリソース。その後、同じリソースの設定と監視、アラート、および操作の両方を保持します。

32.1.4. JBoss ON を使用した EAP 6 リソースの管理の目的

JBoss ON UI は EAP 6 コンソールとパリティーを維持するため、多くの設定を編集し、子エントリーの作成、およびコンテンツのデプロイに EAP 6 管理コンソールと同じに使用できます。
しかし、JBoss ON 管理の目的は、別の Web UI を使用する訳ではありません。JBoss ON は、ドメイン内のリソースについてより大きな観点を維持します。このインフラストラクチャー全体の観点では、ドメイン内のリソース、より大きな IT 構造、さらには現在の設定変更を除いて、独自の履歴も明確になります。
JBoss ON のスタンドアロンサーバーおよびドメインは、管理者が利用できる情報を強調表示するように構成されています。
  • 保存した履歴データ、リソース固有の運用ベースライン、および代替の表示タイプを含む、リソースの追加の監視メトリック
  • 履歴の設定および接続設定
  • JBoss ON で子を追加または削除した場合のインベントリー変更履歴
  • 制御されたパッケージ更新用のパッケージバージョン管理およびリポジトリー
  • プラットフォーム、Apache サーバー、Tomcat Web サーバーなどの基礎となるリソースおよび関連するリソースの設定、監視、アラート、およびアラート mod_cluster

32.2. JBoss EAP 6 リソースプラグインのアップグレード

JBoss Operations Network 3.0 および 3.0.1 には、テクノロジープレビューバージョンの JBoss Enterprise Application Platform(EAP)6 エージェントプラグインがありました。通常のアップグレードプロセスでは、JBoss ON サーバーの更新時にエージェントプラグインが更新されます。ただし、テクノロジープレビューのプラグインはアップグレードされません。プラグインのテクノロジープレビューバージョンは削除してから、新しいプラグインがインストールされている必要があります。
EAP 6 のテクノロジープレビュープラグインおよび EAP 6 GA プラグインは、JBoss ON によって 2 つのプラグインとして処理されます。テクノロジープレビューのバージョンが削除されないと、Technology preview プラグインによって検出され、GA プラグインによって再度検出される EAP 6 リソースがインベントリーで検出され、インベントリーに 2 回表示されます。
注記
新しい EAP 6 プラグインにアップグレードすると、設定、データおよびベースライン、およびリソースの履歴は失われます。

手順32.1 EAP 6 プラグインを読み込む方法

  1. 元のテクノロジープレビュープラグインを削除し、JBoss ON データベースからパージします。プラグインをパージすると、サーバーはその場所に新しいプラグインをデプロイできます。
    1. トップメニューで、Administration タブをクリックします。
    2. 左側のナビゲーションバーの Configuration ボックスで、Agent Plugins リンクをクリックします。
    3. EAP 6 のテクノロジープレビュープラグインを選択します。
    4. Delete ボタンをクリックします。
  2. EAP 6 サーバーとその子をインポートし、通常通りにリソースを管理します。

32.3. JBoss EAP 6 インスタンスの設定

32.3.1. EAP 6 インスタンスを検出するエージェントの設定

に記載されているように 4章エージェントおよびリソースのシステムユーザーとの対話、エージェントを実行するシステムユーザーは、エージェントが特定のリソースタイプを管理する方法に直接影響します。EAP インスタンスの場合、エージェントのシステムユーザーに EAP リソースを管理できるように適切なパーミッションが必要です。
  • エージェントには、ファイルの読み取り権限が必要です。さらに、run.jar ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になり run.jar ます。
  • RPM から JBoss EAP 6 インスタンスがインストールされている場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。

32.3.2. サーバーおよびプロファイルの設定

32.3.2.1. スタンドアロンサーバーおよびドメインの相違点

「JBoss EAP 6 の構造」 スタンドアロンサーバーとドメイン構造の相違点がいくつかあります。設定に重要な違いは、スタンドアロンサーバーでは、すべての設定が子エントリーで直接実行される点です。ドメインを使用すると設定が分割され、ほぼすべての設定をドメイン管理プロファイルとサーバーグループで一元管理されます。
これは EAP 6 管理コンソールに反映されます。ほとんどすべての設定は Profiles エリアにあります。ドメインプロファイルは、個別のサブシステム設定、システムプロパティー、グローバル JVM 設定、およびサーバーグループの設定を定義します。

図32.6 EAP 6 コンソールのプロファイルエリア

EAP 6 コンソールのプロファイルエリア
この Servers エリアは、管理対象サーバーに設定されている設定量(主にローカル JVM 定義とサーバーの停止や起動など)をカバーします。
JBoss ON では、domain(プロファイル)とそれらのサブシステム、ソケットバインディング、サーバーグループの主な設定エリアは個別のリソースタイプとして分類されます。この設定は、テンプレートと同様に、管理対象サーバー(サーバーグループ経由)に適用されます。
常に設定元となるリソースを編集します。ほとんどの設定では、ドメインコントローラーの関連する子リソースを編集することを意味します。
  • サブシステム設定はドメインコントローラーの autogroup 内の Profiles プロファイルリソースにあります。
  • JVM 定義は、ドメインコントローラー(ドメイン全体のデフォルト)、サーバーグループ(グループ全体の設定)、または管理対象サーバー(ローカル設定)で設定されます。
  • ネットワークインターフェースはドメインコントローラーで設定されます。
  • ソケットバインディング自体は、ドメインコントローラーの autogroup の下にあるエントリーでドメインコントローラー設定の一部として SocketBindings 設定されます。各サーバーグループと管理対象サーバーにはオフセットがあり、ソケットバインディング値に追加されます。これは、管理対象ドメインで一意のポート番号を提供するために使用される番号です。これらのオフセットはサーバーグループと管理対象サーバーの接続設定で設定されます。
  • システムプロパティーは、ほぼすべてのサーバーリソース(ドメインコントローラー、ホストコントローラー、サーバーグループ、管理対象サーバー)で設定できます。
設定(JVM 定義およびシステムプロパティー)は、異なるレベル(domain、サーバーグループ、または管理対象サーバー)で定義できます。この場合、設定は cascade で機能し、最も低いレベルの設定が優先されます。そのため、サーバーグループの設定はドメイン設定と管理対象サーバー設定は、サーバーグループ設定に優先します。これらの設定 には、ドメイン階層の適切なレベルで設定を 行ってください。ドメイン全体に設定を適用するには、関連するドメインエントリーを編集します。サーバーグループまたはサーバーレベルで設定を設定するには、そのエントリーレベルで設定を作成または編集します。

32.3.2.2. EAP 6 で必要な管理インターフェース

JBoss ON の EAP 6 プラグインは、EAP 6 ドメインコントローラーのデフォルト HTTP 管理インターフェースに接続します。この管理インターフェースは、EAP 6 ドメインインスタンスを管理および監視するために使用されます。
HTTP 管理インターフェースが削除または無効になっている場合、エージェント(EAP 6 プラグインを使用)は EAP 6 ドメインインスタンスに接続できなくなります。そのため、EAP 6 ドメインリソースを管理または監視できず、リソースが実行していても利用できなくなります。
必要な場合は、EAP 6 CLI を使用して JBoss ON エージェントが接続する HTTP 管理インターフェースを有効にします。
/host=instanceName/core-service=management/management-interface=http-interface:add(interface=http,port="\${jboss.management.http.port:9990}",security-realm=ManagementRealm
JBoss ON JBoss Enterprise Application Platform 6 プラグインは、HTTPS(SSL)を使用した管理インターフェースへの接続もサポートします。JBoss Enterprise Application Platform 6 管理コンソールに対して HTTPS インターフェースを使用するよう JBoss ON を設定する方法は、を参照してください 「JBoss Enterprise Application Platform 6 サーバーのセキュア接続設定の変更」。HTTPS を使用するよう JBoss Enterprise Application Platform 6 管理コンソールを設定する方法は、JBoss Enterprise Application Platform 6『セキュリティーガイド』の「 HTTPS 用管理コンソールの設定」を参照してください

32.3.2.3. JBoss ON の設定機能

JBoss ON は JBoss ON のリソースに加えられた設定変更をすべて追跡します(JBoss ON UI または CLI を使用)。JBoss ON 上の値は、設定変更を行うだけでなく、設定を管理します。JBoss ON の他の管理領域と同様に、設定は履歴を維持します。これにより、管理者は変更のコンテキストおよびパフォーマンスやメンテナンスへの影響で設定を管理することができます。
  • バージョン間の diffs を含む変更履歴の表示
  • ボタンをクリックして、以前のバージョンへの変更をロールバックします。
  • 監査証跡の一部として変更を行ったユーザーを追跡
  • アラートを使用して、設定変更の管理者に通知します。
  • ドリフト監視を定義して、定義したベースラインに対して設定の変更を追跡し、予期しない設定変更を制御する
各リソースについて、JBoss ON は一般的なリソースプロパティー(タブ内)と、エージェントがリソースへの接続に使用する接続プロパティー( Configuration タブ内の)の 2 つのタイプの設定を除外します Inventory。いずれのタイプの設定にも設定履歴があり、以前のバージョンに戻すことができ、アラートとモニタリングに使用できます。現実的には、いずれかの設定タイプを編集すると、リソース上の同じ設定ファイルを編集できます。これらの 2 つの設定エリアは JBoss ON に分離され、リソースの動作に影響する設定とリソースへの接続に影響する設定の区別に役立ちます。
設定や接続設定を編集できない場合でも、JBoss ON では、管理者はそのリソースに適用されている設定を表示することができます。これは、プロファイルリソースで定義された設定を使用する管理サーバーに特に便利です。

32.3.3. Setup CLI 操作を使用した JBoss ON と EAP 6 間の SSL 認証

EAP 6 サーバーがセキュア化された場合(SSL 認証が必要な場合)、Setup CLI 操作を使用して JBoss ON EAP プラグインから認証設定を複製できます。これにより、JBoss 6 の JBoss CLI(jboss-cli.sh または jboss-cli.bat)への JBoss ON GUI アクセスが可能になります。この操作は JBoss ON と EAP 間 Execute CLI script<EAP_install_directory>/bin/jboss-cli.xml 公開鍵を更新し、JBoss ON GUI からの Execute CLI commands /からの操作を可能にします。
注記
この操作は 任意です。jboss-cli は EAP 6 のドキュメントを使用して手動で設定できます。詳細は、「 Setting up 2-Way SSL/TLS for the Management Interfaces 」を参照してください。
Setup CLI 操作を使用するには、JBoss ON エージェントには EAP ファイルおよびディレクトリーへの読み取りおよび書き込み権限が必要です。
これ Setup CLI は、JBoss ON 3.3 向けに Enterprise Application Platform(EAP)Management Plug-in Pack Update-03 によって導入されました。

表32.1 Setup CLI 操作から利用できるプロパティー

propertydescription
デフォルトコントローラーJBoss ON コントローラーホストおよびポートを EAP 6 の JBoss CLI のデフォルトとして設定します。
securityEAP 6 にセキュアな管理インターフェースがある場合、このオプションは Store Password Method を基にして JBoss ON と EAP 間の認証を設定します。これにより、JBoss ON は EAP 6 JBoss CLI を実行できるようになります。
ストアパスワードメソッドセキュリティーを設定する際に、パスワードを jboss-cli.xml に保存するメソッドを設定します。
  • plain: プレーンテキストとして保存された EAP サーバープラグイン設定のパスワードを使用します。これはデフォルトのオプションです。
  • vault: EAP パスワード vault で難読化されたサーバー設定ファイル(例: standalone.xml)からパスワードを使用します。パスワード vault もサーバー設定ファイルに定義する必要があります。パスワード vault が見つからない場合、この操作は失敗します。jboss-cli.xml のパスワード vault が EAP 6.3 に導入されました。

手順32.2 Setup CLI 操作の使用

  1. JBoss ON CLI で Inventory タブをクリックします。
  2. Resources メニューからをクリックし Servers、設定する EAP サーバーを選択します。
  3. EAP サーバーリソースページから、Operations タブをクリックします。
  4. New をクリックし、新しい操作をスケジュールします。
  5. Operation ドロップダウンリストから、以下に示すように Setup CLIを選択します。

    図32.7 Setup CLI 操作の例

    Setup CLI 操作の例
  6. 必要なプロパティーを変更するには、Unset? チェックボックスをクリアし、該当するをクリックし Valueます。
  7. Schedule をクリックし、操作を保存します。このページは Operations History タブにリダイレクトします。
  8. Setup CLI 操作が実行され、ステータスが success を示す場合、以下のように Setup CLI 操作の Date Submitted エントリーをクリックして、操作の結果を表示し、変更が正常に行われたことを確認し ます

    図32.8 Setup CLI 操作の結果の例

    Setup CLI 操作の結果の例
EAP 6 JBoss CLI の設定に関する詳細 は、『Red Hat JBoss Enterprise Application Platform 6 管理および設定ガイド』の「管理 CLI 」を参照してください。

32.3.4. 管理ユーザーの作成

JBoss ON エージェントは管理ユーザーとして EAP 6 サーバーに接続します。これにより、JBoss ON は設定の変更やリソースの開始および停止などのタスクを実行できます。
JBoss ON が EAP 6 インスタンスを管理できるようにするには、管理ユーザーが必要です。
管理ユーザーを作成する方法は複数あります。
  • LDAP ディレクトリーまたは外部データストアの使用これは EAP 6 の最もセキュアな実装であり、推奨されます。
  • JBoss ON を使用して管理ユーザーを作成します。
  • EAP add-user スクリプトでローカル EAP アカウントを作成する。
ユーザー名とパスワードが EAP 6 リソース接続プロパティーに設定されている限り、セキュリティー実装とローカル EAP 6 インスタンスの要件に応じて、これらはすべて有効です。

32.3.4.1. 管理ユーザーの認証情報の設定

JBoss ON では、EAP 6 サーバーに接続するためのユーザー名とパスワードが必要です。リソースの操作、アプリケーションのデプロイメント、設定の変更、およびその他の保守を行うのに適切な権限があれば、EAP 6 ユーザーをすべて使用できます。
JBoss ON は EAP のユーザー設定について認識せず、認証情報のみを EAP に送信し、EAP サーバーが認証リクエストを処理します。そのため、EAP が LDAP ディレクトリーをユーザーストアまたはその他のセキュリティーレルムとして使用するよう設定されていても、JBoss ON はその情報は必要ありません。ユーザー名とパスワードのみが必要です。
管理ユーザーは EAP リソースの接続プロパティーで定義されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Inventory タブを開きます。
  5. Connection Settings サブタブを選択します。
  6. EAP 6 で作成した管理ユーザーのユーザー名とパスワードを入力します。
  7. ページ上部の Save ボタンをクリックします。

32.3.4.2. JBoss ON での管理ユーザーの作成

エージェントが EAP 6 インスタンスへの接続に使用できるローカル EAP ユーザーを作成および設定するリソース操作があります。これは、ユーザー用に事前定義された設定と JBoss ON の追加設定が含まれる EAP 6 add-user ユーティリティーのラッパーです。
この操作は、EAP 6 サーバー ManagementRealmrhqadmin ユーザーを作成します。これはデフォルトのセキュリティーレルムです。実稼働環境では、異なる管理レルムを使用することが強く推奨されます。
ユーザーは セキュアな 管理レルムに作成されます。EAP 6 サーバーがセキュアモードではない 場合、JBoss ON が管理レルムに接続できないため、インストール RHQ ユーザー 操作は失敗します。EAP 6 サーバーは、デフォルトでセキュア化されます。
注記
この操作は、1 つのステップで EAP 6 と JBoss ON の両方の設定を設定 するので便利ですが、セキュリティー制限があります。他のセキュリティーレルム(実稼働環境に推奨)を使用する場合は、add-user.sh スクリプトなどのこの操作は使用できません。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Operations タブを開きます。
  5. ページ下部の New ボタンをクリックします。
  6. ドロップダウンメニューから Install RHQ User オプションを選択します。
  7. Schedule ボタンをクリックします。

32.3.4.3. EAP 6 での管理ユーザーの作成

EAP 6 add-user.sh ユーティリティーは、エージェントが EAP 6 インスタンスへの接続に使用できるローカル EAP ユーザーを作成し、設定します。EAP でユーザーを作成したら、そのユーザーの認証情報を JBoss ON のリソースの接続プロパティー設定に提供する必要があります。
注記
add-user.sh スクリプトによるユーザーの作成には、セキュリティーに関する制限があります。デフォルトの管理レルム(ManagementRealm)にユーザー のみを作成します。実稼働環境に推奨される他のセキュリティーレルムが使用される場合、このスクリプトを使用して JBoss ON エージェントのユーザーを作成することはできません。
  1. add-user ユーティリティーを実行してユーザーを作成します。
    [root@server ~]# cd /opt/jboss-eap-6.0
    
    [root@server bin]# ./add-user.sh
    What type of user do you wish to add?
     a) Management User (mgmt-users.properties)
     b) Application User (application-users.properties)
    (a): a
    
    Enter the details of the new user to add.
    Realm (ManagementRealm) :
    Username : jonadmin
    Password :
    Re-enter Password :
    About to add user 'jonadmin' for realm 'ManagementRealm'
    Is this correct yes/no? yes
  2. JBoss ON の EAP 6 サーバーリソースの接続設定でそのユーザーを設定します。
    1. トップメニューの Inventory タブをクリックします。
    2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 6 サーバーを選択します。
    3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
    4. Inventory タブを開きます。
    5. Connection Settings サブタブを選択します。
    6. EAP 6 で作成した管理ユーザーのユーザー名とパスワードを入力します。
    7. ページ上部の Save ボタンをクリックします。

32.3.5. EAP 6 リソースの動的グループの作成

管理(特に設定の監視や編集の場合)では、互換性のあるグループで関連リソースをグループ化すると非常に便利です。互換性のあるグループを使用すると、管理者はすべてのグループメンバーのアラート定義の設定、メトリクス設定の変更、設定の変更を同時に行うことができます。
Dynagroups は検索式を使用してグループメンバーを検索し、ユーザー定義の基準に基づいてグループを作成します。これにより、JBoss ON インベントリーの変更時にメンバーが追加され、自動的にドロップされるため、グループメンバーシップは常に最新の状態になります。
Dynagroup 構文の詳細は、を参照してください 「動的グループ構文」。この特定の dynagroup 式は、まずリソースプラグイン、カテゴリー(サーバー)、および親を基にしてリソースを検索します。次に、製品のタイプと名前に基づいてグループを作成します。
これにより、Ansible-P、Data Grid(JDG)、ホストコントローラーおよびスタンドアロンサーバーなど、JBoss EAP 6 に関連付けられたすべての JBoss 製品に個別の互換性のあるグループが作成されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Groups エリアで、Dynagroup Definitions リンクをクリックします。
  3. EAP 6 のサーバータイプごとに互換性のあるグループを作成する式を入力します。
    resource.type.plugin = JBossAS7
    resource.type.category = SERVER
    resource.parent.type.category = PLATFORM
    groupby resource.pluginConfiguration[productType]
    groupby resource.type.name
  4. ページの中央にある Save ボタンをクリックします。

32.3.6. 起動スクリプト引数、環境変数、および JAVA_OPTS の設定

32.3.6.1. スクリプト検出と設定の開始

JBoss EAP 6 サーバー(ドメインコントローラーまたはスタンドアロンサーバー)の検出の一環として、JBoss ON はサーバーが実行されている環境の検出を試みます。特に、検出プロセスはランタイム環境の特定および再作成を試行します。
  • 検出プロセスは、カスタム開始スクリプトを含む、使用される開始スクリプトを特定または試行します。
  • Discovery は、開始スクリプトが機能するために必要な run.conf ファイルまたは親プロセスに設定された環境変数のサブセットを検出します。
    注記
    検出プロセスで一部の環境変数が検出されますが 、検出スキャンは JAVA_OPTS 値を検出しません。
    開始スクリプトの接続プロパティーは意図的に JAVA_OPTS 値のために run.conf ファイルに移されます。
  • 検出は、開始スクリプト自体で渡された引数の検出を試みます。
  • Discovery は、スクリプトが実行しているユーザーを検出し、start スクリプトで使用する 接頭辞 コマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。
検出された設定は、EAP 6 リソースの Start Script Environment Variables および Start Script Arguments 接続設定に保存されます。
検出スキャンが一部のスクリプト設定を検出できない場合(エージェントは EAP 6 サーバーとは異なるユーザーとして実行され、親プロセスの読み取りができない場合)、正常に失敗します。可能な情報をすべて収集し、空の値を無視します。
注記
Start Script Environment Variables および Start Script Arguments 接続設定は、リソースの初回検出時に 1 回だけ検出されます。その後、接続設定は接続設定で変更できますが、ローカルシステムで行った変更は検出されません。たとえば、サーバーが特定の値(など -XX:PermSize=256M)で検出されると、サーバーが別の設定値で後で再起動すると、引数の値は更新されません。
スクリプト引数と環境変数は、開始スクリプトの実行時にエージェントによって使用される唯一の変数です。これらの引数および環境変数は、他の設定や親プロセスに追加されません。EAP 6 接続設定の開始スクリプト設定は決定論的です。

32.3.6.2. スクリプト引数およびドリフト監視の開始

JBoss ON はディレクトリーや特定のファイルを監視して、設定の ドリフト を確認することができます。詳細は 「設定項目の制御」 およびで説明されてい 15章設定項目の管理 ます。
管理者は重要なリソースを管理するのに、ドリフト監視は重要ですが、いくつかの設定で必要になるか、または有益である場合もあります。start スクリプト引数を使用すると、ドリフトアラートをトリガー せず に EAP 6 サーバーの定義設定をオーバーライドできます。
起動スクリプトのオプションはすべて接続設定であるため、すべての変更は変更履歴に記録され、にあるように簡単に表示および元に戻すことができ 「設定変更の追跡および取り消し」 ます。これにより、システムプロパティーと Java 設定が追跡および修復されます。

例32.2 ドリフト定義を自動化せずにシステムプロパティー

Tim the IT Guy は、すべての実稼働 EAP 6 サーバーが環境を使用する特定の設定セットを作成します。その後、テンプレートに設定が加わるモニタリングおよび関連付けまたはピン用にドリフト定義テンプレートを作成します。
テンプレートのドリフトを使用する EAP 6 サーバーは、これらの構成設定に準拠する必要があります。Tim the IT Guy は、実稼働サーバーが特定の設定からドリフトした場合に通知するアラートを作成します。これは、Example Co. の実稼働アプリケーションサーバーに対する重要な安全対策です。
ただし、実稼働サーバーでは、動作中のハードウェアやその他のアプリケーションが若干異なるため、効果的に実行するために異なるヒープサイズが必要になります。
TI Guy が別のヒープサイズを使用するようにシステムプロパティーを追加する場合、一定のドリフトアラートを受信するか、サーバー側の自動スクリプトを実行してドリフト設定を修正すると、編集した設定が上書きされる可能性があります。
開始スクリプトで異なるヒープ設定を設定すると、Tim は設定ファイルを編集せずにそのシステムの正しい設定を適用できるため、アラート可能な設定のドリフトはありません。

32.3.6.3. 起動スクリプト設定の変更

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Inventory タブを開き、Connection Settings サブタブを選択します。
  5. Operations エリアを展開します。
  6. 開始スクリプトの設定を変更または追加します。これらは、EAP 6 サーバーで起動または再起動の操作を実行する際に JBoss ON エージェントが使用するスクリプトおよび設定です。
    • domain.sh または以外のカスタムの開始スクリプトを使用するには standalone.sh、パスとスクリプト名を入力します。
    • 必要に応じて、開始スクリプトの実行時にスクリプトで使用する接頭辞を入力します。
      起動スクリプトが検出されると、エージェントはスクリプトが実行されているユーザーを判断しようとし、start スクリプトで使用するプレフィックスコマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。
      さらに、JBoss ON は nohup コマンドをプレフィックスとして割り当て、JBoss Enterprise Application Platform がエージェントによって開始され、エージェントプロセスが終了すると、JBoss Enterprise Application Platform プロセスが実行を継続します。
    • 各行に 1 つずつ環境変数を設定します。
    • スクリプト引数を設定します(行ごとに 1 つ)。通常の JAVA_OPTS の場合、これらの引数は通常 -X -D、またはです -P。便利な -XX 引数の一部は、Sun の JVM オプションのドキュメントに記載されています。EAP 6 の便利なシステムプロパティーの一部は、JBoss AS7 プロジェクトのドキュメント に記載されています。
      EAP 6 のデフォルトの起動スクリプトは - 形式の run.shスクリプトを使用するため、引数はその形式を使用します。カスタムスクリプトは、異なる引数またはオプションを使用できます。
  7. ページ上部の Save ボタンをクリックします。

32.3.6.4. スタンドアロンモードでの JVM ヒープ引数の変更

重要
このセクションでは、スタンドアロンモードおよび標準設定ファイル(standalone.conf または standalone.bat)のみを使用する場合に JVM 引数を更新する方法を説明します。ドメインモードで JVM Arguements を更新する場合は、を参照してください 「JVM 定義の変更」
JBoss ON JBoss Enterprise Application Platform 6 プラグインを使用すると、スタンドアロンモードで実行している JBoss Enterprise Application Platform 6 サーバーの JVM Heap を編集および永続化できるようになりました。この機能により、JBoss ON の JAVA_OPTS 設定は JBoss ON の外部で再起動できます。ここで使用する値は、設定ファイル(standalone.conf または standalone.bat)に永続化されます(例: -Xms512M -Xmx1024M)。設定ファイルに加えられた変更を削除するには、「Unset?」チェックボックスを使用する必要があります。これらの変更を有効にするには、サーバーを再起動する必要があります。
重要
この値は、ファイルの最後で永続化される standalone.confstandalone.bat (OS によって異なります)。
このプロパティーを設定した後に、設定ファイルでこの値を更新しないでください。この値は、JBoss ON UI を使用してのみ変更する必要があります。
この機能にアクセスするには、以下を実行します。
  1. トップメニューのインベントリータブをクリックします。
  2. 左側の Resources メニューテーブルで「Servers - Top Level Imports」を選択し、右側の表で該当する JBoss Enterprise Application Platform 6 スタンドアロンサーバーをクリックします。
  3. JBoss Enterprise Application Platform Server の詳細で「 Inventory」タブをクリックします。
  4. 「Connection Settings」サブタブをクリックします。
  5. テーブルの「Operations」セクションの「Additional JAVA_OPTS」行までスクロールします。
  6. 外観を追加するには、「Unset?」チェックボックスの選択を解除し、そのテキストをテキストボックスに追加します。
    注記
    "Unset" チェックボックスは、設定が JBoss ON Server から使用されているかどうかのみ決定します。「未設定」チェックが解除されると、テキストボックスの値が使用されます。"Unset" がチェックされると、テキストボックスの値は使用されません。「 Unset?」チェックを実行しても、設定ファイルが JAVA_OPTS を設定しないことを意味します。これは単に値が JBoss ON を介して設定されていないことを意味します。
  7. 「 Save」をクリックします。
  8. この更新を反映するには、JBoss Enterprise Application Platform 6 サーバーを再起動する必要があります。
この値の設定を解除するには、「Unset?」チェックボックスを有効にして「Save」をクリックします。この更新を有効にするには、JBoss Enterprise Application Platform 6 サーバーを再起動する必要があります。
注記
この値の設定を解除すると、設定ファイル(standalone.conf または standalone.bat)から JBoss ON によって追加された値が削除されます。このファイルにすでに存在するその他の設定はすべて影響を受けません。

32.3.7. ポート番号の変更

32.3.7.1. ソケットバインディングポートの変更

ソケットバインディングリソースは、利用可能なポート(HTTP、AJP、HTTPS など)とポート番号を定義します。ソケットバインディング設定は、ソケットのマルチキャストポート番号を設定することもできます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで SocketBindingsGroup 互換性のあるグループを選択し、編集するソケットバインディングを選択します。
  4. Configuration タブを開きます。
  5. 鉛筆アイコンをクリックして既存のソケット定義を編集するか、プラス記号(+)をクリックして新しいソケット定義を作成します。
  6. 1025 から 65535 までの利用可能なポートに Port 番号を変更します。Linux では、利用可能なポート番号はを使用して決定でき iptablesます。
    オプションで、ソケットのマルチキャスト設定を行います。同じシステムまたは同じクラスターに複数の JBoss サーバーインスタンスがある場合、マルチキャストはクラスター通信用に設定されます。
  7. ページ上部の Save ボタンをクリックします。

32.3.7.2. ドメインのサーバーグループのポートオフセットの変更

ポートオフセットは、ソケットバインディンググループの各ポート番号に追加される番号で、サーバーインスタンスによって使用される実際のポート番号を作成します。これにより、同じソケットバインディング設定を使用しながら、管理サーバーのドメイン全体で一意のポート番号を指定するか、またはクラスター内のスタンドアロンサーバーに一意のポートを持たせることができます。
たとえば、ソケットバインディング HTTP ポートが 8080 で、管理サーバーのオフセットが 110 の場合、管理対象サーバーによって使用される実際のポートは 8190(8080 + 110)になります。サーバーグループはオフセットも定義でき、オフセットは加算されます。そのため、サーバーグループに 15 のオフセットがあり、管理サーバーのオフセットが 110 の場合、サーバーが使用するポート番号は 8205(8080 + 15 + 110)になります。
注記
管理対象サーバーのオフセットは、host.xml ファイルのエントリーで定義されます。これは、JBoss ON で管理サーバーの作成時に設定できますが、後で編集することはできません。
サーバーグループによって使用されるポートオフセットを編集できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで Server Groups ノードを展開し、サーバーグループを選択します。
  4. サーバーグループの Configuration タブを開きます。
  5. Port Offset フィールドにオフセットの新しい値を入力します。
  6. ページ Save 上部をクリックします。
スタンドアロンサーバーのオフセットを変更するには、にあるように接続設定を編集し 「EAP 6 サーバーの一般プロパティーの変更」 ます。

32.3.8. ネットワークインターフェースの編集

ネットワークインターフェースがそのインターフェースのソケットと通信する際に、特定の IP アドレスまたは IP アドレスのタイプを使用するように設定できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで Server Configuration で Network Interfaces グループを選択し、インターフェース(management、public、または unsecure)を選択します。
  4. Configuration タブを開きます。
  5. 使用するインターフェースの特定の IP アドレスを設定するか、使用する IP アドレスの タイプ (IPv4、IPv6、またはどちらか)を設定します。IP アドレスまたは IP アドレスタイプを設定する必要があります。
    特定の IP アドレスまたは IP アドレスタイプのいずれかを設定できます。また、使用するプロパティーは任意であるため、UI では選択が強制されることはありません。ただし、ネットワークインターフェースが適切に機能するには、一部の IP アドレス設定を設定する必要があります。
  6. ページ上部の Save ボタンをクリックします。

32.3.9. システムプロパティーの設定

サーバーおよび特にサブシステム(統合サービス)では、システムプロパティーとして追加の設定プロパティーを追加できます。システムプロパティーは単純な属性と値のペアで、任意のものです。利用可能なシステムプロパティーは、編集するリソースによって異なります。
プロファイルやサブシステム、エクステンション、サーバーグループ、およびその他のドメインコンポーネントを編集すると、システムプロパティーが domain.xml ファイルのコンポーネントのエントリーに追加されます。ホストコントローラーまたは管理対象サーバーを編集すると、プロパティーが host.xml ファイルのサーバーのエントリーに追加されます。
注記
システムプロパティーは、ドメインの他の設定要素と同様に、cascade で機能します。システムプロパティーがサーバーグループに設定されていると、グループのすべてのメンバーに適用されます。管理対象サーバーで設定されている場合は、そのサーバーにのみ適用されます。
ドメインの適切なレベルでエントリーを編集して、設定が適切に適用されるようにします。
システムプロパティーはデフォルト設定を設定します。これは、-D または -P 引数で start スクリプトで上書きできます。
注記
ドリフト監視が設定されている場合は、システムプロパティーを追加または編集すると、ドリフトアラートがトリガーされる可能性があります。を参照してください 「設定項目の制御」
利用可能なシステムプロパティーに関する情報は、プロジェクトのドキュメントを確認してください。
システムプロパティーを設定に追加するには、以下を行います。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Configuration タブを開きます。
  5. Properties セクションを展開します。
  6. Paths リストの下部にあるプラス(+)アイコンをクリックします。
  7. 新しいプロパティー情報を入力します。
    • システムプロパティー名。
    • プロパティーの値。
    • プロパティーを稼働中の JVM に即座にロードする必要がある場合や、JVM の起動時にロードする必要がある場合。デフォルトでは、即座に読み込むことができます。
  8. をクリックし OKます。

32.3.10. システムパスの追加

システムパスの一部は、ホームディレクトリー、ログディレクトリー、Java ホームディレクトリーなど、重要なサーバーディレクトリーの場所に対してすでに定義されています。カスタムアプリケーションの場合、他のパスを定義するのに有用または必要になる場合があります。これらはサーバー設定に追加できます。
注記
デフォルトのシステムパスは、リソース設定で編集または削除できません。これらは JBoss EAP 6 のインストール自体によって定義されます。これらのパスは名前 jboss.* user.*、およびで始まり java.*ます。
にあるように EAP 6 サーバー接続設定を編集して、ホームディレクトリーやベースディレクトリーなどのデフォルトのシステムパスの一部を編集でき 「接続設定の編集」 ます。
これらのデフォルトのパスエントリーには、edit および delete アイコンが表示されます。編集ウィンドウが表示され、パスは編集または削除できますが、これらの変更は即座にリセットされます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Configuration タブを開きます。
  5. Paths セクションを展開します。
  6. Paths リストの下部にあるプラス(+)アイコンをクリックします。
  7. パス情報を入力します。
    • 作成するパスの名前。
    • 作成するパス(絶対または相対パス)。
    • 相対パスが Path 値として指定された場合は、Relative フィールドの Unset? チェックボックスの選択を解除し、相対パスの 名前 を入力します。
      たとえば、新しいパスがで devel/、これが EAP ホームディレクトリーとの相対パスである場合、Relative 値は java.home.dir になります。これにより、の最終パスが作成され /opt/jboss-eap-6.0/devel/ます。
    • プロパティーが読み取り専用である場合。読み取り専用プロパティーの作成後は編集 できません。読み取り専用パス(デフォルトのパスから)を削除し、変更する必要がある場合には再作成する必要があります。
  8. をクリックし OKます。

32.3.11. 接続設定の編集

32.3.11.1. EAP 6 サーバーの一般プロパティーの変更

コネクション設定は、JBoss ON エージェントがリソースへの接続に使用するプロパティーです。使用する接続設定は、リソースのプラグイン記述子で識別されます。
接続設定はドメインコントローラーまたはスタンドアロンサーバーでのみ設定可能で、すべての子リソース接続プロパティーはメインサーバー設定から派生します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Inventory タブを開き、Connection Settings サブタブを選択します。
  5. サーバー接続プロパティーは General Properties セクションにあります。プロパティーの一部のみを編集できます。ホームディレクトリー、ベースディレクトリー、サーバータイプ(EAP または AS)などの JBoss EAP 6 インストール自体から派生した情報が表示されますが、非アクティブになります。
    • Hostname サーバーへの接続に使用する IP アドレスを指定します。通常 127.0.0.1 ですが、管理インターフェース設定が変更された場合、IP アドレスは localhost ではなくパブリック IP になります。
    • Port は管理インターフェースのポートです。
    • Secure SSL を使用して JBoss Enterprise Application Platform 6 管理インターフェースと通信するかどうかを示します。JBoss ON エージェントが JBoss Enterprise Application Platform 6 スタンドアロンサーバーまたはホストコントローラーの HTTP 管理インターフェースが SSL を使用することを検出すると、検出中に true に設定されます。
    • Username および Password は、エージェントがログインに使用する JBoss EAP 6 ユーザーのクレデンシャルです。このユーザーが、インストール RHQ ユーザー操作 を使用して作成されている場合、ユーザーはになり rhqadminます。
    • ドメインコントローラーのみ。スタンドアロンサーバーでは、設定とサーバーインスタンスの定義はすべて同じファイル standalone.xml か、起動スクリプトに渡されるその他の設定ファイルにあります。ドメインの場合、サーバー設定は 1 つのファイル(ドメインコントローラー用)で定義されますが、サーバーインスタンスは別のファイル(ホストコントローラー用)で定義されます。Domain Configuration および Host Configuration フィールドには、プロファイル設定、および管理対象サーバーインスタンスを参照する domain/configuration/ ディレクトリー内のファイルの名前がそれぞれ示されます。
  6. ページ上部の Save ボタンをクリックします。
注記
Connection Settings エリアの情報を表示する他に、スタンドアロンサーバーの設定も Configuration タブに表示され(編集できません) Server Environment エリアの下に表示されます。

32.3.11.2. JBoss Enterprise Application Platform 6 サーバーのセキュア接続設定の変更

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Inventory タブを開き、Connection Settings サブタブを選択します。
  5. セキュアな接続設定は Secure Connections Settings セクションにあります。
  6. セキュアな接続設定を適切な情報で構成し、をクリックし Saveます。
  7. JBoss ON は、次の可用性スキャンの後にこれらの設定の使用を開始します。
注記
これらの設定を使用するには、General Settings セクションで「Yes」に設定 Secure する必要があります。詳細は 「EAP 6 サーバーの一般プロパティーの変更」 を参照してください。

32.3.11.3. EAP 6 トピックリソースのインストールパスの表示

管理対象サーバー、サブシステムサービス、JVM 定義、サーバーグループなどの EAP 6 サーバーの子リソースは EAP 6 サーバーの設定ファイル内に定義されます。
子リソースの「接続設定」は、そのサーバー設定のエントリーになります。
コネクション設定は子リソースの Inventory > Connection Settings タブで表示できますが、リソース自体に必須であるため、編集できません。子の接続設定はリソースです。
たとえば、main-server-group 定義はドメインコントローラーの domain.xml ファイルに含まれます。
    <server-groups>
        <server-group name="main-server-group" profile="full">
		...
JBoss ON GUI では、定義は element=name形式の接続設定パスとして指定されます。

図32.9 子リソース接続設定

子リソース接続設定

32.3.12. インストール済み拡張の表示

JBoss EAP 6 のプロファイル(スタンドアロンサーバーおよびドメインの両方)で利用可能なサブシステムはすべて 拡張機能 としてロードされます。これらのエクステンションは、設定ファイル(domain.xml または standalone.xml)で定義されるモジュールのクラスです。
    <extensions>
        <extension module="org.jboss.as.clustering.infinispan"/>
        <extension module="org.jboss.as.clustering.jgroups"/>
        <extension module="org.jboss.as.cmp"/>
        <extension module="org.jboss.as.configadmin"/>
        <extension module="org.jboss.as.connector"/>
        <extension module="org.jboss.as.ee"/>
        <extension module="org.jboss.as.ejb3"/>
	...
これらの拡張機能は JBoss ON では設定できませんが、現在の拡張機能設定はスタンドアロンサーバーまたはドメインコントローラーの設定の一部として JBoss ON で表示できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Configuration タブを開きます。
  5. Installed extensions セクションを展開します。
注記
EAP 6 サーバー設定の Extensions 領域にあるモジュール名の横に編集アイコンが表示されます。これらのプロパティーは読み取り専用で、編集ボックスがポップアップしても編集できません。

32.3.13. サーバー設定の再読み込み

一部の設定変更を有効にするには、EAP 6 サーバーを再起動する必要があります。サーバーは内部的に requires-reload 状態としてマークされています。JBoss ON はリロードを強制しませんが、再読み込みを必要とする変更が加えられているかどうかは管理者に通知します。
注記
JBoss ON は設定が変更されるたびに設定を自動的に再読み込みしないため、管理者は複数の変更を行い、メンテナンスウィンドウ(JBoss ON 経由)またはローカルシステムに cron ジョブを設定して、再読み込み操作をスケジュールできます。
サーバーツリー内 リソースについてConfiguration > Current タブをクリックすると、サーバーのリロードが必要なメッセージボックスが表示されます。

図32.10 設定メッセージのリロード

設定メッセージのリロード
注記
通常、設定をリロードする必要がある変更には、ポート番号のリセットやインターフェースの接続プロトコルの変更など、接続の処理方法を変更する必要があります。
注記
エージェントがオフラインになり、UI で Configuration タブを表示すると、サーバーがリロードされた場合でもメッセージボックスが表示されます。これは、reload 状態が変更したサーバーと通信できなかったため、サーバーが古い情報を表示するためです。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Operations タブを開きます。
  5. ページ下部の New ボタンをクリックします。
  6. ドロップダウンメニューから Reload)オプションを選択します。
  7. Schedule ボタンをクリックします。

32.3.14. 設定項目の制御

設定のドリフト は、時間の経過と共に必要な設定または管理者が定義した設定への変更を蓄積するものです。これらの変更は簡単です。ただし、リソースを目的の設定外に移動します。
設定のドリフトおよび JBoss ON のドリフトモニタリングの詳細は、で説明されてい 15章設定項目の管理 ます。
EAP 6 では、重要な設定をすべてカバーし、管理者の介入なしに修復へのパスを提供するドリフトストラテジーを計画し、実稼働システムを保護するのに役立ちます。
  1. やなどの重要な設定ディレクトリーを追跡するドリフト定義を設定 domain/configuration/ しますがstandalone/configuration/、ロギング、ライブラリー、データディレクトリーなど、常にデータが変更されるディレクトリーは除外されるようにします。設定ディレクトリー内でも、、、host_xml_history/ domain_xml_history/、およびディレクトリーの除外ルールを作成します。これらは適切な設定ファイルではなく standalone_xml_history/、追跡すべきではありません。
  2. 必要な設定が配置されたら、その 設定 をドリフト定義に固定します。これにより、希望の設定がベースラインとして設定されます。すべての変更は、そのベースラインと比較されます。
  3. 設定ファイル設定のアーカイブを作成します。
  4. EAP 6 の設定をリセットし、ドリフトを修正するために自動的にデプロイできるバンドル定義を作成します。
    移行先の作成時には、EAP 6 リソースのプラットフォームである必要があります。宛先はスタンドアロンサーバーまたはドメインコントローラーのいずれかですが、プラットフォームを使用すると、バンドルを期限切れのディレクトリーにデプロイしてから /tmp/mybundles/holding、インストール後のタスクを実行して設定ファイルを configuration ディレクトリーにコピーします。
    通常、バンドルをデプロイすると、ターゲットディレクトリーにある既存ファイルがすべて削除され、バンドルに置き換えられます。この動作を制御する方法はありますが、通常はバンドルの内容が最終デプロイメントの目的と完全に一致するのは安全です。
    バンドルに設定ディレクトリー全体を含めることができないため、ファイルシステム上の別の場所にデプロイすると設定ディレクトリーが保持され、重要な設定ファイルのみが Ant タスクによってコピーされます。
  5. 2 つのことを行う設定のドリフトに関するアラートを設定します。
    • 管理者に通知メールを送信します。
    • バンドルを自動的にデプロイするプラットフォームで CLI スクリプトを実行します。
    25章アラートの定義 JBoss ON サーバーサイドスクリプトを起動するアラート通知を設定する方法や、別のリソースで操作を実行する方法についての情報があります。
注記
EAP 6 リソース設定の変更、JVM 定義設定の変更、サーバーグループおよび管理対象サーバーの追加、または構成設定の変更はすべて EAP 6 設定ファイルの編集 domain.xml および変更を行い standalone.xmlます。これにより、アラートが設定されている場合にドリフトアラートがトリガーされます。

32.3.15. 設定変更の追跡および取り消し

JBoss ON UI または CLI で加えられた設定変更は、変更履歴に記録されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Configuration タブを開き、History サブタブを選択します。
    注記
    変更履歴ページは、リソース設定( Configuration タブ)および接続設定( Inventory > Connection Settings タブ)に対して保持されます。
  5. ID 番号の変更をクリックすると、その バージョン に適用された構成設定が開きます。
  6. 変更内容は、一覧から選択して Compare ボタンをクリックして、標準の diff 形式の変更を比較できます。
  7. 現在、ライブバージョンの設定は、一覧で目的の 以前 のバージョンを選択して Rollback ボタンをクリックすることで、以前のバージョンに戻すことができます。

32.4. JBoss EAP 6 リソースの作成

32.4.1. 履歴の追跡

すべての Inventory タブには Child History サブタブがあります。履歴は、子リソースを追加または削除した場合と、アクションが発生した日付と、JBoss ON ユーザーが開始した日の一覧です。

図32.11 子履歴

子履歴
JBoss ON でのリソースの追加または削除は、インベントリーの変更の追跡を維持するのに役立ちます。

32.4.2. サーバーグループの作成

サーバーグループはドメイン設定の一部として作成され、管理対象サーバーの設定とコンテンツの管理に役立ちます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. ドメインコントローラーエントリーを右クリックします。
  4. Create Child メニューで、の項目を選択し Server Groupます。
  5. 新しいサーバーグループの名前を入力します。
  6. サーバーグループの設定: 使用するプロファイル、使用するソケットバインディンググループ、および設定するシステムプロパティーを入力します。
  7. をクリックし Finishます。

32.4.3. 管理対象サーバーの作成

管理対象サーバーはドメイン内の機能サーバーであり、実際のクライアントの対話を実行します。管理サーバーはドメインコントローラーの子で、管理サーバーの設定と内容はドメインコントローラーの設定にあり、サーバーグループによって割り当てられます。
注記
ドメインコンポーネントを物理システム(「設定とリアルタイム操作の分離: ドメイン」)に編成する方法により、管理サーバーは、その親であるドメインコントローラーと同じ設定エントリーに表示されない場合があります。新しい管理サーバーは、作成されたホストコントローラーの子として一覧表示されます。新しい管理対象サーバーは、そのホストコントローラーのプラットフォーム(エージェント)インベントリーに表示されます。
注記
ジョブの送信後にホストコントローラーで作成プロセスを実行する必要があります。その後、ローカルエージェントは新しいインスタンスを検出する必要があります。ジョブが実行されて完了するスケジュールの場所によっては、新しい管理対象サーバーがエージェントの検出キューに表示されるまでに数分の時間がかかる場合があります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. ドメインコントローラーエントリーを右クリックします。
  4. Create Child メニューで、の項目を選択し Managed Serverます。
  5. 新しいサーバーの名前を入力します。
  6. サーバーの設定を入力します。
    • サーバーを作成する EAP 6 ドメインホスト。
    • サーバーを追加するサーバーグループ。
    • 使用するソケットバインディンググループ。これにより、使用するサーバーインスタンスのベースポート番号が指定されます。
    • ポートオフセット。これは、ソケットバインディング設定に追加して、サーバーインスタンスの実際のポート番号を判断する番号です。ソケットバインディングポートが 1000 で、オフセットが 150 の場合は、管理対象サーバーのそのインターフェースに使用されるポート番号は 1150 になります。
    • EAP 6 ホストの起動時にサーバーが自動的に起動するかどうか。
    • サーバーのシステムプロパティー。
  7. をクリックし Finishます。

32.4.4. JVM 定義の変更

インスタンスの JVM 設定を管理すると、パフォーマンスの向上とシステムリソースの割り当てが改善されます。EAP 6 のドメイン構造の性質上、JVM 設定は CAScade の種類で機能します。ホストコントローラーの JVM 設定はサーバーグループとすべてのサーバーに適用されます。サーバーグループの JVM 設定はホストコントローラー設定をオーバーライドし、すべての管理対象サーバーに適用されます。次に、管理リソースに対して JVM 定義を作成し、その定義により高レベルの JVM 設定が強制されます。

32.4.4.1. リソースとしての JVM 定義

EAP 6 管理コンソールでは、JVM 設定はサーバーエントリーの設定オプションとして処理されます。各サーバーには JVM 設定の設定タブがあり、ホストコントローラーのページの JVM Configurations 下に別の Server ページがあります。

図32.12 EAP 6 コンソールでの JVM 定義

EAP 6 コンソールでの JVM 定義
管理対象サーバー設定と同様に、サーバーグループの設定には JVM 設定のタブがあります。
JBoss ON では、JVM はこれまで別のリソースタイプで、独自の設定とモニタリングを使用していました。EAP 6 では、JVM 定義は、構造的に JVM 定義 が設定プロパティーのコレクションであることが分かりますが、JVM 自体は親リソースとして扱われます。

32.4.4.2. JVM 定義の作成

デフォルトの JVM 定義はすでにホストコントローラーに対して定義され、その JVM 定義はすべてのサーバーグループに適用され、その後にそのグループに関連するすべての管理対象サーバーに適用されます。
サーバーグループまたは管理対象サーバー用に新しい JVM 定義を作成して、これらのデフォルト設定をオーバーライドできます。管理対象サーバーとサーバーグループの定義はホストコントローラーの JVM 定義に基づいています。新しいサーバーグループおよびサーバーの JVM に使用する別のベースを提供するために、追加の JVM をホストコントローラーに追加できます。
重要
ホストコントローラーには複数の JVM 定義を設定できます。デフォルトのデフォルトはすべての管理対象サーバーとサーバーグループで使用されます。また、追加の JVM 定義は管理対象サーバーおよびサーバーグループレベルでカスタム JVM 定義のベース定義として利用できます。
ただし、管理対象サーバーとサーバーグループには JVM 定義は 1 つだけです。UI では、管理対象サーバーとサーバーグループに対して複数の JVM 定義を作成できますが、JVM 定義がすでに存在する場合は最終的な作成手順は失敗します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. JVM 定義を追加するエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し JVM Definitionます。
  5. 定義の名前を入力します。
    注記
    JVM 定義の名前はホストコントローラーの任意の名前になります。管理対象サーバーまたはサーバーグループでは、JVM 定義の名前は、定義のベースであるホストコントローラーの JVM 定義と同じである必要があります。
  6. JVM の設定を入力します。空白のままにすると、親 JVM 定義で定義された値が使用されます。
    JVM の設定の大半は、メモリーとリソースの使用状況に関連するもので、環境変数やその他の設定を JVM に渡すオプションに関連します。この設定の値は、リソースのパフォーマンスとシステム全体のパフォーマンスの両方に悪影響を及ぼす可能性があります。
    設定がに記載されてい 表32.2「JVM 定義プロパティー」 ます。
  7. をクリックし Finishます。

表32.2 JVM 定義プロパティー

property description
JVM オプション 他の Java オプションを設定します。これらのほとんどは、Sun のドキュメントなど Java プロバイダーで文書化されてい http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html ます。
環境変数 JVM で使用する環境変数を設定します。
ヒープサイズ JVM の初期ヒープサイズを設定します。
最大ヒープサイズ JVM の最大許容ヒープサイズを設定します。これを設定しすぎると、メモリー不足のエラーが発生する可能性があります。
Permgen Size 永続生成の初期サイズを設定します。
最大 Permgen サイズ 永続生成の最大サイズを設定します。
type JVM のタイプ。これは、JBoss ON でサポートされる Java タイプである Sun または IBM です。

32.4.4.3. JVM 定義の編集

JVM 定義は、JVM 定義リソースの設定プロパティーを編集して編集されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. EAP サーバーを選択し、適切な JVM 定義エントリーに移動します。
  4. Configuration タブを開きます。
  5. JVM 設定のいずれかを変更します。これらはに記載されてい 「JVM 定義の作成」 ます。
  6. ページ上部の Save ボタンをクリックします。

32.4.5. Parent-Child リソースの短いリスト

JBoss EAP 6 エージェントプラグインで定義するリソースタイプは、数百種類あり、主要なサーバー、サブシステムタイプ、およびサービスをすべて扱います。Resource Reference は、すべての異なるリソースタイプについて説明し、それぞれの子タイプを一覧表示します。
表32.3「Parent-Child リソースの短いリスト」 は、JBoss EAP 6 の一般的なリソースタイプと、JBoss ON UI を使用してそれらのリソースを作成できます。
注記
ジョブの送信後に、子リソースの作成は親リソースで実行する必要があります。次に、ローカルエージェントは新規インスタンスを検出する必要があります。
ジョブが実行されて完了するスケジュールの場所によっては、新しい管理対象サーバーがエージェントの検出キューに表示されるまでに数分の時間がかかる場合があります。

表32.3 Parent-Child リソースの短いリスト

resource 子リソースタイプ
スタンドアロンサーバー
  • デプロイメント
ドメインコントローラー
  • ドメインのデプロイメント
  • 管理対象サーバー
  • サーバーグループ
host
  • JVM 定義
サーバーグループ
  • デプロイメント
  • JVM 定義
データソース(プロファイル下)
  • データソース
  • XA データソース
Infinispan > Hibernate
  • キャッシュ
logging
  • Async ハンドラー
  • Console ハンドラー
  • Custom ハンドラー
  • ファイルハンドラー
  • ロガー
  • Periodic Rotating File ハンドラー
  • Size rotating File ハンドラー
Web
  • connector
  • vhost

32.5. Web アプリケーションのデプロイ

Web アプリケーションは、固有のリソースタイプです。これらはサーバーの子リソースとして追加されるため、独自のエントリー、独自の子リソース、監視、アラート、および操作の独立した設定を持つインベントリー内に場所があります。ただし、Web アプリケーションは コンテンツベースのリソース です。最終的に、これらのパッケージは、実際のサーバーやサービスではなく、ソフトウェアパッケージになります。
コンテンツベースのリソースを管理するには、最初のデプロイメント(デプロイメントを子リソースとして作成)およびパッチおよび更新(コンテンツ更新)のパスも行う必要があります。
重要
コンテンツベースのリソースをデプロイすると、ディスク領域の要件に大きく影響する可能性があります。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部で、コンテンツベースのリソースを元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。
したがって、バックエンドデータベース(Oracle または PostgreSQL)をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。

32.5.1. ランタイム情報およびデプロイメントリソース

32.5.1.1. デプロイメントの表示

EAP 6 と JBoss ON の両方で、Web アプリケーションを中央コンテンツリポジトリーに追加し、そのコンテンツをサーバーグループに関連付けるための明確なワークフローが提供されます。ただし、それらが提供する観点は非常に異なります。そのため、使用するコンソールの定義は、その特定の時点で達成する必要があるものによって異なります。
EAP 6 コンソールは、直ちにコンテンツをサーバーグループに関連付けることに重点が置かれます。EAP 6 コンソールでは、デプロイメントは JVM 定義のように共有設定と同様に処理されます。コンテンツパッケージはドメインコントローラーまたはサーバーグループにデプロイされ、管理サーバーに関連付けられます。

図32.13 ランタイムページでのデプロイメント

ランタイムページでのデプロイメント
JBoss ON は、履歴および変化するパースペクティブである web アプリケーションのライフサイクル管理に重点を置いています。JBoss ON が Web アプリケーションを定義する方法には、基本的な違いがいくつかあります。
  • Web アプリケーションは、個別のエンティティーとして、内およびそれ自体として扱われます。インベントリーには独自の場所があり、ドメインおよびサーバーグループとの関連性は、それらのリソースの子であるため反映されます。
    JBoss ON は、ファイルサイズや特定 SHA256 ハッシュなどのパッケージの詳細も記録します。
  • Web アプリケーションには履歴があります。パッケージの更新が changelog に記録されるため、アプリケーションの維持方法を追跡できます。
  • Web アプリケーションは監視できます。応答時間メトリックは、特に基盤のサーバーのパフォーマンスやモニタリング以外に、Web アプリケーションのパフォーマンスを追跡します。

図32.14 JBoss ON の Deployment Resource Details

JBoss ON の Deployment Resource Details
リソースとしてのこの Web アプリケーションは、コンテンツをサーバーにデプロイする簡単なタスクではないことです。EAP 6 コンソールは、非常に単純かつクリーンに実行できます。JBoss ON 管理の目的は、Web アプリケーションのコンテンツを管理することです。
  • パッチおよび更新を格納するコンテンツリポジトリーの作成
  • 複数バージョンのコンテンツの追跡
  • ソフトウェアパッケージを以前のバージョンに戻す(特にスタンドアロンサーバーの場合)
  • 複数のドメインおよびスタンドアロンサーバーを含む、複数の EAP インスタンスに同じコンテンツリポジトリーを使用
  • コンテンツの変更の追跡(および監査)

32.5.1.2. スタンドアロンサーバーおよびドメインのデプロイメントパス

スタンドアロンサーバーとドメインには、非常に異なる構造があり、Web アプリケーションをデプロイするためのコンテンツフローに影響します。
スタンドアロンサーバーの Web アプリケーションデプロイメントは EAP 5 と似ており、デプロイメントに使用されるローカルファイルシステムディレクトリーがあります。ローカルでは、アプリケーションをデプロイメントディレクトリーに追加し、ホットデプロイできます。JBoss ON を使用すると、Web アプリケーションをデプロイするためのパスは 2 つあります。
  • 子リソースとしてデプロイメントを作成します。
  • バンドルを使用してデプロイメントディレクトリーにアプリケーションをプロビジョニングします。
バンドルシステムには、複数のバージョンを保存したり、更新をロールバックしたり、更新のバージョンをスキップしたり、デプロイメントを 1 つのボタンと共にパージする機能があるため、バンドルの使用は多用途で実用的な管理方法です。
ただし、バンドルシステムは実際のファイルシステムの場所でのみ機能します。JBoss EAP 6 ドメインの分散構造およびモジュール構造は、バンドルがオプションではないことを意味します。
EAP 6 ドメインの場合、コンテンツは子リソースとしてドメインにデプロイされ、管理者によってサーバーグループに伝播されます。
バンドルシステムの柔軟性と細かな機能はありませんが、通常のコンテンツシステムを使用すると、コンテンツのバージョンと更新を制御する方法が提供されています。コンテンツベースのリソースは、JBoss ON のコンテンツリポジトリーに関連付けることができます。これらのリポジトリーは、さまざまなコンテンツソースから、さまざまな種類のソフトウェアパッケージを保存できます。リポジトリーのパッケージは、リソースに選択的にインストールできます。さらに、リソースを複数のリポジトリーに関連付けることもできます。JBoss ON のコンテンツリポジトリーは、バンドルでの変更の更新や元に戻す際にフラッシュされませんが、個別のパッチファイルを web アプリケーションに適用したり、完全な更新をロールアウトするためのパスルートを提供します。
コンテンツ管理全般は、を参照してください 28章リソースレベルのコンテンツ更新の管理。ここでは、コンテンツリポジトリーの設定、リソースのサブスクライブ、および更新のプッシュについて説明します。

32.5.2. ドメインへの Web アプリケーションのデプロイメント

32.5.2.1. ドメインへの Web アプリケーションを帰リソースとしてデプロイ

注記
他の子リソースを作成する場合と同様に、新しいデプロイメントが JBoss ON インベントリーに追加され、表示されるまで数分かかることがあります。これは、ローカルシステムで新しいリソースを作成し、エージェントが検出する必要があるためです。リソースの作成時に検出スキャンが実行されている場合は、次の検出スキャンが 15 分以上検出されるまでかかることがあります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 ドメインコントローラーを選択します。
  3. ドメインコントローラーエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し DomainDeploymentます。
  5. バージョン番号を入力します。
  6. EAR、WAR、または JAR ファイルをアップロードします。
  7. オプションで、デプロイメントのランタイム名を入力します。
  8. ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。
    注記
    タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。
    特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
  9. をクリックし Finishます。
パッケージがアップロードされると、ドメインの DomainDeployments ディレクトリーに新しいリソースエントリーが追加されます。

図32.15 ドメインデプロイメントディレクトリー

ドメインデプロイメントディレクトリー

32.5.2.2. バンドルを介したドメインへの Web アプリケーションのデプロイ

アプリケーションは、ant バンドルレシピを使用して rhq:handover 要素とともに JBoss Enterprise Application Platform 6 ドメインにデプロイできます。一般的な ant バンドルレシピの詳細は、を参照してください 27章バンドルへのコンテンツおよびアプリケーションのデプロイ
以下の ant バンドルのサンプルにより、「website.war」が「main-server-group-01」 JBoss Enterprise Application Platform 6 ドメインサーバーグループにデプロイされます。
<project name="handover-test-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle">
 <rhq:bundle name="example.com (EAP 6)" version="1.0" description="example.com corporate website hosted on EAP 6">

  <rhq:input-property name="myapp.runtime.name" defaultValue="website.war" required="true"/>
  <rhq:input-property name="myapp.serverGroup.name" defaultValue="main-server-group-01" required="true"/>

  <rhq:deployment-unit name="example.com deployment unit" compliance="filesAndDirectories">
   
   <rhq:file name="prepareDatasource.cli" replace="true">
    <rhq:handover action="execute-script"/>
   </rhq:file>
   <rhq:archive name="website.war">
    <rhq:handover action="deployment">
     <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/>
     <rhq:handover-param name="serverGroup" value="${myapp.serverGroup.name}"/>
    </rhq:handover>
   </rhq:archive>
  </rhq:deployment-unit>
 </rhq:bundle>
 <target name="main"/>
</project>
特定のハンドオーバーアクション、ハンドオーバーパラメーター、およびレシピの例については、にナビゲートして見つかった JBoss Enterprise Application Platform 6 プラグインドキュメントを参照してください Administration > Configuration > Agent Plugins > JBoss Application Server 7.x
Ant Bundle を JBoss Enterprise Application Platform ドメインにデプロイするには、以下を実行します。
  1. トップメニューで、Bundles タブをクリックします。
  2. Bundle セクションの New ボタンをクリックします。
  3. を選択 UploadChoose てクリックし、目的のディストリビューションファイルに移動して選択します。
  4. をクリックし Nextます。
  5. 必要なバンドルグループを選択し、をクリックし Nextます。
  6. をクリックし Finishた後 Next、をクリックします。
  7. 新たにアップロードしたバンドルの Bundle セクションをクリックします。
  8. バンドルの詳細の Deploy ボタンをクリックします。
  9. 宛先情報を入力し、ウィザードに進みます。
注記
バンドルの宛先情報を指定する場合は、ドメインコントローラーのリソースグループを基にする必要があります。
ant バンドルで server group パラメーターを指定する場合、これはアプリケーションがデプロイされる JBoss Enterprise Application Platform ドメインのサーバーグループになります。

32.5.3. サーバーグループへの Web アプリケーションの割り当て

さまざまなグループに Web アプリケーションを手動で割り当てると、管理者は、で拡張されたようにアプリケーションのライフサイクルを制御でき 「拡張例: Web アプリケーションの割り当てと更新の管理」 ます。異なるオペレーティング環境で同じコンテンツが使用されます。
注記
Web アプリケーションは、ドメインにデプロイするプロセスと同様に、サーバーグループに直接デプロイでき 「ドメインへの Web アプリケーションのデプロイメント」 ます。
ドメインのデプロイメントパスは、コンテンツをドメインコントローラーにアップロードしてからそのコンテンツをサーバーグループに分散することです。サーバーグループへのデプロイメントの作成は同じプロセスに従います。ドメインにデプロイしてサーバーグループに送信します。ショートカットのみを提供します。
ドメインコントローラーにコンテンツがすでに存在する場合は、ここで説明するドメインコントローラー操作でコンテンツをデプロイする必要があります。
コンテンツをドメインにデプロイすると、最初にドメインが種類のリポジトリーとして使用されます。ドメインから、同じパッケージを複数のグループにデプロイできます。また、ドメインにデプロイすると、管理者は、同時に複数のパッケージをグループまたは指定した順序で、同じ操作で複数のパッケージをデプロイできます。これにより、サーバーへのコンテンツストリームを制御するのに役立ちます。
重要
サーバーグループの新たにデプロイされたコンテンツは、正常に作成された場合でも 24 時間限り JBoss ON インベントリーに表示されない場合があります。デフォルトでは、サービスの検出スキャンは 24 時間ごとにのみ行われます。新しいコンテンツベースのリソースを表示するには、エージェントの検出スキャンを実行し、手動で検出します。
注記
デプロイメントはドメインで子リソースとして作成され、操作としてサーバーグループに割り当てられ、最後にドメインの Content タブで更新されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 ドメインコントローラーを選択します。
  3. DomainDeployments フォルダーを展開します。
    デプロイメントフォルダーにすべての Web アプリケーションをデプロイするには、デプロイメントフォルダー自体を選択して操作を実行します。
    単一の Web アプリケーションをデプロイするには、特定の Web アプリケーションを選択します。
  4. サーバーの Operations タブを開きます。
  5. ページ下部の New ボタンをクリックします。
  6. ドロップダウンメニューから Assign to Server-Group オプションを選択します。
  7. アプリケーションをデプロイするグループ(またはすべてのグループ)を選択します。
  8. 操作の実行時やタイムアウト期間のスケジュールなど、操作の標準情報を入力します。
    注記
    タイムアウト期間は、操作がタイムアウトして失敗したことを想定するまでのサーバーが待機する時間を設定します。これは、操作の実行に失敗したり、停止したりすることを意味するわけではありません。
  9. 複数の Web アプリケーションをデプロイしている場合は、パッケージがデプロイされる順序を設定する方法に Execute ラジオボタンを設定します。すべてのパッケージは一度にデプロイすることも、特定の順序でデプロイすることもできます。
  10. Schedule ボタンをクリックします。
  11. 必要に応じて、エージェントで検出スキャンを実行して、新しいコンテンツリソースを検出します。デフォルトでは、サービスの検出スキャンは 24 時間ごとに実行されるため、新規コンテンツの検出に時間がかかる可能性があります。
    1. UI でエージェントエントリーを開きます。
    2. Operations タブを開き、execute prompt command 操作を選択します。
    3. discovery コマンドを操作 rgument として入力します。これで検出スキャンが実行されます。
    4. Schedule ボタンをクリックします。

32.5.4. 拡張例: Web アプリケーションの割り当てと更新の管理

設定

Tim the IT Guy は、開発からステージングおよび実稼働環境まで、Web アプリケーションの進捗を明確にしたいと考えています。EAP 6 のネイティブ構造では、異なるサーバーグループを作成し、各ステージでテストを渡す際に、中央ドメインコントローラーから適切なサーバーグループにコンテンツをデプロイできます。

IT Guy が希望する Tiim はそのパスの上にレイヤーを追加し、適用パッチおよび更新の作成を可能にします。メンテナンススケジュールの一部として、修正を管理し、監査できるようにする必要があります。

The Plan

  1. Tim は、まず維持する必要のあるサーバーグループの概要を示します。シンプルな環境では、3 つのグループ(testing、staging、および production)が必要です。
  2. 2 つのコンテンツリポジトリーを作成します。1 つはパッチ用で、もう 1 つは Web アプリケーションの新しいバージョン用です。
  3. ドメインデプロイメントを作成し、web アプリケーションを testing サーバーグループにプロモートします。
  4. Tim は、Web アプリケーションの応答時間監視を設定します。テストエリアで必要なパフォーマンスパラメーターを満たすと、Tim はデプロイメントをステージング環境にプロモートし、次に実稼働サーバーグループにプロモートします。

結果

各デプロイメントのパッケージ履歴により、Web アプリケーションがデプロイされた時点、バージョン、およびそのコンテンツを追跡できます。

Tim は、コンテンツをリポジトリーにデプロイし、サブスクライブしているすべてのリソースにインストールすることで、パッチまたは完全なアップデートを適用できます。コンテンツの新しいバージョン番号など、このパッケージの変更はパッケージ履歴に含まれています。
パッチおよび更新リポジトリーは特定の JBoss Enterprise Application Platform 6 ドメインではなく、JBoss ON 自体に設定されているため、必要に応じて他のドメインおよびスタンドアロンサーバーと使用するパッケージを使用できます。

32.5.5. ドメインサーバーグループでの Web アプリケーションの有効化および無効化

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 ドメインコントローラーを選択します。
  3. インベントリーツリーでフォルダーを展開し、web アプリケーションを選択 DomainDeployments して一覧から有効または無効にします。
  4. Web アプリケーションの Configuration タブを開きます。
  5. Assigned to セクションで、Web アプリを有効または無効にするサーバーグループに対応する Server Group 行の青の鉛筆をクリックします。
  6. Enabled 行で Yes または No を選択し、OK をクリックします。
  7. Save ボタンをクリックします。

32.5.6. デプロイメントコンテンツの更新

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 サーバーを選択します。
  3. DomainDeployments フォルダーを開きます(スタンドアロンサーバーでは Deployment フォルダーを使用)、更新する Web アプリケーションを選択します。
  4. Web アプリケーションの詳細ページで Content タブを開き、New サブタブをクリックします。
  5. UPLOAD NEW PACKAGE ボタンをクリックします。
  6. UPLOAD FILE ボタンをクリックします。
  7. ポップアップウィンドウで Add ボタンをクリックし、ローカルファイルシステムをアップロードする更新されたコンテンツファイルを参照します。
  8. UPLOAD ボタンをクリックします。
  9. Web アプリケーションパッケージを保存するリポジトリーを選択します。これは不要ですが、更新されたパッケージを JBoss ON に保存して、他の JBoss EAP 6 デプロイメントで使用できるようにすることが推奨されます。
  10. バージョン情報を入力します。
  11. 新しいパッケージの詳細を確認してから、をクリックし CONTINUEます。
パッケージが正常にアップロードされると、UI は Content タブの履歴ページにリダイレクトします。

図32.16 リソースのデプロイメント履歴

リソースのデプロイメント履歴

32.5.7. Web アプリケーションのスタンドアロンサーバーへのデプロイ

スタンドアロンサーバーは、特定のファイルシステムディレクトリーをデプロイメントディレクトリーとして使用します。ドメインのデプロイメントと同様に、子リソースを作成してコンテンツをデプロイすることができます。ただし、スタンドアロンサーバーの構造がシンプルであるため、コンテンツはコンテンツバンドルを使用してデプロイすることもできます。バンドルは、単純化された更新およびパスの元に戻すだけでなく、より詳細なバージョン管理システムを提供します。

32.5.7.1. Web アプリケーションの クライアントリソースとしてのデプロイ

重要
新しいデプロイメントは、正常に作成された場合でも数分または 24 時間間 JBoss ON インベントリーに表示されない場合があります。これは、作成後にエージェントがインベントリーに追加するために新しいリソースを検出する必要があるためです。デフォルトでは、サービスの検出スキャンは 24 時間ごとにのみ行われます。
即座に表示するには、エージェントで 実行プロンプトのコマンド 操作を実行し、discovery コマンドを入力します。これで検出スキャンが実行されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 6 スタンドアロンサーバーを選択します。
  3. ナビゲーションツリーのスタンドアロンサーバーエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し Deploymentます。
  5. バージョン番号を入力します。
  6. EAR、WAR、または JAR ファイルをアップロードします。
  7. オプションで、デプロイメントのランタイム名を入力します。
  8. ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。
    注記
    タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。
    特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
  9. をクリックし Finishます。

32.5.7.2. バンドルへの Web アプリケーションのデプロイ

バンドルアーカイブとレシピの作成、宛先の定義、およびバンドルバージョンの管理については、を参照してください 27章バンドルへのコンテンツおよびアプリケーションのデプロイ
  1. トップメニューで、Bundles タブをクリックします。
  2. ディストリビューションファイルをアップロードし、デプロイメントウィザードにアクセスしてバンドルバージョンを作成します。
  3. ウィンドウの下部までスクロールし、Deploy ボタンをクリックします。
  4. デプロイするバンドルを選択します。
  5. JBoss スタンドアロンサーバーの宛先情報を定義します。宛先は、互換性のあるグループ(JBoss リソースを含む)とバンドルをデプロイするディレクトリーの組み合わせです。
  6. デプロイメントウィザードを完了し、必要なプロパティーを設定します。

32.5.8. コンテンツ履歴の追跡および変更の取り消し

デプロイメント履歴ページでは、コンテンツベースのリソースへの変更を追跡します。つまり、更新の試行、タイムスタンプ、およびバージョン番号が一覧表示されます。

図32.17 リソースのデプロイメント履歴

リソースのデプロイメント履歴
バンドルプロビジョニングシステムを介してスタンドアロンサーバーにデプロイされた Web アプリケーションには、変更を元に戻すための簡単なパスがあります。詳細ページには、デプロイしたバージョンに最新のデプロイメントに戻る Revert ボタンがあります。
ただし、サーバーグループまたはドメインへのデプロイメントは、同一のクリアパスを持ちません。コンテンツデプロイメントを元に戻す場合は、最終的にそれを別のバージョンに置き換えることになります。
直接のバージョンを変更できない場合には、パッケージを変更する方法があります。
  • ドメインデプロイメントまたはサーバーグループのデプロイメントがコンテンツリポジトリーに関連付けられている場合は、更新されたパッケージをコンテンツリポジトリーにアップロードし、変更を関連するリソースに同期します。
  • 更新されたパッケージをドメインデプロイメントにアップロードし、deploy を使用して操作をグループ 化して、更新されたパッケージをサーバーグループに送信します。

32.5.9. バージョン管理されたデプロイメントおよびサブデプロイメント

JBoss ON 3.3 および JBoss ON JBoss Enterprise Application Platform 6 プラグインは、JBoss Enterprise Application Platform 6 の管理対象デプロイメントとスタンドアロンデプロイメントの両方(WAR、SAR、JAR、EJB など)および Subdeployments(WAR、SAR、JAR、EJB など)をサポートします。Versioned Deployment(または Subdeployment)は、アーティファクトのバージョンがその名前(例: myapp-1.0.war、myapp-1.1.war、myapp-2.0.war)に組み込む際に存在します。デフォルトでは、アーティファクトが Versioned Deployment(または Subdeployment)として認識されると、そのバージョン番号が削除され、インベントリー内のその名前に一致するリソースが指定のバージョン番号で更新または作成されます。
たとえば、アーティファクト「myapp-1.1.war」がデプロイされている場合、JBoss ON JBoss Enterprise Application Platform 6 プラグインはインベントリーで「myapp.war」という名前のリソースを探し、バージョン番号を「1.1」にリセットします。そうでない場合は、「myapp.war」という名前の新しいリソースが作成され、バージョン番号が「1.1」になります。このアプローチの利点は、JBoss ON が複数の個別のリソース(例: myapp-1.0.war や myapp-1.1.war)ではなく、バージョン管理されたアーティファクトを単一のリソースとして追跡できることです。これにより、リソースの過去のデータをすべてそのまま維持でき、以前のバージョンのリソースが「DOWN」状態で永続的に表示されるのを回避できます。
JBoss ON はデフォルトでアーティファクトに「Maven-style」バージョンを使用します。これには、バージョンのタイムスタンプをダッシュで区切って区切り、少なくともメジャーバージョンとマイナーバージョンをピリオドで区切る必要があります。
JBoss ON では、デフォルトで以下の正規表現が使用されます。
^(.*?)-([0-9]+\\.[0-9].*)(\\..*)$
注記
バージョン管理スキームと一致しないアーティファクトは個別のリソースとして表示されます。たとえば、myapp-1.war、myapp-2.war、myapp1.war、および myapp2.war は 4 つの異なるリソースとして表示されます。
注記
Versioned Deployments および Subdeployments を無効にするには、JBoss ON JBoss Enterprise Application Platform 6 プラグインで versionedSubsystemDiscovery パラメーターを無効にすることができます。このプロパティーが更新されるには、起動前に適用可能なエージェントごとに更新する必要があります。

32.5.9.1. 既存のリソース

初回起動時に、エージェントはバージョンスキームに一致する既存のリソースを変換しようとします。さらに、同じリソースの複数のバージョンが同時にデプロイされた場合(例: myapp-1.1.war および myapp-2.0.war)、JBoss ON は、同じ論理リソース(myapp.war)の両方へのアップグレードを試みます。このような場合に問題を解決するには、アップグレードの前に不必要なリソースを無効にするか、またはバージョン管理のデプロイメントを無効にする必要があります。
注記
Versioned Deployments を使用する場合は、MISSING ポリシーを DOWN(デフォルト)として設定する必要があります。この設定を変更すると、更新ウィンドウでリソースが削除されたり、無視されてしまう可能性があります。

32.5.10. デプロイメントのトラブルシューティング

問:
デプロイメントでは失敗と示唆されますが、パッケージの再デプロイを試みると、リソースがすでに存在することを示すため、失敗します。
答:
考えられる原因の 1 つが、パッケージのデプロイ時のタイムアウト設定です。タイムアウト時間は、デプロイ操作が失敗した場合に JBoss ON サーバーが待機する時間を設定します。これは、実際にデプロイ操作自体を停止したり、制限したりしません。操作がタイムアウトの制限に達する場合でも、操作は正常に完了し、Web アプリケーションが正常にデプロイされます。
操作がタイムアウトすると、エージェントは新しいリソースを自動的に検出しません。Web アプリケーションは手動でインベントリーにインポートする必要があります。
問:
サーバーグループにパッケージをデプロイしようとしましたが、デプロイメントが一覧に表示されません。
答:
考えられる原因は以下のとおりです。
  • エージェント検出スキャンが実行されていません。検出の実行には数時間かかる可能性があるため、アプリケーションが検出キューに表示されるまで時間がかかる場合があります。これを回避するには、エージェントで検出スキャンを実行します。
  • パッケージが ドメイン にすでにデプロイされている。サーバーグループでデプロイメント子を作成すると、実際に(コンテンツが保存される)ドメインにデプロイメントを作成し、そのデプロイメントをサーバーグループにデプロイします。パッケージがドメインにすでに存在する場合は、サーバーグループでデプロイメントを複製として再度作成しようとすると失敗します。
    この場合は、デプロイを使用してドメインコントローラーでサーバーグループ 操作を行い、アプリケーションをデプロイします。

32.6. JBoss EAP 6 リソースの監視

32.6.1. ランタイム情報および JBoss ON Monitoring

メトリクスは、リソースまたはリソースのグループの実行方法に関する情報のライブストリームです。メトリックは、患者のストレス率、付いたプレッシャー、および知能レベルなどの重要な記号です。リソースでは、これらの重要な統計は可用性、データベースキャッシュのページヒット、データソースまたは Web アプリケーションのアクティブな接続などです。このメトリクスは、特定時に確認されたリソースの正常性を表示します。
JBoss EAP 6 コンソールは、データソース、トランザクション、Web アプリケーションなどの重要なリソースで、重要なメトリック情報の現在および即時スナップショットを示しています。
この変更情報は EAP 6 コンソールの Runtime タブに表示されます。

図32.18 EAP 6 Runtime Metrics

EAP 6 Runtime Metrics
ランタイム情報は、その時点の健全性を示します。
時間の経過と共に ランタイム情報を確認すると、通常、リソースの実行方法がはるかに改善されます。JBoss ON のすべてのリソースには、監視を表示および設定し、そのモニタリングに基づいてアラートを設定するエリアがあります。
JBoss ON は、管理者がパフォーマンスデータを処理するのに役立つように、ランタイムメトリクスをいくつかの異なる方法で自動的に処理します。
  • 各メトリクスの時間ベースのモニタリンググラフ
  • リソースの実際のパフォーマンス で計算された操作パラメーター、またはベースライン
  • 稼働時間の割合、復旧時間、およびダウンタイムの平均

図32.19 単一のメトリックの JBoss オンベースライン

単一のメトリックの JBoss オンベースライン
JBoss ON は GUI を介して、個別のリソースの監視データも公開します。
  • リソースにはより多くのメトリクスを使用できます。少なくとも、すべてのリソースには可用性監視があります。データソースや管理サーバーなどの一部のリソースには、ルーチン監視で有効にできる多くのメトリクスがあります。
  • 応答時間監視は、Web アプリケーションの特定の URL およびページに対して設定できます。これにより、管理者は、Web アプリケーションのユーザビリティーやカスタマーエクスペリエンスを、接続数などの内部メトリクスと共に追跡できます。
  • イベントログ監視は、異なるエラーログからの重要なメッセージをフィルタリングできます。これにより、JBoss ON はパフォーマンスしきい値を超えていない問題に対して(アラート経由)応答し、ログイベントとパフォーマンスメトリックを関連付けることもできます。

32.6.2. EAP 6 リソースの監視の設定

JBoss EAP 6 管理コンソールの Runtime タブは、管理対象サーバーの状態と共通のサブシステムの現在のスナップショットを提供します。EAP 6 コンソールは、現在の情報にすばやくアクセスできます。これにより、即座に管理タスクを行うことが容易になります。
JBoss ON は、直接的なビューではなく、長期のパフォーマンス追跡に重点を置いています。JBoss ON の EAP 6 エージェントプラグインを使用すると、管理者はリソースの追加のメトリクスを監視し、履歴測定を追跡し、パフォーマンスベースラインを確立し、リソースのステータスが変更(スケールダウン)と、異なる状態にあるかを確認できます。

図32.20 グラフの監視

グラフの監視
モニタリング情報はグラフおよび Monitoring タブのテーブルに表示されます。Summary タブには、モニタリングポートレットで視覚的に異なるライングラフが表示されます。
注記
概念と設定の監視に関する詳細は、を参照してください パートIII「監視」

32.6.2.1. 追加メトリクスの有効化

JBoss ON は、EAP 6 コンソールに表示される JBoss EAP 6 リソースのすべてのメトリクスと、追加のメトリクスをサポートします。
しかし、JBoss ON ではデフォルトで有効になっているメトリクスは、EAP 6 コンソールで表示できないものとは異なる場合があります。たとえば、データソースの場合、EAP 6 コンソールは、利用可能な接続数、アクティブな接続数、および使用最大接続数を表示します。JBoss ON では、収集されるデフォルトのメトリクスは最大および最小プールサイズ設定、最大待機時間、および 1 分あたりのタイムアウト数です。
注記
リソースタイプごとに可能なメトリクスの完全リストは、「リソースの 完了」を参照してください
リソースに対してメトリクスコレクションを有効または無効にできます。管理者は、指定のメトリクス( コレクション間隔)をチェックする JBoss ON の頻度をリセットすることもできます。
注記
重要度の低いメトリックをチェックすると、プラットフォームやエージェントのパフォーマンスが向上しますが、参照またはイベントの関連付けに関する情報を記録できます。
リソースの監視設定を変更するには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。その後、JBoss EAP 6 サーバーを選択し、編集するリソースに移動します。
  3. リソースエントリーの Monitoring タブをクリックします。
  4. Schedules サブタブをクリックします。
  5. メトリックを有効にするには、以下を実行します。
    1. メトリクスの行を選択します。Ctrl キーを使用して複数のメトリクスを選択できます。
    2. ページ下部の Enable ボタンをクリックします。
  6. メトリックのコレクション間隔を変更するには、以下を実行します。
    1. メトリクスの行を選択します。複数のメトリクスは同じ頻度に変更されていれば、Ctrl キーを使用して複数のメトリクスを選択できます。
    2. 適切な時間単位(秒、分、時間)で、目的のコレクション期間を Collection Interval フィールドに入力します。
    3. をクリックし Setます。
    注記
    無効なメトリックのコレクション間隔を変更すると、メトリクスが自動的に有効になります。

32.6.2.2. 可用性監視

可用性は(大半の)直接的な測定値で、リソースが実行中で最小限の応答であるかどうかを示します。エージェントがリソースに接続できる場合は、そのリソースが利用できます。
これは、リソースの EAP 6 コンソールに可用性を表示する方法です。これは、リソースが現在実行しているかどうかを示します。

図32.21 EAP 6 コンソールでの可用性

EAP 6 コンソールでの可用性
パフォーマンスの観点として、可用性 は単に実行しているよりも、グレーのグレーの粒度を得られる場合があり ます。たとえば、リソースが周期的にオフになり、繰り返し発生しているか調べる必要があります。回復するまでは、長期間オフライン状態であるか。自身の障害によりリソースが利用できないか、または(プラットフォームなどの)親リソースに到達できない場合、子が正常に動作しているか。JBoss ON は、リソースの実際の状態を区別するために、up、down、disabled、および unknown の 4 つのリソース状態をサポートします。
可用性については、を参照してください 18章可用性
JBoss ON では、リソースの現在のステータスを示すだけでなく、その状態にある時間と、リソースがさまざまな状態で費やした時間の割合も表示されます。これにより、JBoss ON はリソースごとにいくつかの異なる傾向を計算することができます。
  • 全体のアップタイム率
  • さまざまな状態(up、down、または disabled)で費やされた合計時間
  • 失敗の総回数(停止時)
  • 障害間の時間(基本的にはリソースが稼働中および利用可能時間)
  • リカバリーの平均時間。これは障害後にリソースをバックアップするのにかかる時間です。

図32.22 JBoss ON での可用性

JBoss ON での可用性
可用性は、モニタリングメトリクスなどのスケジュールで収集されます。可用性チェックの頻度を制御すると、リソースの優先度が確立されます。
注記
ドメインコントローラーや管理対象サーバーなどのサーバーには、毎分実行される可用性チェックがあります。これにより、不安定なサーバーでリソースのサイクリングを取得するのに役立ちます。データソースや JMS キューなどのサービスは、10 分ごとに可用性についてチェックされます。
可用性チェックの頻度は、エージェントのパフォーマンスに影響を及ぼす可能性があります。特に、多くの子リソースを持つ EAP 6 のようなサーバーに対する影響があります。デフォルトでは、すべてのリソースが利用可能かどうかがチェックされます。OSGi クラスや EJB などの低レベルの子リソースが、実際に独立した可用性チェックを必要としないことがあります。この場合、子の可用性チェックを無効にできます。エージェントは、親の状態を子に自動的に適用します。親が実行中である場合、親は実行していると見なされます。これはバックフィルと呼ば ます。

32.6.3. イベント監視の設定

イベント監視は基本的にログフィルターです。リソース自体はログファイルを維持します。JBoss ON は、指定されたログファイルで発生したメッセージまたはイベントをチェックします。JBoss ON は、ストリーム内のメッセージや、特定のパターンまたは重大度に一致するメッセージのみをチェックできます。
JBoss ON はログメッセージに基づいてアラートを発行する可能性があり、新しい管理リソースの作成やサーバーを再起動など、イベントに対応して自動的にアクションを実行することもできます。
イベントはスケジュールではなく、リソースの実際の操作に基づいて予測できないため、管理者がメッセージをフィルターして動的に応答できる大きな利点があります。
注記
イベント設定は、を参照してください 20章イベント
3 つの JBoss EAP 6 サーバータイプはイベントをサポートし、標準の場所にイベントログで事前設定されています。
  • ホストコントローラー、 domain/log/host-controller.log
  • 管理対象サーバー( domain/servers/server-three/log/server.log
  • スタンドアロンサーバーの場合 standalone/log/server.log
イベントログが設定されている間、デフォルトでは有効になっていません。イベントが JBoss ON エージェントによって収集される前に、イベントログを有効にする必要があります。ログメッセージで検索する特定の文字列などの追加設定も設定できます。
  1. トップメニューの Inventory タブをクリックします。
  2. Servers - Top Level Imports 項目をクリックし、JBoss EAP 6 リソースを選択します。
  3. 適切な EAP 6 リソースに移動します。
  4. リソースエントリーの Inventory タブをクリックします。
  5. Connection Settings サブタブを選択します。
  6. Events Log セクションの下にあるプラスアイコンをクリックします。
  7. イベントエントリーを有効にします。
    必要に応じて、日付の形式、文字列フィルターを設定してメッセージ、またはメッセージの重大度を追加します。
イベント監視を有効にすると、一致するログメッセージがリソースの Events タブに表示されます。

図32.23 JBoss EAP 6 イベントロギング

JBoss EAP 6 イベントロギング

32.6.4. JBoss EAP 6 リソースでのアラート

アラートの詳細は 25章アラートの定義、で詳細に説明しています。これは、設定するアラート条件および応答方法を計画する際の詳細な参考となります。
アラートの計画における主な事項は、アラートを発生させた条件に対する自動応答をプランニングすることです。たとえば、EAP 6 ドメインでは、1 つの管理対象サーバーがオフラインになるか、または非常に遅い応答時間の表示を開始することがあります。この場合、JBoss ON は、障害が発生したサーバーの代わりに別のプラットフォームに同じサーバーグループ内に新しい管理対象サーバーインスタンスを自動的に作成できます。
お客様がアクセスする問題(web アプリケーションの応答時間が十分ではない場合など)には、管理者の介入を必要とせず、即座に対応できます。
JBoss ON では以下のようなタイプの応答を使用できます。
  • 管理者へのメール送信
  • アラートリソースでの再起動操作の実行
  • アラートリソースの親に対する操作の実行
  • シェルスクリプトの実行
  • JBoss ON サーバーサイドスクリプトの実行
    サーバー側のスクリプトは非常に強力なものです。スクリプトは、リソース設定の変更、更新されたパッケージのデプロイ、新規リソースの作成、既存リソースの削除、オペレーションの実行、上記のすべてなど、JBoss ON でほぼすべての管理タスクを実行できます。サーバー側のスクリプトの作成に関する詳細は、『 JBoss ON Command-Line Scripts 』の「Writing JBoss ON Command-Line Scripts」 を参照してください。

32.6.5. JBoss EAP 6 リソースでのドリフト設定監視

JBoss ON は、JBoss Enterprise Application Platform 6 プラグインを使用したドリフト設定モニタリングをサポートします。drift Configuration Monitoring を使用すると、ユーザーはスタンドアロンリソースとホストコントローラーリソースの両方でサーバー設定ディレクトリーに加えられた設定ファイルの変更を監視および追跡できます。これは、JBoss ON によって設定ファイルに加えられた変更や、JBoss Enterprise Application Platform CLI または JBoss Enterprise Application Platform 管理コンソールを使用して変更された変更に適用されます。JBoss ON のドリフト設定モニタリングは、アプリケーションやデータソースなどの JBoss Enterprise Application Platform 6 へのデプロイメントを追跡および監視します。設定のドリフトの管理に関する詳細は、を参照してください 15章設定項目の管理
Drift 設定モニタリングを有効にするには、以下を実行します。
  1. トップメニューで、をクリックし Inventoryます。
  2. 左側の Resources メニューテーブル Servers - Top Level Imports から選択します。
  3. インベントリーツリーでスタンドアロンまたはホストコントローラーを選択し、設定のドリフトを監視します。
  4. Drift タブをクリックします。
  5. 下部の New ボタンをクリックします。
  6. ドロップダウンメニュー Template-Configuration Files から選択し、をクリックし Nextます。
  7. 設定オプションを入力し、Finish をクリックします。

32.7. EAP 6 での mod_cluster サービスの使用

mod_cluster モジュールは、JBoss アプリケーションサーバーの Web コンテキストと Apache Web サーバーとの間に動的な負荷分散を提供します。
クラスターを作成する方法は 2 つあり mod_clusterます。JBoss でモジュールを設定して web アプリケーションを管理し、Apache でモジュールを設定してセッションおよびルーティングを管理します。
JBoss ON は、ドメインサーバーとスタンドアロンサーバーの両方で JBoss EAP 6 の埋め込み mod_cluster サブシステムを管理できます。

32.7.1. mod_cluster および JBoss ON について

EAP 6 の mod_cluster モジュールであるモジュールは、JBoss EAP サーバーの web アプリケーションと Apache Web サーバーの間で通信します。複数の JBoss EAP サーバーを mod_cluster グループに含めることができ、これらのサーバーは管理対象サーバー、スタンドアロンサーバー、または両方を混在させることができます。

図32.24 mod_cluster トポロジー

mod_cluster トポロジー
mod_cluster モジュールが含まれる高可用性プロファイルのみ。ドメインでは、高可用性をサポートするプロファイル( full-ha プロファイルやカスタムプロファイルなど)を使用できますが、other-server-group サーバーグループはこの ha プロファイルを使用するように設定されます。スタンドアロンサーバーの場合、サーバーは standalone-ha.xml 設定で起動する必要があります。
サーバー内の 1 つの EAP mod_cluster サーバーがマスターノードです。これは管理 mod_cluster サービスです。クラスターの他のすべてのメンバーはワーカーノードです。
注記
一般 mod_cluster の情報は mod_cluster プロジェクトドキュメンテーション で入手できます。
特定のリソースが mod_cluster ドメインに属するかどうかは、リソースに関連するプロファイルによって異なる(JBoss ON の制御のほとんどは)。(当然ながらスタンドアロンサーバーは起動スクリプトに JBoss ON の設定を使用して高可用性 JAVA_OPTS 設定を使用するか、高可用性プロファイルを使用する新しい管理サーバーを作成できます。ただし、プロファイル定義自体は JBoss ON の外部で作成され、維持されます。
JBoss ON は mod_cluster 設定自体を管理します。クラスター設定には、マルチキャスト(アドバタイズ)、負荷分散、セッションの処理、およびネットワーク設定が含まれます。

32.7.2. ロードバランシング用のマルチキャストの設定

mod_cluster マルチキャストシグナルを使用して、プロキシーサーバーが利用可能であるノードに通知できます。これにより、ノードが自動的にドメインに登録できるようになります。
登録プロセスのサブセットとして、ノードを特定のドメインまたはロードバランサーに転送できます。
注記
マルチキャストはデフォルトで設定されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 6 サーバーを選択します。
  3. mod_cluster service リソースに移動します。
  4. リソースエントリーの Configuration タブをクリックします。
  5. Advertise Options セクションに移動します。
  6. マルチキャストの設定を変更します。
    mod_cluster ノードの特定のロードバランサーを使用するには、Balancer フィールドをロードバランサー名に設定します。任意で、Domain フィールドはロードバランサー自体に設定されたグループのいずれかです。
    重要
    Balancer および Domain 値は、対応する Apache サーバーの設定と一致する必要があります。
  7. ページ上部の Save ボタンをクリックします。

32.7.3. Discovery からの Web コンテキストの除外

デフォルトでは、ノードの Web コンテキストは mod_cluster サービスによって検出および管理されます。Web コンテキストをクラスターに含まれない場合、名前で除外できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 6 サーバーを選択します。
  3. mod_cluster service リソースに移動します。
  4. リソースエントリーの Configuration タブをクリックします。
  5. Web Context Options セクションに移動します。
  6. Excluded Contexts フィールドの設定を解除し、除外するコンテキストの名前を追加します。
    注記
    JBoss EAP の内部コンテキストの一部はデフォルトで除外されます。これは除外リストに保持する必要があります。除外する新しいコンテキストは、既存のリストに追加する必要があります。
  7. ページ上部の Save ボタンをクリックします。

32.7.4. Web コンテキストメトリクスの設定

mod_cluster 異なるタイプのメトリクスを使用して、トラフィックのバランスを最も効率的に判断することができます。これらのメトリクスについては、mod_cluster ドキュメント に記載されています。これらのメトリクスには、アクティブなセッション、要求数、トラフィックが含まれます。
また、カスタムメトリクスを作成してサブシステムに追加することもできます。
これらのメトリクスを JBoss ON の mod_cluster サブシステム設定に追加して監視できます(および既存のメトリクスを削除できます)。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 6 サーバーを選択します。
  3. mod_cluster service リソースに移動します。
  4. リソースエントリーの Operations タブをクリックします。
  5. ドロップダウンメニューから Add (Custom) Metrics 操作を選択します。
  6. メトリック情報を入力します。デフォルトのメトリクスは mod_cluster ドキュメント に記載されています。
  7. ページ下部の Schedule ボタンをクリックします。

32.8. JBoss Enterprise Application Platform 6.2 および Above のパッチ適用

JBoss ON UI(または CLI)は JBoss ON によって管理される JBoss ON および JBoss ON JBoss Enterprise Application Platform 6 プラグインに基づいて、JBoss Enterprise Application Platform 6.2 インスタンスまたは他のレイヤード製品にパッチを適用できます。重要な例外として、このメカニズムを使用して JBoss ON 自体にパッチを適用する ことはできません。パッチは、製品の特定のマイナーバージョン(JBoss Enterprise Application Platform 6.2 など)で利用可能で、個別の更新(ワンオフ)または累積更新として確認できます。JBoss Enterprise Application Platform パッチに関する詳細は、JBoss Enterprise Application Platform 『インストールガイド』を参照してください

32.8.1. パッチ操作

JBoss ON は、使い慣れた deploy、revert、およびpurge 操作を使用して、バンドルサブシステムに JBoss Enterprise Application Platform パッチを適用します。デプロイにより、ユーザーは JBoss Enterprise Application Platform 6 インスタンスのグループにパッチ(1 回限りまたは累積)を適用できます。パッチを元に戻すと、ユーザーは JBoss Enterprise Application Platform 6 サーバーのグループからパッチをロールバックできます。宛先をパージすると、その宛先を介して JBoss Enterprise Application Platform インスタンスのグループに適用されたすべてのパッチがロールバックされます。
注記
エージェントに $EAP/.installation$EAP/.installation/.rhq (エージェントがメタデータを保存する場所)、および EAP ディレクトリーに対する読み取りおよび書き込み権限があることを確認します。これにより、JON エージェントは EAP サーバーにパッチを当てることができます。

32.8.1.1. バンドルおよび宛先

JBoss Enterprise Application Platform 6 パッチは、で説明されている JBoss ON の bundle サブシステムを使用して処理され 「コンテンツバンドルのプロビジョニングの概要」 ます。
宛先は、パッチ操作のターゲットとなるリソースの関連付けです。宛先は、初期デプロイパッチを指定することによって最初 Resource Group に作成されます。同じ宛先への後続のパッチデプロイメントは Destination セクションから作成 され、新しいデプロイメントとして使用しないでください。
重要
予期しない動作を防ぐために、特定の JBoss Enterprise Application Platform インスタンスの JBoss Enterprise Application Platform パッチを 1 つの JBoss Enterprise Application Platform 宛先で作業できます。JBoss ON を使用してパッチを配布する宛先が複数ある場合は、重複しないようにしてください(例: JBoss Enterprise Application Platform サーバーは、これらの宛先がターゲットとする複数のリソースグループの一部ではありません)。パッチを特定の宛先にデプロイしようとし、別の宛先を使用してすでにデプロイされているパッチが検出されると、重複する JBoss Enterprise Application Platform サーバーでパッチデプロイメントが中止されます。
宛先をパージすると、その宛先からリソースグループの所属の 関連付け が削除されます(つまり、宛先がパージされた後に、以前にパージされた宛先によって処理されたサーバーにパッチを配信するのに、別の宛先が使用されます)。
JBoss Enterprise Application Platform インスタンスとの宛先の関連付けを強制的に変更するために(JBoss ON サーバーで宛先が削除されても、削除前にパージされないケースを含む)、新しい 宛先の使用時にバンドルのデプロイメント時に takeOver プロパティーを true に設定できます。これにより、新しい宛先ターゲットであるすべてのサーバーの古い宛先との関連を忘れないように JBoss ON が強制されます。

32.8.1.2. パッチデプロイの実行

パッチは、新規または既存の宛先にデプロイできます。
重要
JBoss ON がパッチデプロイメントを正しく追跡し、パッチを適切に実行するためには、既存の宛先に予定されている後続のパッチが 「既存の宛先へのパッチデプロイの実行」 セクションに従って適用され、新しい宛先として動作しないようにしてください。
注記
JBoss ON は、JBoss Enterprise Application Platform の実行中および停止されたインスタンスの両方にパッチを適用することができます。インスタンスが実行されている場合には、パッチがインストールされますが、インスタンスが再起動されるまで有効になりません。停止したインスタンスの場合、次回のインスタンス起動時にパッチが有効になります。パッチのデプロイメント中に restart プロパティーを使用して、パッチのデプロイメント後にサーバーを自動的に再起動するかどうかを指定できます(デフォルトでは trueに設定されます)。
32.8.1.2.1. パッチを使用したバンドルの作成
  1. Bundles タブをクリックします。
  2. Bundle セクションの New ボタン Bundle Creation Wizard をクリックして起動します。
  3. 必要なパッチをアップロードします。
  4. 設定を更新し、Next ボタンをクリックします。
  5. Next ボタンをクリックします。
  6. Finish ボタンをクリックします。
32.8.1.2.2. 新しい宛先へのパッチデプロイの実行
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Deploy ボタンをクリックして、バンドルのデプロイウィザードを起動します。
    1. 宛先情報を入力し、をクリックし Nextます。
    2. Deployment Bundle Version を選択し、をクリックし Nextます。
    3. Deployment Configuration を選択し、をクリックし Nextます。
      注記
      • この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
      • リソースグループのサーバーにパッチデプロイメントのデフォルトの場所として提供された新しい宛先を設定するには、takeOver オプションをに設定し trueます。
    4. Deployment Information を指定して、をクリックし Nextます。
    5. Finish をクリックし、バンドルを宛先にデプロイします。
32.8.1.2.3. 既存の宛先へのパッチデプロイの実行
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Destinations サブタブをクリックします。
  4. バンドルをデプロイする宛先をクリックします。
  5. Deploy ボタンをクリックします。
  6. デプロイするバンドルバージョンを選択し、をクリックし Nextます。
  7. Deployment Configuration を選択し、をクリックし Nextます。
    注記
    この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
  8. 必要なデプロイメント情報を指定して、をクリックし Nextます。
  9. Finish をクリックし、バンドルを宛先にデプロイします。
注記
JBoss Enterprise Application Platform インスタンスに 1 つのオフパッチを 1 つ以上インストールできますが、累積パッチは 1 つだけです。これは、最後のデプロイメントのみを ライブ として理解するため、JBoss ON UI には反映されません。しかし、JBoss Enterprise Application Platform と JBoss ON ではデプロイメントおよびロールバックロジックと同じです。いずれの場合も、パッチデプロイメントの以前の状態を復元する(JBoss ON で変換)最新のパッチのみをロールバックできます。現在適用されているパッチの実際のセットを表示するには、JBoss ON で JBoss Enterprise Application Platform 6 リソースの Active Patches 特性を確認してください。

32.8.1.3. パッチ変換の実行

パッチを元に戻すと、ユーザーは JBoss ON によって適用されたパッチをロールバックできます。JBoss ON は JBoss Enterprise Application Platform インスタンスに適用されるすべてのパッチを追跡し、適用されたパッチのみを元に戻します。さらに、JBoss ON は適用された最初のパッチのみを返すことがあります。つまり、元に戻す前に JBoss ON は別のパッチを適用する必要があります。JBoss ON によって適用されたすべてのパッチを削除するには、を参照してください 「パッチパージの実行」
重要
JBoss ON では JBoss Enterprise Application Platform の累積パッチに対してパッチ処理を実行できますが、JBoss ON では累積パッチ(およびこれまでのパッチ)が 1 つの単位として扱われます。そのため、累積パッチに対して元に戻すと、JBoss ON は累積パッチ全体を元に戻します。たとえば、ユーザーは Cumulative Patch 01 を JBoss Enterprise Application Platform インスタンスにデプロイし、Cumulative Patch 03(Cumulative Patch 02)を同じ JBoss Enterprise Application Platform インスタンスに適用します。ユーザーが Cumulative Patch 03 を元に戻す場合は、Cumulative Patch 01 に戻すことができます。
パッチを実行するには、以下を行います。
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Summary セクションの Destinations タブをクリックします。
  4. 元に戻す宛先を選択します。
  5. odo をクリックし Revert、をクリックし Yesます。
  6. Next 2 回クリックし、をクリックし Finishます。

32.8.1.4. パッチパージの実行

パージにより、ユーザーは JBoss Enterprise Application Platform インスタンスまたはインスタンスのセットに JBoss ON によってインストールされたすべてのパッチをアンインストールおよび削除できます。パージにより、JBoss Enterprise Application Platform インスタンスまたはインスタンスのセットは、JBoss ON が最初のパッチをインストールする前に見つかったバージョン番号に戻ります。
パージを実行するには、以下を実行します。
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Summary セクションの Destinations タブをクリックします。
  4. パージする宛先を選択します。
  5. odo をクリックし Purge、をクリックし Yesます。

第33章 JBoss EAP 7 の管理

JBoss Enterprise Application Platform 7 はモジュール型で柔軟性があり、環境に応じて設定およびデプロイメントオプションの数は無制限です。
これらの章では、JBoss ON を通じて可能な管理オプションやタスクをすべて説明しません。代わりに、EAP 7 に固有のタスクまたは設定、または EAP 7 の管理に使用する際に特別な考慮が必要なタスクまたは設定を取り上げます。

33.1. JBoss EAP 7 の構造

JBoss EAP 7 の主な機能は、モジュラークラスローディング構造と、単一のコントローラーで設定を一元化するドメインフレームワークです。これら 2 つの機能には、柔軟性という 1 つの大きなアセットがあります。この概念は、小規模で軽量のアプリケーションサーバーから開始し、必要な機能およびサーバーインスタンスのモジュールに追加して、分散したシステム用のサーバーインスタンスを追加するという概念です。
JBoss ON はそのシステムの変更可能性内で機能し、モジュール化された分散リソースがどのように関係しているかを明確にし、管理制御と情報の可視性をさらに高めています。
JBoss ON では JBoss EAP 7 のインストールには階層と構造がありますが、その構造を適用する前に、EAP 7 自体の順番を理解するのに役立ちます。
注記
スタンドアロンサーバーおよびドメインサーバーの JBoss EAP 7 トポロジーは、Wildfly プロジェクトのドキュメント で説明されています。

33.1.1. 「classic」構造: スタンドアロンサーバー

JBoss EAP 7 サーバーのほとんどの機能は、独立したクラスまたは サブシステム を介して実装されます。サーバーが使用するサブシステムとその設定プロパティーまたは設定されたインスタンスは、プロファイル で定義されます。
EAP 6 のスタンドアロンインスタンスは、定義されたサブシステムのコレクションで、通信、ネットワークインターフェース、およびその他の設定を定義するソケットバインディングのセットです。
サーバーインスタンス全体が standalone.xml ファイルに定義されます。そのファイルのほとんどすべてのエントリーは、サーバーの子として識別されます。たとえば、以下のサブシステムエントリーは ee、サーバーの jmx 子リソースを作成します。
<subsystem xmlns="urn:jboss:domain:ee:1.1"/>
<subsystem xmlns="urn:jboss:domain:jmx:1.1">
    <show-model value="true"/>
    <remoting-connector/>
</subsystem>
同様に、ソケットバインディング、ネットワークインターフェース、およびデプロイ済みのコンテンツ(設定ファイルに定義されているコンテンツ)はリソースとして検出されます。
データソースやロギング設定などのサブシステムには複数のインスタンスを定義できます。これらはすべてサブシステムの子リソースとして設定されます。EAP 7 サーバーのモジュールの性質上、サブシステムは正確なサブシステムであるため、JBoss ON の正確な子は、設定ファイルのサブシステムや他の定義により異なります。
全体的には、サブシステムやその他の設定の数により、スタンドアロンサーバーには非常に幅広くフラットなインベントリーツリーがあります。JBoss ON では、スタンドアロンサーバー構造に追加の階層が設定されていません。サーバーの設定方法を反映してい standalone.xmlます。

図33.1 スタンドアロンサーバー設定

description
スタンドアロンサーバーの管理および操作は自己完結型です。 スタンドアロンサーバーのすべての子ノードは、設定とそのランタイム環境(監視、アラート、および操作)を同じ場所に組み合わせます。データソースの設定を変更するには、データソースエントリーを直接編集します。すべてのスタンドアロンサーバーは、同じクラスターまたは同じマシンであっても、他のサーバーとは別々に管理されます。

33.1.2. 設定とリアルタイム操作の分離: ドメイン

ドメインの構造は、よりモジュール型設計の観点から完全に異なります。
ドメインは、アプリケーションサーバーをサーバー設定とランタイム操作という 2 つの概念的な方法で分割します。
設定はドメインコントローラーに一元化されます。ドメインコントローラーは、プロファイルおよびサブシステムの設定、JVM の設定、インターフェース、およびその他の設定を単一の場所で定義します。
アプリケーションサーバーの機能は、複数のマシンにインストールできる 管理 サーバーによって実行されます。これらの管理サーバーは、独自の設定を定義しません(例外は除く)。ドメインからのプロファイル構造を受け入れ、ドメインを介してデプロイされた web アプリケーションを提供します。
組織ドメインとサーバー グループ と呼ばれる管理サーバーのセカンダリーレベルがあります。サーバーグループはドメイン設定の一部として定義されます。管理対象サーバー用に環境を作成します。それらは設定ノードです。ドメインには複数のプロファイル、JVM 定義、Web アプリケーションを含めることができます。すべての設定の中央リポジトリーです。特定の設定とコンテンツのみがサーバーグループに割り当てられ、その特定の設定が管理対象サーバーに適用されます。

図33.2 簡易ドメイン構造

簡易ドメイン構造
ドメイン設定は domain.xml ファイルに定義されます。これにより、設定されたプロファイルおよびサブシステム、サーバーグループ、ソケットバインディング設定、システムプロパティー、デプロイメント、およびその他の設定がすべて一覧表示されます。スタンドアロンサーバーと同様に、ほぼすべてのエントリーが検出され、リソースとしてインベントリーに追加されます。たとえば、これにより、子デプロイメントリソースとサーバーグループの子 JVM リソースを持つサーバーグループリソースが作成されます。

例33.1 Server Group domain.xml エントリー

        <server-group name="main-server-group" profile="full">
            <jvm name="default">
                <heap size="1303m" max-size="1303m"/>
                <permgen max-size="256m"/>
            </jvm>
            <socket-binding-group ref="full-sockets"/>
            <deployments>
                <deployment name="sample2.war" runtime-name="sample2.war"/>
            </deployments>
	</server-group>
操作を実行するインスタンスは、host.xml ファイルで識別されます。これらの管理サーバーは実質的には独自の設定を持ちません。ドメインで使用する元のサーバーグループ設定に戻るだけです。
    <servers>
        <server name="server-one" group="main-server-group"/>
        <server name="server-two" group="other-server-group">
            <!-- server-two avoids port conflicts by incrementing the ports in
                 the default socket-group declared in the server-group -->
            <socket-bindings port-offset="150"/>
        </server>
    </servers>
ドメイン(プロファイルとそのサーバーグループ)は、全体の設定を定義します。管理されたサーバーは、その設定下のワーカーです。これは、設定と操作(特に個々のメンバーではなく、ドメインの機能全体)を EAP 7 管理コンソールに反映します。Profile および Servers エリアは、現在の統計とデプロイされた Web アプリケーションを Runtime 表示し、ドメイン設定を管理します。フォーカスは常にドメイン設定とドメイン情報に重点が置かれます。

図33.3 EAP 7 コンソール

EAP 7 コンソール
JBoss ON でドメインリソースを管理することは、設定の管理が情報を管理するよりも少なくなります。JBoss ON インベントリー構造の強度の 1 つは、ドメインのコンポーネントを非常に明確に公開し、それらのリソース間の関係を説明するのに役立ちます。

図33.4 ドメインリソース

ドメインリソース
たとえば、管理対象サーバーのエントリーは、そのサーバーグループのプロファイルに定義されているすべてのサブシステムを一覧表示し、ホストコントローラー定義を一覧表示し、それにデプロイされた管理 web アプリケーションを一覧表示します(サーバーグループを介して)。これにより、1 つのワーカーインスタンスに適用される設定情報がすべて統合され、管理されたサーバーの監視情報がより重要になります。
JBoss ON インベントリーには、ドメイン関係を維持するため、実用性が高くなります。ドメインは単一のオーバーアーキテクチャーエンティティーですが、ドメインのコンポーネントはこれらのプラットフォームの複数のプラットフォームおよびリソースにまたがることができます。ドメインコントローラーは、プラットフォームに関係なく、すべてのドメインリソースの親リソースとみなされます。これは、でヒントとなり 図33.5「JBoss ON インベントリーのドメインコンポーネント」 ます。ドメインコントローラーと 2 台の管理サーバーがプラットフォーム 2 にある場合でも、ドメインコントローラーは 1 つです。ホストコントローラーと管理リソースは、ドメインコントローラーと管理リソースがドメインリソースの子として表示されます(プラットフォーム 1 上)。

図33.5 JBoss ON インベントリーのドメインコンポーネント

JBoss ON インベントリーのドメインコンポーネント

33.1.3. JBoss ON の EAP 7 リソース

domain.xmlhost.xmlまたはの EAP 7 のすべての設定エリア standalone.xml はリソースタイプとして解釈されます。EAP 7 では設定コンポーネントと運用コンポーネントの違いがあるため、JBoss ON の EAP 7 リソースタイプは異なることを行います。また、リソースによっては設定を定義し、監視、アラート、および操作に使用されます。
ドメインでは、ドメインのプロファイル、ソケットバインディング、およびネットワークインターフェースはすべて設定エントリーです。そのため、JBoss ON では、対応するリソースタイプによって設定が定義されます。
ドメインでは、管理対象サーバーは機能するインスタンスです。これらのリソースはアクティブであるため、JBoss ON では管理対象サーバーリソースは操作を実行し、メトリクスを監視し、アラートをトリガーできます。
設定リソースと機能の運用リソースとの間に重複はありません。たとえば、プロファイル下のデータソースリソースには設定がありますが、監視またはアラートはありません。管理対象サーバーのデータソースはモニタリングメトリクスを収集し、アラートを定義し、操作を実行します。これらのリソースは関連しています。管理対象サーバーデータソースリソースはプロファイルデータソースの設定を参照しますが、それらは異なります。
スタンドアロンサーバーでは、同じリソースで設定および管理が有効になります。スタンドアロンサーバーは基本的に、プロファイルリソース(設定)と管理対象サーバーリソース(management)の組み合わせです。スタンドアロンサーバーのデータソースリソース。その後、同じリソースの設定と監視、アラート、および操作の両方を保持します。

33.1.4. JBoss ON を使用した EAP 7 リソースの管理の目的

JBoss ON UI は EAP 7 コンソールとパリティーを維持するため、ほとんどの設定を編集し、子エントリーの作成、およびコンテンツのデプロイに EAP 7 管理コンソールと同じように使用できます。
しかし、JBoss ON 管理の目的は、別の Web UI を使用する訳ではありません。JBoss ON は、ドメイン内のリソースについてより大きな観点を維持します。このインフラストラクチャー全体の観点では、ドメイン内のリソース、より大きな IT 構造、さらには現在の設定変更を除いて、独自の履歴も明確になります。
JBoss ON のスタンドアロンサーバーおよびドメインは、管理者が利用できる情報を強調表示するように構成されています。
  • 保存した履歴データ、リソース固有の運用ベースライン、および代替の表示タイプを含む、リソースの追加の監視メトリック。
  • 履歴の設定および接続設定
  • JBoss ON で子を追加または削除した場合のインベントリー変更履歴
  • 制御されたパッケージ更新用のパッケージバージョン管理およびリポジトリー
  • プラットフォーム、Apache、Undertow Web サーバーなどの基盤のリソースおよび関連するリソースの設定、監視、アラート、およびアラート mod_cluster

33.2. JBoss EAP 6 リソースプラグインの使用

EAP 6 プラグインおよび EAP 7 プラグインは、JBoss ON によって 2 つのプラグインとして扱われます。EAP 6 プラグインは EAP 7 リソースを無視し、EAP 7 プラグインと同様に EAP 6 リソースを無視します。
EAP 6 プラグインは、EAP 7 リソースを管理する EAP 7 プラグインが正常に実行されるように完全に更新する必要があります。

33.3. JBoss EAP 7 インスタンスの設定

33.3.1. EAP 7 インスタンスを検出するエージェントの設定

に記載されているように 4章エージェントおよびリソースのシステムユーザーとの対話、エージェントを実行するシステムユーザーは、エージェントが特定のリソースタイプを管理する方法に直接影響します。EAP インスタンスの場合、エージェントのシステムユーザーに EAP リソースを管理できるように適切なパーミッションが必要です。
  • エージェントには、ファイルの読み取り権限が必要です。さらに、run.jar ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になり run.jar ます。
  • RPM から JBoss EAP 7 インスタンスがインストールされている場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。

33.3.2. サーバーおよびプロファイルの設定

33.3.2.1. スタンドアロンサーバーおよびドメインの相違点

「JBoss EAP 7 の構造」 スタンドアロンサーバーとドメイン構造の相違点がいくつかあります。設定に重要な違いは、スタンドアロンサーバーでは、すべての設定が子エントリーで直接実行される点です。ドメインを使用すると設定が分割され、ほぼすべての設定をドメイン管理プロファイルとサーバーグループで一元管理されます。
これは EAP 7 管理コンソールに反映されます。ほとんどすべての設定は Profiles エリアにあります。ドメインプロファイルは、個別のサブシステム設定、システムプロパティー、グローバル JVM 設定、およびサーバーグループの設定を定義します。
この Servers エリアは、管理対象サーバーに設定されている設定量(主にローカル JVM 定義とサーバーの停止や起動など)をカバーします。
JBoss ON では、domain(プロファイル)とそれらのサブシステム、ソケットバインディング、サーバーグループの主な設定エリアは個別のリソースタイプとして分類されます。この設定は、テンプレートと同様に、管理対象サーバー(サーバーグループ経由)に適用されます。
常に設定元となるリソースを編集します。ほとんどの設定では、ドメインコントローラーの関連する子リソースを編集することを意味します。
  • サブシステム設定はドメインコントローラーの autogroup 内の Profiles プロファイルリソースにあります。
  • JVM 定義は、ドメインコントローラー(ドメイン全体のデフォルト)、サーバーグループ(グループ全体の設定)、または管理対象サーバー(ローカル設定)で設定されます。
  • ネットワークインターフェースはドメインコントローラーで設定されます。
  • ソケットバインディング自体は、ドメインコントローラーの autogroup の下にあるエントリーでドメインコントローラー設定の一部として SocketBindings 設定されます。各サーバーグループと管理対象サーバーにはオフセットがあり、ソケットバインディング値に追加されます。これは、管理対象ドメインで一意のポート番号を提供するために使用される番号です。これらのオフセットはサーバーグループと管理対象サーバーの接続設定で設定されます。
  • システムプロパティーは、ほぼすべてのサーバーリソース(ドメインコントローラー、ホストコントローラー、サーバーグループ、管理対象サーバー)で設定できます。
設定(JVM 定義およびシステムプロパティー)は、異なるレベル(domain、サーバーグループ、または管理対象サーバー)で定義できます。この場合、設定は cascade で機能し、最も低いレベルの設定が優先されます。そのため、サーバーグループの設定はドメイン設定と管理対象サーバー設定は、サーバーグループ設定に優先します。これらの設定 には、ドメイン階層の適切なレベルで設定を 行ってください。ドメイン全体に設定を適用するには、関連するドメインエントリーを編集します。サーバーグループまたはサーバーレベルで設定を設定するには、そのエントリーレベルで設定を作成または編集します。

33.3.2.2. EAP 7 で必要な管理インターフェース

JBoss ON の EAP 7 プラグインは、EAP 7 ドメインコントローラーのデフォルト HTTP 管理インターフェースに接続します。この管理インターフェースは、EAP 7 ドメインインスタンスの管理および監視に使用されます。
HTTP 管理インターフェースが削除または無効になっている場合、エージェント(EAP 7 プラグインを使用)は EAP 7 ドメインインスタンスに接続できなくなります。そのため、EAP 7 ドメインリソースを管理または監視できず、リソースが実行していても利用できなくなります。
必要な場合は、EAP 7 CLI を使用して JBoss ON エージェントが接続する HTTP 管理インターフェースを有効にします。
/host=instanceName/core-service=management/management-interface=http-interface:add(interface=http,port="\${jboss.management.http.port:9990}",security-realm=ManagementRealm
JBoss ON JBoss Enterprise Application Platform 7 プラグインは、HTTPS(SSL)を使用した管理インターフェースへの接続もサポートします。JBoss Enterprise Application Platform 7 管理コンソールに対して HTTPS インターフェースを使用するよう JBoss ON を設定する方法は、を参照してください 「JBoss Enterprise Application Platform 7 サーバーのセキュア接続設定の変更」。HTTPS を使用するよう JBoss Enterprise Application Platform 7 管理コンソールを設定する方法は、access.redhat.comで利用可能な EAP 7 ドキュメントを参照してください。

33.3.2.3. JBoss ON の設定機能

JBoss ON は JBoss ON のリソースに加えられた設定変更をすべて追跡します(JBoss ON UI または CLI を使用)。JBoss ON 上の値は、設定変更を行うだけでなく、設定を管理します。JBoss ON の他の管理領域と同様に、設定は履歴を維持します。これにより、管理者は変更のコンテキストおよびパフォーマンスやメンテナンスへの影響で設定を管理することができます。
  • バージョン間の diffs を含む変更履歴の表示
  • ボタンをクリックして、以前のバージョンへの変更をロールバックします。
  • 監査証跡の一部として変更を行ったユーザーを追跡
  • アラートを使用して、設定変更の管理者に通知します。
  • ドリフト監視を定義して、定義したベースラインに対して設定の変更を追跡し、予期しない設定変更を制御する
各リソースについて、JBoss ON は一般的なリソースプロパティー(タブ内)と、エージェントがリソースへの接続に使用する接続プロパティー( Configuration タブ内の)の 2 つのタイプの設定を除外します Inventory。いずれのタイプの設定にも設定履歴があり、以前のバージョンに戻すことができ、アラートとモニタリングに使用できます。現実的には、いずれかの設定タイプを編集すると、リソース上の同じ設定ファイルを編集できます。これらの 2 つの設定エリアは JBoss ON に分離され、リソースの動作に影響する設定とリソースへの接続に影響する設定の区別に役立ちます。
設定や接続設定を編集できない場合でも、JBoss ON では、管理者はそのリソースに適用されている設定を表示することができます。これは、プロファイルリソースで定義された設定を使用する管理サーバーに特に便利です。

33.3.3. Setup CLI 操作を使用した JBoss ON と EAP 7 間の SSL 認証

EAP 7 サーバーがセキュア化された場合(SSL 認証が必要な場合)、Setup CLI 操作を使用して JBoss ON EAP プラグインから認証設定を複製できます。これにより、JBoss 7 の JBoss CLI(jboss-cli.sh または jboss-cli.bat)への JBoss ON GUI アクセスが可能になります。この操作は JBoss ON と EAP 間 Execute CLI script<EAP_install_directory>/bin/jboss-cli.xml 公開鍵を更新し、JBoss ON GUI からの Execute CLI commands /からの操作を可能にします。
注記
この操作は 任意です。jboss-cli は、EAP 7 のドキュメントを使用して手動で設定できます。「レガシーコア管理 認証のある管理インターフェースに対して双方向 SSL/TLS を設定 」を参照してください。
Setup CLI 操作を使用するには、JBoss ON エージェントには EAP ファイルおよびディレクトリーへの読み取りおよび書き込み権限が必要です。
これ Setup CLI は、JBoss ON 3.3 向けに Enterprise Application Platform(EAP)Management Plug-in Pack Update-03 によって導入されました。

表33.1 Setup CLI 操作から利用できるプロパティー

propertydescription
デフォルトコントローラーJBoss ON コントローラーホストおよびポートを EAP 7 の JBoss CLI のデフォルトとして設定します。
securityEAP 7 にセキュアな管理インターフェースがある場合、このオプションは Store Password Method を基にして JBoss ON と EAP との間で認証を設定します。これにより、JBoss ON は EAP 7 JBoss CLI を実行できるようになります。
ストアパスワードメソッドセキュリティーを設定する際に、パスワードを jboss-cli.xml に保存するメソッドを設定します。
  • plain: プレーンテキストとして保存された EAP サーバープラグイン設定のパスワードを使用します。これはデフォルトのオプションです。
  • vault: EAP パスワード vault で難読化されたサーバー設定ファイル(例: standalone.xml)からパスワードを使用します。パスワード vault もサーバー設定ファイルに定義する必要があります。パスワード vault が見つからない場合、この操作は失敗します。

手順33.1 Setup CLI 操作の使用

  1. JBoss ON CLI で Inventory タブをクリックします。
  2. Resources メニューからをクリックし Servers、設定する EAP サーバーを選択します。
  3. EAP サーバーリソースページから、Operations タブをクリックします。
  4. New をクリックし、新しい操作をスケジュールします。
  5. Operation ドロップダウンリストから、以下に示すように Setup CLIを選択します。

    図33.6 Setup CLI 操作の例

    Setup CLI 操作の例
  6. 必要なプロパティーを変更するには、Unset? チェックボックスをクリアし、該当するをクリックし Valueます。
  7. Schedule をクリックし、操作を保存します。このページは Operations History タブにリダイレクトします。
  8. Setup CLI 操作が実行され、ステータスが success を示す場合、以下のように Setup CLI 操作の Date Submitted エントリーをクリックして、操作の結果を表示し、変更が正常に行われたことを確認し ます

    図33.7 Setup CLI 操作の結果の例

    Setup CLI 操作の結果の例
EAP 7 JBoss CLI の設定に関する詳細は、『 Red Hat JBoss Enterprise Application Platform 7 管理 CLI ガイド』を参照してください

33.3.4. 管理ユーザーの作成

JBoss ON エージェントは管理ユーザーとして EAP 7 サーバーに接続します。これにより、JBoss ON は設定の変更やリソースの開始および停止などのタスクを実行できます。
JBoss ON が EAP 7 インスタンスを管理できるようにするには、管理ユーザーが必要です。
管理ユーザーを作成する方法は複数あります。
  • LDAP ディレクトリーまたは外部データストアの使用これは EAP 7 の最もセキュアな実装であるため、推奨されます。
  • JBoss ON を使用して管理ユーザーを作成します。
  • EAP add-user スクリプトでローカル EAP アカウントを作成する。
ユーザー名とパスワードが EAP 7 リソース接続プロパティーに設定されている限り、セキュリティー実装とローカル EAP 7 インスタンスの要件に応じて、これらはすべて有効です。

33.3.4.1. 管理ユーザーの認証情報の設定

JBoss ON では、EAP 7 サーバーに接続するためのユーザー名とパスワードが必要です。リソースの操作、アプリケーションのデプロイメント、設定の変更、およびその他の保守を行うのに適切な権限があれば、EAP 7 のユーザーをすべて使用できます。
JBoss ON は EAP のユーザー設定について認識せず、認証情報のみを EAP に送信し、EAP サーバーが認証リクエストを処理します。そのため、EAP が LDAP ディレクトリーをユーザーストアまたはその他のセキュリティーレルムとして使用するよう設定されていても、JBoss ON はその情報は必要ありません。ユーザー名とパスワードのみが必要です。
管理ユーザーは EAP リソースの接続プロパティーで定義されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
  4. Inventory タブを開きます。
  5. Connection Settings サブタブを選択します。
  6. EAP 7 で作成した管理ユーザーのユーザー名とパスワードを入力します。
  7. ページ上部の Save ボタンをクリックします。

33.3.4.2. JBoss ON での管理ユーザーの作成

エージェントが EAP 7 インスタンスへの接続に使用できるローカル EAP ユーザーを作成および設定するリソース操作があります。これは、ユーザー用に事前定義された設定と JBoss ON の追加設定が含まれる EAP 7 add-user ユーティリティーのラッパーです。
この操作は、EAP 7 サーバー ManagementRealmrhqadmin ユーザーを作成します。これはデフォルトのセキュリティーレルムです。実稼働環境では、異なる管理レルムを使用することが強く推奨されます。
ユーザーは セキュアな 管理レルムに作成されます。EAP 7 サーバーがセキュアモードではない 場合、JBoss ON が管理レルムに接続できないため、インストール RHQ ユーザー 操作は失敗します。EAP 7 サーバーは、デフォルトでセキュア化されます。
注記
この操作は、1 つのステップで EAP 7 と JBoss ON の両方の設定を設定するので便利ですが、セキュリティー制限があります。 これは、デフォルトの管理レルム(ManagementRealm)にのみユーザーを作成するためです。他のセキュリティーレルム(実稼働環境に推奨)を使用する場合は、add-user.sh スクリプトなどのこの操作は使用できません。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
  4. Operations タブを開きます。
  5. ページ下部の New ボタンをクリックします。
  6. ドロップダウンメニューから Install RHQ User オプションを選択します。
  7. Schedule ボタンをクリックします。

33.3.4.3. EAP 7 での管理ユーザーの作成

EAP 7 add-user.sh ユーティリティーは、エージェントが EAP 7 インスタンスへの接続に使用できるローカル EAP ユーザーを作成し、設定します。EAP でユーザーを作成したら、そのユーザーの認証情報を JBoss ON のリソースの接続プロパティー設定に提供する必要があります。
注記
add-user.sh スクリプトによるユーザーの作成には、セキュリティーに関する制限があります。デフォルトの管理レルム(ManagementRealm)にユーザー のみを作成します。実稼働環境に推奨される他のセキュリティーレルムが使用される場合、このスクリプトを使用して JBoss ON エージェントのユーザーを作成することはできません。
  1. add-user ユーティリティーを実行してユーザーを作成します。
    [root@server ~]# cd /opt/jboss-eap-7.0
    
    [root@server bin]# ./add-user.sh
    What type of user do you wish to add?
     a) Management User (mgmt-users.properties)
     b) Application User (application-users.properties)
    (a): a
    
    Enter the details of the new user to add.
    Realm (ManagementRealm) :
    Username : jonadmin
    Password :
    Re-enter Password :
    About to add user 'jonadmin' for realm 'ManagementRealm'
    Is this correct yes/no? yes
  2. JBoss ON の EAP 7 サーバーリソースの接続設定でそのユーザーを設定します。
    1. トップメニューの Inventory タブをクリックします。
    2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 7 サーバーを選択します。
    3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
    4. Inventory タブを開きます。
    5. Connection Settings サブタブを選択します。
    6. EAP 7 で作成した管理ユーザーのユーザー名とパスワードを入力します。
    7. ページ上部の Save ボタンをクリックします。

33.3.5. EAP 7 リソースの動的グループの作成

管理(特に設定の監視や編集の場合)では、互換性のあるグループで関連リソースをグループ化すると非常に便利です。互換性のあるグループを使用すると、管理者はすべてのグループメンバーのアラート定義の設定、メトリクス設定の変更、設定の変更を同時に行うことができます。
Dynagroups は検索式を使用してグループメンバーを検索し、ユーザー定義の基準に基づいてグループを作成します。これにより、JBoss ON インベントリーの変更時にメンバーが追加され、自動的にドロップされるため、グループメンバーシップは常に最新の状態になります。
Dynagroup 構文の詳細は、を参照してください 「動的グループ構文」。この特定の dynagroup 式は、まずリソースプラグイン、カテゴリー(サーバー)、および親を基にしてリソースを検索します。次に、製品のタイプと名前に基づいてグループを作成します。
これにより、Ansible-P、Data Grid(JDG)、ホストコントローラーおよびスタンドアロンサーバーなど、JBoss EAP 7 に関連付けられたすべての JBoss 製品に個別の互換性のあるグループが作成されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側の Groups エリアで、Dynagroup Definitions リンクをクリックします。
  3. EAP 7 のサーバータイプごとに互換性のあるグループを作成する式を入力します。
    resource.type.plugin = EAP7
    resource.type.category = SERVER
    resource.parent.type.category = PLATFORM
    groupby resource.pluginConfiguration[productType]
    groupby resource.type.name
  4. ページの中央にある Save ボタンをクリックします。

33.3.6. 起動スクリプト引数、環境変数、および JAVA_OPTS の設定

33.3.6.1. スクリプト検出と設定の開始

JBoss EAP 7 サーバー(ドメインコントローラーまたはスタンドアロンサーバー)の検出の一環として、JBoss ON はサーバーが実行されている環境の検出を試みます。特に、検出プロセスはランタイム環境の特定および再作成を試行します。
  • 検出プロセスは、カスタム開始スクリプトを含む、使用される開始スクリプトを特定または試行します。
  • Discovery は、開始スクリプトが機能するために必要な run.conf ファイルまたは親プロセスに設定された環境変数のサブセットを検出します。
    注記
    検出プロセスで一部の環境変数が検出されますが 、検出スキャンは JAVA_OPTS 値を検出しません。
    開始スクリプトの接続プロパティーは意図的に JAVA_OPTS 値のために run.conf ファイルに移されます。
  • 検出は、開始スクリプト自体で渡された引数の検出を試みます。
  • Discovery は、スクリプトが実行しているユーザーを検出し、start スクリプトで使用する 接頭辞 コマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。
検出された設定は、EAP 7 リソースの Start Script Environment Variables および Start Script Arguments 接続設定に保存されます。
検出スキャンが一部のスクリプト設定を検出できない場合(エージェントは EAP 7 サーバーとは異なるユーザーとして実行され、親プロセスの読み取りができない場合)、正常に失敗します。可能な情報をすべて収集し、空の値を無視します。
注記
Start Script Environment Variables および Start Script Arguments 接続設定は、リソースの初回検出時に 1 回だけ検出されます。その後、接続設定は接続設定で変更できますが、ローカルシステムで行った変更は検出されません。たとえば、サーバーが特定の値(など -XX:PermSize=256M)で検出されると、サーバーが別の設定値で後で再起動すると、引数の値は更新されません。
スクリプト引数と環境変数は、開始スクリプトの実行時にエージェントによって使用される唯一の変数です。これらの引数および環境変数は、他の設定や親プロセスに追加されません。EAP 7 接続設定の開始スクリプト設定は決定論的です。

33.3.6.2. スクリプト引数およびドリフト監視の開始

JBoss ON はディレクトリーや特定のファイルを監視して、設定の ドリフト を確認することができます。詳細は、「 リソース設定の管理」の章 「設定項目の制御」 およびドリフトの章を参照してください。
管理者は重要なリソースを管理するのに、ドリフト監視は重要ですが、いくつかの設定で必要になるか、または有益である場合もあります。start スクリプト引数を使用すると、ドリフトアラートをトリガー せず に EAP 7 サーバーの定義設定をオーバーライドできます。
起動スクリプトのオプションはすべて接続設定であるため、すべての変更は変更履歴に記録され、にあるように簡単に表示および元に戻すことができ 「設定変更の追跡および取り消し」 ます。これにより、システムプロパティーと Java 設定が追跡および修復されます。

例33.2 ドリフト定義を自動化せずにシステムプロパティー

Tim the IT Guy は、すべての実稼働 EAP 7 サーバーが環境を使用する特定の設定セットを作成します。その後、テンプレートに設定が加わるモニタリングおよび関連付けまたはピン用にドリフト定義テンプレートを作成します。
テンプレートのドリフトを使用する EAP 7 サーバーは、これらの構成設定に準拠する必要があります。Tim the IT Guy は、実稼働サーバーが特定の設定からドリフトした場合に通知するアラートを作成します。これは、Example Co. の実稼働アプリケーションサーバーに対する重要な安全対策です。
ただし、実稼働サーバーでは、動作中のハードウェアやその他のアプリケーションが若干異なるため、効果的に実行するために異なるヒープサイズが必要になります。
TI Guy が別のヒープサイズを使用するようにシステムプロパティーを追加する場合、一定のドリフトアラートを受信するか、サーバー側の自動スクリプトを実行してドリフト設定を修正すると、編集した設定が上書きされる可能性があります。
開始スクリプトで異なるヒープ設定を設定すると、Tim は設定ファイルを編集せずにそのシステムの正しい設定を適用できるため、アラート可能な設定のドリフトはありません。

33.3.6.3. 起動スクリプト設定の変更

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
  4. Inventory タブを開き、Connection Settings サブタブを選択します。
  5. Operations エリアを展開します。
  6. 開始スクリプトの設定を変更または追加します。これらは、EAP 7 サーバーで起動または再起動の操作を実行する際に JBoss ON エージェントが使用するスクリプトおよび設定です。
    • domain.sh または以外のカスタムの開始スクリプトを使用するには standalone.sh、パスとスクリプト名を入力します。
    • 必要に応じて、開始スクリプトの実行時にスクリプトで使用する接頭辞を入力します。
      起動スクリプトが検出されると、エージェントはスクリプトが実行されているユーザーを判断しようとし、start スクリプトで使用するプレフィックスコマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。
      さらに、JBoss ON は nohup コマンドをプレフィックスとして割り当て、JBoss Enterprise Application Platform がエージェントによって開始され、エージェントプロセスが終了すると、JBoss Enterprise Application Platform プロセスが実行を継続します。
    • 各行に 1 つずつ環境変数を設定します。
    • スクリプト引数を設定します(行ごとに 1 つ)。通常の JAVA_OPTS の場合、これらの引数は通常 -X -D、またはです -P。便利な -XX 引数の一部は、Sun の JVM オプションのドキュメントに記載されています。EAP 7 の便利なシステムプロパティーの一部は、WildFly 10 プロジェクトのドキュメント に記載されています。
      EAP 7 のデフォルト起動スクリプトは - 形式の run.shスクリプトを使用するため、引数はその形式を使用します。カスタムスクリプトは、異なる引数またはオプションを使用できます。
  7. ページ上部の Save ボタンをクリックします。

33.3.6.4. スタンドアロンモードでの JVM ヒープ引数の変更

重要
このセクションでは、スタンドアロンモードおよび標準設定ファイル(standalone.conf または standalone.bat)のみを使用する場合に JVM 引数を更新する方法を説明します。ドメインモードで JVM Arguements を更新する場合は、を参照してください 「JVM 定義の変更」
JBoss ON JBoss Enterprise Application Platform 7 プラグインを使用すると、スタンドアロンモードで実行される JBoss Enterprise Application Platform 7 サーバーに JVM Heap 引数を編集および永続化できるようになりました。この機能により、JBoss ON の JAVA_OPTS 設定は JBoss ON の外部で再起動できます。ここで使用する値は、設定ファイル(standalone.conf または standalone.bat)に永続化されます(例: -Xms512M -Xmx1024M)。設定ファイルに加えられた変更を削除するには、「Unset?」チェックボックスを使用する必要があります。これらの変更を有効にするには、サーバーを再起動する必要があります。
重要
この値は、ファイルの最後で永続化される standalone.confstandalone.bat (OS によって異なります)。
このプロパティーを設定した後に、設定ファイルでこの値を更新しないでください。この値は、JBoss ON UI を使用してのみ変更する必要があります。
この機能にアクセスするには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level Imports の Resources メニューテーブルを選択し、右側の表から該当する EAP 7 スタンドアロンサーバーをクリックします。
  3. JBoss Enterprise Application Platform Server の詳細で、Inventory タブをクリックします。
  4. Connection Settings サブタブをクリックします。
  5. テーブルの Operations セクションの Additional JAVA_OPTS 行までスクロールします。
  6. 引数を追加するには、「Unset?」チェックボックスの選択を解除し、テキストボックスに引数を追加します。
    注記
    "Unset" チェックボックスは、設定が JBoss ON Server から使用されているかどうかのみ決定します。「未設定」チェックが解除されると、テキストボックスの値が使用されます。"Unset" がチェックされると、テキストボックスの値は使用されません。「 Unset?」チェックを実行しても、設定ファイルが JAVA_OPTS を設定しないことを意味します。これは単に値が JBoss ON を介して設定されていないことを意味します。
  7. 「 Save」をクリックします。
  8. この更新を反映するには、JBoss Enterprise Application Platform 7 サーバーを再起動する必要があります。
この値の設定を解除するには、「Unset?」チェックボックスを有効にして「Save」をクリックします。この更新を有効にするには、JBoss Enterprise Application Platform 7 サーバーを再起動する必要があります。
注記
この値の設定を解除すると、設定ファイル(standalone.conf または standalone.bat)から JBoss ON によって追加された値が削除されます。このファイルにすでに存在するその他の設定はすべて影響を受けません。

33.3.7. ポート番号の変更

33.3.7.1. ソケットバインディングポートの変更

ソケットバインディングリソースは、利用可能なポート(HTTP、AJP、HTTPS など)とポート番号を定義します。ソケットバインディング設定は、ソケットのマルチキャストポート番号を設定することもできます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで SocketBindingsGroup 互換性のあるグループを選択し、編集するソケットバインディングを選択します。
  4. Configuration タブを開きます。
  5. 鉛筆アイコンをクリックして既存のソケット定義を編集するか、プラス記号(+)をクリックして新しいソケット定義を作成します。
  6. 1025 から 65535 までの利用可能なポートに Port 番号を変更します。Linux では、利用可能なポート番号はを使用して決定でき iptablesます。
    オプションで、ソケットのマルチキャスト設定を行います。同じシステムまたは同じクラスターに複数の JBoss サーバーインスタンスがある場合、マルチキャストはクラスター通信用に設定されます。
  7. ページ上部の Save ボタンをクリックします。

33.3.7.2. ドメインのサーバーグループのポートオフセットの変更

ポートオフセットは、ソケットバインディンググループの各ポート番号に追加される番号で、サーバーインスタンスによって使用される実際のポート番号を作成します。これにより、同じソケットバインディング設定を使用しながら、管理サーバーのドメイン全体で一意のポート番号を指定するか、またはクラスター内のスタンドアロンサーバーに一意のポートを持たせることができます。
たとえば、ソケットバインディング HTTP ポートが 8080 で、管理サーバーのオフセットが 110 の場合、管理対象サーバーによって使用される実際のポートは 8190(8080 + 110)になります。サーバーグループはオフセットも定義でき、オフセットは加算されます。そのため、サーバーグループに 15 のオフセットがあり、管理サーバーのオフセットが 110 の場合、サーバーが使用するポート番号は 8205(8080 + 15 + 110)になります。
注記
管理対象サーバーのオフセットは、host.xml ファイルのエントリーで定義されます。これは、JBoss ON で管理サーバーの作成時に設定できますが、後で編集することはできません。
サーバーグループによって使用されるポートオフセットを編集できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで Server Groups ノードを展開し、サーバーグループを選択します。
  4. サーバーグループの Configuration タブを開きます。
  5. Port Offset フィールドにオフセットの新しい値を入力します。
  6. ページ Save 上部をクリックします。
スタンドアロンサーバーのオフセットを変更するには、にあるように接続設定を編集し 「EAP 6 サーバーの一般プロパティーの変更」 ます。

33.3.8. ネットワークインターフェースの編集

ネットワークインターフェースがそのインターフェースのソケットと通信する際に、特定の IP アドレスまたは IP アドレスのタイプを使用するように設定できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで Server Configuration で Network Interfaces グループを選択し、インターフェース(management、public、または unsecure)を選択します。
  4. Configuration タブを開きます。
  5. インターフェースで使用する特定の IP アドレスを設定するか、アドレスの使用を 許可 します。
    UI では、使用するプロパティーが任意で、この画面で選択が行われていることを強制しません。ただし、ネットワークインターフェースが適切に機能するには、以下のいずれかのオプションを設定する必要があります。
  6. ページ上部の Save ボタンをクリックします。

33.3.9. システムプロパティーの設定

サーバーおよび特にサブシステム(統合サービス)では、システムプロパティーとして追加の設定プロパティーを追加できます。システムプロパティーは単純な属性と値のペアで、任意のものです。利用可能なシステムプロパティーは、編集するリソースによって異なります。
プロファイルやサブシステム、エクステンション、サーバーグループ、およびその他のドメインコンポーネントを編集すると、システムプロパティーが domain.xml ファイルのコンポーネントのエントリーに追加されます。ホストコントローラーまたは管理対象サーバーを編集すると、プロパティーが host.xml ファイルのサーバーのエントリーに追加されます。
注記
システムプロパティーは、ドメインの他の設定要素と同様に、cascade で機能します。システムプロパティーがサーバーグループに設定されていると、グループのすべてのメンバーに適用されます。管理対象サーバーで設定されている場合は、そのサーバーにのみ適用されます。
ドメインの適切なレベルでエントリーを編集して、設定が適切に適用されるようにします。
システムプロパティーはデフォルト設定を設定します。これは、-D または -P 引数で start スクリプトで上書きできます。
注記
ドリフト監視が設定されている場合は、システムプロパティーを追加または編集すると、ドリフトアラートがトリガーされる可能性があります。を参照してください 「設定項目の制御」
利用可能なシステムプロパティーに関する情報は、プロジェクトのドキュメントを確認してください。
システムプロパティーを設定に追加するには、以下を行います。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Configuration タブを開きます。
  5. Properties セクションを展開します。
  6. Paths リストの下部にあるプラス(+)アイコンをクリックします。
  7. 新しいプロパティー情報を入力します。
    • システムプロパティー名。
    • プロパティーの値。
    • プロパティーを稼働中の JVM に即座にロードする必要がある場合や、JVM の起動時にロードする必要がある場合。デフォルトでは、即座に読み込むことができます。
  8. をクリックし OKます。

33.3.10. システムパスの追加

システムパスの一部は、ホームディレクトリー、ログディレクトリー、Java ホームディレクトリーなど、重要なサーバーディレクトリーの場所に対してすでに定義されています。カスタムアプリケーションの場合、他のパスを定義するのに有用または必要になる場合があります。これらはサーバー設定に追加できます。
注記
デフォルトのシステムパスは、リソース設定で編集または削除できません。これらは JBoss EAP 7 のインストール自体によって定義されます。これらのパスは名前 jboss.* user.*、およびで始まり java.*ます。
にあるように EAP 7 サーバー接続設定を編集して、ホームディレクトリーやベースディレクトリーなどのデフォルトのシステムパスの一部を編集でき 「接続設定の編集」 ます。
これらのデフォルトのパスエントリーには、edit および delete アイコンが表示されます。編集ウィンドウが表示され、パスは編集または削除できますが、これらの変更は即座にリセットされます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
  4. Configuration タブを開きます。
  5. Paths セクションを展開します。
  6. Paths リストの下部にあるプラス(+)アイコンをクリックします。
  7. パス情報を入力します。
    • 作成するパスの名前。
    • 作成するパス(絶対または相対パス)。
    • 相対パスが Path 値として指定された場合は、Relative フィールドの Unset? チェックボックスの選択を解除し、相対パスの 名前 を入力します。
    • プロパティーが読み取り専用である場合。読み取り専用プロパティーの作成後は編集 できません。読み取り専用パス(デフォルトのパスから)を削除し、変更する必要がある場合には再作成する必要があります。
  8. をクリックし OKます。

33.3.11. 接続設定の編集

33.3.11.1. EAP 7 サーバーの一般的なプロパティーの変更

コネクション設定は、JBoss ON エージェントがリソースへの接続に使用するプロパティーです。使用する接続設定は、リソースのプラグイン記述子で識別されます。
接続設定はドメインコントローラーまたはスタンドアロンサーバーでのみ設定可能で、すべての子リソース接続プロパティーはメインサーバー設定から派生します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
  4. Inventory タブを開き、Connection Settings サブタブを選択します。
  5. サーバー接続プロパティーは General Properties セクションにあります。プロパティーの一部のみを編集できます。ホームディレクトリー、ベースディレクトリー、サーバータイプ(EAP または AS)などの JBoss EAP 7 インストール自体から派生した情報が表示されますが、非アクティブになります。
    • Hostname サーバーへの接続に使用する IP アドレスを指定します。通常 127.0.0.1 ですが、管理インターフェース設定が変更された場合、IP アドレスは localhost ではなくパブリック IP になります。
    • Port は管理インターフェースのポートです。
    • Secure SSL を使用して JBoss Enterprise Application Platform 6 管理インターフェースと通信するかどうかを示します。JBoss ON エージェントが JBoss Enterprise Application Platform 7 スタンドアロンサーバーまたはホストコントローラーの HTTP 管理インターフェースが SSL を使用することを検出すると、検出中に true に設定されます。
    • Username および Password は、エージェントがログインに使用する JBoss EAP 7 ユーザーのクレデンシャルです。このユーザーが、インストール RHQ ユーザー操作 を使用して作成されている場合、ユーザーはになり rhqadminます。
    • ドメインコントローラーのみ。スタンドアロンサーバーでは、設定とサーバーインスタンスの定義はすべて同じファイル standalone.xml か、起動スクリプトに渡されるその他の設定ファイルにあります。ドメインの場合、サーバー設定は 1 つのファイル(ドメインコントローラー用)で定義されますが、サーバーインスタンスは別のファイル(ホストコントローラー用)で定義されます。Domain Configuration および Host Configuration フィールドには、プロファイル設定、および管理対象サーバーインスタンスを参照する domain/configuration/ ディレクトリー内のファイルの名前がそれぞれ示されます。
  6. ページ上部の Save ボタンをクリックします。
注記
Connection Settings エリアの情報を表示する他に、スタンドアロンサーバーの設定も Configuration タブに表示され(編集できません) Server Environment エリアの下に表示されます。

33.3.11.2. JBoss Enterprise Application Platform 7 サーバーのセキュア接続設定の変更

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss Enterprise Application Platform 7 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Inventory タブを開き、Connection Settings サブタブを選択します。
  5. セキュアな接続設定は Secure Connections Settings セクションにあります。
  6. セキュアな接続設定を適切な情報で構成し、をクリックし Saveます。
  7. JBoss ON は、次の可用性スキャンの後にこれらの設定の使用を開始します。
注記
これらの設定を使用するには、General Settings セクションで「Yes」に設定 Secure する必要があります。詳細は 「EAP 7 サーバーの一般的なプロパティーの変更」 を参照してください。

33.3.11.3. EAP 7 トピックリソースのインストールパスの表示

管理対象サーバー、サブシステムサービス、JVM 定義、サーバーグループなどの EAP 6 サーバーの子リソースは EAP 6 サーバーの設定ファイル内に定義されます。
子リソースの「接続設定」は、そのサーバー設定のエントリーになります。
コネクション設定は子リソースの Inventory > Connection Settings タブで表示できますが、リソース自体に必須であるため、編集できません。子の接続設定はリソースです。
たとえば、main-server-group 定義はドメインコントローラーの domain.xml ファイルに含まれます。
    <server-groups>
        <server-group name="main-server-group" profile="full">
		...
JBoss ON GUI では、定義は element=name形式の接続設定パスとして指定されます。

図33.8 子リソース接続設定

子リソース接続設定

33.3.12. インストール済み拡張の表示

JBoss EAP 7 のプロファイル(スタンドアロンサーバーおよびドメインの両方)で利用可能なサブシステムはすべて 拡張機能 としてロードされます。これらのエクステンションは、設定ファイル(domain.xml または standalone.xml)で定義されるモジュールのクラスです。
    <extensions>
        <extension module="org.jboss.as.clustering.infinispan"/>
        <extension module="org.jboss.as.clustering.jgroups"/>
        <extension module="org.jboss.as.cmp"/>
        <extension module="org.jboss.as.configadmin"/>
        <extension module="org.jboss.as.connector"/>
        <extension module="org.jboss.as.ee"/>
        <extension module="org.jboss.as.ejb3"/>
	...
これらの拡張機能は JBoss ON では設定できませんが、現在の拡張機能設定はスタンドアロンサーバーまたはドメインコントローラーの設定の一部として JBoss ON で表示できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
  4. Configuration タブを開きます。
  5. Installed extensions セクションを展開します。
注記
EAP 7 サーバー設定の Extensions 領域にあるモジュール名の横に編集アイコンが表示されます。これらのプロパティーは読み取り専用で、編集ボックスがポップアップしても編集できません。

33.3.13. サーバー設定の再読み込み

一部の設定変更を有効にするには、EAP 7 サーバーを再起動する必要があります。サーバーは内部的に requires-reload 状態としてマークされています。JBoss ON はリロードを強制しませんが、再読み込みを必要とする変更が加えられているかどうかは管理者に通知します。
注記
JBoss ON は設定が変更されるたびに設定を自動的に再読み込みしないため、管理者は複数の変更を行い、メンテナンスウィンドウ(JBoss ON 経由)またはローカルシステムに cron ジョブを設定して、再読み込み操作をスケジュールできます。
サーバーツリー内 リソースについてConfiguration > Current タブをクリックすると、サーバーのリロードが必要なメッセージボックスが表示されます。

図33.9 設定メッセージのリロード

設定メッセージのリロード
注記
通常、設定をリロードする必要がある変更には、ポート番号のリセットやインターフェースの接続プロトコルの変更など、接続の処理方法を変更する必要があります。
注記
エージェントがオフラインになり、UI で Configuration タブを表示すると、サーバーがリロードされた場合でもメッセージボックスが表示されます。これは、reload 状態が変更したサーバーと通信できなかったため、サーバーが古い情報を表示するためです。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
  4. Operations タブを開きます。
  5. ページ下部の New ボタンをクリックします。
  6. ドロップダウンメニューから Reload オプションを選択します。
  7. Schedule ボタンをクリックします。

33.3.14. 設定項目の制御

設定のドリフト は、時間の経過と共に必要な設定または管理者が定義した設定への変更を蓄積するものです。これらの変更は簡単です。ただし、リソースを目的の設定外に移動します。
設定のドリフトおよび JBoss ON のドリフトモニタリングの詳細は、で説明されてい 15章設定項目の管理 ます。
EAP 7 では、重要な設定をすべてカバーし、管理者の介入なしに修復へのパスを提供するドリフトストラテジーを計画し、実稼働システムを保護するのに役立ちます。
  1. やなどの重要な設定ディレクトリーを追跡するドリフト定義を設定 domain/configuration/ しますが standalone/configuration/、ロギング、ライブラリー、データディレクトリーなど、常にデータが変更されるディレクトリーは除外されるようにします。設定ディレクトリー内でも、、、host_xml_history/ domain_xml_history/、およびディレクトリーの除外ルールを作成します。これらは適切な設定ファイルではなく standalone_xml_history/、追跡すべきではありません。
  2. 必要な設定が配置されたら、その 設定 をドリフト定義に固定します。これにより、希望の設定がベースラインとして設定されます。すべての変更は、そのベースラインと比較されます。
  3. 設定ファイル設定のアーカイブを作成します。
  4. EAP 7 設定をリセットし、ドリフトを修正するために自動的にデプロイできるバンドル定義を作成します。
    宛先の作成時には、EAP 7 リソースのプラットフォームである必要があります。宛先はスタンドアロンサーバーまたはドメインコントローラーのいずれかですが、プラットフォームを使用すると、バンドルを期限切れのディレクトリーにデプロイしてから /tmp/mybundles/holding、インストール後のタスクを実行して設定ファイルを configuration ディレクトリーにコピーします。
    通常、バンドルをデプロイすると、ターゲットディレクトリーにある既存ファイルがすべて削除され、バンドルに置き換えられます。この動作を制御する方法はありますが、通常はバンドルの内容が最終デプロイメントの目的と完全に一致するのは安全です。
    バンドルに設定ディレクトリー全体を含めることができないため、ファイルシステム上の別の場所にデプロイすると設定ディレクトリーが保持され、重要な設定ファイルのみが Ant タスクによってコピーされます。
  5. 2 つのことを行う設定のドリフトに関するアラートを設定します。
    • 管理者に通知メールを送信します。
    • バンドルを自動的にデプロイするプラットフォームで CLI スクリプトを実行します。
    25章アラートの定義 JBoss ON サーバーサイドスクリプトを起動するアラート通知を設定する方法や、別のリソースで操作を実行する方法についての情報があります。
注記
EAP 7 リソース設定の変更、JVM 定義設定の変更、サーバーグループおよび管理対象サーバーの追加、または構成設定の変更はすべて EAP 7 設定ファイルの編集 domain.xml および変更を行い standalone.xmlます。これにより、アラートが設定されている場合にドリフトアラートがトリガーされます。

33.3.15. 設定変更の追跡および取り消し

JBoss ON UI または CLI で加えられた設定変更は、変更履歴に記録されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
  3. インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
  4. Configuration タブを開き、History サブタブを選択します。
    注記
    変更履歴ページは、リソース設定( Configuration タブ)および接続設定( Inventory > Connection Settings タブ)に対して保持されます。
  5. ID 番号の変更をクリックすると、その バージョン に適用された構成設定が開きます。
  6. 変更内容は、一覧から選択して Compare ボタンをクリックして、標準の diff 形式の変更を比較できます。
  7. 現在、ライブバージョンの設定は、一覧で目的の 以前 のバージョンを選択して Rollback ボタンをクリックすることで、以前のバージョンに戻すことができます。

33.4. JBoss EAP 7 リソースの作成

33.4.1. 履歴の追跡

すべての Inventory タブには Child History サブタブがあります。履歴は、子リソースを追加または削除した場合と、アクションが発生した日付と、JBoss ON ユーザーが開始した日の一覧です。

図33.10 子履歴

子履歴
JBoss ON でのリソースの追加または削除は、インベントリーの変更の追跡を維持するのに役立ちます。

33.4.2. サーバーグループの作成

サーバーグループはドメイン設定の一部として作成され、管理対象サーバーの設定とコンテンツの管理に役立ちます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. EAP 7 サーバーのリソースエントリーを選択します。
  4. 左側のメニューの EAP7 Host Controllers セクションを展開します。
  5. ドメインコントローラーエントリーを右クリックします。
  6. Create Child メニューで、の項目を選択し Server Groupます。
  7. 新しいサーバーグループの名前を入力します。
  8. サーバーグループの設定: 使用するプロファイル、使用するソケットバインディンググループ、および設定するシステムプロパティーを入力します。
  9. をクリックし Finishます。

33.4.3. 管理対象サーバーの作成

管理対象サーバーはドメイン内の機能サーバーであり、実際のクライアントの対話を実行します。管理サーバーはドメインコントローラーの子で、管理サーバーの設定と内容はドメインコントローラーの設定にあり、サーバーグループによって割り当てられます。
注記
ドメインコンポーネントを物理システム(「設定とリアルタイム操作の分離: ドメイン」)に編成する方法により、管理サーバーは、その親であるドメインコントローラーと同じ設定エントリーに表示されない場合があります。新しい管理サーバーは、作成されたホストコントローラーの子として一覧表示されます。新しい管理対象サーバーは、そのホストコントローラーのプラットフォーム(エージェント)インベントリーに表示されます。
注記
ジョブの送信後にホストコントローラーで作成プロセスを実行する必要があります。その後、ローカルエージェントは新しいインスタンスを検出する必要があります。ジョブが実行されて完了するスケジュールの場所によっては、新しい管理対象サーバーがエージェントの検出キューに表示されるまでに数分の時間がかかる場合があります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. EAP 7 サーバーのリソースエントリーを選択します。
  4. 左側のメニューの EAP7 Host Controllers セクションを展開します。
  5. ドメインコントローラーエントリーを右クリックします。
  6. Create Child メニューで、の項目を選択し Managed Serverます。
  7. 新しいサーバーの名前を入力します。
  8. サーバーの設定を入力します。
    • サーバーを作成する EAP 6 ドメインホスト。
    • サーバーを追加するサーバーグループ。
    • 使用するソケットバインディンググループ。これにより、使用するサーバーインスタンスのベースポート番号が指定されます。
    • ポートオフセット。これは、ソケットバインディング設定に追加して、サーバーインスタンスの実際のポート番号を判断する番号です。ソケットバインディングポートが 1000 で、オフセットが 150 の場合は、管理対象サーバーのそのインターフェースに使用されるポート番号は 1150 になります。
    • EAP 6 ホストの起動時にサーバーが自動的に起動するかどうか。
    • サーバーのシステムプロパティー。
  9. をクリックし Finishます。

33.4.4. JVM 定義の変更

インスタンスの JVM 設定を管理すると、パフォーマンスの向上とシステムリソースの割り当てが改善されます。EAP 7 のドメイン構造の性質上、JVM 設定は CAScade の種類で機能します。ホストコントローラーの JVM 設定はサーバーグループとすべてのサーバーに適用されます。サーバーグループの JVM 設定はホストコントローラー設定をオーバーライドし、すべての管理対象サーバーに適用されます。次に、管理リソースに対して JVM 定義を作成し、その定義により高レベルの JVM 設定が強制されます。

33.4.4.1. リソースとしての JVM 定義

EAP 7 管理コンソールでは、JVM 設定はサーバーエントリーの設定オプションとして処理されます。各サーバーには JVM 設定の設定タブがあり、ホストコントローラーのページの JVM Configurations 下に別の Server ページがあります。
管理対象サーバー設定と同様に、サーバーグループの設定には JVM 設定のタブがあります。
JBoss ON では、JVM はこれまで別のリソースタイプで、独自の設定とモニタリングを使用していました。EAP 7 では、JVM 定義は設定プロパティーのコレクションであることが分かりますが、JVM 定義は個別のリソースタイプ、サーバーグループの子として扱われます。これは、JVM 定義 は設定プロパティーのコレクションです。JVM 自体は親リソースです。

33.4.4.2. JVM 定義の作成

デフォルトの JVM 定義はすでにホストコントローラーに対して定義され、その JVM 定義はすべてのサーバーグループに適用され、その後にそのグループに関連するすべての管理対象サーバーに適用されます。
サーバーグループまたは管理対象サーバー用に新しい JVM 定義を作成して、これらのデフォルト設定をオーバーライドできます。管理対象サーバーとサーバーグループの定義はホストコントローラーの JVM 定義に基づいています。新しいサーバーグループおよびサーバーの JVM に使用する別のベースを提供するために、追加の JVM をホストコントローラーに追加できます。
重要
ホストコントローラーには複数の JVM 定義を設定できます。デフォルトのデフォルトはすべての管理対象サーバーとサーバーグループで使用されます。また、追加の JVM 定義は管理対象サーバーおよびサーバーグループレベルでカスタム JVM 定義のベース定義として利用できます。
ただし、管理対象サーバーとサーバーグループには JVM 定義は 1 つだけです。UI では、管理対象サーバーとサーバーグループに対して複数の JVM 定義を作成できますが、JVM 定義がすでに存在する場合は最終的な作成手順は失敗します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. JVM 定義を追加するエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し JVM Definitionます。
  5. 定義の名前を入力します。
    注記
    JVM 定義の名前はホストコントローラーの任意の名前になります。管理対象サーバーまたはサーバーグループでは、JVM 定義の名前は、定義のベースであるホストコントローラーの JVM 定義と同じである必要があります。
  6. JVM の設定を入力します。空白のままにすると、親 JVM 定義で定義された値が使用されます。
    JVM の設定の大半は、メモリーとリソースの使用状況に関連するもので、環境変数やその他の設定を JVM に渡すオプションに関連します。この設定の値は、リソースのパフォーマンスとシステム全体のパフォーマンスの両方に悪影響を及ぼす可能性があります。
    設定がに記載されてい 表33.2「JVM 定義プロパティー」 ます。
  7. をクリックし Finishます。

表33.2 JVM 定義プロパティー

property description
JVM オプション 他の Java オプションを設定します。これらのほとんどは、Sun のドキュメントなど Java プロバイダーで文書化されてい http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html ます。
環境変数 JVM で使用する環境変数を設定します。
ヒープサイズ JVM の初期ヒープサイズを設定します。
最大ヒープサイズ JVM の最大許容ヒープサイズを設定します。これを設定しすぎると、メモリー不足のエラーが発生する可能性があります。
Permgen Size 永続生成の初期サイズを設定します。
最大 Permgen サイズ 永続生成の最大サイズを設定します。
type JVM のタイプ。これは、JBoss ON でサポートされる Java タイプである Sun または IBM です。

33.4.4.3. JVM 定義の編集

JVM 定義は、JVM 定義リソースの設定プロパティーを編集して編集されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。
  3. EAP サーバーを選択し、適切な JVM 定義エントリーに移動します。
  4. Configuration タブを開きます。
  5. JVM 設定のいずれかを変更します。これらはに記載されてい 「JVM 定義の作成」 ます。
  6. ページ上部の Save ボタンをクリックします。

33.4.5. Parent-Child リソースの短いリスト

JBoss EAP 7 エージェントプラグインで定義するリソースタイプは、数百種類あり、主要なサーバー、サブシステムタイプ、およびサービスをすべて扱います。Resource Reference は、すべての異なるリソースタイプについて説明し、それぞれの子タイプを一覧表示します。
表33.3「Parent-Child リソースの短いリスト」 は、JBoss EAP 7 の一般的なリソースタイプと、JBoss ON UI で作成可能な子リソースを一覧表示します。
注記
ジョブの送信後に、子リソースの作成は親リソースで実行する必要があります。次に、ローカルエージェントは新規インスタンスを検出する必要があります。
ジョブが実行されて完了するスケジュールの場所によっては、新しい管理対象サーバーがエージェントの検出キューに表示されるまでに数分の時間がかかる場合があります。

表33.3 Parent-Child リソースの短いリスト

resource 子リソースタイプ
スタンドアロンサーバー
  • デプロイメント
ドメインコントローラー
  • ドメインのデプロイメント
  • 管理対象サーバー
  • サーバーグループ
host
  • JVM 定義
サーバーグループ
  • デプロイメント
  • JVM 定義
データソース(プロファイル下)
  • データソース
  • XA データソース
Infinispan > Hibernate
  • キャッシュ
logging
  • Async ハンドラー
  • Console ハンドラー
  • Custom ハンドラー
  • ファイルハンドラー
  • ロガー
  • Periodic Rotating File ハンドラー
  • Size rotating File ハンドラー
Undertow
  • バッファーキャッシュ
  • サーブレットコンテナー
  • server
  • フィルター設定
  • ハンドラーの設定

33.5. Web アプリケーションのデプロイ

Web アプリケーションは、固有のリソースタイプです。これらはサーバーの子リソースとして追加されるため、独自のエントリー、独自の子リソース、監視、アラート、および操作の独立した設定を持つインベントリー内に場所があります。ただし、Web アプリケーションは コンテンツベースのリソース です。最終的に、これらのパッケージは、実際のサーバーやサービスではなく、ソフトウェアパッケージになります。
コンテンツベースのリソースを管理するには、最初のデプロイメント(デプロイメントを子リソースとして作成)およびパッチおよび更新(コンテンツ更新)のパスも行う必要があります。
重要
コンテンツベースのリソースをデプロイすると、ディスク領域の要件に大きく影響する可能性があります。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部で、コンテンツベースのリソースを元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。
したがって、バックエンドデータベース(Oracle または PostgreSQL)をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。

33.5.1. ランタイム情報およびデプロイメントリソース

33.5.1.1. デプロイメントの表示

EAP 7 と JBoss ON の両方で、Web アプリケーションを中央コンテンツリポジトリーに追加し、そのコンテンツをサーバーグループに関連付けるための明確なワークフローが提供されます。ただし、それらが提供する観点は非常に異なります。そのため、使用するコンソールの定義は、その特定の時点で達成する必要があるものによって異なります。
EAP 7 コンソールは、直ちにコンテンツをサーバーグループに関連付けることを重視しています。EAP 7 コンソールでは、デプロイメントは JVM 定義のように共有設定と同様に処理されます。コンテンツパッケージはドメインコントローラーまたはサーバーグループにデプロイされ、管理サーバーに関連付けられます。

図33.11 ランタイムページでのデプロイメント

ランタイムページでのデプロイメント
JBoss ON は、履歴および変化するパースペクティブである web アプリケーションのライフサイクル管理に重点を置いています。JBoss ON が Web アプリケーションを定義する方法には、基本的な違いがいくつかあります。
  • Web アプリケーションは、個別のエンティティーとして、内およびそれ自体として扱われます。インベントリーには独自の場所があり、ドメインおよびサーバーグループとの関連性は、それらのリソースの子であるため反映されます。
    JBoss ON は、ファイルサイズや特定 SHA256 ハッシュなどのパッケージの詳細も記録します。
  • Web アプリケーションには履歴があります。パッケージの更新が changelog に記録されるため、アプリケーションの維持方法を追跡できます。
  • Web アプリケーションは監視できます。応答時間メトリックは、特に基盤のサーバーのパフォーマンスやモニタリング以外に、Web アプリケーションのパフォーマンスを追跡します。

図33.12 JBoss ON の Deployment Resource Details

JBoss ON の Deployment Resource Details
リソースとしてのこの Web アプリケーションは、コンテンツをサーバーにデプロイする簡単なタスクではないことです。EAP 7 コンソールは、非常に単純かつクリーンに実行できます。JBoss ON 管理の目的は、Web アプリケーションのコンテンツを管理することです。
  • パッチおよび更新を格納するコンテンツリポジトリーの作成
  • 複数バージョンのコンテンツの追跡
  • ソフトウェアパッケージを以前のバージョンに戻す(特にスタンドアロンサーバーの場合)
  • 複数のドメインおよびスタンドアロンサーバーを含む、複数の EAP インスタンスに同じコンテンツリポジトリーを使用
  • コンテンツの変更の追跡(および監査)

33.5.1.2. スタンドアロンサーバーおよびドメインのデプロイメントパス

スタンドアロンサーバーとドメインには、非常に異なる構造があり、Web アプリケーションをデプロイするためのコンテンツフローに影響します。
スタンドアロンサーバーの Web アプリケーションデプロイメントは EAP 5 と似ており、デプロイメントに使用されるローカルファイルシステムディレクトリーがあります。ローカルでは、アプリケーションをデプロイメントディレクトリーに追加し、ホットデプロイできます。JBoss ON を使用すると、Web アプリケーションをデプロイするためのパスは 2 つあります。
  • 子リソースとしてデプロイメントを作成します。
  • バンドルを使用してデプロイメントディレクトリーにアプリケーションをプロビジョニングします。
バンドルシステムには、複数のバージョンを保存したり、更新をロールバックしたり、更新のバージョンをスキップしたり、デプロイメントを 1 つのボタンと共にパージする機能があるため、バンドルの使用は多用途で実用的な管理方法です。
ただし、バンドルシステムは実際のファイルシステムの場所でのみ機能します。JBoss EAP 7 ドメインの分散構造およびモジュール構造は、バンドルがオプションではないことを意味します。
EAP 7 ドメインでは、コンテンツは子リソースとしてドメインにデプロイされ、管理者によってサーバーグループに伝播されます。
バンドルシステムの柔軟性と細かな機能はありませんが、通常のコンテンツシステムを使用すると、コンテンツのバージョンと更新を制御する方法が提供されています。コンテンツベースのリソースは、JBoss ON のコンテンツリポジトリーに関連付けることができます。これらのリポジトリーは、さまざまなコンテンツソースから、さまざまな種類のソフトウェアパッケージを保存できます。リポジトリーのパッケージは、リソースに選択的にインストールできます。さらに、リソースを複数のリポジトリーに関連付けることもできます。JBoss ON のコンテンツリポジトリーは、バンドルでの変更の更新や元に戻す際にフラッシュされませんが、個別のパッチファイルを web アプリケーションに適用したり、完全な更新をロールアウトするためのパスルートを提供します。
コンテンツ管理全般は、を参照してください 28章リソースレベルのコンテンツ更新の管理。ここでは、コンテンツリポジトリーの設定、リソースのサブスクライブ、および更新のプッシュについて説明します。

33.5.2. ドメインへの Web アプリケーションのデプロイメント

33.5.2.1. ドメインへの Web アプリケーションを帰リソースとしてデプロイ

注記
他の子リソースを作成する場合と同様に、新しいデプロイメントが JBoss ON インベントリーに追加され、表示されるまで数分かかることがあります。これは、ローカルシステムで新しいリソースを作成し、エージェントが検出する必要があるためです。リソースの作成時に検出スキャンが実行されている場合は、次の検出スキャンが 15 分以上検出されるまでかかることがあります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 ドメインコントローラーを選択します。
  3. ドメインコントローラーエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し DomainDeploymentます。
  5. バージョン番号を入力します。
  6. EAR、WAR、または JAR ファイルをアップロードします。
  7. オプションで、デプロイメントのランタイム名を入力します。
  8. ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。
    注記
    タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。
    特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
  9. をクリックし Finishます。
パッケージがアップロードされると、ドメインの DomainDeployments ディレクトリーに新しいリソースエントリーが追加されます。

図33.13 ドメインデプロイメントディレクトリー

ドメインデプロイメントディレクトリー

33.5.2.2. バンドルを介したドメインへの Web アプリケーションのデプロイ

アプリケーションは、ant バンドルレシピを使用して rhq:handover 要素とともに JBoss Enterprise Application Platform 7 ドメインにデプロイできます。一般的な ant バンドルレシピの詳細は、を参照してください 27章バンドルへのコンテンツおよびアプリケーションのデプロイ
以下の ant バンドルのサンプルにより、「website.war」が「main-server-group-01」 JBoss Enterprise Application Platform 7 ドメインサーバーグループにデプロイされます。
<project name="handover-test-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle">
 <rhq:bundle name="example.com (EAP 7)" version="1.0" description="example.com corporate website hosted on EAP 7">

  <rhq:input-property name="myapp.runtime.name" defaultValue="website.war" required="true"/>
  <rhq:input-property name="myapp.serverGroup.name" defaultValue="main-server-group-01" required="true"/>

  <rhq:deployment-unit name="example.com deployment unit" compliance="filesAndDirectories">
   
   <rhq:file name="prepareDatasource.cli" replace="true">
    <rhq:handover action="execute-script"/>
   </rhq:file>
   <rhq:archive name="website.war">
    <rhq:handover action="deployment">
     <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/>
     <rhq:handover-param name="serverGroup" value="${myapp.serverGroup.name}"/>
    </rhq:handover>
   </rhq:archive>
  </rhq:deployment-unit>
 </rhq:bundle>
 <target name="main"/>
</project>
特定のハンドオーバーアクション、ハンドオーバーパラメーター、およびレシピの例については、にナビゲートして見つかった JBoss Enterprise Application Platform 7 プラグインのドキュメントを参照してください Administration > Configuration > Agent Plugins > JBoss Application Server 7.x
Ant Bundle を JBoss Enterprise Application Platform ドメインにデプロイするには、以下を実行します。
  1. トップメニューで、Bundles タブをクリックします。
  2. Bundle セクションの New ボタンをクリックします。
  3. を選択 UploadChoose てクリックし、目的のディストリビューションファイルに移動して選択します。
  4. をクリックし Nextます。
  5. 必要なバンドルグループを選択し、をクリックし Nextます。
  6. をクリックし Finishた後 Next、をクリックします。
  7. 新たにアップロードしたバンドルの Bundle セクションをクリックします。
  8. バンドルの詳細の Deploy ボタンをクリックします。
  9. 宛先情報を入力し、ウィザードに進みます。
注記
バンドルの宛先情報を指定する場合は、ドメインコントローラーのリソースグループを基にする必要があります。
ant バンドルで server group パラメーターを指定する場合、これはアプリケーションがデプロイされる JBoss Enterprise Application Platform ドメインのサーバーグループになります。

33.5.3. サーバーグループへの Web アプリケーションの割り当て

さまざまなグループに Web アプリケーションを手動で割り当てると、管理者は、で拡張されたようにアプリケーションのライフサイクルを制御でき 「拡張例: Web アプリケーションの割り当てと更新の管理」 ます。異なるオペレーティング環境で同じコンテンツが使用されます。
注記
Web アプリケーションは、ドメインにデプロイするプロセスと同様に、サーバーグループに直接デプロイでき 「ドメインへの Web アプリケーションのデプロイメント」 ます。
ドメインのデプロイメントパスは、コンテンツをドメインコントローラーにアップロードしてからそのコンテンツをサーバーグループに分散することです。サーバーグループへのデプロイメントの作成は同じプロセスに従います。ドメインにデプロイしてサーバーグループに送信します。ショートカットのみを提供します。
ドメインコントローラーにコンテンツがすでに存在する場合は、ここで説明するドメインコントローラー操作でコンテンツをデプロイする必要があります。
コンテンツをドメインにデプロイすると、最初にドメインが種類のリポジトリーとして使用されます。ドメインから、同じパッケージを複数のグループにデプロイできます。また、ドメインにデプロイすると、管理者は、同時に複数のパッケージをグループまたは指定した順序で、同じ操作で複数のパッケージをデプロイできます。これにより、サーバーへのコンテンツストリームを制御するのに役立ちます。
重要
サーバーグループの新たにデプロイされたコンテンツは、正常に作成された場合でも 24 時間限り JBoss ON インベントリーに表示されない場合があります。デフォルトでは、サービスの検出スキャンは 24 時間ごとにのみ行われます。新しいコンテンツベースのリソースを表示するには、エージェントの検出スキャンを実行し、手動で検出します。
注記
デプロイメントはドメインで子リソースとして作成され、操作としてサーバーグループに割り当てられ、最後にドメインの Content タブで更新されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 ドメインコントローラーを選択します。
  3. DomainDeployments フォルダーを展開します。
    デプロイメントフォルダーにすべての Web アプリケーションをデプロイするには、デプロイメントフォルダー自体を選択して操作を実行します。
    単一の Web アプリケーションをデプロイするには、特定の Web アプリケーションを選択します。
  4. サーバーの Operations タブを開きます。
  5. ページ下部の New ボタンをクリックします。
  6. ドロップダウンメニューから Assign to Server-Group オプションを選択します。
  7. アプリケーションをデプロイするグループ(またはすべてのグループ)を選択します。
  8. 操作の実行時やタイムアウト期間のスケジュールなど、操作の標準情報を入力します。
    注記
    タイムアウト期間は、操作がタイムアウトして失敗したことを想定するまでのサーバーが待機する時間を設定します。これは、操作の実行に失敗したり、停止したりすることを意味するわけではありません。
  9. 複数の Web アプリケーションをデプロイしている場合は、パッケージがデプロイされる順序を設定する方法に Execute ラジオボタンを設定します。すべてのパッケージは一度にデプロイすることも、特定の順序でデプロイすることもできます。
  10. Schedule ボタンをクリックします。
  11. 必要に応じて、エージェントで検出スキャンを実行して、新しいコンテンツリソースを検出します。デフォルトでは、サービスの検出スキャンは 24 時間ごとに実行されるため、新規コンテンツの検出に時間がかかる可能性があります。
    1. UI でエージェントエントリーを開きます。
    2. Operations タブを開き、execute prompt command 操作を選択します。
    3. discovery コマンドを操作引数として入力します。これで検出スキャンが実行されます。
    4. Schedule ボタンをクリックします。

33.5.4. 拡張例: Web アプリケーションの割り当てと更新の管理

設定

Tim the IT Guy は、開発からステージングおよび実稼働環境まで、Web アプリケーションの進捗を明確にしたいと考えています。EAP 7 のネイティブ構造では、異なるサーバーグループを作成し、各ステージでテストを渡すため、中央ドメインコントローラーから適切なサーバーグループにコンテンツをデプロイできます。

IT Guy が希望する Tiim はそのパスの上にレイヤーを追加し、適用パッチおよび更新の作成を可能にします。メンテナンススケジュールの一部として、修正を管理し、監査できるようにする必要があります。

The Plan

  1. Tim は、まず維持する必要のあるサーバーグループの概要を示します。シンプルな環境では、3 つのグループ(testing、staging、および production)が必要です。
  2. 2 つのコンテンツリポジトリーを作成します。1 つはパッチ用で、もう 1 つは Web アプリケーションの新しいバージョン用です。
  3. ドメインデプロイメントを作成し、web アプリケーションを testing サーバーグループにプロモートします。
  4. Tim は、Web アプリケーションの応答時間監視を設定します。テストエリアで必要なパフォーマンスパラメーターを満たすと、Tim はデプロイメントをステージング環境にプロモートし、次に実稼働サーバーグループにプロモートします。

結果

各デプロイメントのパッケージ履歴により、Web アプリケーションがデプロイされた時点、バージョン、およびそのコンテンツを追跡できます。

Tim は、コンテンツをリポジトリーにデプロイし、サブスクライブしているすべてのリソースにインストールすることで、パッチまたは完全なアップデートを適用できます。コンテンツの新しいバージョン番号など、このパッケージの変更はパッケージ履歴に含まれています。
パッチおよび更新リポジトリーは特定の JBoss Enterprise Application Platform 7 ドメインではなく、JBoss ON 自体に設定されているため、必要に応じて他のドメインおよびスタンドアロンサーバーと使用するパッケージを使用できます。

33.5.5. ドメインサーバーグループでの Web アプリケーションの有効化および無効化

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss Enterprise Application Platform 7 ドメインコントローラーを選択します。
  3. インベントリーツリーでフォルダーを展開し、web アプリケーションを選択 DomainDeployments して一覧から有効または無効にします。
  4. Web アプリケーションの Configuration タブを開きます。
  5. Assigned to セクションで、Web アプリを有効または無効にするサーバーグループに対応する Server Group 行の青の鉛筆をクリックします。
  6. Enabled 行で Yes または No を選択し、OK をクリックします。
  7. Save ボタンをクリックします。

33.5.6. デプロイメントコンテンツの更新

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss Enterprise Application Platform 7 サーバーを選択します。
  3. DomainDeployments フォルダーを開きます(スタンドアロンサーバーでは Deployment フォルダーを使用)、更新する Web アプリケーションを選択します。
  4. Web アプリケーションの詳細ページで Content タブを開き、New サブタブをクリックします。
  5. UPLOAD NEW PACKAGE ボタンをクリックします。
  6. UPLOAD FILE ボタンをクリックします。
  7. ポップアップウィンドウで Add ボタンをクリックし、ローカルファイルシステムをアップロードする更新されたコンテンツファイルを参照します。
  8. UPLOAD ボタンをクリックします。
  9. Web アプリケーションパッケージを保存するリポジトリーを選択します。これは不要ですが、更新されたパッケージを JBoss ON に保存して、他の JBoss EAP 7 デプロイメントで使用できるようにすることが推奨されます。
  10. バージョン情報を入力します。
  11. 新しいパッケージの詳細を確認してから、をクリックし CONTINUEます。
パッケージが正常にアップロードされると、UI は Content タブの履歴ページにリダイレクトします。

図33.14 リソースのデプロイメント履歴

リソースのデプロイメント履歴

33.5.7. Web アプリケーションのスタンドアロンサーバーへのデプロイ

スタンドアロンサーバーは、特定のファイルシステムディレクトリーをデプロイメントディレクトリーとして使用します。ドメインのデプロイメントと同様に、子リソースを作成してコンテンツをデプロイすることができます。ただし、スタンドアロンサーバーの構造がシンプルであるため、コンテンツはコンテンツバンドルを使用してデプロイすることもできます。バンドルは、単純化された更新およびパスの元に戻すだけでなく、より詳細なバージョン管理システムを提供します。

33.5.7.1. Web アプリケーションの クライアントリソースとしてのデプロイ

重要
新しいデプロイメントは、正常に作成された場合でも数分または 24 時間間 JBoss ON インベントリーに表示されない場合があります。これは、作成後にエージェントがインベントリーに追加するために新しいリソースを検出する必要があるためです。デフォルトでは、サービスの検出スキャンは 24 時間ごとにのみ行われます。
即座に表示するには、エージェントで 実行プロンプトのコマンド 操作を実行し、discovery コマンドを入力します。これで検出スキャンが実行されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。JBoss EAP 7 スタンドアロンサーバーを選択します。
  3. ナビゲーションツリーのスタンドアロンサーバーエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し Deploymentます。
  5. バージョン番号を入力します。
  6. EAR、WAR、または JAR ファイルをアップロードします。
  7. オプションで、デプロイメントのランタイム名を入力します。
  8. ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。
    注記
    タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。
    特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
  9. をクリックし Finishます。

33.5.7.2. バンドルへの Web アプリケーションのデプロイ

バンドルアーカイブとレシピの作成、宛先の定義、およびバンドルバージョンの管理については、を参照してください 27章バンドルへのコンテンツおよびアプリケーションのデプロイ
  1. トップメニューで、Bundles タブをクリックします。
  2. ディストリビューションファイルをアップロードし、デプロイメントウィザードにアクセスしてバンドルバージョンを作成します。
  3. ウィンドウの下部までスクロールし、Deploy ボタンをクリックします。
  4. デプロイするバンドルを選択します。
  5. JBoss スタンドアロンサーバーの宛先情報を定義します。宛先は、互換性のあるグループ(JBoss リソースを含む)とバンドルをデプロイするディレクトリーの組み合わせです。
  6. デプロイメントウィザードを完了し、必要なプロパティーを設定します。

33.5.8. コンテンツ履歴の追跡および変更の取り消し

デプロイメント履歴ページでは、コンテンツベースのリソースへの変更を追跡します。つまり、更新の試行、タイムスタンプ、およびバージョン番号が一覧表示されます。

図33.15 リソースのデプロイメント履歴

リソースのデプロイメント履歴
バンドルプロビジョニングシステムを介してスタンドアロンサーバーにデプロイされた Web アプリケーションには、変更を元に戻すための簡単なパスがあります。詳細ページには、デプロイしたバージョンに最新のデプロイメントに戻る Revert ボタンがあります。
ただし、サーバーグループまたはドメインへのデプロイメントは、同一のクリアパスを持ちません。コンテンツデプロイメントを元に戻す場合は、最終的にそれを別のバージョンに置き換えることになります。
直接のバージョンを変更できない場合には、パッケージを変更する方法があります。
  • ドメインデプロイメントまたはサーバーグループのデプロイメントがコンテンツリポジトリーに関連付けられている場合は、更新されたパッケージをコンテンツリポジトリーにアップロードし、変更を関連するリソースに同期します。
  • 更新されたパッケージをドメインデプロイメントにアップロードし、deploy を使用して操作をグループ 化して、更新されたパッケージをサーバーグループに送信します。

33.5.9. バージョン管理されたデプロイメントおよびサブデプロイメント

JBoss ON 3.3 および JBoss ON JBoss Enterprise Application Platform 7 プラグインは、JBoss Enterprise Application Platform 7 の管理対象デプロイメントとスタンドアロンデプロイメントの両方(WAR、SAR、JAR、EJB など)およびサブデプロイメント(WAR、SAR、JAR、EJB など)をサポートします。Versioned Deployment(または Subdeployment)は、アーティファクトのバージョンがその名前(例: myapp-1.0.war、myapp-1.1.war、myapp-2.0.war)に組み込む際に存在します。デフォルトでは、アーティファクトが Versioned Deployment(または Subdeployment)として認識されると、そのバージョン番号が削除され、インベントリー内のその名前に一致するリソースが指定のバージョン番号で更新または作成されます。
たとえば、アーティファクト「myapp-1.1.war」がデプロイされている場合、JBoss ON JBoss Enterprise Application Platform 7 プラグインはインベントリー内の「myapp.war」という名前のリソースを探し、バージョン番号を「1.1」にリセットします。そうでない場合は、「myapp.war」という名前の新しいリソースが作成され、バージョン番号が「1.1」になります。このアプローチの利点は、JBoss ON が複数の個別のリソース(例: myapp-1.0.war や myapp-1.1.war)ではなく、バージョン管理されたアーティファクトを単一のリソースとして追跡できることです。これにより、リソースの過去のデータをすべてそのまま維持でき、以前のバージョンのリソースが「DOWN」状態で永続的に表示されるのを回避できます。
JBoss ON はデフォルトでアーティファクトに「Maven-style」バージョンを使用します。これには、バージョンのタイムスタンプをダッシュで区切って区切り、少なくともメジャーバージョンとマイナーバージョンをピリオドで区切る必要があります。
JBoss ON では、デフォルトで以下の正規表現が使用されます。
^(.*?)-([0-9]+\\.[0-9].*)(\\..*)$
注記
バージョン管理スキームと一致しないアーティファクトは個別のリソースとして表示されます。たとえば、myapp-1.war、myapp-2.war、myapp1.war、および myapp2.war は 4 つの異なるリソースとして表示されます。
注記
Versioned Deployment および Subdeployments を無効にするには、JBoss ON JBoss Enterprise Application Platform 7 プラグインで versionedSubsystemDiscovery パラメーターを無効にすることができます。このプロパティーが更新されるには、起動前に適用可能なエージェントごとに更新する必要があります。

33.5.9.1. 既存のリソース

初回起動時に、エージェントはバージョンスキームに一致する既存のリソースを変換しようとします。さらに、同じリソースの複数のバージョンが同時にデプロイされた場合(例: myapp-1.1.war および myapp-2.0.war)、JBoss ON は、同じ論理リソース(myapp.war)の両方へのアップグレードを試みます。このような場合に問題を解決するには、アップグレードの前に不必要なリソースを無効にするか、またはバージョン管理のデプロイメントを無効にする必要があります。
注記
Versioned Deployments を使用する場合は、MISSING ポリシーを DOWN(デフォルト)として設定する必要があります。この設定を変更すると、更新ウィンドウでリソースが削除されたり、無視されてしまう可能性があります。

33.5.10. デプロイメントのトラブルシューティング

問:
デプロイメントでは失敗と示唆されますが、パッケージの再デプロイを試みると、リソースがすでに存在することを示すため、失敗します。
答:
考えられる原因の 1 つが、パッケージのデプロイ時のタイムアウト設定です。タイムアウト時間は、デプロイ操作が失敗した場合に JBoss ON サーバーが待機する時間を設定します。これは、実際にデプロイ操作自体を停止したり、制限したりしません。操作がタイムアウトの制限に達する場合でも、操作は正常に完了し、Web アプリケーションが正常にデプロイされます。
操作がタイムアウトすると、エージェントは新しいリソースを自動的に検出しません。Web アプリケーションは手動でインベントリーにインポートする必要があります。
問:
サーバーグループにパッケージをデプロイしようとしましたが、デプロイメントが一覧に表示されません。
答:
考えられる原因は以下のとおりです。
  • エージェント検出スキャンが実行されていません。検出の実行には数時間かかる可能性があるため、アプリケーションが検出キューに表示されるまで時間がかかる場合があります。これを回避するには、エージェントで検出スキャンを実行します。
  • パッケージが ドメイン にすでにデプロイされている。サーバーグループでデプロイメント子を作成すると、実際に(コンテンツが保存される)ドメインにデプロイメントを作成し、そのデプロイメントをサーバーグループにデプロイします。パッケージがドメインにすでに存在する場合は、サーバーグループでデプロイメントを複製として再度作成しようとすると失敗します。
    この場合は、デプロイを使用してドメインコントローラーでサーバーグループ 操作を行い、アプリケーションをデプロイします。

33.6. JBoss EAP 7 リソースの監視

33.6.1. ランタイム情報および JBoss ON Monitoring

メトリクスは、リソースまたはリソースのグループの実行方法に関する情報のライブストリームです。メトリックは、患者のストレス率、付いたプレッシャー、および知能レベルなどの重要な記号です。リソースでは、これらの重要な統計は可用性、データベースキャッシュのページヒット、データソースまたは Web アプリケーションのアクティブな接続などです。このメトリクスは、特定時に確認されたリソースの正常性を表示します。
JBoss EAP 7 コンソールは、データソース、トランザクション、Web アプリケーションなど、いくつかの重要なリソースに対する重要なメトリクスの現在および即時スナップショットを示しています。
この変更情報は EAP 7 コンソールの Runtime タブに表示されます。
ランタイム情報は、その時点の健全性を示します。
時間の経過と共に ランタイム情報を確認すると、通常、リソースの実行方法がはるかに改善されます。JBoss ON のすべてのリソースには、監視を表示および設定し、そのモニタリングに基づいてアラートを設定するエリアがあります。
JBoss ON は、管理者がパフォーマンスデータを処理するのに役立つように、ランタイムメトリクスをいくつかの異なる方法で自動的に処理します。
  • 各メトリクスの時間ベースのモニタリンググラフ
  • リソースの実際のパフォーマンス で計算された操作パラメーター、またはベースライン
  • 稼働時間の割合、復旧時間、およびダウンタイムの平均

図33.16 単一のメトリックの JBoss オンベースライン

単一のメトリックの JBoss オンベースライン
JBoss ON は GUI を介して、個別のリソースの監視データも公開します。
  • リソースにはより多くのメトリクスを使用できます。少なくとも、すべてのリソースには可用性監視があります。データソースや管理サーバーなどの一部のリソースには、ルーチン監視で有効にできる多くのメトリクスがあります。
  • 応答時間監視は、Web アプリケーションの特定の URL およびページに対して設定できます。これにより、管理者は、Web アプリケーションのユーザビリティーやカスタマーエクスペリエンスを、接続数などの内部メトリクスと共に追跡できます。
  • イベントログ監視は、異なるエラーログからの重要なメッセージをフィルタリングできます。これにより、JBoss ON はパフォーマンスしきい値を超えていない問題に対して(アラート経由)応答し、ログイベントとパフォーマンスメトリックを関連付けることもできます。

33.6.2. EAP 7 リソースの監視の設定

JBoss EAP 7 管理コンソールの Runtime タブは、管理対象サーバーの状態と共通のサブシステムの現在のスナップショットを提供します。EAP 7 コンソールは、現在の情報にすばやくアクセスできます。これにより、即座に管理タスクを行うことが容易になります。
JBoss ON は、直接的なビューではなく、長期のパフォーマンス追跡に重点を置いています。JBoss ON の EAP 7 エージェントプラグインを使用すると、管理者はリソースの追加のメトリクスを監視し、過去の測定値を追跡し、パフォーマンスベースラインを確立し、リソースのステータスが変更(スケールダウン)と、異なる状態にあるかを確認することができます。

図33.17 グラフの監視

グラフの監視
モニタリング情報はグラフおよび Monitoring タブのテーブルに表示されます。Summary タブには、モニタリングポートレットで視覚的に異なるライングラフが表示されます。
注記
概念と設定の監視に関する詳細は、を参照してください パートIII「監視」

33.6.2.1. 追加メトリクスの有効化

JBoss ON は、EAP 6 コンソールに表示される JBoss EAP 7 リソースのすべてのメトリクスと、追加のメトリクスをサポートします。
しかし、JBoss ON ではデフォルトで有効になっているメトリクスは、EAP 7 コンソールで表示できないものとは異なる場合があります。たとえば、データソースの場合、EAP 7 コンソールは利用可能な接続数、アクティブな接続数、および使用最大接続数を表示します。JBoss ON では、収集されるデフォルトのメトリクスは最大および最小プールサイズ設定、最大待機時間、および 1 分あたりのタイムアウト数です。
注記
リソースタイプごとに可能なメトリクスの完全リストは、「リソースの 完了」を参照してください
リソースに対してメトリクスコレクションを有効または無効にできます。管理者は、指定のメトリクス( コレクション間隔)をチェックする JBoss ON の頻度をリセットすることもできます。
注記
重要度の低いメトリックをチェックすると、プラットフォームやエージェントのパフォーマンスが向上しますが、参照またはイベントの関連付けに関する情報を記録できます。
リソースの監視設定を変更するには、以下を実行します。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。その後、JBoss EAP 7 サーバーを選択し、編集するリソースに移動します。
  3. リソースエントリーの Monitoring タブをクリックします。
  4. Schedules サブタブをクリックします。
  5. メトリックを有効にするには、以下を実行します。
    1. メトリクスの行を選択します。Ctrl キーを使用して複数のメトリクスを選択できます。
    2. ページ下部の Enable ボタンをクリックします。
  6. メトリックのコレクション間隔を変更するには、以下を実行します。
    1. メトリクスの行を選択します。複数のメトリクスは同じ頻度に変更されていれば、Ctrl キーを使用して複数のメトリクスを選択できます。
    2. 適切な時間単位(秒、分、時間)で、目的のコレクション期間を Collection Interval フィールドに入力します。
    3. をクリックし Setます。
    注記
    無効なメトリックのコレクション間隔を変更すると、メトリクスが自動的に有効になります。

33.6.2.2. 可用性監視

可用性は(大半の)直接的な測定値で、リソースが実行中で最小限の応答であるかどうかを示します。エージェントがリソースに接続できる場合は、そのリソースが利用できます。
これは、リソースに対して EAP 7 コンソールに可用性を表示する方法です。このコンソールは、リソースが現在実行しているかどうかを示します。
パフォーマンスの観点として、可用性 は単に実行しているよりも、グレーのグレーの粒度を得られる場合があり ます。たとえば、リソースが周期的にオフになり、繰り返し発生しているか調べる必要があります。回復するまでは、長期間オフライン状態であるか。自身の障害によりリソースが利用できないか、または(プラットフォームなどの)親リソースに到達できない場合、子が正常に動作しているか。JBoss ON は、リソースの実際の状態を区別するために、up、down、disabled、および unknown の 4 つのリソース状態をサポートします。
可用性については、を参照してください 18章可用性
JBoss ON では、リソースの現在のステータスを示すだけでなく、その状態にある時間と、リソースがさまざまな状態で費やした時間の割合も表示されます。これにより、JBoss ON はリソースごとにいくつかの異なる傾向を計算することができます。
  • 全体のアップタイム率
  • さまざまな状態(up、down、または disabled)で費やされた合計時間
  • 失敗の総回数(停止時)
  • 障害間の時間(基本的にはリソースが稼働中および利用可能時間)
  • リカバリーの平均時間。これは障害後にリソースをバックアップするのにかかる時間です。

図33.18 JBoss ON での可用性

JBoss ON での可用性
可用性は、モニタリングメトリクスなどのスケジュールで収集されます。可用性チェックの頻度を制御すると、リソースの優先度が確立されます。
注記
ドメインコントローラーや管理対象サーバーなどのサーバーには、毎分実行される可用性チェックがあります。これにより、不安定なサーバーでリソースのサイクリングを取得するのに役立ちます。データソースや JMS キューなどのサービスは、10 分ごとに可用性についてチェックされます。
可用性チェックの頻度は、エージェントのパフォーマンスに影響を及ぼす可能性があります。特に、多くの子リソースを持つ EAP 7 のようなサーバーに対する影響があります。デフォルトでは、すべてのリソースが利用可能かどうかがチェックされます。OSGi クラスや EJB などの低レベルの子リソースが、実際に独立した可用性チェックを必要としないことがあります。この場合、子の可用性チェックを無効にできます。エージェントは、親の状態を子に自動的に適用します。親が実行中である場合、親は実行していると見なされます。これはバックフィルと呼ば ます。

33.6.3. イベント監視の設定

イベント監視は基本的にログフィルターです。リソース自体はログファイルを維持します。JBoss ON は、指定されたログファイルで発生したメッセージまたはイベントをチェックします。JBoss ON は、ストリーム内のメッセージや、特定のパターンまたは重大度に一致するメッセージのみをチェックできます。
JBoss ON はログメッセージに基づいてアラートを発行する可能性があり、新しい管理リソースの作成やサーバーを再起動など、イベントに対応して自動的にアクションを実行することもできます。
イベントはスケジュールではなく、リソースの実際の操作に基づいて予測できないため、管理者がメッセージをフィルターして動的に応答できる大きな利点があります。
注記
イベント設定は、を参照してください 20章イベント
3 つの JBoss EAP 7 サーバータイプはイベントをサポートし、標準の場所にイベントログで事前設定されています。
  • ホストコントローラー、 domain/log/host-controller.log
  • 管理対象サーバー( domain/servers/server-three/log/server.log
  • スタンドアロンサーバーの場合 standalone/log/server.log
イベントログが設定されている間、デフォルトでは有効になっていません。イベントが JBoss ON エージェントによって収集される前に、イベントログを有効にする必要があります。ログメッセージで検索する特定の文字列などの追加設定も設定できます。
  1. トップメニューの Inventory タブをクリックします。
  2. Servers - Top Level Imports 項目をクリックし、JBoss EAP 7 リソースを選択します。
  3. 適切な EAP 7 リソースに移動します。
  4. リソースエントリーの Inventory タブをクリックします。
  5. Connection Settings サブタブを選択します。
  6. Events Log セクションの下にあるプラスアイコンをクリックします。
  7. イベントエントリーを有効にします。
    必要に応じて、日付の形式、文字列フィルターを設定してメッセージ、またはメッセージの重大度を追加します。
イベント監視を有効にすると、一致するログメッセージがリソースの Events タブに表示されます。

33.6.4. JBoss EAP 7 リソースでのアラート

アラートの詳細は 25章アラートの定義、詳細に説明しています。これは、どのアラート条件を設定するか、およびその応答方法を計画するための詳細な参考となります。
アラートの計画における主な事項は、アラートを発生させた条件に対する自動応答をプランニングすることです。たとえば、EAP 7 ドメインでは、1 つの管理対象サーバーがオフラインになるか、または非常に遅い応答時間の表示を開始することがあります。この場合、JBoss ON は、障害が発生したサーバーの代わりに別のプラットフォームに同じサーバーグループ内に新しい管理対象サーバーインスタンスを自動的に作成できます。
お客様がアクセスする問題(web アプリケーションの応答時間が十分ではない場合など)には、管理者の介入を必要とせず、即座に対応できます。
JBoss ON では以下のようなタイプの応答を使用できます。
  • 管理者へのメール送信
  • アラートリソースでの再起動操作の実行
  • アラートリソースの親に対する操作の実行
  • シェルスクリプトの実行
  • JBoss ON サーバーサイドスクリプトの実行
    サーバー側のスクリプトは非常に強力なものです。スクリプトは、リソース設定の変更、更新されたパッケージのデプロイ、新規リソースの作成、既存リソースの削除、オペレーションの実行、上記のすべてなど、JBoss ON でほぼすべての管理タスクを実行できます。サーバー側のスクリプトの作成に関する詳細は、『 JBoss ON Command-Line Scripts 』の「Writing JBoss ON Command-Line Scripts」 を参照してください。

33.6.5. JBoss EAP 7 リソースでのドリフト設定の監視

JBoss ON は、JBoss Enterprise Application Platform 6 プラグインを使用したドリフト設定モニタリングをサポートします。drift Configuration Monitoring を使用すると、ユーザーはスタンドアロンリソースとホストコントローラーリソースの両方でサーバー設定ディレクトリーに加えられた設定ファイルの変更を監視および追跡できます。これは、JBoss ON によって設定ファイルに加えられた変更や、JBoss Enterprise Application Platform CLI または JBoss Enterprise Application Platform 管理コンソールを使用して変更された変更に適用されます。JBoss ON のドリフト設定モニタリングは、アプリケーションやデータソースなどの JBoss Enterprise Application Platform 7 へのデプロイメントを追跡および監視します。設定のドリフトの管理に関する詳細は、を参照してください 15章設定項目の管理
Drift 設定モニタリングを有効にするには、以下を実行します。
  1. トップメニューで、をクリックし Inventoryます。
  2. 左側の Resources メニューテーブル Servers - Top Level Imports から選択します。
  3. インベントリーツリーでスタンドアロンまたはホストコントローラーを選択し、設定のドリフトを監視します。
  4. Drift タブをクリックします。
  5. 下部の New ボタンをクリックします。
  6. ドロップダウンメニュー Template-Configuration Files から選択し、をクリックし Nextます。
  7. 設定オプションを入力し、Finish をクリックします。

33.7. EAP 7 での mod_cluster サービスの使用

mod_cluster モジュールは、JBoss アプリケーションサーバーの Web コンテキストと Apache Web サーバーとの間に動的な負荷分散を提供します。
クラスターを作成する方法は 2 つあり mod_clusterます。JBoss でモジュールを設定して web アプリケーションを管理し、Apache でモジュールを設定してセッションおよびルーティングを管理します。
JBoss ON は、ドメインサーバーとスタンドアロンサーバーの両方で JBoss EAP 7 の埋め込み mod_cluster サブシステムを管理できます。

33.7.1. mod_cluster および JBoss ON について

EAP 6 の mod_cluster モジュールであるモジュールは、JBoss EAP サーバーの web アプリケーションと Apache Web サーバーの間で通信します。複数の JBoss EAP サーバーを mod_cluster グループに含めることができ、これらのサーバーは管理対象サーバー、スタンドアロンサーバー、または両方を混在させることができます。

図33.19 mod_cluster トポロジー

mod_cluster トポロジー
mod_cluster モジュールが含まれる高可用性プロファイルのみ。ドメインでは、高可用性をサポートするプロファイル( full-ha プロファイルやカスタムプロファイルなど)を使用できますが、other-server-group サーバーグループはこの ha プロファイルを使用するように設定されます。スタンドアロンサーバーの場合、サーバーは standalone-ha.xml 設定で起動する必要があります。
サーバー内の 1 つの EAP mod_cluster サーバーがマスターノードです。これは管理 mod_cluster サービスです。クラスターの他のすべてのメンバーはワーカーノードです。
注記
一般 mod_cluster の情報は mod_cluster プロジェクトドキュメンテーション で入手できます。
特定のリソースが mod_cluster ドメインに属するかどうかは、リソースに関連するプロファイルによって異なる(JBoss ON の制御のほとんどは)。(当然ながらスタンドアロンサーバーは起動スクリプトに JBoss ON の設定を使用して高可用性 JAVA_OPTS 設定を使用するか、高可用性プロファイルを使用する新しい管理サーバーを作成できます。ただし、プロファイル定義自体は JBoss ON の外部で作成され、維持されます。
JBoss ON は mod_cluster 設定自体を管理します。クラスター設定には、マルチキャスト(アドバタイズ)、負荷分散、セッションの処理、およびネットワーク設定が含まれます。

33.7.2. ロードバランシング用のマルチキャストの設定

mod_cluster マルチキャストシグナルを使用して、プロキシーサーバーが利用可能であるノードに通知できます。これにより、ノードが自動的にドメインに登録できるようになります。
登録プロセスのサブセットとして、ノードを特定のドメインまたはロードバランサーに転送できます。
注記
マルチキャストはデフォルトで設定されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 7 サーバーを選択します。
  3. mod_cluster service リソースに移動します。
  4. リソースエントリーの Configuration タブをクリックします。
  5. Advertise Options セクションに移動します。
  6. マルチキャストの設定を変更します。
    mod_cluster ノードの特定のロードバランサーを使用するには、Balancer フィールドをロードバランサー名に設定します。任意で、Domain フィールドはロードバランサー自体に設定されたグループのいずれかです。
    重要
    Balancer および Domain 値は、対応する Apache サーバーの設定と一致する必要があります。
  7. ページ上部の Save ボタンをクリックします。

33.7.3. Discovery からの Web コンテキストの除外

デフォルトでは、ノードの Web コンテキストは mod_cluster サービスによって検出および管理されます。Web コンテキストをクラスターに含まれない場合、名前で除外できます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 7 サーバーを選択します。
  3. mod_cluster service リソースに移動します。
  4. リソースエントリーの Configuration タブをクリックします。
  5. Web Context Options セクションに移動します。
  6. Excluded Contexts フィールドの設定を解除し、除外するコンテキストの名前を追加します。
    注記
    JBoss EAP の内部コンテキストの一部はデフォルトで除外されます。これは除外リストに保持する必要があります。除外する新しいコンテキストは、既存のリストに追加する必要があります。
  7. ページ上部の Save ボタンをクリックします。

33.7.4. Web コンテキストメトリクスの設定

mod_cluster 異なるタイプのメトリクスを使用して、トラフィックのバランスを最も効率的に判断することができます。これらのメトリクスについては、mod_cluster ドキュメント に記載されています。これらのメトリクスには、アクティブなセッション、要求数、トラフィックが含まれます。
また、カスタムメトリクスを作成してサブシステムに追加することもできます。
これらのメトリクスを JBoss ON の mod_cluster サブシステム設定に追加して監視できます(および既存のメトリクスを削除できます)。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level ImportsResources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 7 サーバーを選択します。
  3. mod_cluster service リソースに移動します。
  4. リソースエントリーの Operations タブをクリックします。
  5. ドロップダウンメニューから Add (Custom) Metrics 操作を選択します。
  6. メトリック情報を入力します。デフォルトのメトリクスは mod_cluster ドキュメント に記載されています。
  7. ページ下部の Schedule ボタンをクリックします。

33.8. JBoss Enterprise Application Platform 7 のパッチ適用

JBoss ON UI(または CLI)は、JBoss ON および JBoss ON JBoss Enterprise Application Platform 7 プラグインによって管理されるものに基づいて、JBoss Enterprise Application Platform インスタンス(バージョン 6.2 以降)または他のレイヤード製品にパッチを適用できます。重要な例外として、このメカニズムを使用して JBoss ON 自体にパッチを適用する ことはできません。パッチは、製品の特定のマイナーバージョン(JBoss Enterprise Application Platform 6.3 など)で利用可能で、個別の更新(1 回限り)または累積更新として確認できます。JBoss Enterprise Application Platform パッチに関する詳細は、JBoss Enterprise Application Platform 『インストールガイド』を参照してください

33.8.1. パッチ操作

JBoss ON は、使い慣れた deploy、revert、およびpurge 操作を使用して、バンドルサブシステムに JBoss Enterprise Application Platform パッチを適用します。デプロイにより、ユーザーは JBoss Enterprise Application Platform 7 インスタンスのグループにパッチ(1 回限りまたは累積)を適用できます。パッチを元に戻すと、ユーザーは JBoss Enterprise Application Platform 7 サーバーのグループからパッチをロールバックできます。宛先をパージすると、その宛先を介して JBoss Enterprise Application Platform インスタンスのグループに適用されたすべてのパッチがロールバックされます。
注記
エージェントに $EAP/.installation$EAP/.installation/.rhq (エージェントがメタデータを保存する場所)、および EAP ディレクトリーに対する読み取りおよび書き込み権限があることを確認します。これにより、JON エージェントは EAP サーバーにパッチを当てることができます。

33.8.1.1. バンドルおよび宛先

JBoss Enterprise Application Platform 7 パッチは、で説明されている JBoss ON の bundle サブシステムを使用して処理され 「コンテンツバンドルのプロビジョニングの概要」 ます。
宛先は、パッチ操作のターゲットとなるリソースの関連付けです。宛先は、初期デプロイパッチを指定することによって最初 Resource Group に作成されます。同じ宛先への後続のパッチデプロイメントは Destination セクションから作成 され、新しいデプロイメントとして使用しないでください。
重要
予期しない動作を防ぐために、特定の JBoss Enterprise Application Platform インスタンスの JBoss Enterprise Application Platform パッチを 1 つの JBoss Enterprise Application Platform 宛先で作業できます。JBoss ON を使用してパッチを配布する宛先が複数ある場合は、重複しないようにしてください(例: JBoss Enterprise Application Platform サーバーは、これらの宛先がターゲットとする複数のリソースグループの一部ではありません)。パッチを特定の宛先にデプロイしようとし、別の宛先を使用してすでにデプロイされているパッチが検出されると、重複する JBoss Enterprise Application Platform サーバーでパッチデプロイメントが中止されます。
宛先をパージすると、その宛先からリソースグループの所属の 関連付け が削除されます(つまり、宛先がパージされた後に、以前にパージされた宛先によって処理されたサーバーにパッチを配信するのに、別の宛先が使用されます)。
JBoss Enterprise Application Platform インスタンスとの宛先の関連付けを強制的に変更するために(JBoss ON サーバーで宛先が削除されても、削除前にパージされないケースを含む)、新しい 宛先の使用時にバンドルのデプロイメント時に takeOver プロパティーを true に設定できます。これにより、新しい宛先ターゲットであるすべてのサーバーの古い宛先との関連を忘れないように JBoss ON が強制されます。

33.8.1.2. パッチデプロイの実行

パッチは、新規または既存の宛先にデプロイできます。
重要
JBoss ON がパッチデプロイメントを正しく追跡し、パッチを適切に実行するためには、既存の宛先に予定されている後続のパッチが 「既存の宛先へのパッチデプロイの実行」 セクションに従って適用され、新しい宛先として動作しないようにしてください。
注記
JBoss ON は、JBoss Enterprise Application Platform の実行中および停止されたインスタンスの両方にパッチを適用することができます。インスタンスが実行されている場合には、パッチがインストールされますが、インスタンスが再起動されるまで有効になりません。停止したインスタンスの場合、次回のインスタンス起動時にパッチが有効になります。パッチのデプロイメント中に restart プロパティーを使用して、パッチのデプロイメント後にサーバーを自動的に再起動するかどうかを指定できます(デフォルトでは trueに設定されます)。
33.8.1.2.1. パッチを使用したバンドルの作成
  1. Bundles タブをクリックします。
  2. Bundle セクションの New ボタン Bundle Creation Wizard をクリックして起動します。
  3. 必要なパッチをアップロードします。
  4. 設定を更新し、Next ボタンをクリックします。
  5. Next ボタンをクリックします。
  6. Finish ボタンをクリックします。
33.8.1.2.2. 新しい宛先へのパッチデプロイの実行
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Deploy ボタンをクリックして、バンドルのデプロイウィザードを起動します。
    1. 宛先情報を入力し、をクリックし Nextます。
    2. Deployment Bundle Version を選択し、をクリックし Nextます。
    3. Deployment Configuration を選択し、をクリックし Nextます。
      注記
      • この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
      • リソースグループのサーバーにパッチデプロイメントのデフォルトの場所として提供された新しい宛先を設定するには、takeOver オプションをに設定し trueます。
    4. Deployment Information を指定して、をクリックし Nextます。
    5. Finish をクリックし、バンドルを宛先にデプロイします。
33.8.1.2.3. 既存の宛先へのパッチデプロイの実行
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Destinations サブタブをクリックします。
  4. バンドルをデプロイする宛先をクリックします。
  5. Deploy ボタンをクリックします。
  6. デプロイするバンドルバージョンを選択し、をクリックし Nextます。
  7. Deployment Configuration を選択し、をクリックし Nextます。
    注記
    この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
  8. 必要なデプロイメント情報を指定して、をクリックし Nextます。
  9. Finish をクリックし、バンドルを宛先にデプロイします。
注記
JBoss Enterprise Application Platform インスタンスに 1 つのオフパッチを 1 つ以上インストールできますが、累積パッチは 1 つだけです。これは、最後のデプロイメントのみを ライブ として理解するため、JBoss ON UI には反映されません。しかし、JBoss Enterprise Application Platform と JBoss ON ではデプロイメントおよびロールバックロジックと同じです。いずれの場合も、パッチデプロイメントの以前の状態を復元する(JBoss ON で変換)最新のパッチのみをロールバックできます。現在適用されているパッチの実際のセットを表示するには、JBoss ON で JBoss Enterprise Application Platform 7 リソースの Active Patches 特性を確認してください。

33.8.1.3. パッチ変換の実行

パッチを元に戻すと、ユーザーは JBoss ON によって適用されたパッチをロールバックできます。JBoss ON は JBoss Enterprise Application Platform インスタンスに適用されるすべてのパッチを追跡し、適用されたパッチのみを元に戻します。さらに、JBoss ON は適用された最初のパッチのみを返すことがあります。つまり、元に戻す前に JBoss ON は別のパッチを適用する必要があります。JBoss ON によって適用されたすべてのパッチを削除するには、を参照してください 「パッチパージの実行」
重要
JBoss ON では JBoss Enterprise Application Platform の累積パッチに対してパッチ処理を実行できますが、JBoss ON では累積パッチ(およびこれまでのパッチ)が 1 つの単位として扱われます。そのため、累積パッチに対して元に戻すと、JBoss ON は累積パッチ全体を元に戻します。たとえば、ユーザーは Cumulative Patch 01 を JBoss Enterprise Application Platform インスタンスにデプロイし、Cumulative Patch 03(Cumulative Patch 02)を同じ JBoss Enterprise Application Platform インスタンスに適用します。ユーザーが Cumulative Patch 03 を元に戻す場合は、Cumulative Patch 01 に戻すことができます。
パッチを実行するには、以下を行います。
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Summary セクションの Destinations タブをクリックします。
  4. 元に戻す宛先を選択します。
  5. odo をクリックし Revert、をクリックし Yesます。
  6. Next 2 回クリックし、をクリックし Finishます。

33.8.1.4. パッチパージの実行

パージにより、ユーザーは JBoss Enterprise Application Platform インスタンスまたはインスタンスのセットに JBoss ON によってインストールされたすべてのパッチをアンインストールおよび削除できます。パージにより、JBoss Enterprise Application Platform インスタンスまたはインスタンスのセットは、JBoss ON が最初のパッチをインストールする前に見つかったバージョン番号に戻ります。
パージを実行するには、以下を実行します。
  1. Bundles タブをクリックします。
  2. EAP バンドルをクリックします。
  3. Summary セクションの Destinations タブをクリックします。
  4. パージする宛先を選択します。
  5. odo をクリックし Purge、をクリックし Yesます。

付録A よくある質問

A.1. 全般

問:
JBoss Operations Network と RHQ の違いは何ですか?
答:
RHQ は、JBoss Operations Network のアップストリームのオープンソースバージョンです。JBoss Operations Network は RHQ 上に構築された商用製品で、Red Hat を通じた豊富なテストおよび公式カスタマーサポートを提供します。
問:
バグを検索して機能拡張要求を送信するには、公開されている問題トラッカーシステムが存在するか?
答:
バグの検索、バグの報告、または機能強化リクエストの送信には、Bugzilla を使用します。Other ディストリビューションを選択し、RHQ Project コンポーネントを選択します。
問:
サポートされるデータベース
答:
PostgreSQL 8.2.4 以降 8.2.x バージョン。PostgreSQL 8.3、8.4、および 9.0 のすべてのリリース、および Oracle 11 はサポートされるデータベースです。
サポートされるデータベース、サーバーおよびエージェントのプラットフォーム、および Java バージョンの完全なリストは、で利用でき http://www.redhat.com/jboss_on/requirements ます。
問:
JBoss ON を Java 5 で起動できないのはなぜですか?
答:
Java 5 はサポート対象外になりました。Java 6 にアップグレードします。
サポートされるデータベース、サーバーおよびエージェントのプラットフォーム、および Java バージョンの完全なリストは、で利用でき http://www.redhat.com/jboss_on/requirements ます。
問:
ユーザーの設定内容を見つけるにはどうすればよいですか?
答:
データベースクライアントまたは http://server.hostname:7080/coregui/#Test/ ページのいずれかで、以下の SQL コマンドを実行します。
select id, name, string_value 
from rhq_config_property 
where configuration_id = (select configuration_id 
from rhq_subject 
where name = 'your-user-name')
問:
JBoss ON で使用される正規表現の構文
答:
JBoss ON は、UI と設定ファイルの両方において、正規表現を使用します。すべての正規表現は、Regex 構文および 日付/時刻の形式構文 の Sun ドキュメントで説明されているように、標準の Java 形式に従います。
問:
JBoss ON がリソースの可用性をチェックする頻度
答:
エージェントは、サーバー用に利用できるリソースを毎分チェックし、サービスについては 10 分ごとにチェックします。エージェント自体は、合計インベントリーのサブセットで 30 秒ごとに可用性チェックを実行します。これにより、エージェントに安定した負荷が保持され、メモリー集約型使用量の急増が回避されます。エージェントは結果を JBoss ON サーバーに送信します。
特定のリソースが利用可能な状態についてチェックされる頻度は、メトリクスの頻度のスケジュールと同様にスケジュールされます。この可用性チェックの間隔は、その Monitoring > Schedules タブのリソースについて変更できます。
エージェント自体が可用性チェックを実行する頻度は、rhq.agent.plugins.availability-scan.period-secs 設定で定義されます。デフォルトは 30 秒です。パフォーマンス上の理由から、30 秒未満になることはありません。新しい間隔を ADDITIONAL_JAVA_OPTIONS 値のいずれかに設定することで、スキャン間隔を拡張できます。例:
RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Drhq.agent.plugins.availability-scan.period-secs=45"
問:
JBoss ON エージェントは起動時に待機する理由
答:
コマンドラインから JBoss ON エージェントを起動すると、send > プロンプトには続行されず、そこに留まり、待機することがあります。これには、いくつかの理由があります。

サーバーはエージェントの登録要求を拒否しました。

エージェントが起動時にこのメッセージを返すと、エージェントは 1 つの名前でサーバーで認識されているが、起動時に別の名前を送信することを意味します。

Cause: [org.rhq.core.clientapi.server.core.AgentRegistrationException:The 
agent asking for registration is trying to register the same address/port 
[172.31.7.7:16163] that is already registered under a different name [example]; 
if this new agent is actually the same as the original, then re-register with
the same name]
これに対処するには、オプションを指定してエージェントを起動 --clean し、正しい名前を付けます。

エージェントはサーバーに到達できません。

これは、サーバーがダウンしているか、ファイアウォールがトラフィックをブロックしたためにサーバーにアクセスできないエージェントの状態です。サーバーマシンのポート 7080 がエージェントのマシンから到達可能であることを確認します。これは、Web ブラウザーで確認できます。

サーバーはエージェントに接続できません。

サーバーがエージェントのエンドポイントに ping できないことを示すエラーは、エージェントがサーバーと通信できるが、サーバーはエージェントと通信できないことを意味します。これは、エージェントポートがファイアウォールによってブロックされていることを意味します。

The server has rejected the agent registration request. Cause: 
[org.rhq.core.clientapi.server.core.AgentRegistrationException:Server cannot 
ping the agent's endpoint. The agent's endpoint is probably invalid or there 
is a firewall preventing the server from connecting to the agent. Endpoint:
socket://172.31.7.3:12345/....

エージェントにはプラグインがありません。ダウンロードするまで待機します。

これは通常、サーバーがエージェントが送信したセキュリティートークンとは異なることを意味します。これにより、異なるエージェントバージョンや仮想マシンでテストするなどして、Java プリファレンスエントリーが mangled になります。

このメッセージは、プラグインがない場合は、初期エージェントの起動時のみ表示されます。以前の実行でプラグインがダウンロードされている場合は、以下の状況で実行されます。
これをエージェントで確認した場合は、サーバーに以下のようなメッセージが表示されるはずです。
11:40:48,454 WARN [CommandProcessor] {CommandProcessor.failed-
authentication}Command failed to be authenticated! This command will be 
ignored and not processed: Command: type=[remotepojo]; cmd-in-response=
[false]; config=[{rhq.security-token=1217855913569-109582636-403140853869881172, rhq.send-throttle=true}];
params=
[{targetInterfaceName=org.rhq.core.clientapi.server.core.CoreServerService, 
invocation=NameBasedInvocation[getLatestPlugins]}]
これに対応するには、--clean オプションを使用してエージェントを対話的に起動します。

エージェントの起動は問題ありませんが、ping コマンドは失敗します。

ここでは、エージェントは正常に起動しますが、監視データが送信されないなど、他のエージェント通信の問題が生じる可能性があります。エージェントコマンドラインに ping を試みると、以下のようなエラーが返されます。

sending> ping
 
 
Pinging...
 
 
Failed to execute prompt command [ping]. Cause: 
org.rhq.enterprise.communications.command.server.AuthenticationException:Command 
failed to be authenticated! This command will be ignored and not processed: 
Command: type=[remotepojo]; cmd-in-response=[false]; config=[{rhq.security-
token=1214208960346-102975580-7334156733284942657, rhq.send-throttle=true}]; 
params=[{targetInterfaceName=org.rhq.enterprise.communications.Ping, 
invocation=NameBasedInvocation[ping]}]
サーバーログには、複数の CommandProcessor.failed-authentication メッセージが含まれる可能性があります。つまり、エージェントのポートは、サーバーが通信できないようにファイアウォールによりブロックされている可能性があります。

高可用性の IP アドレスの正引きおよび後方マッピングは一致しません。

コンピューターの IP アドレスをコンピューター名に逆マッピングでき、この名前が同じ IP アドレスにマッピングされていることを確認します。すべてのホストで true である必要があります。

たとえば、IP アドレスが 172.31.7.7 の場合、名前解決の結果は以下のようになります。
$ dig -x 172.31.7.7
[...]
;; ANSWER SECTION:
7.7.31.172.in-addr.arpa. 86400 IN     PTR     example
$
$ dig example
[...]
;; ANSWER SECTION:
example       74030   IN      A       172.31.7.7
エージェントサーバー通信が機能し、その通信が停止している場合は JBoss ON サーバー UI に移動します。次に Administration> High Availability> に移動し、表示される名前が予想される内容 Server と一致するかどうかを確認します。エージェントは同じかどうかを確認します。
これが機能し、エージェントがハングしている場合には、設定が間違っている可能性もあります。
問:
How do I install a supported version of PostgreSQL on Red Hat Enterprise Linux?
答:
Red Hat Enterprise Linux 5.5 のデフォルトの PostgreSQL バージョンは、サポート対象外である PostgreSQL の古いバージョンであるため、更新する必要があります。
Red Hat カスタマーポータルから Postgres をインストールするには、以下を実行します。
  1. RHN/JBoss の認証情報 を使用 して http://rhn.redhat.com にログインします。
  2. Red Hat Application Stack v2 チャネルを追加します。
  3. システムを更新します。
    sudo yum update
  4. 具体的には PostgreSQL を更新します
    sudo yum install postgresql-server
    data ディレクトリーがインストールされている /var/lib/pgsql/data。JBoss ON は、PostgreSQL 8.2.4 以降および 8.2.x バージョンと PostgreSQL 8.3、8.4、および 9.0 のすべてのリリースをサポートします。
  5. JBoss ON サーバーを通常通りにインストールおよび設定します。
問:
JBoss ON コンソールから JBoss ON データベースに SQL コマンドを実行するにはどうすればよいですか?
答:
SQL ページに移動します。
http://server.example.com:7080/coregui/#Test/
問:
VMWare で JBoss ON はサポートされますか?
答:
VMware ESX は、Red Hat Enterprise Linux では、ベアメタルと同等のサポートです。VMWare 製品にハードウェアの問題が発生した場合は、VMWare サポートと連携して問題を解決します。
JBoss EAP は、Red Hat Enterprise Linux のすべての現行バージョンで完全にサポートされます。サポートレベルと SLA は、購入したエンタイトルメントによって異なります。
問:
メモリー不足の状態をデバッグできるようにするには、メモリー不足または要求に応じてエージェントまたはサーバーがヒープをダンプするにはどうすればよいですか?
答:
これらの JVM 引数をサーバーまたはエージェントに渡します(設定)。 RHQ_AGENT_ADDITIONAL_JAVA_OPTS または RHQ_SERVER_ADDITIONAL_JAVA_OPTS 変数)。
-XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpOnCtrlBreak
特定の場所にヒープダンプファイルをドロップするには、path:
-XX:HeapDumpPath=location
SUN JVM Debugging Options 」を参照してください。

A.2. インストールおよびアップグレードの問題

問:
サーバーのインストール(またはアップグレード)時にエラーメッセージが表示されます。意味は?
答:
アップグレード中に、以下のようなエラーメッセージがコンソールに表示されます。
ERROR [ClientCommandSenderTask] {ClientCommandSenderTask.send-failed}Failed to send
command [Command: type=[remotepojo]; cmd-in-response=[false]; config=[{rhq.timeout=1000,
rhq.send-throttle=true}]; params=[{targetInterfaceName=org.rhq.enterprise.communications.Ping,
invocation=NameBasedInvocation[ping]}]]. Cause: org.jboss.remoting.CannotConnectException:[.....]
これは無視できます。
問:
サーバーをインストールしましたが、接続できません。What's wrong?
答:
インストーラーが実行時に 0.0.0.0 にバインドされていない場合、必要な接続プロパティーは rhq-server.properties ファイル内のサーバーに設定されません。java.rmi.server.hostname パラメーターは、jboss.bind.address パラメーターの値に一致するサーバーの実際の IP アドレスに手動で設定する必要があります。rhq-server.properties ファイルを編集した後にサーバーを再起動して、新しい設定を読み込む。
問:
インストーラーは「Relation RHQ_Principal does not exist」で PostgreSQL で失敗します。
答:
まず、JBoss ON サーバーインストーラーに PostgreSQL に接続するための適切なパーミッションがあることを確認します。PostgreSQL 設定ファイルを開き pg_hba.conf、パーミッションが有効になっていることを確認します。インストール用の PostgreSQL の設定に関する詳細は、『インストール 『ガイド』』 を参照してください。
問:
サーバーをアップグレードしましたが、インストーラーページに接続して設定しようとすると、引き続き(以前の) coregui/ モジュールにリダイレクトしようとします。インストーラーにアクセスする方法は?
答:
一部のブラウザーは、以前の coregui/ モジュールをキャッシュし、アップグレードした coregui/ モジュールがロードされていなくても、アップグレード後に自動的にリダイレクトを試みます。
インストーラーページに直接移動します。
http:/server.example.com:7080/installer/start.jsf
問:
ORA-01843 では、Oracle で JBoss ON インストールに失敗します。
答:
この問題は、Oracle が 4 月の省略形が APR ではないロケールで実行されると発生します。現在、以下の 2 つの回避策があります。
  • Oracle を別のロケールにします。
  • インストーラーを実行する前にサーバーディストリビューションファイルのいずれかを編集します。
    1. 古いサーバーディレクトリーを削除して、インストールパッケージを再度展開します。
    2. serverRoot/jon-server-3.3.0.GA/jbossas/server/default/rhq-installer.war/WEB-INF/classes ディレクトリーを開きます。
    3. 編集 db-data-combined.xml01-APR-08 形式の日付を、現在のロケールにあるように更新します。
    4. ファイルを保存します。
    5. インストーラーを再実行し、データベースの上書きを選択します。

A.3. ユーザーインターフェース

問:
自動検出されたリソースを無視するにはどうすればよいですか?
答:
エージェントが新規プラットフォームを検出し、インベントリーに使用したくないリソースを発見した場合は、サーバーにこれらのリソースを無視するように指示する必要があります。
まず、自動検出ポートレットでインポートするリソースを選択し、不要なリソースの選択を解除できます。ポートレットに表示されている限り、インポートされません。
または、インポートしないリソースを選択し Ignore、オンにすると、ポートレットには表示されなくなります。ただし、新しく検出されたプラットフォームのリソースでこれを試みると、失敗します。この理由により、インベントリーはプラットフォームを tree-root として使用してツリーのような構造で構成されています。サーバーまたはサービスがシステムに取得される場合(インポートまたは無視されているかどうかに関わらず)、その root の下にアタッチされます。プラットフォームがまだインベントリーにインポートされていない場合、無視されるリソースがに割り当てられるルートはありません。
以下の手順を実行して、プラットフォームでサーバーを無視できます。
  1. プラットフォームをインポートし、そのサーバーをオフのままにします。
  2. プラットフォームが正常にインポートされたら、サーバーを選択し、をクリックし Ignoreます。
プラットフォームだけを無視することはできません。プラットフォームを無視する場合は、エージェントを実行しないでください。
問:
リソース検索ボックスから検索の提案を選択しましたが、結果が得られませんでした。なぜですか?
答:
検索ドロップダウンの提案はカテゴリーごとにフィルターされませんが、検索結果 になります。たとえば、Server タブを使用している場合、CPU がサービスカテゴリーにある場合でも type==CPU、動的検索の提案が出力されます。選択した場合は type==CPU、検索結果がカテゴリーによってフィルターされ、検索が暗黙的にサーバーカテゴリーに設定されて いる ため、検索には何も返されません。
問:
GWT Message Center でエラーやスタックトレースが利用できないことがあります。実際の問題は何ですか?
答:
UI にエラーがある場合は、エラー ID が表示され、角括弧で囲まれます。これは、JBoss ON サーバーのログファイルでエラーおよびスタックトレースを追跡するために使用できます。例:
java.lang.RuntimeException:[1312480384219] ...
これらの例外はサーバー側で発生し、GWT クライアントに転送されるため、サーバー側のログ情報はより便利です。
問:
GUI の MONITOR タブのグラフおよびチャートが表示されるのはなぜですか?
答:
以下のようなエラーが JBoss ON サーバーログに表示されます。
java.lang.NoClassDefFoundError: Could not initialize class org..enterprise.gui.image.chart.ColumnChart
グラフおよびチャートでテキストを生成するには、Java では特定のシステムフォントをインストールする必要があります。必要なフォントパッケージがインストールされていない場合は、エラーメッセージが表示されます。Red Hat Enterprise Linux で、urw-fonts パッケージがインストールされていることを確認します。
yum install urw-fonts

A.4. server

問:
サーバーを起動すると、ログにサーブレットエラーが表示されます。What's wrong?
答:
サーバーが起動し、エージェントがすでに実行中の場合は、に関連してエラーが生じる可能性があります。 Servlet.service() ログに記録されるクラス:
22:55:35,319 ERROR [[ServerInvokerServlet]] Servlet.service() for servlet
ServerInvokerServlet threw exception
java.lang.reflect.UndeclaredThrowableException
        at $Proxy421.processRequest(Unknown Source)
        at
org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.processRequest(ServerInvokerServlet.java:128)
        at
org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.doPost(ServerInvokerServlet.java:157)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
... more ...
このエラーは正常で、起動時にサーバーがクラスをロードするシーケンスに関連します。リモーティングクラスは起動シーケンスの初期段階でロードされます。これは、サーバーが完全に開始する前にエージェントへの接続を試みることを意味します。これにより、ログに記録されるエラーが発生する可能性があります。これらのエラーは、サーバーが完全に起動すると削除されるはずです。
エラーは無視しても問題ありません。
問:
JBoss ON サーバーからデバッグメッセージを取得する方法
答:
serverRoot/jon-server-3.3.0.GA/jbossas/server/default/conf/jboss-log4j.xml 設定ファイルを編集して、のコメントを解除してデバッグメッセージを有効にすることができます。 org.rhq カテゴリー。これにより、DEBUG に設定されます。デバッグメッセージは、すべての JBoss ON サブシステムがログファイルに出力されます。デバッグメッセージを JBoss ON サーバー内部の小規模サブセットに対してのみ出力する場合は、コメントを解除して使用するカテゴリーを指定するか、独自のカテゴリーを追加することもできます。
log4j.xml コメントを含むコメントアウトされたカテゴリーには、特定のカテゴリーから期待されるデバッグメッセージのタイプを簡単に説明します。JBoss/Remoting や Hibernate などのサードパーティーサブシステムのデバッグメッセージを出力することもできます。これらの一部はすでににコメントアウトされてい log4j.xmlます。
ファイルを変更したら、log4j.xml ファイルを保存し、JBoss ON サーバーを再起動します。
serverRoot/jon-server-3.3.0.GA/bin/rhq-server.sh|bat stop
serverRoot/jon-server-3.3.0.GA/bin/rhq-server.sh|bat start
デバッグメッセージはログファイルにあり serverRoot/jon-server-3.3.0.GA/logs/server.logます。
注記
デフォルトでは、コンソールウィンドウにはデバッグメッセージは表示されません。これは、log4j CONSOLE アペンダーにしきい値があるためです。 INFO.デバッグメッセージがコンソールにも表示されるようにするには、CONSOLE アペンダーのしきい値設定をに変更します。 DEBUG.
場合によっては、JBoss ON サーバーランチャースクリプトからデバッグメッセージが必要な場合もあります。これには、環境変数を設定する必要があります。 RHQ_SERVER_DEBUG 任意の値を設定します。ランチャーの開始時にこの変数を設定すると、スクリプトはデバッグメッセージを出力します。
問:
サーバーの JVM のコマンドラインオプションを指定する方法
答:
Red Hat Enterprise Linux では、デフォルトの最大ヒープサイズと permgen サイズを上書きし、を使用して設定します。 RHQ_SERVER_JAVA_OPTS 環境変数。例:
 
RHQ_SERVER_JAVA_OPTS="-Dapp.name=rhq-server -Xms256M -Xmx1024M          
-XX:PermSize=128M -XX:MaxPermSize=256M     
-Djava.net.preferIPv4Stack= true" 
 export RHQ_SERVER_JAVA_OPTS


からその他すべての JVM オプションを設定します。 RHQ_SERVER_ADDITIONAL_JAVA_OPTS 環境変数。例:
 RHQ_SERVER_ADDITIONAL_JAVA_OPTS= "-Dfoo= true" 
 export RHQ_SERVER_ADDITIONAL_JAVA_OPTS

Windows では、他のすべての JVM オプションで wrapper.java.additional.n 行を追加します <server-install-dir>\bin\wrapper\rhq-server-wrapper.inc (ファイルの作成が必要になる場合があります)。例:
  • wrapper.java.additional.12=-verbosegc:file=gc-log.txt
  • wrapper.java.additional.13=-XX:+HeapDumpOnOutOfMemoryError
  • wrapper.java.additional.14=-XX:HeapDumpPath=heap-dump.txt
問:
すべてのデータのスキーマをどのようにパージするか?
答:
すべてのデータのデータベーススキーマを完全にパージする必要があるインスタンスがあります。これは、カスタムプラグインを作成し、多くのリソース階層情報やメタデータを置き換える必要がある場合に便利です。データベースからすべてのデータを削除し、スキーマをそのままにするには、サーバーを再インストールします。
  1. 現在の JBoss ON サーバーディレクトリーを保存します。
    mv jon-server-3.3.0.GA/ jon-server-3.3.0.GA.bak/
  2. 最新の JBoss ON バイナリーを展開します。
    unzip jon-server-3.3.0.GA.zip
  3. 新しいサーバープロセスを開始します。
    serverRoot/jon-server-3.3.0.GA/bin/rhqctl.sh start
  4. JBoss ON GUI を開き、インストール設定を行います。選択可能な場合は、のオプションを選択し Overwrite existing dataます。これにより、サーバーの以前のインストール用のデータがすべて削除されます。
問:
JDBC アクセスおよびトレース SQL をデバッグする方法
答:
log4jdbc を使用して JDBC およびアクセスおよびトレース SQL をデバッグできます。
問:
サーバーの email/SMTP 設定が正しいことを確認するにはどうすればよいですか?
答:
サーバーが正常に電子メールを送信できることを確認するには、rhqadmin ユーザーとして GUI にログインして、メールテストページを開きます。
http://server.example.com:7080/coregui/#Test/
問:
サーバーマシンには /var/run という書き込み可能なディレクトリーがありません。rhq-server.sh スクリプトを取得して、その pid ファイルを正常に書き込みするにはどうすればよいですか?
答:
環境変数の設定 RHQ_SERVER_PIDFILE_DIR pid ファイルを保存するディレクトリーのフルパスを設定します。スクリプトを実行すると、その変数の値がデフォルトの場所を上書きします。2.1 またはそれ以前のスクリプトがある場合は、直接編集して rhq-server.sh、希望のディレクトリー /var/run に切り替えます。
問:
サーバーを起動しようとすると、「Exception created identity」で例外が発生し、サーバーは起動に失敗します。どうすればよいですか?
答:
参照しているメッセージは、以下のようになります。
Caused by: java.lang.RuntimeException: Exception creating identity: my.host.name.com: my.host.name.com
|         at org.jboss.remoting.ident.Identity.get(Identity.java:211)
これは JBoss ON 固有のものです。これは、JBoss/Remoting 通信の失敗によって生じます。通常、コアの問題はホスト名が解決できないためです。JBoss/Remoting は実際のエラーメッセージを生成しないため、通常はこの問題がユーザーに非表示になります。このエラーは、通常、マシンのホスト名が外部で解決できないことを示しています。JBoss ON が正常に機能するには、すべてのサーバーおよびエージェントが相互のホスト名を解決できる必要があります。ベストプラクティスは、ホストファイル(例: /etc/hosts)を使用してすべてのサーバーおよびエージェントのマッピングを維持することです。これにより、DNS が失敗しても JBoss ON が正常に機能し続けます。ただし、ホストファイルの使用は、お使いの環境では実用的ではない場合があります。この場合、JBoss ON インストールを開始する前に時間がかかる必要があります。これにより、JBoss ON を実行する予定の各ホストが、nslookup などのツールを使用して計画された環境にある他のすべてのホスト名を適切に解決できることを確認してください。
注記
サーバーおよびエージェントが特定の機能に対してホストルックアップを実行するため、この設定は、設定された値に排他的に IP アドレスを使用している場合でも適用されます。
問:
サーバーログに「Have not packet from agent ...」というメッセージが表示されます。ダウンしていると疑われるため、バックフィルが行われます。 意味は?
答:
[org.rhq.enterprise.server.core.AgentManagerBean] Have not heard from agent [agent_name]
since [timestamp]. Will be backfilled since we suspect it is down

つまり、エージェントは利用可能なレポートを必要な時間に送信しませんでした。デフォルトは 2 分ですが、Administration > System Configuration > Settings ページで設定することができます。必要な時間で可用性レポートが送信されない場合、サーバーはエージェントがダウンしていることを前提とします。この時点で、そのエージェントによって管理されるすべてのリソースの可用性が DOWN にバックバックされ、リソースの可用性は red になります。
これは、以下のような理由により発生する可能性があります。
  1. エージェントは実際にシャットダウンまたはクラッシュした。
  2. エージェントがシャットダウンまたはクラッシュしているマシン。
  3. エージェントとサーバー間のネットワークがダウンし、エージェントがサーバーに接続し、可用性レポートを送信することを禁止していました。
  4. エージェントが実行しているマシンは偽装されるため、エージェントの速度が遅くなり、エージェントが十分な速度でレポートを送信できないようにします。
問:
サーバーとエージェント間でファイアウォールを設定する際に考慮すべきポートは何ですか?
答:
注記
デフォルトはデフォルト値です。JBoss ON サーバーまたはエージェントのインストール時に異なる値を設定できます。
デフォルトのサーバーポートは、7080(標準)および 7443(セキュアな SSL)です。
標準接続とセキュアな接続の両方で、デフォルトのエージェントポートは 16163 です。
また、サーバーはデータベースと通信する必要があります。デフォルトのポートは、データベースの種類によって異なります。
問:
サーバーを Windows サービスとしてインストールしましたが、エラーメッセージなしで起動できません。サーバーを Windows サービスとして起動するにはどうすればよいですか?
答:
ローカルシステムアカウントとして実行するようにサーバーをインストールし、そのアカウントにはセキュリティー上の懸念があるため、サーバーまたはマシンを実行するための適切なパーミッションがない可能性があり、ローカルシステムアカウントがネットワークにアクセスできない、または Java を実行できないことが原因です。
これに対応するには、サーバーを適切に実行できるユーザーを Windows ボックスに作成します。ユーザー権限をテストするには、ユーザーとしてログインし、そのユーザーが実行できるかどうかを rhq-server.bat console 確認します。次に、サーバーを、で Windows サービスとしてインストールします。 RHQ_SERVER_RUN_AS_ME 環境変数がに設定されます。 true:
rhq-server.bat remove
set RHQ_SERVER_RUN_AS_ME=true
rhq-server.bat install

問:
Oracle── の使用時に ORA-12519, TNS:no appropriate service handler found error を修正するにはどうすればよいですか?
答:
本番環境では Oracle── はサポートされませんが、テスト環境または開発環境に使用するものもあります。ORA-12519 エラーを停止するには、この設定を設定します
ALTER SYSTEM SET PROCESSES=150 SCOPE=SPFILE;
。これにより、Oracle── データベースを再起動します。
問:
サーバーログまたはスタックトレースにこのエラーが表示 されています: WARN [QueryTranslatorImpl] firstResult/maxResults with collection fetch; apply in memory.その意味と原因は何ですか?
答:
このエラーは Hibernate サービスによって発行され、さまざまな理由でトリガーされる可能性があります。このエラーは無視できます。
問:
「同一の論理プラグイン」と「異なるコンテンツ」および「非推奨とみなされる」というメッセージをサーバーが定期的にログに記録しないようにするにはどうしたらよいですか?
答:
Bugzilla 676073 の既知の問題です。これを回避するには、サーバーをシャットダウンし、サーバーのファイルシステムからプラグイン jar を削除し、サーバーを再起動します。
問:
JBoss ON の LDAP ユーザー認証と LDAP グループ承認の違い
答:
認証 は、リソースにアクセスしようとしているエンティティーが要求するアイデンティティーであることを確認するのに使用されるプロセスです。承認 とは、エンティティーがリソースにアクセスするために必要な権限を決定するプロセスのことです。という名前のユーザー jsmith が JBoss ON にログインしようとしているとします。認証は、ログインを jsmith 試行するプロセスで、JBoss ON がデータベースに存在する jsmith ユーザーと同じです。これは、パスワードを検証することで検証できます。jsmith ログインしたら、JBoss ON は、これらのリソースの設定の編集、新しいアプリケーションのプロビジョニング、サーバー設定の変更、JBoss ON でその他のタスクを表示 jsmith できるリソースを決定します。
通常、JBoss ON は独自のユーザーデータベースを使用してユーザーを識別し、認証します。最初に JBoss ON にユーザー情報について LDAP サーバーを確認し、そのユーザーのベースで有効な JBoss ON ユーザーのベースを使用すると、LDAP 認証を有効にすることができます。これは LDAP 認証 です。これは基本的にパススルー認証です。ユーザーが JBoss ON へのログインを試行します。JBoss ON は最初に認証情報を LDAP サーバーに送信して、LDAP サーバーがそのユーザーを保存しているかどうかを確認します。LDAP サーバーで認証に失敗した場合、JBoss ON は独自のデータベースをチェックします。
JBoss ON のすべての承認はロールに基づきます。ユーザーとリソースグループの両方がロールに追加され、パーミッションはそれらのロールに割り当てられます。これらのロールは JBoss ON で作成および管理されますが、LDAP グループのグループメンバーシップを使用して JBoss ON ロールにユーザーを提供することは可能です。基本的には LDAP 内の既存のユーザーのリストを取り、「ロールメンバーにこのリストを使用」とだけます。 LDAP グループが JBoss ON ロールに追加され、その LDAP グループのすべてのメンバーは自動的にロール権限を持つ権限を持ちます。これは LDAP 承認 です。
注記
LDAP 認証は LDAP 認証に推奨されますが、必須ではありません。
詳細はを参照してください 10章認証および承認用の LDAP サービスの統合
問:
LDAP グループ承認を設定するにはどうすればよいですか?
答:
以下で、LDAP 認証が Administration タブで設定され System Settingsます。
最初に JBoss ON を設定し、LDAP ユーザーが LDAP ユーザーアカウントを使用して認証できるようにします(「LDAP ユーザー認証の設定」)。(LDAP 認証は必要ありませんが、推奨されます。) その後、JBoss ON を LDAP サーバーの LDAP グループを確認するように設定します(「LDAP ユーザーグループを JBoss ON のロールに関連付ける」)。
LDAP サーバー設定には、LDAP グループ承認の設定を確認する必要がある要素が 5 つあります。
  • LDAP URL の形式で LDAP サーバーに接続する情報。たとえば、ldap://server.example.com:1389 など です
  • サーバーへの接続に使用するユーザー名およびパスワード。このアカウントには、検索対象のサブツリーへの読み取りアクセスが必要です。
  • 検索ベース。これは、エントリーを検索するディレクトリーツリー内のポイントです。これには、パフォーマンスを向上させ、不要なアクセスを防ぐのに十分なエントリーを含めて、すべてのエントリーを含めることができるはずです。たとえば、JBoss ON の両方のサブツリーに ou=Web Team,dc=example,dc=com ou=Engineering,dc=example,dc=com およびとある場合、検索ベースをツリー上に設定し dc=example,dc=comます。エンジニアリンググループを JBoss ON が使用する場合のみ使用する場合は、検索ベースをに設定し ou=Engineering,dc=example,dc=comます。
  • グループフィルター。これにより、グループエントリーの検索に使用する検索フィルターが作成されます。これは、グループオブジェクトクラスを使用できます。これは、JBoss ON 関連のエントリーにカスタム属性がある場合に特に便利です。また、グループ名、ローカリティー、エントリーの説明にある文字列などの他の要素を参照することもできます。これは、JBoss ON 関連グループを特定するのに有用または意味のあるものです。
  • member 属性。グループオブジェクトクラスにはさまざまなタイプがあり、ほとんどの属性を使用してグループメンバーを特定します。たとえば、groupOfUniqueNames オブジェクトクラスは uniqueMember 属性を持つメンバーを一覧表示します。
LDAP 承認を有効にしたら、JBoss ON のロールを LDAP ディレクトリーの適切なグループに関連付けることができます。

A.5. エージェント

問:
共有ディスクリソースを持つ複数の仮想マシンをホストする物理マシンがあります。各仮想インスタンスでエージェントを実行する方法
答:
同じボックスで複数のエージェントを実行できますが、エージェントは 2 つの異なるエージェントのインストールディレクトリーから実行する必要があります。
問:
JBoss ON エージェントからデバッグメッセージを取得する方法
答:
JBoss ON エージェントを起動する前に、エージェントがデバッグメッセージのロギングを開始する最も簡単な方法で、環境変数を設定する方法が最も簡単です。 RHQ_AGENT_DEBUG 任意の値を設定します。エージェントを起動すると、ランチャースクリプトとエージェント自体の両方がデバッグメッセージを出力します。この環境変数を使用すると、エージェントは内部 log4j 設定ファイルを使用します。
どの log4j カテゴリーに DEBUG 優先順位があるかをより詳細に制御するには、conf/log4j.xml ファイルを編集してエージェントを再起動して変更を読み込みます。未設定 RHQ_AGENT_DEBUG エージェントが log4j.xml ファイルを使用し、その環境変数を設定する log4j.xml と、内部的に設定された log4j 設定でエージェントが上書きされます。
ログメッセージは agentRoot/rhq-agent/logs ディレクトリーにあるログファイルにあります。
サービスラッパーを使用して Microsoft Windows で JBoss ON エージェントを起動する場合は、設定する必要があります。 RHQ_AGENT_DEBUG サービスをインストールします。
rhq-agent-wrapper.bat install

問:
サーバーへの接続が許可されているエージェントを制限するにはどうすればよいですか?
答:
サーバーの JBoss/Remoting サーブレット設定を変更して、IPs エージェントのリクエストを制限します。エージェントが特定のサブネットにある場合は、接続をそのサブネットに制限できます。
  1. 以下の名前と場所を使用して、制限ルールのファイルを作成します。
    vim serverInstallDir/jbossas/server/default/deploy/rhq.ear/jboss-remoting-servlet-invoker-2x.r3040.jon.war/WEB-INF/context.xml
  2. このコンテンツをファイルに追加します。
     
    <Context> 
    <Valve className="org.apache.catalina.valves.RemoteAddrValve" 
    allow="192.168.*,142.104.128.*,10.224.27.182"/> 
    </Context>
    allow= 属性は、サーバーへの接続が許可される IP の一覧です。その他の IP はすべてブロックされます。
問:
root でエージェントを実行する必要がありますか?
答:
root でエージェントを実行する必要はありません。
ただし、一部のリソースタイプには、ユーザーが設定ファイルやプロセスにアクセスできる項目に非常に厳格な制限があり、root としてエージェントを実行することが、これらのリソースを管理または監視する唯一の方法になります。
たとえば、PostgreSQL プラグインを使用すると、エージェントは PostgreSQL 設定ファイルをプローブでき postgres.confます。PostgreSQL 権限のない root 以外のユーザーとしてエージェントを実行すると、エージェントはファイルの読み取りおよび管理ができません。(また、エージェントログにはこのようなログメッセージがあります)。 iptables や一部の JBoss サーバーなど、同様の特権ファイルを持つ他のリソースがあります。
エージェントを root として実行すると、これらを管理するエージェント権限が付与されます。その権限レベルがない場合、エージェントには管理リソースのビューが制限されます。
問:
JBoss ON エージェントを新たにインストールしたかのようにクリーンアップするにはどうすればよいですか?
答:
エージェントの設定には、エージェントの(ローカル)永続設定、エージェントインベントリー(および関連するリソースデータ)、およびサーバーインベントリーのプラットフォームエントリーの 3 つの点があります。
エージェント設定をクリーンアップし、新規であるかのようにエージェントを再起動するには、以下の 2 つの手順を実行します。
  1. JBoss ON サーバーインベントリーから platform エントリーを削除します。プラットフォームエントリーは agent エントリーの代表であるため、実際には JBoss ON トポロジーからエージェントが削除されます。
  2. エージェントを停止し、--fullcleanconfig (-L) コマンドラインオプションを使用して再起動します。
    agentRoot/rhq-agent/bin/rhq-agent.sh --fullcleanconfig
    --fullcleanconfig オプションは、エージェントのローカルインベントリーをすべて削除し、agent-configuration.xml ファイルから新しい設定を再読み込みし、サーバーでエージェントを再登録します。
    必要に応じて、--config 引数を渡して、ユーザーが指定した設定ファイルで起動できるようにします。それ以外の場合は、デフォルトの conf/agent-configuration.xml ファイルが使用されます。ディレクトリーが指定されていない場合は、コマンドでエージェントの conf/ ディレクトリー内の設定ファイルを検索します。
    agentRoot/rhq-agent/bin/rhq-agent.sh --fullcleanconfig -c my-agent-configuration.xml
問:
バックグラウンドの Windows サービスとして実行中のエージェントの「clean config」を実行する方法
答:
JBoss ON エージェントの Windows サービス(すべての Windows サービスなど)は特定のユーザーとして実行されます。そのユーザーの Windows レジストリーに移動し、エージェントの設定ノードを削除します。RHQ Agent は標準の Java Preferences API を使用して、エージェントの設定は Windows レジストリーの通常の Java Preferences の場所(HKEY_CURRENT_USER\Software\JavaSoft\Prefs\rhq-agent\default など)のノードとして保存されます。("default" は preferences ノードの名前です)。
ノードを削除すると、以前の設定のみが削除されます。エージェントを再度起動する前にエージェントを再設定する必要があります。最も簡単なパスは、フォアグラウンドでエージェントを起動し、インタラクティブなエージェント設定を確認してから、そのセッションを停止し、サービスとしてエージェントを起動します。
エージェントは、agent-configuration.xml ファイルから設定を読み取るように強制できます。エージェントがファイルから設定を再読み込みするよう強制するには、フォアグラウンドで起動できないため、再設定がより困難になります。
エージェントが JBoss ON リソースとして追加された場合は、「Execute Command prompt」操作を実行して config --import agent-configuration.xml コマンドを実行します。
3 番目のパラメーターに rhq-agent-wrapper.conf ファイルを編集し、行を追加することができます。
wrapper.app.parameter.3=--cleanconfig
これにより、サービスとして起動される agent-configuration.xml たびにエージェントの設定を再読み込みします。この場合、エージェントに必要な(およびオプション)の設定をすべて事前に設定し、正しい設定で再起動するように agent-configuration.xml する必要があります。
問:
すべてのエージェントでプラグインを更新するにはどうすればよいですか?
答:
新しいプラグインをシステムに追加する場合や、既存のプラグインをアップグレードする場合は、エージェントに新しいプラグインバージョンで既存のプラグインを更新するように指示することができます。
この操作は、エージェントプロンプト plugins update で prompt コマンドを個別に実行するか、エージェントの OPERATION タブ内の Update All Plugins タスクを使用して UI で実行できます。
すべてのエージェントを最新のプラグインで更新するには、JBoss ON エージェントの autogroup でグループ操作を実行します。まず、Browse Resources ページに移動して自動グループを作成します。その後、Group Definitions> New Definition ボタンをクリックします。autogroup 定義には、以下の式が必要です。
resource.resourceType.pluginName = RHQAgent
resource.resourceType.typeName = RHQ Agent

これにより、すべての JBoss ON エージェントをメンバーとして動的に追加する互換性のあるグループが作成されます。
注記
すでにエージェントと、メンバーとして互換性のあるグループがある場合には、このグループの作成ステップを省略できます。
次に、agent グループに移動します。OPERATIONS タブで Update All Plugins 操作を呼び出します。これは、そのグループ内のすべてのエージェントがプラグインを更新するように指示します。グループ操作が完了すると、すべてのエージェントに最新のすべてのプラグインが含まれます。
問:
登録後にエージェント名を変更するにはどうすればよいですか?
答:
エージェントを初めて起動すると、エージェント名の設定画面で尋ねられます。この名前は、環境内のすべてのエージェントで一意でなければなりません。登録後、この名前は変更できません。このエージェントの再登録を試みる場合は、前のステップで登録した名前と同じ名前で再登録する必要があります。
エージェント名は、UI の JBoss ON エージェントリソース名とは異なります。JBoss ON エージェントリソースをインベントリーにインポートする場合、そのリソースの名前は agent_name JON エージェントになります。この JBoss ON エージェントリソース名は、INVENTORY タブ内で値を編集して変更できます。この名前を変更しても、エージェントが登録されている名前は変更されません。エージェントは、元のエージェント名で登録されています。
問:
すべてのマシンでエージェントを実行したいが、正常に起動するのは 1 つだけです。残りのアドレスは正しくないアドレスにバインドされるため失敗します。
答:
このエラーが発生する可能性がある事項がいくつかあります。
FATAL [main] (org.jboss.on.agent.AgentMain)-
{AgentMain.startup-error}The agent encountered an error during startup
and must abort java.net.BindException: Cannot assign requested address


まず、エージェントの設定 agent-configuration.xml 手動で変更になりましたか?(例: IP アドレスの変更)。エージェントの設定 XML ファイルは、Java Preferences を使用して永続化されるため、エージェントの設定後に参照され ません。設定を保持すると、設定が失われずにエージェントを更新または再インストールできます。エージェントの設定ファイルを変更し、それらの変更を取得するに -c は、エージェントを再起動して、--config コマンドラインオプション(または短所 --config)を渡します。これにより、エージェントは設定ファイルを再読み込みし、以前永続化した古い設定をオーバーライドするように指示します。
ホームディレクトリーが NFS に保存されている場合は、すべてのマシン(Red Hat Enterprise Linux)で同じ Java 設定$HOME/.java を選択することになります。Java 設定はレジストリーに保存されるため、通常は Windows では問題ありません。エージェントをユーザーと同じユーザーとして実行し、ユーザーのホームディレクトリーを共有している場合は、エージェントが異なる Java 設定名を使用します。エージェントの agent-configuration.xml ファイルを編集し、Java プリファレンスノード名を次のように変更します。 デフォルト すべてのエージェントで一意となるものにすることができます。例:
<node name="NewName">


デフォルトの場所を上書きするため、エージェントを起動するたびに、設定が見つかる場所をエージェントに指示する必要があります。--pref オプションを使用して、エージェントに新しい優先順位を指示します。設定ファイルを変更したら、でエージェントを再起動して設定ファイル -c を指定します。
agentRoot/rhq-agent/bin/rhq-agent.sh --pref NewName -c agent-configuration.xml

したがって、--pref オプションを使用してエージェントを再起動して、ノード名を渡すようにします。
スコープ、システムプロパティーを定義します。 java.util.prefs.userRoot 別の一意の場所をポイントします。エージェントが起動すると、Java はそのシステムプロパティーの値を Java Preferences を格納する場所として使用します。このシステムプロパティーは、に設定して、エージェントに設定できます。 RHQ_AGENT_ADDITIONAL_JAVA_OPTS 環境変数。その環境変数を設定すると、エージェントの Java 仮想マシンにオプションを渡すと、デフォルトの Java オプションに値が rhq-agent.sh 追加されます。
set RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Djava.util.prefs.userRoot=/etc/rhq-agent-prefs"
agentRoot/rhq-agent/bin/rhq-agent.sh

問:
Windows サービス経由でエージェントを起動すると、エージェントが起動しなくなり、エージェントラッパーログファイルで「java.lang.IllegalStateException: The name of this agent is not defined - you cannot start the agent」というエラーが表示されます。意味は?
答:
Windows サービスとしてインストールする際に、エージェントは初期セットアップの設定を要求できません。ユーザーがプロンプトを表示および応答するコンソールがないためです。つまり、事前に設定されたファイルで情報を渡すか、またはサービスとしてサービスとしてインストールする前に、サービスを実行するユーザーとして、標準(サービス以外の)モードでエージェントを実行する必要があります。
問:
エージェントのセットアップは適切ですが、エージェントは「Cause: org.jboss.remoting.CannotConnectException: Can not connect http client invoker」というメッセージが表示されます。
答:
このエラーは、通常、サーバーのエンドポイントアドレスがエージェントによって解決できるものに設定されていない場合に表示されます。JBoss ON サーバーの高可用性クラウド設定が原因で、各サーバーのパブリックエンドポイントアドレスはすべての JBoss ON エージェントによって解決可能である 必要 があります。
GUI の高可用性ページでサーバーエンドポイントの情報を確認し、必要に応じて設定を変更します。更新後、エージェントを再起動します。
問:
使用しているエージェントマシンには、という書き込み可能なディレクトリーがありません /var/run。rhq-agent-wrapper.sh スクリプトを取得して、pid ファイルを正常に書き込みするにはどうすればよいですか?
答:
環境変数の設定 RHQ_AGENT_PIDFILE_DIR pid ファイルを保存するディレクトリーのフルパスを設定します。スクリプトを実行すると、その変数の値がデフォルトの場所を上書きします。古いスクリプト(2.1 以前)がある場合は、直接編集して rhq-agent-wrapper.sh、希望のディレクトリー /var/run に切り替えます。
問:
エージェントがリソースをスキャンする頻度。
答:
エージェントがインストールされると、そのプラットフォームおよびそれにあるすべてのアプリケーション(サーバー、サービス、またはインベントリーに追加できるその他の項目)が スキャン されます。潜在的なリソースを検索するプロセスは 検出 です。
リソースのタイプ(プラットフォーム、サーバー、およびサービス)には、さまざまなスキャンがあります。サーバーおよびプラットフォームの高度なスキャンは、エージェントが 15 分ごとに開始します。サービススキャンは、インベントリーにすでにインポートされているサーバーで実行されている低レベルのサービスを検出します。これらのスキャンは、デフォルトで 24 時間ごとに実行されます。これらの間隔はいずれも設定可能です。
注記
検出スキャンで子プロセス、サーバー、またはサービスを検出する前に、サーバーをインベントリーにインポートする必要があります。
問:
エージェントの永続化設定を表示するにはどうすればよいですか?
答:
エージェントの設定は、最初にエージェントの設定で指定さ agent-configuration.xml れている値で読み取られ、上書きされます。エージェントを最初に設定した後は、その設定が永続化され、設定をクリアしない限り agent-configuration.xml、その設定に再び参照されることはありません。
エージェントの永続化設定を表示する方法は複数あります。
  1. エージェントが JBoss ON インベントリーにある場合は、エージェントの Configuration タブに移動し、ライブ設定を表示します。これは永続する設定と同じです。
  2. エージェントがデーモン以外のモードで実行されている場合は(たとえば、コンソールにエージェントプロンプトがある場合は)、getconfig または config prompt コマンドを使用してライブ設定を表示できます。詳細は help getconfig、または help config を入力します。
  3. エージェントが JBoss ON インベントリーにある場合は、Execute Prompt Command 操作を実行し、getconfig prompt コマンドを実行します。
  4. エージェント設定は標準の Java Preferences API バッキングストアに保存されるため、Google の Java Preferences Tool などの Java 設定を調べることのできるツールを使用できます。これは、ファイルシステムのような表示を Java 設定に提供できる GUI ツールです。エージェントの設定は、ノード名の User preferences ノードに保存され rhq-agentます。起動時にノード名のエージェントに渡される -p オプションに応じて、実際の構成設定は、以下のサブノードの下にあります。 rhq-agent.デフォルトの設定ノードが呼び出されます。 デフォルトしたがって、通常、エージェントの永続化された設定は、以下のユーザー設定にあり rhq-agent/defaultます。
警告
サードパーティーツールを使用する優先順位の値を変更せずに、サードパーティーツールの値を変更しないでください。誤った優先度を誤った値に変更すると、これによりエージェントが無効になる可能性があります。このメカニズムは、エージェントの設定を表示する場合にのみ使用します。
問:
エージェントの JVM プロセスに設定された環境変数と Java システムプロパティーを確認するにはどうすればよいですか?
答:
version agent prompt コマンドは、エージェントプロセスの環境変数およびシステムプロパティーの一覧を表示します。は、すべてのシステムプロパティーの version --sysprops 一覧を version --env 提供し、すべての環境変数の一覧を提供します。(エージェントプロンプトで、そのコマンドの構文 help version を確認します。)
問:
別のマシンで実行しているエージェントからインベントリー情報をダンプするにはどうすればよいですか?
答:
エージェントインベントリーが破損すると、エージェントのインベントリーをダンプすると、問題のデバッグに役立ちます。
この情報を取得するには、エージェントの data/inventory.dat ファイルを取得します。そのファイルをローカルマシンにコピーします。次に、他のエージェントと同じプラグインを使用して、ローカルマシンでエージェントを実行します。エージェントは必ずしもサーバーに接続する必要はなく、プラグインコンテナーを起動する必要があるため、エージェントが登録されている必要があります。次に、インポートされた DAT ファイルから情報をエクスポートします。
inventory --xml --export=/bad-inventory.xml /the/bad/inventory.dat
この --export オプションを指定しないと、XML は単に stdout コンソールウィンドウにダンプされます。
これで、お客様エージェントがそのインベントリーであることを記述した XML ファイルが作成されます。
問:
エージェントマシンの IP アドレスを変更する必要があります。この変更でサーバーとエージェントを最新の状態に維持するにはどうすればよいですか?
答:
エージェントには設定優先順位があり、サーバーソケットの開始時にエージェントがバインドする IP アドレスの rhq.communications.connector.bind-address 値を設定します(サーバーから受信メッセージをリッスンします)。
エージェントの IP アドレスを変更し(古いエージェントの IP アドレスを無効にした場合)、以下の操作を行う必要があります。
  1. 優先順位が新しい IP アドレスと同じになるように、エージェントの設定を変更します。agent プロンプトで setconfig prompt コマンドを実行します。
    setconfig rhq.communications.connector.bind-address=IP_address
    Do not change agent-configuration.xml。変更は反映されません。
    エージェントがバックグラウンドでデーモンプロセスとして実行している場合は、スクリプト(rhq-agent-wrapper.sh|bat)を使用してシャットダウンし、再起動します。
  2. 設定の編集後にエージェントを再起動します。
エージェントを再起動すると、その新規 IP アドレスが使用されます。
問:
サーバーが稼働状態のままになったときに、サーバーが稼働し続けることをエージェントが停止するにはどうすればよいですか?
答:
エージェントログに以下のようなエラーが表示される可能性があります。
INFO (org.rhq.enterprise.agent.AgentAutoDiscoveryListener)- {AgentAutoDiscoveryListener.server-offline}
The Agent has auto-detected the Server going offline [InvokerLocator
[servlet://server:7080/jboss-remoting-servlet-invoker
/ServerInvokerServlet?rhq.communications.connector.rhqtype=server]] -
the agent will stop sending new messages 
...
INFO (org.rhq.enterprise.agent.AgentAutoDiscoveryListener)- {AgentAutoDiscoveryListener.server-online}
The Agent has auto-detected the Server coming online [InvokerLocator
[servlet://server:7080/jboss-remoting-servlet-invoker
/ServerInvokerServlet?rhq.communications.connector.rhqtype=server]] -
the agent will be able to start sending messages now
つまり、エージェントは自動検出され、マルチキャスト検出を介してサーバーがダウンしてからバックアップされます。これは、エージェントがサーバーのステータスの検出を試みる 2 番目の方法である discovery-via-polling とは異なります。
エージェントが稼働中またはダウンしたサーバーを正しく検出している場合は、ネットワークがマルチキャストトラフィックに対応していないか、マルチキャストネットワークが異常に動作している可能性があります。いずれの場合も、エージェントマルチキャスト検出を無効にし、代わりにポーリングに依存してサーバーステータスの変更を検出します。
マルチキャスト検出を無効にするには、以下のエージェント設定を false に設定します。
  • rhq.agent.server-auto-detection
  • rhq.communications.multicast-detector.enabled
マルチキャスト検出を無効にするため、ポーリング検出機能が有効になっていることを確認してください。つまり、rhq.agent.client.server-polling-interval-msecs 値が 0(通常は 60000)よりも大きくなります。それ以外の場合は、エージェントはサーバーがダウンしたタイミングを認識できません。
エージェントを再設定したら、通信サブシステムが変更を検出できるようにエージェントを再起動します。

A.6. ログメッセージ

問:
「Command failed to be authenticated」メッセージとは
答:
エージェントには、最初にサーバーに登録する際にセキュリティートークンが割り当てられます。トークンは、エージェントがサーバーとともに自己識別する方法です。エージェントがトークンで自身を識別しない場合や、誤ったトークンで自身を特定すると、サーバーはそのエージェントへのアクセスを拒否します。このため、サーバーは、エージェントが適切に登録されるまで、そのエージェントからのコマンドを拒否します。
02:31:33,095 WARN  [CommandProcessor] {CommandProcessor.failed-authentication}
Command failed to be authenticated! This command will be ignored and not processed:
Command: type=[identify]; cmd-in-response=[false]; config=[{}]; params=[null]
通常、認証エラーの失敗 は、エージェントの設定が間違っていること、または別のエージェントとして自身を識別しようとする未知のエージェントであることを意味します。--cleanconfig コマンドラインオプションを使用してエージェントを再起動して、その設定をクリーンアップし、再登録します。
注記
JBoss ON 環境を侵入から保護する方法として、セキュリティートークンメカニズムに依存しないでください。エージェントサーバー通信用に SSL を設定します。
問:
「 fail-safe cleanup」メッセージとは?
答:
これらのメッセージは無視できます。これは、JBoss ON によって使用される Hibernate サービスと、メモリーリークを防ぐために、それ自体が自動的にクリーンアップされる方法に関連しています。
13:43:10,781 WARN [LoadContexts] fail-safe cleanup (collections) : 
org.hibernate.engine.loading.CollectionLoadContext@103583b 
<rs=org.postgresql.jdbc3.Jdbc3ResultSet@d16f5b>

A.7. サーバーおよびエージェントプラグイン

問:
JBoss ON の拡張方法
答:
他の外部プロジェクトやカスタムアプリケーションをサポートするために、新しいプラグインを作成できます。
問:
JBoss ON のプラグインを作成するにはどうすればよいですか?
答:
エージェントおよびサーバープラグインの記述は、JBoss ON のドキュメントセットの『プラグインガイド 『』 で説明しています。
問:
スケルトンプラグインモジュールとは何ですか?
答:
カスタムプラグインの作成を開始するには、JBoss ON ソースコードで利用可能なテンプレートである custom-plug-in maven モジュールスケルトンから始まります。これには、定義された依存関係、リソースコンポーネントのスターターセット、および最小 rhq-plug-in.xml プラグイン記述子が含まれる Maven pom が含まれます。

A.8. 一般的なリソースに関する質問

問:
インベントリーからプラットフォームを削除しました。再検出するにはどうすればよいですか?
答:
エージェントのコマンドプロンプトで以下のコマンドを実行して、エージェントの検出を強制できます。
> discovery -f
問:
Red Hat Enterprise Linux プラットフォームでは、インターフェース「sit0」が検出されますが、常に red になります。インベントリーからこのインターフェースを削除するにはどうすればよいですか?
答:
ネットワークアダプターは子サービスであるため、現時点で JBoss ON に無視するか、インベントリー化しないように指示することはできません。
ただし、マシン自体でこのインターフェースを簡単に無効にする方法はあります。このボックスへの root または sudo アクセスがある場合は、IPv6 サポートをすべて無効にします。
NETWORKING_IPV6 値を /etc/sysconfig/network以下のように変更します。
NETWORKING_IPV6=no
警告
このインターフェースを無効にすると、IPv6 サポートが無効になります。
次に、以下の行 /etc/modprobe.conf を追加します。
alias net-pf-10 off
alias ipv6 off
ipv6tables サービスを停止します。
service ip6tables stop
ipv6tables サービスを無効にします。
chkconfig ip6tables off
問:
syslog メッセージを JBoss ON イベントとして収集するにはどうすればよいですか?
答:
Linux プラットフォームプラグインは、syslog メッセージをイベントとして送信して監視できます。syslog メッセージは、syslog メッセージファイルを読み取るか、またはソケットリスナー経由でそれらを受信することでプラグインによって収集されます。
syslog は、JBoss ON が解析できる方法でメッセージをフォーマットするように設定する必要があります。JBoss ON(プラットフォームのプラグイン設定または接続プロパティー)に対して正規表現が syslog メッセージを解析できるか、または syslog 設定ファイル(/etc/rsyslog.conf)でメッセージをフォーマットして JBoss ON が理解できるようにします。例:
$template RHQfmt,"%timegenerated:::date-rfc3339%,%syslogpriority-text%,%syslogfacility-text%:%msg%\n"
この形式 RHQfmt でメッセージを書き出すために syslog 設定で使用する場合、JBoss ON はログメッセージを完全に理解します。例:
$template RHQfmt,"%timegenerated:::date-rfc3339%,%syslogpriority-text%,%syslogfacility-text%:%msg%\n"
*.* /var/log/messages-for-rhq;RHQfmt
*.* @@127.0.0.1:5514;RHQfmt
どちらも syslog メッセージに書き込み、プラットフォームの接続プロパティーで設定されるポート 5514 のリスナーに TCP 経由でメッセージを /var/log/messages-for-rhq 送信します。
問:
Red Hat Enterprise Linux では、スクリプトリソースの実行に失敗します。
答:
スクリプトリソースで Execute 操作を呼び出すと、スクリプトを実行できないことを示すエラーメッセージですぐに失敗します。スクリプト自体が実行可能であることを確認します。以下を実行するスクリプトを設定します。
chmod a+x scriptname

A.9. JBoss リソース

問:
すべての JNP クレデンシャルがリソースの接続プロパティーで適切に設定されていても、JBoss AS サーバーが緑色の可用性を示し、1 つの JBoss AS サーバーのみが緑色の状態で表示されるのはなぜですか?
答:
JBoss AS JNP クライアントの動作方法に問題があります。複数の JBoss AS サーバーを 1 つのボックスで管理する場合、これらのサーバーのセキュリティークレデンシャルはすべて同じである必要があります(例: JNP のユーザー名とパスワードは同じである必要があります)。
問:
JBoss EAP 5 や Tomcat などのサーバーをインポートする場合、インベントリー内に子 JVM リソースが表示されますが、これは Red(DOWN)になります。なぜですか?
答:
JMX リモーティングを有効にしてサーバーが セキュア化 された場合、適切な認証情報を検出できないため、エージェントは JMX サーバーに接続できません。
たとえば、JMX サーバーに以下のシステムプロパティーがある場合:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=5222
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=/jmxremote.access
エージェントの JMX プラグインは JMX サーバーのプロセスに対するコマンドラインを検査し、JMX サーバーがリモートおよびセキュアであることを確認し、セキュアでリモートの JMX コネクターを設定しようとします。エージェントには適切な認証情報がないため、リモート JMX MBean サーバーに接続できず、DOWN 状態にあることを前提とします。
リソースの Inventory タブでリソースのを編集 Connections Settingsし、JMX リモートアクセスファイルに設定した有効なユーザー名とパスワードを入力します。これにより、JBoss ON がリモート JMX エンドポイントを通過できるようになります。
JBoss ON は親リソースに接続し、それを使用して JMX サーバーに接続できます。この場合、Connection Settings サブタブで、プロパティー 以外 の接続プロパティーの設定 Type を解除し Parentます。JVM の親 JBoss EAP リソースは、JVM に接続するための情報を提供できます。
問:
JBoss EAP インスタンスの監視を試みると、「Connection failure Failed to authenticate principal=null, securityDomain=jmx-console」というエラーが表示されます。
答:
JBoss EAP の ドキュメントおよび JBoss EAP 4.3 ドキュメント で説明されているように、jmx-console はデフォルトでセキュア化されます。EAP のドキュメントに記載されているユーザー名とパスワードを定義します。その後、このユーザー名とパスワードを JBoss EAP インスタンスの Inventory> Configuration Properties ページの下に追加します。
注記
設定パラメーター(-c)を指定せずに JBoss EAP インスタンスを起動すると、実稼働設定でインスタンスが開始されます。
問:
JBoss AS インスタンスを監視する場合、その下には JVM リソースは表示されません。
答:
JBoss ON で JBoss AS リソースの JVM リソースを検出するには、対応する JBoss AS インスタンスが Java 5 以降を実行している必要があります。また、以下から開始する必要もあります。 jboss.platform.mbeanserver システムプロパティーが設定されている。たとえば、Red Hat Enterprise Linux では、この ${JBOSS_HOME}\bin\run.conf ファイルには以下の設定が必要です。
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
問:
JBoss AS 5.1 を監視できますか?
答:
いいえ。エージェントが検出しないように、JBoss AS 5.1 プロファイルサービスに問題があります。
JBoss EAP 5.0 以降のバージョンおよび JBoss AS 6.0 を監視できます。
問:
エージェントは JBoss サーバーを検出し、接続プロパティーを取得できますが、JNP 接続は失敗します。なぜですか?
答:
これは、などの pathname にスペースを持つディレクトリーにエージェントがインストールされている場合に、主に Windows で実行され C:\Program Filesます。
エージェントが JBoss サーバーを検出し、その接続プロパティーをすべて検索できる場合は、ログでプロファイルサービスへの接続に失敗したかどうかを確認します。
2012-01-12 15:03:38,982 DEBUG [ResourceContainer.invoker.daemon-1] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to connect to Profile Service.
java.lang.RuntimeException: Failed to lookup JNDI name 'ProfileService' from InitialContext.
 at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.lookup(AbstractProfileServiceConnectionProvider.java:84)

[snip]
エージェントを pathname に空白のないディレクトリーに移動し、JBoss リソースを再検出します。

A.10. Postgres リソース

問:
ユーザー「postgres」に対して認証に失敗したことに関する PostgreSQL 検出でエラーが表示されるのはなぜですか?
答:
Postgres プラグインは、Postgres のユーザー名とパスワードを使用してデータベースサーバーにログインしようとします。多くのインストールでは、これはデフォルトのスーパーユーザーであり、機能します。ただし、以下の複数の理由でこのログインが失敗する可能性もあります。
  • postgres ユーザーが削除されている。
  • postgres ユーザーのパスワードが変更になりました。
  • Linux では、管理ログインがに設定されてい ident sameuserます。
これを解決するには、以下を行います。
  • 検出された Postgres リソースをインベントリーします。この可用性はダウン状態になり、子リソースを見つけることはありません。
  • Postgres リソースの INVENTORY タブに移動します。
  • の下 Connection Propertiesにある Edit ボタンをクリックします。
  • Postgres インスタンスで有効なスーパーユーザーアカウントを反映するように、ロール名およびパスワードフィールドを変更します。
さらに、pg_hba.conf ファイルの設定を変更してパスワードベースのログインを許可するために、Red Hat Enterprise Linux システムで Postgres を変更する必要がある場合があります。
問:
なぜ Postgres リソースのメトリクスが NaN として表示されるのはなぜですか?
答:
多くのインストールでは、Postgres はデフォルトで統計コレクターを開始しません。統計収集を有効にするには、postgres.conf ファイルで以下の行を追加または変更します。
stats_start_collector = on
問:
Postgres データベースの監視に必要なデータベース接続の数
答:
JBoss ON に準拠する各 Postgres データベースには 1 つの接続が必要です。
問:
JBoss ON で永続化されているデータベースをドロップできないのはなぜですか?
答:
可用性および統計の監視頻度により、Postgres プラグインはデータベースへの接続を開放します。JBoss ON で現在使用されているデータベースを破棄しようとすると、使用中のデータベースに関するエラーが発生します。データベースをドロップするには、データベースを監視する JBoss ON エージェントまたはデータベースリソースを JBoss ON から削除する必要があります。これにより、Postgres プラグインの Postgres サーバーへの接続が閉じ、データベースをドロップすることができます。

A.11. Apache リソース

問:
Apache コネクターはどこで取得できますか?
答:
Apache プラグインは、SNMP コネクターなどのカスタムモジュールを介して Apache Web サーバーを監視します。コネクターは、GUI の Downloads ページの JBoss ON サーバーからダウンロードできます。
問:
Response Time モジュールで Apache をインストルメント化しましたが、VirtualHosts に対して RT メトリックは表示されていません。
答:
VirtualHosts に RT メトリクスが表示されていない場合は、以下の 2 つの確認を行う必要があります。
  1. エージェントのシステムユーザーが _rt log ファイルを読み取りできますか?たとえば、RHEL/Apache では、デフォルトのパーミッション /var/log/httpd は 700、root です。
    ls -arltd /var/log/httpd/
    drwx------ 2 root root 4096 Jul 28 11:36 /var/log/httpd/
    回避策として、httpd ログに代替ログディレクトリーを指定するか、権限を変更することです /var/log/httpd。これら両方には、特定のセキュリティー上の影響があります。root としてエージェントを実行することもできますが、これが最も望ましいオプションですが、ファイルのパーミッションを変更してシステムセキュリティーを侵害しないようにする必要がある場合があります。たとえば、JBoss ON は、700、postgres パーミッションをデータディレクトリー上でアクセスするため、root 権限なしで postgres デーモンを監視できません。これらのパーミッションは変更されないため、エージェントを root として実行するのは残りの唯一のオプションです。
  2. Apache Vhost テンプレートに対する Response Time Metric を有効にし、応答時間が有効にされているか?これはデフォルトで無効になっています。
これを行うには、以下に移動します。
  1. Administration > > System Configuration Templates | Apache HTTP Server> Apache Virtual Hostで、をクリックし Edit Metric Templateます。
  2. の横にあるチェックボックスを選択し HTTP Response Timeます。
  3. ページの下部で、を選択し Update schedules for existing resources of marked typeます。
  4. コレクションの間隔を設定します。
  5. Go ボタンをクリック[>]します。
注記
RT メトリクスが機能するようになりました。メトリクスが表示されるまでに約 10 分かかる場合があります。
問:
Apache メトリクスの一部はゼロの値を表示します。なぜですか?
答:
SNMP モジュールでモニタリングする場合は、3 つのメトリクスでゼロの値が表示されます。
  • 1 分あたりの GET リクエストの受信バイト数
  • 1 分あたり POST リクエストの受信バイト数
  • 1 分あたり受信バイト数の合計
これは、SNMP がリクエスト本文から情報を解釈する方法により生じます。まず、SNMP はリクエストボディーにさまざまな長さの値を提供し、GET リクエストにはボディーがないため、GET 応答は計算されず、値をゼロにします。次に、リクエストチャンクがある場合、Apache はリクエストボディーサイズを計算しません。
問:
Augeas プラグインとは何ですか?
答:
Augeas プラグインは、他のプラグインの拡張ポイントとしてのみ存在する抽象プラグインです。Augeas プラグインは、Augeas ネイティブライブラリーにアクセスするために他の依存プラグインに必要な Java JNI クラスを提供します。たとえば、OpenSSHD プラグインは、Augeas ライブラリーを使用して OpenSSH デーモン設定にアクセスするため、Augeas プラグインによって異なります。その他の JBoss ON プラグインは、以下の Augeas プラグインを使用します。
  • hosts
  • grub
  • apt
問:
「java.lang.UnsatisfiedLinkError: Unable to load library 'augeas': libaugeas.so: cannot open shared object file: No such file or directory"?
答:
これは、Augeas ベースのプラグインがデプロイされていることを意味しますが、Red Hat Enterprise Linux ボックスには Augeas ネイティブライブラリーがインストールされていません。Augeas ライブラリー インストールに関する詳細は、http://augeas.net を参照してください。
問:
Apache SNMP モジュールがエラーを出して起動できないのはなぜですか?
答:
一般的なエラーと原因がいくつかあります。
error 原因
/etc/httpd/conf/httpd.conf の 1376 行での構文エラー: Unable to write to SNMPvar directory"(stderr) 「 SNMPVar」ディレクティブで指定されているディレクトリーが存在し、Apache プロセスを所有するユーザーが書き込み可能であることを確認します。
init_master_agent: Invalid local port(Permission denied)"(error_log ファイル内)
Apache error_log に以下のようなログメッセージが含まれるかどうかを確認します。
[Notice] SELinux policy enabled; httpd running as context user_u:system_r:httpd_t:s0
これは、SELinux(Security-Enhanced Linux)ポリシーにより httpd プロセスが SNMP エージェントポート 1610 にバインドされないようにします。この問題を解決するには、コマンドを実行してから Apache を再起動して /usr/bin/setenforce 0、SELinux を Permissive モードに変更します。その後、error_log に以下のようなメッセージが表示されるはずです。
[notice] SELinux policy enabled; httpd running as context user_u:system_r:unconfined_t"
このメッセージには、unconfined_t という用語があります。これは、SELinux がプロセスの制限を解除していることを示します。

A.12. Tomcat リソース

問:
Tomcat リソースの Configuration タブに移動すると、「 this resource's configuration has not been initialized」というエラーが表示されます。なぜですか?
答:
特に、 リソースにアクセスし、Configuration タブを開くとエラーが発生します。
そのため、設定管理が Tomcat リソースに対して有効になっていません。これを行うには、Tomcat サーバーのタブに移動し、Connections サブ Inventory タブを開いて、設定を明示的に有効にします。

A.13. プロビジョニングおよびコンテンツ

問:
Ant レシピ XML を直接アップロードしてバンドルを作成しようとすると、XML コンテンツが破損したと思われ、タグは古い順に配置されます。
答:
ANT スクリプトをレシピとしてアップロードする場合は、のような XML 表記を使用することはできません <property name="a" />。のように、明示的に定義されたクローズタグが必要です <property name="a"></property>。Ant スクリプト XML ファイルを訂正しない場合は、ファイルのアップロードの代わりに、レシピを直接 text フィールドに貼り付けます。
問:
JBoss ON の JBoss パッチコンテンツ機能は実際に何を行うのですか?完全に自動化されているか?
答:
パッチプロセスにより、パッチ zip に含まれるアップグレードされた jar/class ファイルが含まれる既存の jar/class ファイルが更新されます。非実行手順など、一部の変更は手作業で完了しなければならない 場合があります。設定にパッチが適用される jar の 1 つが含まれない場合、そのステップはスキップされます。
パッチプロセスでは、サーバー設定プロファイルが呼び出されるか、または派生するベースイメージを明示的に考慮しません。
JBoss サーバーのパッチや JBoss ON リソースへのコンテンツをストリーミングするその他の方法は、『 『基本的な管理ガイド』』 で説明されています。

A.14. アラート

問:
アラート定義を作成しました。エージェントが直ちにアラートを発生させるはずのデータを報告していることがわかります。しかし、警告は表示されません。なぜですか?
答:
アラート定義が作成されると、JBoss ON サーバーアラートキャッシュに挿入してから JBoss ON サーバークラウド全体で伝播するのに数秒かかります。アラート定義がサーバーアラートキャッシュにあるまでアラートは起動されません。
アラート定義がキャッシュに挿入されると、メッセージは JBoss ON サーバーログに記録されます。
INFO  [CacheConsistencyManagerBean] localhost took [51]ms to reload global cache
INFO  [CacheConsistencyManagerBean] localhost took [49]ms to reload cache for 1 agents
通常、アラート定義がキャッシュに追加されるまで約 30 秒かかります。定義の作成後、1 分以上待ってからアラートが発生しているかどうかを確認します。
問:
同じメトリクスを使用している場合に、各種のアラート定義条件の異なるメトリクス値でアラートがトリガーされるのはなぜですか?
答:
これは、エージェントからデータを測定する際にアラート条件がどのように処理されるかによって発生する可能性があります。これは、単一のアラート定義に同じメトリクスを使用する複数の条件があり、そのアラート定義が「ALL」と併用される場合に発生します。たとえば、アラート定義に「alert if metric X is greater than 5」の条件が 1 つあり 「alert if metric X less than 10」という条件が異なります。
アラート条件範囲は、範囲のチェックを実行してこれを回避します。詳細は、Bugzilla 735262 を参照してください

A.15. 監視

問:
Events タブが「ログイベントソース」のいずれかのイベントをキャプチャーしないのはなぜですか?
答:
イベントソースを定義する際には、以下の 3 つの項目を確保する必要があります。
  • 有効になっています。
  • ログへのパスが有効である。
  • 選択した日付の形式がログにあるものと一致します。
イベントソースの作成時にデフォルトの日付形式を選択し、その形式がログにある内容と一致しない場合、ログイベントについて何もキャプチャーされません。
たとえば、デフォルトの日付形式 2017-07-14 15:36:25,075 を選択し、ログに 2017.08.27-09:46:34 の場合、ログイベントはキャプチャーされません。
の説明に従って、異なる日付形式を指定します。 java.text.SimpleDateFormat.
問:
ベースラインの自動計算を行うタイミング
答:
JBoss ON GUI の Administration ページに移動し、Server Configuration リンクをクリックします。の設定が表示され Automatic Baseline Configuration Propertiesます。は、ベースラインが計算される頻度を Baseline Frequency 決定します。デフォルトは 3 日です。つまり、ユーザーが手動で設定したものを除き、3 日ごとに新しいベースラインのセットが計算されます。これらはユーザーが設定したベースラインに固定されたままになります。
Baseline Dataset 測定の基準が計算される前に測定用に収集された必要のあるデータの最小セットを決定します。デフォルトは 7 日です。たとえば、ベースラインの計算が必要となると判断されると、デフォルトでは 3 日ごとに、7 日間またはそれよりも古いデータがある測定値のみに基準が算出されます。7 日前のデータがない測定は省略されます。これにより、測定のベースラインが計算されると、計算に含める適切なデータの代表的なセットがあります(デフォルトでは、基準計算に含まれるデータが 7 日になります)。

A.16. operations

問:
「 Operations」タブをクリックしましたが、利用可能な操作は表示されません。また、「表示しない項目」と書かれています。 操作のスケジュール方法
答:
この Schedules タブには、スケジュールされた操作の一覧が表示されます。これは、設定済みですが実行されていない操作を示します。スケジュールされた操作がない場合、タブには No items to show を読み取る説明があります。
これは、リソースに利用できる操作がないことを意味します。つまり、操作がスケジュールされていないことを意味します。
操作をスケジュールするには、Operations タブ New の左下隅をクリックし、操作情報を入力します。

付録B ドキュメント履歴

改訂履歴
改訂 3.3.7-1Tue 11 Apr 2017Conscot ムムー
さまざまなバグ修正を再構築します。
改訂 3.3.2-11Thu Jun 23 2016Conscot ムムー
BZ-1315797: EAP 7 サポートの更新
改訂 3.3.2-7Thu 02 July 2015Jared イタリア
JBoss ON UI のヘルプ > ドキュメントメニューにリンクしていた HTML Anchors が修正されました。
一部のブランドフォーマットの問題を削除するために公開されました。
コンテンツへの即時アクセスの Preface を削除しました。
改訂 3.3.2-2Tue 28 Apr 2015Jared イタリア
BZ#1151788: 本ガイドのテキスト手順が修正され、ユーザーインターフェースに関連しています。
改訂 3.3.2-1Tue 28 Apr 2015Jared イタリア
JBoss ON 3.3.2 リリースの準備
改訂 3.3.1-3Wed Feb 25 2015Jared イタリア
JBoss ON 3.3.1.GA リリースの準備
BZ#1151202: 3.3.0 の UX の変更後に更新が必要なモニタリングメトリクスの追加手順が修正されました。
BZ#1152895: "Installing the Response Time Filters" セクションに記載された説明では、呼び出し時間メトリックを収集する唯一の方法は HTTPS 管理インターフェースを介してしか行われていないことを示唆しています。
改訂 3.3-71Mon Nov 17 2014Jared イタリア
3.3 Release Notes for Customer Initiated Defects を参照してください。
https://bugzilla.redhat.com/show_bug.cgi?id=1160757: パッチの読み取り/書き込みアクセスを必要とするディレクトリーに関する注意書きを強化し 「JBoss Enterprise Application Platform 6.2 および Above のパッチ適用」 ます。
https://bugzilla.redhat.com/show_bug.cgi?id=1151214: UI の変更により適用さ 「リソースの可用性チャートの表示」 れなくなったため、ステップ 5 から削除されました。
https://bugzilla.redhat.com/show_bug.cgi?id=1073483: URL を /coregui/#Test/ に次のように修正し、修正が必要なさらにいくつかのインスタンスを見つけます。
https://bugzilla.redhat.com/show_bug.cgi?id=1123716: 古い GUI から誤った手順が記載された 2 つの手順を削除しました。セクションのマイナーな文法の編集。この手順を簡潔に示す自己説明グラフィックスをコメントしました。

法律上の通知

著作権 © 2017 Red Hat。
このドキュメントのテキストおよび図は、Red Hat によって Creative Commons Attribution-Share Alike 3.0 Unported ライセンス("CC-BY-SA")でライセンスが適用されています。CC-BY-SA についての説明は、 http://creativecommons.org/licenses/by-sa/3.0/.CC-BY-SA に従って、本書を配布したり、その適合を配布する場合は、元のバージョンの URL を指定する必要があります。
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by apply.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linusinusvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent.Red Hat Software Collections は、公式の Joyent Node.js オープンソースまたは商用プロジェクトによって正式に関連または承認されていません。
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission.We are not affiliated with, endorsed or stuorsed by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.