バランスの取れた I/O 構成の環境
機能についての話ではありませんが、ちょっと考えを整理するためのメモとして。 データベースサーバー以外でもそうだと思いますがサーバーを利用する際の基本的な構成は以下のようになるかと思います。 サーバー上でアプリケーションを実行している場合はネットワークは経由しませんが、外部でアプリケーション (サーバーを利用するリソース) が動作している場合、サーバーからの情報はネットワークを介して行われます。 また、接続の形態は SAS/SATA や PCI-e の HBA 等いろいろとありますが何かしらの方法でストレージ (記憶媒体) まで接続がされています。 バランスの取れた I/O 構成を考える場合、これら全体のバランスがどうなっているかを考慮する必要が出てきます。 たとえば、ストレージまでの接続が、 PCI Express 2.0 x4 PCI Express 2.0 x8 で行われている場合、バ
Puppet や Chef で構築したサーバを RSpec でテストする - Gosuke Miyashita
追記 ここに書いてあることを実現する serverspec という gem をつくりました。詳しくはこちらのエントリで。 Puppet マニフェストをリファクタリングするからテスト書くぞ、ってことで、 puppet-lxc-test-box に書いたように、テストするためのシステムコンテナを簡単に作る仕組みをつくったので、今度は実際にテストコードを書くためのベースをつくってみた。 rspec-lxc-test-box こんな感じでテストが書ける。 require 'container_spec_helper' describe 'nrpe' do it { should be_installed } it { should be_enabled } it { should be_running } end describe 'nagios-plugins-all' do it { shou
構築済みサーバを RSpec でテストする serverspec という gem をつくった - Gosuke Miyashita
Puppet や Chef で構築したサーバを RSpec でテストする で書いた仕組みを使いやすくするために serverspec という名前で gem 化してみた。 rubygems.org にも登録してあるので、gem install でインストールできる。 $ gem install serverspec インストールしたら、適当なディレクトリで serverspec-init を実行。すると、雛形となるディレクトリやファイルを生成する。 $ serverspec-init + spec/ + spec/www.example.jp/ + spec/www.example.jp/httpd_spec.rb + spec/spec_helper.rb + Rakefile spec/www.example.jp/httpd_spec.rb がサンプルテストコードで、こんな感じになって
キャパシティ プランニング
1. キャパシティ プランニング 2012/12/14 社内勉強会 外道父@GedowFather Copyright © DRECOM Co., Ltd All Rights Reserved. 1 2. い ジ サ な 見会冗 い ャ ー に て社談 かのは ん ブ バ ？ ら業 だ ジ な 言績 よ ャ ん えを ？ ブ て ！ 使 え ば Copyright © DRECOM Co., Ltd All Rights Reserved. 2
ビルの屋上から落下したサーバーラックが大破する前にサーバの切替を成功させるムービー
仮想データセンターをラックごと高層ビルから落下させ、その間に別に用意した仮想データセンターにフェイルオーバーさせる様子を、シマンテックがプロモーション映像として公開しています。その準備の様子などが詳しく紹介されており、チェックしてみることにしました。 Data Center Down! Behind the Scenes (High Availability & Disaster Recovery) - YouTube アメリカのサンノゼにあるビルの屋上からサーバーラックを落下させようとしているところ。 ものすごいスピードで落下していきます。 サーバーラックは木っ葉微塵。この落下して壊れるまでの間に別に用意した仮想データセンターにフェイルオーバーさせているというわけです。 では、まずはこの実験のためにどれほどの準備がされていたのか見ていくことに。まずは1日目の様子から。 サーバーラックを落
Fabricでサーバー管理をDRYにしよう
7. $ ssh <web/ap server> $ sudo yum update ... $ exit $ ssh <db server> $ sudo yum update • ssh serverA ... $ exit • sudo yum update $ ssh <scm server> $ sudo yum update ... $ exit • お茶を飲んで待つ $ ssh <pm server> $ sudo yum update ... • exit $ exit $ ssh <ci server> • 以下5回繰り返し $ sudo yum update ... $ exit ... 8. $ scp foo.pub <web/ap server>:. $ ssh <web/ap server> $ sudo mv foo.pub /etc/ssh/keys/ $
ファーストサーバ、データ消失事故の再発防止策を発表
レンタルサーバ事業者のファーストサーバは8月10日、6月20～21日に発生した大規模なデータ消失事故に関する再発防止策を発表した。7月31日に第三者委員会から受領した最終調査報告書およびその要約版を基に、開発および運用体制の見直しやデータバックアップの強化、リスクマネジメントに関する組織の設置などを8月24日までに実施するとしている。 再発防止策は、最終調査報告書が指摘した2つの事故（システムメンテナンス作業での過失およびデータの消失）に沿って段階的に実施するという。第1事故（システムメンテナンス作業での過失）に対する実施計画は以下の通り。 再発防止策および実施計画 開発・運用プロセスの見直し（8月10日までに実施完了予定） 1.システム変更のための社内マニュアルを開発プロセス、運用プロセスの視点により検証し、安全性を確認した上で、部内ルールとして再徹底する。 2.潜在的な問題が発見された
サーバのディスクの話
sugipooh @sugipooh 日本にRAIDという言葉が無いころからストレージ障害の近くに居る。 すぐにデータが消えるMO、動いているときに「こつん」とたたくと古い データを消しても平気に動くHDD、それを守るためのRAIDのいい加減さ。 どうしてストレージ障害が起きるか？根本を知らない人が多すぎる。 sugipooh @sugipooh RAID5コントローラを市場で初めて多数売った今は無いMylexへ研修に 行かしてもらった。そのときRAID5でデータが無くなる条件を聞いた。 「簡単に飛ぶ（驚）」。その10年後 日本の会社がその簡単に飛ぶ条件で 多量にRAIDを売っている。おかげでデータ復旧会社が繁盛している。 sugipooh @sugipooh 「簡単にデータが飛ぶ」RAID5でビジネスを辞めたが、その頃から市場では ビジネスが拡がってゆく。正直なビジネスは儲からない。 対
ともちゃ日記 - 元大学生の悪魔^H^H魔神ＯＬ日記- 激安VPSの上手な使い方、使い分け
そのほか、DNSサーバやメールサーバなどを運用するとき、セカンダリDNSや、バックアップMXをOsukiniVPSといった使い方をすれば、メイン側がメンテナンスや障害でも、バックアップが出来る。そのため、バックアップシステム、データのバックアップサーバとして構築すれば、一石二鳥である。 上記の構成例であれば、OsukiniLTは、初期費用がかかってしまうが、ダントツにやすい。飲み会１，２回我慢すれば終わりだし、自宅サーバで電気代を考えても断然やすい。 そのほか、 NTTPC WebArena の Cloud9やSuitePro、 お名前.com VPSなど、他のVPSを使用している場合でも、上記のような構成で、バックアップを行っていれば、最悪な事態にはならないだろう。 また、バックアップ側が障害でデータが消えたとしても、主系サーバが生きていれば、改めてバックアップを取ればよいこと。 基本的
UnicornでSinatraアプリをデプロイしてみた - 射撃しつつ前転 改
最近は仕事でSinatraアプリを書いたりしているので、Sinatraアプリを動かすためにはどのHTTPサーバを使うのがベストなのかが気になっている。（先に結論を書いておくけれど、どれがベスト、という唯一の選択肢は今のところありません。適材適所です。） SinatraはRackの上に構築されているので、Rackに対応したHTTPサーバーを使って動かす事になるのだが、この数がやたらと多く、どれを使えばいいのか迷う。代表的なものを挙げただけでも、WebRick, Mongrel, Thin, Unicorn, Passenger(Apacheとかに組み込んで使うやつ), FastCGI, (普通の)CGI、これぐらいは選択肢がある（いくつかHTTPサーバじゃない物も混ざっているが、Rackが対応してるという点は共通している）。 WebRickはそもそもパフォーマンスに重点を置いていないし、Mo
ISUCONに参加してきた - inuzのブログ
まずは運営のライブドアの皆さま、楽しいイベントをありがとうございました。 さて、俺id:inuzことTwitterID: inuwarumonoは同じ会社のアプリ屋2名と一緒に、チーム名「ツヤマ倶楽部」として出場してきたのでそのメモ/レポートを。 出場者3名とも名前はツヤマさんでは全然なくて、ツヤマというのは弊社技術部門の最高責任者の名前。(会社名は非公開)。 俺はインフラ/ミドルウェア屋なので、主にOSやらミドルウェアの最適化を考える担当。あとの2名はアプリケーション側からの切り口での改善と、それに伴うミドルウェアの最適化。両面からのアプローチというのが当初の作戦だった。 事前準備が肝、ということでツヤマ倶楽部の面々が考えていた事前対策は以下のとおり。 DBのクエリ解析が肝になるはず。的確にボトルネックを探すには断然クエリアナライザ。 パフォーマンスモニタリングが重要、でもまぁsarで良
livedoor Techブログ : 自家製 #isucon のつくりかた
こんにちは、ISUCON というイベントのレギュレーションを考えたり環境の準備をやったりコード書いたりしてた tagomoris です。普段はライブドア開発本部のインフラサービス部というところで働いてます。 先日ISUCONは幸いにも大好評のうちに終了したのですが、へとへとになって疲れ切った状態で帰宅し、寝て起きてみると、公開しておいたソースコードをさっそく自分の手元で動かしている人がいました。説明とか何にもなかったのによくそこまで。どういうことなのと思わずにはいられません。 #isucon に参加してきました＆isuconツールを試してみました - As a Futurist... また翌日にはTwitterでも続々と動かしてみた報告が見られ、エンジニアのみなさんのバイタリティには感服するばかりです。 ざいりょう で、せっかくだから本番と同じデータで同じように試せるようにしたいよね、とい
isuconに参加してきました
どうもコンニチワ。 去る2011.8.27に開催された なんでもありのWebアプリケーション高速化バトル、#isucon に、チーム「いんふらえんじにあー」として @matsuu さん、 @ishikawa84g さんと参加してきました。 チーム名は2秒くらい考えてこんなものしか思いつきませんでした。 チーム名を決めなければならないということに気づいたのは、要返信のメールの締切を2日過ぎてからのことでした。相談なしに決めてゴメン。。。 ともあれ結果は2位 3位。1位とは大差！2位とは僅差！すごくすごく楽しかったです。 主催のライブドアさん、ありがとうございました！ さて、今回も結果が出てほっとしました。 今回はチームメイト @matsuu さんがすでに詳細書いてくれているのでそちらを見ていただくと紆余曲折を感じていただけるかと。 →isuconに参加してきた＆チーム「いんふらえんじにあー」
サーバはデータセンターの中を液体のように流れるような存在になる、という仮説
先日、あるIT関係の集まりで、大手ネットワーク機器ベンダの偉い人がこんな話をしてくれました「最新のイーサネットは、サーバの内部バス並のスピードで通信ができる。これはすごいことだよね」と。 いま市場では10ギガビットーサネットが普及し始めているところですが、すでにその次の世代のイーサネットとして40ギガビットイーサネットと100ギガビットーサネットも昨年、IEEEによって標準化されており、まだ非常に高価ですが製品が登場し始めています。 その話を聞く少し前、僕は別の大手システムベンダの偉い人のこんな話を聞いていました。「これから2年もしないうちにサーバの形が大きく変わっていく。すごく面白くなるはずだ」と。 この2つの話はつながっているように思えました。 サーバは液体のように流動的で論理的な存在に クラスタを構成するネットワークが内部バス並みに高速になれば、あるサーバの負荷が高まってきたときには
私家版省サーバ運用2011またはWebシステムのコンポーネントの配置について - blog.nomadscafe.jp
小規模のサービスを如何にスモールスタートするか、そのために各コンポーネントをどうやって配置するのがいいのかという話。個人的な考えも含めて。 大まかな構成は昨年のnekokakさんのYAPC::Asiaでの発表、省サーバ運用と大体同じです。Web/Appに使うサーバ2台、データベース2台です。あとはLBが別にあればそれを、なかったらもう一台(組)必要となります。 Web/Appサーバには、Reverse Proxy、Application Serverがまず配置されます。あとは必要に応じてmemcached、Job Queueのworkerを動かします。ここまでのコンポーネントは2台のサーバ両方に配置し、Active-Activeで動作し冗長性がとれるよう構築します。cronについては、両方のサーバで動かしても問題がない状態が理想ですが、そうでない場合、Web/Appの1台目で動かすというル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mizzy/serverspec: RSpec tests for your servers configured by CFEngine, Puppet, Chef, Ansible, Itamae or anything else even by hand
SSDやioDriveモデルも最速10分納品、「さくらの専用サーバ」新シリーズについて聞く 
Realtime event-driven monitoring system with CEP
7 Open and Free Network Servers | ServerWatch
hbstudy25 劇的ビフォーアフター
