mod_mod: Apache module を動的にコンパイルして実行する Apache module : DSAS開発者の部屋
現在 WEBアプリケーションの開発言語といえばいわゆる Light Weight Langage が主流の様な気がしますが、C言語で WEBアプリケーションを書きた いと思った時、どのような方法があるでしょうか。一つはコンパイルした実行 オブジェクトを CGI として呼び出す方法、もう一つは apache module を書く という方法があると思います。 CGI の場合プロセス起動のオーバーヘッドがありますが apache module の 場合非常に高速です、にも関わらず apache module による WEB アプリケーショ ンの開発があまり流行っていないのはやはり、コード変更の度にコンパイルし なければならない事と、反映の際に apache を再起動しなければならない事が 原因ではないかと思います。 そこで、apache module っぽい C言語のコードをサーバー上で動的に
高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋
「こんなに簡単！ Linuxでロードバランサ」のシリーズでは、 こんなに簡単！ Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単！ Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単！ Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや？」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調
こんなに簡単！ 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をお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
ディレクティブの処理と設定値の利用 (apache module 開発事初め その3) : DSAS開発者の部屋
今回は前回の記事で予告した通り，Apache の(いくつかのタイプの)モジュールが動作するべきか否かをどうやって判断するか，というお話です．タイトルは「ディレクティブの処理」となっていますが，モジュールがディレクティブを処理することと今回のテーマは密接に結びついています． モジュールが，というよりも厳密には各種 hook が，呼び出された際に処理をするべきか否かの判断は，大体の場合そのモジュール用の設定ディレクティブが設定ファイル(httpd.conf)にあるか否かで行います．handler の場合は前々回の記事でも出てきたように，汎用の handler 指定用のディレクティブがあります．(hook ではないですが) filter も，Input/Output filter のための設定用ディレクティブがそれぞれあります．もちろん，必ずこれらのディレクティブを使わなければならない，という訳
アクセス制御モジュールを作ってみる (apache module 開発事初め その2) : DSAS開発者の部屋
前回の記事では，apxs が生成したテンプレートをそのまま動かしてみましたが，今度は少しコードを書いてみましょう．同じ handler を作っても面白くないので，アクセス制御をするモジュールにしてみます．Apache のアクセス制御は2種類あって，一つはユーザ認証を目的としたもので，mod_auth の眷属がそれです．もう一つはリクエストの別の側面，例えばクライアントのアドレスによってアクセスを許可したり拒否したりするもので，標準モジュールでは mod_access がそれに当たります．あまり複雑なことをしても話が見えにくくなるので，今回作るモジュールではランダムにアクセスを許可したり拒否したりすることにします． apxs -g -n denyrandomとして出力したものをベースにしています)． 1 #include "httpd.h" 2 #include "http_config.h
apache module 開発事始め : DSAS開発者の部屋
先日は，必要に迫られて Apache 1.3 の mod_access を改造したという話を書きました．その時は単にあるものを改造しただけでしたが，ふと思い立って，一から Apache 2.0 用のモジュールを書いてみました．書く上で色々 Web サイトを探してみたのですが，あまり日本語の入門向けの文章が見あたらなかったので，開発する上で分かったこと(と言うほど大したものじゃないですが)をまとめておこうと思います． フェーズには，例えばそのリクエストを受け付けるか拒否するかを決めるフェーズや，リクエストされた URI と実際のディスク上のファイルとの間の対応付けを解決するフェーズ，そしてもちろん実際のレスポンスを生成するフェーズ等があります．hook 関数を挿入するポイントはこれらのフェーズになりますが，もちろんその全てのフェーズのための関数を用意する必要はありません．また個別の設定を施す
Linuxでクラッシュダンプを採取(1) 〜 kexec + kdump を使ってみる 〜 : DSAS開発者の部屋
専用パーティーションを切らずにシステムを構築してしまったがために、クラッシュダンプを採取できなくて苦しんでいる人（って私ですが）にとってはとっても魅力的な仕組みがカーネルに取り込まれたみたいです。導入手順も Documentation/kdump/kdump.txt に非常にわかりやすく書かれているので、比較的スムーズに組み込むことができそうな予感がします。 kexec の機能を利用して別のカーネル（kdumpを組み込んだもの）を起動すると、/proc/vmcore から元のカーネルのクラッシュダンプを採取できるというものなので、通常利用するカーネル（以下、ファーストカーネル）と、パニック時に動き始めるカーネル（以下、セカンドカーネル）の二つのカーネルを作る必要があります。 以下、kdump.txt より抜粋 A) First kernel or regular kernel: -----
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
