Red Hat Training

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

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);