昨日、hbstudy#8 で話をする機会をいただくことができたので、Nagios や Amanda といった既製品の管理ツールやバックアップツールを使わずに内製したことで「パストラック」の運用コストを下げた、という話をしてきました。 もちろん、「既製品を使わない」というのもひとつの手段にすぎませんから、それを無闇にお勧めするつもりはありません。ただ、小回りの効くツールを組み合わせる手法にも十分な競争力があるという点、あるいはその事例として参考になれば幸いです。 スライドはこちら。hbstudy 運営の皆様、話を聞いてくださった皆様、ありがとうございました。
サーバのシャットダウンの仕方で、その人がどの程度の力量を持っているかなんとなくわかってしまいます。それくらいサーバのシャットダウンは奥深いです。そこで今回はサーバをシャットダウンする作法について考えてみたいと思います。 【初級：いきなりシャットダウンしてしまう】 サーバ管理初心者がサーバをシャットダウンするシーンを見ていると、rootでログインしたかと思ったらいきなりshutdownと打ち始めました。個人PCならまだしも、サーバでそれをやるのは危険ですよね。誰かそのサーバ上で作業しているかもしれないし。 【中級：上がっているサービス・プロセス・TCPコネクションなどを確認してシャットダウン】 サーバ管理中級者になると、サーバをシャットダウンする際は、まずはTCPコネクションがないかなどを確認してから、立ち上がっているサービスやプロセスを全て落とし、その後シャットダウンします。慣れているので
最高気温:20℃ _ tentakelを使って、dnscacheサーバのLルートサーバを変更した 社内LANで動かしているdnscacheは複数台あるので、昨日知ったsudoの-Sオプションとtentakelを使って一気に書き換えてみた。 FreeBSDのports treeに入っているsysutils/tentakelはエラーを吐いて動かなかったので、最新のtentakelをsvnレポジトリから持ってきた。 > svn co http://svn.tue.mpg.de/tentakel/trunk tentakel ~/.tentakel/tentakel.confを設定。 set ssh_path="/usr/bin/ssh" set metod="ssh" group dns () +dnscache1.example.com +dnscache2.example.com +dnsc
Puppetの説明をしていて「システム管理の自動化を進めると仕事がなくなるので困る」といわれて落ち込んだ。「腐ったSIerみたいなこといってんじゃねーよ」と心の中で言い返してみたものの、一般の見方はそうなのかもね。経営者もITの素人だとすれば、同様の思考から「自動化を進めればもっと首を切れる」とか言い出しそうだしな。 「くだらん属人的な作業は自動化して、より人間の力が必要とされるべき分野に注力して、サービスの品質をさらに高めよう」という意図は伝わらなかったみたい。自分の説明が良くなかったのかもしれないけれどな!運用のしろうとさんにもメリットをきちんと説明できなければいけないのだから、まだまだ修行が足りないのだ!ということにして出直します。 One Response to “システム管理の自動化を進めると仕事がなくなるので困る” tsuchiya yoshihiro Says: Octob
システム管理の省力化は管理者の永遠のテーマだ。複雑化するシステム、多様な要求、コストダウンの圧力、管理者の悩みのタネは尽きない。 ほぼ同一の構成のclusterの管理であれば、HDDイメージによる複製や、pxeboot+NFSによるdiskless構成などで管理を省力化することができるが、複数のOSや複数の役割を果たすホストの混在環境や、NFSに依存できない状況では、多数のホストを一括管理するのがむずかしい。そこでcfengine。cfengineはUniversity of Osloで開発されたGPLソフトウェアで、 設定の一括管理 OSに依存しない言語(cfengineの設定ファイル)による統一管理 ネットワーク経由のファイル配信 階層的なホスト管理 条件に応じたジョブ管理 といった機能がある。このcfengineにSubversionなどのrevision control syste
前回は概要を説明した。今回はとりあえずcfservdを起動できるところまで。 cfengineはややこしい。cfservdにcfagent、それにsubversionとcfagentが動作する各ホストのOSおよびdaemonなどを連携させるのだから、環境を作るだけでもおのずと複雑になる。なので、いきなり完全な環境を構築しようとせずに、少しずつcfengineの環境に移行していくのがおすすめ。ゆくゆくはOSのインストールから環境構築までをcfengineだけで実行することも可能なので、ひとつひとつ確実に理解したい。 前提はつぎのとおり。 FreeBSD 6-STABLE cfengine-2.1.20 管理対象のネットワークは10.0.0.0/24 すべてのIP addressに対して適切なPTRが引ける(重要) repositoryは/usr/local/etc/cfengine以下に置く
前回まででcfservdは起動できているはず。 cfagentは2種類のファイルを使用し、どのクライアントも同じファイルを共有する。update.confを使って、update.confそれ自身とcfagent.confをpolicyhostから取ってくる。そしてcfagent.confの指示に従って処理を行う。こうすることにより、cfagent.confが壊れてしまった場合でも、update.confさえまともであれば正常なcfagent.confをクライアントに配布することができる。逆に言えば、update.confを間違えると修正は面倒になる。なので、update.confは必要最小限なものにとどめておくこと。まずは簡単な作業を通じて文法に慣れること。 cfservdの/var/cfengine/inputs/hostsをlocalの/tmpにコピーし、/var/cfengine/b
WEBサーバを数台用意して負荷分散している会社が多いと思います。このような場合必ず悩むのが、どうやって複数WEBサーバへ最新ソースコードを配信するかだと思います。そこで今回はソースコードを複数サーバにコピーする方法について述べてみたいと思います。 【その前にネットワーク確認】 まずはネットワークを確認したいと思います。ほとんどの会社は図1のような感じだと思いますが、安全性を考えればできれば図2のレベルまで持って行きたいところです。 図1 図2 【ステージングサーバを用意しよう】 次に押さえたいのがステージングサーバです。小さな会社ではWEB1にまずは最新ソースを置いて、そこから他のサーバにコピーする方法を取っているかもしれません。しかしいろいろな意味で配信専用のステージングサーバを別途用意することをお勧めします。ステージングサーバを用意することのメリットは １．ステージングサーバもWEBサ
こんにちは satoです WEBサービスは作るよりも運用の方がコストがかかるとも言われています。 運用を極力自動化して、コストを減らしたいものです。 ここではウノウで使っているツール類を紹介したいと思います。 1) 疎通、生存監視 webの生存監視などは nagiosを使って監視しています。 nagiosには - いつ(土日を除く、10時～22時までの間で など) - どのタイミングで(N回連続で ,復旧したら など) - 何が起こったった時に(疎通が取れない など) - どうするか(メールで通知する) などを細かく設定できる監視ツールです。 ウノウでは MySQL、memcached、HTTP、ping、DNS、SMTPなどの監視をnagiosで行っています。 2) システムやアプリケーションLOG ログの監視には swatch を使用しています swatchの機能には -
サーバのレスポンスが遅くなると経験のないサーバ管理者は無意味にメモリ増強を行ったりしますが、行き当たりばったりのシステム拡張は無駄な投資につながります。ボトルネック個所の調べ方は案外簡単なので、この際押さえるところをきちんと押さえて正しい方法論でシステム拡張をしていきましょう。 【一般論】 ボトルネックとなりうる要素は主に４つです。 ①CPU使用率 ②メモリ使用量 ③ディスクI/O ④TCPコネクション数 これらを押さえておけばボトルネック個所の把握とその解消は難しくありません。これを踏まえた一般論を述べてみたいと思います。 WEBサーバの場合は多くの場合、TCPコネクション数から先に限界が来ます。OSやApache等のWEBサーバのパフォーマンスチューニングを十分施すことが前提ですが、その場合TCPコネクション数1万くらいまではなんとか保てると思いますが、それ以上のTCPコネクショ
■ OSC 北海道。 [07/15 11:16] ■ RHEL5対応 [07/15 11:20] ■ Hinemosの新バージョン [07/15 11:06] ■ 2007年度「自治体等におけるオープンソースソフトウェア活用に向けての導入実証」成果報告会 [05/21 18:04] ■ 残席わずか！ 5/22Hinemosソリューションセミナー [05/16 22:14] ■ 5月はHinemosイベント盛りだくさん！ [05/08 20:24] ■ Hinemos実証実験 （IPA） [04/11 11:04] ■ Hinemos ver. 2.4.0 をリリースしました！！ [04/01 17:27] ■ ver.2.3.1クライアント を Ubuntu 7.10デスクトップで試してみました。 [02/18 16:01]
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く