[要約] RFC 3237は、信頼性のあるサーバープーリングの要件を定義したものであり、サーバープーリングの信頼性向上を目的としています。
Network Working Group M. Tuexen
Request for Comments: 3237 Siemens AG
Category: Informational Q. Xie
Motorola
R. Stewart
M. Shore
Cisco
L. Ong
Ciena
J. Loughney
M. Stillman
Nokia
January 2002
Requirements for Reliable Server Pooling
信頼できるサーバープーリングの要件
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines a basic set of requirements for reliable server pooling.
このドキュメントは、信頼できるサーバープーリングの基本的な一連の要件を定義しています。
The goal of Reliable Server Pooling (RSerPool) is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool.
信頼できるサーバープーリング（RSERPOOL）の目標は、非常に信頼性の高いアプリケーションをサポートするサーバープールの管理と操作、およびサーバープールへのクライアントアクセスメカニズムのためのアーキテクチャとプロトコルを開発することです。
The Internet is always on. Many users expect services to be always available; many businesses depend upon connectivity 24 hours a day, 7 days a week, 365 days a year. In order to fulfill this level of performance, many proprietary solutions and operating system dependent solutions have been developed to provide highly reliable and highly available servers.
インターネットは常にオンです。多くのユーザーは、サービスが常に利用可能であることを期待しています。多くの企業は、24時間、週7日、年間365日接続に依存しています。このレベルのパフォーマンスを満たすために、非常に信頼性が高く利用可能なサーバーを提供するために、多くの独自のソリューションとオペレーティングシステムに依存するソリューションが開発されました。
This document defines requirements for an architecture and protocols enabling pooling of servers to support high reliability and availability for applications.
このドキュメントでは、アーキテクチャおよびプロトコルの要件を定義し、サーバーのプーリングを可能にして、アプリケーションの高い信頼性と可用性をサポートします。
The range of applications that can benefit from reliable server pooling includes both mobile and real-time applications. Reliable server pooling mechanisms will be designed to support functionality for flexible pooling such as registration and deregistration, and load balancing of traffic across the server pool. Mechanisms will need to balance the needs of scalability, overhead traffic and response time to changes in pool status, as discussed below.
信頼できるサーバープーリングの恩恵を受ける可能性のあるアプリケーションの範囲には、モバイルアプリケーションとリアルタイムアプリケーションの両方が含まれます。信頼できるサーバープーリングメカニズムは、登録や登録などの柔軟なプーリング、サーバープール全体のトラフィックの負荷分散のための機能をサポートするように設計されます。メカニズムは、以下で説明するように、スケーラビリティ、オーバーヘッドトラフィック、およびプールステータスの変化に対する応答時間のニーズのバランスをとる必要があります。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
Operation scope: The part of the network visible to pool users by a specific instance of the reliable server pooling protocols.
操作範囲：信頼できるサーバープールプロトコルの特定のインスタンスによって、ユーザーにプールユーザーに表示されるネットワークの部分。
Pool (or server pool): A collection of servers providing the same application functionality.
プール（またはサーバープール）：同じアプリケーション機能を提供するサーバーのコレクション。
Pool handle (or pool name): A logical pointer to a pool. Each server pool will be identifiable in the operation scope of the system by a unique pool handle or "name".
プールハンドル（またはプール名）：プールへの論理的なポインター。各サーバープールは、一意のプールハンドルまたは「名前」によって、システムの操作範囲で識別できます。
Pool element: A server entity having registered to a pool.
プール要素：プールに登録されたサーバーエンティティ。
Pool user: A server pool user.
プールユーザー：サーバープールユーザー。
Pool element handle (or endpoint handle): A logical pointer to a particular pool element in a pool, consisting of the name of the pool and one or more destination transport addresses for the pool element.
プール要素ハンドル（またはエンドポイントハンドル）：プールの名前とプール要素の1つ以上の宛先輸送アドレスで構成されるプール内の特定のプール要素への論理的なポインター。
Name space: A cohesive structure of pool names and relations that may be queried by an internal or external agent.
名前スペース：内部または外部エージェントが照会する可能性のあるプール名と関係のまとまりのある構造。
Name server: Entity which is responsible for managing and maintaining the name space within the RSerPool operation scope.
名前サーバー：RSERPOOL操作範囲内の名前スペースの管理と維持を担当するエンティティ。
RSerPool: The architecture and protocols for reliable server pooling.
RSERPOOL：信頼できるサーバープーリングのためのアーキテクチャとプロトコル。
PE: Pool element
PE：プール要素
PU: Pool user
PU：プールユーザー
SCTP: Stream Control Transmission Protocol
SCTP：ストリーム制御伝送プロトコル
TCP: Transmission Control Protocol
TCP：伝送制御プロトコル
The solution must allow itself to be implemented and deployed in such a way that there is no single point of failure in the system.
このソリューションは、システムに単一の障害ポイントがないように実装および展開することを可能にする必要があります。
The RSerPool architecture must be able to detect failure of pool elements and name servers supporting the pool, and support failover to available alternate resources.
RSERPOOLアーキテクチャは、プールをサポートするプール要素と名前サーバーの故障を検出し、利用可能な代替リソースへのフェイルオーバーをサポートできる必要があります。
The general architecture should support flexibility of the communication model between pool users and pool elements, especially allowing for a peer-to-peer relationship to support some applications.
一般的なアーキテクチャは、プールユーザーとプール要素間の通信モデルの柔軟性をサポートする必要があります。特に、ピアツーピアの関係がいくつかのアプリケーションをサポートすることを可能にします。
It should be possible to use the protocol stack in small devices, like handheld wireless devices. The solution must scale to devices with a differing range of processing power.
ハンドヘルドワイヤレスデバイスなど、小さなデバイスでプロトコルスタックを使用することが可能です。ソリューションは、処理能力の範囲が異なるデバイスにスケーリングする必要があります。
The protocols used for the pool handling should not cause network congestion. This means that it should not generate heavy traffic, even in case of failures, and has to use flow control and congestion avoidance algorithms which are interoperable with currently deployed techniques, especially the flow control of TCP [RFC793] and SCTP [RFC2960] and must be compliant with [RFC2914].
プールの取り扱いに使用されるプロトコルは、ネットワークの輻輳を引き起こさないはずです。これは、失敗の場合でも交通量を増やすべきではなく、現在展開されている手法、特にTCP [RFC793]およびSCTP [RFC2960]のフロー制御と相互運用可能なフロー制御および渋滞回避アルゴリズムを使用する必要があることを意味します。[RFC2914]に準拠してください。
The architecture should not rely on multicast capabilities of the underlying layer. Nevertheless, it can make use of it if multicast capabilities are available.
アーキテクチャは、基礎となる層のマルチキャスト機能に依存してはなりません。それにもかかわらず、マルチキャスト機能が利用可能な場合、それを利用できます。
Network failures have to be handled and concealed from the application layer as much as possible by the transport protocol. This means that the underlying transport protocol must provide a strong network failure handling capability on top of an acknowledged error-free non-duplicated data delivery service. The failure of a network element must be handled by the transport protocol in such a way that the timing requirements are still fulfilled.
ネットワークの障害は、輸送プロトコルによって可能な限りアプリケーション層から処理および隠される必要があります。これは、基礎となる輸送プロトコルが、認められているエラーのない非重複データ配信サービスに加えて、強力なネットワーク障害処理機能を提供する必要があることを意味します。ネットワーク要素の障害は、タイミング要件がまだ満たされているように、トランスポートプロトコルによって処理される必要があります。
The architecture should allow for ease of interaction between pools and non-RSerPool-aware clients. However, it is assumed that only RSerPool-aware participants will receive maximum timing and notification benefits the architecture offers.
アーキテクチャは、プールと非Rserpoolに認識されていないクライアント間の相互作用を容易にする必要があります。ただし、RSERPOOLを認識している参加者のみが、アーキテクチャが提供する最大のタイミングと通知の特典を受け取ると想定されています。
Another important requirement is that servers should be able to register to (become PEs) and deregister from a server pool transparently without an interruption in service. This means that after a PE has deregistered, it will continue to serve PUs which started their connection before the deregistration of the PE. New connections will be directed towards an alternative PE.
別の重要な要件は、サーバーがサービスを中断することなく透過的に透過的に透過的に登録し（PEになる）、登録できるようにする必要があることです。これは、PEが登録を行いた後、PEの登録の前に接続を開始したPUSを提供し続けることを意味します。新しい接続は、代替PEに向けられます。
Servers should be able to register in multiple server pools which may belong to different namespaces.
サーバーは、異なる名前空間に属する可能性のある複数のサーバープールに登録できる必要があります。
Server pools are identified by pool handles. These pool handles are only valid inside the operation scope. Interoperability between different namespaces has to be provided by other mechanisms.
サーバープールは、プールハンドルによって識別されます。これらのプールハンドルは、操作範囲内でのみ有効です。異なる名前空間間の相互運用性は、他のメカニズムによって提供する必要があります。
The name resolution should not result in a pool element which is not operational. This might be important for fulfilling the timing requirements described below.
名前の解像度は、動作しないプール要素をもたらさないでください。これは、以下で説明するタイミング要件を満たすために重要かもしれません。
The RSerPool mechanisms must be able to support different server selection mechanisms. These are called server pool policies.
RSERPOOLメカニズムは、さまざまなサーバー選択メカニズムをサポートできる必要があります。これらはサーバープールポリシーと呼ばれます。
Examples of server pool policies are:
サーバープールポリシーの例は次のとおりです。
- Round Robin
- ラウンドロビン
- Least used
- 最小使用
- Most used
- 最も使用
The set of supported policies must be extensible in the sense that new policies can be added as required. Non-stochastic and stochastic policies can be supported.
サポートされているポリシーのセットは、必要に応じて新しいポリシーを追加できるという意味で拡張可能でなければなりません。非確率的および確率的ポリシーをサポートできます。
There must be a way for the client to provide operational status feedback to the name server about the pool elements.
クライアントがプール要素についてネームサーバーに運用ステータスフィードバックを提供する方法が必要です。
The name server protocols must be extensible to allow more refined server selection mechanisms to be implemented as they are developed in the future.
ネームサーバープロトコルは、将来開発されているため、より洗練されたサーバー選択メカニズムを実装できるようにするために拡張可能でなければなりません。
For some applications it is important that a client repeatedly connects to the same server in a pool if it is possible, i.e., if that server is still alive. This feature should be supported through the use of pool element handles.
一部のアプリケーションでは、クライアントが可能であれば、クライアントがプール内の同じサーバーに繰り返し接続することが重要です。つまり、そのサーバーがまだ生存している場合です。この機能は、プール要素ハンドルを使用してサポートする必要があります。
Handling of name resolution must be fast to support real-time applications. Moreover, the name space should reflect pool membership changes to the client application as rapidly as possible, i.e., not waiting until the client application next reconnects.
リアルタイムアプリケーションをサポートするには、名前の解決の処理は速い必要があります。さらに、名前スペースは、クライアントアプリケーションのプールメンバーシップの変更をできるだけ迅速に反映する必要があります。つまり、クライアントアプリケーションが次に再接続するまで待っていません。
The architecture should support control of timing parameters based on specific needs, e.g., of an application or implementation.
アーキテクチャは、特定のニーズ、たとえばアプリケーションや実装に基づいたタイミングパラメーターの制御をサポートする必要があります。
In order to support more rapid and accurate response, the requirements on scalability of the mechanism are limited to server pools consisting of a suitably large but not Internet-wide number of elements, as necessary to support bounded delay in handling real-time name resolution.
より迅速かつ正確な応答をサポートするために、メカニズムのスケーラビリティに関する要件は、リアルタイム名解像度の処理の境界遅延をサポートするために必要に応じて、適切に大きいがインターネット全体ではない要素で構成されるサーバープールに限定されます。
Also, there is no requirement to support hierarchical organization of name servers for scalability. Instead, it is envisioned that the set of name servers supporting a particular pool is organized as a flat space of equivalent servers. Accordingly, the impact of relatively frequent updates to ensure accurate reflection of the status of pool elements is limited to the set of name servers supporting a specific pool.
また、スケーラビリティのために名前サーバーの階層構成をサポートするための要件はありません。代わりに、特定のプールをサポートする名前サーバーのセットは、同等のサーバーのフラットスペースとして編成されることが想定されています。したがって、プール要素のステータスを正確に反映するための比較的頻繁な更新の影響は、特定のプールをサポートする名前サーバーのセットに限定されます。
The RSerPool architecture should not require a limitation on the number of server pools or on the number of pool users, although the size of an individual pool may be limited by timing requirements as defined above.
RSERPOOLアーキテクチャは、サーバープールの数またはプールユーザーの数に制限を必要としないはずですが、個々のプールのサイズは、上記のようにタイミング要件によって制限される場合があります。
- The scaling characteristics of the security architecture should be compatible with those given previously.
- セキュリティアーキテクチャのスケーリング特性は、以前に与えられたものと互換性がある必要があります。
- The security architecture should support hosts having a wide range of processing powers.
- セキュリティアーキテクチャは、幅広い処理能力を持つホストをサポートする必要があります。
- It must not be possible for an attacker to falsely register as a pool element with the name server either by masquerading as another pool element or by registering in violation of local authorization policy.
- 別のプール要素を装ったり、ローカル認証ポリシーに違反して登録したりすることにより、攻撃者が名前サーバーでプール要素として誤って登録することは不可能である必要はありません。
- It must not be possible for an attacker to deregister a server which has successfully registered with the name server.
- 攻撃者が名前サーバーに正常に登録されているサーバーを登録することは不可能であってはなりません。
- It must not be possible for an attacker to spoof the response to a query to the name server
- 攻撃者がネームサーバーへのクエリへの応答を押し上げることは不可能であってはなりません
- It must be possible to protect the privacy of queries to the name server and responses to those queries from the name server.
- 名前サーバーへのクエリのプライバシーと、名前サーバーからのクエリへの応答を保護することが可能である必要があります。
- Communication among name servers must be afforded the same protections as communication between clients and name servers.
- 名前サーバー間の通信は、クライアントと名前サーバー間の通信と同じ保護を提供する必要があります。
The security context of an application is a subset of the overall context, and context or state sharing is explicitly out-of-scope for RSerPool. Because RSerPool does introduce new security vulnerabilities to existing applications application designers employing RSerPool should be aware of problems inherent in failing over secured connections. Security services necessarily retain some state and this state may have to be moved or re-established. Examples of this state include authentication or retained ciphertext for ciphers operating in cipher block chaining (CBC) or cipher feedback (CFB) mode. These problems must be addressed by the application or by future work on RSerPool.
アプリケーションのセキュリティコンテキストは、全体的なコンテキストのサブセットであり、コンテキストまたは状態共有は、RSERPOOLのスコープ外です。RSERPOOLは、既存のアプリケーションに新しいセキュリティの脆弱性を導入しているため、RSERPOOLを採用しているアプリケーションデザイナーは、セキュリティで保護された接続に障害に固有の問題に注意する必要があります。セキュリティサービスは必然的に何らかの状態を保持しており、この状態を移動または再確立する必要がある場合があります。この状態の例には、暗号ブロックチェーン（CBC）または暗号フィードバック（CFB）モードで動作する暗号の認証または保持された暗号文が含まれます。これらの問題は、アプリケーションまたはRSERPOOLでの将来の作業によって対処する必要があります。
Security issues are discussed in section 2.13.
セキュリティの問題については、セクション2.13で説明します。
The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot Lear, Christopher Ross, Werner Vogels and many others for their invaluable comments and suggestions.
著者は、バーナード・アボバ、マット・ホールデジ、エリオット・リア、クリストファー・ロス、ヴェルナー・フォーゲルスなどに感謝します。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[RFC959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル（FTP）」、STD 9、RFC 959、1985年10月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[RFC2719] Ong、L.、Rytina、I.、Garcia、M.、Schwarzbauer、H.、Coene、L.、Lin、H.、Juhasz、I.、Holdrege、M. and C. Sharp、 "Framework Architectureシグナリング輸送の場合」、RFC 2719、1999年10月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, November 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。and V.Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年11月。
Michael Tuexen Siemens AG ICN WN CS SE 51 D-81359 Munich Germany
Michael Tuexen Siemens AG ICN WN CS SE 51 D-81359ミュンヘンドイツ
Phone: +49 89 722 47210
EMail: Michael.Tuexen@icn.siemens.de
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, Il 60004 USA
Qiaobing Xie Motorola、Inc。1501 W. Shure Drive、＃2309 Arlington Heights、IL 60004 USA
Phone: +1 847 632 3028
EMail: qxie1@email.mot.com
Randall Stewart Cisco Systems, Inc. 24 Burning Bush Trail Crystal Lake, Il 60012 USA
Randall Stewart Cisco Systems、Inc。24 Burning Bush Trail Crystal Lake、IL 60012 USA
Phone: +1 815 477 2127
EMail: rrs@cisco.com
Melinda Shore Cisco Systems, Inc. 809 Hayts Rd Ithaca, NY 14850 USA
Melinda Shore Cisco Systems、Inc。809 Hayts Rd Ithaca、NY 14850 USA
Phone: +1 607 272 7512 EMail: mshore@cisco.com Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA
電話：1 607 272 7512メール：mshore@cisco.com lyndon ong ciena 10480 Ridgeview Court Cupertino、CA 95014 USA
Phone: +1 408 366 3358
EMail: lyong@ciena.com
John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
ジョン・ラフニー・ノキア・リサーチ・センター私書箱407フィン-00045ノキア・グループフィンランド
Phone: +358 50 483 6242
EMail: john.loughney@nokia.com
Maureen Stillman Nokia 127 W. State Street Ithaca, NY 14850 USA
モーリーンスティルマンノキア127 W.ステートストリートイサカ、ニューヨーク14850 USA
Phone: +1 607 273 0724 62
EMail: maureen.stillman@nokia.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。