[要約] RFC 5351は、信頼性のあるサーバープーリングプロトコルについての概要を提供しています。このRFCの目的は、異なるサーバー間で負荷を分散し、高い可用性と信頼性を実現するためのプロトコルを紹介することです。
Network Working Group P. Lei
Request for Comments: 5351 Cisco Systems, Inc.
Category: Informational L. Ong
Ciena Corporation
M. Tuexen
Muenster Univ. of Applied Sciences
T. Dreibholz
University of Duisburg-Essen
September 2008
An Overview of Reliable Server Pooling Protocols
信頼できるサーバープーリングプロトコルの概要
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite.
信頼できるサーバープーリングの取り組み（「RSERPOOL」の略語）は、アプリケーションに依存しないサービスとプロトコルを提供し、フォールトトレラントで非常に利用可能なクライアント/サーバーアプリケーションを構築します。このドキュメントは、信頼できるサーバープーリングスイートのプロトコルとメカニズムの概要を提供します。
Table of Contents
目次
1. Introduction ....................................................3
2. Aggregate Server Access Protocol (ASAP) Overview ................6
2.1. Pool Initialization ........................................6
2.2. Pool Entity Registration ...................................6
2.3. Pool Entity Selection ......................................7
2.4. Endpoint Keep-Alive ........................................7
2.5. Failover Services ..........................................7
2.5.1. Cookie Mechanism ....................................7
2.5.2. Business Card Mechanism .............................8
3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview ........8
3.1. Initialization .............................................8
3.2. Server Discovery and Home Server Selection .................8
3.3. Failure Detection, Handlespace Audit, and Synchronization ..9
3.4. Server Takeover ............................................9
4. Example Scenarios ...............................................9
4.1. Example Scenario Using RSerPool Resolution Service .........9
4.2. Example Scenario Using RSerPool Session Services ..........11
5. Reference Implementation .......................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................12
8. Acknowledgements ...............................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
The Reliable Server Pooling (RSerPool) protocol suite is designed to provide client applications ("pool users") with the ability to select a server (a "pool element") from among a group of servers providing equivalent service (a "pool"). The protocols are currently targeted for Experimental Track.
信頼できるサーバープーリング（RSERPOOL）プロトコルスイートは、同等のサービス（「プール」）を提供するサーバーのグループの中からサーバー（「プール要素」）を選択する機能をクライアントアプリケーション（「プールユーザー」）に提供するように設計されています。。現在、プロトコルは実験トラックのターゲットを絞っています。
The RSerPool architecture supports high availability and load balancing by enabling a pool user to identify the most appropriate server from the server pool at a given time. The architecture is defined to support a set of basic goals:
RSERPOOLアーキテクチャは、プールユーザーが特定の時間にサーバープールから最も適切なサーバーを識別できるようにすることにより、高可用性とロードバランスをサポートします。アーキテクチャは、一連の基本的な目標をサポートするために定義されています。
o application-independent protocol mechanisms
o アプリケーションに依存しないプロトコルメカニズム
o separation of server naming from IP addressing
o IPアドレス指定からのサーバーの命名の分離
o use of the end-to-end principle to avoid dependencies on intermediate equipment
o 中間機器への依存関係を回避するためのエンドツーエンドの原則の使用
o separation of session availability/failover functionality from the application itself
o アプリケーション自体からのセッションの可用性/フェールオーバー機能の分離
o facilitation of different server selection policies
o さまざまなサーバー選択ポリシーの促進
o facilitation of a set of application-independent failover capabilities
o アプリケーションに依存しない一連のフェールオーバー機能の促進
o peer-to-peer structure
o ピアツーピア構造
The basic components of the RSerPool architecture are shown in Figure 1 below:
RSERPOOLアーキテクチャの基本コンポーネントを以下の図1に示します。
.......................
______ ______ . +-------+ .
/ ENRP \ / ENRP \ . | | .
|Server| <----> |Server|<----------.----->| PE 1 | .
\______/ ENRP \______/ ASAP(1) . | | .
^ . +-------+ .
| . .
| ASAP(2) . Server Pool .
V . .
+-------+ . +-------+ .
| | . | | .
| PU |<---------->. | PE 2 | .
| | PU to PE . | | .
+-------+ . +-------+ .
. .
. +-------+ .
. | | .
. | PE 3 | .
. | | .
. +-------+ .
.......................
Figure 1
図1
A server pool is defined as a set of one or more servers providing the same application functionality. The servers are called Pool Elements (PEs). Multiple PEs in a server pool can be used to provide fault tolerance or load sharing, for example. The PEs register into and de-register out of the pool at an entity called the Endpoint haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate Server Access Protocol (ASAP) [RFC5352] (this association is labeled ASAP(1) in the figure).
サーバープールは、同じアプリケーション機能を提供する1つ以上のサーバーのセットとして定義されます。サーバーはプール要素（PES）と呼ばれます。たとえば、サーバープールの複数のPEを使用して、フォールトトレランスまたは負荷共有を提供できます。PESは、Aggregate Server Access Protocol（ASAP）[RFC5352]を使用して、エンドポイントハンドルスペース冗長プロトコル（ENRP）サーバーと呼ばれるエンティティでプールに登録して登録して登録します（この関連付けは、図のASAP（1）とラベル付けされています。）。
Each server pool is identified by a unique byte string called the pool handle (PH). The pool handle allows a mapping from the pool to a specific PE located by its IP address (both IPv4 and IPv6 PE addresses are supported) and port number. The pool handle is what is specified by the Pool User (PU) when it attempts to access a server in the pool. To resolve the pool handle to the address necessary to access a PE, the PU consults an ENRP server using ASAP (this association is labeled ASAP(2) in the figure). The space of pool handles is assumed to be a flat space with limited operational scope (see RFC 3237 [RFC3237]). Administration of pool handles is not addressed by the RSerPool protocol documents at this time. The protocols used between the PU and PE are application-specific. It is assumed that the PU and PE are configured to support a common set of protocols for application layer communication, independent of the RSerPool mechanisms.
各サーバープールは、プールハンドル（pH）と呼ばれる一意のバイト文字列によって識別されます。プールハンドルにより、プールからIPアドレス（IPv4およびIPv6 PEアドレスの両方がサポートされている）とポート番号によって配置された特定のPEへのマッピングが可能になります。プールハンドルは、プール内のサーバーにアクセスしようとするときにプールユーザー（PU）が指定するものです。PEにアクセスするために必要なアドレスへのプールハンドルを解決するために、PUはASAPを使用してENRPサーバーに相談します（この関連付けは、図のASAP（2）とラベル付けされています）。プールハンドルのスペースは、操作範囲が限られているフラットスペースであると想定されています（RFC 3237 [RFC3237]を参照）。プールハンドルの管理は、現時点ではRSERPOOLプロトコルドキュメントでは対処されていません。PUとPEの間で使用されるプロトコルは、アプリケーション固有です。PUとPEは、RSERPOOLメカニズムとは無関係に、アプリケーションレイヤー通信用の共通のプロトコルセットをサポートするように構成されていると想定されています。
RSerPool provides a number of tools to aid client migration between servers on server failure: it allows the client to identify alternative servers, either on initial discovery or in real time; it also allows the original server to provide a state cookie to the client that can be forwarded to an alternative server to provide application-specific state information. This information is exchanged between the PE and PU directly, over the association labeled PU to PE in the figure.
RSERPOOLは、サーバーの障害時にサーバー間のクライアントの移行を支援するための多くのツールを提供します。これにより、クライアントは、最初の発見またはリアルタイムのいずれかで、代替サーバーを識別できます。また、元のサーバーがクライアントに状態Cookieを提供することを可能にします。クライアントは、アプリケーション固有の状態情報を提供して、代替サーバーに転送できるものです。この情報は、PEとPEの間で、PEとラベル付けされたAssociationの間で、図のPEに直接交換されます。
It is envisioned that ENRP servers provide a fully distributed and fault-tolerant registry service. They use ENRP [RFC5353] to maintain synchronization of data concerning the pool handle mapping space. For PUs and PEs, the ENRP servers are functionally equal. Due to the synchronization provided by ENRP, they can contact an arbitrary one for registration/de-registration (PE) or PH resolution (PU). An illustration containing 3 ENRP servers is provided in Figure 2 below:
ENRPサーバーは、完全に分散されたフォールトトレラントレジストリサービスを提供することが想定されています。彼らは、entrp [rfc5353]を使用して、プールハンドルマッピングスペースに関するデータの同期を維持します。PUSおよびPESの場合、ENRPサーバーは機能的に等しくなります。ENRPによって提供される同期により、登録/登録解除（PE）またはpH解像度（PU）のために任意の同期に連絡できます。3つのENRPサーバーを含む図を以下の図2に示します。
______ _____
... / ENRP \ / ENRP \ ...
PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs
... ASAP \______/ ENRP \______/ ASAP ...
^ ^
| |
| / ENRP \ |
+---->|Server|<----+
ENRP \______/ ENRP
^
| ASAP
v
...
PEs/PUs
...
Figure 2
図2
The requirements for the Reliable Server Pooling framework are defined in RFC 3237 [RFC3237]. It is worth noting that the requirements on RSerPool in the area of load balancing partially overlap with grid computing/high-performance computing. However, the scope of both areas is completely different: grid and high-performance computing also cover topics like managing different administrative domains, data locking and synchronization, inter-session communication, and resource accounting for powerful computation services, but the intention of RSerPool is simply a lightweight realization of load distribution and session management. In particular, these functionalities are intended to be used on systems with small memory and CPU resources only. Any further functionality is not in the scope of RSerPool and can -- if necessary -- be provided by the application itself.
信頼できるサーバープーリングフレームワークの要件は、RFC 3237 [RFC3237]で定義されています。グリッドコンピューティング/高パフォーマンスコンピューティングと部分的に重複する負荷バランスの分野におけるRSERPOOLの要件が注目に値します。ただし、両方の領域の範囲は完全に異なります。グリッドと高性能のコンピューティングは、さまざまな管理ドメインの管理、データのロックと同期、セッション間通信、強力な計算サービスを考慮したリソースなどのトピックもカバーしていますが、Rserpoolの意図は単に負荷分布とセッション管理の軽量な実現。特に、これらの機能は、小さなメモリとCPUリソースのみを備えたシステムでのみ使用することを目的としています。さらなる機能はRSERPOOLの範囲内ではなく、必要に応じてアプリケーション自体によって提供される可能性があります。
This document provides an overview of the RSerPool protocol suite, specifically the Aggregate Server Access Protocol (ASAP) [RFC5352] and the Endpoint Handlespace Redundancy Protocol (ENRP) [RFC5353]. In addition to the protocol specifications, there is a common parameter format specification [RFC5354] for both protocols, a definition of server selection rules (pool policies) [RFC5356], as well as a security threat analysis [RFC5355].
このドキュメントは、RSERPOOLプロトコルスイート、特に集計サーバーアクセスプロトコル（ASAP）[RFC5352]とエンドポイントハンドルスペース冗長プロトコル（ENRP）[RFC5353]の概要を提供します。プロトコル仕様に加えて、両方のプロトコルに共通のパラメーター形式仕様[RFC5354]、サーバー選択ルール（プールポリシー）[RFC5356]の定義、およびセキュリティ脅威分析[RFC5355]があります。
ASAP defines a straightforward set of mechanisms necessary to support the creation and maintenance of pools of redundant servers. These mechanisms include:
ASAPは、冗長サーバーのプールの作成とメンテナンスをサポートするために必要な単純なメカニズムセットを定義します。これらのメカニズムには次のものが含まれます。
o registration of a new server into a server pool
o 新しいサーバーのサーバープールへの登録
o de-registration of an existing server from a pool
o プールからの既存のサーバーの解体
o resolution of a pool handle to a server or list of servers
o サーバーへのプールハンドルの解像度またはサーバーのリスト
o liveness detection for servers in a pool
o プール内のサーバーのlivension検出
o failover mechanisms for handling a server failure
o サーバー障害を処理するためのフェールオーバーメカニズム
Pools come into existence when a PE registers the first instance of the pool name with an ENRP server. They disappear when the last PE de-registers. In other words, the starting of the first PE on some machine causes the creation of the pool when the registration reaches the ENRP server.
PEがENRPサーバーを使用してプール名の最初のインスタンスを登録すると、プールが生じます。最後のPE脱登録者が消えます。言い換えれば、一部のマシンでの最初のPEの開始により、登録がENRPサーバーに到達したときにプールが作成されます。
It is assumed that information needed for RSerPool, such as the address of an ENRP server to contact, is configured into the PE beforehand. Methods of automating this configuration process are not addressed at this time.
連絡先にENRPサーバーのアドレスなど、RSERPOOLに必要な情報が事前にPEに構成されていると想定されています。この構成プロセスを自動化する方法は、現時点では対処されていません。
A new server joins an existing pool by sending a Registration message via ASAP to an ENRP server, indicating the pool handle of the pool that it wishes to join, a PE identifier for itself (chosen randomly), information about its lifetime in the pool, and what transport protocols and selection policy it supports. The ENRP server that it first contacts is called its Home ENRP server, and maintains a list of subscriptions by the PE as well as performs periodic audits to confirm that the PE is still responsive.
新しいサーバーは、ASAPを介してASAPを介してENRPサーバーに登録メッセージを送信することにより、既存のプールに参加し、参加したいプールのプールハンドル、PE識別子（ランダムに選択）、プールでの寿命に関する情報、そして、それがサポートする輸送プロトコルと選択ポリシー。最初に接触するENRPサーバーは、Home Endp Serverと呼ばれ、PEによるサブスクリプションのリストを維持し、PEがまだ応答していることを確認するために定期的な監査を実行します。
Similar procedures are applied to de-register itself from the server pool (or, alternatively, the server may simply let the lifetime that it previously registered with expire, after which it is gracefully removed from the pool).
同様の手順は、サーバープールから自体を解放するために適用されます（または、以前に登録されていた寿命を期限切れにするだけで、プールから優雅に削除されます）。
When an endpoint wishes to be connected to a server in the pool, it generates an ASAP Handle Resolution message and sends this to its Home ENRP server. The ENRP server resolves the handle based on its knowledge of pool servers and returns a Handle Resolution Response message via ASAP. The response contains a list of the IP addresses of one or more servers in the pool that can be contacted. The process by which the list of servers is created may involve a number of policies for server selection. The RSerPool protocol suite defines a few basic policies and allows the use of external server selection input for more complex policies.
エンドポイントがプール内のサーバーに接続することを希望する場合、ASAPハンドル解像度のメッセージを生成し、これを自宅のENRPサーバーに送信します。ENRPサーバーは、プールサーバーの知識に基づいてハンドルを解決し、できるだけ早くハンドル解像度の応答メッセージを返します。応答には、接触できるプール内の1つ以上のサーバーのIPアドレスのリストが含まれています。サーバーのリストが作成されるプロセスには、サーバーの選択に関する多くのポリシーが含まれる場合があります。RSERPOOLプロトコルスイートは、いくつかの基本的なポリシーを定義し、より複雑なポリシーに外部サーバー選択入力を使用できるようにします。
ENRP servers monitor the status of pool elements using the ASAP Endpoint Keep-Alive message. A PE responds to the ASAP Keep-Alive message with an Endpoint Keep-Alive Ack response.
ENRPサーバーは、ASAPエンドポイントのキープアライブメッセージを使用して、プール要素のステータスを監視します。PEは、エンドポイントのキープアライブACK応答を使用して、ASAP Keep-Aliveメッセージに応答します。
In addition, a PU can notify its Home ENRP server that the PE it used has become unresponsive by sending an ASAP Endpoint Unreachable message to the ENRP server.
さらに、PUは、使用したPEがASAPエンドポイントの到達不可能なメッセージをENRPサーバーに送信することにより反応していないことをHome Enrpサーバーに通知できます。
While maintaining application-independence, the RSerPool protocol suite provides some simple hooks for supporting failover of an individual session with a pool element. Generally, mechanisms for failover that rely on application state or transaction status cannot be defined without more specific knowledge of the application being supported. However, some simple mechanisms supported by RSerPool allow some level of failover that any application can use.
アプリケーション独立を維持しながら、RSERPOOLプロトコルスイートは、プール要素で個々のセッションのフェイルオーバーをサポートするためのいくつかの簡単なフックを提供します。一般に、アプリケーションの状態またはトランザクションステータスに依存するフェールオーバーのメカニズムは、サポートされているアプリケーションのより具体的な知識なしでは定義できません。ただし、RSERPOOLによってサポートされるいくつかの簡単なメカニズムにより、あらゆるアプリケーションが使用できるある程度のフェールオーバーが可能になります。
Cookies may optionally be generated by the ASAP layer and periodically sent from the PE to the PU. The PU only stores the last received cookie. In case of failover, the PU sends this last received cookie to the new PE. This method provides a simple way of state sharing between the PEs. Please note that the old PE should sign the cookie, and the receiving PE should verify that signature. For the PU, the cookie has no structure and is only stored and transmitted to the new PE.
CookieはオプションでASAPレイヤーによって生成され、PEからPEに定期的に送信される場合があります。PUは最後に受け取ったクッキーのみを保存します。フェールオーバーの場合、PUはこの最後の受信クッキーを新しいPEに送信します。この方法は、PES間のシンプルな状態共有方法を提供します。古いPEはCookieに署名する必要があり、受信PEはその署名を確認する必要があることに注意してください。PUの場合、Cookieには構造がなく、新しいPEにのみ保存および送信されます。
A PE can send a business card to its peer (PE or PU) containing its pool handle and guidance concerning which other PEs the peer should use for failover. This gives a PE a means of telling a PU what it identifies as the "next best" PE to use in case of failure, which may be based on pool considerations, such as load balancing, or user considerations, such as PEs that have the most up-to-date state information.
PEは、ピアがフェールオーバーに使用すべき他のPEに関するプールハンドルとガイダンスを含む、ピア（PEまたはPU）に名刺を送信できます。これにより、障害の場合に使用する「次のベスト」PEと識別するPEにPEに、ロードバランスなどのプールの考慮事項やユーザーの考慮事項など、PESなどのユーザーの考慮事項に基づいていることをPEに伝える手段が与えられます。最新の状態情報。
A set of server pools, which is denoted as a handlespace, is managed by ENRP servers. Pools are not valid in the whole Internet but only in smaller domains, called the operational scope. The ENRP servers use the ENRP protocol in order to maintain a distributed, fault-tolerant, real-time registry service. ENRP servers communicate with each other for information exchange, such as pool membership changes, handlespace data synchronization, etc.
ハンドルスペースとして示されるサーバープールのセットは、ENRPサーバーによって管理されます。プールはインターネット全体では有効ではなく、運用範囲と呼ばれる小さなドメインでのみ有効です。ENRPサーバーは、分散型の障害耐性のリアルタイムレジストリサービスを維持するために、ENRPプロトコルを使用します。ENRPサーバーは、プールメンバーシップの変更、ハンドルスペースデータの同期など、情報交換のために互いに通信します。
Each ENRP server initially generates a 32-bit server ID that it uses in subsequent messaging and remains unchanged over the lifetime of the server. It then attempts to learn all of the other ENRP servers within the scope of the server pool, either by using a pre-defined Mentor server or by sending out Presence messages on a well-known multicast channel in order to determine other ENRP servers from the responses and select one as Mentor. A Mentor can be any peer ENRP server. The most current handlespace data is requested by Handle Table Requests from the Mentor. The received answer in the form of Handle Table Response messages is unpacked into the local database. After that, the ENRP server is ready to provide ENRP services.
各ENRPサーバーは、最初に後続のメッセージングで使用する32ビットサーバーIDを生成し、サーバーの寿命にわたって変化しません。次に、事前に定義されたメンターサーバーを使用するか、有名なマルチキャストチャネルでプレゼンスメッセージを送信して、他のENRPサーバーを決定することにより、サーバープールの範囲内の他のすべてのENRPサーバーを学習しようとします。応答し、メンターとして1つを選択します。メンターは、あらゆるピアエンプサーバーにすることができます。最新のハンドルスペースデータは、メンターからのハンドルテーブルリクエストによって要求されます。ハンドルテーブル応答メッセージの形式で受信した回答は、ローカルデータベースに開梱されます。その後、ENRPサーバーはENRPサービスを提供する準備ができています。
PEs can now register their presence with the newly functioning ENRP server by using ASAP messages. They discover the new ENRP server after the server sends out an ASAP Server Announce message on the well-known ASAP multicast channel. PEs only have to register with one ENRP server, as other ENRP servers supporting the pool will synchronize their knowledge about pool elements using the ENRP protocol.
PESは、ASAPメッセージを使用して、新しく機能するENRPサーバーに存在感を登録できるようになりました。彼らは、よく知られているASAPマルチキャストチャネルでASAPサーバーアナウンスメッセージを送信した後、サーバーがASAPサーバーアナウンスメッセージを送信した後に新しいENRPサーバーを発見します。PEは、プールをサポートする他のENRPサーバーがENRPプロトコルを使用してプール要素に関する知識を同期させるため、1つのENRPサーバーに登録する必要があります。
The PE may have a configured list of ENRP servers to talk to, in the form of a list of IP addresses, in which case it will start to set up associations with some number of them and assign the first one that responds to it as its Home ENRP server.
PEには、IPアドレスのリストの形式で通信するENRPサーバーの構成されたリストがある場合があります。ホームENRPサーバー。
Alternatively, it can listen on the multicast channel for a set period, and when it hears an ENRP server, start an association. The first server it gets up can then become its Home ENRP server.
あるいは、設定された期間、マルチキャストチャンネルで聞くことができ、ENRPサーバーを聞いたら、関連性を開始します。それが起きている最初のサーバーは、その後、ホームENRPサーバーになる可能性があります。
ENRP servers send ENRP Presence messages to all of their peers in order to show their liveness. These Presence messages also include a checksum computed over all PE identities for which the ENRP server is in the role of a Home ENRP server. Each ENRP server maintains an up-to-date list of its peers and can also compute the checksum expected from a certain peer, according to its local handlespace database. By comparing the expected sum and the sum reported by a peer (denoted as handlespace audit), an inconsistency can be detected. In such a case, the handlespace -- restricted to the PEs owned by that peer -- can be requested for synchronization, analogously to Section 3.2.
ENRPサーバーは、ENRPのプレゼンスメッセージをすべての仲間に送信して、活気を示します。これらの存在メッセージには、ENRPサーバーがホームENRPサーバーの役割にあるすべてのPE IDに対して計算されたチェックサムも含まれます。各ENRPサーバーは、ピアの最新リストを維持し、ローカルハンドルスペースデータベースに従って、特定のピアから予想されるチェックサムを計算することもできます。予想される合計とピアによって報告された合計（ハンドルスペース監査として示される）を比較することにより、矛盾を検出できます。そのような場合、そのピアが所有するPESに限定されたハンドルスペースは、セクション3.2に似て、同期を要求できます。
If the unresponsiveness of an ENRP server is detected, the remaining ENRP servers negotiate which other server takes over the Home ENRP role for the PEs of the failed peer. After reaching a consensus on the takeover, the ENRP server taking over these PEs sends a notification to its peers (via ENRP) as well as to the PEs taken over (via ASAP).
ENRPサーバーの反応が検出された場合、残りのENRPサーバーは、他のサーバーが失敗したピアのPESのHome EndPの役割を引き継ぐかを交渉します。テイクオーバーのコンセンサスに達した後、これらのPESを引き継ぐENRPサーバーは、（ENRP経由）および（ASAP経由で）引き継がれたPESに通知を（ENRPを介して）送信します。
RSerPool can be used in a 'standalone' manner, where the application uses RSerPool to determine the address of a primary server in the pool, and then interacts directly with that server without further use of RSerPool services. If the initial server fails, the application uses RSerPool again to find the next server in the pool.
RSERPOOLは「スタンドアロン」方法で使用できます。この方法では、アプリケーションがRSERPOOLを使用してプール内のプライマリサーバーのアドレスを決定し、RSERPOOLサービスをさらに使用せずにそのサーバーと直接対話することができます。初期サーバーが失敗した場合、アプリケーションはRSERPOOLを再度使用して、プール内の次のサーバーを見つけます。
For pool user ("client") applications, if an ASAP implementation is available on the client system, there are typically only three modifications required to the application source code: 1. Instead of specifying the hostnames of primary, secondary, tertiary servers, etc., the application user specifies a pool handle.
プールユーザー（「クライアント」）アプリケーションの場合、ASAP実装がクライアントシステムで利用可能である場合、通常、アプリケーションソースコードに必要な3つの変更のみがあります。1。プライマリ、セカンダリ、三次サーバーなどのホスト名を指定する代わりに。、アプリケーションユーザーはプールハンドルを指定します。
2. Instead of using a DNS-based service (e.g., the Unix library function getaddrinfo()) to translate from a hostname to an IP address, the application will invoke an RSerPool service primitive provisionally named GETPRIMARYSERVER that takes a pool handle as input, and returns the IP address of the primary server. The application then uses that IP address just as it would have used the IP address returned by the DNS in the previous scenario.
2. DNSベースのサービス（UNIXライブラリ機能getAddrinfo（））を使用する代わりに、ホスト名からIPアドレスに翻訳する代わりに、アプリケーションは、プールハンドルを入力として取得するgetPrimaryServerという暫定的に名前が付けられた原始的な原始的な原始的なrserpoolサービスを呼び出し、返します。プライマリサーバーのIPアドレス。その後、アプリケーションは、以前のシナリオでDNSによって返されたIPアドレスを使用していたように、そのIPアドレスを使用します。
3. Without the use of additional RSerPool services, failure detection and failover procedures must be designed into each application. However, when failure is detected on the primary server, instead of invoking DNS translation again on the hostname of a secondary server, the application invokes a service primitive provisionally named GETNEXTSERVER, which performs two functions in a single operation.
3. 追加のRSERPOOLサービスを使用しないと、各アプリケーションに障害検出およびフェールオーバー手順を設計する必要があります。ただし、プライマリサーバーで障害が検出された場合、セカンダリサーバーのホスト名でDNS変換を再度呼び出す代わりに、アプリケーションは、単一の操作で2つの関数を実行するGetNextServerという暫定的に暫定的に暫定的に名前が付けられたサービスを呼び出します。
1. First, it indicates to the RSerPool layer the failure of the server returned by a previous GETPRIMARYSERVER or GETNEXTSERVER call.
1. まず、以前のgetPrimaryServerまたはgetNextServerコールによって返されたサーバーの障害をRSERPOOLレイヤーに示します。
2. Second, it provides the IP address of the next server that should be contacted, according to the best information available to the RSerPool layer at the present time (e.g., set of available pool elements, pool element policy in effect for the pool, etc.).
2. 第二に、現在のRSERPOOLレイヤーが利用できる最良の情報に応じて、連絡する必要がある次のサーバーのIPアドレスを提供します（たとえば、利用可能なプール要素のセット、プールに有効なプール要素ポリシーなど。）。
Note: at the time of this document, a full API for use with RSerPool protocols has not yet been defined.
注：このドキュメントの時点で、RSERPOOLプロトコルで使用する完全なAPIはまだ定義されていません。
For pool element ("server") applications where an ASAP implementation is available, two changes are required to the application source code:
ASAP実装が利用可能なプール要素（「サーバー」）アプリケーションの場合、アプリケーションソースコードに2つの変更が必要です。
1. The server should invoke the REGISTER service primitive upon startup to add itself into the server pool using an appropriate pool handle. This also includes the address(es) protocol or mapping id, port (if required by the mapping), and pooling policy (or policies).
1. サーバーは、スタートアップ時にレジスタサービスプリミティブを呼び出して、適切なプールハンドルを使用してサーバープールに追加する必要があります。これには、アドレス（ES）プロトコルまたはマッピングID、ポート（マッピングで必要な場合）、およびプーリングポリシー（またはポリシー）も含まれます。
2. The server should invoke the DEREGISTER service primitive to remove itself from the server pool when shutting down.
2. サーバーは、シャットダウン時にサーバープールからそれ自体を削除するために、登録官サービスの原始的なものを呼び出す必要があります。
When using these RSerPool services, RSerPool provides benefits that are limited (as compared to utilizing all services), but nevertheless quite useful as compared to not using RSerPool at all. First, the client user need only supply a single string, i.e., the pool handle, rather than a list of servers. Second, the decision as to which server is to be used can be determined dynamically by the server selection mechanism (i.e., a "pool policy" performed by ASAP; see ASAP [RFC5352]). Finally, when failures occur, these are reported to the pool via signaling present in ASAP [RFC5352] and ENRP [RFC5353]; other clients will eventually know (once this failure is confirmed by other elements of the RSerPool architecture) that this server has failed.
これらのRSERPOOLサービスを使用する場合、RSERPOOLは限られた利点を提供します（すべてのサービスを利用するのと比較して）が、それでもRSERPOOLを使用していない場合と比較して非常に有用です。まず、クライアントユーザーは、サーバーのリストではなく、単一の文字列、つまりプールハンドルを提供するだけです。第二に、どのサーバーを使用するかについての決定は、サーバーの選択メカニズム（つまり、ASAPによって実行される「プールポリシー」、ASAP [RFC5352]を参照）によって動的に決定できます。最後に、障害が発生したとき、これらはASAP [RFC5352]およびENRP [RFC5353]に存在するシグナリングを介してプールに報告されます。他のクライアントは、このサーバーが失敗したことを最終的に（この失敗がRSERPOOLアーキテクチャの他の要素によって確認されると）知ります。
When the full suite of RSerPool services is used, all communication between the pool user and the pool element is mediated by the RSerPool framework, including session establishment and teardown, and the sending and receiving of data. Accordingly, it is necessary to modify the application to use the service primitives (i.e., the API) provided by RSerPool, rather than the transport layer primitives provided by TCP, Stream Control Transmission Protocol (SCTP), or whatever transport protocol is being used.
RSERPOOLサービスの完全なスイートが使用されると、プールユーザーとプール要素間のすべての通信は、セッションの確立と分解、およびデータの送信と受信など、RSERPOOLフレームワークによって媒介されます。したがって、TCP、ストリーム制御伝送プロトコル（SCTP）、または使用されている輸送プロトコルが提供する輸送層プリミティブではなく、RSERPOOLが提供するサービスプリミティブ（つまり、API）を使用するためにアプリケーションを変更する必要があります。
As in the previous case, sessions (rather than connections or associations) are established, and the destination endpoint is specified as a pool handle rather than as a list of IP addresses with a port number. However, failover from one pool element to another is fully automatic, and can be transparent to the application (so long as the application has saved enough state in a state cookie):
前の場合と同様に、セッション（接続や関連付けではなく）が確立され、宛先エンドポイントは、ポート番号のIPアドレスのリストとしてではなく、プールハンドルとして指定されています。ただし、あるプール要素から別のプール要素へのフェールオーバーは完全に自動であり、アプリケーションに対して透過的である可能性があります（アプリケーションが状態Cookieで十分な状態を保存している限り）：
The RSerPool framework control channel provides maintenance functions to keep pool element lists, policies, etc. current.
RSERPOOLフレームワーク制御チャネルは、プール要素リスト、ポリシーなどを最新の状態に保つためのメンテナンス機能を提供します。
Since the application data (e.g., data channel) is managed by the RSerPool framework, unsent data (data not yet submitted by RSerPool to the underlying transport protocol) is automatically redirected to the newly selected pool element upon failover. If the underlying transport layer supports retrieval of unsent data (as in SCTP), retrieved unsent data can also be automatically re-sent to the newly selected pool element.
アプリケーションデータ（例：データチャネル）はRSERPOOLフレームワークによって管理されるため、フェイルオーバー時に新しく選択されたプール要素に自動的にリダイレクトされた、Unsent Data（RSERPOOLが基礎となる輸送プロトコルにまだ提出していないデータ）。基礎となる輸送層が（SCTPのように）無関係なデータの取得をサポートしている場合、検索された未解決のデータも、新しく選択したプール要素に自動的に再セントすることができます。
An application server (pool element) can provide a state cookie (described in Section 2.5.1) that is automatically passed on to another pool element (by the ASAP layer at the pool user) in the event of a failover. This state cookie can be used to assist the application at the new pool element in recreating whatever state is needed to continue a session or transaction that was interrupted by a failure in the communication between a pool user and the original pool element.
アプリケーションサーバー（プール要素）は、フェールオーバーの場合に（プールユーザーのASAPレイヤーによって）別のプール要素に自動的に渡される状態Cookie（セクション2.5.1で説明）を提供できます。この状態Cookieを使用して、新しいプール要素でアプリケーションを支援して、プールユーザーと元のプール要素間の通信の障害によって中断されたセッションまたはトランザクションを継続するために必要な状態を再現できます。
The application client (pool user) can provide a callback function that is invoked on the pool user side in the case of a failover. This callback function can execute any application-specific failover code, such as generating a special message (or sequence of messages) that helps the new pool element construct any state needed to continue an in-process session.
アプリケーションクライアント（プールユーザー）は、フェールオーバーの場合、プールユーザー側に呼び出されるコールバック関数を提供できます。このコールバック関数は、新しいプール要素がインプロセスセッションを継続するために必要な状態を構築するのに役立つ特別なメッセージ（または一連のメッセージ）を生成するなど、アプリケーション固有のフェールオーバーコードを実行できます。
Suppose in a particular peer-to-peer application, PU A is communicating with PE B, and it so happens that PU A is also a PE in pool X. PU A can pass a "business card" to PE B identifying it as a member of pool X. In the event of a failure at A, or a failure in the communication link between A and B, PE B can use the information in the business card to contact an equivalent PE to PU A from pool X.
特定のピアツーピアアプリケーションで、PU AがPE Bと通信していると仮定します。PUAはプールXのPEでもあります。PUAは「名刺」を渡すことができます。プールXのメンバー。Aで障害が発生した場合、またはAとBの間の通信リンクの障害が発生した場合、PE Bは名刺の情報を使用して、プールXからPU Aに相当するPEに連絡することができます。
Additionally, if the application at PU A is aware of some particular PEs of pool X that would be preferred for B to contact in the event that A becomes unreachable from B, PU A can provide that list to the ASAP layer, and it will be included in A's business card (see Section 2.5.2).
さらに、PU Aでのアプリケーションが、AがBから到達できなくなった場合にBに接触することを好むプールXの特定のPESを認識している場合、PU AはそのリストをASAPレイヤーに提供し、Aの名刺に含まれています（セクション2.5.2を参照）。
A reference implementation of RSerPool is available at [RSerPoolPage] and described in [Dre2006].
RSERPOOLの参照実装は[RSERPOOLPAGE]で入手でき、[DRE2006]で説明されています。
This document does not identify security requirements beyond those already documented in the ENRP and ASAP protocol specifications. A security threat analysis of RSerPool is provided in THREATS [RFC5355].
このドキュメントは、ENRPおよびASAPプロトコルの仕様に既に文書化されているものを超えたセキュリティ要件を特定しません。RSERPOOLのセキュリティ脅威分析は、脅威[RFC5355]で提供されています。
This document does not require additional IANA actions beyond those already identified in the ENRP [RFC5353] and ASAP [RFC5352] protocol specifications.
このドキュメントでは、Enrp [RFC5353]およびASAP [RFC5352]プロトコル仕様で既に特定されているものを超えた追加のIANAアクションは必要ありません。
The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall Stewart, Scott Bradner, and many others for their invaluable comments.
著者は、Maureen Stillman、Qiaobing Xie、Randall Stewart、Scott Bradner、その他多くのコメントに感謝したいと考えています。
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002.
[RFC3237] Tuexen、M.、Xie、Q.、Stewart、R.、Shore、M.、Ong、L.、Loughney、J。、およびM. Stillman、「信頼できるサーバープーリングの要件」、RFC 3237、1月2002年。
[RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.
[RFC5352] Stewart、R.、Xie、Q.、Stillman、M。、およびM. Tuexen、「Aggregate Server Access Protocol（ASAP）」、RFC 5352、2008年9月。
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
[RFC5353] Xie、Q.、Stewart、R.、Stillman、M.、Tuexen、M.、およびA. Silverton、「エンドポイントハンドルスペース冗長プロトコル（ENRP）」、RFC 5353、2008年9月。
[RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008.
[RFC5354] Stewart、R.、Xie、Q.、Stillman、M。、およびM. Tuexen、「Aggregate Server Access Protocol（ASAP）およびEndpoint Handlespace Redundancy Protocol（ENRP）パラメーター」、RFC 5354、2008年9月。
[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, September 2008.
[RFC5355] Stillman、M.、Ed。、Gopal、R.、Guttman、E.、Holdrege、M.、およびS. Sengodan、「信頼できるサーバープーリング（RSERPOOL）によって導入された脅威と脅威に応じてセキュリティの要件」、RFC 5355、2008年9月。
[RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008.
[RFC5356] Dreibholz、T。およびM. Tuexen、「信頼できるサーバープーリングポリシー」、RFC 5356、2008年9月。
[RSerPoolPage] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", <http://tdrwww.iem.uni-due.de/dreibholz/rserpool/>.
[RSERPOOLPAGE] Dreibholz、T。、「Thomas DreibholzのRSerpoolページ」、<http://tdrwww.iem.uni-due.de/dreibholz/rserpool/>。
[Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, Optimization and Extension of a Novel IETF Architecture", Ph.D. Thesis University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, March 2007, <http://duepublico.uni-duisburg-essen.de/ servlets/DerivateServlet/Derivate-16326/ Dre2006-final.pdf>.
[DRE2006] Dreibholz、T。、「信頼できるサーバープーリング - 新しいIETFアーキテクチャの評価、最適化、拡張」、Ph.D。論文学部経済学部、コンピュータサイエンスおよびビジネス情報システム研究所、2007年3月、<http://duepublico.uni-duisburg-essen.de/ servlets/derivateservlet/derivate-16326/dre2006-Final。pdf>。
Authors' Addresses
著者のアドレス
Peter Lei Cisco Systems, Inc. 955 Happfield Dr. Arlington Heights, IL 60004 US
Peter Lei Cisco Systems、Inc。955 Happfield Dr. Arlington Heights、IL 60004 US
Phone: +1 773 695-8201
EMail: peterlei@cisco.com
Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 US
Lyndon Ong Ciena Corporation PO Box 308 Cupertino、CA 95015 US
EMail: Lyong@Ciena.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
マイケル・テクセン・ミューンスター大学。Applied SciencesStegerwaldstraßeの。39 48565 Steinfurtドイツ
EMail: tuexen@fh-muenster.de
Thomas Dreibholz University of Duisburg-Essen, Institute for Experimental Mathematics Ellernstrasse 29 45326 Essen, Nordrhein-Westfalen Germany
トーマス・ドレイブホルツ・ドゥイスブルク・エッセン大学、実験数学研究所エルンストラッセ29 45326エッセン、ノルドルハイン・ヴェストファレン・ドイツ
Phone: +49 201 183-7637
Fax: +49 201 183-7673
EMail: dreibh@iem.uni-due.de
URI: http://www.iem.uni-due.de/~dreibh/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。