こんなに簡単！ Linuxでロードバランサ (3) : DSAS開発者の部屋
前回はkeepalivedを使ってWebサーバを冗長化してみました。 今回はkeepalivedのもう一つの機能であるVRRPを使って、ロードバランサ自身を冗長構成にしてみたいと思います。 ┌─────┐ │ client │ └──┬──┘ │[10.10.31.200] │ ━━━━━━━┯━━━━┷━━━━━┯━━━━━━━━━ 10.10.31.0/24 │ │ │ │ │ ←(10.10.31.10) → │ │ ←{10.10.31.100}→ │ [10.10.31.11]│ │[10.10.31.12] ┌─┴─┐ ┌─┴─┐ │ lv1 │ │ lv2 │ └─┬─┘ └─┬─┘ [192.168.31.11]│ │[192.168.31.12] │ ←(192.168.31.10)→│ │ │ ━━━━━━┯┷━━━━━━━━━━┷┯━━━━━━━━ 192.168.3
こんなに簡単！ Linuxでロードバランサ (2) : DSAS開発者の部屋
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜
DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │
節約のためにこころがけること | 赤と黒
僕は細かい（せこい）性格なので、1円単位で収支や財産の記録をしているのだが、たいがいの人はそうではないらしい。当たり前か。 しかしそんな僕も、社会人になりたてで「お金のつかい方」が未熟だったころ、別に何をしたわけでもないのに200万もの借金ができたことがある。 このままじゃまずい、と思ってはじめ、今でも実践している節約法が何かのお役に立てればいいと思うので書いてみる。 ■給料の一定額をまず貯金 「金持ち父さん」なんかにもでてくる基本中の基本だけど、やっぱり一番大事。 できれば金額ではなく割合がいいのだが、強制的に貯金に回すという習慣が大事。 サラリーマンの人なら財形貯蓄に入るのもいいし、証券口座を持っている人は、毎月MMFで預貯金よりはるかにいい利子が得られるのでそこにいれちゃうのもよし。 ■毎月の支出額を大体把握する 家計簿をつけるのが一番いいのだけど、やはりなかなか難しい。 でもとりあ
jQueryを良くする25のTIPS
jQueryを良くする25のTIPS ネタ元：Improve your jQuery - 25 excellent tips ちょっと多いですが、かなり良いTIPSがまとまっています。 Google AJAX Libraries APIを利用しよう Google AJAX Libraries APIを活用すればすばやくライブラリを読み込むことが出来ます。 <script src="http://www.google.com/jsapi"></script> <script type="text/javascript"> // Load jQuery google.load("jquery", "1.2.6"); google.setOnLoadCallback(function() { // Your code goes here. }); </script> 直接読み込むことも出来ます。
memcachedを愚弄する１つの方法 - グニャラくんのグニャグニャ備忘録@はてな
某サービスでセッション情報を保持するために利用している memcached(repcached)に障害が起こった。 ちゃんと追えていないけど、おそらく以下のような原因。他の人がハマらないように。 障害発生まで memcached(repcached)の中には揮発したらそれなりにマズい情報が入っている。 repcachedサーバ２台のOS入れ替えをしていて、１台は再起動が成功した。 １台目のサーバへ２台目のサーバからのレプリケーションが完了したのをstatsのcurr_itemsにて確認した。 よって２台目を再起動するものの、起動しなくなった。 この時点では、１台は生きているから後でデータセンターいこうっと、という気軽な気持ちだった… 現象 生きている１台目のサーバで、以下のような現象が起こった… 値をsetする際に、ある閾値以上のexptimeを指定すると即expireされる。 その閾値は
PHPとjQueryでCometっぽいモノを実装する - Rewish
クライアントからのリクエストに対してすぐに応答せず溜めておき、何らかのタイミングを見計らって応答する技術。 Comet - Wikipedia 例えばチャットなんかで使うと、相手が発言したタイミングでレスポンスが返ってくるので、リアルタイムに会話が出来たりする訳です。 ※あくまでも実装の一例なので、このままでは利用シーンがかなり限定される事をご留意下さい。 注意事項 以下の実装方法は、知識的なコストがあまり必要ない替わりに、サーバー的なコストを多く消費します。 共有レンタルサーバーなんかで使うと、アカウント制限・停止などの処置がとられる場合があるので、共有で使うスペースなどでの使用は避け、専用サーバーや自前のサーバーなどで使用して下さい。 Comet動作の流れ 大まかな流れはこんな感じです。 Ajax(XMLHttpRequest)を利用してサーバー(PHP)にリクエストを送る リクエスト
ローカルでのコミットを１つにまとめてSubversionにコミットする方法 - ぷぎがぽぎ
個人のリポジトリならいいんですが、共有しているリポジトリではコミットはある程度"意味のある単位"で行った方が親切です。 「もう帰るけど作業は途中。とりあえずコミット」をされて、そうとは知らずに、中途半端な動かないソースでアップデートしちゃったもんだからアプリが動かないとか悲しすぎます。 だから、ローカルに自分専用のミラー（ローカルリポジトリ）を作成し、そこにはガンガンコミットしておいて、タスクが終わったらまとめてサーバー側にコミットするという作業に意味があります。 また、ネットワークにつながっていなくてもガッツリと開発が行うことができるのも魅力です。 イメージとしては以下のような感じです。 <これまでの管理> コミット => (サーバーのリポジトリ) <分散管理> コミット => (ローカルのリポジトリ) => コミット => (サーバーのリポジトリ)ツールとしては分散リビジョンシステムと
gitosis - Git リポジトリ群の管理とアクセス制御 vol.1 - openbooth
gitosis - Git リポジトリ群の管理とアクセス制御 vol.0 の続編です。 前回のエントリでは、Git リポジトリの管理に対する不満と、それを少し改善してくれる gitosis を簡単に紹介をしました。このエントリでは gitosis のインストール編ということで話を進めていきます。 基本的に Hosting Git repositories, The Easy (and Secure) Way のエントリと同様です。本家の方が安心という人はそちらのエントリをどうぞ。 サーバ/クライアント(ローカル)両方で作業する必要があるので、識別しやすいように以下の表記をします。 サーバ作業のプロンプト表記 remote% クライアント(ローカル)作業のプロンプト表記 local% また、サーバアドレスを便宜上 remote-name.com とします。 まずは Git リポジトリをホ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Greenbear Laboratory - SVKを使ってみよう