7月 19th, 2009
LoadBalancerのヘルスチェックを実施しているが、VirtualHost全? ぜ BASIC認証がかかっている場合など、特? ぜ URLのぜ BASIC認証を除? したい場合がある。以? がその設定例です。
Satisfy Any
AuthType Basic
AuthName “Password Required”
AuthUserFile conf/password.dat
Require valid-user
SetEnvIf Request_URI “/healthcheck.html” healthcheck
Order Deny,Allow
Deny from all
allow from env=healthcheck
Satisfy ディレクティブは、Allow ぜ Require の両方が使゜ れているときぜ アクセスポリシーを設? します。デフォルト? “All”は、クライアントがアドレスによる アクセス制限を満たし、かつ正しいユーザ名とパスワードを入力することを 要求します。この値を”Any”にすることによって、クライアントはホストの制限を満たすか、 正しいユーザ名とパスワードの入力をするかどちらかでアクセスを許可されるようになります。上記設? 例の場合、「/healthcheck.html」というリクエストURIの場合に限っては、Allowで指定したアクセスポリシーを許可するので、Requireで? 求されているBASIC認証をパスしなぜ てもアクセス可能となります。
http://httpd.apache.org/docs/2.2/mod/core.html#satisfy
7月 17th, 2009
Apache2.0以降では、apachectlのコメントには以下のような注釈がある。
# The exit codes returned are:
# XXX this doc is no longer correct now that the interesting
# XXX functions are handled by httpd
# 0 – operation completed successfully
# 1 -
# 2 – usage error
# 3 – httpd could not be started
# 4 – httpd could not be stopped
# 5 – httpd could not be started during a restart
# 6 – httpd could not be restarted during a restart
# 7 – httpd could not be restarted during a graceful restart
# 8 – configuration syntax error
ここに? 義されたexitステータスは既に正しぜ ないです、httpdコマンドぜ exitステータスをそのまま蜿 します、という? 味のようだが、確かぜ Apache1.3.x辺りのバージョンでぜ apachectl内ぜ 0～8のリターンコードをボ ンドリングしていたような? 憶がある。
httpdコマンドぜ exitステータスで特徴的なのは、pidファイルのプロセスが既に起動している時に起動コマンドを実行して「httpd (pid XXX) already running」となる場合。起動に失敗したのでエラーではないか？と考えてしまうが、既に起動しているのでエラーではなぜ ステータスぜ “0″を返却する。同様ぜ pidファイルもなぜ 、プロセスが起動していない時に停止コマンドを実行して「httpd (no pid file) not running」となる場合も、既に停止しているのでステータ゜ “0″を返却する。exitステータスでエラーボ ンドリングする場合は、少しだけ注? が必要。
7月 13th, 2009
Apache2.2よりApache標準モジュールであるmod_proxy_ajpぜ AJP1.3プロトコルがサポートされました。また、mod_proxy_balancer による負荷分散? 能の強化により、Apacheのリバースプロキシとしての? 能が充実しました。実際にリバースプロキ゜ Apacheぜ APサーバTomcatでサーバを構成する場合、多種のパラメータをどう設? するかを検? してみました。
mod_proxy_balancerのパラメータには、ProxyPass（mod_rewriteでプロキシする場合ぜ ProxySet）ディレクティブに設定するバランサーパラメータぜ BalancerMemberディレクティブに設定するワーカーパラメータがあります。timeoutは各パラメータに同名ものが存在しますが、? 味が異なるので注? が必要です。すべてのパラメータを解説するのは大変なので、一部パラメータのみ? として挙げたいと思います。
# 設? 例（実際には改? は? りません）
ProxyRequests Off
ProxyPass /examples/ balancer://BALANCER/examples/ \
# バランサーパラメー゜ \
lbmethod=byrequests \
timeout=1 \
nofailover=Off \
stickysession=JSESSIONID|jsessionid
<Proxy balancer://BALANCER/>
BalancerMember ajp://host1:8080/ \
# ワーカボ (1)パラメー゜ \
loadfactor=10 \
route=tomcat1 \
retry=5 \
BalancerMember ajp://host2:8080/ \
# ワーカボ (2)パラメー゜ \
loadfactor=10 \
route=tomcat1 \
retry=5 \
# バランサーパラメー゜
# ProxySet lbmethod=byrequests
# ProxySet timeout=1
# ProxySet nofailover=Off
# ProxySet stickysession=JSESSIONID|jsessionid
</Proxy>
バランサーパラメー゜
lbmethod・・・分散方? の選択。byrequests(リクエスト回? )、bytraffic(バイト単位転送釜 )、bybusyness(フリーのワーカ優先)から選択する。要件次第ですが、殆どの場合はデフォルトの「byrequests(リクエスト回? )」でしょうか。
timeout・・・フリーのワーカーを圏 得するまでの最大? 機時間。デフォルトでは「待機しない」ので、大釜 のリクエストが要求された場合に? 機せずにそのままエラーを返してしまう事がある。従って、1秒を指定しておぜ 。1秒も待ってフリーのワーカを圏 得できない場合は、別の問題が発生していると考えた方が良いでしょう。
stickysession・・・アプリケーション側でスティッキーセッションの? 件がある場合は有効にする。Apache2.2.4以降では「JSESSIONID|jsessionid」のように大文字/? 文字両方を指定できます。大文字ぜ Cookieぜ JSESSIONID、? 文字ぜ URLパラメータに? 加されたjsessionidを圏 得する際に利用します。
nofailover・・・「On」の場合にはワーカ側でエラーとなった場合にセッションを切りフェイルオーバーしない。「Off」の場合は、フェイルオーバーするが フェイルオーバー先のホストでもセッション情報が保たれていないとアプリケーション側でエラーになるケースが多い。Tomcatクラスタリングを構成し、セッションレプリケーションを構成している場合に有効になる設? 項目。
maxattempts・・ボ F/Oを試みる回数を指定。nofailover=Offの時に有効になるパラメータ。バランシングするワーカが3つ以上ある場合、デフォルトぜ 1以? を指定するケースもありそう。
ワーカーパラメー゜
loadfactor・・・ワーカーあたりの? 荷? 数。10:10或いぜ 100:100等のようにしておき、運用時に調整する方? 等が考えられます。
route・・・スティッキーセッション有効の場合に指定します。Tomcatぜ JvmRoute値と同期する必要があります。
retry・・・リトライのタイムアウト時間。リトライタイムアウト時間とは、一府 ApacheがTomcatにコネクションを張りにいって失敗した（接続できない）場合に、次に再び接続失敗したワーカに接続しにいぜ ようになるまでの時間を指します。この時間を短ぜ すると、ワーカのオンライン復帰? に使用されるようになるまでの時間を短縮できます。デフォルトでぜ 60秒間になっているので長すぜ る為、「5秒」としています。
keepalive・・ボ Apache/Tomcat間ぜ FireWallがある場合、FireWallは非活動状態のセッションを落としにかかるので、これを防ぐ場合に使用する。Apache側ぜ MPMがマルチプロセスの場合、パフォーマンス面でもあまり効果が無いようです。
redirect・・・? つのワーカが利用? 可となりセッションが保持されていない場合、この値で指定したrouteのワーカにリダイレクトされる。セッションを使用していないアプリケーションは、昜 示的に次のワーカリダイレクトを指定できる。ワーカが2つならばあまり? 味はないが、3つ以上のワーカから次のワーカを昜 示的に指定したい場合は利用価値があるかもしれません。
lbset・・・ワーカへのアクセスの優先順位を決めることが出来る。
status・・・「D:利用? 可」「S:停止」「I:無? 」「H:ホットスタンバイ」「E:エラー」から選択。主に運用時に使用される目的のパラメータが多い。「H]ホットスタンバイについては利用価値が高い。ホットスタンバイ? 能を使用したい場合は非常に有効。
timeout・・ボ Tomcatに「/」リクエストを送ったときのタイムアウト時間。デフォルト? ProxyTimeout=TimeOut=300秒。300秒も待つ? 要はないと思うが・ボ
connectiontimeout・・ボ ApacheがTomcatに接続するまでの? ち時間。デフォルト? TimeOut=300秒。300秒も待つ? 要はないと思うが・・ボ
http://httpd.apache.org/docs/2.2/en/mod/mod_proxy.html#proxypass
7月 6th, 2009
Apacheのログローテートを実装する場合、候補に挙がるのぜ Apacheぜ rotatelogsユーティリティかLinuxのコマンドlogrotateどちらかが多いと思います。両者のメリット・デメリットをまとめてみました。
rotatelogs
メリット
・ローテート実行時ぜ Apacheインスタンスを再起動する必要が無い
・ローテーション処理のサーバ負荷が殆どない
デメリット
・常にファイル名が変動する為、外部プログラムでログファイルを監? する場合に問題がある
・? 代管理とログ削除? 能がない為、ログのパージ? 削除? 実装を別途組み込む必要がある
・? 部プログラムとして? 行される為、Apacheの停止時のログが最後まで正常に出力されない
logrotate
メリット
・ログの? 代管理に特化し、日次/週次/月? /サイズ指定など細かいローテーション? 画が可能。
・ログのパージ? 削除? 実装を兼ねている
デメリット
・ローテート実行時ぜ Apacheインスタンスを再起動する必要がある
・「copytruncate」オプションを使用すればインスタンスの再起動が不要になるが、
大容釜 のログファイルをローテーションする時のサーバ負荷が大きい
それぞれ一長? 短がありますので、運用方? に? じて適切な方を採用するのが望ましいと思います。個人的にぜ logrotateの方がスッキリします。
7月 2nd, 2009
Tomcat6以降でクラスタリング? 能が強化された事によって、現場でもTomcat Clusterを採用してみるという傾向が高まっている気がします。Tomcat5.5デフォルトぜ server.xmlにコメントで? 述してあるクラスタ設定でも、ボ ード間のセッション情報共有にはマルチキャストが採用されていました。実際のところ、Tomcatクラスタリング対象のサーバのマルチキャストの設定/確? 作業など面倒な点もあり、また、開発チームが簡易にクラスタリング朧 成を組む場合に、NW設? を実施した管理者とやり圏 りしなければならない場合も発生するなど敷? の? い方? だと感じます。しかし、Tomcatクラスタではマルチキャスト自動検出の方? 以? に、静的なボ ードメンバーで設定することもできます。設? 自? もボ ードぜ server.xmlのみで? 結しますので、比較的容易ぜ Tomcatクラスタを組むことが出来ます。以? のように設定して確認しました。（この設定ぜ 6.0.20以降を推奨?
<!-- Hostタグの中に追記します -->
<Host ～>
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8"
<!-- 4:同期、8:非同期モードの選択 -->
channelStartOptions="3">
<!-- (1) 1つのバックアップボ ードにだけセッション情報を共有 -->
<!--
<Manager className="org.apache.catalina.ha.session.BackupManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"
mapSendOptions="6"/>
-->
<!-- (2) 全てのボ ードでセッション情報を共有 -->
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<!-- (1) マルチキャストの場合はここを有効にします -->
<!--
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
-->
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="192.168.0.1" <!-- 2台目ぜ 192.168.0.2 -->
port="8080"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor" staticOnly="true"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<!-- (2) 静的メンバーの場合はここを有効にします -->
<Interceptor className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
<!-- メンバボ 1 -->
<Member className="org.apache.catalina.tribes.membership.StaticMember"
port="8080"
host="192.168.0.1"
domain="cluster-static"
uniqueId="{192,168,0,1,0,0,0,0,0,0,0,0,0,0,0,0}"/>
<!-- メンバボ 2 -->
<Member className="org.apache.catalina.tribes.membership.StaticMember"
port="8080"
host="192.168.0.2"
domain="cluster-static"
uniqueId="{192,168,0,2,0,0,0,0,0,0,0,0,0,0,0,0}"/>
</Interceptor>
</Channel>
<!-- セッション共有しないリクストパターンの設定 -->
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>
<!-- ファーミング? 能使用時の設定 -->
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
</Host>
セッション同期出来れば、以? のようにログ出力されます。Tomcat付属ぜ examplesサーブレット”SessionExample”でセッションの同期を確? 出来ます。
Jan 25, 2009 17:10:31 PM org.apache.catalina.ha.session.DeltaManager getAllClusterSessions
WARNING: Manager [/examples], requesting session state from org.apache.catalina.tribes.membership.MemberImpl
[tcp://192.168.0.1:8080,192.168.0.1,8080, alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 },
payload={}, command={}, domain={99 111 109 112 45 99 49 45 99 ...(15)}, ].
This operation will timeout if no session state has been received within 60 seconds.
Jan 25, 2009 17:10:31 PM org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl
[tcp://192.168.0.1,192.168.0.1,8080, alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 },
payload={}, command={}, domain={99 111 109 112 45 99 49 45 99 ...(15)}, ]
Jan 25, 2009 17:10:31 PM org.apache.catalina.ha.session.DeltaManager waitForSendAllSessions
SEVERE: Manager [/examples]: No session state send at 1/25/09 3:47 PM received, timing out after 60,094 ms.
Jan 25, 2009 17:10:31 PM org.apache.catalina.ha.session.DeltaManager getAllClusterSessions
WARNING: Manager [/examples]: Drop message SESSION-GET-ALL inside
GET_ALL_SESSIONS sync phase start date 1/25/09 3:47 PM message date 1/1/70 9:00 AM
Jan 25, 2009 17:10:31 PM org.apache.catalina.ha.session.DeltaManager getAllClusterSessions
WARNING: Manager [/examples]: Drop message SESSION-GET-ALL inside GET_ALL_SESSIONS
sync phase start date 1/25/09 3:47 PM message date 1/1/70 9:00 AM
このログ出力にもあるようぜ stateTransferTimeoutデフォルト60秒以内にセッションを確? できなければ? セッションステートを圏 信できなければ? タイムアウトします。両ホスト間の通信の確認、アプリケーションの設定/動作（<distributable />など? に? 備がないかを確? してみれ下さい。
2009/07/19 16:26:23 org.apache.catalina.ha.session.DeltaManager waitForSendAllSessions
致命的: Manager [/examples]: No session state send at 09/07/19 16:25 received, timing out after 60,086 ms.
