大規模インフラの監視システム | GREE Engineers' Blog
こんにちは。インフラチームの ebisawa です。 今回はグリーのインフラにおける各種機器の監視がどのように行われているのかご紹介させていただきたいと思います。一般にサーバの監視というと、システムダウンを検出するための死活監視を意味する場合と、ネットワークトラフィック等のモニタリングのことを意味する場合とがあります。今回の監視は特に後者についてのお話です。大規模なインフラの監視には、やはり特有の課題があります。 どんなツールを使っているのか グリーではサーバの各種リソース使用状況をモニタリングしてグラフ化するためのツールとして、Cacti を利用しています。Cacti は、大変有名なツールなので皆様ご存知かと思いますが、バックエンドの RRDtool で作成したグラフを閲覧するための使いやすいユーザーインターフェイスを備えています。 http://www.cacti.net/ ツールの使
パイプ経由のログ出力はCPUを浪費する
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP Serverでログをパイプ経由でプログラムに出力すると、リクエストを処理するたびにログを処理するプログラムへのコンテキストスイッチが起こります。そのためアクセスが増えたときにCPUをかなり浪費します。UltraSPARC T1は32個のコンテキストを保持できて、1クロックでコンテキストスイッチできるので問題ないと思っていました。しかし、CPUの使用率が100%に達して、さらに負荷が掛かる状況になると違いました。 ftp.jaist.ac.jpにはパイプ経由のログ出力が3つあります。エラーログとアクセスログのrotatelogsへの出力と、以前
http://www.mdis.co.jp/news/press/2010/0225.html
2010 年 2 月 25 日 「非機能要求グレード」が完成 ～情報システムの強度や品質の「見える化」手法を確立、 今後は IPA SEC を通じ IT 業界全体への普及を図る～ 株式会社ＮＴＴデータ 富士通株式会社 日本電気株式会社 株式会社日立製作所 三菱電機インフォメーションシステムズ株式会社 沖電気工業株式会社 （株）ＮＴＴデータ、富士通（株）、日本電気（株）、（株）日立製作所、三菱電機インフォメーション システムズ（株）、沖電気工業（株）（＊1）の国内 SI（システム構築）事業者 6 社が 2008 年 4 月から 活動を開始した「システム基盤の発注者要求を見える化する非機能要求グレード検討会(略称：非 機能要求グレード検討会)」は、各社の知見とノウハウに発注者企業 7 社（＊2）の意見を反映した 「非機能要求グレード」をまとめあげた上で、外部からの有効性評価を得て、完成した非機
業務をアウトソーシングした後の社員は何をするの：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
ずいぶん前の話だが、ある会社から現在運用しているインフラ系システムのひとつをアウトソーシング（今流行のSaaS)にしたいという引き合いをうけて訪問した。対象のシステムは24H365Dの稼働が求められるため運用が大変で自社の運用管理者を貼り付けておくのが勿体ないというのがきっかけで、システム名を聞く限りどこの会社にもある一般的で共通的なシステムだったので、この意見にさもありなんと同意をして訪問することにした。 当日詳しく話を聞いてみると、このシステムには今でも自社の開発者が数名はり付いて継続的に追加開発やメンテナンスを行っいるとのこと。採用していたプロダクトが独自アーキテクチャーだったことも影響しているのだろうが、ユーザからのきめ細かい要望に対応する為に自社ＳＥをそこに特化させて抱え込んでいたようだ。 ところが本社の企画部門から情報子会社に異動してきたという担当者が声高に叫んでいるのは「単純
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
クラウド時代のサーバ/ネットワーク自動マネジメントツール Wakame の開発者を募集中 - @kyanny's blog
株式会社あくしゅさんが、 AmazonEC2 のクラウド環境下におけるサーバ/ネットワーク自動マネジメントツールである Wakame の開発者を募集しています。 やむにやまれず : [Wakame]Wakameの開発にご協力くださる方を探しています http://blog.hansode.org/archives/52052018.html クラウド環境下の仮想サーバが物理的なサーバと比べて特に優位なのは、サーバの追加や撤去をスピーディーかつダイナミックに行える点だと思います。ラックや電源やパーツなどの物理的な諸問題を、仮想サーバのユーザーは意識する必要がないから。 とはいえ、まだまだクラウド環境を実サービスの運用に利用するとなると躊躇してしまう人も少なくないはず。それまでのサーバ運用とは、少し違ったノウハウが必要になってくるわけだし、そういう環境に触れたことがない人にとっては勝手がわから
第28回 日本企業を見限ったインドの“システム屋”から学んだこと
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回（第27回）で登場したインド人の“システム屋”経営者の言葉をもう1つ紹介したいと思います。彼から「日本企業向けの仕事はもうやりたくない」と言われたことがあります。英語力の問題ではなく、日本人はそもそもシステム開発に向いていないというのが彼の主張です。 これを聞いた私は、その場では苦笑するほかありませんでしたが、日本人の“システム屋”として悔しいという感情が残りました。しかし今ようやく、この意見には反論が可能だという思いに至りました。
クラウド時代にSIerはどう変わるのだろう？ セールスフォースの展示会場に飛び込んで聞いてみた
クラウドの登場によってSIerの収益モデルが脅かされようとしています。その主な理由は2つあります。 1つは、プラットフォームとしてクラウドを利用することで、いままでの受注案件に含まれていたハードウェア費用、冗長構成のための作業費など高い利益を得られていた部分がなくなり、ソフトウェアの開発費用のみが丸裸になること。 もう1つは、そのソフトウェア開発でさえ、Salesforce CRMのようにSaaSが普及することでスクラッチからの開発が減って開発内容はカスタマイズ中心にシンプルになり、開発期間も短くなるため、案件あたりの単価が低下すること。 このような状況にSIerはどう対応していけばいいのでしょうか？ その疑問を解くため、昨日、9月15日に都内のホテルで行われたセールスフォース・ドットコムのイベント「Cloudforce Japan」の展示会場に飛び込んで、すでにクラウド対応のビジネスを始
1Uラックマウント可能なサーバを自作する - marqs blog
はてなでは以前から自社製サーバを使用しているのですが、今年の春に、新たに自社製1Uハーフサーバを開発しました。 最近、タワー型だとメーカー製でもかなり安価なサーバがあるのですが、データセンターでの運用を考えると1ラックへの集積度が問題になってくるので、必然的にラックマウント可能なサーバが求められます。1Uサーバの中で価格対性能比のよいものを探すと、まだまだはてな的に使いやすいサーバが少ないので、今回このような1Uラックマウント可能なサーバを自社開発しました。 さてこのサーバの特徴としては、 ケーブル類がフロントアクセス 組み立て簡単 いけてるインフラアルバイトのid:hxmasakiが組み立てると15分 1ラックに60台以上搭載可能 もちろん、電源容量との兼ね合いもあります ディスクのホットスワップが可能 低消費電力 お値段据え置き 以前の自社製サーバとほぼ同価格 といったところがあげられ
NagiosからのアラートをIRCにも通知してみた - （ひ）メモ
Nagiosのアラート通知をメールだけじゃなくてIRCにも通知したいなぁと思ったのでやってみました。 IRC bot 今までだと Plagger 付属の plagger-ircbot を走らせて、適宜 POE の IKC で通知命令を送っていたんですが、ちょっと CPAN を探してみたら、 Bot::BasicBot::Pluggable というのがありました。 karmaもつけられていいなーと思ってこれを使おうと思ったんですが、POE を使っているものの IKC で連携する機能がありません。 そこでこのモジュールを継承して、Bot::IKCBot::Pluggable というのを作りました。 http://github.com/hirose31/p5-bot-ikcbot-pluggable/tree/master Bot::IKCBot::Pluggable BasicBotとの違いは
運用管理に「コーン入りしょうゆラーメン」の発想を
システム運用管理業務に従事していると、本当にいろいろな場面に遭遇します。わたしはシステム運用管理サービスに携わってはや10年目を迎えますが、いまだに現場では日々さまざまな課題が発生します。 でも、そうした課題に悪戦苦闘しながら取り組んでいるうちに、やはりそれなりにノウハウや知恵のようなものが身に付いてくるものです。本コラムではこれから何回かにわたって、わたしが現場で得たものを、読者の皆さんに紹介していきたいと思います。わたしと同じく、日々現場で戦っているシステム運用担当者の方々、あるいはシステム管理者の方々のお役に少しでも立てれば幸いです。 さて、第1回は少し大きなテーマで、「システム運用管理」というものに対する、そもそもの考え方について述べてみたいと思います。 真っ先に「できない理由」を考えてしまう…… 先日、ある顧客との会議（定例会）に参加したときの話です。わたしたちのチームは、その顧
Geekなぺーじ : BGPを解説してみた
2009年2月17日にインターネットが壊れました。 今回の障害はチェコのISPが出してしまった経路情報によって世界各地のルータが機能不全に陥るという事態へと発展したようです。 先日の記事で、流れた経路情報の詳細などを紹介しましたが、「BGPとは何か？」や「そもそもルーティングとは何か？」を知らなければ何を言っているのか意味不明な解説記事だったと思います。 そこで、今回は「インターネットの仕組み」そのものを解説しながら「何が起きたか？」を解説しようと思います。 対象としている読者は、IT系の知識はあるがIPによる通信そのものに関しての知識は無いエンジニアです。 なお、本来ならば正確さを確保するために解説すべきである細かい点は、あえて解説しないようにしているのでご注意下さい。 そもそもインターネットとは何か？ まず、最初に「インターネットとは何か？」を説明したいと思います。 Inter-net
Geekなぺーじ : 2009年2月17日 世界的インターネット経路障害解説
2009年2月17日に発生した世界的なインターネット経路障害に関しての解説、及びその後調べたことです。（参考：インターネットが壊れました）。 BGPとは何かに関しての解説も書いたので、インターネット通信技術そのものに関して知りたい方はそちらもご覧下さい。 何が発生していたのか？ チェコのプロバイダが非常に長いAS pathを流してしまい、その長いAS pathを受け取ったルータがBGP peerを切れたり上げたりを繰り返しました。 BGPのpeerが切れた次の瞬間に、また接続し直してpeerが復活し、そしてまた問題のAS path情報を受け取って切れるという状況を繰り返してしまったようです。 BGP peerが切れるのは、パケットがISP間で転送されなくなるという事なので、世界中で「到達出来ない場所」が発生しました。 この障害は約1時間弱続きました。 問題をトリガーしたチェコのプロバイダと
Geekなぺーじ : 今朝、インターネットが壊れました
今朝０１時２３時JST頃から１時間弱、インターネットが世界的に壊れていたようです。 ほどなくして収束していったようですが、ISP同士のBGP接続が切れて通信が出来ないという状況が局所的に発生していたようです。 3/11 (invalid or corrupt AS path) anyone else seeing very long AS paths? [janog:08731] long AS Path incident] JANOGメーリングリスト 世界中で影響があったようですが、国内では上流網の一部でBGPのpeerが切れて国際的な通信が不通になっていた瞬間があったようです。 ただし、繋がったり切れたりという箇所もあったようです。 「壊れた」原因 NANOGでの情報によると、以下のようなログがルータに残されていたようです。 255以上という異常に長いAS pathが原因のようです。
CapiFy | Home Page
Welcome to easy deployment The Pitch. You lead a busy life. You don’t have the time to waste logging in and logging out of your servers all day, running tasks, installing software, keeping machines in sync, and trying to make sure it all happens correctly. Enter Capistrano. Let Capistrano do the heavy lifting for you. It is designed with repeatability in mind, letting you easily and reliably autom
満足せる豚。眠たげなポチ。:「大規模サービスの運用事例まとめ」に補記
「大規模サービスの運用事例まとめ」をすべて読んでいる時間がない人はこの一枚のスライドだけでも見ておくといいかもしれない。 tech days Japan 2009 の萩原正義さんのセッション「クラウドコンピューティングのエッセンス」のスライド 33 枚目にこう書いてある。（ちなみにこれはエンタープライズアプリケーションの話。） N-tier モデル 密結合が条件 障害がないことが前提 ACID トランザクションが前提 データ層がボトルネック 新しいアーキテクチャ Scale out Key-value データ 非一貫性モデル 非同期 REST, AtomPub 関数型での処理 via http://www.microsoft.com/japan/powerpro/techdays/default.mspx の T1-401 のセッション。 それぞれについての詳しい解説は上記からダウンロード
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
Nagiosに用意された外部コマンドの使用法 | OSDN Magazine
システム監視ツールのNagiosには、コマンドやイベントを外部アプリケーションから受け取る強力な機能が装備されている。通常こうした外部コマンドの送信元となるのは、イベントハンドラないしNagiosのWebインタフェースである。外部コマンドが最も役立つ状況としては、各自のシステムで用いるハンドラを作成する場合や、Nagiosと情報交換をさせる外部アプリケーションを構築する場合を想定すればいい。 本稿はPackt Publishingより最近出版された『Learning Nagios 3.0』からの抜粋である。 外部コマンドパイプとは、Nagiosがメッセージの受信に使用するファイルシステム上に作成されたパイプファイルのことである。ここでの通信には特別な認証や権限は必要なく、唯一課される要件は、コンパイル時のlocalstatedirオプションにて指定されたディレクトリにあるパイプファイルrw
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
一定規模以上のWebサイトを運営しているエンジニアの方、業務時間外の障害対応ってどういう風にやっていますか？ - 人力検索はてな