新米Linux管理者がよくやる10の間違い
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 多くの人にとって、Linuxへの移行は喜びに等しい出来事だ。だが、悪夢を経験する人もいる。前者ならば素晴らしいが、もし後者なら最悪だ。しかし、悪夢は必ずしも起きるわけではない。特に、新米のLinux管理者が犯しやすい、よくある間違いをあらかじめ知っていれば、悪夢を避けられる可能性は高いだろう。この記事では、いくつかの典型的なLinuxでのミスを列挙する。 #1：さまざまな手段でアプリケーションをインストールする これは最初は悪いアイデアではないように思える。もしUbuntuを使っていれば、パッケージ管理システムが.debパッケージを使っていることを知っているだろう。しかし、ソースコードでしか見つけられないアプリケーションも多くある。大し
スラッシュドット・ジャパン | サーバ監視、何使ってる？
SF.JP Magazineで「Webインタフェースでマシンを監視する4つの方法」という記事が掲載されています。Webインタフェースを持つ4つのサーバ監視ツール（collectd、Cacti、Monitorix、Munin）の特徴をそれぞれ解説した記事で、筆者は記事の末尾で以下のように述べています。 データをじっくりと分析する場合や、管理者以外のユーザからもシステムの統計情報を参照できるようにする場合は、最初にCactiをあたるのがよさそうだ。すでに十分な負荷がかかっているシステムで情報収集を行うなら、システムに与える影響の小さいcollectdを試せばよい。また、多数のノードで個別のアプリケーションパッケージを使って情報を集めるMuninは、同じようなマシンで構成される小規模なグループの監視に向いており、1台しかないサーバの状態を手っとり早く把握したければ、とりあえずCactiかMoni
"make install"したソフトウェアを管理できる超便利ツール「Paco」 - RX-7乗りの適当な日々
最近、Linuxではaptやyumなど、パッケージ管理ツールで多くのアプリケーションやライブラリが管理されるようになり、普通に利用している限りはソースからコンパイルして"make install"することがほとんどありません。 とはいっても、マイナーなソフトウェアをインストールしたりとか、まだパッケージ管理されていない最新バージョンのものを使いたい場合などは、ソースからコンパイルして"make install"をしたくなる場合も有るかと思います。 しかし、"make install"した場合の最大の欠点は、インストールしたソフトウェアの管理ができないことにあります。そのため、何が入っているのか分からなくなっているとか、アンインストールが出来ない、などのケースが起こりうるわけです。 特にアンインストールする可能性があるソフト(ほとんどのソフトがそうですが・・・)をインストールする場合は、わざ
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
DSAS開発者の部屋:特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します
『Linuxロードバランサ構築・運用ノウハウ』を公開します！ これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。 一口でいうと、「Linux＋IPVS＋keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、 サーバ負荷分散一般についてのはなし Linuxでロードバランサを作ってみる ロードバランサを冗長化 といった構成になっています。 みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください！ 第1章 サーバ負荷分散概論 特集のはじめに なぜサーバ負荷分散をするのか？ サーバ負荷分散の実現方法 ロードバランサのいる構成 ロードバランサはなにを元に分散す
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
naoyaのはてなダイアリー - 負荷とは何か
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
さくらインターネット移行記#2 VPN越しのMySQLレプリケーション
前回さくらiDCに移転し始めた、ということを書いたのですが、あれから一ヶ月ちょっとが経過しましてその後も順調に iDC への移転が進んでいます。すでにラックもいくつか借りて、サーバーも数十台がさくら iDC で稼動しています。回線がこれまでよりも高速なバックボーンに接続されつつ、帯域幅も大きくなったことから、移転したサービスによってはこれまでよりもパフォーマンスが出ているサービスもあります。うち比較的大きなデータを扱うフォトライフも移転を完了していますが、おかげさまで画像の読み出しがかなり速くなったのが体感できるぐらいスループットが向上しました。 既存サービスを移転するにあたって、どういった構成でそれを行っているかをちょっと紹介してみようと思います。 移転当初は、既存のはてなのサービスとはあまり関係していないサーバー群から手を付けました。例えば広告のシステムといった、はてなのデータベースを
naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転
さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸
_ [Ruby][システム管理] システム管理の自動化ツール puppet が熱いらしい - Don'tStopMusic(2007-03-19)
_ [ネットサービス] Yahoo! Pipes で del.icio.us のフィードをフィルタリングする eban さんがdel.icio.us の rss を Yahoo! Pipes でフィルタリング したというのを読んで私もやってみることにしました。 大まかには Yahoo! US に登録 Pipe を作る 作った結果の RSS を bloglines に登録 Pipe 作成を細かく説明しますと、 User Inputs の URL Input を配置。default に http://del.icio.us/rss/tag/rails を入力。Name と Prompt は適当。他は空白のまま。 Sources の Fetch を配置。URL Input と繋ぐ。 Operators の Filter を配置。Fetch と繋ぐ。"Block" items that matc
DSAS開発者の部屋:GREEさんの勉強会の資料を公開しました
先日発表してきた、グリーさんの 第9回 オープンソーステクノロジー勉強会 『DSASのいろいろ』の発表資料と音声を公開しました。 発表資料 (PDF, 2,294 KB) 音声 (mp3, 32,151 KB) 発表はこんな内容です。 自己紹介 [0:22] (1) DSASの特徴の紹介 [6:34] 設計思想、全体構成など (2) DSASの構成要素の紹介 [17:22] ロードバランサ - LVS, keepalived [17:33] ネットワークブートの活用 [30:23] 故障に強いストレージサーバ - DRBD [37:15] NICの二重化 - bonding [44:29] シリアル接続 温故知新 [46:24] サーバリソースの見える化 - ganglia [49:11] 質疑応答 [58:00] 発表はかなり駆け足でしたが、 ロードバランサ (LVS, keepaliv
DSAS開発者の部屋:keepalivedの運用ノウハウお見せします 〜 設定ファイルを同期する
keepalivedはLinuxで冗長構成を組む道具としてとても便利ですが、運用面に関する配慮に物足りなさを感じることがあります。例えばIncludeがないとかIncludeがないとかIncludeがないとか（笑） naoyaの日記でnaoyaさんも悩んでいるようですが、設定ファイルをうまく保守する仕組みをどう作るかが導入する際の大きな鍵になると思います。今回は、DSASではどのようにして2台のkeepalivedを運用しているかを少しだけご紹介させて頂きたいと思います。 1) マスターで設定ファイルを編集する 2) バックアップに設定ファイルを転送する 3) バックアップで設定を反映する 4) マスターとバックアップの差分を確認する 5) マスターで設定を反映する 具体的にはどのようにしているかというと、、、 lv1:# vi 設定ファイル lv1:# lvs-sync -ine lv1
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
複数のサーバのモニタリングソフト
Linux、Windows、FreeBSD、Mac OS Xで動作可能なサーバモニタリングソフトウェアです。フリーで利用できるバージョンであっても商用利用可能で、30個までのサーバを一元監視することができます。 HTTPなどの各種サービスの監視はもちろん、CPU負荷やメモリ、温度の詳細なグラフ出力やレポート出力も可能。サービスが落ちたかどうかの判断基準や、落ちた場合の通知方法はグラフィカルに条件分岐のダイアグラムから作成可能で、その際に実行するスクリプトなども指定できます。 ソフトウェア自体は監視するBixAgent、監視エージェントから送られてきた情報をまとめるBixServer、そしてその監視結果を表示して確認するためのBixDesktopで構成されています。 詳細は以下の通り。 BixData | Cluster and Systems Management http://www.b
[ThinkIT] 第3回：データレプリケーションとWebサーバの構築の基本 (1/4)
今回はRHEL4でrsyncコマンドを使ったデータレプリケーションによるバックアップ環境の構築方法について解説します。 rsyncコマンドを使ったデータレプリケーションは、LAN経由によるDisk To Diskバックアップとも呼ばれています。これはバックアップ対象のサーバとバックアップサーバがLANで接続されており、バックアップサーバ側はテープ装置ではなくハードディスクにバックアップデータを保管するからです。 この接続しているLANは、通常だと業務用のLANとは別にバックアップ専用のLANを敷設し、その専用のLAN経由でrsyncコマンドを実行します。 rsyncコマンドの利点は、なんといっても差分バックアップが可能という点です。 はじめにフルバックアップを取っておけば、次回以降では差分バックアップを行うためバックアップ時間は初回時に比べて非常に短くなります。そのためデータ容量が大きくて
DSAS開発者の部屋:サーバ管理者向け無精のすすめ 〜ちょっと便利なツールの紹介〜
弊社のLinuxサーバ、ネットワークインフラのDSASの特徴のひとつに、100台近くある全てのサーバの内容が(数個の役割設定ファイルを除いて)同期されているという点があります。 これにより、 スケーラビリティ 予備機をサービス投入するだけで済むので、テレビCMなど突発的な高アクセス時にも迅速な対応が可能です。 増強が容易 サーバをラックマウントしたら適当なサーバからまるまんまコピーすればクラスタに参加可能です。まとまった台数の増強をする際に、いちいちCD-ROMからOSをインストールしていると日が暮れちゃいます。 役割の変更が容易 ディスクの内容が同じなので、もし、メールサーバが故障しても、適当なWebサーバの役割設定ファイルを変更して再起動するだけでメールサーバに早変わりできます。 メンテナンスが容易 ディスク上のファイルを更新した場合は、rsyncなどで全サーバに同期コピーすれば更新完
cyano
ユーザーがページをロード開始してから閲覧できるようになるまでのロード時間はユーザーが自分のページを快適に閲覧できているかどうかを示す重要なファクターです。Google Analyticsのイベントという機能を使用することで、ユーザーの実際の体感速度を可視化することができます。 たとえば、このブログのある期間における体感速度のグラフはGoogle Analytics上で以下のように出ています。 44.84%のユーザーは100〜499msでロードできており、1秒未満でロード完了しているユーザーは合わせて73.49%であるとわかります。また、3秒以上かかっているユーザーも7.42%居ることも分かります。3秒以上ロードにかかるようだと離脱率も高くなるので、7.42%のユーザーに対して何かの施策が必要であるということも分かります。 このように、ユーザーが実際感じている体感速度を可視化することで、この
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux でのバックアップを自動化する
mputの日記。 - , rootのパスワードは潰さないほうがいいと思う件
IBM Developer