• Save
hbstudy#06
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,155
On Slideshare
3,133
From Embeds
22
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 22

http://www.slideshare.net 13
http://10.25.129.67 9

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. システムの運用・監視のコツ 株式会社ハートビーツ 坂口 利樹 2009/12/04
  • 2. agenda  インフラエンジニアのお仕事  監視とは  なぜ監視が必要なのか  どうやって監視するか  監視チームを作る
  • 3. 誰?  坂口利樹 ( さかぐちとしき )  twitter : tsakaguchi  Mail : sakaguchi.toshiki@gmail.com  インフラエンジニア  エンジニア歴 2 年半 ( しんそつ )  PostgreSQL Confarence 2009 Tokyo/Fall  実行委員
  • 4. インフラエンジニアのお仕事 定例業務 定例業務 非定例業務 設計、アーキテクト ● 管理 ● ● ボトルネックの解析・ログ解析 ● 機器・設定情報の管理 高負荷プロセスの分析 ● リソース管理 ● 運用方法・監視方法の検討・提案 ● バックアップ ● 権限・セキュリティ管理 選定 ● ● ネットワーク・サーバ 監視 ● OS ・アプリケーション ● システム・機器の稼働状況、 iDC ・回線等の選定 リソース状況・ログ出力、改竄検知 ● 負荷テスト ● 障害対応 構築 ● 問い合わせ対応・サポート ● ● サーバ、機器のセットアップ ● 社内外からの問い合わせ ラックマウント・ケーブリング SSL 証明書取得・設定
  • 5. インフラエンジニアのお仕事 定例業務 定例業務 非定例業務 設計、アーキテクト ● 管理 ● ● ボトルネックの解析・ログ解析 ● 機器・設定情報の管理 高負荷プロセスの分析 ● リソース管理 ● 運用方法・監視方法の検討・提案 ● バックアップ ● 権限・セキュリティ管理 選定 ● ● ネットワーク・サーバ 監視 ● OS ・アプリケーション ● システム・機器の稼働状況、 iDC ・回線等の選定 リソース状況・ログ出力、改竄検知 ● 負荷テスト ● 障害対応 構築 ● 問い合わせ対応・サポート ● ● サーバ、機器のセットアップ ● 社内外からの問い合わせ ラックマウント・ケーブリング SSL 証明書取得・設定
  • 6. 監視とは
  • 7. 監視とは  システムやネットワークの状況変化を 知るための情報収集活動
  • 8. なぜ監視が必要なのか
  • 9. なぜ監視が必要なのか  大前提:ビジネス・サービスが動いている  高可用性が求められる  すべての障害を予期することは困難 機能停止 性能低下 機能監視 性能把握
  • 10. 監視の種類を分類 機能監視 性能把握 ● L1 〜 L3 ネットワーク ● L4 〜 L7 サービス ● HTTP(S) システムリソース ● POP3(S) CPU 使用量 ● ● ● SMTP(S) ● IMAP(S) ● メモリ使用量 DNS Disk I/O ● ● ● SSH ● (S)FTP ● Network( 遅延・帯域 ) ● DB への接続状態 ● DB の内部状態 ● プロセス死活 ● ログ出力 ● RAID
  • 11. 監視の種類を分類 機能監視 性能把握 ● L1 〜 L3 ネットワーク ● L4 〜 L7 サービス ● HTTP(S) システムリソース ● POP3(S) CPU 使用量 ● ● ● SMTP(S) ● IMAP(S) ● メモリ使用量 DNS Disk I/O ● ● ● SSH ● (S)FTP ● Network( 遅延・帯域 ) ● DB への接続状態 ● DB の内部状態 ● プロセス死活 ● ログ出力 ● RAID
  • 12. どうやって監視するか
  • 13. どうやって監視するか  監視ツールを使う  メリット  既に欲しい機能が作り込まれている  オープンソース  ZABBIX  Hinemos  Nagios  hobbit(Xymon)
  • 14. Google trend(world) hobbit hinemos zabbix Nagios
  • 15. Google trend(Japan) hobbit hinemos zabbix Nagios
  • 16. 監視ツール選定 (1)  機能  スケジューリング  人間のスケジュールに合わせた運用 例:バッチ処理時間帯はある程度の負荷を許容   柔軟性  プラグインで拡張可能か!? Nagios の場合、プラグインの exit code で判定 0: OK 1: WARNING 2: CRITICAL
  • 17. 監視ツール選定 (2)  性能  Nagios の場合、 3 年前のマシン 1 台で 400 台く らいが目安 Pentium4 3GHz, mem 1GB  で検証→ 400 台、 4000 項目程度は OK  Nagios は AMQP と組み合わせてスケールアウト もできるらしい ( 未検証 )
  • 18. 監視ツール選定 (3)  運用  設定内容の管理  バージョン管理システム ( ハートビーツでは SVN) で管理できると楽  テスト環境の用意  バージョン管理システムと組み合わせて テスト環境を構築しています  テスト環境はメールが一切飛ばないようにしています
  • 19. 監視設定手順 2.設定・動作確認 1.チェックアウト Nagios(test) 3.コミット SVN リポジトリ 5.設定反映 4 .チェックアウト Nagios (1) 7.設定反映 Nagios (2) 6.チェックアウト
  • 20. 監視のポイント  何のサービスが動いているか  最適な監視  必要なところ ( 使っているところ )  監視項目をむやみに増やしすぎない  使う側の視点
  • 21. 監視サーバのネットワーク  2拠点から監視  別キャリアのネットワーク Nagios(1) Internet 監視対象サーバ Nagios(2)
  • 22. 監視項目例 (Web サイト )  外部  内部  HTTP/HTTPS  LoadAverage  表示されるまでの時間  メモリ  文字列  プロセス総数  ログイン  ログ出力  シナリオ  プロセス稼働状況  回線使用状況  DB レプリケーション  Disk 残容量  Disk I/O
  • 23. 監視項目例 (JavaVM)  プロセス死活  ヒープ域不足 (Out of Memory)  OOM Killer によりプロセスが Kill される  Tomcat/Jboss プロセスサイズ  ログ監視
  • 24. 監視項目例 (MySQL)  Mysql Status の取得  Web サーバから DB サーバへの接続  レプリケーションの状況  テーブルを作成して削除
  • 25. システム監視だけじゃない!  大事なのはビジネスなので、そのレイヤーまで見る!  IBM 用語で「センス アンド レスポンド」というそうです  例えば・・・  システムのログインユーザ数を監視 (DB へのクエリ結 果)  広告からのサイト流入量を監視 (DB へのクエリ結果 )
  • 26. 閾値の調整  閾値の決定ポリシー  サービスによって様々  運用しながら  誤報  なくすことはできない(宿命)  減らすことはできる  リトライチェック  根本的な解決を !
  • 27. 誤報撲滅!  遠い場合 (EC2 、中国にあるサーバ )  パケットロスは容認  リトライ回数を増やす  対応しないアラートは誤報と同じ  「アラートを無視する習慣」につながるので、重点 的になくす!  「アラートを無視する習慣」がついたら一巻の終わ り
  • 28. 閾値の調整例  どこまでが正常なのか  サイト表示: 3 秒〜 5 秒 ( 目標値 )  LoadAverage : CPU のコア数  SWAP : 20%  プロセス総数 Web サーバ (Apache­prefork) の場合 稼働中のプロセス総数      + (MaxClients­ 稼働中の httpd プロセス数 )
  • 29. 対応の自動化  イベントハンドラの活用  LB から切り離す  落とし穴に注意 例: Apache の自動再起動スクリプト  セマフォによるリソース管理の上限で Apache が自動起動されず、 web サービスが復旧しない  Apache 管理ユーザのセマフォの削除を手動で行い解決
  • 30. 監視の種類を分類 障害監視 性能監視 ● L1 〜 L3 ネットワーク死活 ● L4 〜 L7 サービス監視 ● HTTP(S) POP3(S) システムリソース ● ● SMTP(S) ● ● IMAP(S) ● DNS ● CPU SSH メモリ使用量 ● ● (S)FTP ● DB への接続状態・内部 ● Disk I/O ● ● システムリソース ● ログインユーザ数 ● Network プロセス死活 DB の内部状態 ● ● ● CPU ● Memory 使用量 ● SWAP 使用量 ● ディスク空き容量 ● ログ出力
  • 31. なぜ監視するか  変化の把握  ボトルネックの把握  チューニング  スケールアウト / スケールアップ  後々必要になってくるので早い段階からの実装  キャパシティプランニング  このシステムでどれだけこなせるか  どのタイミングで増設が必要になるか
  • 32. どうやって監視するか  ツールを使う  MRTG  Cacti  Munin  ZABBIX  Hinemos
  • 33. 何を監視するか  想定されるボトルネックはどこか?  想定されるトラブルは何か?
  • 34. 監視項目例 (MySQL)  Cacti  Login Count /Session Count  InnoDB BuffrePool / I/O / Insert Buffer Row Operations / Log Buffer Size.....
  • 35. さいごに・・・ 監視チームを作る
  • 36. 監視チームを作る  監視と障害対応は切り離せない  一人ではやりきれない  夜間の障害対応  複数同時の障害  精神的・労務的な問題  24 時間 365 日  4 人は最低必要 ( 休み無し )
  • 37. 情報共有  アラートメールの送信先  インフラ担当だけでなく開発や企画担当の人も  ドキュメント ( 監視仕様書 )  人を育てるのにも有効
  • 38. ドキュメントの書き方のコツ  ネットワーク構成図  アプリケーション構成図  対応フローの確定  監視項目ごとの状況確認方法  監視項目ごとの対応方法
  • 39. アプリケーション構成図 ( 例 ) hb-web01 ハートビーツ Postfix:25 Internet apache(123.123.1.1:80) 共有 FW tomcat(8009) MySQL:3306 (Master) hb-nfs01 apache2(123.123.1.21:80) ト ウン ファイル共有 smb マ ト vsftpd:21 sshd:22 ウン sm bマ rs yn c+ ss h hb-webdev01 バ ッ Postfix:25 ク apache(123.123.2.1:80) ア ッ プ tomcat(8009) MySQL:3306 hb-backup01 MySQL:3307 MySQL:3306 Replication Replication apache2(123.123.2.2:80) Slave Slave rsync+ssh バックアップ sshd:22 vsftpd:21 sshd:22 svn リポジトリ
  • 40. 監視項目ごとの状況確認方法例
  • 41. 復旧方法例 (1)
  • 42. 復旧方法例 (2)
  • 43. その他気をつける点  ドキュメントの二重管理  対応する人の決定
  • 44. 対応する人の決定の補足  お見合いが一番怖い  ダウンタイムだけが伸びたら・・・ビジネスに影響大!  誰がボールを持っているか、常に明確に!  アラート同報だと誰がボールを持っているか不明確  深夜の場合、ボールを受け取った後や、対応中にホストダウン ( 居 眠り ) の可能性も・・・  ハートビーツの場合、ひとりずつ電話をかけるのでボールの持ち 主は明確になります 対応完了のご連絡をいただけない場合、ベストエフォートでリ マインドもできます
  • 45. 終 ご清聴ありがとうございました