Return-Path: 
 <cvs-return-40633-apmail-httpd-cvs-archive=httpd.apache.org@httpd.apache.org>
X-Original-To: apmail-httpd-cvs-archive@www.apache.org
Delivered-To: apmail-httpd-cvs-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 52EE29D85
	for <apmail-httpd-cvs-archive@www.apache.org>;
 Mon, 12 Dec 2011 05:41:48 +0000 (UTC)
Received: (qmail 46964 invoked by uid 500); 12 Dec 2011 05:41:46 -0000
Delivered-To: apmail-httpd-cvs-archive@httpd.apache.org
Received: (qmail 46406 invoked by uid 500); 12 Dec 2011 05:41:40 -0000
Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:cvs-help@httpd.apache.org>
list-unsubscribe: <mailto:cvs-unsubscribe@httpd.apache.org>
List-Post: <mailto:cvs@httpd.apache.org>
List-Id: <cvs.httpd.apache.org>
Delivered-To: mailing list cvs@httpd.apache.org
Received: (qmail 46399 invoked by uid 99); 12 Dec 2011 05:41:39 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2011 05:41:39 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,NORMAL_HTTP_TO_IP
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2011 05:41:28 +0000
Received: from eris.apache.org (localhost [127.0.0.1])
	by eris.apache.org (Postfix) with ESMTP id 3C949238899C;
	Mon, 12 Dec 2011 05:41:06 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: svn commit: r1213144 -
 /httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_balancer.xml.ja
Date: Mon, 12 Dec 2011 05:41:06 -0000
To: cvs@httpd.apache.org
From: kawai@apache.org
X-Mailer: svnmailer-1.0.8-patched
Message-Id: <20111212054106.3C949238899C@eris.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

Author: kawai
Date: Mon Dec 12 05:41:05 2011
New Revision: 1213144

URL: http://svn.apache.org/viewvc?rev=1213144&view=rev
Log:
Update translation.
English Revision: 1213141

Submitted by: INOUE Seiichiro <inoue _at_ ariel-networks.com>
Reviewed by: OKANO Takayoshi <kano _at_ na.rim.or.jp>, kawai

Modified:
    httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_balancer.xml.ja

Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_balancer.xml.ja
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_balancer.xml.ja?rev=1213144&r1=1213143&r2=1213144&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_balancer.xml.ja [utf-8] (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_balancer.xml.ja [utf-8] Mon Dec 12 05:41:05 2011
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 153116:1033595 (outdated) -->
+<!-- English Revision: 1213141 -->
 
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
@@ -27,11 +27,11 @@
 <status>Extension</status>
 <sourcefile>mod_proxy_balancer.c</sourcefile>
 <identifier>proxy_balancer_module</identifier>
-<compatibility>2.1 以降</compatibility>
+<compatibility>Apache 2.1 以降で使用可能</compatibility>
 
 <summary>
     <p>本モジュールには <module>mod_proxy</module> が<em>必要です</em>。
-    <code>HTTP</code>, <code>FTP</code> と <code>AJP13</code>
+    本モジュールは <code>HTTP</code> と <code>FTP</code> と <code>AJP13</code>
     プロトコルのロードバランス機能を持っています。</p>
 
     <p>ですから、 ロードバランスを有効にする場合 <module>mod_proxy</module>
@@ -39,8 +39,8 @@
     いなければいけません。</p>
 
     <note type="warning"><title>警告</title>
-      <p><a href="mod_proxy.html#access"
-      >安全なサーバにする</a>までプロクシ機能は有効にしないでください。
+      <p><a href="mod_proxy.html#access">
+      安全なサーバにする</a>までプロキシ機能は有効にしないでください。
       オープンプロキシサーバはあなた自身のネットワークにとっても、
       インターネット全体にとっても危険です。</p>
     </note>
@@ -49,16 +49,65 @@
 
 <section id="scheduler">
     <title>ロードバランサのスケジューラのアルゴリズム</title>
-    <p>現時点では 2 種類のロードバランサスケジューラアルゴリズムから選べます。
+    <p>現時点では 3 種類のロードバランサスケジューラアルゴリズムから選べます。
     リクエスト回数によるもの <transnote>Request Counting</transnote>
-    と、トラフィック量によるもの <transnote>Weighted Traffic Counting</transnote>
-    があります。バランサの設定 <code>lbmethod</code> 値で、どちらを使うか指定します。
-    詳細は <directive module="mod_proxy">Proxy</directive> ディレクティブを
+    、トラフィック量によるもの <transnote>Weighted Traffic Counting</transnote>
+    と、処理中リクエスト数によるもの <transnote>Pending Request Counting</transnote>
+    とがあります。バランサの設定 <code>lbmethod</code> 値で、どれを使うか指定します。
+    詳細は <directive module="mod_proxy">ProxyPass</directive> ディレクティブを
     参照してください。</p>
+</section>
+
+<section id="stickyness">
+    <title>ロードバランサのスティッキネス</title>
+    <p>バランサはスティッキネスをサポートします。リクエストがあるバックエンドに
+    プロキシされた時、続く同じユーザからのリクエストは、すべてその同じバックエンドに
+    プロキシされるべきです。多くのロードバランサはこの機能をクライアントの
+    IP アドレスとバックエンドの対応表を持つことで実現します。
+    この方法はクライアントにもバックエンドにも透過に動作しますが、
+    次に挙げるいくつかの問題があります。
+    もしクライアント自身がプロキシの背後にいる場合、負荷分散が不均一になります。
+    もし動的な IP アドレスを持つクライアントのアドレスがセッション中に変わると
+    スティッキネスは期待どおりに動作しません。
+    もし対応表があふれると、スティッキネスが失われます。</p>
+    <p><module>mod_proxy_balancer</module> はスティッキネスを
+    2 種類の別手法をもとに実装しています。クッキーと URL エンコーディングのふたつです。
+    クッキーはバックエンドもしくは Apache Web サーバ自身により提供されます。
+    URL エンコーディングは通常バックエンドにより行われます。</p>
+</section>
+
+<section id="example">
+    <title>ロードバランサの設定例</title>
+    <p>技術的な詳細に入る前に例を示します。以下は、2 台のバックエンドサーバを
+    ロードバランスするための <module>mod_proxy_balancer</module> の使い方の一例です:
+    </p>
+
+    <example>
+    &lt;Proxy balancer://mycluster&gt;<br />
+	BalancerMember http://192.168.1.50:80<br />
+	BalancerMember http://192.168.1.51:80<br />
+    &lt;/Proxy&gt;<br />
+    ProxyPass /test balancer://mycluster
+    </example>
+
+    <p>別の例として、<module>mod_headers</module> を使ってスティッキネス
+    を実現するロードバランサの設定例を示します。バックエンドのサーバが
+    適切なセッションクッキーをセットしなくても動作します。
+    </p>
 
+    <example>
+    Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
+           env=BALANCER_ROUTE_CHANGED<br />
+    &lt;Proxy balancer://mycluster&gt;<br />
+    BalancerMember http://192.168.1.50:80 route=1<br />
+    BalancerMember http://192.168.1.51:80 route=2<br />
+    ProxySet stickysession=ROUTEID<br />
+    &lt;/Proxy&gt;<br />
+    ProxyPass /test balancer://mycluster
+    </example>
 </section>
 
-<section id="byrequests">
+<section id="requests">
     <title>Request Counting アルゴリズム</title>
     <p><code>lbmethod=byrequests</code> で有効になります。
     このスケジューラの背景にある考え方は、様々なワーカーがそれぞれ、
@@ -79,7 +128,7 @@
     <p>まず個々のワーカーにワーカークオータを割り振り、どのワーカーが最も急ぎで
     働かなければならないか (lbstatus が最大のもの) を調べます。
     次に仕事をするようにこのワーカーを選択し、選択したワーカーの lbstatus 
-    を全体に割り振ったぶんだけ差し引きます。ですから、lbstatus の総量は
+    から全ワーカーに割り振ったクオータの合計を引きます。ですから、lbstatus の総量は
     結果的に変化しません(*)し、リクエストは期待通りに分散されます。</p>
 
     <p>あるワーカーが無効になっても、他のものは正常にスケジュールされ続けます。
@@ -173,9 +222,7 @@ candidate lbstatus -= total factor</code
         <td>1</td></tr>
     </table>
 
-    <p>This is because all values of <dfn>lbfactor</dfn> are normalized
-    with respect to the others. For:</p>
-    <p><dfn>lbfactor</dfn> は全て正規化されたもので、
+    <p>と言うのも、<dfn>lbfactor</dfn> の値は全て正規化されたもので、
     他との相対値だからです。次の設定では:</p>
 
     <table style="data">
@@ -239,7 +286,7 @@ candidate lbstatus -= total factor</code
     <var>b</var> 3 回でまばらに選ばれます。</p>
 </section>
 
-<section id="bytraffic">
+<section id="traffic">
     <title>Weighted Traffic Counting アルゴリズム</title>
     <p><code>lbmethod=bytraffic</code> で有効になります。
     このスケジューラの背景にある考え方は、Request Counting 
@@ -273,7 +320,77 @@ candidate lbstatus -= total factor</code
 
 </section>
 
-<section id="enable">
+<section id="busyness">
+
+    <title>Pending Request Counting アルゴリズム</title>
+
+    <p><code>lbmethod=bybusyness</code> で有効になります。このスケジューラは
+    現在どのぐらいのリクエストが個々のワーカーにアサインされているかを把握しています。
+    新しいリクエストは、最も処理途中のリクエスト数が少ないワーカーに
+    自動的に割り振られます。これは、ワーカーが Apache と無関係に入力リクエストを
+    キューに溜め込む場合に有効で、キューの長さを同程度に維持しつつも、
+    最も早く処理できそうなワーカーに常にリクエストを割り振ります。</p>
+
+    <p>複数のワーカーが最少の処理中リクエスト数で並んだ場合、Request Counting
+    アルゴリズムと同じ統計情報（と重み付け）を使って順番を決めます。
+    時間が経つと、割り振りの割合は <code>byrequests</code> と似たような
+    傾向を示すようになるでしょう。</p>
+
+    <p>このアルゴリズムは Apache HTTP サーバ 2.2.10以降で利用可能です。</p>
+
+</section>
+
+<section id="environment">
+    <title>エクスポートされる環境変数</title>
+    <p>現在、6 つの環境変数がエクスポートされます:</p>
+
+    <dl>
+    <!-- ============= BALANCER_SESSION_STICKY =============== -->
+    <dt><var><a name="balancer_session_sticky" id="balancer_session_sticky">BALANCER_SESSION_STICKY</a></var></dt>
+    <dd>
+    <p>現在のリクエストに使われる <var>stickysession</var> 値になります。
+    スティッキーセッションのためのクッキー名もしくはリクエストパラメータ名です。</p>
+    </dd>
+
+    <!-- ============= BALANCER_SESSION_ROUTE ================ -->
+    <dt><var><a name="balancer_session_route" id="balancer_session_route">BALANCER_SESSION_ROUTE</a></var></dt>
+    <dd>
+    <p>現在のリクエストをパースして得られる <var>route</var> 値です。</p>
+    </dd>
+
+    <!-- ============= BALANCER_NAME ========================= -->
+    <dt><var><a name="balancer_name" id="balancer_name">BALANCER_NAME</a></var></dt>
+    <dd>
+    <p>現在のリクエストが使うバランサ名です。<code>balancer://foo</code>
+    のような値です。</p>
+    </dd>
+
+    <!-- ============= BALANCER_WORKER_NAME ================== -->
+    <dt><var><a name="balancer_worker_name" id="balancer_worker_name">BALANCER_WORKER_NAME</a></var></dt>
+    <dd>
+    <p>現在のリクエストが使うワーカー名です。<code>http://hostA:1234</code>
+    のような値です。</p>
+    </dd>
+
+    <!-- ============= BALANCER_WORKER_ROUTE ================= -->
+    <dt><var><a name="balancer_worker_route" id="balancer_worker_route">BALANCER_WORKER_ROUTE</a></var></dt>
+    <dd>
+    <p>現在のリクエストが使うワーカーの <var>route</var> 値です。</p>
+    </dd>
+
+    <!-- ============= BALANCER_ROUTE_CHANGED ================= -->
+    <dt><var><a name="balancer_route_changed" id="balancer_route_changed">BALANCER_ROUTE_CHANGED</a></var></dt>
+    <dd>
+    <p>セッションルートとワーカールートが一致しない時 (BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE) 
+    あるいは、セッションがまだルートを確立していない時、値が 1 になります。
+    スティッキーセッションを使う時、ルートの更新をクライアントに送る必要があるかを
+    判断するためにこの環境変数を使えます。</p>
+    </dd>
+    </dl>
+
+</section>
+
+<section id="balancer_manager">
     <title>バランサマネージャのサポートを有効にする</title>
     <p>このモジュールは <module>mod_status</module> のサービスを
     <em>必要とします</em>。
@@ -286,7 +403,7 @@ candidate lbstatus -= total factor</code
     <module>mod_status</module> と <module>mod_proxy_balancer</module>
     をサーバに組み込まなければなりません。</p>
 
-    <p>foo.com ドメインのブラウザからロードバランサ管理機能を
+    <p>example.com ドメインのブラウザからロードバランサ管理機能を
     使えるようにするには、次のようなコードを <code>httpd.conf</code>
     に追加します。</p>
 <example>
@@ -295,7 +412,7 @@ candidate lbstatus -= total factor</code
 <br />
     Order Deny,Allow<br />
     Deny from all<br />
-    Allow from .foo.com<br />
+    Allow from .example.com<br />
     &lt;/Location&gt;
 </example>
 
@@ -304,4 +421,106 @@ candidate lbstatus -= total factor</code
     アクセスできるようになります。</p>
 </section>
 
+<section id="stickyness_implementation">
+    <title>ロードバランサのスティッキネスの詳細</title>
+    <p>クッキーをもとにスティッキネスを使う場合、どのバックエンドに割り振るべきか
+    を決めるクッキーの名前を指定する必要があります。
+    クッキー名は <directive module="mod_proxy">ProxyPass</directive> または
+    <directive module="mod_proxy">ProxySet</directive> のいずれか
+    に付与する <var>stickysession</var> 属性で設定します。
+    クッキー名は大文字小文字を区別します。
+    バランサはそのクッキーの値を取り出し、その値に一致する <var>route</var> 値の
+    ワーカーを探します。
+    <var>route</var> も <directive module="mod_proxy">ProxyPass</directive>
+    または <directive module="mod_proxy">ProxySet</directive>
+    のいずれかに設定しなければいけません。
+    クッキーはバックエンドによって設定されるか、あるいは
+    上記の <a href="#example">例</a> のように Apache Web サーバ自身
+    によって設定されます。</p>
+    <p>バックエンドの中の一部は少し異なる形式のスティッキネスクッキーを使います。
+    たとえば Apache Tomcat がそうです。Tomcat は自身のインスタンス名を
+    セッション ID のクッキーの最後に付け加えます。この時、セッション ID
+    との区切り文字にドット (<code>.</code>) を使います。
+    このため、Apache Web サーバがドットをスティッキネスクッキー値の中に見つけると、
+    route を探すためにドット以降の部分のみを使うようにします。
+    Tomcat 側で自身のインスタンス名を設定するには、Tomcat の設定ファイル
+    <code>conf/server.xml</code> の中の <code>jvmRoute</code> 属性に
+    指定する必要があります。値はそれぞれの Tomcat に接続するワーカーの
+    <var>route</var> 値と一致させます。
+    Tomcat およびサーブレットベースの Java Web アプリサーバが一般に使う
+    セッションクッキーの名前は <code>JSESSIONID</code> (すべて大文字) です。
+    この名前は設定により変更も可能です。</p>
+    <p>スティッキネスを実装するふたつめの手段は URL エンコーディングです。
+    Web サーバはリクエストの URL の中からクエリパラメータを探します。
+    探すパラメータ名は同じように <var>stickysession</var> 属性で指定します。
+    パラメータ値と一致する <var>route</var> 値のワーカーを探します。
+    レスポンスに含まれるすべての URL リンクを探しだし書き換えるのは簡単ではないので、
+    一般にそれぞれのリンクにクエリパラメータを付け加えるのは、
+    そのコンテンツを生成したバックエンドの仕事です。
+    時には、<module>mod_substitute</module> を使って Web サーバにこの書き換えを
+    させるのが可能な場合もあります。
+    ただし、パフォーマンスを落とす可能性があります。</p>
+    <p>Java 標準は URL エンコーディングを少し異なる形で実装します。
+    URL のパス情報をセミコロン (<code>;</code>) で区切って
+    セッション ID を付け加えます。
+    クッキーの場合と同じように、 Apache Tomcat はこのパス情報に
+    <code>jvmRoute</code> の設定値を含めます。
+    Apache にこの種のパス情報を見つけさせるには、
+    <directive module="mod_proxy">ProxyPass</directive> あるいは
+    <directive module="mod_proxy">ProxySet</directive> の
+    <code>scolonpathdelim</code> を <code>On</code> にします。</p>
+    <p>最後に、クッキーと URL エンコーディングの両方が指定できることを示します。
+    次の例のように、クッキー名と URL パラメータ名を垂直バー (<code>|</code>)
+    で区切って指定します:</p>
+    <example>
+    ProxyPass /test balancer://mycluster stickysession=JSESSIONID|jsessionid scolonpathdelim=On
+    &lt;Proxy balancer://mycluster&gt;<br />
+    BalancerMember http://192.168.1.50:80 route=node1<br />
+    BalancerMember http://192.168.1.51:80 route=node2<br />
+    &lt;/Proxy&gt;<br />
+    </example>
+    <p>もし同じリクエストが、クッキーとリクエストパラメータの両方のルーティング情報を
+    提供した場合、リクエストパラメータのほうが使われます。</p>
+</section>
+
+<section id="stickyness_troubleshooting">
+    <title>ロードバランサのスティッキネスのトラブルシューティング</title>
+    <p>もしアプリのセッションが失われてユーザが再ログインしなければいけないなど
+    スティッキネス関連のエラーに遭遇したら、
+    この原因はバックエンドの応答に支障があったせいか、
+    あるいは設定ミスによるものかを最初に切り分けたいでしょう。
+    バックエンドの安定性に関して起きうる問題を見つけるには、
+    Apache のエラーログにプロキシエラーのメッセージがないか確認してください。</p>
+    <p>設定が正しいかを確認するには、最初にスティッキネスを
+    クッキーと URL エンコーディングのどちらで行っているかを確認してください。
+    次に、<directive module="mod_log_config">LogFormat</directive> を変更して
+    アクセスログに適切なデータが残るようにするとよいでしょう。
+    次のフィールドが便利です:</p>
+    <dl>
+    <dt><code>%{MYCOOKIE}C</code></dt>
+    <dd><code>MYCOOKIE</code> という名前のクッキーの値。
+    この名前は <var>stickysession</var> 属性の指定値と同じはずです。</dd>
+    <dt><code>%{Set-Cookie}o</code></dt>
+    <dd>これによりバックエンドがセットするクッキーをログに出せます。
+    バックエンドが期待するセッションクッキーをセットしているかと、
+    どんな値がセットされているかを追跡できます。</dd>
+    <dt><code>%{BALANCER_SESSION_STICKY}e</code></dt>
+    <dd>ルーティング情報を決めるために使われたクッキー名もしくは
+    リクエストパラメータ名。</dd>
+    <dt><code>%{BALANCER_SESSION_ROUTE}e</code></dt>
+    <dd>リクエスト内に見つかった route 値の情報</dd>
+    <dt><code>%{BALANCER_WORKER_ROUTE}e</code></dt>
+    <dd>選択されたワーカーの route 値</dd>
+    <dt><code>%{BALANCER_ROUTE_CHANGED}e</code></dt>
+    <dd>リクエストの route 値がワーカーの route 値と異なる場合に
+    <code>1</code> になります。つまり、リクエストはスティッキーとして
+    処理されていません。</dd>
+    </dl>
+    <p>セッションが失われる原因でよくあるものは、セッションタイムアウトですが、
+    これは通常バックエンドのサーバで変更可能です。</p>
+    <p>ログレベルを <code>debug</code> 以上に設定すると、
+    バランサはスティッキネス動作の詳細な情報をエラーログに書き出します。
+    これはスティッキネスの問題のトラブルシューティングする簡単な手法ですが、
+    高負荷な本番サーバではログの分量が膨大になってしまうかもしれません。</p>
+</section>
 </modulesynopsis>