日時:2010/02/23 19:00 to 21:00
会場:ハロー貸会議室 新宿B(新宿三葉ビル6F)（東京都新宿区西新宿1-5-11）
URL:http://heartbeats.jp/hbstudy/2010/02/hbstudy8.html
URL:http://atnd.org/events/3092
hbstudyとは…
サーバ運営会社が主催するインフラ勉強会です。
- 19:07 スクリプトを使ったサービスの監視・運用について 〜 パストラックの実例をもとに 奥 一穂さん
- 資料 Infrastructure of Pathtraq
- パストラック=ブラウザプラグインで情報を抽出
- ウェブアクセス統計サービス
- サービス開始 2007年8月
- ページ単位のリアルタイム統計・検索
- 注目情報
- インフラプログラマがインフラを作るとどうなる？
- データセット
- 秒間20〜40
- 累計 8億 100GB DBサーバ1台
- HDDだとアクセスが遅い
- メモリ64GBつらい
- 新サーバ
- DB専用サーバ
- 他はVMで立てて単機能
- バックアップ手法を統一したい
- LVMの増分バックアップ
- SSDを積極利用
- InnoDBアクセス HDD(7200rpm)の40倍
- NCQに対応したSSDを(ハマる)
- 並列度が高いのでI/Oプロセスの影響少ない
- 2台(+1)構成
- MySQL 5.1＋Q4M
- SSD 160GBx2 統計用
- マスタDBをSSD化
- HDD 500GBx2 本文データ(RAIDでなくJBOD)
- 予備兼開発
- 仮想サーバ=XenServer VMWare ESXiは他で使っていたのでXenServerを評価したかった
- Apache+mod_proxy
- PSSPSS(PSGIの実態)+CGI::Application
- 全文検索 Tritonベース
- 運用
- デーモンはdaemontoolsで統一
- デーモン化管理とプログラム化の分離(ワーカープロセスのデーモン化が面倒)
- アプリケーションサーバのデプロイ
- Server::Starterによるホットデプロイ(YAPC::Asia2009ネタ)
- サービス停止しない
- タスクはcron
- 排他処理はsetlock
- I/O競合を避けるため
- バックアップとの競合を避ける
- cronが失敗したら？
- cronlogを使用
- cronlog=cronタスクに失敗したとき"だけ"エラーメールを送信
- crontab を使って効率的にサービス監視する方法
- cronのメール送信機能じゃダメなのか？
- タスク出力の有無でメールする／しないかが決まる(ログ読むの大変)
- タスク監視とサービス監視の両方
- 学習コストが安い
- 開発者にやさしい
- 「監視=継続的なテスト」
- 定期的なpollingによる条件成立の確認
- Unixツールは正否を出力コードで返す
- 例) pingが通らない(という出力コード)を監視 HTTPはwgetで
- Q. 多数の項目を管理するのに使う？
- A. 開発のテストフレームを使う
- 開発で使い慣れている
- 出力も見慣れている
- インフラ担当でなく開発者が監視プロセスを書ける
- アプリのパフォーマンスは開発者でないと分からない
- 例) Perlはprove
- テストが1つでも失敗すればアラートメール
- critical/warningレベル分け可
- その他小物
- touch_if=ログからhttpdの応答時間やエラー応答を正規表現で抽出できる
- ssh_run=スクリプトをsshで送って実行
- バックアップ
- 要求
- 実質無停止
- ボリュームレベルでバックアップ
- MySQLはダンプ、VMはイメージファイルを…とか個々にやりたくない
- インクリメンタル
- 毎日フル300GBもとりたくない
- 自作「Blockdiff」blockdiff を使ったお手軽ホットバックアップ環境の構築 (Linux, MySQL, etc.)
- 特徴
- DBバックアップ用diffがベース
- over-sshでバックアップ
- バックアップのための空き領域が不要
- 設定ファイル不要
- エージェントのインストール不要
- フルバックアップと増分バックアップが可能
- 仕組み
- 必要なロック(setlock)を取得
- LVMスナップショット→lzopで圧縮
- ロックを解除
- 毎日増分、月1回フル
- バックアップ単位
- DB=論理ボリューム
- VM=イメージ
- Q. バックアップしている間のバックアップできなかった差分のフォローは？
A. DBならバイナリログ
- LVMの限界
- スナップショットの差分だけは無理。ボリュームを全部舐める
- バックアップイメージ内のファイルを取り出すのは面倒
- zfs iSCSIなら簡単なんだけど
- BlockdiffはCからperlに書き直した
- Cだと32bit/64bit対応が面倒
- perlやpythonなら最初から導入されている シェルスクリプトが書けるならperl/pythonでも書ける
- Q. リストアは？
A. Blockdiff restoreがある
- まとめ
- 統合型も良いけど、細かいツールの組み合わせの方が良いケースもある
- 20:10 Puppetのススメ 宮下 剛輔さん
- 資料 Puppetのススメ
- Puppetとは
- Ruby製
- システム管理ツール？ → サーバの状態を定義・維持するツール
- なぜPuppetが必要？
- 手作業に問題
- 時間がかかる
- 人的ミス
- 他の自動化は？ カスタム化するとメンテ(人が書いたのを読んだり)が大変
- HDD複製、PXEブート、rsync同期
- 混在、複数環境だと難しい
- 設定の差異(IPアドレス等)の吸収が難しい
- 導入のメリット
- 構築・更新の自動化
- マニフェストと呼ばれる独自言語で見える化
- マニフェスト=自由度は低いが扱いやすい
- svnによるバージョン管理ができる
- すぐにやめられる 既存環境に影響を与えない
- 動作概要
- クライアントがサーバからマニフェストを取得、実行、サーバに結果を返す
- マニフェストの基礎
- リソースの定義
- クラス=リソースをまとめる(継承可)
- インストール方法
- ググれ
- 設定方法
- デフォの設定ファイルは削除、フルスクラッチで
- マニフェストを収納するディレクトリを作成
- スタンドアローンでも動く→テスト
- 使いどころ
- 大量にサーバがある
- 混在環境
- 何度も同じようなことをする
- 開発環境、検証環境、本番環境…
- 自分以外にやる人がいる
- バージョン管理によるトラッキング
- 「なぜこんな設定になっているのか」の記録、意図が分かる
- デプロイツール Archer と組み合わせ →あとで調べる
- インクリメンタル／テスト駆動サーバ構築
- マニフェストを少しずつ書いてテスト
- Puppet化しておく→VMの再構築がラク
- 本番とテスト環境の差異は変数(facter)で吸収
- テストがちゃんとしていれば本番は大丈夫という自信
- Puppetのコンセプトになじむ
- システム上で何を動かすかではなくどういう状態にするかを考える
- マニフェスト
- 設定ではなく言語
- 宣言型=こうなるべきという定義(プロセスを定義する手続型ではない)
- define
- リソースタイプを定義(関数定義ではない)
- クラス
- クラスはリソースのコレクション(オブジェクト指向のクラスとは異なる)
- モジュール
- 汎用化できるマニフェストをまとめたもの
- エラー通知
- エラー通知機能が動かない？→0.24.6から可能
- syslogに吐いて拾ってもらうのもアリ
- ノード管理
- cobbler
- LDAP
- execは最小限に
- exec=何を実行するか
- 乱用は避ける
- Facter変数
- $変数名 (例 OS名)
- カスタム化可能
- 0.25.xから正規表現を使える
- Puppterの微妙なところ
- 変数のスコープとオーバーライド
- 思うような動作にならない場合がある
- グローバルにしたり再定義(上書き)して対処
- 柔軟性(使いやすい)とメンテナンス性(管理しやすい)のバランス
- モジュールに関する問題
- CPANみたいのがない
- クラス設計が難しい
- ドキュメントが読みづらい
- Nagiosに関するものがコアに入っている
- Puppetの利用はrpmの利用が必要
- execでmakeする→遅い、makeが必要になる
- 大量ファイルの配布は遅い→rsyncする→最初からrsyncでいいじゃん
- ロールバックできない
- サーバ間の依存関係を記述できない
- DB必須な環境で「DBサーバが起動したら何かする」ができない
- 追加はウラでyumを実行、削除はウラでrpmコマンドを実行
- 依存関係で消せないものが出てくる
- 結論
- Puppet以外でシンプルなものが見つからないので…
- みんなPuppetを使ってみよう
- Puppetの参考資料
- Puppet Best Practices 2.0
- Puppet Best Practices 3.0
- 思ったこと
上２つのハイブリットで下記のような感じはどうだろう
- サーバに何かするときは必須になる手順書とセットでスクリプトも用意
- 手順書とスクリプトは本番疑似環境でテストをパスしたもの
- 手順書とスクリプトはトラッキングシステムで、PDCAとバージョン管理
- ホスト名等のサーバの差異は、変数にしておいて、スクリプト内でインクルードする
- Wikiに「サーバでこういうことやりたいんだけど…」のような問答集を掲載(回答には手順書とスクリプトのリンクを掲載)
0 件のコメント:
コメントを投稿