<4D F736F F F696E74202D E656D6F73837D836C815B C B CC90DA91B182CC8E DD82F0979D89F082B582E682A F38DFC E >

Transcription

1 序章はじめに との接続の仕組みを理解しよう! ~ 開発者による設計セミナー vol.02~ 2012 年 11 月 14 日株式会社 NTT データ 幸坂大輔 2 開発チームって何をやってるの? 問い合わせの種別 開発チームの業務 開発 新バージョンの開発 オプションの開発 保守 仕様問い合わせ対応 解析問い合わせ対応 パッチ作成 導入支援 NTTデータの案件 NTTデータ以外の案件 どんな問い合わせが多いの? ユーザはこんな事で困っています! が正常に接続できない との接続機構が複雑で 自己解決できない 監視結果が不明 / 危険 環境に問題がある場合が多い ジョブの挙動 ジョブのハンズオンセミナを受講してください が高負荷 監視対象が多すぎる場合が多い今回はこちらにフォーカスします! 4.0では改善 3 4

2 本セミナの目的 目次 との接続の仕組みを理解しよう! 理解すると との接続ができていない場合に 自己解決する事ができます! 第 1 章が利用できない! 第 2 章ジョブがすぐ動いてくれない! 第 3 章クラスタ環境のアクティブ側でジョブを動作させたい! 第 4 章クラウド環境もオンプレミス環境も管理したい! さらに 特殊な環境でもを利用できるようになります! 5 6 問題発生! 第 1 章が利用できない! 下記の問題が発生! を ログファイル監視が動作しない利用する機能 カスタム監視が動作しない ジョブが失敗する ( ジョブ実行して10 分後に AgentTimeoutErrorとなります ) これらの事象はとが接続できていない時に発生します まずはが接続されているか確認しましょう! 7 8

3 の接続確認その 1 の接続確認その 2 接続一覧が確認可能 接続できていないを確認可能 監視設定画面 監視結果 リポジトリ [ ] ビューを見る事で 監視を利用すると が正常に接続されているか確認する事ができます が正常に接続されているか確認する事ができます 9 10 が接続されていない原因を調査する前に 3.2 の接続機構 が接続されていない原因を調査する前に の接続機構を簡単に勉強しましょう Topic からに情報を送信する方法 1 対多の通信 全に送信して が自分宛の情報か否かを判別する Topic の数 2+α の張りっぱなしの TCP コネクションが生成される (HeartBeat 通信により 接続断を検知したら再接続 ) JobExecuteTopic : ジョブ実行時に送出される Topic LogtransferTopic : ログ転送設定変更時に送出される Topic RepositoryTopic : リポジトリに変更があった時に送出される Topic 4.0では3.2で利用していた通信機構を廃止し 一から通信機構を開発しました Topic 4.0の通信機構のメリット 1000 台接続可能! (3.2では50 台程度 ) NAT 環境などでも利用可能! (ping 等で接続できる環境であれば は接続可能です 3.2ではping 等で接続できても が接続不可の場合がありました ) 難しいので省略 Queue からに情報を送信する方法 1 対 1の通信 Queueの数の張りっぱなしのTCPコネクションが生成される (HeartBeat 通信により 接続断を検知したら再接続 ) JobStatusQueue : ジョブの実行結果を送出するQueue RMI からの API を呼び出す方法 NAT を越えられない getfacilityid : IP アドレスとホスト名をキーに ファシリティ ID を取得するメソッド Queue RMI 側では 下記のポートを利用します 1098, 1099, 4444, 4445, 4446, 4457,

4 4.0 の接続機構はこれだ! 4.0 の接続機構を もうちょっと詳しく説明 SOAP/HTTP の通信は TCP8080 に接続します から の API を呼び出す SOAP/HTTP の通信は -Topic 機能を利用します とってもシンプル! 側では 下記のポートを利用します TCP8080 TopicPool gettopic 30 秒周期で動作 に送りたい情報は TopicPool に置く このスライドは TCP8080 で 30 秒周期でアクセスしている事だけ理解すれば OK! 動作例 チェックポイントその 1 ジョブが実行された時 1 はTopicPoolにJobExecuteTopicを置きます 2 は常に30 秒周期でTopicPoolを確認して JobExecuteTopicを取得します (gettopic) との通信を確認しよう! は gettopic により 30 秒周期でにアクセスしています の IP アドレス 3 は TopicPool から JobExecuteTopic が取得できた場合 JobExecuteTopic からジョブ実行詳細 ( コマンドなど ) を取り出し 実行します 4 実行結果を に送信します 正常に通信できている場合は 30 秒おきに出力される 1 TopicPool 2getTopic 4 jobresult 3 通信していない場合 ネットワークを調査しましょう (FW ルーティングテーブル) 通信しているが が正常に接続されていない場合や tcpdump を実行するのが困難な場合 (tcpdump よりも簡単な方法を知りたい!) 正常に通信できていない場合は 何も表示されない 2 スライド後の チェックポイントその 2 へ 15 16

5 チェックポイントその 2 のための事前知識 チェックポイントその 2 gettopic ノードプロパティを確認しよう! gettopicは30 秒周期で動作します サーバの IPアドレスとホスト名 をキーにTopicの取得を試みます はgetTopicの依頼が来た場合は IPアドレスとホスト名 からファシリティIDを判別し そのファシリティIDに応じたTopicが存在する場合のみ Topicをに返信します リポジトリ [ プロパティ ] ビューと ifconfig と hostname を確認する 一致していない場合 の設定を変更する 一致している場合 次スライドの 最後の手段 へ TopicPool 2getTopic IP アドレス ホスト名 つまり で設定している IP アドレスとノード名 が の IP アドレスとホスト名 と一致している必要があります! 最後の手段 gettopic の仕様として ホスト名 と IP アドレス が一致する必要があります しかし には ホスト名 と IP アドレス が一致しない環境でも 利用する事ができます! IPアドレスは一致するが ホスト名が一致しない環境 第 2 章ジョブがすぐ動いてくれない! ファイル名 :agent_start.sh HOSTNAME=`hostname` HOSTNAME= IP アドレスもホスト名も一致しない環境 ファイル名 :Agent.properties # facilityid= facilityid=testdb01 これで 無事に と が正常に接続できます! 19 20

6 問題発生! awakeagent 下記の問題が発生! すぐ終わるジョブが数十秒かかってしまう ジョブで設定したシェルスクリプトを実行した場合は すぐ終了するのに gettopicの問題点 gettopicは30 秒周期で動作します ジョブの即時実行などは 30 秒程度かかる場合があります 即時に実行されない awakeagent(gettopicを即時に実行させる仕組み ) がawakeAgentを発行 (UDP24005) 即時にがgetTopicを実行 UDP awakeAgent TopicPool 2getTopic ジョブ開始からジョブ終了まで 22 秒かかっている は即時実行の実現ために UDP24005 を利用している事を理解しましょう! ここまで TCP8080 のみ利用していると説明していましたが 実は UDP24005 も利用しています チェックポイントその 3 FW( ファイアウォール ) を確認しよう! RHEL のデフォルトの FW 設定では UDP24005 は遮断されています 第 3 章クラスタ環境のアクティブ側でジョブを動作させたい! FW の停止 FW の停止確認 なお UDP24005 が遮断されていても ジョブ等のの機能は動作します この事象のように 動作が遅くなるだけです 注 : この例では原因が FW であるか確認するために iptables を停止させています 確認した結果 FW が原因という事が分かったら iptables を起動し UDP24005 が通過するルールを追加する事を推奨します 23 24

7 クラスタ環境で が動作しない! クラスタ環境で が動作しない! 仮想 IP を保持しているアクティブサーバでジョブを実行したい! がアクティブの時 に命令 A B hostb ノードX A B hostb hostb がアクティブの時 に命令 A B hostb 仮想 IP が移動 下記の問題発生! Aが仮想 IPを保持 Aは動作する Bが仮想 IPを保持 Bは動作しない クラスタ環境で を動作させる失敗例 クラスタ環境で を動作させる成功例 ノード X A B hostb ノード X A B は ホスト名とIPアドレス をキーに自ノードを判定します (gettopic) にノードX(, ) を登録 はホスト名を直接指定する事ができる! agent_start.sh: HOSTNAME=`hostname` HOSTNAME= A が仮想 IP を保持 (,, ) ノード X としては動作!! B が仮想 IP を保持 (hostb,, ) は動作せず にノード X(, ) を登録 A が仮想 IP を保持 A がノード X として動作!! B が仮想 IP を保持 B がノード X として動作!! 27 28

8 補足 : 仮想 IP に連動させつつ 両にも動作させる ノード X ノード A ノード B は下記の3つのノードを登録 ノードX :, 仮想 IPを保持している ノードA :, A ノードB :, B A B 仮想 IP を保持しているサーバでジョブを実行 両系のサーバでログファイル監視を実行 第 4 章クラウド環境もオンプレミス環境も管理したい! クラウド環境もオンプレミス環境 クラウド環境もオンプレミス環境 こんな構成ってできないの? クラウド環境とオンプレミス環境の両方を1つので管理したい 3.2では NATを越えられない とか ネットワーク的に遠いと利用できない と聞いたんだけど 4.0では可能です! ただし 下記に注意してください HTTP8080が通信できるようにしてください ( できればUDP24005も ) 通信は暗号化されないので VPN 等で暗号化する必要があります 自社環境 ( オンプレミス ) 自社環境 ( オンプレミス ) クラウド環境 クラウド環境 監視 ジョブ 監視 ジョブ 監視 ジョブ 監視 ジョブ 31 32

9 まとめ 最終章まとめ 進化した の接続の仕組みを理解して ライフをエンジョイしてください! 以上 おまけ : 4.0 と 3.2 の接続差異 4.0 当たりのコネクション数は2 TCP8080が通信できていれば コネクションに問題なしと判断できる 利用するポートは2 個 NATを越えられる FWを越えられる コネクションレス 無通信タイムアウトや瞬断に強い 3.2 当たりのコネクション数は約 20 一部のコネクションが切れた場合に 監視で検知できない事がある 利用するポートは10 個 NATを越えられない FWを超えるときは注意が必要 ( 無通信タイムアウトなど ) コネクションは維持 無通信タイムアウトや瞬断に弱い ( 内部でheartbeatしているが ) Copyright 2011 NTT DATA Corporation 35