第1回 システム自動管理ツールの必要性とPuppetの概要 | gihyo.jp
はじめまして。株式会社 paperboy&co. の宮下と申します。 この連載では、最近注目を集めているRuby製のシステム自動管理ツールPuppetについて、その概要から具体的なシステム管理への適用まで、実際の現場で利用するために必要な情報をお届けします。 システム管理とは システム管理と一口に言っても、以下のような様々なタスクから構成されます。 ハードウェアの設置 ネットワークへの接続 OSのインストール/設定 ネットワークの設定 OSへの最新パッチ適用 ソフトウェアのインストール/設定 OS/ソフトウェアのアップデート OS/ソフトウェの設定変更 細かく言えば、他にもタスクは色々ありますが、これらのタスクを通じてシステムを「あるべき状態」に維持するのがシステム管理である、と言えるのではないでしょうか。 システム自動管理ツールの必要性 それでは、システム管理の自動化はなぜ必要なのでしょ
連載：そろそろLDAPにしてみないか？｜gihyo.jp … 技術評論社
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
連載：オープンソースなシステム自動管理ツール Puppet｜gihyo.jp … 技術評論社
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
ライブドアデータホテルパトロール 無料サーバ・ネットワーク監視サービス
「DATAHOTEL PATROL」サービスからのアラートメール誤配信のお知らせ（2019年4月3日） 2019.04.03 平素は大変お世話になっております。 掲題の通り、既にサービス提供を終了しております、「DATAHOTEL PATROL」 サービスにおきまして、3月30日から31日にかけて、以前ご利用のお客様のメールアドレス に対してアラートメールが誤って配信されました。 メールを受信された皆様には、ご迷惑お掛けしまして、大変申し訳ありませんでした。 本事象の原因は、サーバ撤去時の誤作動により、誤って監視が再開され、アラートメールが 配信されたことによるものでございます。 該当サーバは既に撤去及びデータ消去を実施済みのため、メールは配信されないよう 対応させて頂いております。 お客様におかれましてはご不便をお掛けいたしましたことをお詫び申し上げます。 今後とも弊社をご愛顧くださいま
16 Commands to Check Hardware Information on Linux
Hardware information Like for every thing, there are plenty of commands to check information about the hardware of your linux system. Some commands report only specific hardware components like cpu or memory while the rest cover multiple hardware units. This post takes a quick look at some of the most commonly used commands to check information and configuration details about various hardware peri
今更聞けない人の為の Chef 再入門
こんにちは、エンジニアの鈴木です。 「今更聞けない人の為の Vagrant 再入門」に引き続き、今回は Chef 再入門をお送りします。 この記事は以下のような人を対象としています。 ・Chef ってそもそも何？ ・Chef って名前を聞いたことあるけど、触ったことがない。 Chef ってそもそも何？ Chef(シェフ) とは Ruby 製のシステム構成管理ツールでインフラの構築を自動化できます。 サーバを弄ったことがある人なら誰しもが経験していると思われる「手順書」の作成。 手順書からコマンドをコピペして、ユーザ作成してWebサーバいれてDBいれて。。あとからこのパッケージが必要になったから手順書を変更して。。 どう考えてもオペミスの温床になります。 Chef はインフラをすべてコードで管理するので、Gitなどでインフラを管理でき、いつどこで誰が修正したのか分かるのでドキュメントや構築手
サーバのトラブルシューティングにsysdigが使えそう - $web->{note};
sysdig とは？ Sysdig is open source, system-level exploration: capture system state and activity from a running Linux instance, then save, filter and analyze. Think of it as strace + tcpdump + lsof + awesome sauce. With a little Lua cherry on top. http://www.sysdig.org/ 上に書いてある通り、一言で言うと strace + tcpdump + lsof + α。tcpdumpのように-wで書き出して-rで読み込めるのがありがたい。 高機能過ぎてまだ全然使いこなせてないけど、ぱっと触った感じ使えそうだなと思ったものを紹介。 1. プロ
Sensuを使って自由度の高い監視システムの構築を行う方法
SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります（公式サイトの記述を整理） シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象）を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubでホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens
DeNAが社内利用しているMySQLの自動フェイルオーバーツール、オープンソースで公開開始
MySQLがダウンしたときに自動的に別のMySQLへ処理を引き継ぐことで、高可用性を実現するフェイルオーバーツール「MySQL-MHA: MySQL Master High Availability manager and tools」がオープンソースとして公開されたことを、作者の松信嘉範（まつのぶよしのり）氏がブログで伝えています。 Yoshinori Matsunobu's blog: Announcing MySQL-MHA: "MySQL Master High Availability manager and tools" 松信氏はモバゲーなどで知られるDeNAに勤務しており、MySQL-MHAによる自動フェイルオーバー機能はDeNAのインフラ運用を支えているとのこと。同氏のブログから引用します。 Difficulties of master failover is one of
サーバのリソース使用状況レポートを作る - mikedaの日記
数百台のサーバに対して CPU メモリ HDD の使用状況をサクッとチェックしたいなーと思ったのですが、さすがにmuninのグラフで見るのはダルすぎる。 というわけで日次でこういうページを作ってチェックするようにしました。 上記の情報が数字でダーっと並んでて、ついでに簡単に色付けとか、muninへのリンク張りとか、各項目でのソート機能付けたりとかをやってます。 CPUとメモリの使用率は前日の平均、ディスク使用率はバッチ実行時の値です。 最初はmuninのRRDファイルから作ろうかと思ったのですが（gist）、この程度の情報ならsysstatやdfの結果から作るほうが簡単なので、sshで集めてくることにしました。 とりあえずHTMLに出力してますが、CSVで出したりDBに突っ込んだりすれば各種調査に便利ですよ！ ソースコード Ruby1.9版です #!/usr/local/bin/ruby
0×0018 till I die » はてなnaoyaさん「はてなを支えるバックエンドシステム」
403 Forbidden nginx
mixiのサーバOS移行のお話 - 前回補足＆インストール編 - mixi engineer blog
こんにちは。新しもの好きが集まる運用部アプリ運用グループの清水です。 前回の記事では、多くの反響をいただきました。ありがとうございます。 Twitterや、はてブのほとんどのコメントを読ませていただきました。 みなさんのOSの宗派が垣間見えた気がします。 さまざまなコメントをいただいていた中で、よくある代表的なコメントについて、改めてこの場を借りてお答えしたいと思います。 2012年12月28日追記: 以下のQAにつきまして、いわゆる"ネタ"として書きましたが、誤解を招き、不適切な表現で不快な思いをされた方々へ深くお詫び申し上げます。 また、QAの一部に関わるところですが、OS標準のパッケージを否定するつもりは全くございません。 Linuxを安心して使うことができるのは、Linuxディストリビューションに携わっているデベロッパーの方々の素晴らしい活動や成果によるもの、というのが揺るぎない事
サーバ管理の仕組みを作り始めた話 - Kentaro Kuribayashi's blog
先日(10/9)、riywoさんさんの呼びかけにより、サーバ管理をどうやったらいい感じなるかを話し合う会がもたれました。僕は、直接サーバ管理をやっているわけではないのですが、社内でそういうの欲しいという話をしていて、ツールを作りたいといっていたので、参考になればというわけで、お誘いいただいて参加してきたのでした。 riywoさんから、叩き台としてホストのキーを元にした統合的なAPIの構想を図式化したスライドを提示していただいた後、管理システムの主なユースケースや、各社の実際の管理手法などをいろいろお話をうかがいました。僕など、インフラ的な知識に乏しいもので、これはなかなか大変なことだなあというのがあらためてわかりました。 組織体制や経理ルールの複雑性が各社でだいぶ違う サーバの情報として必要な属性が各社でだいぶ違う そもそもサーバの情報が複雑 既にあるなんらかの管理の仕組みとの整合性を取る
はてなブックマークの裏側その後 - naoyaのはてなダイアリー
まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000
マルチコア時代のロードアベレージの見方 - 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分ごとのシ
実録、ほぼ無停止な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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF]第4回 PPTPを使用したリモートアクセスVPNの仕組み![[PDF]第4回 PPTPを使用したリモートアクセスVPNの仕組み](https://cdn-ak-scissors.b.st-hatena.com/image/square/745dbedd5d4da3a92973ece57a841d4ca8af1646/height=288;version=1;width=512/https%3A%2F%2Fperfectdomain.com%2Fstatic%2Fimg%2Fupload%2Fseo-acquisition.png)
AWS費用試算例 · さよならインターネット