Apache Traffic Server 6.2 - en to ja_JP translation catalogue (27 entries)

en: Because the router serves as the inline network element, Traffic Server must run on a separate host. This host can be located anywhere as long as Traffic Server is either on the same network segment or a GRE tunnel can be maintained between the Traffic Server host and the router.
ja_JP: ルーターはインラインのネットワーク要素として動くので、Traffic Server は別のホスト上で動作しなければ成りません。このホストは Traffic Server が同じネットワークセグメント上にあるか Traffic Server のホストとルーターとの間で GRE トンネルが維持可能であればどこに置くこともできます。

en: Configuration overview
ja_JP: 設定の概要

en: Dedicated -- Traffic Server traffic goes over an interface that is not used for client nor origin server traffic.
ja_JP: 専用 -- Traffic Server のトラフィックがクライアントにもオリジンサーバーのトラフィックにも使われていないインターフェースに渡ります。

en: Finally Traffic Server itself must be configured for transparency and use of WCCP. The former is again very similar to the standard use, while WCCP configuration is specific to WCCP and uses a separate configuration file, referred to by the :file:`records.config` file.
ja_JP: 最後に Traffic Server 自体が透過性と WCCP を使用するように設定されなければなりません。構成方法もまた標準的な使用とよく似ており、WCCP の設定は WCCP に特化していて分離された設定ファイルを使用しますが、:file:`records.config` ファイルにより参照されます。

en: If already have a router that supports WCCP inline you do not have to change your network topology.
ja_JP: もしすでに WCCP インラインに対応したルーターを持っているのならネットワークトポロジを変更する必要はありません。

en: Use of WCCP only makes sense for client side transparency [1]_ because if the clients are explicitly proxied by Traffic Server there's no benefit to WCCP fail open, as the clients will continue to directly access the unresponsive Traffic Server host. It would be better to adjust the routing tables on the router for explicit proxying.
ja_JP: クライアントが Traffic Server によって明示的にプロキシーされている場合には WCCP の fail open に対して利益がなく、クライアントは応答しない Traffic Server ホストに直接アクセスできるので WCCP の使用はクライアント側の透過性でのみ意味をなします [1]_ 。ルーター上のルーティングテーブルを明示的なプロキシーのために調整すると良いでしょう。

en: WCCP fails open so that if the Traffic Server machine fails, it is bypassed and users continue to have Internet access.
ja_JP: Traffic Server マシンが失敗するように WCCP がオープンに失敗すると、それはバイパスされユーザーはインターネットへのアクセスを継続できます。

en: Inside Shared -- Traffic Server and client traffic share an interface.
ja_JP: 内部共有 -- Traffic Server とクライアントのトラフィックがインターフェースを共有します。

en: Setting WCCP is a three step process, first configuring the router, the Traffic Server host, and Traffic Server.
ja_JP: WCCP の設定は、ルーターの設定、Traffic Server ホスト、そして Traffic Server の 3 ステップです。

en: The Traffic Server host system must also be configured using ``iptables`` to accept connections on foreign addresses. This is done roughly the same way as the standard transparency use.
ja_JP: Traffic Server のホストシステムは外部アドレスの接続を受け付けるために ``iptables`` を使うようにも設定されなかれば成りません。これは標準的な透過性の使用とだいたい同じ方法で行えます。

en: WCCP Configuration
ja_JP: WCCP 設定

en: `WCCP <http://cio.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/wccp.html>`_ is de-facto semi-standard used by routers to redirect network traffic to caches. It is available on most Cisco™ routers although it does not appear to be officially supported by Cisco. The primary benefits of WCCP are
ja_JP: `WCCP <http://cio.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/wccp.html>`_ はルーターがネットワークトラフィックをキャッシュに向ける準デファクトスタンダードです。Cisco™ から公式にサポートされているようには見えないものの、多くの Cisco のルーターで利用可能です。WCCP の主な利益は次のとおりです。

en: |important| This document presumes that the router is already properly configured to handle traffic between the clients and the origin servers. If you are not certain, verify it before attempting to configure Traffic Server with WCCP. This is also a good state to which to revert should the configuration go badly.
ja_JP: |important| このドキュメントはルータがクライアントとオリジンサーバーとの間のトラッフィクを扱えるように正しく設定済みであることを仮定しています。もし確かでない場合は、WCCP を使うよう Traffic Server を設定する前に確認してください。設定がおかしくなった際に元に戻すのも良い心がけです。

en: A shared interface topology has additional issues compared to a dedicated topology that must be handled. Such a topology is required if the router has only two interfaces, and because of these additional issues it is normally only used in such cases, although nothing prevents it use even if the router has three or more interfaces.
ja_JP: 共有インターフェーストポロジーは専用トポロジーと比べると扱わなければならない追加の課題があります。このようなトポロジーはルーターが二つのインターフェースしか持っていない場合に必要となり、ルーターが三つ以上のインターフェースを持っている場合でもその使用を妨げるものはありませんが、これらの追加の課題があるので通常はそのようなケースでしか使用されません。

en: Frequently encountered problems
ja_JP: よくぶつかる問題

en: In general the dedicated topology is preferred. However, if the router has only two interfaces one of the shared topologies will be required [2]_ Click the links above for more detailed configuration information on a specific topology.
ja_JP: 一般的には専用トポロジーが好まれます。しかしながら、ルーターが二つしかインターフェースを持っていない場合は二つの共有トポロジーのうちの一つが必要となります [2]_ 。特定のトポロジーでのより詳細な設定情報については上記のリンクをクリックしてください。

en: Shared -- Traffic Server traffic shares an interface with client or server traffic.
ja_JP: 共有 -- Traffic Server のトラッフィクがクライアントまたはサーバーのトラフィックとインターフェースを共有します。

en: The primary concern for configuration in which of three basic topologies are to be used.
ja_JP: 三種類のどの基本トポロジーが使用されるかによる設定における主な懸念。

en: If your router has only one interface, it's hardly a *router*.
ja_JP: ルーターが一つのインターフェースしかもっていないなら、それはまったく\ *ルーター*\ ではありません。

en: MTU and fragmentation
ja_JP: MTU と断片化

en: Shared interface issues
ja_JP: 共有インターフェースの課題

en: |image1| The router will **not** respond to WCCP protocol packets unless explicitly configured to do so. Via WCCP, the router can be made to perform packet interception and redirection needed by Traffic Server transparency. The WCCP protocol in effect acts as means of controlling a rough form of policy routing with positive heartbeat cutoff.
ja_JP: |image1| ルーターは明示的に設定をしない限り WCCP プロトコルのパケットに応答\ *しません*\ 。WCCP では、ルーターがパケットの横取りと Traffic Server の透過性に必要とされる向き先の変更を行うように設定されます。WCCP プロトコルは事実上、positive heartbeat cutoff によりポリシールーティングのだいたいの形を制御する方法として振る舞います。

en: In most cases the basic configuration using a tunnel in any topology can fail due to issues with fragmentation. The socket logic is unable to know that its packets will eventually be put in to a tunnel which will by its nature have a smaller `MTU <http://en.wikipedia.org/wiki/Maximum_transmission_unit>`_ than the physical interface which it uses. This can lead to pathological behavior or outright failure as the packets sent are just a little too big. It is not possible to solve easily by changing the MTU on the physical interface because the tunnel interface uses that to compute its own MTU.
ja_JP: ほとんどのケースではどのトポロジーでもトンネルを使用する基本設定は断片化の課題により失敗します。ソケットのロジックはパケットがいずれ物理インターフェースが使用するものより小さい `MTU <http://en.wikipedia.org/wiki/Maximum_transmission_unit>`_ をもったトンネルに入るということを知ることができません。これは送信したパケットがほんの少し大きすぎるのと同様に異常な振る舞いや完全な失敗を引き起こします。トンネルインターフェースは自身の MTU を計算するために物理インターフェース上の MTU を使用するのでそれを変更することで簡単に解決することはできません。

en: References
ja_JP: 参考文献

en: Server side transparency should also be used, but it is not as significant. In its absence, however, origin servers may see the source address of connections suddenly change from the Traffic Server address to client addresses, which could cause problems. Further, the primary reason for not having server side transparency is to hide client addresses which is defeated if the Traffic Server host fails.
ja_JP: サーバー側の透過性も使用されるべきですが、重要なことではありません。それがない場合であっても、オリジンサーバーは問題を起こすであろう突然 Traffic Server のアドレスからクライアントのアドレスへと変わる接続元のアドレスに遭遇するでしょう。また、サーバー側の透過性を持たない主な理由は、Traffic Server ホストが動かなくなったときに使えなくなるクライアントのアドレスを隠すためです。

en: The basic concept for a shared interface is to use a tunnel to simulate the dedicated interface case. This enables the packets to be distinguished at layer 3. For this reason, layer 2 redirection cannot be used because the WCCP configuration cannot distinguish between packets returning from the origin server and packets returning from Traffic Server as they are distinguished only by layer 2 addressing [3]_. Fortunately the GRE tunnel used for packet forwarding and return can be used as the simulated interface for Traffic Server.
ja_JP: 共有インターフェースのための基本的なコンセプトは専用インターフェースのケースをシミュレートするためにトンネルを使うことです。これはパケットがレイヤー 3 で識別できるようにします。この理由のために、オリジンサーバーから帰ってくるパケットと Traffic Server から帰ってくるパケットの識別はレイヤー 2 のアドレスでのみでき [3]_ WCCP の設定ではできないので、レイヤー 2 での向き先の変更は使うことができません。幸いパケットの転送と返送に使われる GRE トンネルが Traffic Server のためにシミュレートされたインターフェースとして使用できます。

en: This is not fundamentally impossible, as the packets are distinct in layer
ja_JP: パケットはレイヤー内では別々なので、本質的には不可能ではありません。
